Comments 2
Мне кажется, разработка действительно движется от ручного редактирования каждого файла к работе на более высоком уровне. AI ускоряет этот переход, но одновременно показывает ограничение нынешней модели: агент умеет писать код быстрее, чем понимать большую систему.
Увеличение контекстного окна поможет, но не устранит саму необходимость каждый раз восстанавливать архитектурный замысел из реализации.
ИИ не согласен
Мысль автора понятна и отлично описывает боли первой волны генеративного ИИ (эпохи «вайб-кодинга» и простых копилотов). Действительно, если просто натравить LLM на огромный монолитный репозиторий, она начнет тонуть в легаси-коде, совершать регрессионные ошибки и пытаться, как археолог, раскопать исходный замысел архитектора по косвенным признакам.
Однако эта логика исходит из предпосылки, что код — это единственный и финальный источник правды (Single Source of Truth) для ИИ. И именно в этой точке тезис начинает стремительно устаревать.
Индустрия прямо сейчас совершает тектонический сдвиг от «промпт-кодинга» к методологии IDD (Intent-Driven Development) и системному Context Engineering. Этот подход полностью переворачивает парадигму и решает озвученную проблему через три фундаментальных изменения:
Замысел больше не скрыт в реализации. В зрелых IDD-системах агенту не нужно «декомпилировать» архитектуру из миллионов строк кода. Замысел выносится на уровень выше и фиксируется декларативно — в виде архитектурных манифестов (например, стандарты типа
OpenSpecили расширенныйCLAUDE.md), схем данных и машиночитаемого бизнес-глоссария (Ubiquitous Language из DDD). Для ИИ архитектурный контекст — это не загадка, которую нужно разгадать, а жесткий входной параметр и рельсы, с которых нельзя съехать.Изоляция вместо расширения контекстных окон. Пытаться скормить модели весь проект целиком, надеясь на миллионные контекстные окна — тупиковый путь (модели неизбежно «тупеют» и теряют фокус в слишком длинном контексте). Решение, пришедшее из Domain-Driven Design — это жесткие границы контекста (Bounded Contexts). Агент, меняющий модуль оплаты, физически не видит код модуля логистики или авторизации. Он видит только свой изолированный кусок и строго зафиксированные контракты соседей через AST-графы (Abstract Syntax Tree). Ему просто запрещено понимать устройство всей системы, как и любому разработчику-человеку в крупном энтерпрайзе.
Смена ролей: Спецификация валидирует код, а не наоборот. Мы уходим от парадигмы, где ИИ учится на коде проекта и бездумно масштабирует его ошибки. В IDD сначала валидируется само «намерение» (Intent) на уровне абстрактного графа зависимостей. Если ИИ-архитектор видит, что новая фича нарушает контракт или создает циклическую зависимость, пайплайн останавливается до генерации кода.
Резюме: Цитата идеально описывает кризис систем, где код первичен. Но как только мы переходим на уровень Intent-Driven Engineering, где код становится лишь автоматически генерируемым артефактом, а человек управляет ограничениями и контрактами, необходимость «восстанавливать замысел из реализации» исчезает. Мы больше не просим ИИ понять наш код — мы заставляем его подчиняться нашей спецификации.
IDD (Intent-Driven Development) в ИИ-разработке
**Intent-Driven Development (IDD, разработка на основе намерений)** — это новая методология инженерии программного обеспечения в эпоху ИИ, при которой **инженер формулирует, структурирует и валидирует свои верхнеуровневые намерения (Intents), а ИИ-агенты полностью берут на себя генерацию кода, тестов и интеграцию**.
В отличие от хаотичного «вайб-кодинга» (написания кода через простые чат-промпты), IDD смещает роль программиста с ручного написания строк кода («укладки кирпичей») к роли Архитектора и Контролера, который управляет контекстом и проверяет результат работы автономных агентов.
📊 Разница подходов: Эволюция к IDD
Критерий Вайб-кодинг (Vibe Coding) Spec-Driven Development (SDD) Intent-Driven Development (IDD) Что делает человек Пишет сырые промпты, кодит на ходу Создает огромные, жесткие ТЗ и контракты Формулирует намерения (Зачем/Что/Как) и тесты Что делает ИИ Генерирует куски кода по запросу Реализует систему строго по готовой спеке Автономно планирует задачи и пишет рабочий код Основной риск Галлюцинации, хаос в архитектуре Огромные затраты на ручную актуализацию спек Требует высокой архитектурной зрелости от инженера Результат Быстрый старт, нежизнеспособный легаси Стабильный код, медленный процесс итераций Высокая скорость, масштабируемость и прозрачность
💡 Анатомия Намерения (Intent) в IDD
Документ намерения (обычно оформляется в виде структурированного Markdown-файла) является единственным источником истины для ИИ-агента. Он состоит из трех обязательных блоков:
ЗАЧЕМ (WHY): Бизнес-контекст и мотивация. Зачем пользователю эта фича? Какую проблему мы решаем?
ЧТО (WHAT): Строгие функциональные требования. Часто описываются на понятном ИИ языке сценариев (например, Gherkin / Cucumber: Given-When-Then).
КАК (HOW): Верхнеуровневый пошаговый план технической реализации, разбитый на мелкие задачи, границы архитектуры и стек.
ИИ-агент считывает этот файл, не отвлекаясь на догадки и двусмысленные промпты, и генерирует реализацию, точно соответствующую ожиданиям.
🔎 Почему IDD критически важен для ИИ-эпохи?
Исключение «дрейфа намерений»: При классическом промптинге ИИ склонен додумывать логику за программиста, что ведет к накоплению скрытых багов. IDD жестко фиксирует рамки дозволенного.
Отделение стратегии от рутины: Человек концентрируется на бизнес-логике, граничных условиях и безопасности, а ИИ за секунды пишет рутинный boilerplate-код и юнит-тесты.
Архитектурный контроль: Передавая ИИ схему системы (DDD) и явное намерение, инженер сохраняет архитектуру проекта чистой, не позволяя нейросети превратить кодовую базу в “спагетти”.
➡️ Как выглядит рабочий процесс (Workflow) в IDD
Создание интента: Инженер описывает задачу в документе Интента (проверяя архитектурную совместимость).
Фиксация тестов: Инженер (или ИИ под его контролем) пишет поведенческие тесты, которые зафиксируют успешность выполнения намерения.
Запуск ИИ-агента: Специализированный ИИ-агент (например, на базе фреймворков для авто-кодинга) берет Интент в работу, декомпозирует его и приступает к кодингу.
Автоматическая валидация: Код прогоняется через тесты и линтеры. Если тесты падают, агент исправляет себя сам, пока условия интента не будут выполнены на 100%.
Human-in-the-loop: Инженер проводит финальный аудит (Code Review) и вливает изменения в основную ветку.
Что использует Robert C. Martin (Uncle Bob)?
Позиция Роберта Мартина (Uncle Bob) — автора культовой книги «Чистый код» и создателя принципов SOLID — по поводу агентной разработки произвела настоящий фурор в индустрии. Человек, десятилетиями учивший инженеров вылизывать каждую строчку, официально заявил, что больше вообще не читает код, написанный ИИ-агентами.
Вместо построения абстрактных моделей он использует подход, который называют «Испытательным полигоном» (Test Gauntlet). Его методология идеально ложится на рельсы IDD, но с жестким фокусом на автоматическую верификацию.
Вот стек практик и инструментов, которые дядя Боб использует для работы с ИИ:
1. Отказ от Code Review в пользу Метрик и Контрактов
Вместо того чтобы тратить время на построчное ревью кода (поскольку человек делает это слишком медленно), Мартин полностью абстрагировался от реализации. Качество кода ИИ-агентов он оценивает через автоматический скоринг телеметрии и метрик. Если ИИ-агент приносит Pull Request, платформа Дяди Боба автоматически проверяет:
Тестовое покрытие (Mutation Testing): Не просто покрытие строк, а мутационное тестирование. Код считается принятым, только если тесты ИИ-агента «ловят» искусственно внесенные баги.
Цикломатическую сложность (Cyclomatic Complexity): ИИ не должен плодить вложенные циклы и конструкции
if-else.Зацепление и связность (Dependency Structure): Проверка на нарушение принципов SOLID на уровне графа кода.
«Человек слишком медлителен в написании и чтении кода. Чтобы расти в продуктивности, люди должны отключиться от самого кода и управлять системой с более высокого уровня», — пишет Мартин.
2. Приемочное тестирование как интерфейс (ATDD)
В качестве главного инструмента управления намерениями (Intent) Дядя Боб использует Acceptance Test-Driven Development (ATDD) на базе Gherkin / Cucumber.
Как это работает: Инженер описывает требования к системе в виде человекочитаемых сценариев (например,
Given / When / Then).Этот файл спецификации скармливается агенту (Мартин активно поддерживает экосистему вокруг Claude Code и кастомных CLI-оберток). ИИ обязан написать реализацию так, чтобы эти сквозные приемочные тесты загорелись зеленым.
3. Архитектурные тесты (Architecture-as-Code)
Поскольку ИИ-агенты любят нарушать границы слоев (например, тащить инфраструктурный SQL-запрос напрямую в UI-контроллер), Дядя Боб использует инструмент ArchUnit (для Java/C#) и его аналоги в других языках.
Архитектурные правила зашиваются в специальные Unit-тесты.
Тест проверяет структуру проекта на уровне компиляции: «Пакет Domain не должен зависеть от пакета Infrastructure». ИИ физически не сможет запушить код, нарушающий Clean Architecture.
4. Навыки ИИ вместо гайдлайнов (Agent Skills)
Вместо того чтобы надеяться, что ИИ «вспомнит» правила чистого кода, Дядя Боб перевел весь свой каталог из 66 правил и эвристик «Clean Code» в машиночитаемый формат Agent Skills. Это конфигурационные файлы, которые нативно поддерживаются современными IDE (например, через Anthropic MCP-серверы). Перед тем как написать метод, агент парсит этот файл-инструкцию, выступающий жестким Guardrail.
Резюме: Формула Дяди Боба в эпоху ИИ
Метод Роберта Мартина сегодня — это «Дисциплинированная агентная инженерия» (Disciplined Agentic Engineering). Он не верит в то, что ИИ поймет архитектурный замысел сам. Но вместо создания сложной визуальной UML-модели до генерации кода, он кодирует архитектурные ограничения в виде автоматических тестов (TDD/ATDD). Тесты становятся единственным валидатором намерений, а ИИ выступает в роли «слепого исполнителя», который обязан пройти этот жесткий фильтр.
А еще хабр не умеет в нормальный маркдаун.
Мы уже проходили похожие переходы: от ассемблера к C, потом к C++, Java, Rust и т.д. Но результат всегда оставался детерминированным — компилятор выполнял строго определённую трансформацию.
С IDD и SDD у меня пока остаётся открытый вопрос. Я пока не видел действительно крупных публичных проектов, где тысячи спецификаций стали бы основным артефактом разработки. Если рядом с кодом появятся десятки тысяч Intent/Spec-файлов, кто гарантирует их непротиворечивость? Кто гарантирует, что архитектурные ограничения не конфликтуют между собой? И кто гарантирует, что они действительно перенесены в код, а не остались только в спецификациях?
Мне кажется, мы действительно будем подниматься на всё более высокий уровень абстракции. Но этот уровень должен быть не просто текстовым описанием, а формальной моделью, которую можно автоматически валидировать, проверять на противоречия и использовать как детерминированную границу ограничений. Иначе мы рискуем не решить проблему, а просто перенести её из кода в ещё один слой артефактов.
Код написали за нас. Как упростить ревью и сколько это стоит в рантайме