AI уже генерирует код быстрее, чем команды успевают его проверять, и на этом фоне проект Codeplain продвигает жесткий тезис: код пора не поддерживать, а заново собирать из спецификаций. Для русскоязычной IT-аудитории это не теоретический спор о прекрасном будущем, а вполне прикладной вопрос: если LLM превратили написание кода в дешевую операцию, то где теперь находится настоящее узкое место команды.
Как пишет The New Stack, вокруг spec-driven разработки формируется пусть и небольшая, но растущая группа сторонников. Их позиция проста: главным артефактом должен быть не сам код, а спецификация, которая описывает поведение системы, ограничения, интерфейсы и правила работы. Тогда исходники перестают быть чем-то сакральным, что нужно годами латать и беречь. Они становятся производным слоем, который можно регулярно регенерировать под текущие требования, инструменты и архитектурные решения.
На первый взгляд это звучит как очередная итерация старой мечты про «программирование без программирования». Но контекст у идеи другой. Раньше генерация кода упиралась в слабые инструменты, шаблоны и ручную настройку. Теперь код пишут LLM, и проблема сместилась: не как получить еще одну функцию, а как убедиться, что сотни таких функций не превращают репозиторий в склад плохо согласованных решений. Чем быстрее AI производит код, тем дороже становятся ревью, верификация, поддержка и разбор того, почему в одном сервисе бизнес-правило уже изменили, а в другом забыли. На этом фоне spec-driven разработка выглядит не модным лозунгом, а попыткой вернуть контроль над системой через описание намерений, а не через ручную археологию в исходниках.
Логика Codeplain в этом месте довольно прагматична. Если спецификация достаточно точна, проверяема и актуальна, то команда может менять не тысячи строк, а документированный контракт системы. После этого код генерируется заново с учетом новых условий. В такой схеме основная ценность переезжает из «умения аккуратно править легаси» в «умение формализовать поведение продукта так, чтобы его можно было надежно воспроизвести». Для разработчиков это означает сдвиг в сторону тестируемых требований, явных ограничений, машиночитаемых описаний API и более строгой дисциплины вокруг acceptance criteria. Для тимлидов и CTO это еще неприятнее и интереснее одновременно: придется инвестировать не только в AI-инструменты, но и в качество спецификаций, иначе генерация просто ускорит хаос.
Здесь и проходит граница между красивой концепцией и реальной инженерной практикой. Большинство корпоративных систем живут не по чистым спецификациям, а по смеси документации, устных договоренностей, исторических костылей и скрытой бизнес-логики, которая давно осела в коде. В таком ландшафте идея «не поддерживать, а регенерировать» работает только при одном условии: команда действительно знает, что должна делать система, и может это выразить в форме, пригодной для проверки и повторной генерации. Иначе вместо управляемой regeneration-модели получится знакомая история про vibe coding, только с более красивой терминологией. Код появится быстро, но доказать его корректность, безопасность и совместимость с соседними сервисами будет все так же тяжело.
Именно поэтому разговор о spec-driven разработке важен не только для стартапов, которые готовы перепридумывать процесс с нуля, но и для больших продуктовых команд. AI уже снижает стоимость написания кода, а значит, относительная ценность самого акта кодинга падает. Выигрывать будут не те, кто быстрее получает очередной pull request от ассистента, а те, кто умеет превращать требования в проверяемую систему ограничений. На практике это усиливает роль архитектуры, продуктовой аналитики, контрактного тестирования и всего, что раньше считалось скучной подготовительной работой перед «настоящей» разработкой. Парадоксально, но чем мощнее становятся генераторы кода, тем больше отрасль возвращается к старой инженерной истине: дорого не написать программу, дорого точно описать, что она обязана делать.
Вопрос теперь не в том, сможет ли AI писать еще больше кода. С этим рынок уже почти определился. Вопрос в другом: готовы ли команды перестроить процесс так, чтобы исходники стали расходным материалом, а спецификация — главным активом разработки. Если да, то тезис Codeplain про spec-driven разработку может оказаться не провокацией, а довольно трезвым описанием следующего этапа индустрии. Подробнее об исходной публикации — .