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