Claude Code это инициативный junior с памятью золотой рыбки. 5 правил контроля для production

TL;DR

За один месяц я в одиночку написал и развернул production-систему регулярного анализа цен и продуктов на конкурентном рынке. Сейчас в системе ~25 источников разной природы, в плане до конца года — ~60. На текущей выборке ~6000 единиц данных о продуктах, на полной будет ~15000. Уже сделаны 814 unit-тестов, многоступенчатый matching с embeddings и LLM-as-judge на 4-компонентном скоринге, 89 спринтов (не знаю, о чем это говорит), 2000+ записей в decisions log, регрессионный фильтр на эталонных парах в CI. До этого пятнадцать лет я преимущественно управлял командами и бизнесами, код руками открывал раз в три года. Главный вывод: Claude Code это инициативный темпераментный junior с памятью золотой рыбки. Он умеет фигачить код пачками и предлагать решения, до которых senior дозревает за неделю, но без жесткого контроля разваливает любую систему сложнее MVP за две сессии. Ниже — пять правил, которые я выработал, и мое мнение, для каких задач этого хватает, а для каких нет.

Кто я

Карьеру в IT начал в 16 лет. Прошел путь от эникейщика до CEO IT-компании. По дороге был администратором Linux (даже разбираюсь в sendmail.cf), разработчиком на C++, Oracle DBA, тимлидом, руководителем разработки, бизнес-аналитиком. Двадцать с лишним лет в индустрии. Но последние годы управлял командами и бизнесами, а IDE открывал редко, и то чтобы сразу закрыть. Месяц назад взялся за проект, в котором не хотел нанимать команду: задача разовая по объему, но требует production-уровня инфраструктуры. Решил посмотреть, что LLM-инструменты дают такому как я с моим бэкграундом. Так в моей жизни появился Claude Code.

Что я построил

Задача: регулярный анализ цен и продуктов конкурентов. Это нужно финансам (ценовой бенчмарк), продуктовой команде (gap-анализ свойств продуктов) и продажам (УТП и battle cards). Снаружи задача звучит просто, по факту это полноценный проект.

• Сбор данных: ~25 источников на разных движках (WordPress+Elementor, Tilda, Next.js+Apollo, Vue/Nuxt SPA, MODX, кастомные CMS). Каждый источник — уникальный сборщик: discovery → fetcher → recognition → postprocessing. Стек: requests + BeautifulSoup/lxml для статики, Playwright для JS-only страниц, API-first для встроенного JSON.

• Хранилище: SQLite на dev с реляционной схемой, PostgreSQL в production.

• Аналитика: gap-analysis, cannibalization, duration-benchmark, opportunity-map, price-benchmark, pricing-report — каждый отдельный CLI с экспортом в XLSX для HITL.

• Matching: трехступенчатая система. Этап 1 — гибридный предварительный фильтр с 4-компонентным баллом + multilingual-e5-base embeddings. Этап 2 — LLM-as-judge для семантических граничных случаев. Этап 3 — агрегация с ручными переопределениями. Веса оптимизированы перебором по сетке 3×3×3×4 грубый + ±0.05 точный. Вычисление через предвычисленную матрицу — ~25 секунд на 70 опорных продуктов × 3700 кандидатов вместо 40-60 минут банального перебора. Достигнутый recall на эталонных парах: R1=91.1%.

• Качество: 814 unit-тестов, регрессионные тесты на эталонных данных в CI, lifecycle верификации семплов, ежемесячная регрессия с порогом 1 п.п.

• Production: VPS с PostgreSQL, cron на 2 запуска в неделю, автоматическая доставка отчетов по email.

Все писал я один с Claude Code в роли постоянного партнера.

Главный инсайт

На третьей неделе работы с Claude Code я поймал ощущение, которое не сразу смог назвать. Это было ровно то же самое, что я чувствовал, когда тимлидил молодую команду, среди которой был один особенный тип junior’а. Знаете, может? Энергичный, инициативный, с подвешенным языком. Делал за полчаса то, на что senior тратил два часа. Сам предлагал улучшения. Никогда не уставал, не обижался на критику. И при этом: не помнил вчерашнего разговора, регулярно соглашался «сделать это» и на следующий день делал не то, в порыве улучшения переписывал модуль, который никто не просил трогать. Если такого junior’а оставить без надзора на неделю, к концу недели у тебя три ветки, из которых работает одна, и никто не помнит, какая именно и почему.

Claude Code это ровно такой же тип. С двумя отличиями: он быстрее в десять раз, и в ноль не помнит, что вы обсуждали в предыдущей сессии. Открыл новый чат — у вас новый сотрудник. Имя то же, опыт тот же, контекст ушел. Без внешней памяти он начинает изобретать заново все подряд, и в production это означает гарантированную деградацию системы. Я выработал пять правил контроля. Без них этот junior разваливает любую систему сложнее MVP. С ними он становится инженером, который делает в день столько, сколько раньше команда из трех человек.

Правило 1. TDD до первой строчки кода

Стандартный TDD — вопрос вкуса. С LLM это не вопрос вкуса. Без теста, написанного до реализации, вы не отличите «Claude сделал то, что я просил» от «Claude сделал то, что компилируется и проходит его собственную интуицию». В моем проекте 814 unit-тестов, каждый написан до соответствующего кода. Регрессионные тесты на эталонных данных — отдельный пакет. Smoke-тесты на критичные пайплайны. Без этого LLM пишет «нормально», но «нормально» в production не работает: на крайних случаях уверенно галлюцинирует, в многослойных взаимодействиях упускает детали. Тест — это рамка, в которой LLM физически не может разбежаться. Если тест зеленый — как минимум одно ожидаемое поведение работает; если красный — вы знаете, где проблема. Без рамки вы доверяете самооценке модели, которая стабильно завышает свою уверенность.

Правило 2. Документация как внешняя память

Документация в эпоху LLM это не «ну хорошо бы». Это инфраструктура. Без нее каждая новая сессия начинается с нуля, и LLM с нуля изобретает архитектурные решения, которые вы уже принимали. В моем проекте документация устроена слоями.

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

• architecture.md / data_model.md / parsing_guide.md — контракты внутри проекта: какие слои, какая схема, какие конвенции.

• decisions_log.md — 2000+ записей формата «дата | решение | обоснование | альтернативы». Без него каждые две недели вы заново отвечаете на вопрос «почему SQLite на dev и Postgres на prod».

• matching.md — 1500-строчный документ по эволюции matching pipeline и обоснованию 4-компонентных весов.

• 89 sprint-планов. Каждый спринт — отдельный документ с задачами, метриками, итогами.

• README в каждом каталоге парсера — особенности конкретного источника: движок, крайние случаи, политика парсинга.

Это выглядит избыточно для одного разработчика. Не фига это не избыточно для Claude. Это компенсация той памяти, которой у LLM нет.

Отдельно — методология спринтов. Каждый мой спринт начинается с трех компонентов: «Название», «Список задач», «Метрики качества». Заканчивается четырьмя: «Статус по метрикам», «Анализ результатов», «Обновление документации», «Merge в main». Без этих заборов спринт расползается, документация устаревает за две недели, в main висят feature-ветки, через месяц никто не помнит, что и зачем делалось. Спринты по matching дополнительно обязаны содержать quality baseline до и после спринта, плюс секцию ## Quality verification со сравнительной таблицей по каждой метрике. Регрессии допустимы только с явным обоснованием. Если recall регрессировал — спринт не мерджится.

Без этой дисциплины Claude Code перестает быть полезным примерно через 10-12 млн. токенов.

Правило 3. Регрессионные тесты на golden data

Специфика data-проектов и matching-систем, но идея переносится шире. У меня есть набор размеченных продактами «правильных» пар — опорный продукт и аналог конкурента. После каждого изменения в matching pipeline я запускаю скрипт quality_baseline, который вычисляет R1 / R2 / R3 (recall на разных подвыборках), C1 / C2 (consistency), G1 / G2 (стабильность эталонных пар). Сравниваю «до спринта» с «после». Если хоть одна метрика регрессирует — спринт не мерджится.

Без этого правила LLM любит «улучшить» код так, что pipeline продолжает работать, но качество деградирует. Я ловил это пять или шесть раз за месяц. Без регрессионного фильтра заметил бы через два спринта, когда уже поздно.

Правило 4. Code review с правилом «не понял — не мерджу»

Каждый коммит, сгенерированный Claude, я читаю целиком. Не «пробежал глазами» — реально читаю. Каждое непонятое место — будущий баг. Если я не могу объяснить себе, почему именно эта реализация, а не другая, я не мерджу: либо разбираюсь, либо переписываю. Никаких «потом разберусь». Это утомительно. Это медленнее, чем доверять. Но это и есть единственная защита от того, что Claude в порыве инициативы добавил кэширование, которое сломает согласованность кэша при параллельной работе. Или поменял интерфейс функции, которую вызывают пять других модулей. Или заменил потокобезопасное соединение на общее — а через неделю на CI все начнет падать с SIGSEGV.

Это не абстрактный пример. Реальный случай из спринта оптимизации matching: Claude разделил sqlite3.Connection на ThreadPoolExecutor (c=20 для скорости), и до нагрузочного теста никто не заметил — на macOS под нагрузкой стало стабильно падать. Фикс: соединение на каждый поток через threading.local(). После — 14-кратное ускорение при стабильности. Если бы пропустил ревью этого PR, поймали бы SIGSEGV в production.

Правило 5. Жесткие границы инициативы в промпте

Темпераментный junior хочет улучшать все. Если попросить «поправь баг в функции X», есть существенная вероятность, что заодно будут переименованы две переменные в соседнем модуле, добавлено логирование «которое все равно понадобится», и слегка отрефакторено наследование, потому что «так чище». Через неделю таких улучшений вы открываете diff и не понимаете, что изменилось. Решение — явные границы в каждом промпте. «Не предлагай рефакторинг», «не меняй интерфейс», «не добавляй логирование», «ничего, кроме явного запроса». У меня для серьезных задач шаблон промпта на полстраницы с границами и обязательным форматом отчета о сделанном. Это снимает 80% незаказанных изменений.

Темпераментность опасна: при контроле дает скорость, без контроля разваливает систему.

Граница метода: для серьезной разработки этого недостаточно

Claude Code снимает огромный кусок трения для инженера, который знает, что делает. Я могу за день написать парсер нового источника, потому что знаю архитектуру, помню стек, держу в голове политики качества. Я ставлю Claude задачи плотно, проверяю каждый pull request, и за месяц мой результат эквивалентен команде из двух-трех инженеров средней квалификации. Звучит великолепно, да? Но дальше начинаются оговорки и нюансы.

Если бы вместо меня сел человек без бэкграунда, у него получился бы MVP, который выглядит как production. Тесты были бы зеленые, потому что Claude генерирует тесты под код, а не под требование. Документация или отсутствовала бы, или была бы враньем. Регрессии не ловились бы, потому что не на чем. Через три месяца этот MVP стал бы кладбищем, в котором никто не понимает, что происходит. Я наблюдал такие кладбища в чужих репозиториях уже не один раз в прошлой айтишной жизни. Видимо, они теперь появляются массово.

Маркетинг LLM-инструментов продает сюжет «убийство профессии разработчика». В реальности профессия не умирает — она усложняется. Теперь middle и senior должны не только проектировать, тестировать и владеть архитектурой, но и постоянно управлять моделью, которая инициативно вносит изменения, на которые ее не просили. Это новая нагрузка, которую никто не считал в обещаниях про «ускорение производительности». Создание production-систем по-прежнему требует людей, которые умеют думать, и LLM не делает junior’а senior’ом. Он просто позволяет тому, кто уже умеет, делать быстрее. И только при условии жесткой дисциплины: TDD, документация, регрессии, ручное ревью, явные границы инициативы и так далее. Оговорюсь: я давно не брал “шашки в руки”, может я что-то и подзабыл.

Если кто-то рядом с вами называет LLM-инструменты «революцией в разработке» — спросите его, поддерживал ли он LLM-сгенерированный код в production хотя бы полгода. Если ответ «нет» — это не революционер, это адепт. Революция в производстве софта происходит не там, где код пишется быстрее, а там, где он работает дольше без переделок. С Claude Code пока ровно наоборот: код пишется в разы быстрее, а сопровождение — в разы дороже, чем кажется на момент сдачи MVP.

Серьезные системы пишут люди. Темпераментный инициативный junior помогает им быстрее доходить до результата. Для сайтиков, разовых утилит и автоматизаций своих задач этого хватает с запасом. Для всего, что должно жить дольше квартала, без senior’а на входе и на ревью у вас не получится продукт. У вас получится впечатление продукта.

Дмитрий Волошин, основатель Школы бизнеса Ninox, сооснователь и генеральный директор OTUS. Заметки про управление, найм и фаундерский опыт: t.me/coffee_notes