80% кода теперь пишет Claude: как инженеры Google и Anthropic масштабировали delivery и CI за 6 месяцев

Я — Денис Шохирев, архитектор агентных AI-систем из Фрайбурга (DennisCraft AI Studio). Мой стек: Claude, Supabase, n8n, Doppler, self-hosted Postgres. В реальном проде, а не на демо, 80% кода для B2B-клиентов DACH сегодня пишет Claude, а CI/CD-процессы за 6 месяцев ушли на новый уровень. Если вы всё ещё вручную сливаете pull request’ы — вы уже отстали.

Claude в проде: как выглядит реальный delivery

Когда Claude Code только появился, многие относились скептически: “AI не может писать production-grade код”. В реальности, на моих проектах — включая публично доступный multi-agent стек live.gerdennisai.com — Claude уже генерирует 80% кода, включая интеграции с Supabase, обработку событий n8n и работу с Postgres. Человеческий труд уходит на ревью архитектуры и edge-case тесты.

На практике, pipeline выглядит так:

1. Промптинг Claude Code на основе issue и спецификации (через Anthropic SDK, не через UI).
2. Автоматический запуск статического анализа (semgrep, bandit, gitleaks) на каждый merge request.
3. CI/CD через GitHub Actions с кастомными чекпоинтами.
4. Вручную смотрю только на патчи, где статический анализ даёт красный флаг или покрытие тестами падает ниже 92%.

CI/CD: как ускорить цикл и не потерять контроль

Автоматизация ревью — не значит “безопасность по умолчанию”

По данным Stanford CodeML (2024, статья), 38% Python-кода, сгенерированного LLM, содержат паттерны CWE-89 (SQL-инъекции). На практике, у меня на 3 последних деплойментах агентов Claude я ловил похожие SQL-инъекции в автогенерируемых ORM-слоях. Поэтому статический анализ обязателен.

# Пример пайплайна статического анализа
semgrep --config=python --error ./
bandit -r ./src
gitleaks detect --source=./src

Результаты интегрируются с CI:

• semgrep отсекает unsafe SQL/exec/OS calls.
• bandit ловит небезопасные паттерны в Python.
• gitleaks — ключи и секреты.

Я вношу правки только если хотя бы один чек не прошёл — иначе авто-merge в main и немедленный деплой через n8n + Supabase.

Интеграция Claude с Supabase, n8n и Postgres: реальный стек

Claude Code не интегрирован “из коробки” с Supabase или n8n. Я пишу промпты, где указываю схемы таблиц, структуру событий, ограничения Postgres (например, ENUM-поля), и даю Claude реальные примеры данных. Это резко снижает количество багов на этапе интеграции. Пример промпта для генерации CRUD:

prompt = f"""
Ты пишешь Python-код для FastAPI сервиса. Таблица users:
- id: UUID, PK
- email: TEXT, unique
- status: ENUM('active', 'blocked')
Сгенерируй эндпоинты CRUD со валидацией и логированием.
"""
code = anthropic_client.completions.create(
    model="claude-3-opus-20240229", prompt=prompt, max_tokens=1000
)

Такой подход применяю и для интеграции с n8n (описание флоу, вход/выход, ошибки). Итог — Claude выдаёт код, который сразу проходит CI.

Production guardrails: как не словить регресс в проде

Динамические тесты и покрытие

Я не доверяю только статике — всегда запускаю runtime sandbox с реальными данными. Генерирую тесты через Claude (по спецификации и реальным edge-case), потом выполняю их в изолированной среде (Docker Compose).

docker-compose -f docker-compose.test.yaml up --abort-on-container-exit
pytest --cov=src tests/

Если покрытие падает ниже 92% — merge блокируется. Такой threshold держу на всех B2B-проектах, где есть compliance-требования (особенно финтех и логистика).

FAQ

Claude действительно пишет production-код?

Да, если правильно промптить и интегрировать с CI/CD. Человеческое ревью нужно только для архитектурных решений и сложных интеграций.

Как Claude справляется с edge-case?

Если описывать edge-case в промпте и автогенерировать тесты — справляется не хуже мидл-разработчика. Без явных указаний — часто пропускает тонкие баги.

CI/CD не превращается в узкое место?

Наоборот, автоматизация ревью и статический анализ ускоряют цикл. Человеческий bottleneck — только на сложных частях.

Какие баги чаще всего пропускает Claude?

Ошибки в валидации, неправильная обработка nullable-полей, некорректные edge-case по данным. Всё, что не было явно описано в промпте.

Какие инструменты критичны для такого пайплайна?

semgrep, bandit, gitleaks, pytest, docker-compose, Anthropic SDK. Всё остальное — по задаче.

Где у вас чаще всего ловятся баги в LLM pipeline — на этапе статического анализа, runtime sandbox или ручного ревью? Я реально хочу понять, где у других продовые затыки. Провожу бесплатный 30-мин аудит стека для DACH-команд, строящих AI под регулирование. Пишите в LinkedIn или @ger_dennis_ai.