Три идеи из Habr, которые кажутся недооценёнными

За последние месяцы на Habr вышло несколько сильных материалов про AI в разработке.

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

Я собрал три общих тренда.

1. Context Engineering становится важнее Prompt Engineering

Проблема уже не в том, чтобы написать особенно хитрый запрос.

Проблема в том, чтобы в нужный момент дать агенту правильный контекст:

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

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

Поэтому инженерия постепенно смещается от «как спросить» к «какие знания собрать, как их структурировать и когда подключить».

2. Спецификация становится источником истины и для людей, и для AI

Раньше спецификация помогала людям договориться до начала разработки. Теперь у неё появляется вторая роль: она становится исполняемым контрактом для агента.

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

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

Хорошая спецификация перестаёт быть документом, который торжественно положили в Confluence и забыли. Она живёт рядом с кодом и меняется вместе с ним.

3. Agent-first процесс заметно отличается от привычного SDLC

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

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

В Content AI, например, оценили общее ускорение зрелой разработки примерно в 10%, хотя отдельные прототипы создавались в 5–10 раз быстрее. Код генерируется быстро, но требования, архитектура, краевые случаи и проверка результата никуда не исчезают.

Поэтому agent-first подход меняет сам процесс:

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

Просто прикрутить AI к старому SDLC недостаточно. Получится тот же конвейер, только с более быстрым генератором очередей.

Мой вывод: через несколько лет мы будем обсуждать уже не столько качество моделей, сколько качество инженерного контекста.

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

Что почитать

— Роль Solution Architect с приходом AI-агентов 
— Spec-Driven Development: контроль AI-кодогенерации 
— Внутри Spec-Driven Development: на что способен Spec Kit 
— Как ИИ изменил разработку в Content AI

Human in the Loop — не кнопка «спросить человека на всякий случай»

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

Звучит разумно. На практике такая схема быстро превращает человека в кнопку «ОК».

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

Human in the Loop нужен не везде. Он нужен там, где цена ошибки оправдывает остановку процесса.

Человек должен оставаться в цепочке, если действие:

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

Например, агент может самостоятельно подготовить миграцию, проверить её на тестовой среде и собрать план отката. Но запуск миграции в production требует подтверждения.

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

Он может сформировать платёжное поручение. Но отправка денег, особенно новому получателю или сверх установленного лимита, требует отдельного решения.

Контрольные точки стоит выбирать не по количеству действий, а по риску. Для этого достаточно оценить три вещи:

1. Последствия ошибки. Что произойдёт, если система ошиблась? 
2. Обратимость. Можно ли быстро и полностью отменить действие? 
3. Неопределённость. Насколько агент уверен, что правильно понял ситуацию?

Чем выше возможный ущерб, ниже обратимость и больше неопределённость, тем раньше должен подключаться человек.

При этом само подтверждение должно быть содержательным. Не «Разрешить продолжить?», а:

— что именно будет сделано; 
— какие объекты и пользователи будут затронуты; 
— почему система предлагает это действие; 
— какие риски она обнаружила; 
— можно ли откатить результат; 
— что произойдёт, если ничего не делать.

Хороший Human in the Loop не заставляет человека контролировать каждый шаг. Он даёт автоматизации работать самостоятельно в безопасных границах и возвращает управление человеку перед действительно рискованным решением.

Иначе получается худший вариант: машина ничего не решает, а человек подтверждает всё, не успевая ничего проверить.