Автор gonzo_ML: в его команде код пишут только модели, люди ревьюят

Обычно такие истории про «мы перешли на агентов» заканчиваются красивой презентацией. Здесь есть хронология, цифры и честное описание того, что не работало. Автор канала gonzo_ML рассказывает, как с 2024-го по 2026-й прошёл путь от «модели иногда дописывают код» до «руками в команде не кодит никто».

Порог, который перешли модели

Первые законченные проекты у автора получились на границе 2024 и 2025 годов. Он считает, что это модели перешли порог, а не он осмелел. В январе 2025-го Gemini и Claude собрали ему код трансформера, интервенций и визуализации активаций для курсового проекта по интерпретируемости. Весной он написал MCP-сервер для переводов, принципиально не набрав руками ни строчки. К декабрю переделал его на Streamable HTTP и довёл до продакшна. Как обычно, продакшн-часть оказалась объёмнее самой фичи: логирование, мониторинг, безопасность, нагрузка, обработка ошибок и деплой добавили больше кода, чем новый транспорт.

Рабочий подход получился такой: спеки с декомпозицией, тесты до реализации, ADR к принятым решениям. Начиналось всё со speckit, теперь команда живёт на этих практиках в Claude Code, уже не в одиночку.

Почему brownfield не получался, а потом получился

В 2025-м автор пробовал отдавать моделям платформенный код десятилетней давности. Багфиксы и мелкие фичи выходили «не то». Он списал это на brownfield. Позже выяснилось, что дело в другом: контекст лежал в головах людей, а не там, где его мог взять агент.

Поэтому команда занялась foundations. Моделям открыли доки в репах и через MCP к Confluence, стандарты и ADR, задачи (сначала в Jira, потом в Linear), продакшн-логи через MCP и при необходимости переписку в Slack. Всё то же, что нужно новому человеку в проекте. Теперь люди дают задачи и ревьюят, а первичное ревью, документацию, релизные документы и тесты тоже берут на себя агенты. Человек заглядывает в процесс на quality gates с аппрувом.

Боттлнек сместился. Писать код больше не долго, а вот финальное человеческое чтение трещит. Все держат несколько агентских сессий: пока один агент пишет, в другой можно читать свежие простыни диффов.

Шоппинг языка и Rust

Неожиданный эффект: язык можно выбирать под задачу, а не под компетенции команды. Первым кандидатом стал сервис-эмулятор реальных API со всеми их проблемами, в который упирались перф-тесты. Его переписали на Rust, а заодно на Go и Node, с parity-тестом на все четыре реализации.

В том же 100-мегабайтном поде Rust держит около 8 900 открытых соединений против примерно 3 400 у питоновского оригинала. В простое он занимает 1 MiB вместо 33. Go с fasthttp оказался лучше Python лишь на 11%, а на стандартном net/http вдвое хуже. Автор оговаривается: цифры с локального стенда, а на такое переписывание для вспомогательного сервиса в ручной парадигме никто бы и недели не выделил.

Не только код

Отдельный пример: бухгалтерский отчёт. Раньше автор каждый год перепроверял работу бухгалтеров и находил ошибки. В этом году это сделал Claude за один вечер. Он нашёл ошибки, которые автор не думал оспаривать, с отсылками к законам и трактовкам (автор проверил, всё сошлось). Нашёл неверный расчёт за прошлый год, который добавил налога, и потерянный возврат за этот год. Quality gate переехал: теперь модель проверяет и бухгалтеров, и самого автора.

Ограничения и вывод

Это один личный опыт, без независимых замеров. Бенчмарк Rust локальный, а налоговый кейс единичный, хотя ссылки автор проверил руками. Условия тоже особые: компания целенаправленно перестраивается в AI-first.

Практический вывод для команд: если агент выдаёт «не то», сначала проверьте, где лежит контекст. Вынесите в репозиторий и MCP доки, ADR, задачи и логи, пишите спеки и тесты до реализации. И заранее готовьте процесс ревью, потому что именно оно станет узким местом.