Подходы к разработке в пост-ИИ эпоху

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

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

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

Однако нейросети не пишут хороший код по умолчанию, им должны помочь важнейшие техники:

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

• Доступ к инструментам - Агент должен уметь запустить свой код для отладки.

• Строгие барьеры - Условия, определяемые человеком, которые агент не вправе менять и обязан исполнить (TDD/BDD).

• Версионирование промптов - Итеративное обучение тому, как работать с конкретным проектом.

Работа с контекстом

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

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

На уровне структуры сущностей на первый план выходит предметно-ориентированное программирование (Domain Driven Design) - архитектура приложения должна зеркально отражать реальные бизнес процессы, а не структуру таблиц в базе или типы данных.

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

DDD - отдельная глубокая тема, рекомендую изучить для эффективной ИИ разработки.

Инструментарий для агента

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

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

Определение условий

Человек уделяет особое внимание тестам, возможно даже (о, ужас!) пишет их вручную. Подробные сквозные (e2e) тесты сами по себе являются промптом. Затем мы поручаем агенту исполнить задачу так, чтобы обязательно проходил тест и при этом он не вправе менять сам тест.

Test-Driven Development стал не опционально тем, что неплохо было бы иметь, а стал мощным инструментом для промптов, на которые не получится сгаллюцинировать.
Особые адепты могут абстрагироваться ещё выше до Behavior-Driver Development и Gherkin, но это опять же отдельная глубокая тема.Итеративное обучение

Итеративное обучение

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

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

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

Софтверные инженеры могут не беспокоиться — никто нас не заменит. Люди думают, что можно сказать: «Создай мне Гугл, не делай ошибок», и всё магически появится. Это далеко от истины. Теперь процессы AI‑first, но задачи не перестают быть сложными и инженерный талант даже более востребован, чтобы продукт получился рабочий и поддерживаемый в кратчайшие сроки.

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