Greenfield и brownfield в разработке систем искусственного интеллекта: где ИИ-ассистенты бессильны

---

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

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

Greenfield и brownfield: не про возраст кода, а про ограничения

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

• Greenfield (дословно «зелёное поле») означает разработку системы с нуля. Команда свободна в выборе технологий, структуры данных и архитектуры, потому что нет старого кода и пользователей, с которыми нужно сохранять совместимость.
• Brownfield (дословно «застроенная территория») означает изменение или развитие уже существующей системы. Здесь приходится учитывать код, данные, контракты, интеграции и сложившиеся правила эксплуатации.

Ключевой тезис гайда: brownfield это не синоним плохого или legacy-кода. Зрелая, хорошо протестированная система тоже будет brownfield, потому что у неё уже есть контракты, данные и пользователи. И наоборот, новый код может стать некачественным через несколько недель, но само по себе низкое качество не делает проект brownfield.

Характеристика относится к конкретной задаче, а не ко всей компании:

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

Почему ИИ-ассистенты пасуют на brownfield?

ИИ-ассистенты генерируют код для пустого проекта за минуты. Но в brownfield нужно другое: восстановить требования, которые нигде не записаны, по коду, данным, конфигурации, привычкам пользователей и памяти сотрудников.

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

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

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

Как попробовать на практике?

1. Определите тип задачи. Прежде чем подключать ИИ-ассистента, честно ответьте: вы пишете с нуля или меняете работающую систему? Если есть данные, пользователи или интеграции, это brownfield, даже если код выглядит свежим.

2. Для greenfield: начните с «работающего каркаса». Гайд описывает подход walking skeleton: один простой сценарий, работающий целиком. Пользователь создаёт заказ, система сохраняет его в базе, приложение разворачивается в окружении, близком к продакшену. ИИ-ассистент здесь полезен: он быстро сгенерирует каркас.

3. Для brownfield: сначала опишите ограничения. Зафиксируйте сценарии, допустимое время простоя, угрозы безопасности и бюджет. На этом этапе ответы на эти вопросы полезнее выбора фреймворка. ИИ-ассистент поможет с анализом кода и документированием зависимостей, но итоговое решение остаётся за инженером.

4. Не делайте первые решения необратимыми. В начале проекта многое основано на предположениях. Решения лучше принимать так, чтобы их можно было заменить без большой переделки.

Сравнение с российскими инструментами

В России большинство команд работают именно в brownfield-режиме: корпоративные системы на «1С», банковские платформы, логистические сервисы с данными за годы. При этом популярные ИИ-ассистенты для кода (GitHub Copilot, Cursor) ориентированы на генерацию нового кода, а не на анализ существующего.

Для авторов Дзена и контент-маркетологов это сравнение важно по другой причине: ваши контент-системы, CRM, воронки рассылок это тоже brownfield. Прежде чем автоматизировать их с помощью ИИ, стоит описать зависимости и ограничения.

Что делать с этим прямо сейчас, по ролям

Автору Дзена. Ваш канал с историей публикаций, рубрикатором и аудиторией это brownfield. Перед тем как просить ИИ «написать пост», дайте ему контекст: тональность канала, темы, которые уже раскрыты, формат заголовков. Иначе получите greenfield-текст, который не впишется в существующую систему.

Маркетологу. Если автоматизируете рассылки или генерацию через ИИ, сначала опишите текущие интеграции: CRM, сегменты, триггеры. ИИ-ассистент не знает, что письмо с таким заголовком уже уходило три месяца назад.

Предпринимателю в РФ. Разработка систем с искусственным интеллектом для вашего бизнеса почти наверняка будет brownfield. Требуйте от подрядчика не демо на пустом проекте, а план работы с вашими данными, интеграциями и ограничениями.

Частые вопросы

Brownfield означает, что код плохой?

Нет. Brownfield описывает не качество кода, а наличие ограничений: данные, пользователи, контракты, интеграции. Хорошо написанная система с тестами и документацией тоже будет brownfield, если у неё есть живые пользователи и зависимости.

Может ли один проект быть одновременно greenfield и brownfield?

Да, и это самый частый случай. Новый микросервис пишется с нуля (greenfield по коду), но подключается к существующим данным и системам (brownfield по интеграциям). Как только у сервиса появляются пользователи, он сам становится brownfield.

Зачем это знать, если я не программист?

Потому что любая система, с которой вы работаете (канал на Дзене, CRM, рассылка), это тоже brownfield. Понимание этого помогает правильно ставить задачу ИИ-ассистенту: не «сделай с нуля», а «измени вот это, не сломав вот то».

Гайд фиксирует простую, но часто игнорируемую мысль: свобода пустого проекта заканчивается после первой интеграции, и именно к этому моменту стоит готовиться заранее.