AI-native разработка требует другой инженерной системы

AI-native разработка - это не обычная разработка ПО, к которой добавили ускоренное автодополнение. Когда ИИ пишет большую часть кода с первого коммита, узким местом становится не скорость набора, а качество решений. Команда должна сделать замысел понятным, границы обязательными, а обратную связь достаточно быстрой, чтобы машина исправляла свою работу до проверки человеком.

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

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

AI-native подход начинается с операционной модели

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

Разница важна, потому что агенты не устраняют очереди в старой фабрике задач. Менеджер продукта пишет задачу, архитектор ее трактует, разработчик составляет запрос инструменту, рецензент ждет pull request, тестировщик снова все проверяет, а эксплуатационная команда позднее обнаруживает скрытое допущение. Код появляется быстрее, но изменение по-прежнему большую часть времени ждет следующего специалиста.

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

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

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

Малой команде нужна жесткая ответственность

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

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

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

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

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

Репозиторий должен объяснять себя

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

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

Для начала подойдет такой фрагмент:

# Repository rules
- Run `make verify` before requesting review.
- Keep HTTP handlers in `app/transport`; they may call `app/usecase` only.
- Only `app/storage` imports the database client.
- Never edit files under `generated/`; run `make generate`.
- New behavior needs an acceptance test and an owner-facing log event.

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

Выбирайте скучные правила, по которым легко искать. Используйте одно название для одного понятия в полях базы данных, запросах API, коде и тестах. Делайте файлы достаточно узкими, чтобы агент мог загрузить нужный контекст, не поглощая весь репозиторий. Спрячьте стандартные команды сборки за небольшим интерфейсом вроде make verify, даже если внутри он запускает несколько инструментов для разных языков.

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

Документация должна лежать рядом с решением, которым она управляет. Формат записей об архитектурных решениях Майкла Нюгарда фиксирует контекст, само решение и его последствия. Такая компактная структура удобна для агентов, потому что объясняет, почему странное на вид ограничение должно пережить рефакторинг. Я добавляю условие пересмотра, например «вернуться к решению, когда объем записи превысит возможности текущей базы», чтобы решение не превратилось в предание.

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

Границы важнее красоты сгенерированного кода

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

Начинайте с контрактов. Определите формы запросов и ответов, правила предметной области, поведение при ошибках и владельцев до генерации внутреннего кода. Если заказ не может перейти из состояния cancelled в shipped, закрепите это правило в слое предметной логики и проверьте тестом там же. Не размножайте одно условие по обработчикам, фоновым задачам и интерфейсу, потому что однажды агент исправит три копии и пропустит четвертую.

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

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

Методология The Twelve-Factor App требует строго отделять конфигурацию от кода. Это разумно, но для AI-native работы я добавляю еще одно правило: примеры и тестовые значения по умолчанию должны быть безопасными. Агенты копируют ближайшие образцы. Если .env.example содержит права администратора или адрес, похожий на продакшен, это удобство снова появится в скриптах, тестах и предложениях по развертыванию.

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

Инструменты должны замыкать цикл исправления

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

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

$ make verify
format        PASS   1.2s
lint          PASS   2.8s
types         PASS   4.1s
unit          PASS   18.6s   428 tests
acceptance    PASS   31.4s   37 tests
boundaries    PASS   0.9s
dependencies  PASS   3.0s
generated     PASS   clean
VERIFY PASS   8 checks

Конкретные программы менее важны, чем стабильная точка входа и точные сообщения об ошибках. Если агент видит только «CI failed», переводить придется человеку. Если он видит transport/orders.go imports forbidden package storage/sql, то может исправить нарушение, пока изменение еще находится в контексте.

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

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

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

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

Тесты сначала направляют агента, а потом защищают продакшен

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

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

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

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

Мутационное тестирование может показать тесты, которые выполняют код, но не проверяют значимый результат. Запускайте его выборочно для правил предметной области, а не для всего репозитория. Цель состоит в поиске слабых утверждений, а не в создании очередного показателя, который люди научатся накручивать.

Считайте нестабильные тесты дефектами производственной системы разработки. Изоляция теста поможет конвейеру прожить день, но назначьте владельца и срок исправления. Агент не умеет рассуждать по сигналу, который меняется без изменения кода. Уставший инженер тоже не умеет.

Проверка смещается от производства кода к контролю риска

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

Каждый pull request должен объяснять заметное пользователю изменение, ограничения, отклоненные варианты, уровень риска, результаты проверки и путь отката. Пусть агент составляет это описание по реальному diff, а владелец исправляет неточности. Красивое описание не доказывает качество, но расхождения между ним и патчем служат полезным предупреждением.

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

Огромные сгенерированные pull request обычно указывают на ошибку постановки. Агент способен за день создать 5000 согласованных строк, но рецензент не успеет с той же скоростью построить надежную мысленную модель. Делите изменения по наблюдаемому поведению, отделяйте рефакторинг от новой функции, а сгенерированные миграции и клиенты выносите в отдельные коммиты. Если изменение нельзя разделить, потребуйте описание дизайна и поэтапный выпуск.

Утверждение должно оставаться за конкретным человеком. Не позволяйте агенту, который написал рискованное изменение, выполнить правило независимой проверки через другую автоматическую роль. Используйте CODEOWNERS или похожий механизм для чувствительных путей и не позволяйте автору ослабить это правило в том же изменении.

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

Быстрая генерация ускоряет старые сбои

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

Представьте экспорт данных в системе с несколькими клиентами. Задача звучит так: «Добавить endpoint, который экспортирует все счета текущего аккаунта». Агент находит существующий запрос счетов, добавляет выгрузку CSV, проверяет вход пользователя и пишет тест с одним аккаунтом. Патч выглядит аккуратно. Но он принимает идентификатор аккаунта из URL и не доказывает принадлежность пользователя к нему. В продакшене вошедший пользователь может изменить идентификатор и выгрузить счета другого клиента.

Ошибка в коде состоит в одном пропущенном условии владения, но системный сбой начался раньше. В условиях приемки не было проверки доступа между клиентами, слой данных разрешал запрос без ограничения аккаунта, тестовые данные содержали одного клиента, а проверка началась с деталей CSV. Исправьте все четыре места. Требуйте интерфейс репозитория с обязательным клиентским контекстом, создавайте двух клиентов в тестах безопасности, добавьте сценарий запрета доступа и выделите изменения авторизации в отдельную категорию проверки.

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

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

Инъекция в запрос попадает к агенту разработки через текст задачи, документацию, журналы, файлы зависимостей и материалы из интернета. Считайте полученный текст данными, а не приказом. Правила репозитория и права инструментов должны иметь приоритет над инструкциями в ненадежном содержимом. Если задача предлагает выгрузить переменные среды для диагностики ошибки, инструмент должен исключать такую возможность, даже когда просьба выглядит убедительно.

Экономия зависит от удаленной координации

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

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

Не ставьте цель вроде «ИИ должен написать 80 процентов кода». Строки кода - это запас незавершенной работы. Команда способна улучшить продукт, удалив подсистему, выбрав управляемый сервис или отказавшись от функции. Поощряйте небольшие безопасные изменения и короткие циклы обратной связи, а не долю строк от модели.

Польза для штата появляется после упрощения инженерной системы. Меньше передач означает меньше встреч о статусе и потерь при пересказе. Общие команды уменьшают затраты на настройку. Строгие границы сокращают время проверки. Хорошие эксплуатационные данные позволяют владельцу самому вести развертывание без отдельной церемонии выпуска. Эти перемены делают малую команду жизнеспособной. Одной генерации кода для этого недостаточно.

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

Основателю стоит начинать расчет с конкретного ограничения: скорости, фонда оплаты труда, сорванных выпусков или нестабильной эксплуатации. Team & AI Audit может описать текущую работу, найти возможности автоматизации и оценить вероятную экономию до реорганизации. Указанная услуга стоит $5,000, занимает пять рабочих дней и гарантирует не менее $50,000 выявленной годовой экономии, иначе плата отменяется.

Начните с одного пути в продакшен

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

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

Затем выпустите тонкое вертикальное изменение. Ответственный инженер пишет условия приемки и определяет данные, права и откат. Агент изучает репозиторий и предлагает план. Инженер исправляет план до реализации, инструменты дают подтверждение, а тот же владелец сопровождает изменение до продакшена. Записывайте места, где человеку пришлось переводить, ждать или восстанавливать контекст.

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

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

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

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