Годами искусственный интеллект сидел рядом с вами в редакторе и угадывал, что будет дальше. Вы писали строку — он предлагал следующую. Архитектура, отладка и синтаксис все еще оставались вашей зоной ответственности. Это время прошло.
Мы переходим к разработке на основе намерений (Intent-Driven Development). Вы перестаете писать циклы и условия. Вместо этого вы описываете желаемый результат. Агент принимает эту цель, планирует шаги, пишет код, запускает тесты и исправляет собственные ошибки еще до того, как вы увидите результат. Клавиатура больше не является основным инструментом. Главным становится ясность мышления.
Конец построчного программирования
Старый рабочий процесс заставлял вас переводить каждое намерение на конкретный язык, понятный компилятору. Вы держали бизнес-требование в голове, а затем вручную разбивали его на функции, импорты, обработку ошибок и тестовые сценарии. Разработка на основе намерений устраняет этот слой трансляции.
Допустим, вам нужно интегрировать платежный вебхук. Раньше вы бы написали обработчик маршрута, распарсили полезную нагрузку, проверили подпись, обновили базу данных внутри транзакции и поставили в очередь отправку письма с чеком. Теперь вы просто описываете требование: «Проверь входящий вебхук Stripe, запиши событие идемпотентно и запусти процесс отправки чека. Если запись в базу данных не удалась, откати транзакцию». Агент сам напишет обработчик, выберет стратегию парсинга, выстроит логику повторных попыток и сгенерирует тесты. Ваша роль меняется с автора на режиссера.
Это работает только потому, что агент не останавливается на генерации. Он входит в цикл.
Внутри цикла агента
Основная работа больше не заключается в наборе текста или ручной отладке. Это плотный цикл между генерацией и валидацией. Агент создает код, запускает его в вашем тестовом наборе, считывает результат и самостоятельно исправляет ошибки. Пропущенный импорт, несоответствие типов, упавший ассершн — агент видит стек вызовов, редактирует файл и перезапускает тесты. Вы не участвуете в этом цикле. Этот цикл работает со скоростью машины.
Вы подключаетесь только тогда, когда ломается сам цикл. Возможно, агент не может разрешить конфликт между двумя зависимостями или продолжает генерировать код, который проходит юнит-тесты, но нарушает высокоуровневое бизнес-правило. Именно на этих границах человеческое суждение все еще имеет значение.
Ваша настоящая работа: проектировщик ограничений и охотник за граничными случаями
Если машина пишет функции, что остается вам? Две вещи, и они сложнее, чем написание синтаксиса.
Во-первых, вы формулируете ограничения, которые удерживают агента в нужном русле. Агент обладает широкими знаниями, но не понимает специфику вашей среды. Вы должны сказать ему: «Используй только внутренний API биллинга, никогда не логируй сырые токены карт и держи задержку ответа менее двухсот миллисекунд». Эти границы — не просто мимолетные промпты. Это спецификации, определяющие успех или провал.
Во-вторых, вы отлавливаете те десять процентов случаев, когда агент ошибается. Агенты хорошо справляются с типичными сценариями. Они спотыкаются на тонких состояниях гонки (race conditions), неоднозначных граничных случаях бизнес-логики и допущениях безопасности, заложенных в их обучающие данные. Ваше преимущество — в способности заметить гонку между обработчиком вебхука и cron-задачей возврата средств или распознать, что сгенерированная логика повторных попыток может привести к дублированию списаний. Машина решает стандартную задачу. Вы ловите опасное исключение.
Замените ревью кода системой верификации
Когда агент может создавать по пятьдесят файлов за ночь, вы не можете проверять их, просто пробегая глазами диффы в поисках того, «выглядит ли всё правильно». Объем делает визуальный контроль невозможным. Вам нужна система верификации (harness), которая ловит ошибки до того, как код попадет к вам.
Эта система опирается на три столпа.
Отказоустойчивое выполнение. Задачи агента часто длятся дольше, чем таймаут одного запроса. Если шаг не удался из-за временного сбоя сети, система верификации приостанавливает процесс, пробует снова и возобновляет работу, не нарушая состояние системы. Работа сохраняется, несмотря на прерывания.
Структурированные выходные данные. Вместо того чтобы надеяться, что агент вернет корректный конфигурационный файл, вы заранее устанавливаете контракт. Инструменты вроде JSON Schema немедленно проверяют результат. Если агент пропустит обязательное поле или использует неверный тип данных, система верификации отклонит его еще до того, как код коснется вашего репозитория.
Динамические ограничители. У агента не должно быть карт-бланш на чтение секретов или запись в рабочие базы данных. Система верификации динамически управляет правами доступа, изолируя агента в «песочнице», чтобы он мог взаимодействовать только с назначенными тестовыми базами данных и внутренними эндпоинтами. Вы не проверяете каждую строку. Вы проводите аудит «забора», возведенного вокруг агента.
When the Code Works but the Product Fails
Here is the paradox. The harness catches bad code. It cannot catch bad intent.
If your specification says, “Send a welcome email to every new user,” the agent will write clean, tested code that sends that email. It will not know you meant, “Send the welcome email only if the user verified their address, opted into marketing, and signed up during business hours in their local timezone.” The code is technically flawless and commercially dangerous.
The real risk in Intent-Driven Development is ambiguous specification. Unclear intent produces software that solves the wrong problem with textbook elegance. This is why you must treat your specifications as real assets. Version them. Review them with stakeholders. Validate them against actual workflows before the agent starts building. A prompt scribbled into a chat box is not a specification. It is a liability.
Engineering Judgment Moves Upstream
Engineering judgment is not disappearing. It is migrating to a higher altitude.
You no longer spend mental energy on how to iterate a map or structure a class hierarchy. You spend it on what the system must do under failure, what data it must never expose, and which invariants must hold across distributed services. The craft of coding is becoming the craft of requirements.
This means your specifications need the same rigor you once applied to your code. Name your constraints precisely. Define the failure modes explicitly. State the business rules as clearly as you once declared your types. The agent will handle the implementation. You must guarantee that the implementation is worth building.
Move your quality bar from the pull request to the prompt. Build the harness first. Write the specification second. Then let the machine handle the syntax while you focus on whether the problem is defined correctly and the boundaries are drawn safely.
If you want to explore the ideas behind this shift in more depth, the original discussion on Intent-Driven Development is available here. For ongoing conversations around AI-native engineering, you can also join the GyaanSetu community.