ИИ-разработка уже не мем, а реальность промышленного использования. Теперь не джун, а нейросеть может нарушить стабильность GitHub, Amazon, Cloudflare и даже сервисов Anthropic и OpenAI. Светила вроде Кента Бека и Дяди Боба осваивают агентскую разработку, вновь ощущая кураж созидания. Эра ИИ пришла — но разработчиков она не заменила, а трансформировала: они перестали писать код вручную.

Новая эра — новые вызовы

Агентская разработка сегодня — это дикий запад. Каждый делает по-своему, фреймворков десятки, если не сотни. Бест-практисов пока нет: каждый хвалит своё болото. Но начинать с чистого листа необязательно.

Опыт автора — 3,5 месяца работы с Claude, 4 тысячи коммитов, 1500 тестов (из них ~350 e2e), 25 тысяч строк продакшн-кода (12k Java, 12k TS/TSX) и столько же тестового кода. Он — техлид в расчётном центре одного из крупнейших банков РФ, фанат экстремального программирования, DDD и TDD. Делится практиками, которые уже запросили коллеги.

Коротко по теории

Согласованная база: LLM-модели систематически врут. Это не баг, а особенность. Придётся с этим жить.

Context Rot

Чем больше контекста загружено в модель — тем хуже её ответы. Явление называется Context Rot: деградация качества при росте объёма контекста. Это центральная проблема ИИ-разработки. Вся свистопляска вокруг — это попытки минимизировать его влияние. Процесс называется Context Engineering.

С одной стороны, LLM нужен контекст: условия, ограничения, связанный код. С другой — чем его больше, тем модель менее надёжна. Работа ведётся в узком диапазоне: между необходимым минимумом и порогом, после которого модель «сходит с ума».

Конкретные значения

На основе опыта и анализа исследований — ориентиры для моделей семейства Opus:

• На контексте >80% модель превращается в «невменяемого олигофрена»; любая нормальная система в этот момент запускает компактизацию.
• На контексте >70% (для 200К) и >40% (для 1М) модель справляется только с простыми задачами.
• На контексте >50% (200К) и >20% (1М) — перестаёт стабильно решать сложные задачи.
• На контексте <40% (200К) и <10% (1М) — модель работает оптимально.

Инструменты контекстного инжиниринга

Основные утилиты в агентских системах:

• /clear — сброс контекста. Новая сессия, вся история теряется. Как в фильме «Город забвения»: модель просыпается с чистого листа. Процесс должен быть устойчив к таким «амнезиям».
• /compact — сжатие контекста в рамках сессии. Модель кратко пересказывает всё. Как в анекдоте про Рабиновича: могут потеряться важные детали. Полезно указывать, что сохранить.
• agents — делегирование задач субагентам. Помогает разгрузить память главного агента. Системы сами это делают, но можно им помогать — хотя они могут и не послушаться.
• /statusline — редактирование статусной строки. Позволяет понимать, с кем сейчас работаешь: с Эйнштейном или Форрестом Гампом.
• /context — отображение текущего контекста. Полезно, если статусная строка не работает.
• /resume — возобновление сессии. Позволяет вернуться к прерванной работе. Большинство сессий с Claude у автора начинаются именно с этого.

Дополнительные техники:

• Spec-Driven Development (SDD) — опора на документацию (часто генерируемую), чтобы после сброса контекста модель имела консистентное представление о системе и планах.
• Прогресс-файлы (progress.md) — чек-листы с ходом выполнения задачи. Позволяют не терять прогресс при сбросе контекста.
• Progressive Disclosure — структура файлов, при которой раскрываются только необходимые детали. Эффективное индексирование контекста.

Тон и философия взаимодействия

Сформировался консенсус, повышающий качество взаимодействия с LLM:

1. Ask don't tell. LLM работает лучше как коллега, а не инструмент. Вместо «сделай так» — «какие есть варианты? какой нравится?». Запрос аргументов повышает качество ответа.
2. Интервью. Вместо детального описания требований — глубокое интервью. Через несколько вопросов кажется, что LLM понимает задачу лучше вас. Позволяет выявить непонятные детали.
3. Графика. Современные LLM читают и рисуют. Сложные вещи можно попросить изобразить. И наоборот — баг, который не описать словами, можно вставить скрином.
4. Ревью вторым агентом. Первый агент выполняет задачу, второй — проверяет правила. Иногда нужен третий проход. Но агент с «чистым» контекстом может переусердствовать и начать строить «воздушные замки».
5. Чек-листы. LLM часто пропускает инструкции. При сотнях требований — почти гарантированно. Чек-листы заставляют модель отчитываться по каждому пункту. Иногда обманывает — пишет, что сломанные тесты «не в скоупе». Но это лечится промптингом и ревью.

Prompt Harness

Со временем вы начнёте повторно использовать одни и те же промпты. У кого-то даже появляется древовидная структура с перекрёстными ссылками. Агентские системы уже поддерживают такие практики:

1. Skills — переиспользуемые промпты для типовых задач.
2. Rules — контекст, полезный в любой момент. Загружается каждый раз.
3. Agents — параллелизация + борьба с Context Rot.
4. Hooks — bash-скрипты, выполняемые по событию. Например, уведомление о завершении задачи.
5. Skill-creator — встроенный в Claude инструмент от Anthropic. Помогает создавать скиллы и валидировать правки. Но при валидации нужно корректировать, чтобы не подсказывать тестовым агентам.

Три главных требования к ИИ-разработке

Автор выделяет три системные ошибки, в которые вляпываются почти все:

1. Нельзя без фреймворка

Голый промптинг — путь в никуда. Разработчики пишут: «сделай», «исправь», «ещё раз исправь» — и в итоге всё правят сами. Контекст-менеджмент, правила кода, архитектура, документация — всё это огромный объём знаний, который приходится повторять снова и снова.

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

2. Нельзя без тестов

Автотесты — это атомы поведения системы. В обычной разработке их часто саботируют. В ИИ-разработке — 100% покрытие обязательно.

Тесты никогда не были так дёшевы в написании. Но ИИ-разработка — самая рискованная по багам. Достаточно вспомнить хит-парад сбоев в AWS, OpenAI, Anthropic, Azure, Cloudflare и GitHub.

3. Нельзя без ревью

Мнение, что ИИ может писать код сам, — опасно. Может. Но как в анекдоте: «Печатаю со скоростью 1000 знаков в минуту... но такая фигня получается!»

Когда Anthropic заявляет «Coding is solved», но не может показать две девятки доступности — это наводит на мысли. Для многих систем такой уровень — непозволительная беспечность.

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

Каждая строка, написанная нейросетью, должна быть отсмотрена. Почему ревью кода от человека — дефолт, а от ИИ — можно пропустить? Ведь ИИ ошибается чаще. Видимо, в нас всех живёт своя внутренняя LLM — ветреная и непостоянная.

Итого: Нельзя без фреймворка с тестами и ревью

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

TDD идеально ложится на эту структуру: сначала проектируем требования, потом — тест-план, затем реализуем. Это естественно для Spec-Driven Development.

Ревью должно быть максимально частым. Большие PR с комментарием «LGTM» — иллюзия. Чем больше код — тем выше шанс пропустить ошибку. Человеческий мозг просто не вмещает большие изменения.

Собственно, фреймворк

Есть ли такой фреймворк в открытом доступе? С оговорками — Superpowers. Он в топ-50 GitHub, опирается на SDD и TDD, open-source, не навязывает архитектуру. Подходит как выбор по умолчанию для лёгких, но дисциплинированных процессов.

Альтернатива

Автор начал без фреймворка, перенося командные практики на ИИ. Со временем промпты превратились в систему — и в итоге в собственный фреймворк. Он строже, чем Superpowers, и лучше соответствует подходам автора: ATDD, Clean Architecture.

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

Итак, вопреки утверждениям скептиков (среди которых не так давно был и я) ИИ-разработка с двух ног влетела в настоящую промышленную эксплуатацию, и мем уже совсем не тот: не джун теперь роняет прод, а нейросеть убивает статистику доступности гитхаба, амазона, Cloudflare и даже самой мекки вайб-кодинга — сервисов Anthropic и OpenAI.

Наконец, когда уже и светила вроде Кента Бека и Дяди Боба осваивают агентскую разработку, вновь ощущая кураж созидания вместо перманентного превозмогания технологий, можно смело констатировать приход новой эры разработки — эры ИИ. И, вопреки ожиданиям некоторых, ИИ так и не смог заменить разработчика, просто сделал так, что разработчики нового поколения больше код руками не пишут.

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

Но ведь не с чистого же листа начинать?

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

Всё последующее следует из 3,5 месяцев танцев с Claude, 4к коммитов, 1500 тестов (из которых ~350 — e2e), 25к строк весьма неплохо отрефакторенного продакшн-кода (12k java back + 12k ts/tsx FE) и такого же объёма тестового кода. Ну и внимательного наблюдения за коллегами и индустрией.

Меня зовутСаша Раковский. Работаю техлидом в расчётном центре одного из крупнейших банков РФ, где ежедневно проводятся миллионы платежей, а ошибка может стоить банку сотни миллионов рублей. Законченный фанатэкстремального программирования, а значит иDDD,TDD, и вот этого всего. Штуки редкие, крутые, так мало кто умеет — для этого я здесь, делюсь опытом. Если стало интересно, добро пожаловать в мойблог.

Коротко по теории

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

Сontext Rot

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

Это явление называетсяContext Rot— деградация качества ответов с ростом контекста. По сути, это центральное понятие во всей ИИ-разработке. Вся остальная свистопляска, как правило, происходит именно вокруг минимизации его негативного влияния и зовётсяContext Engineering.

С другой стороны, ЛЛМ-кам необходим контекст, чтобы решить задачу.  Условия, ограничения, нюансы, связанный код — всё это должно быть загружено в контекст. Собственно, в этом диапазоне контекстного окна мы и работаем: между необходимым для работы контекстом и планкой, после которой модель уже неспособна решить задачу надёжно.

Конкретные значения

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

Опираясь на свой опыт и на то, что я встречал в источниках, я пришёл для себя к следующим цифрам для моделей семейства Opus:

• на контексте >80% модель превращается в невменяемого олигофрена, любая нормальная агентская система в этот момент запускает процесс компактизации контекста;
• на контексте >70% для 200К и >40% для 1М модель может вывезти только простенькие задачки, надёжно решать регулярные задачи она неспособна;
• на контексте >50% для 200к и >20% для 1М модель перестает стабильно решать сложные задачи;
• на контексте <40% для 200к и <10% для 1М модель ведёт себя оптимально.

Инструменты контекстного инжиниринга

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

• /clear— самое частое и полезное. Утилита сброса контекста: новая сессия, теряются вся история прошлой сессии. После этого, как в фильме Memento, модель просыпается с чистого листа, познает окружающий её мир каждый раз заново. Поэтому и процесс разработки должен быть такой, чтобы переживать такие амнезии.
• /compact— сжатие контекста в рамках той же сессии: ЛЛМ-ка кратко пересказывает весь контекст. Тут, как в анекдоте про Рабиновича, который выиграл в лотерее Волку, могут потеряться важные нюансы, поэтому полезно указывать, что сохранить при компактизации.
• agents— чтобы не засорять память главного агента, очень полезно как можно больше задач отдавать субагентам. С таким делегированием неплохо справляются сами агентские системы, но абсолютно не вредно им в этом "помогать". Хотя они гордые, легко могут и не послушаться.
• /statusline- утилита редактирования статусной строки, куда можно вывести состояние контекста, чтобы понимать, кто перед тобой - Альберт Энштейн или Форрест Гамп.
• /context— утилита для отображения текущего состояния контекста для тех, кому, как мне, Клод написал кривой скрипт, и в статусной строке контекст периодически не отображается.
• /resume- утилита для продолжения сессии. Полезно, когда надо вернуться к контексту какой-то работы, и продолжить в нем. Большая часть моих сессий с Claude начинается именно с /resume.

Помимо этого с большой эффективностью используются следующие техники:

• Spec-Driven Development (SDD)— подход с широкой опорой на документацию (в основном, генерированную), чтобы агент после обнуления памяти имел консистентное представление о системе и, в первую очередь, о планах;
• прогресс-файлы (progress.md)— чек-листы с прогрессом выполнения той или иной задачи, чтобы сброс контекста не мешал понимать, что уже сделано, и что еще осталось;
• Progressive Disclosure- структура файлов, построенная таким образом, чтобы постепенно раскрывать только необходимые детали для модели. Этакое индексирование контекста.

Тон и философия взаимодействия

Даже в этом вопросе постепенно появился некий консенсус, который позволяет получать более качественные ответы от LLM:

1. Ask don't tell.LLM лучше работает, когда это не инструмент, а полноценный коллега. Вместо того, чтобы написать "сделай вот так" и смотреть на то, как ЛЛМ делает не так, очень полезно формулировать промпт в виде открытого вопроса "Какие у нас есть варианты? Какой тебе нравится больше?" Одна лишь просьба написать опции и аргументацию делает ЛЛМ на 150 баллов IQ умнее.
2. Интервью.Один из самых-самых полезных инструментов - не формулировать требования в деталях, а попросить провести тщательное и глубокое интервью. Буквально через пару таких вопросов начинает казаться, что ЛЛМ лучше шарит в том, что тебе надо, чем ты. Позволяет уточнить детали в тех вещах, о которых ты и сам не думал.
3. Графика.Многие современные ЛЛМ-ки неплохо справляются с графикой: как с её чтением, так и с рисованием. Многие вещи, которые тяжело понять на словах, можно попросить нарисовать. И наоборот, кривую бажину, которую ни пером не описать, ни в сказке не рассказать, можно просто вставить в CLI скрином.
4. Ревью вторым агентом.Нет ничего более беспомощного безответственного и испорченного, чем LLM, пытающаяся выполнить задание и при этом не нарушить все эти бесконечные правила, которые от неё требуют кожаные. Поэтому крайне полезен второй агент, который может сосредоточиться именно на правилах. Иногда может потребоваться третий проход. А иногда в третий проход агент с "чистым" контекстом может перестараться и начать строить "воздушные замки", пытаясь выполнить правила там, где всё и так ок..
5. Чек-листы.ЛЛМ регулярно пропускают инструкции. Даже агент, который должен только проверить предыдущую LLM, нет-нет да проигнорирует что-нибудь важное. Если число инструкций превышает десятки и сотни важных требований, то ЛЛМ практически гарантированно что-то забудет. Поэтому один из полезных инструментов поддержания дисциплины в инструкциях - чек-листы. ЛЛМ должна письменно отписаться по каждому пункту, как она его прошла, и что сделала.Часто они и тут жульничают - могут написать, что низкий coverage в этом модуле после её изменений - это за пределами скоупа этой задачи. Или то, что тесты сломаны - это нормально, это они и раньше были сломаны. Но все это чинится аккуратным промптингом и ревью.

Prompt Harness

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

Поэтому уже, наверное, все агентские системы вполне справедливо предоставили инструменты для работы с подобными промптами.

1. Skills- переиспользуемые промпты для типовых задач.
2. Rules- загружаются каждую сессию. Контекст, который может оказаться полезным в любой момент.
3. Agents- см. выше, механизм параллелизации работы + борьбы с Context Rot.
4. Hooks- bash скрипт, выполняемый по какому-то событию (например, после выполнения таски). Я использую для уведомлений о завершении выполнения задачи.
5. Skill-creator- skill от антропик для Claude, который включает в себя базовые рекомендации по построению скиллов, и, к тому же, умеет с помощью ключевого слова verify валидировать свои правки. Но при валидации надо его подправлять, чтобы он не подсказывал тестовым агентам, что он от них ждёт.

Три главных требования к ИИ-разработке

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

Я вижу 3 основные проблемы в современной агентской разработке, в которые вляпываются почти все разработчики.

1. Нельзя без фреймворка.

Разработчики регулярно занимаются голым промптингом. Просто пишут нейросетке, что они хотят, чтобы та сделала. Потом просто пишут, что они хотят, чтобы та подправила. Потом снова пишут, что исправить. Потом кидают клавиатуру в экран со словами "Вы же обещали, что Coding is solved" и правят всё сами.

Контекст-менеджмент, правила написания кода/тестов, архитектурные идеи, управление документацией, общее описание процессов разработки - всё это составляет весьма немалый объём знаний, который, если нигде не записать, придётся раз за разом повторять снова и снова.

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

Без обвязки из десятка-другого промптов (skills и rules), разработка превращается в постоянное объяснение одних и тех же идей и непрерывную борьбу с одними и теми же косяками LLM. Фреймворк же, напротив, превращает разработку в ритмичный спокойный созидательный процесс.

2. Нельзя без тестов.

Все последние 30 лет своего существования эта идея всё никак не может прижиться. Но это очень важная концепция: именно зелёный тест-кейс - это единица поведения, неделимая частица, атом, из которых состоит все поведение системы. И если в обычной разработке разработчики регулярно саботируют автотесты по той или иной причине, то ИИ-разработка без 100% покрытия функционала - это безумие.

Автотесты никогда еще не были так дёшевы в написании и поддержке. При этом разработка ещё никогда не была столь рискованной на баги, как при ИИ: мы видим это на примере хит-парада фейлов 2025-2026 годов в AWS, OpenAI, Anthropic, Microsoft Azure, Cloudflare и GitHub.

3. Нельзя без ревью.

Есть очень распространенное мнение, что ИИ может писать код сам.

Может. Но будет как в том бородатом анекдоте: "Я печатаю со скоростью 1000 знаков в минуту... но такая фигня получается!"

Когда Антропик заявляет, что "Coding is solved", а потом не может 2 девятки показать (см. скрин в начале статьи), то это наталкивает на размышления. Может, Антропик и способен построить успешный бизнес на двух девятках, но для огромного числа информационных систем такой уровень доступности - непозволительная беспечность.

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

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

Поэтому я глубоко убежден, что каждая строчка, написанная нейросетью, должна быть отсмотрена. Не понимаю, почему мы считаем, что обязательное ревью для кода, написанного человеком - это дефолт и мастхев, а для нейросети, которая ошибается явно чаще человека, это дело можно пропустить. Видимо, где-то внутри у нас тоже живёт вся такая ветреная и непостоянная LLM.

Итого: Нельзя без фреймворка с тестами и ревью.

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

Какие тесты?На всю эту структуру идеально ложится идея TDD. Ничего лучше не убеждает в корректности теста и решения, чем красный тест, превратившийся в зелёный. К тому же TDD отлично вписывается в крайне естественный для ИИ-разработки Spec-Driven Development: сначала мы проектируем требования, потом на их основе проектируем тест-план - набор кейсов, необходимый, чтобы убедиться, что все работает. И только после этого мы реализуем эти кейсы один за другим, пока задача не будет окончательно решена.

Какое ревью?Самое частое, какое только возможно. Мы все видели эти PR на 100+ файлов с единственным комментарием: LGTM. Чем больше объём кода подлежит ревью, тем труднее его отсмотреть, и тем легче пропустить что-то важное. Почему так - очевидно: большие изменения просто не способны влезть в ограниченное пространство человеческой черепушки.

Собственно, фреймворк

Есть ли такой фреймворк в открытом доступе? Ну, с оговорками, я бы сказал, что этоSuperpowers. Это крайне популярный фреймворк (в топ-50 на гитхаб), который опирается на идеи Spec-Driven Development и TDD.

Хоть мне он и не подошёл из-за недостаточной строгости, я его, конечно, рекомендую, как выбор по умолчанию. Это open-source с большим коммьюнити, не навязывающий ни технологических, ни архитектурных ограничений - только SDD и TDD. Идеальный выбор для легковесных, но всё еще высокодисциплинированных процессов разработки.

Альтернатива

Своё знакомство с Claude я начинал без фреймворка, пытаясь перенести на ИИ-разработку практики из работы нашей команды. Получившиеся промпты постепенно сами собой переросли в систему скиллов и правил, сформировав самостоятельный фреймворк. В итоге, я весьма доволен результатом, желания переехать на опенсурсный Superpowers, разрабатываемый большим коммьюнити, нет.

Почему? Ну просто я себя не сдерживал ненужными мне ограничениями типа: не навязывать архитектуру, технологию или процесс. В итоге, для моих подходов (ATDD, Clean Architecture) и накопленного набора промптов Superpowers подходит заметно хуже, чем мой фреймворк.

После того, как я поделился результатом в канале, меня попросили опубликовать наработки. Так что, кому тоже интересно потрогать, во второй части можно будет спуллить примерчик и за полчаса-час разобраться, как это работает. Ну и, конечно, залетайте наканал.