[Перевод] Я vs. машина

Прошёл примерно год с тех пор, как я начал активно использовать Claude Code для разработки, и, как я уже писал, это существенно изменило мои рабочие процессы. Продуктивность действительно выросла — но в основном по ощущениям, а они у меня примерно такие же надёжные, как мои эстимейты (то есть никакие, и лучше не станут). Так что я решил, что пора проверить своё чутьё абсолютно научно пуленепробиваемым способом (со статистически высокозначимой контрольной группой из меня, себя и моей собственной персоны).

Эксперимент, о котором никто не просил

В голове уже какое-то время крутилось несколько вопросов:

• Это правда быстрее, чем писать код самому?

• Какая разница в качестве?

• Какая реальная разница в стоимости между ручной и агентной разработкой?

• Сколько бы мой процесс стоил без подписки Claude Max?

• Позволяет ли хороший цикл обратной связи использовать более дешёвую/слабую модель?

• Буду ли я когда-нибудь запускать кодинг-модель у себя в подвале?

На работе я крайне редко делаю симуляции прыгающих мячиков или клоны Minecraft (а если бы у меня была ночная подработка помимо укладывания бессонных младенцев — я бы и там этим не занимался), поэтому мне нужен был тестовый кейс чуть ближе к реальной жизни. Когда я начал работать над новым проектом «GraphQL-middleware плюс React-UI», я увидел свой шанс. Архитектура достаточно нестандартная, чтобы посмотреть, как разные модели справятся с вызовом, но при этом близкая к стандартным обучающим данным, чтобы они продвинулись далеко:

• Кастомная GraphQL схема, объединяющая legacy API

• GraphQL сервер с резолверами на Effect

• React клиент для взаимодействия со всем этим добром

Фундамент проекта уже существовал. Это не эксперимент в чистом поле. Задание — добавить страницу управления пользователями на основе React-макета, который навайбкодил наш UX-эксперт. Пригласить новых пользователей по email, сменить им роль, удалить. Звучит просто, но, как всегда, проблема не в написании кода, а в лавировании среди обстоятельств. С одной стороны, legacy API имеет пару белых пятен — например, свойство role на объекте пользователя, которое является просто строкой и не говорит нам, какие роли вообще доступны. С другой стороны, макет очень амбициозный и содержит кучу фич, которые целевой сервис пока даже не поддерживает. Мне хотелось понять, как агент справится с такого рода препятствиями, которые в реальности встречаются чуть чаще, чем надуманные примеры с YouTube при каждом выходе новой модели.

Как замучить 6 AI-агентов (и себя)

Частично ради этого исследования я навайбкодил небольшой инструмент, создающий CLI-интерфейс, не привязанный к конкретному агенту, для одинакового воркфлоу с разными агентами. Он, кстати, оказался очень полезным и за рамками эксперимента — когда доведу до ума, напишу отдельный пост. Суть такая:

1. Создаю файл TODO.md в корне репозитория.

2. Запускаю инструмент в режиме plan. Он читает мой TODO-промпт, исследует проект и составляет план.

3. Делаю ревью плана и даю обратную связь.

4. Агент обновляет план, итерируем до готовности.

5. Запускаю инструмент в режиме build, и он проходит по всем пунктам в Ralph-Loop (цикл «делай пока не сделаешь»).

6. После каждого TODO-пункта прогоняется весь набор тестов, ошибки скармливаются обратно агенту для исправления. Повторять, пока всё не зелёное.

7. Возвращаюсь к готовому проекту, который возможно делает то, что я ожидаю. Или нет. Тогда — ручное тестирование и код-ревью.

Я добавил в репозиторий довольно обширную документацию по стандартам кода. Чёткие инструкции, какие библиотеки использовать для каких задач, предпочтения по типизации и какие тесты писать. Также в проекте уже были реализованы GraphQL-резолверы на Effect, но ни одной формы (это важно — запомните на потом).

Затем я прогнал одинаковый воркфлоу со следующими конфигурациями агентов:

• Opus 4.5 с Claude Code на Max Plan: конфигурация, которую я давно использую. С одной стороны — планка ожиданий для сравнения, с другой — хочу понять, насколько Anthropic её субсидирует.

• GPT Codex 5.2 с OpenCode на OpenCode Zen: в основном чтобы проверить главного конкурента, поскольку сам Codex я раньше не использовал.

• Opus 4.5 с OpenCode на amazee.ai: чтобы получить «сырую» цену для сравнения с Claude Max.

• Kimi 2.5 с OpenCode на OpenCode Zen: open-source модель, которую потенциально можно запускать локально.

• Minimax 2.1 с OpenCode на OpenCode Zen: другая open-source модель, которую потенциально можно запускать локально.

• Mistral Devstral с OpenCode на La Plateforme: европейский вариант.

• Philipp 43 с Neovim на Coffee: чтобы установить «золотой стандарт» и сравнить стоимость всех остальных.

Я дал каждой конфигурации шанс решить задачу, включая 2–3 цикла обратной связи, если с первого раза получилось не всё. При этом я намеренно не делал детальное код-ревью, чтобы не перекосить результаты в сторону моей собственной реализации, за которую сел сразу после (а ведь всегда проще, когда ты уже видел все чужие ошибки — классическая предвзятость в духе «Мы переписали приложение на [модный фреймворк] и стало гораздо лучше!»).

После ручного марафона я бегло просмотрел каждую реализацию и заставил Claude сделать детальное сравнение всех версий по следующим метрикам:

• реализованные фичи

• структура тестов

• использование библиотек

• подход к типизации

• паттерны оптимистичного UI

Ещё я попросил Claude оценить трудозатраты на доведение каждой версии до архитектурного паритета с моей ручной реализацией. К этой оценке стоит относиться с оговоркой, но это же эстимейт — так что он, вероятно, не хуже моего собственного 🤷‍♂️.

Отчёт об ущербе

Детальный отчёт можно посмотреть здесь, а я просто подведу итоги по самым важным находкам.

Opus 4.5 с Claude Code на Max Plan

Сгенерировал самый большой дифф, но это — несколько неожиданно — не сильно ухудшило качество результата. Ближе всех подошёл к ручной реализации, но не справился с тем, чтобы правильно определить границы фичи, которую бэкенд API пока не поддерживает. Съел около 20% недельного лимита моего $100 Max-плана, что сводится примерно к $4 стоимости AI.

GPT Codex 5.2 с OpenCode на OpenCode Zen

Вот это было весело. Codex написал чрезвычайно короткий и расплывчатый план (около 10% от объёма остальных), и результат поначалу меня поразил. UI — пиксель в пиксель, до мельчайших деталей. И все взаимодействия работали. Я даже написал коллеге в Slack, что гонка окончена, но потом увидел, что сетевых запросов нет 🤯 Он просто полностью пропустил бэкенд/API-часть и засунул всё в React-стейты 🤣. Но — после вежливого намёка, что это не совсем продакшен-реди, как он заявлял — выдал вполне приличную реализацию бэкенда тоже. Общая стоимость токенов составила $10.

Opus 4.5 с OpenCode на amazee.ai

Вне Claude Code модель Anthropic оказалась чуть менее способной. Самая крупная ошибка по сравнению с «официальной» версией — использование регулярок для валидации форм вместо Zod. Общая стоимость на AWS дошла до $20, что даёт нам представление, сколько маркетингового бюджета Anthropic закладывает в Max-план.

Kimi 2.5 с OpenCode на OpenCode Zen

На мой взгляд, это была звезда шоу. Kimi выдал результат почти на уровне Opus, и при этом не является проприетарной моделью. Работал очень медленно по сравнению с другими, но поскольку весь смысл в том, что я не пялюсь в экран, пока он думает, мне без разницы — 15 или 45 минут. Стоимость токенов за задачу — $7, что выше субсидированного Claude Max, но даже ниже Codex по сырым токенам.

Minimax 2.1 с OpenCode на OpenCode Zen

Minimax значительно дешевле Kimi, и именно поэтому я хотел столкнуть их друг с другом. К сожалению, потенциал раскрыть не удалось. Имплементация потребовала гораздо больше циклов обратной связи и исправления тестов, что вылилось в $6 за решение, которое в итоге даже не было на 100% рабочим. Более дешёвая модель не означает автоматически более низкую стоимость. Прямо как с людьми 😈. Но тем временем вышел Minimax 2.5, и я слышал о нём много хорошего. Так что не списывайте их со счетов.

Mistral Devstral с OpenCode на La Plateforme

Devstral, к сожалению, разочаровал. После $30, потраченных на токены, решение всё ещё было далеко от конкурентов. Вот тебе и европейская альтернатива.

Что я узнал (кроме того, что я дорого стою)

Сводка «оценочной общей стоимости»:

То, что обе версии Claude оказались на первых местах — вероятно, не совпадение, ведь оценку тоже делал Claude (надо было анонимизировать версии заранее 🤦‍♂️). Также часы разработки на доведение кажутся мне завышенными, но у меня и самого с точностью эстимейтов не очень, так что оставлю как есть. Но несмотря на размытость результатов, эксперимент получился занятным, и я вынес из него несколько уроков. Некоторые были ожидаемы — теперь хотя бы отчасти доказаны, — другие удивили. Вернёмся к исходным вопросам:

• Это правда быстрее, чем писать код самому? Да.

• Какая разница в качестве? При правильных рамках качество зачастую даже выше, потому что у меня остаётся больше времени на полировку.

• Какая реальная разница в стоимости между ручной и агентной разработкой? В зависимости от задачи может быть весьма ощутимой. До 80% экономии — это не шутка.

• Сколько бы мой процесс стоил без подписки Claude Max? В пять раз дороже, если платить за токены той же модели. Но open-source модели меняют это уравнение.

• Позволяет ли хороший цикл обратной связи использовать более дешёвую/слабую модель? К сожалению, нет. Я предполагал, что при наличии цикла, который просто перезапускает агента, пока не станет хорошо, можно обменять время выполнения на более мелкие, менее способные модели. Но в итоге потребление токенов существенно растёт, и дешевле не получается.

• Буду ли я запускать кодинг-модель у себя в подвале? Потенциально. Руки чешутся заказать Framework Desktop, но кто знает, каким будет мир через год. А инвестиция с предполагаемым сроком амортизации в три года — это сейчас слишком долго. Живём в безумные времена.

Но есть ещё один ответ — на вопрос, который я не задавал:

Навыки и документация значительно менее важны, чем существующий код. Все модели отлично справились с созданием GraphQL-резолверов на Effect (которые уже были в кодовой базе), и при этом все полностью проигнорировали мои задокументированные инструкции использовать react-hook-form и Zod для работы с формами. Это значит, что настоящая сила агентной разработки — не в блестящих одноразовых вайб-промптах, за которыми все гонятся. Они могут сработать, но без правильного руководства агент скатится в хаос. Ирония в том, что делать нужно ровно наоборот. Создавать по-настоящему качественные начальные проекты, которые отвечают всем требованиям по качеству, чтобы джинну было что достойно воспроизводить раз за разом. И именно для этого нам по-прежнему нужны инженеры.