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

Чтобы систематизировать подходы к ИИ-программированию, воспользуемся простой моделью. Вместо того чтобы воспринимать «кодинг с ИИ» как единый монолитный процесс, мы можем отобразить его на матрице 2×2, основанной на двух ключевых осях:

1. Вовлеченность человека в код: Пишете ли вы код вручную (читаете, редактируете и проводите код-ревью) или работа с ним полностью делегирована LLM.

2. Метод валидации: Проходит ли проверка результатов неформально (покликать в приложении, оценить интерфейс на глаз, убедиться, что вроде работает) или формально (автотесты, проверка типов, строгие спецификации).

При пересечении этих осей вырисовываются четыре разных стиля разработки:

Четыре подхода

1. Умное автодополнение (Вручную, Неформально)
Вы используете инструменты вроде Copilot или Cursor для генерации небольших сниппетов и автодополнения блоков кода, при этом активно читаете и правите результат сами.

2. Вайб-кодинг (Делегировано, Неформально)
Вы отправляете промпт агенту, и он пишет код. Сам код вы не читаете, а просто открываете приложение, кликаете и смотрите, работает ли оно так, как ожидалось.

3. Разработка, дополненная ИИ (Вручную, Формально)
Это написание кода с использованием ИИ-агентов (Codex, Claude Code). Ответственность за результат по-прежнему лежит на вас: вы указываете агенту, что и где нужно реализовать, применяете TDD или пишете/генерируете тесты, которые затем проверяют созданный агентом код.

4. Агентная инженерия (Делегировано, Формально)
Вы делегируете написание кода ИИ-агенту. Но вместо того чтобы проверять результат вручную, вы помещаете работу ИИ в жесткие рамки тестов, линтеров и других метрик оценки. Код по большей части просматривается только верхнеуровнево. Разработчик определяет, что нужно создать и почему, а агент решает, как это сделать, и сам доказывает, что всё работает корректно. Один из вариантов такого подхода я описал в предыдущей статье.

Правильный подход для каждого этапа

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

• Генерация идей и прототипирование (Вайб-кодинг): Когда вы пытаетесь проверить смелую идею или за 20 минут собрать proof-of-concept, писать юнит-тесты или вычитывать шаблонный код — пустая трата времени. Ваша цель — двигаться максимально быстро, чтобы просто понять, имеет ли концепция смысл.

• Работа с легаси (Умное автодополнение): Проект бывает настолько запутанным, что агенту сложно собрать контекст, нужный для решения задачи. В такой ситуации проще сесть и сделать всё самому, ускоряя процесс небольшими сгенерированными фрагментами кода.

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

• Ядро продакшена (Разработка, дополненная ИИ): При вмешательстве в ядро продукта, работе с пользовательскими данными или критически важными частями системы мы пока не можем полностью полагаться на автономных агентов. Здесь нужно действовать максимально осмотрительно и обязательно проводить код-ревью того, что сгенерировал ИИ.

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