Новый сервис в пустом репозитории легко назвать greenfield. А если он должен заменить часть работающей системы, перенести данные за десять лет, сохранить старый API и пройти аудит? «Чистое поле» быстро заканчивается - обычно где-то между первой интеграцией и миграцией данных.

Greenfield и brownfield описывают не возраст и не качество кода, а количество уже существующих ограничений. В greenfield главная задача - проверить гипотезы о будущем продукте. В brownfield - разобраться в накопленных зависимостях и ничего важного не сломать.

С распространением AI-ассистентов и coding agents это различие стало ещё заметнее. Они впечатляюще быстро создают приложение с нуля. Но сколько профессиональной разработки действительно начинается с пустого репозитория? Гораздо чаще нужно сначала понять существующую систему, а затем безопасно изменить её поведение.

Что такое greenfield и brownfield

Термины пришли из строительства и градостроительства:

  • Greenfield - строительство на ранее не освоенной территории. Нет существующих зданий и загрязнений, которые нужно учитывать.
  • Brownfield - повторное использование уже застроенной территории. На ней есть инфраструктура, ограничения и, возможно, последствия прежней эксплуатации.

В разработке ПО метафора работает похожим образом.

Greenfield development - разработка системы с нуля. Команде не нужно сохранять совместимость со старой реализацией, поэтому она может заново определить границы компонентов, структуру данных, технологии и способ выпуска изменений.

Brownfield development - изменение или развитие уже существующей системы. Здесь приходится учитывать её код, данные, контракты, пользователей, интеграции и сложившиеся правила эксплуатации.

Кайл Бейли и Дональд Белчам подробно разбирают такую разработку в книге Brownfield Application Development in .NET. В названии есть .NET, но сам подход к одной платформе не привязан. Авторы пишут о контроле версий, автоматической сборке, тестировании и постепенной работе с зависимостями - всё это пригодится при изменении любой существующей системы.

Greenfield Brownfield
Исходная точка Новая реализация Работающая или унаследованная система
Главный риск Построить не то Сломать то, что уже приносит ценность
Чего не хватает Знаний о продукте и реальной нагрузке Знаний о фактическом поведении и зависимостях
Выбор решений Широкий, но со временем сужается Ограничен совместимостью и миграцией
Обратная связь Появляется вместе с первыми пользователями Уже есть пользователи, инциденты и история изменений
Как выпускать изменения Сначала один сквозной сценарий, затем небольшие законченные функции Небольшие изменения, параллельный запуск старой и новой версии, постепенное переключение

Brownfield - не синоним плохого или legacy-кода

Что тогда считать brownfield? Разработка зрелой, хорошо протестированной системы тоже будет brownfield: у неё уже есть контракты, данные и пользователи. И наоборот, новый код может оказаться плохим уже через несколько недель, но низкое качество само по себе не превращает проект в brownfield. Он становится brownfield, когда очередное изменение уже нельзя сделать без учёта существующей реализации.

Legacy-системой обычно называют важную для бизнеса систему, которую трудно безопасно менять. Brownfield - более широкое понятие: так можно назвать работу с любой существующей системой, даже если её код хорошо устроен и покрыт тестами.

Поэтому greenfield или brownfield - характеристика конкретной задачи, а не всей компании или всего репозитория:

  • новый внутренний инструмент без пользователей может быть greenfield;
  • новый микросервис среди уже работающих систем - greenfield по коду, но brownfield по данным и интеграциям;
  • переписывание старого приложения с нуля - greenfield по реализации, но brownfield по бизнес-правилам, миграции и эксплуатации;
  • добавление функции в качественный монолит - обычный brownfield, хотя никакого «легаси-ужаса» в нём нет.

На практике большинство проектов внутри компаний сочетают оба режима. Новый сервис можно писать с нуля, но подключать его придётся к существующим данным и системам. А как только у сервиса появятся пользователи и контракты, он сам станет brownfield. Обычно быстрее, чем хотелось бы.

Цена свободы и цена истории

Greenfield привлекателен отсутствием старых ограничений. Можно выбрать современный стек, разделить систему на модули по текущему пониманию предметной области и с первого дня настроить CI/CD, мониторинг и проверки безопасности. Пустой репозиторий вообще редко спорит с архитектурой.

Но что команда в этот момент действительно знает о будущей системе? Пока нет реальных данных о нагрузке, редких исключениях в бизнес-процессах и о том, как будет развиваться продукт. Главная опасность greenfield - принять временные предположения за фундаментальные решения и заранее построить сложную архитектуру для воображаемого будущего.

У brownfield другая исходная позиция: система уже доказала свою полезность, а история эксплуатации даёт реальные данные. Проблема в том, что часть требований нигде не записана. Их приходится восстанавливать по коду, данным, конфигурации, привычкам пользователей и памяти сотрудников. Изменение одной строки может нарушить поведение, от которого давно зависит другая система. Если странный обходной путь прожил в production восемь лет, возможно, за ним скрывается бизнес-правило, до которого документация так и не добралась.

Отсюда два разных инженерных вопроса:

В greenfield: как быстро и недорого проверить, что мы строим правильную систему?

В brownfield: как доказать, что изменение сохраняет важное поведение существующей системы?

Практики для greenfield-систем

Как лучше распорядиться свободой нового проекта? Как можно раньше начать получать обратную связь.

  1. Начать с одного простого сценария, работающего целиком. Например, пользователь создаёт заказ через интерфейс, система сохраняет его в базе данных, а приложение можно развернуть в окружении, близком к production. Такой первый сценарий показывает, что основные части системы соединены, сборка и развёртывание работают, а результат уже можно проверить. Этот подход называют walking skeleton - «работающий каркас» будущей системы.
  2. Сначала описать ограничения, потом выбирать инструменты. Зафиксируйте основные пользовательские сценарии, допустимое время простоя и задержки, угрозы безопасности, требования к данным и бюджет. На этом этапе ответы на эти вопросы полезнее выбора фреймворка.
  3. Не делать первые решения необратимыми. В начале проекта многое ещё основано на предположениях, поэтому решения лучше принимать так, чтобы их можно было заменить без большой переделки. Отдельно фиксируйте только тот выбор, который позднее будет дорого изменить: какой сервис владеет данными, как системы обмениваются сообщениями, где проходят границы безопасности и как выполняется развёртывание. Для этого подходит ADR (Architecture Decision Record) - короткая запись о принятом решении, его причинах и рассмотренных альтернативах.
  4. Двигаться небольшими законченными шагами. Каждое изменение должно добавлять небольшой, но работающий пользовательский сценарий целиком - от интерфейса до данных. Такой результат можно отдельно протестировать, показать пользователям, выпустить и при необходимости откатить. Поэтому важнее ограничивать объём одного изменения, чем ускорять написание большого количества кода.
  5. Сразу автоматизировать обязательные проверки. Форматирование, линтеры, тесты, анализ зависимостей, поиск секретов и проверка миграций базы данных должны одинаково запускаться на компьютере разработчика и в CI.
  6. Предпочитать простую модульную архитектуру. Микросервисы полезны при независимых потоках изменений и эксплуатации, а не как доказательство современности проекта. Архитектура ещё успеет стать сложной - помогать ей заранее необязательно.
  7. Удалять экспериментальный код. Быстрый AI-прототип помогает проверить гипотезу, но не обязан становиться основой рабочей системы.

Практики для brownfield-систем

С чего начинается brownfield-разработка? Не с переписывания, а с ответа на простой вопрос: понимаем ли мы систему достаточно хорошо, чтобы безопасно её менять?

1. Понять, как система работает на самом деле

Сравните документацию с кодом, схемами данных, телеметрией, рабочей конфигурацией и историей инцидентов. Поговорите с пользователями и теми, кто сопровождает систему. Документация показывает, как всё было задумано. Работающая система - что получилось на самом деле.

Для начала полезно проследить путь одного пользовательского действия через систему:

Пользовательский сценарий
        ↓
Входной контракт → бизнес-правила → запись данных
        ↓                 ↓              ↓
  интеграции         побочные эффекты   отчёты
        ↓
метрики, алерты и процедура отката

2. Защититься от непреднамеренных поломок

Если модуль невозможно тестировать изолированно, начните с тестов, которые фиксируют его текущее поведение. Сохраните результаты для характерных входных данных, даже если не уверены, что это поведение идеально. Сейчас важно заметить непреднамеренное изменение, а исправить старую логику можно отдельным шагом.

Для сложных преобразований полезны три вида проверок: golden master сравнивает результат с заранее сохранённым образцом, differential-тест прогоняет одни данные через старую и новую реализации, а property-based тест проверяет общие правила на большом наборе автоматически созданных примеров.

Зафиксируйте и исходные эксплуатационные показатели: время ответа, долю ошибок, стоимость, объём ручных операций, частоту инцидентов и время восстановления. Без исходной точки трудно понять, улучшилась ли система или сложность просто переехала в другое место.

3. Найти границу для безопасного изменения

Как менять систему частями, не затрагивая всё сразу? Нужно найти место, где запросы к старой реализации можно перенаправить в новую или отправить в обе для сравнения. В работе с legacy-кодом такую границу называют seam. Ею может быть API, очередь, файловый обмен, таблица, интерфейс модуля или точка маршрутизации.

Для постепенной модернизации особенно полезны:

  • Strangler Fig - перед старой и новой системами создают общий вход, например API gateway. Он постепенно направляет перенесённые функции в новую систему, а остальные запросы пока оставляет на старой. Когда перенос завершён, старую систему отключают;
  • Branch by Abstraction - старую реализацию сначала скрывают за общим интерфейсом. Затем рядом подключают новую и постепенно переводят на неё вызовы;
  • Parallel run - одни и те же данные обрабатывают старым и новым способом, а результаты сравнивают. Пользователь продолжает получать ответ старой системы, пока команда не убедится, что новая работает правильно;
  • Expand and contract - контракт или схему данных сначала расширяют так, чтобы старые клиенты продолжали работать. Затем зависимые системы переводят на новый вариант и только после этого удаляют старый;
  • Anti-corruption layer - между старой и новой моделями ставят адаптер. Он переводит данные и термины, чтобы устройство legacy-системы не определяло архитектуру нового компонента;
  • Feature flags и canary release - новый путь сначала включают для небольшой доли запросов или пользователей. Если ошибок становится больше, трафик быстро возвращают на старую реализацию.

Подробный каталог таких приёмов собран у Мартина Фаулера в Patterns of Legacy Displacement. Общая идея проста: не пытаться переписать legacy-систему одним большим проектом, а заменять её по частям. Так команда может продолжать выпускать полезные изменения и контролировать риск.

4. Считать полное удаление частью результата

Новый сервис рядом со старым - ещё не завершённая модернизация. Пока работают обе реализации, команде приходится поддерживать их и синхронизацию между ними. Так вместо одной сложной системы легко получить две. Поэтому у каждого временного адаптера и старого пути должен быть ответственный, понятное условие отключения и показатель, по которому виден ход миграции.

Как выбрать стратегию

Оставить всё как есть или переписать с нуля? На практике выбор редко сводится к этим двум вариантам.

Ситуация Предпочтительный ход
Изменения обходятся недорого, система хорошо разделена на модули, а тестам можно доверять Развивать на месте
Проблема находится в одном компоненте, который можно отделить от остальных Выделить или заменить этот компонент
Старый продукт нужен ещё годы, но отдельные его части тормозят развитие Постепенно заменять эти части
Нужно проверить новую гипотезу, не затрагивая критически важную систему Greenfield-эксперимент с заранее продуманной интеграцией
Платформа снята с поддержки или риск эксплуатации неприемлем Сделать миграцию приоритетом, но проводить её поэтапно
Поведение не понято и не зафиксировано тестами Сначала исследовать и зафиксировать поведение, затем принимать архитектурное решение

Полное переписывание оправдано, когда старую систему действительно можно выключить, необходимое поведение известно, а перенос данных можно проверить. Важно заранее ограничить и срок, в течение которого старая и новая системы будут работать одновременно. На архитектурной схеме новая система почти всегда выглядит проще: на ней ещё не появились реальные исключения. Если эти условия не выполняются, переписывание с нуля часто создаёт ещё одну систему, которую приходится синхронизировать со старой.

Что меняет AI-разработка

Что именно меняет AI? Он сокращает время на написание кода, но не отменяет работу по изучению системы, проверке результата, согласованию изменений и эксплуатации. Поэтому эффект сильно зависит от типа задачи.

Почему AI легче в greenfield

В новом проекте меньше внутренних зависимостей и исторически сложившихся правил. Кроме того, в обучающих данных AI много примеров использования популярных библиотек. Поэтому он уверенно создаёт каркас проекта, типовые операции с данными, простые интеграции, тестовые данные, документацию и первый вариант интерфейса.

Контролируемый эксперимент 2023 года с 95 разработчиками показал, что участники с GitHub Copilot выполнили задачу по созданию HTTP-сервера на 55,8% быстрее. Это убедительный результат для небольшой задачи с чёткими требованиями, но не универсальная оценка разработки. Участники работали с подготовленным репозиторием и создавали небольшой сервис, а не меняли зрелую систему. Подробнее - в статье The Impact of AI on Developer Productivity.

Именно здесь возникает опасная иллюзия: быстро созданный greenfield-проект выглядит готовым раньше, чем команда проверила модель данных, безопасность, поведение при сбоях и удобство дальнейших изменений. AI ускоряет первый коммит. Скорость всех следующих по-прежнему зависит от качества принятых в начале решений.

Почему AI сложнее в brownfield

Чтобы изменить существующую систему, AI-модели недостаточно знать синтаксис. Ей нужны сведения о том, как устроен именно этот проект:

  • какие контракты публичны, даже если это нигде не записано;
  • почему странный workaround всё ещё существует;
  • какие правила распределены между кодом, БД и внешними системами;
  • чем production-конфигурация отличается от тестовой;
  • какой уровень риска допустим и как откатить изменение.

Можно ли просто загрузить в модель весь репозиторий? Большое окно контекста - объём текста, который модель может обработать за один раз - помогает, но само по себе проблему не решает. В репозитории много файлов, не связанных с текущей задачей. А важные ограничения могут находиться вне кода: в документации, настройках production, истории инцидентов или знаниях сотрудников. Поэтому в brownfield важно не передать модели как можно больше токенов, а выбрать относящиеся к задаче данные и быстро проверить выводы.

Что показывают исследования AI-разработки

Здесь начинается самое интересное. Результаты исследований на первый взгляд противоречат друг другу, но противоречие во многом исчезает, если учитывать зрелость системы, сложность задач и способ измерения.

Общий эффект положительный, но сильно зависит от среды

Опубликованный в 2026 году метаанализ 23 исследований продуктивности и обучения объединил данные 14 работ, в которых измеряли продуктивность. В среднем авторы обнаружили умеренный положительный эффект AI (g = 0,33). Показатель g описывает разницу между группами с AI и без него относительно разброса результатов внутри этих групп. При этом результаты отдельных исследований заметно расходились. В лабораторных задачах эффект был большим (g = 0,73), а в корпоративной разработке (g = 0,19) и open-source (g = 0,01) оценки статистически не отличались от нуля.

Почему разница настолько велика? Чем больше задача похожа на короткий изолированный эксперимент, тем заметнее выигрыш. В реальном проекте часть ускорения уходит на согласования, интеграции, изучение существующего кода и проверку качества. Это хорошо объясняет, почему AI даёт разный выигрыш в новых и существующих системах.

В то же время авторы исследования с участием 4867 разработчиков объединили три рандомизированных полевых эксперимента в Microsoft, Accenture и одной из компаний рейтинга Fortune 100. С AI разработчики завершили на 26,08% больше задач. Однако результаты трёх экспериментов различались. Менее опытные разработчики чаще использовали инструмент и получили больший выигрыш.

В зрелых репозиториях результат может быть противоположным

В рандомизированном контролируемом эксперименте METR 16 опытных open-source разработчиков выполняли 246 реальных задач в знакомых им крупных репозиториях. С AI-инструментами, доступными в начале 2025 года, они потратили в среднем на 19% больше времени. При этом после эксперимента участники считали, что AI ускорил их на 20%. Именно это расхождение особенно интересно: субъективное ощущение скорости не совпало с фактическим временем. Исследователи ограничивают вывод этой группой участников, набором инструментов и типом задач - полный разбор методологии и ограничений.

В обновлении февраля 2026 года необработанные данные уже указывали на небольшое ускорение. Однако METR признал оценку ненадёжной: разработчики, которые сильнее всего зависели от AI, не хотели выполнять задачи без него, а параллельная работа нескольких агентов мешала точно измерить затраченное время. Это хороший пример того, почему одну эффектную цифру нельзя превращать в закон.

Скорость выполнения не равна пониманию

В небольшом контролируемом исследовании 2025 года десять студентов выполняли brownfield-задачи в незнакомом legacy-приложении. С Copilot они закончили работу на 35% быстрее и выполнили на 50% большую часть задания, но сами отмечали, что хуже понимают, почему предложенные решения работают. См. The Effects of GitHub Copilot on … Brownfield Programming Tasks.

В повторном исследовании с 18 магистрантами участники также тратили меньше времени, а их код проходил больше тестов. Но понимание кодовой базы не улучшилось. Авторы назвали это comprehension-performance gap: результат работы с инструментом улучшается быстрее, чем целостное представление разработчика о системе.

Для существующей production-системы это существенный риск. Что произойдёт при первом инциденте, если команда не может объяснить новый код без помощи модели? Вместе с техническим долгом появляется долг понимания.

Локальное ускорение может переносить работу на ревьюеров

Авторы работы 2025 года о нагрузке сопровождения, которая пока не прошла независимое научное рецензирование, обнаружили связь между внедрением Copilot в open-source проектах и ростом объёма повторных исправлений. Опытные core-разработчики стали проверять на 6,5% больше чужого кода, а объём их собственной разработки снизился на 19%. Это наблюдательное исследование, а не рандомизированный эксперимент. Оно показывает связь, но не доказывает, что единственной причиной изменений стал Copilot.

Вывод для практики всё равно полезен: измерять нужно не количество сгенерированных строк и PR, а весь путь задачи до production. Сюда входят время разработки, очередь на проверку, повторные исправления, дефекты, стабильность и результат для пользователя. Строки кода AI увеличивает охотно. Пользователю, правда, полезно не каждое их увеличение.

AI усиливает то, что уже есть в процессе разработки

DORA State of AI-assisted Software Development 2025 основан на ответах почти 5000 специалистов и более чем 100 часах подробных интервью. 90% респондентов уже используют AI в работе, более 80% считают себя продуктивнее. DORA обнаружила положительную связь между использованием AI и количеством выпущенных изменений, но отрицательную - со стабильностью этих выпусков.

Основной вывод отчёта: AI усиливает уже сложившийся процесс разработки. Команды с удобной внутренней платформой, автоматическими тестами, небольшими изменениями и быстрой обратной связью получают больше пользы. Если любое изменение затрагивает много компонентов, а проверки занимают часы или дни, дополнительный код лишь быстрее увеличивает очередь и число сбоев.

AI в модернизации legacy-систем

Где AI приносит наиболее заметную пользу в brownfield уже сегодня? В понимании и проверке существующей системы, а не в её автономной замене:

  • построение карты модулей и зависимостей;
  • поиск реализаций бизнес-правил в коде, SQL и конфигурации;
  • объяснение незнакомого или редкого языка;
  • восстановление черновой документации;
  • генерация тестов, фиксирующих текущее поведение, и тестовых данных;
  • сопоставление старого и нового контрактов;
  • подготовка небольших механических преобразований;
  • анализ логов и инцидентов, оценка компонентов и пользователей, которых может затронуть изменение;
  • независимая проверка плана и изменений в коде.

Исследования показывают и потенциал, и ограничения такого подхода.

MITRE экспериментировал с извлечением из legacy-кода структурированных описаний программной логики, которые затем можно использовать при миграции. LLM смогли создавать такие описания для больших объёмов кода. Однако автоматические оценки качества не совпадали с оценками экспертов предметной области, а надёжность подхода для редких языков и сложных государственных систем осталась недоказанной.

Software Engineering Institute при Carnegie Mellon сообщает, что при прямом переводе сложного кода с помощью LLM базовые тесты находили около 140 ошибок на тысячу строк. Исследователи добавили статический анализ, подсказки с нужным контекстом и автоматическое создание связующего кода. В пилотных проектах это сократило количество ошибок двух типов на границах модулей на 86-100%. Значит, важен не только удачный промпт, но и система независимых проверок вокруг модели.

Авторы свежей работы AgentModernize, пока не прошедшей независимое научное рецензирование, поставили модели задачу не просто перевести код на другой язык, а сохранить поведение старой системы. На этапе анализа система нашла около 91% заранее известных правил. Но после полного переноса лучшая конфигурация сохранила в среднем лишь 19,4% поведения, которое проверялось тестами, на восьми искусственно созданных сценариях. Исследование небольшое, поэтому выводы пока предварительны. Однако разрыв показателен: модели легче найти правило, чем без ошибок перенести его в новую реализацию.

Практический процесс работы с AI

Для greenfield

  1. Команда описывает ожидаемый результат для пользователя, ограничения, критерии приёмки и заведомо недопустимые решения.
  2. AI предлагает несколько вариантов и для каждого перечисляет предположения и компромиссы.
  3. Команда выбирает один минимальный сценарий, который проходит через всю систему, и фиксирует дорогие архитектурные решения в ADR.
  4. AI помогает реализовать один небольшой пользовательский сценарий целиком - от входного запроса до сохранения данных и ответа. Для этого же сценария он готовит тесты, журналирование, метрики и проверку работоспособности после развёртывания.
  5. CI независимо проверяет сборку, типы, тесты, безопасность и миграции.
  6. Измерения на реальной нагрузке заменяют предположения; ненужный сгенерированный код удаляется.

Для brownfield

  1. Сначала исследование, потом изменение. Попросите AI проследить один сценарий и сослаться на конкретные файлы, символы, запросы и конфигурацию.
  2. Отделите факты от гипотез. Для каждого вывода AI должен указать проверяемое основание: код, конфигурацию, документацию или данные наблюдений. Если подтверждения нет, вывод остаётся гипотезой.
  3. Опишите правила, которые нельзя нарушить. Например, прежними должны остаться API-контракт, порядок событий, правила округления, права доступа, повторная обработка запросов и требования к доступности и времени ответа.
  4. Зафиксируйте текущее поведение тестами. Сделайте это до генерации новой реализации, чтобы сразу обнаруживать непреднамеренные изменения.
  5. Разбейте работу по найденной границе. За один шаг агент должен создавать небольшое изменение в коде, которое можно отдельно понять, проверить и откатить.
  6. Разделите создание и проверку решения. Сначала AI предлагает изменение. Затем запустите отдельную проверку, которая будет искать сценарии, где решение не работает, неучтённые зависимости от изменённого API или формата данных, уязвимости и несовместимые изменения структуры данных.
  7. Сравните старую и новую реализацию. Можно незаметно для пользователя отправлять копию реальных запросов в новую систему, запускать обе реализации параллельно или прогонять через них одинаковые тестовые данные. Совпадение результатов доказывает больше, чем уверенное объяснение модели.
  8. Включайте изменение постепенно. Сначала направьте на новую реализацию небольшую долю запросов. Следите за метриками и настройте автоматический возврат на старый путь при ошибках.
  9. Актуализируйте документацию. Зафиксируйте изменённые связи, контракты, бизнес-правила и принятые решения. Тогда следующему инженеру или AI-инструменту не придётся заново исследовать ту же часть системы.

Схематично процесс выглядит так:

Исследование → Важные правила → Тесты текущего поведения → Малый план
      ↑                                                 ↓
Новые факты ← Наблюдение ← Постепенное включение ← Код и проверка

Когда можно давать AI больше самостоятельности? Чем надёжнее независимые проверки, тем больше работы можно ему поручить. Уверенность модели здесь мало что доказывает. Важнее возможность откатить изменение, полнота тестов и масштаб возможных последствий ошибки.

Как измерять пользу AI

Как понять, действительно ли AI помогает? Сравнение «до и после» по числу коммитов почти неизбежно поощряет генерацию большего количества кода. По этой метрике AI способен выглядеть великолепно, даже если очередь на проверку растёт быстрее результата. Полезнее выбрать несколько типов задач, выполнять их с AI и без него в случайном или чередующемся порядке и измерять весь путь до выпуска.

Минимальный набор метрик:

  • время от начала задачи до production, а не только до первого PR;
  • доля принятого кода и количество циклов проверки;
  • объём повторных исправлений в течение 7-30 дней;
  • дефекты, найденные после выпуска, доля неудачных изменений и время восстановления;
  • размер одного изменения и время ожидания CI и проверки кода;
  • изменение эксплуатационной стоимости;
  • понимание системы: может ли инженер объяснить правила, которые нельзя нарушать, и диагностировать сбой без повторной генерации;
  • пользовательский или бизнес-результат.

Анализируйте отдельно разные типы работы: greenfield и brownfield, знакомую и незнакомую кодовую базу, простые и сложные задачи, популярные и редкие технологии. Среднее значение по всей организации скроет именно те различия, от которых зависит результат.

Исследования, доклады и видео

Исследования и отчёты

Доклады и видео

Вывод

Greenfield и brownfield не нужно выбирать один раз и навсегда. В одном проекте они почти всегда встречаются вместе. Новый компонент можно написать с нуля, но затем его придётся подключить к существующим данным, контрактам и процессам эксплуатации.

Главный риск тоже различается. В greenfield можно быстро и уверенно построить не то. В brownfield - правильно изменить код и случайно нарушить старое правило, о котором никто не вспомнил. Архитектурная схема, как обычно, узнает об этом последней.

AI делает эту разницу ещё заметнее. При разработке с нуля он быстро собирает первый рабочий вариант. В зрелой системе полезнее поручать ему поиск связей, объяснение кода, подготовку тестов и небольших изменений. Чем дороже ошибка, тем важнее заранее описать ожидаемое поведение, автоматически проверить результат, независимо просмотреть изменения и включать их постепенно.

AI уже умеет быстро писать много вполне убедительного кода. Интересный инженерный вопрос начинается после генерации:

Можем ли мы дать AI достаточно контекста, а затем быстро проверить три вещи: что именно изменилось, как это повлияло на систему и сможем ли мы безопасно всё откатить?

Комментарии в Telegram-группе!