(Не) качесвенный код агента — 15 июля 2026 г. в 07:15:02.000
(Не) качесвенный код агента Сегодня большинство в индустрии признаёт нежизнеспособность вайб-кодинга в Enterprise. Для прототипов — да, но для серьёзной разработки — точно нет. Тут практически консенсус. Но при этом идея сильно не погружаться в код никуда не исчезла. Признавайтесь, кто из вас устал от скорости, с которой меняются тренды вокруг? Поднимаю руку первым! За последние пару недель я прочёл о процессе AI-разработки столько, что мозг уже кипит. Но это так интересно, что остановиться порой невозможно. Мейнстрим сегодня — SDD, или Specification-Driven Development. Пишешь спецификацию о работе функционала. Получаешь одновременно и актуальное описание системы, и постановку на разработку для AI-агента. Запускаешь его в специальном окружении (harness) и получаешь результат. Концептуально — просто и логично. Также все сходятся во мнении, что код должен быть качественным. А вот дальше начинается самое интересное. Каждый вкладывает свой смысл в «качество кода» Нейтральная точка зрения такова: качественный код — соответствует спецификации. Формулировка обтекаемая, но с ней не поспоришь. При этом итоговый результат будет сильно зависеть от того, что именно положили в спеку. И вот об этом как раз две другие точки зрения — более конкретные и интересные. Первая предлагает не смотреть в код вообще. Суть такова: задаём бизнесовые и технические инварианты в спеке, а потом валидируем их через evals в цикле разработки методом чёрного ящика. Мотивация: Код живёт 2–3 коммита, потом переписывается агентом, поэтому неважно, как именно он написан. Паттерны типа SOLID были нужны людям, чтобы понимать код, который был единственным источником правды. Теперь есть спецификация, которая решает эту задачу, поэтому чистый код больше не актуален. Другие утверждают обратное. Кроме бизнесовых и технических инвариантов, важно явно указывать архитектурные ограничения на уровне кода до старта разработки. А после контролировать их выполнение gate-ами прямо в агентском цикле. Мотивация: Без явных ограничений агенты склонны к созданию монолитных архитектур. Они оптимизируют код под функциональную корректность, а не под архитектурные атрибуты качества. В результате — техдолг растёт по экспоненте, а человек уже не сможет помочь, если агент зайдёт в тупик. Почему важно решить, на чьей вы стороне При переходе к SDD мы не должны использовать агентов типа Claude Code / Open Code без инженерной обвязки (harness). Потому что именно он, а не модель, в итоге определяет качество результата. Не верите — посмотрите статью о том, что поведение Claude Code на 98,4% — это детерминированная инфраструктура, и только 1,6% приходится на логику принятия решений ИИ. В итоге именно те идеи, которые будут заложены в harness на этапе его проектирования, будут определять качество продукта, который создаст агент по спеке. Я считаю, что в основе эффективных решений в IT лежит умение декомпозировать задачи и делать сложное простым. А опыт взаимодействия с LLM показывает, что наилучший результат работы модели обеспечивается путём декомпозиции задач и структуризации данных, с которыми она работает. Поэтому для меня выбор очевиден. Бизнесовых и технических инвариантов при постановке задачи разработки AI-агенту недостаточно. Важно явно задавать архитектурные ограничения, а также контролировать цикломатическую сложность прямо внутри цикла разработки. А на какой вы стороне? 🤖 — если доверяете структуру кода агенту. 😃 — если задаете арх.требования к коду. Обо мне | Telegram | MAX