Начало 2026 года прошло под знаком «вайб-кодинга» — разработки программ через диалоги с языковыми моделями в окне чата. Разработчики восторгались возможностью за пару часов собрать прототип, не написав вручную ни строчки кода. Однако по мере развития проектов эйфория сменилась кризисом сопровождения. На дистанции в несколько недель кодовые базы, созданные потоком свободных промптов, превращаются в спагетти-архитектуру: накопление лишних зависимостей, циклические связи и скрытые ошибки приводят к тому, что любое изменение ломает существующие функции.
В ответ на этот тупик сформировалась инженерная парадигма «софтверных фабрик» (Software Factories), предложенная предпринимателем Грегом Айзенбергом и инженером Расом Миком. Ее суть — отказ от восприятия ИИ как творческого собеседника. Вместо попыток уговорить нейросеть написать код разработчик выстраивает детерминированный конвейер, где агенты выступают рабочими на стандартизированных станциях.
Методологическую основу сформулировал экс-технический директор npm Лори Восс: себестоимость генерации кода обнулилась, а 100% добавленной стоимости сосредоточены в формулировании требований, архитектурных ограничениях и проверке качества. Когда модель пишет код мгновенно, узким местом становится не скорость набора текста, а способность человека организовать надежный контроль и исключить деградацию проекта.
Архитектура конвейера: спецификации Markdown вместо монолитных промптов
Главная ошибка начинающих команд при работе с агентами — попытка упаковать в один гигантский системный промпт всю историю проекта, документацию и правила форматирования. В софтверной фабрике этот подход заменен модульной системой из пяти-шести компактных файлов Markdown (включая общесистемный регламент процессов AGENTS.md и каталог навыков SKILLS.md).
Файл AGENTS.md не перегружают фактами о структуре проекта, которые модель считывает из файлов. Он описывает строгий алгоритм процесса, порядок взаимодействия между станциями и критерии перехода задачи на следующий этап.
Эта архитектура нейтральна к используемым моделям. Конвейер спецификаций одинаково работает под управлением рассуждающей модели GPT-6 Astra, терминального агента Claude Code, открытых локальных сетей или платформ оркестрации. Разработчик формализует правила один раз, получая воспроизводимый контур сборки.
Станция 1: Изоляция рабочих процессов через деревья Git Worktree
Когда команда запускает параллельную работу десяти или пятнадцати агентных сессий в одной директории, система сталкивается с техническим тупиком: агенты перезаписывают файлы друг друга, блокируют процессы Git и создают конфликты слияния.
На первой станции фабрики — станции изоляции (Isolate) — эта проблема решается с помощью встроенного механизма рабочих деревьев Git (Git Worktree).
Рабочее дерево Git позволяет создать независимую папку на диске, привязанную к отдельной ветке, но использующую общую базу данных репозитория. При получении задачи навык инициализирует изолированное окружение, ответвляясь от актуального состояния origin/main.
В итоге каждый агент получает суверенное рабочее пространство. На практике это выглядит как десять параллельных терминальных сессий, в каждой из которых агент решает задачу — от исправления верстки до обновления схемы базы данных — не вмешиваясь в соседние процессы и не рискуя стабильностью основной ветки.
Станция 2: Архитектурный контракт и навык структуры кода
Языковые модели стремятся решить задачу кратчайшим путем, что приводит к размещению логики, интерфейса и сетевых вызовов в одном файле. Для прототипа это допустимо, но в продукте делает код непригодным для поддержки.
На станции сборки (Build) агент обязан следовать архитектурному контракту, зафиксированному в навыке структуры кода (Code Structure Skill). Этот файл задает правила:
- Компоненты интерфейса отвечают только за отображение и лишены прямой бизнес-логики;
- Все операции с данными, авторизацией и внешними сервисами выносятся в сервисный слой;
- Структура данных строго валидируется через схемы типов;
- Любой новый модуль снабжается предсказуемыми входными и выходными интерфейсами.
Агент лишается права писать код хаотично. Он конструирует модули так, чтобы полученный сервис оставался понятным для senior-разработчика, аудитора или нового ИИ-агента, который откроет проект спустя месяцы.
Станция 3: Валидация доказательствами (Evidence-Driven Testing)
Традиционная приемка задач от моделей строится на доверии к текстовому ответу бота: разработчик спрашивает о статусе, а модель заверяет, что тесты пройдены. На практике это маскирует скрытые ошибки или сломанный интерфейс.
Станция доказательств (Prove) вводит методику Evidence-Driven Testing (тестирование доказательствами). Текстовые заверения модели запрещены. Агент признает задачу выполненной только при предоставлении объективных артефактов:
- Фиксация исходного состояния: до внесения правок агент запускает браузер через библиотеку автоматизации и записывает видео воспроизведения ошибки или делает снимок экрана;
- Фиксация результата: после сборки кода сценарий повторяется с видеозаписью корректной работы интерфейса;
- Метрики производительности: для оптимизации бэкенда или базы данных агент предоставляет числовые замеры отклика до и после изменений (например, сокращение времени ответа с 815 до 61 миллисекунды);
- Автономный цикл исправления: если видеозапись фиксирует дефект, агент самостоятельно возвращает задачу на станцию сборки.
Видеозаписи, скриншоты и логи прикрепляются к запросу на слияние (Pull Request), формируя наглядное досье выполненной работы.
Станция 4: Конвейерная поставка через Greptile и скоринг pull request
Финальный этап — станция поставки (Ship). После сборки и подтверждения работоспособности агент передает pull request на рецензирование сервису семантического анализа Greptile (альтернативы — CodeRabbit или Macroscope).
Greptile анализирует изменения в контексте всей кодовой базы, оценивая архитектурную согласованность, безопасность и влияние на соседние модули, выставляя оценку по пятибалльной шкале.
Если оценка ниже пяти баллов (например, три из пяти из-за краевого случая), агент считывает замечания и уходит на повторный круг: правит код на станции сборки, обновляет доказательства на станции валидации и запрашивает скоринг. Человек подключается к процессу только при достижении высшего балла: разработчику остается просмотреть видеозапись работы интерфейса и подтвердить слияние ветки.
Сравнительный анализ подходов к разработке
| Параметр | Хаотичный вайб-кодинг | Детерминированная софтверная фабрика |
|---|---|---|
| Инструмент | Диалог в веб-чате | Спецификации Markdown и изолированные агенты |
| Репозиторий | Прямое редактирование рабочей ветки | Изолированные рабочие деревья Git Worktree |
| Архитектура | Смешение логики и интерфейса | Сервисный слой по правилам навыка |
| Критерий приемки | Текстовый ответ «все готово» | Видеозаписи, скриншоты, замеры метрик |
| Контроль качества | Ручное вычитывание сотен строк диффа | Автоматический семантический скоринг PR |
| Параллелизм | 1 задача в фокусе разработчика | 10–15 задач параллельно в фоновых процессах |
Практические правила для инженерных команд
Переход к фабричному конвейеру не требует закупки сложного софта. Достаточно внедрить пять базовых правил организации процессов:
- Изолировать задачи: запретить запуск агентов в основном каталоге проекта, сделав создание Git-ворктри обязательным шагом;
- Зафиксировать стандарты: вынести требования к коду в файл навыка структуры проекта;
- Исключить приемку на веру: настроить запись браузерных сессий (Playwright или Puppeteer) и требовать артефакты ко всем задачам;
- Внедрить автоматический аудит pull request: использовать алгоритмы семантического анализа для предварительной оценки изменений;
- Переосмыслить роль senior-инженера: освободить старших специалистов от рутинного вычитывания строк, превратив их в архитекторов и контролеров конвейера.
Софтверная фабрика переводит применение рассуждающих моделей в категорию предсказуемого производства, позволяя продуктовым командам кратно увеличивать скорость и надежность выпуска цифровых решений.