Я уже два месяца не писал ни одной функции руками. Кодовая база никогда не была здоровее. Два года назад эта фраза звучала бы как маркетинг. В 2026 это просто новая база, и инженеры, которые этого не видят, вот-вот потеряют ступеньку, на которой они стояли, не замечая.
Это design-time-двойник поста про контекст-инжиниринг. Контекст-инжиниринг — это то, что рантайм собирает в момент исполнения. Spec-driven development — это то, что пишет команда и из чего рантайм потом собирает. Это две стороны одного сдвига, и нельзя всерьёз заниматься одной, не занявшись второй.
Тезис здесь жёстче, чем людям удобно. Ваша кодовая база больше не ваша кодовая база. Ваши спеки — да. Код — это просто кеш.
Сдвиг: код как кеш, спека как истина
Тридцать лет исходный код был долговечным артефактом, а всё остальное — тикеты, требования, архитектурные доки — украшениями вокруг него. Код был единственным местом, где жила истина. Всё остальное дрейфовало.
В 2026 эти отношения переворачиваются на многих командах, включая мою. Долговечный артефакт — это спека: файл, который читает агент, eval-набор, под который её проверяют, ограничения, которым обязана подчиняться система. Код — это то, что регенерируется из спеки по требованию. Если удалить код и оставить спеку, код можно произвести заново. Если удалить спеку и оставить код — вы потеряли истину, и удачи в реверс-инжиниринге из папки .ts-файлов, к которой последними прикасались три разных агента.
Это не гипотеза. Это практическая реальность кодовой базы, где большая часть написания кода делегирована. Код перестаёт быть источником истины, потому что больше нет одного автора, держащего его в голове. Эту роль обязана взять спека, иначе никто.
Это меняет всё, что идёт вниз по течению: ревью, тестирование, онбординг, найм. Дойдём до каждого.
Что такое «спека» в 2026
Спека — это не документ требований. Не user story. Не страница в wiki, которую кто-то написал шесть месяцев назад и никто с тех пор не трогал.
Спека в 2026 — это исполнимый артефакт, который агент читает напрямую, против которого его оценивают и из которого он производит код. У неё есть три конкретные формы, которые встречаются на зрелых командах.
| Старый артефакт | Эквивалент-спека 2026 | Что изменилось |
|---|---|---|
| Тикет в Jira | Feature-спека | Исполнима агентом, а не желаема; лежит в репо, а не в трекере |
| README | CLAUDE.md / AGENTS.md / правила репо | Читаемо машинами, а не только людьми; принудительно, а не декоративно |
| Архитектурный доc | System-спека + eval-набор | Проверяема, а не мемориальна; ревьюится при изменении |
| Комментарий в коде | Inline-спека | Управляет поведением, а не просто описывает |
Формат Anthropic Skills, GitHub Spec Kit, появление файлов AGENTS.md в корне репозиториев — это не разрозненные тренды. Это один и тот же тренд под разными шапками. Индустрия коллективно осознаёт, что долговечный вход для агентских систем должен жить в файле, а не в промпте, и этот файл должен ревьюиться и версионироваться так же, как код.
Иерархия спек
В зрелой spec-driven кодовой базе вы находите четыре уровня, вложенных друг в друга.
Системная спека. Инварианты. Архитектурные правила. Границы безопасности. Ограничения работы с данными. «Все ответы API — JSON; PII не покидает БД; авторизация на edge, а не в хендлерах». Эти редко меняются и редко принадлежат одной фиче. Они живут в корне репо — в AGENTS.md или эквиваленте.
Feature-спека. Что делает возможность. Примеры и контр-примеры. Критерии приёмки. Eval-набор, по которому фича удерживается. Эти переписываются, когда фичи эволюционируют. Они живут рядом с кодом, который описывают, часто как feature.md-сосед к директории реализации.
Task-спека. Единица, которую агент исполняет за один прогон. Уже фичи: «Добавь middleware-ограничитель частоты, использующий существующий Redis-клиент, и излучающий ту же телеметрию, что и auth middleware». Часто эфемерна, но версионирована в описании PR или task-файлах.
Inline-спека. Правила, встроенные в файлы репо — CLAUDE.md, AGENTS.md, комментарии к схемам, директорные README.md, которые агент читает как контекст всего, что делает в этой директории.
Что работает: маленькие спеки, скомпонованные вместе. Большие спеки протекают. Двухтысячесловная feature-спека, покрывающая пять задач, агентом (или человеком) обязуется хуже, чем пять трёхсотсловных, покрывающих по одной задаче.
Что меняется, когда спеки становятся first-class
Как только спека — долговечный артефакт, рабочий процесс ниже по течению меняет форму:
- Code review становится spec review. Ревью PR с двумя сотнями строк сгенерированного агентом кода — неблагодарная работа: код обычно нормальный механически. Ревью спеки, которая его произвела, — высоковажная работа: там реально приняты решения. Команды, которые не перенесли внимание ревью на спеку, всё ещё тратят время сеньоров на код, который агент сгенерирует заново из исправленной спеки за двадцать секунд.
- PR description становится spec diff. «Я поменял спеку политики rate-limit с X на Y; код регенерирован под неё» — гораздо лучшее описание PR, чем стена изменённых файлов. Diff, который интересен людям, — это spec diff. Code diff — его следствие.
- Тестирование становится eval. Юнит-тесты по-прежнему существуют. Но высокоценное тестирование — выполняет ли фича спеку на разных входах, краевых случаях и враждебных условиях — выглядит больше как eval-набор, чем как файл юнит-тестов. Evals привязаны к спеке; меняется спека — меняются evals в том же коммите.
- Дебаг становится spec-gap-анализом. «Почему агент сгенерировал неправильный код?» превращается в «Где в спеке этот случай не доспецифицирован?». Баг почти всегда в спеке, а не в коде, который она произвела. Относиться к спеке как к источнику багов — это самое высоковажное изменение workflow, которое я сделал за два года.
- Онбординг становится чтением спек, а не чтением исходников. Новые инженеры не разгоняются, читая кодовую базу. Они разгоняются, читая системную спеку, потом feature-спеки тех областей, где будут работать. Код идёт вниз по течению — и они сами быстро его произведут, когда поймут ограничения.
Кредитное плечо сеньорного инженера в 2026 — в написании спек, которые агенты других людей исполнят правильно.
Это та часть сдвига, которая бьёт по сеньорам сильнее всего — и в обе стороны. Кредитное плечо огромное. Деятельность непривычная. Мышечная память «писать код руками» начинает атрофироваться, если активно не решать, какие задачи всё ещё этого заслуживают.
Пять правил написания спек, которым агенты действительно подчиняются
Пронумерованы, потому что выработаны в продакшене, а не выведены из блог-постов.
1. Исполнима, а не желаема. Каждой спеке нужна проверка приёмки. «Эта фича должна быть user-friendly» — это не спека, это пожелание. «Когда пользователь отправляет форму без email, верни 400 с телом {error: 'email_required'} и залогируй событие validation_failed с ID формы» — это спека. Правило: если из одной спеки нельзя написать тест — спека не готова.
2. Показывайте примеры и контр-примеры. Агенты быстрее учатся на контрасте, чем на правилах. Спека «имена должны быть в sentence case» слабее, чем спека, добавляющая «Пример: ‘Annual revenue’. Контр-пример: ‘annual_revenue’ или ‘AnnualRevenue’». Всегда показывайте, как выход не должен выглядеть. Вот где живёт настоящая управляемость.
3. Называйте режимы отказа. Позитивные спеки («Всегда делай X») слабее негативных («Никогда не делай Y»). Агент надёжнее подчиняется «не ходи в БД из хендлера», чем «используй слой репозитория». Оба места в спеке, но если можно написать только одно — пишите отрицание.
4. Версионируйте спеки как код. Спеки лежат в репо. У них есть история. Их ревьюят в PR. Их винят, когда что-то ломается. «Изменение спеки без изменения кода» — это реальная форма PR в 2026: иногда главное изменение — спека, а регенерация кода — следующий шаг. Относиться к спекам как к коду — не обсуждаемо; всё остальное разваливается, если спеки дрейфуют.
5. Одна спека — одна возможность. Большие спеки протекают. Спека, покрывающая аутентификацию и rate-limit и логирование, произведёт код, где одна из этих трёх задач стабильно слегка не так. Разделяйте. Композируйте возможности. Тот же инстинкт «маленькие функции, единая ответственность» применим к спекам с двойной силой.
Где это разваливается
Я продавал бы вам что-то, если бы остановился здесь. Есть реальные случаи, где spec-driven development — неверный фрейм, и притворяться обратным значит обжечься.
- Разведка и исследовательская работа. Вы ещё не знаете, что специфицировать. Вы изучаете форму проблемы. Писать спеку до понимания проблемы — это карго-культ инженерии. В этих фазах пишите код руками, читайте выход, потом извлекайте спеку из того, что сработало. Спека после, а не сначала.
- Перфоманс-критичный код. Горячие циклы, чувствительный к memory layout код, плотные внутренние ядра — агент произведёт нечто, что подходит под спеку, но в два раза медленнее, чем нужно, способами, которые спека предусмотреть не могла. Пишите такие куски руками. Спекуйте поверхность; ядро — руками.
- Археология легаси-кода. «Поменяй эту четырнадцатилетнюю функцию» — редко spec-driven задача. Читайте код, понимайте, что он делает, потом решайте. Спеки — для движения вперёд; археология — отдельная дисциплина.
- Случаи, когда спека длиннее, чем код. Если ваша спека сто строк, а код двадцать — вы переспецифицировали. Соотношение spec-to-code имеет sweet spot, и пересечение его значит, что вы используете спеки как замену тому, что не знаете, что строить. Сделайте шаг назад, напишите тридцатистрочную спеку, согласитесь итерировать.
Честная рамка: spec-driven development — это дефолт для девяноста процентов работы в зрелой кодовой базе 2026. Остальные десять процентов важны, и сеньорный инженер — это тот, кто отличает.
Карьерный угол: автор спек как ремесло
Что меняется лично для вас в зависимости от ступени лестницы, грубо разделяется на три группы.
Джуны. Ловушка очевидна и опасна: писать код, который мог бы написать агент, вместо того чтобы научиться писать спеку, в которой агент нуждался. Самый быстрый способ так и не стать сеньором — гордиться объёмом кода, который вы производите. Самый быстрый способ начать становиться сеньором — гордиться точностью спек, которые вы пишете, включая отрицательные случаи. Каждая написанная вами спека — мыслительный артефакт. Каждая строка агентского кода — нет.
Мидлы. Сдвиг сильнее всего здесь. Ваше старое кредитное плечо — писать код хорошо; ваше новое — писать спеки хорошо. Карьерный риск: если вы не сделаете переход, разрыв до сеньора станет сложнее закрыть, потому что то, за что сейчас нанимают сеньоров, лежит выше по течению, чем код. Карьерная возможность: spec authoring — недоразвитый навык по всей индустрии; быстро в нём прокачаться — одна из самых высокодоходных инвестиций, доступных прямо сейчас.
Сеньоры и стаффы. Описание вашей работы сдвинулось, успело догнать ваше звание или нет. Вы — автор спек, который иногда пишет код, а не автор кода, который иногда пишет спеки. Самые сеньорные инженеры, с которыми я работаю, теперь проводят день, формируя спеки, которые управляют пятью-десятью агентскими сессиями параллельно. Кредитное плечо складывается, потому что хорошо сформированные спеки композируются по нескольким агентам и фичам. Плохо сформированные — протекают во все одновременно.
Более глубокая мысль
Спеки — это то, что вы пишете; контекст — это то, что рантайм собирает из них. Оба должны быть правильными. Сломайте одно — и система отказывает способами, которые выглядят как AI-баги, но на самом деле — инженерные. Сделайте оба правильно — и кодовая база большую часть пишет сама. Звучит хлёстко, пока не увидите это в работе, после чего звучит как самый важный сдвиг в инженерной практике со времён системы контроля версий.
Если хотите глубже, в курсах ниже — те части дисциплины, которые я преподаю чаще всего: Claude Code Mastery: Agentic Coding for Engineers — ежедневный workflow spec-driven development с реальным агентом, Building Agents with the Claude Agent SDK — построение агентов, потребляющих спеки как first-class вход, Prompt Engineering & AI Workflow Automation — фундамент prompt-уровня, из которого эволюционируют спеки, и Building MCP Servers & AI Tool Integrations — как сделать спеки переносимыми между агентами и инструментами.
