Spec-driven development (SDD): почему AI вернул спецификации в разработку (Рубрика #Engineering)
Горячая тема spec-driven development мне кажется реинкарнацией старых подходов типа бородатых V-Model или RUP, что в районе двухтысячных использовались для описания инженерных процессов. Мне стало интересно поразмышлять, а почему так происходит и так появилась этот пост:)
Старый spec-driven подход был про то, что сначала нужно описать требования, потом дизайн, потом реализацию, потом проверку. V-Model хорошо показывала эту симметрию: каждому уровню проектирования соответствует свой уровень validation/verification. Плюсы были в трассировке от требований к коду и проверяемости ожиданий, а минусы были в бюрократии и разрыве между документами и кодом.
С AI ситуация поменялась. Спецификация стала рабочим интерфейсом между человеком и агентом. Если код пишет или сильно помогает писать агент, то главный вопрос уже не “как быстро я напишу реализацию руками”. Главный вопрос: насколько точно я могу сформулировать intent, ограничения, критерии приемки и способ проверки результата. Агенту мало сказать “сделай фичу”. Ему нужен контекст: что должно измениться, что не должно сломаться, какие сценарии считаются успехом, какие тесты запустить, где границы задачи.
Поэтому современный spec-driven development выглядит примерно так:
Теперь документы становятся исполняемым контекстом для агента. Спека используется для составления плана, план раскладывается на задачи, задачи делегируются, тесты и логи становятся доказательством работоспособности, а review проверяет не только diff, но и соответствие исходному намерению.
Есть разные подходы к этому снаряду
1️⃣ GitHub Spec Kit прямо формулирует SDD как процесс “сначала определить, что строить, потом дать AI coding agent реализовать”. Там есть цепочка
2️⃣ Kiro от AWS идет похожим путем, но более продуктово. У них spec обычно раскладывается на
3️⃣ Codex и подход harness engineering показывают третий вариант. Там важны
4️⃣ Есть и lightweight-вариант, который, кажется, сейчас самый практичный для многих команд: PRD/RFC/issue + acceptance tests + CI + agent instructions. Без отдельного фреймворка. Главное, чтобы у задачи был четкий “definition of done”, а агент мог доказать, что он его достиг.
На практике это дает несколько преимуществ
- Меньше неопределенность - агент хуже всего работает там, где человек сам не решил, чего хочет
- Большие задачи проще делегировать - их можно резать на независимые кусочки и проверять по частям
- Появляется трассировка между намерением, дизайном решения, задачами и тестами
- Review перестает быть только чтением diff'а - он становится проверкой: “достигли ли мы цели, которую сами же сформулировали?”
Правда, не все так безоблачно - spec-driven development (SDD) сам по себе не гарантирует качество. Пeлохая спецификация просто быстрее производит неправильный код.
#Engineering #AI #Software #Architecture #Management #DevTools #Agents #ML #SystemDesign
Горячая тема spec-driven development мне кажется реинкарнацией старых подходов типа бородатых V-Model или RUP, что в районе двухтысячных использовались для описания инженерных процессов. Мне стало интересно поразмышлять, а почему так происходит и так появилась этот пост:)
Старый spec-driven подход был про то, что сначала нужно описать требования, потом дизайн, потом реализацию, потом проверку. V-Model хорошо показывала эту симметрию: каждому уровню проектирования соответствует свой уровень validation/verification. Плюсы были в трассировке от требований к коду и проверяемости ожиданий, а минусы были в бюрократии и разрыве между документами и кодом.
С AI ситуация поменялась. Спецификация стала рабочим интерфейсом между человеком и агентом. Если код пишет или сильно помогает писать агент, то главный вопрос уже не “как быстро я напишу реализацию руками”. Главный вопрос: насколько точно я могу сформулировать intent, ограничения, критерии приемки и способ проверки результата. Агенту мало сказать “сделай фичу”. Ему нужен контекст: что должно измениться, что не должно сломаться, какие сценарии считаются успехом, какие тесты запустить, где границы задачи.
Поэтому современный spec-driven development выглядит примерно так:
intent -> acceptance criteria -> plan -> tasks -> implementation -> verification.Теперь документы становятся исполняемым контекстом для агента. Спека используется для составления плана, план раскладывается на задачи, задачи делегируются, тесты и логи становятся доказательством работоспособности, а review проверяет не только diff, но и соответствие исходному намерению.
Есть разные подходы к этому снаряду
1️⃣ GitHub Spec Kit прямо формулирует SDD как процесс “сначала определить, что строить, потом дать AI coding agent реализовать”. Там есть цепочка
spec -> plan -> tasks -> implement, checklists, clarify/analyze шаги и интеграции с разными агентами. Тут соль в agent-agnostic идее: спецификация становится переносимым контрактом, а не промптом для одного IDE.2️⃣ Kiro от AWS идет похожим путем, но более продуктово. У них spec обычно раскладывается на
requirements.md, design.md, tasks.md; отдельно есть steering-файлы для постоянного знания о проекте: архитектура, стек, conventions, структура. Это уже очень похоже на попытку сделать из AI coding управляемый процесс разработки feature или bugfix.3️⃣ Codex и подход harness engineering показывают третий вариант. Там важны
AGENTS.md, знание репозитория, configured dev environment, тесты, логи, PR review и возможность запускать несколько задач параллельно. В таком мире prompt начинает напоминать хорошо написанный GitHub issue: цель, контекст, ограничения, expected behavior, команды проверки.4️⃣ Есть и lightweight-вариант, который, кажется, сейчас самый практичный для многих команд: PRD/RFC/issue + acceptance tests + CI + agent instructions. Без отдельного фреймворка. Главное, чтобы у задачи был четкий “definition of done”, а агент мог доказать, что он его достиг.
На практике это дает несколько преимуществ
- Меньше неопределенность - агент хуже всего работает там, где человек сам не решил, чего хочет
- Большие задачи проще делегировать - их можно резать на независимые кусочки и проверять по частям
- Появляется трассировка между намерением, дизайном решения, задачами и тестами
- Review перестает быть только чтением diff'а - он становится проверкой: “достигли ли мы цели, которую сами же сформулировали?”
Правда, не все так безоблачно - spec-driven development (SDD) сам по себе не гарантирует качество. Пeлохая спецификация просто быстрее производит неправильный код.
#Engineering #AI #Software #Architecture #Management #DevTools #Agents #ML #SystemDesign
1❤13👍6🔥5
AI Dev Podcast #2: Александр Поломодов, Сергей Баранов / Архитектура в эпоху ИИ (Рубрика #Architecture)
Около месяца назад мы записывали подкаст вместе с Сергеем Барановым (основателем ArchDays) и Андреем Дмтриевым (со-основателем JUG.RU) в рамках подготовки к сегодняшней конфе AI Dev Conf. Так получилось, что дальше я уехал в отпуск и забыл поделиться с вами этим эпизодом, а он был интересным:) Речь в нем шла про то, как LLM и мультиагентные системы меняют software architecture и инженерные процессы. Обсудили двойственную природу ИИ: с одной стороны - демократизация разработки (через lovable.dev и аналоги), с другой - жесткая необходимость в инженерном фундаменте для масштабирования.
Основными темами выпуска стали
- От SOE 1.0 к SOE 2.0: как люди и агенты будут работать в связке.
- Роль архитектора: больше не "чертежник", а стратег, валидирующий варианты от ИИ и выстраивающий внутренние модели.
- Экономика: почему типовые решения уходят в автоматизацию, а ценность повторного использования компонентов взлетает до небес.
- Болевые точки: бардак с данными и онтологиями, блокирующие зависимости между сервисами и проблема контекста.
- Прогноз: как готовить платформу к "мажорной разработке" с агентами и почему локальные эксперименты с моделями станут базовым навыком архитектора.
В итоге: агенты научатся писать код, делать ревью и документацию. Но ставить цели, изобретать и управлять контекстом останется за человеком. Тех, кто не адаптируется, ждет разорение. Компании уже поняли, что просто заменить людей ИИ недостаточно - им срочно понадобились специалисты, умеющие с ним работать эффективно.
#AI4SDLC #AI #Engineering #Software #Processes #Management #Productivity
Около месяца назад мы записывали подкаст вместе с Сергеем Барановым (основателем ArchDays) и Андреем Дмтриевым (со-основателем JUG.RU) в рамках подготовки к сегодняшней конфе AI Dev Conf. Так получилось, что дальше я уехал в отпуск и забыл поделиться с вами этим эпизодом, а он был интересным:) Речь в нем шла про то, как LLM и мультиагентные системы меняют software architecture и инженерные процессы. Обсудили двойственную природу ИИ: с одной стороны - демократизация разработки (через lovable.dev и аналоги), с другой - жесткая необходимость в инженерном фундаменте для масштабирования.
Основными темами выпуска стали
- От SOE 1.0 к SOE 2.0: как люди и агенты будут работать в связке.
- Роль архитектора: больше не "чертежник", а стратег, валидирующий варианты от ИИ и выстраивающий внутренние модели.
- Экономика: почему типовые решения уходят в автоматизацию, а ценность повторного использования компонентов взлетает до небес.
- Болевые точки: бардак с данными и онтологиями, блокирующие зависимости между сервисами и проблема контекста.
- Прогноз: как готовить платформу к "мажорной разработке" с агентами и почему локальные эксперименты с моделями станут базовым навыком архитектора.
В итоге: агенты научатся писать код, делать ревью и документацию. Но ставить цели, изобретать и управлять контекстом останется за человеком. Тех, кто не адаптируется, ждет разорение. Компании уже поняли, что просто заменить людей ИИ недостаточно - им срочно понадобились специалисты, умеющие с ним работать эффективно.
#AI4SDLC #AI #Engineering #Software #Processes #Management #Productivity
YouTube
AI Dev Podcast #2: Александр Поломодов, Сергей Баранов / Архитектура в эпоху ИИ
AI Dev Conf Podcast #2: Архитектура в эпоху ИИ — от хаоса к новой инженерной реальности
Гости выпуска: Сергей Баранов (продюсер ArchDays) и Александр Поломодов (технический директор в Т-Банке).
О чем поговорили:
Как LLM и мультиагентные системы меняют софт…
Гости выпуска: Сергей Баранов (продюсер ArchDays) и Александр Поломодов (технический директор в Т-Банке).
О чем поговорили:
Как LLM и мультиагентные системы меняют софт…
🔥7❤6👍4🥱1
No Drama - Color Lama (Рубрика #Brain)
Я давно замечал, что у меня лучше работает голова, если я размышления совмещаю с физическим действием. Именно поэтому я часто провожу one-on-ones, гуляя вокруг нашего офиса. Потом у нас в офисе в каждой переговорке добавили карандаши и листочки раскраски - мне эта идея понравилась и я купил себе набор раскрасок. Я использую их теперь на некоторых онлайн встречах или просто когда надо подумать о чем-то глубоко, а руки требуется занять чем-то. В итоге, получается этакая арт-терапия, которая мне помогает фокусироваться.
К посту прикрепил несколько раскрашенных картинок, что накопились за пару лет, что я практикую эту активность.
#Thinking #Brain #Books
Я давно замечал, что у меня лучше работает голова, если я размышления совмещаю с физическим действием. Именно поэтому я часто провожу one-on-ones, гуляя вокруг нашего офиса. Потом у нас в офисе в каждой переговорке добавили карандаши и листочки раскраски - мне эта идея понравилась и я купил себе набор раскрасок. Я использую их теперь на некоторых онлайн встречах или просто когда надо подумать о чем-то глубоко, а руки требуется занять чем-то. В итоге, получается этакая арт-терапия, которая мне помогает фокусироваться.
К посту прикрепил несколько раскрашенных картинок, что накопились за пару лет, что я практикую эту активность.
#Thinking #Brain #Books
🔥26😁8❤3⚡2
Почему AI делает инфраструктуру управленческой темой (Рубрика #AI)
Пару дней назад вышла статья РБК про то, почему бизнес выбирает гибридную инфраструктуру. В этом интервью РБК от 19 мая генеральный директор Yandex Cloud Григорий Атрепьев говорит, что рынок корпоративного ПО в России по итогам 2025 года вырос до 808 млрд руб., а два главных фактора изменения рынка сейчас - информационная безопасность и искусственный интеллект.
А сегодня я весь день преподаю в рамках программы ВШЭ “ИИ-лидеры: бизнес-лаборатория для руководителей” и рассказываю менеджерам про облака, DataOps, MLOps и AIOps. И эта статья отлично попадает в главный тезис моего рассказа: AI в компании начинается не с красивой демки модели. Он начинается с инфраструктуры, данных, безопасности, эксплуатации и управленческой готовности довести пилот до промышленного внедрения.
Если возвращаться к тезисам Григория из статьи то они примерно такие
1️⃣ Искусственный интеллект и информационная безопасность - это комбо-связка. С одной стороны, компании живут в более агрессивной среде: по словам Yandex Cloud, в прошлом году они обрабатывали 103 млрд событий ежедневно в собственной SIEM-системе, в три раза больше год к году. С другой стороны, AI уже перестал быть только экспериментом: на платформе, по данным компании, создано более 18 тыс. агентов.
2️⃣ Дальше начинается самое интересное для менеджеров. AI быстро превращается в инфраструктурную задачу. Растет спрос на GPU, по исследованию Yandex Cloud и Apple Hills Digital среднегодовой темп роста этого сегмента до 2030 года оценивается в 23%. Меняются требования к ЦОД: если раньше стойка могла потреблять 5-6 кВт, то сейчас для AI-нагрузок речь идет уже о 100 кВт и выше.
3️⃣ На этом фоне гибридная инфраструктура выглядит не как компромисс “между облаком и своим железом”, а как рабочая модель зрелой компании. Публичное облако дает скорость экспериментов, быстрые пилоты и гибкое потребление ресурсов. Частный контур нужен там, где есть чувствительные данные, регуляторные ограничения, требования ИБ и уже сложившиеся корпоративные системы.
4️⃣ Но гибридность не достается бесплатно. В статье хорошо перечислены барьеры: разные инструменты и навыки, Kubernetes, API, мониторинг, синхронизация, резервное копирование, безопасность. А с AI добавляется новый слой: нужно контролировать агентов в корпоративных системах, разграничивать доступ к данным, защищать протоколы и наблюдать цепочки действий. Observability становится не только темой SRE, но и темой управления AI-рисками.
В общем, управленческий вывод такой: AI-проекты чаще ломаются не на выборе или доступе к вашей любимой модели. Они начинаю буксовать на качестве данных, доступности инфраструктуры, отсутствии сильного бизнес-спонсора, непонятной модели ответственности и неспособности превратить пилот в повторяемый процесс. Поэтому менеджерам важно понимать не только "какую нейросеть купить". Важно понимать, какой контур данных, облаков, MLOps/AIOps, ИБ, мониторинга и эксплуатации нужен, чтобы AI не остался презентацией на несколько сотрудников, а стал частью корпоративной системы.
#AI #Cloud #DataOps #MLOps #AIOps #Management #Engineering
Пару дней назад вышла статья РБК про то, почему бизнес выбирает гибридную инфраструктуру. В этом интервью РБК от 19 мая генеральный директор Yandex Cloud Григорий Атрепьев говорит, что рынок корпоративного ПО в России по итогам 2025 года вырос до 808 млрд руб., а два главных фактора изменения рынка сейчас - информационная безопасность и искусственный интеллект.
А сегодня я весь день преподаю в рамках программы ВШЭ “ИИ-лидеры: бизнес-лаборатория для руководителей” и рассказываю менеджерам про облака, DataOps, MLOps и AIOps. И эта статья отлично попадает в главный тезис моего рассказа: AI в компании начинается не с красивой демки модели. Он начинается с инфраструктуры, данных, безопасности, эксплуатации и управленческой готовности довести пилот до промышленного внедрения.
Если возвращаться к тезисам Григория из статьи то они примерно такие
1️⃣ Искусственный интеллект и информационная безопасность - это комбо-связка. С одной стороны, компании живут в более агрессивной среде: по словам Yandex Cloud, в прошлом году они обрабатывали 103 млрд событий ежедневно в собственной SIEM-системе, в три раза больше год к году. С другой стороны, AI уже перестал быть только экспериментом: на платформе, по данным компании, создано более 18 тыс. агентов.
2️⃣ Дальше начинается самое интересное для менеджеров. AI быстро превращается в инфраструктурную задачу. Растет спрос на GPU, по исследованию Yandex Cloud и Apple Hills Digital среднегодовой темп роста этого сегмента до 2030 года оценивается в 23%. Меняются требования к ЦОД: если раньше стойка могла потреблять 5-6 кВт, то сейчас для AI-нагрузок речь идет уже о 100 кВт и выше.
3️⃣ На этом фоне гибридная инфраструктура выглядит не как компромисс “между облаком и своим железом”, а как рабочая модель зрелой компании. Публичное облако дает скорость экспериментов, быстрые пилоты и гибкое потребление ресурсов. Частный контур нужен там, где есть чувствительные данные, регуляторные ограничения, требования ИБ и уже сложившиеся корпоративные системы.
4️⃣ Но гибридность не достается бесплатно. В статье хорошо перечислены барьеры: разные инструменты и навыки, Kubernetes, API, мониторинг, синхронизация, резервное копирование, безопасность. А с AI добавляется новый слой: нужно контролировать агентов в корпоративных системах, разграничивать доступ к данным, защищать протоколы и наблюдать цепочки действий. Observability становится не только темой SRE, но и темой управления AI-рисками.
В общем, управленческий вывод такой: AI-проекты чаще ломаются не на выборе или доступе к вашей любимой модели. Они начинаю буксовать на качестве данных, доступности инфраструктуры, отсутствии сильного бизнес-спонсора, непонятной модели ответственности и неспособности превратить пилот в повторяемый процесс. Поэтому менеджерам важно понимать не только "какую нейросеть купить". Важно понимать, какой контур данных, облаков, MLOps/AIOps, ИБ, мониторинга и эксплуатации нужен, чтобы AI не остался презентацией на несколько сотрудников, а стал частью корпоративной системы.
#AI #Cloud #DataOps #MLOps #AIOps #Management #Engineering
👍7❤3🔥2🥱1
Atomic Heart. Предыстория «Предприятия 3826»: как строилась советская техноутопия до сбоя (Рубрика #SciFi)
Продолжая свое погружение в мир Atomic Heart, прочитал специальное издание "Atomic Heart. Предыстория «Предприятия 3826»" Харальда Хорфа, которая отличается цветными вставками и более плотной и белой бумагой от обычного издания. Про саму игру я уже рассказывал отдельно: для меня Atomic Heart оказался не просто шутером про роботов, а погружением в советскую техноутопию, где автономные системы, централизованное управление и вера в автоматизацию в какой-то момент начинают вести себя как большая распределенная система со сбойнувшим контуром управления (control plane). Также чуть раньше этого я разбирал сборник "Atomic Heart: Далёкое светлое будущее", который показывает мир до старта игры: витрины утопии, бытовых роботов, ощущение прогресса и тот самый момент, когда ты читаешь почти лог системы прямо перед тем, как все пошло по наклонной.
Но новая книга показалась мне еще интереснее - она расскрывает всю историю от открытия полимера Сеченовым до научного рывка, роботизации, инфраструктуры Предприятия 3826 и движения к "Коллективу 2.0". Это крепкая научная фантастика, а не просто справочник с описанием основых персонажей - здесь раскрывается история о том, как большая технологическая мечта постепенно становится системой. Книга добавляет к игре не столько факты, сколько логичную историю с набором причин и следствий, в конце которых мы понимаем как мы оказались на месте майора Нечаева и понимаем кто и как сгенерировал этот сбой. Но это же означает, что книга содержит спойлеры, а значит ее стоит читать уже после прохождения игры. В игре мы уже видим последствия сбоя: агрессивных роботов, закрытые комплексы, поломанный контур управления и странное ощущение, что красивые лозунги будущего обернулись инфраструктурной катастрофой. А здесь видишь, почему люди вообще могли поверить в такую систему. Почему она выглядела не опасной, а логичной, прогрессивной и почти неизбежной.
Это, кстати, хорошо дополняет мои предыдущие мысли про Atomic Heart. Большая автономная система опасна не потому, что роботы внезапно “злые”. Она опасна, когда масштаб, централизация, доступы, цели, governance и границы ответственности становятся частью архитектуры, но к ним относятся как к второстепенным деталям. В мире Atomic Heart это выглядит красиво: наука, заводы, полимер, роботы, коллективное будущее. Но инженерно ты все время видишь вопрос: а где план Б, observability, kill switch и независимый контур контроля?
Мне кажется, что как отдельная фантастическая книга эта предыстория зайдет не всем, но она понравится тем, кому уже интересен Atomic Heart или кто хотя бы примерно понимает мир игры. Она делает мир плотнее и понятнее. После нее Предприятие 3826 воспринимается не просто как декорация для шутера, а как большой технологический проект со своей логикой, идеологией и архитектурной ценой. В общем, если вам нравится Atomic Heart, советская техноутопия, автономные роботы и истории о том, как “идеальное будущее” постепенно превращается в систему с огромным радиусом сбоя, книгу можно смело брать.
#SciFi #Games #AtomicHeart #AI #Robotics #Architecture #SystemDesign
Продолжая свое погружение в мир Atomic Heart, прочитал специальное издание "Atomic Heart. Предыстория «Предприятия 3826»" Харальда Хорфа, которая отличается цветными вставками и более плотной и белой бумагой от обычного издания. Про саму игру я уже рассказывал отдельно: для меня Atomic Heart оказался не просто шутером про роботов, а погружением в советскую техноутопию, где автономные системы, централизованное управление и вера в автоматизацию в какой-то момент начинают вести себя как большая распределенная система со сбойнувшим контуром управления (control plane). Также чуть раньше этого я разбирал сборник "Atomic Heart: Далёкое светлое будущее", который показывает мир до старта игры: витрины утопии, бытовых роботов, ощущение прогресса и тот самый момент, когда ты читаешь почти лог системы прямо перед тем, как все пошло по наклонной.
Но новая книга показалась мне еще интереснее - она расскрывает всю историю от открытия полимера Сеченовым до научного рывка, роботизации, инфраструктуры Предприятия 3826 и движения к "Коллективу 2.0". Это крепкая научная фантастика, а не просто справочник с описанием основых персонажей - здесь раскрывается история о том, как большая технологическая мечта постепенно становится системой. Книга добавляет к игре не столько факты, сколько логичную историю с набором причин и следствий, в конце которых мы понимаем как мы оказались на месте майора Нечаева и понимаем кто и как сгенерировал этот сбой. Но это же означает, что книга содержит спойлеры, а значит ее стоит читать уже после прохождения игры. В игре мы уже видим последствия сбоя: агрессивных роботов, закрытые комплексы, поломанный контур управления и странное ощущение, что красивые лозунги будущего обернулись инфраструктурной катастрофой. А здесь видишь, почему люди вообще могли поверить в такую систему. Почему она выглядела не опасной, а логичной, прогрессивной и почти неизбежной.
Это, кстати, хорошо дополняет мои предыдущие мысли про Atomic Heart. Большая автономная система опасна не потому, что роботы внезапно “злые”. Она опасна, когда масштаб, централизация, доступы, цели, governance и границы ответственности становятся частью архитектуры, но к ним относятся как к второстепенным деталям. В мире Atomic Heart это выглядит красиво: наука, заводы, полимер, роботы, коллективное будущее. Но инженерно ты все время видишь вопрос: а где план Б, observability, kill switch и независимый контур контроля?
Мне кажется, что как отдельная фантастическая книга эта предыстория зайдет не всем, но она понравится тем, кому уже интересен Atomic Heart или кто хотя бы примерно понимает мир игры. Она делает мир плотнее и понятнее. После нее Предприятие 3826 воспринимается не просто как декорация для шутера, а как большой технологический проект со своей логикой, идеологией и архитектурной ценой. В общем, если вам нравится Atomic Heart, советская техноутопия, автономные роботы и истории о том, как “идеальное будущее” постепенно превращается в систему с огромным радиусом сбоя, книгу можно смело брать.
#SciFi #Games #AtomicHeart #AI #Robotics #Architecture #SystemDesign
❤10👍7🔥6🗿1