9 мая пост «I’m going back to writing code by hand» набрал на Hacker News 1038 баллов и 617 комментариев. Для сравнения, наша собственная статья про Clean Architecture и AI получила 21 голос за первые сутки, и мы этому радовались. Автор семь месяцев вайб-кодил Kubernetes-дашборд с Claude, дошёл до объекта на 1690 строк, который тянул на себя вообще всё, и объявил, что возвращается писать код руками. Я прочитал пост дважды, потому что узнал в нём собственную историю полугодовой давности. Вывод у меня только другой.

Коротко о себе: Full-Stack JS архитектор, стек TypeScript, Node.js, NestJS. С Claude Code в продакшене с 2024 года, про перестройку 200К-строчного проекта под ежедневную работу с агентом писал отдельно.

1. Что случилось у автора k10s

Проект называется k10s, TUI-дашборд для Kubernetes-кластеров с GPU, что-то вроде k9s, но заточенное под людей, которые следят за утилизацией видеокарт. 234 коммита, около 30 выходных, почти полностью вайб-кодинг с Claude на протяжении семи месяцев.

Первые недели прошли на эйфории. Автор просил «добавь вью подов с live-обновлением», и оно просто работало. Ресурсные списки, фильтрация по неймспейсам, стриминг логов, командная палитра, вим-биндинги, всё за пару сессий. Проект был маленький, агент держал его целиком в контексте, и каждая фича прилетала чистой.

Потом он попросил главную фичу, ради которой всё затевалось: экран с fleet view по GPU-нодам, утилизация, температура, память. Агент собрал её с одного промпта, выглядело красиво. А потом автор переключился обратно на вью подов, и всё сломалось. Таблица пустая, live-обновления встали, счётчики во вьюхах перепутались.

Он сел читать код, которым семь месяцев не интересовался, только смотрел на диффы и проверял, что компилируется. model.go разросся до 1690 строк. Один структ держал вообще всё: UI-компоненты, k8s-клиента, состояние каждой отдельной вьюхи, историю навигации, кэши, обработчик мыши. Функция Update() разрослась почти до 500 строк со 110 веточками switch. Чтобы вьюха не показывала данные от предыдущего экрана, в коде накопилось девять отдельных ручных сбросов полей в nil, разбросанных по разным обработчикам. Пропусти один, получишь тень от прошлой вьюхи.

Отдельно там нашлась настоящая гонка данных: фоновая горутина мутировала общие поля структуры напрямую, без канала и без блокировки, а View() в это время читала те же поля из другого потока. Работало в 99% случаев. В оставшемся проценте автора убеждало, что он сходит с ума.

Ни разу тесты не были красными в процессе. Каждый диф проходил визуальную проверку. Просто в какой-то момент система стала непроходимой, потому что фичи закрывались одна за одной, а архитектуры под ними не было вообще, был один разрастающийся объект.

2. Пять уроков, которые он из этого вынес

После разбора автор написал пять тезисов, которые теперь держит в CLAUDE.md для своего следующего проекта. Пересказываю своими словами, без копирования его кода:

1. AI строит фичи, а не архитектуру. Каждый промпт закрывает одну задачу и не видит остальные сорок девять фич, которые уже живут рядом.

2. God object это дефолтный результат агента. Один структ на всё дешевле в моменте, чем пять типов с интерфейсами, а агент оптимизирует именно моментальную стоимость.

3. Иллюзия скорости расширяет масштаб задачи. Раз фича стоит «бесплатно», хочется добавить ещё одну, и ещё, пока бюджет сложности не кончится незаметно для автора.

4. Данные без типов это бомба с часовым механизмом. Строки и позиционные массивы вместо структур работают, пока кто-то не поменяет порядок колонок, и тогда сортировка молча ломается.

5. Агент не различает, кто владеет состоянием. Мутация без явного канала сообщений работает в большинстве случаев и ломается в проценте случаев, что хуже всего для отладки.

Все пять по существу верные наблюдения. Ни с одним не спорю.

3. У меня была почти такая же ночь

Про свой похожий момент я уже писал отдельно. Полгода назад я открыл pull request от Claude Code и завис над одной функцией. Формально чистая, тесты зелёные, ревьюер поставил апрув. А я не мог внести правку, не удержав в голове граф из восемнадцати файлов, потому что сервис уведомлений тянул зависимости из биллинга, профиля и аналитики.

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

4. Где я согласен с автором

AI не изобретает архитектуру сам. Это факт, который я проверял на своём проекте месяцами. У модели нет органа, которым чувствуют разрастающуюся связность, у неё есть только контекст текущего промпта. Инварианты нужно написать явно и заранее, иначе их не будет вообще.

Автор в этом прав на все сто. Проблема не в диагнозе. Проблема в рецепте, который он из этого диагноза вывел.

5. Где не согласен

Вывод «возвращаюсь писать руками» путает причину со следствием. Смотрите внимательно на его же пять тезисов. Ни один не требует, чтобы человек лично печатал код. Каждый требует, чтобы человек принял архитектурное решение до первого промпта, а не после тысяча шестисотой строки.

«AI строит фичи, не архитектуру» решается тем, что архитектуру строит человек заранее, а дальше не важно, кто печатает реализацию. «God object это дефолт» решается запретом на добавление полей в общий структ, а это правило линтера, а не правило клавиатуры. «Иллюзия скорости расширяет скоуп» решается явной границей задачи, записанной до старта. Ни один пункт не говорит «печатай сам», каждый говорит «реши раньше».

Настоящая граница проходит не между «пишет человек» и «пишет агент». Она проходит между «архитектура придумана заранее» и «архитектура нащупывается по факту после коллапса». Автор перепутал вторую линию с первой, потому что в его случае обе совпали случайно: он не думал про архитектуру заранее, и он же не читал код, который писал агент. Совпадение двух причин он списал на одну.

6. Тот же провал бывает и без AI, просто медленнее

Комок из спутанных зависимостей и разросшихся объектов существовал в индустрии задолго до языковых моделей. Есть даже отдельный термин для этого, big ball of mud, ему больше двадцати лет. Команды без единого агента годами копят ту же связность, что k10s накопил за семь месяцев.

У меня есть с чем сравнить. Тот legacy JS-проект, который мы позже мигрировали на strict TypeScript, копил похожий уровень спутанности примерно три года, без единого агента, силами живых разработчиков, которые торопились к дедлайнам. У k10s это заняло семь месяцев с одним человеком за клавиатурой и AI в роли рук. Это не новая болезнь. Это старая болезнь, которая работает в разы быстрее, потому что печатать стало почти бесплатно.

Отсюда практический вывод: если раньше плохая архитектура убивала проект за годы, и у команды было время это заметить и поправить, то с AI то же самое происходит за месяцы. Значит, замечать и поправлять надо тоже быстрее, а не убирать AI из процесса.

7. Что стоит у нас вместо возврата к рукам

Мы решали ровно те же пять проблем в статье про Clean Architecture, только не после коллапса, а как систему, которую строили заранее. Вот как пять его тезисов ложатся на наши практики:

Разница не в том, что мы умнее придумали правила. Разница в том, когда эти правила появились. У нас они стояли до того, как агент написал первую строчку в новом модуле. У автора k10s они появились как посмертный список полугода спустя.

8. Почему просто написать это в CLAUDE.md не сработало ни у него, ни у нас сначала

Автор в итоге тоже кладёт свои пять правил в CLAUDE.md и agents.md. Это шаг в верном направлении, но у нас был тот же провал на старте, и текст в файле его не закрыл.

Текстовое правило агент трактует. Когда «не добавляй поля в общий структ» вступает в конфликт с «сделать задачу прямо сейчас», агент почти всегда выбирает задачу. У нас было ровно так же, пока правила жили только в виде абзацев в CLAUDE.md. Разница появилась, когда те же правила переехали в dependency-cruiser и eslint-конфиг, и нарушение стало валить CI. Тогда агент не трактует правило, а видит красный пайплайн и чинит сам, до того как код доходит до ревью.

Пять правил автора k10s это ровно то, что нам дало не в разы меньше переделок, а хоть какой-то эффект, только когда правила превратились из текста в код. Пока они остаются текстом в CLAUDE.md, это шаг вперёд по сравнению с их отсутствием, но не решение, а полумера.

9. Anthropic на этой неделе говорят о том же

Пока писал эту статью, наткнулся на свежий разбор от самой Anthropic про то, как Claude Code ведёт себя на больших кодовых базах. Тезис там ровно тот же: результат определяет не модель, а обвязка вокруг неё, CLAUDE.md, hooks, линтеры, скоуп задачи. Модель за последний год почти не изменилась в этом смысле, а разница между удачным и неудачным внедрением у них по наблюдениям в основном в обвязке, а не в выборе версии Claude. Разберу подробно в следующей статье, там у Anthropic есть конкретные паттерны про иерархию CLAUDE.md по поддиректориям, которые стоит сверить с тем, что описано выше.

10. Когда «вернуться к рукам» на самом деле оправдано

Не буду делать вид, что рецепт автора всегда неверный. Есть случай, где он честный.

k10s это сольный проект выходного дня. Один человек, без команды, без бюджета на построение инфраструктуры энфорсмента. Настроить dependency-cruiser, контрактные тесты на границах модулей, CI-гейты, это работа, которая сама по себе не пишет фич. На проекте одного человека, который развивается по вечерам, эта работа может не окупиться до того, как проект надоест или закроется. В таких условиях писать руками на языке, который чувствуешь пальцами, вправду может быть быстрее, чем строить систему энфорсмента ради тридцати коммитов в год.

У нас другая ситуация. Продакшн-проект, команда, код живёт годами. Стоимость построения тех же правил окупилась за первые же месяцы, я про это писал с цифрами, доля пул-реквестов на архитектурную переделку упала примерно с каждого второго до каждого пятого. На таком горизонте инвестиция в границы и линтер окупается кратно, и отказываться от агента ради ручного набора текста было бы шагом назад, а не вперёд.

Правило простое: чем дольше живёт код и чем больше у него авторов, тем выгоднее заплатить один раз за архитектуру заранее. Чем короче горизонт проекта и чем меньше в нём рук, тем более законен путь «просто пишу сам».

Вывод

Разделительная линия проходит не между человеком и агентом за клавиатурой. Она проходит между архитектурой, продуманной до первой строчки, и архитектурой, которую нащупывают на обломках после тысяча шестисотой строки. Пять уроков из k10s это на самом деле пять способов сказать одно и то же: решайте про инварианты заранее, а не потом. Просто автор заплатил за этот вывод семью месяцами и god object’ом, а рецепт себе выписал не тот.

Если тема близка, я пишу про реальный опыт работы с Claude Code в продакшене в Telegram-канале «AI-усиленный разработчик», там разборы покороче и почаще. Ссылка в профиле. В комментариях интересно, у кого был свой момент с god object, и что вы сделали после, переписали руками или заплатили за границы заранее.