Как выстроить AI-native разработку

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

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

Полный доступ не означает безусловного доверия. Для инженерной задачи нужно заранее определить минимальное ожидаемое изменение, запрещённые действия и наблюдаемый результат. Агент может считать, что свободен, но операционная система, права репозитория, sandbox и Git задают границы ущерба. Правила, спецификации и архитектурный контекст работают как feedforward, а тесты, линтеры, хуки и CI/CD — как feedback. Вместе они замыкают цикл и возвращают недетерминированное исполнение в проверяемый коридор.

Когда скорость генерации обгоняет способность команды проверять изменения, возникает verification debt. Сеньоры превращаются в живой фильтр для растущего потока diff, перестают понимать систему и со временем лишь подтверждают результат. Выход — проверять не объём кода, а пакет доказательств: тесты, контракты, скриншоты, видео и наблюдаемое изменение поведения. В сложном домене ревьюером может стать не программист, а бухгалтер или юрист. Зелёный CI доказывает соблюдение известных инвариантов, но не подтверждает, что команда решила правильную задачу.

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

Автоматизация меняет и работу людей. В растущем продукте она высвобождает пропускную способность для реального бэклога; в зрелом или умирающем продукте может стать инструментом сокращения затрат. Лидер должен не только выдать инструменты, но и помочь инженерам перейти от знания одного стека к умению выбирать методологию, настраивать проверки и принимать результат агента. Поэтому собеседование будущего ближе к совместной работе над brownfield-задачей, чем к вопросам о деталях языка: важно увидеть, как кандидат исследует систему, формулирует intent и сохраняет понимание.