Ты наверняка ловил себя на странном чувстве: открываешь редактор кода, пальцы по привычке тянутся набрать шаблонный компонент на TypeScript, а в голове щелкает мысль: «Зачем я вообще это печатаю вручную, если языковая модель выплюнет этот код за полторы секунды?»
Справедливое сомнение. Я сам долго отгонял от себя эту мысль, списывая автономных агентов на модный хайп для ленивых джуниоров. Казалось, что пока ты сам не прочувствуешь каждый интерфейс, каждый цикл и каждую точку с запятой, надежного продакшена не собрать. Но индустрия перешагнула ту черту, когда отрицать очевидное стало просто экономически невыгодно.
Яркий маркер этого тектонического сдвига — опыт Мэтта Покока. Человек десять лет писал код руками (из них восемь — на серьезном профессиональном уровне), обучил тонкостям TypeScript десятки тысяч инженеров, а сегодня… полностью прекратил вручную набивать синтаксис. В содержательном разборе с Нейтом Херком он разложил по полочкам механику этого перехода. И знаешь, что в его рассказе цепляет сильнее всего? Не победные реляции о «смерти программирования», а честная хроника собственных провалов и грабель, на которые наступает почти каждый, кто пытается переложить работу на автономных агентов вроде Claude Code, OpenClaw или Codex.
Давай разберем эту новую инженерную реальность без корпоративного глянца и посмотрим, что на самом деле отличает сильного разработчика, когда написание кода перестало быть конкурентным преимуществом.
Ловушка жестких спецификаций: почему идея SDD сломалась о реальность
Когда волна моделей вроде Claude 3.5 Sonnet и Opus 4.5 показала, что они умеют писать связный код целыми файлами, индустрию захлестнула идея разработки на основе жестких спецификаций — Spec-Driven Development (SDD). Логика казалась железобетонной: если код стал дешевым расходником, то новым «исходным кодом» становятся сверхподробные текстовые спецификации. Ты садишься, тратишь неделю, выписываешь до мельчайших подробностей структуру данных, все эндпоинты, форматы ответов и граничные случаи, а потом скармливаешь этот монументальный документ агенту и идешь пить кофе.
Мэтт Покок пошел ровно по этому пути, пытаясь построить свой видеоредактор (аналог популярного Descript) с помощью популярных фреймворков спецификаций вроде Spec-Kit и BMAD. И наступил на гигантские грабли. Несколько месяцев работы превратились в бесконечный кошмар отладки.
В чем оказалась засада? В иллюзии человеческого контроля. Когда ты скармливаешь модели гигантскую простыню требований на 50 страниц, ты перегружаешь контекст миллионом ограничений одновременно. Агент пытается удовлетворить пункт 47, незаметно ломает пункт 12, затем пытается починить сломанное и вносит скрытую регрессию в пункт 3. Проект превращается в классическую сцену с собакой в горящем доме: внешне всё компилируется, но архитектура расползается по швам.
Спецификация — это попытка заранее угадать будущее в мире, где само написание кода меняет твоё понимание задачи. Как только агент начинает итеративно внедрять фичу, ты вживую видишь, где интерфейс неудобен, где модель данных избыточна, а где выбранный подход упирается в тупик. Попытка намертво забетонировать ТЗ до первого запуска лишает тебя главного преимущества агентов — скорости проверки гипотез.
Настоящая среда обитания агента: Environment Design вместо культа промптов
Если секрет не в километровых промптах и не в монолитных спецификациях, то в чем? Ответ звучит парадоксально просто: в качестве инженерной среды.
Подумай вот о чем: языковая модель — это не телепат, способный угадать твои скрытые ожидания. Агент воспринимает мир исключительно через окружение, в которое ты его поместил. Если ты бросаешь умнейшую модель в замусоренный монорепозиторий без автотестов, со сломанным линтером и плавающей типизацией, она начнет выдавать такой же мусор. И виноват здесь не искусственный интеллект, а инженер, создавший токсичную среду обитания.
Переход к агентной разработке требует смены фокуса с микроменеджмента формулировок на проектирование обвязки (test harness):
- Чистый компилятор и строгие линтеры: первое, с чем сталкивается агент после генерации файла, — это статический анализатор. Если линтер четко ругается на невалидные типы или нарушенные соглашения, модель исправляет ошибку сама, не дергая человека.
- Быстрые юнит-тесты и песочница: код должен проверяться мгновенно. Когда цикл исполнения тестов занимает 3 секунды, агент успевает сделать десять итераций самопроверки, прежде чем показать результат.
- Изоляция изменений: маленькие, обозримые PR вместо попыток переписать всю кодовую базу за один присест.
Мы уже подробно разбирали, как автономные фабрики программного обеспечения превращают разработку в замкнутый конвейер с автоматическим самолечением кода. Но если фабрика работает в облаке, то на твоем локальном ноутбуке действуют те же законы: инженерная дисциплина среды определяет качество вывода куда сильнее, чем витиеватость промпта.
Агент не знает, оптимизируешь ли ты код под минимальное потребление памяти, читаемость для новичков или скорость сборки. Если ты прямо не укажешь свои приоритеты («мне критически важна обратная совместимость этого модуля и отсутствие внешних зависимостей»), модель выберет путь наименьшего сопротивления. Говори агенту о своих ценностях, а не диктуй каждую строчку синтаксиса.
Управление рассуждениями: почему Opus 5.5 на medium побеждает «сверхинтеллект»
Еще одно занятное наблюдение Мэтта, которое полностью совпало с моими собственными экспериментами: погоня за максимальным уровнем логических усилий модели (Reasoning Effort) часто выходит боком.
Современные тяжелые модели вроде Opus 5.5 или Claude 3.5 позволяют выставлять регулятор размышлений на максимум (high). Казалось бы: пусть подумает подольше, взвесит все квантовые флуктуации и выдаст шедевр! На практике же сверхвысокий reasoning effort нередко приводит к патологическому многословию: агент начинает строить философские трактаты, накручивать сложнейшие абстракции там, где нужен простой тернарный оператор, и сжигать десятки тысяч токенов на ровном месте.
Когда у тебя настроена жесткая тестовая обвязка, уровень усилий medium (а на типовых задачах даже low) работает чище и быстрее. Зачем модели пять минут медитировать над структурой функции, если она может набросать черновой вариант за пару секунд, прогнать его через тесты компилятора, получить обратную связь и довести до зеленого статуса за два коротких шага? Это экономит не только бюджет API, но и твое рабочее время.
Как приручить неизвестные риски: навыки /grill-me и вездесущий язык
Главный вызов для любого архитектора — это «неизвестные неизвестные» (unknown unknowns). Ты физически не способен заранее предвидеть все скрытые коллизии, узкие места безопасности и тонкости деплоя, просто глядя в пустой файл.
Чтобы решить эту проблему, Мэтт Покок разработал любопытный подход, оформив его в открытую библиотеку навыков mattpocock/skills на GitHub. В частности, навык /grill-me (и его расширенную инженерную версию /grill-with-docs).
Как это работает на практике? Вместо того чтобы сразу бросаться писать код по твоему первому импульсу, агент устраивает тебе настоящее перекрестное интервью. Он агрессивно задает неудобные вопросы:
- «Что произойдет, если пользователь нажмет кнопку отмены прямо во время загрузки чанка?»
- «Как этот сервис должен вести себя при потере соединения с базой данных на 500 миллисекунд?»
- «Какой уровень изоляции транзакций мы здесь предполагаем?»
Агент вытаскивает наружу скрытые допущения, которые сидели у тебя в голове, но не были сформулированы явно. В процессе такого диалога формируется дерево архитектурных решений (ADR) и фиксируется единый язык предметной области — Ubiquitous Language из классического Domain-Driven Design (DDD). Термины в коде, в документации GLOSSARY.md и в интерфейсе синхронизируются. После такого 10-минутного штурма модель пишет код практически без осечек, потому что контекст задачи очищен от двусмысленностей.
Существует опасная иллюзия «вайб-кодинга»: запустить агента на выходных, наклепать за пару часов работающий прототип и радоваться скорости. Но если этот прототип лишен тестов, не задокументирован и написан как попало, он моментально превращается в радиоактивный технический долг. В эпоху ИИ плохой код стал самым дорогим за всю историю, потому что агенты при следующих итерациях начинают спотыкаться о собственный мусор и галлюцинировать с удвоенной силой.
Лестница доверия: учись жать на тормоз
Как инженеру перестроить свое мышление и не сгореть от постоянного страха, что ИИ сломает прод? Здесь отлично работает концепция «лестницы доверия» (Trust Ladder), которую сформулировала Лорен Тан.
Когда ты учишься водить автомобиль, инструктор первым делом показывает тебе педаль тормоза, а не учит входить в занос на скорости 150 км/ч. С кодинг-агентами действует ровно то же правило:
- Первая ступень — кнопка стоп и чистый откат: Прежде чем давать агенту команду, научись быстро останавливать его процесс, проверять
git diffи возвращаться к последнему стабильному коммиту за одно нажатие клавиши. - Вторая ступень — ручной надзор за каждой строкой: Ты читаешь каждое сгенерированное изменение в окне диффа, как при ревью кода джуниора.
- Третья ступень — валидация через тесты в песочнице: Ты доверяешь агенту реализацию целиком, но требуешь зеленых тестов перед тем, как взглянуть на итоговый мердж-реквест.
- Четвертая ступень — мультиагентная оркестрация: Ты запускаешь параллельно 4–8 изолированных субагентов на отдельных ветках (или в окружении VPS) под разные задачи: один пишет тесты, второй правит верстку, третий проверяет документацию.
О том, как крупные технологические платформы меняют свои инженерные процессы под эту парадигму, мы подробно говорили, исследуя, как Vercel перестраивает разработку под агентную инженерию и внедряет инструмент fx harness для изоляции сред исполнения. Архитектурный тренд очевиден: чем больше рутины забирает модель, тем выше требования к строгости границ и контрактов, описанных в нашем материале про инженерию автономных ИИ-агентов и контроль архитектурного дрейфа.
В сухом остатке
Профессия разработчика не умирает — она сбрасывает с себя рутинную шелуху ручного набора символов. Механическое перекладывание JSON из одного формата в другой и заучивание специфических сигнатур методов окончательно уходят в прошлое.
Но взамен от инженера требуют куда более глубоких навыков: умения декомпозировать сложные системы, выстраивать непробиваемую тестовую обвязку, управлять неизвестными рисками и формулировать намерения на точном человеческом языке. Синтаксис стал дешев как никогда. Но архитектурное мышление, инженерный вкус и способность сказать агенту твердое «нет, мы так делать не будем» сегодня стоят дороже золота.