Соло-разработчик создал полноценный Electron-продукт за 56 дней. Без команды. Без менеджера. Только два ИИ-агента: Claude Code для генерации кода и Codex для независимого ревью. Результат сопоставим с работой группы из 3-4 человек, а затраты на подписки уложились в 5-10% от зарплаты одного senior-разработчика. Этот кейс меняет представление о том, как устроена современная разработка.
Секрет не в моделях. Модели доступны всем. Секрет в харнессе - системе гейтов, правил и контрактов, которая превращает хаотичную генерацию кода в предсказуемый конвейер. Харнесс фиксирует, что именно должен сделать агент, проверяет результат и блокирует проход дефектов дальше по пайплайну. Без него два агента просто генерировали бы код, который невозможно поддерживать.
Автор кейса отказался от готовых SDD-фреймворков. Вместо них собрал собственную обвязку из трёх простых правил, которые работают в любом проекте. Разберём устройство харнесса, экономику подписок и грабли, которые ждут тех, кто попробует повторить этот подход.
56 дней до продукта: как соло-разработчик заменил команду двумя ИИ-агентами
Исходные условия: один разработчик, задача - создать десктопное приложение на Electron с пользовательским интерфейсом, бизнес-логикой и интеграциями. Никакой команды, никакого продакт-менеджера, никакого QA-инженера. Только Claude Code, Codex и 56 календарных дней.
Результат: работающий продукт, прошедший через несколько итераций ревью и автоматических проверок. Кодовая база структурирована, тесты написаны, интерфейс соответствует спецификации. Время, которое обычно тратится на коммуникацию внутри команды, ушло на формализацию требований и настройку харнесса.
Этот подход радикально отличается от «попросил модель написать код и скопировал в проект». Здесь выстроен полноценный конвейер, где каждый этап имеет чёткие критерии приёмки. Подробнее о том, как структурная инженерия заменяет убеждение моделей промптами на систему правил, мы разбирали в статье о корпоративном харнессе для агентного SDLC на слабых LLM.
Роли агентов: Claude Code пишет, Codex проверяет
Разделение обязанностей - фундамент харнесса. Claude Code получает спек-контракт и генерирует код. Codex получает тот же спек-контракт и сгенерированный код, но не видит историю генерации, промпты и промежуточные артефакты. Его задача - найти расхождения между контрактом и реализацией.
Пример взаимодействия: Claude Code создаёт компонент интерфейса по спецификации из 15 пунктов. Codex проверяет каждый пункт и находит, что обработка ошибки сетевого запроса описана в контракте, но в коде отсутствует. Агент-писатель получает отчёт о несоответствии и исправляет код. Цикл повторяется до тех пор, пока Codex не подтвердит полное соответствие.
Почему это работает: модель, которая генерирует код, склонна «верить» в свою правоту. Она не видит пропущенных крайних случаев, потому что контекст генерации уже содержит допущения, которые модель приняла за истину. Независимый ревьюер с чистым контекстом лишён этой предвзятости. Он сравнивает два артефакта - контракт и код - без знания о том, как код появился.
Этот же принцип изоляции контекста лежит в основе архитектуры личных ИИ-агентов, которые работают за пределами IDE. Мы разбирали этот переход в статье о личных ИИ-агентах как новом шаге после Claude Code и Codex.
Харнесс: система гейтов и правил для управляемой генерации кода
Проблема неконтролируемой генерации кода известна каждому, кто пробовал использовать LLM в продакшене. Модель выдаёт рабочий, но архитектурно несогласованный код. Или код, который проходит тесты, но не соответствует спецификации. Или код, который работает сейчас, но развалится при следующем изменении.
Харнесс решает эту проблему через систему обязательных этапов. Код не попадает в основную ветку, пока не пройдёт все гейты. Это аналог CI/CD-пайплайна, но заточенный под особенности генеративного кода: проверки учитывают типичные ошибки моделей - галлюцинации, пропуск крайних случаев, несогласованность интерфейсов.
Ключевое отличие от классического CI/CD: харнесс контролирует не только синтаксис и тесты, но и семантическое соответствие контракту. Линтер не найдёт пропущенную обработку ошибки. Codex найдёт.
Спек-контракты: почему спецификация оказалась дороже кода
Спек-контракт - это формализованное описание того, что должен делать компонент. Не как он устроен внутри, а какое поведение демонстрирует снаружи: входные данные, выходные данные, инварианты, обработка ошибок, граничные условия.
Автор кейса обнаружил закономерность: время, потраченное на написание спек-контракта, кратно сокращает время на исправление ошибок после генерации. Компонент интерфейса без контракта требовал 4-5 итераций ревью и ручных правок. Тот же компонент с детальным контрактом из 20 пунктов проходил ревью Codex с первого раза в 80% случаев.
Пример контракта для компонента интерфейса:
- Принимает массив объектов с полями id, title, status
- Отображает список с фильтрацией по статусу
- При пустом массиве показывает сообщение «Нет данных»
- При ошибке загрузки показывает сообщение об ошибке с кнопкой повтора
- Фильтр сохраняет состояние между перезагрузками страницы
- Клик по элементу вызывает callback с id элемента
Формализация занимает 15-20 минут. Исправление сгенерированного кода без контракта - час и больше. Разница в инвестициях очевидна: спецификация окупается на первой же итерации.
Спек-контракты также решают проблему накопления технического долга. Когда каждый компонент имеет формальную спецификацию, рефакторинг превращается из гадания в механическую проверку соответствия. Меняете реализацию - прогоняете контракт через Codex - получаете вердикт: соответствует или нет.
Чистый контекст ревью: как избежать самообмана моделей
Самообман моделей - это ситуация, когда LLM «верит» в сгенерированный код и не видит в нём ошибок. Механизм прост: модель породила код на основе определённых допущений. Эти же допущения остались в контексте. При повторном просмотре модель подтверждает свои же допущения, а не проверяет код.
Решение: Codex получает только два артефакта - спек-контракт и финальный код. Никакой истории генерации. Никаких промптов. Никаких промежуточных версий. Чистый вход, чистый анализ.
Реальный пример из кейса: Claude Code сгенерировал модуль аутентификации. Модуль работал, тесты проходили. Codex при ревью с чистым контекстом обнаружил, что токен обновления сохраняется в localStorage без шифрования - это противоречило пункту контракта о безопасном хранении чувствительных данных. Агент-писатель не заметил этого, потому что в контексте генерации уже было допущение «используем localStorage для хранения состояния».
Чистый контекст ревью - это не техническая оптимизация. Это архитектурный принцип, который превращает ревью из формальности в реальный барьер для дефектов. Без него харнесс теряет смысл: два агента будут просто соглашаться друг с другом.
Гейты качества: автоматические проверки перед мержем
Гейты выстроены в жёсткую последовательность. Код не проходит дальше, пока не пройден текущий этап:
- Линтинг и форматирование. Автоматическая проверка синтаксиса и стиля. Модели иногда генерируют код с мелкими синтаксическими ошибками или неконсистентным форматированием. Этот гейт отсекает такие дефекты за секунды.
- Юнит-тесты. Прогон тестов, которые либо написаны в спек-контракте, либо сгенерированы самим Claude Code по контракту. Тесты должны проходить все, без исключений.
- Проверка соответствия контракту. Codex получает спек-контракт и код, возвращает вердикт по каждому пункту контракта: «соответствует», «не соответствует», «не проверяемо автоматически». Пункты с несоответствием возвращаются агенту-писателю.
- Интеграционное ревью. Codex проверяет, что новый код не ломает существующие интерфейсы. Для этого он получает контракты соседних модулей и проверяет совместимость.
Только после прохождения всех четырёх гейтов код попадает в основную ветку. Процесс занимает от 5 до 30 минут в зависимости от объёма изменений. Ручное ревью человеком остаётся только для стратегических решений - архитектурных изменений и принятия компромиссов, которые не описаны в контрактах.
Архитектурные решения для обвязки кодинг-агентов - тема, которую мы детально разобрали в статье о пяти харнессах и выводах для 2026 года. Эксперимент показал: смена обвязки влияет на результат в 7.8 раза сильнее, чем смена модели.
Экономика подписок: 5-10% стоимости сеньора за полноценную разработку
Цифры по состоянию на август 2026 года. Подписка на Claude Code: $20-30 в месяц в зависимости от тарифа. Подписка на Codex: $10-20 в месяц. Суммарно: $30-50 в месяц на двух агентов.
Медианная зарплата senior-разработчика на русскоязычном рынке: $4000-6000 в месяц. Стоимость подписок составляет 0.5-1.25% от этой суммы. Добавим затраты на инфраструктуру: сервер для CI/CD, хранилище артефактов, мониторинг. Ещё $50-100 в месяц. Итоговая стоимость инфраструктуры и подписок: $80-150 в месяц, или 1.3-3.75% от зарплаты сеньора.
Автор кейса оценивает свои затраты в 5-10% от стоимости сеньора с учётом времени на настройку харнесса и написание спек-контрактов. Это не «бесплатная разработка». Это разработка с радикально другой структурой затрат: вместо зарплат - подписки, вместо коммуникации - формализация, вместо ручного ревью - автоматические гейты.
Важный нюанс: эти цифры справедливы для проектов, где разработчик уже умеет писать спек-контракты и настраивать харнесс. Входной порог существует. Первый проект потребует инвестиций в обучение и настройку инфраструктуры. Но эти инвестиции окупаются на втором-третьем проекте, когда харнесс становится переиспользуемым активом.
Почему автор отказался от готовых SDD-фреймворков в пользу собственной обвязки
Spec-Driven Development (SDD) как методология существует несколько лет. На рынке есть инструменты, которые обещают превратить спецификации в код: от генераторов API по OpenAPI-спеке до фреймворков, которые интегрируются с LLM. Автор кейса протестировал несколько готовых решений и отказался от них.
Причины:
- Жёсткость формата. Готовые фреймворки диктуют структуру спецификации. Если проект не укладывается в эту структуру, начинается борьба с инструментом. Собственная обвязка позволяет адаптировать формат контрактов под конкретный проект.
- Привязка к вендору. Коммерческие SDD-решения завязаны на конкретные модели или облачных провайдеров. Смена модели или переход на self-hosted решение ломает весь пайплайн. Собственная обвязка работает с любой моделью через API.
- Сложность отладки. Когда готовый фреймворк генерирует некорректный код, разработчик оказывается между двух огней: баг в модели или баг в фреймворке? Собственная обвязка прозрачна на каждом этапе - видно, какой промпт ушёл, какой ответ вернулся, на каком гейте произошла остановка.
- Избыточность. Готовые решения включают функции, которые не нужны конкретному проекту, но потребляют ресурсы и усложняют конфигурацию. Собственная обвязка содержит ровно то, что нужно.
Собственная обвязка автора - это набор скриптов и конфигурационных файлов, которые оркеструют работу агентов и гейтов. Никакого сложного фреймворка. Никакого вендор-лока. Только то, что реально работает в его контексте.
Три простых правила, которые можно забрать в любой проект
Автор кейса сформулировал три правила, которые не зависят от стека, модели или предметной области:
Правило 1: всегда пиши спек-контракт перед генерацией. Формализуй, что должен делать код, до того, как попросишь модель его написать. Контракт может быть коротким - 5-10 пунктов для простого компонента. Главное - он должен быть проверяемым. Каждый пункт должен допускать однозначный ответ «да/нет» при ревью. Внедрение: создай шаблон контракта в проекте и добавь проверку наличия контракта в первый гейт харнесса. Нет контракта - код не генерируется.
Правило 2: разделяй агентов на писателя и ревьюера. Одна модель генерирует, другая проверяет. Ревьюер получает только контракт и код, без истории генерации. Внедрение: настрой два разных API-ключа или два разных проекта в рамках одного сервиса. Разнеси контексты физически - разные сессии, разные системные промпты, разные истории сообщений.
Правило 3: автоматизируй гейты качества. Код не должен попадать в основную ветку без прохождения автоматических проверок. Линтинг, тесты, ревью контракта - всё это должно выполняться автоматически при каждом push. Внедрение: настрой pre-commit хуки или CI/CD-пайплайн, который блокирует мерж до прохождения всех гейтов. Начни с одного гейта - линтинга - и добавляй новые по мере готовности.
Эти три правила не требуют специальных инструментов. Они работают с любым LLM-сервисом и любой системой контроля версий. Разница между «попросил модель написать код» и «выстроил харнесс» начинается именно с них.
Грабли и ограничения: что осталось за кадром успешного кейса
Кейс выглядит впечатляюще, но за кадром остались проблемы, которые важно учитывать:
Не все задачи решаются с первого раза. Сложные алгоритмы, нетривиальная бизнес-логика, интеграция с плохо документированными API - в этих случаях агентам требуется 3-5 итераций. Спек-контракт помогает, но не гарантирует успеха с первой попытки. Разработчик должен быть готов к циклам «генерация - ревью - исправление».
Спек-контракты требуют ручной доработки. Модель может помочь написать черновик контракта, но финальная формализация остаётся за человеком. Упущенный пункт в контракте означает упущенную функцию в коде. Качество контракта прямо пропорционально качеству результата.
Отладка сгенерированного кода сложнее. Когда разработчик пишет код сам, он понимает каждую строку. Когда код генерирует агент, понимание требует дополнительных усилий. Приходится разбираться в чужой логике, которая может быть неоптимальной или неочевидной. Это плата за скорость генерации.
Подход не работает с legacy-кодом. Высокая связанность компонентов, отсутствие формальных спецификаций, неявные зависимости - в таких условиях харнесс теряет эффективность. Агенты генерируют код, который конфликтует с существующей архитектурой, а контракты не могут описать все неявные ограничения.
Жёсткие требования к безопасности. Если проект требует сертификации или аудита безопасности, автоматические проверки не заменят ручной анализ. Харнесс может отсечь явные проблемы - хранение токенов в открытом виде, отсутствие валидации ввода - но не гарантирует отсутствие уязвимостей.
Важно разделять: харнесс не делает разработку полностью автоматической. Он меняет роль разработчика. Вместо написания кода - формализация требований и настройка конвейера. Вместо ручного ревью - анализ отчётов агентов и принятие архитектурных решений. Это сдвиг, который мы детально разобрали в статье о кодинг-агентах как когнитивной ловушке: скорость генерации кода перестаёт быть узким местом, узким местом становится способность разработчика управлять потоком сгенерированного кода.
Харнесс для ИИ-разработки - это не серебряная пуля. Это инженерная дисциплина, которая требует инвестиций в формализацию и автоматизацию. Но для тех, кто готов эти инвестиции сделать, экономика говорит сама за себя: 5-10% стоимости сеньора за результат, сопоставимый с работой целой команды.