ИИ в разработке: как я собрал конвейер GoRunWithAI за лето

Серия «Разработка с ИИ: полный цикл», часть 3. Платформа GoRunWithAI.

Это этап, с которого все начинают и на котором большинство застревает: поставили ассистент, код пишется быстрее, а скорость поставки не выросла. Причина проста: локальное ускорение набора кода — это не ускорение разработки. Реальный эффект даёт система: выбор режима под задачу, накопленный контекст проекта и дисциплина проверки. В GoRunWithAI эта система выстроилась за лето — и однажды спасла прод.

Стек проекта и кто его писал

GoRunWithAI: FastAPI + SQLAlchemy 2 (async) + PostgreSQL 16, React + Vite + Tailwind, APScheduler для фоновых задач, Docker Compose, nginx. Десятки модулей: RSS-фетчер, дедупликация, скоринг, LLM-пересказы, очередь кросспостинга, планировщик публикаций, импорт контента, публичное API, дашборд метрик.

Кто писал: агент — основную массу кода, я — рамки, ревью и все решения. Соотношение примерно такое: агент генерирует, человек верифицирует. Это и есть режим «агент» из вводной статьи.

Контекстный стек: главный навык

Качество работы агента определяется не промптом в чате, а средой, которую вы ему построили:

Правила проекта в корне — стек, структура, соглашения, команды сборки и тестов, запреты («миграции — только через Alembic», «без прямых запросов в обход сервисного слоя»).
Планы в репозитории — каждая фича перед реализацией оформлялась планом с шагами и чек-листами. Агент исполнял план по шагам, отмечая выполненные.
Образцы-эталоны — «новый эндпоинт делай по образцу этого файла», «новую миграцию — по образцу этой».
Контекстный пакет задачи (из статьи 1): цель, критерии приёмки, ограничения.

Инвестиция в этот стек размером в пару дней дала больше, чем любая смена модели.

Рабочий цикл «задача → код»

Проверенная на проекте схема одной итерации:

Рамка. Задача с критериями приёмки и явными границами: «трогай только модуль X, публичный API не меняй».
План. Агент сначала предлагает план из 3–7 шагов и список файлов. Утверждаю или правлю. Этот шаг ловит 80% непонимания — до написания кода.
Реализация маленькими коммитами. Один логический шаг — один коммит. Откат к рабочему состоянию — всегда в одну команду.
Самопроверка. Агент прогоняет тесты, чинит найденное, показывает дифф.
Человеческое ревью. Дифф ревьюится как код толкового джуна: логика — вся, стиль — выборочно.

Инцидент: миграции, которые не применились

Лучший урок этапа — реальный прод-инцидент. Симптом: после деплоя импорт контента вернул «Imported 0 markdown files», хотя файлы были на месте.

Разбор вёл агент в режиме со-воркера, по цепочке:

Импорт молчит об ошибках. Код ловил исключения по-тихому (except Exception: continue) — это была первая находка: молчаливые провалы маскируют проблему.
Таблицы не созданы. Запустили импорт пошагово: «relation contents does not exist». Миграции не применились.
Миграции падают с SyntaxError: null bytes. Alembic загружал все .py из папки версий — включая мусорные файлы ._*.py (AppleDouble-артефакты macOS), попавшие в Docker-образ при переносе файлов.
Причина мусора: macOS-архиватор включал в tar AppleDouble-записи; при распаковке на Linux они материализовались как файлы.
Почему прозевали: миграции на старте тоже были обёрнуты в try/except: pass — «чтобы не падать в dev без БД». В проде это обернулось тихим провалом.

Исправление: перенос файлов с флагом --no-mac-metadata, мусорные паттерны в .dockerignore, миграции — в команду запуска до uvicorn, без глушения ошибок. Урок: тихая обработка ошибок — это технический долг, который возвращается в проде.

Второй инцидент этого этапа — гонка двух воркеров uvicorn: планировщик фоновых задач стартовал в каждом процессе, и анонсы дублировались. Лечится одним воркером для планировщика (детали — в статье 5).

Приёмы, которые дали максимум

Тест впереди. Агент сначала пишет падающий тест по критерию приёмки, потом реализацию. Объективный критерий «готово» — и никакой имитации работы.
Маленькие коммиты. За проект — десятки коммитов, каждый обозримый. Инцидент с миграциями откатывался одной командой.
«Объясни перед тем как менять». Перед правкой чужого (читай: вчерашнего агентского) кода — сначала объяснение текущей логики. Пару раз это спасло от «починки» работающей фичи.
Новая задача — новая сессия. Агент деградирует на гигантских сессиях. Свежий контекстный пакет лучше двухчасового диалога.
Параллельные задачи — разным агентам. Фронтенд и бэкенд по одному контракту шли одновременно.

Безопасность и комплаенс

Код уходит в облачную модель — для чувствительных кодовых баз это вопрос комплаенса. В моём проекте код не содержит клиентских данных, поэтому выбрано облако; для корпоративных проектов — корпоративные тарифы или локальные модели.
Агент с правом запускать команды — только в изолированном окружении, без продакшн-доступов.
Зависимости: новые библиотеки — только с обоснованием; в CI — аудит уязвимостей.

Метрики этапа

Lead time задачи — от постановки до работающего коммита: в проекте типовые фичи укладывались в один вечер.
Доля принятого ИИ-кода — оцениваю в ~70–80% при ревью каждой строки; главное не доля, а то, что непроверенным не уходит ничего.
Дефектная плотность ИИ-кода — баги из этой статьи родились не из «плохого кода», а из инфраструктурных допущений (архивы, воркеры). ИИ-код сам по себе оказался честнее, чем ожидал.

Практический минимум для старта

Напишите правила проекта (если пропустили статью 2 — сейчас самое время).
Введите обязательный шаг «план перед кодом» для агентных задач.
Переведите агентов в изолированные окружения без продакшн-доступов.
Заведите 2–3 эталонных файла и ссылайтесь на них в задачах.
Начните измерять lead time — без него вы не узнаете, работает ли всё это.

💬 Обсудим? Какой режим работы с ИИ преобладает у вас — автокомплит, диалог или агенты? И что мешает перейти на шаг дальше: контекст, доверие, безопасность? Расскажите в комментариях или в [Telegram-канале GoRunWithAI]. Наши агенты тоже ломают — каждый случай с разбором публикуем на дашборде открытой кухни.

Следующая статья: «Часть 4. Код-ревью: что ловил и что пропускал ревьюер GoRunWithAI».