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’а на входе и на ревью у вас не получится продукт. У вас получится впечатление продукта.
Дмитрий Волошин, сооснователь и генеральный директор OTUS, основатель Клуба менторов, основатель школы бизнеса Ninox. Заметки про управление, найм и фаундерский опыт: t.me/coffee_notes
Комментарии (45)
akod67
27.04.2026 17:18Где вы джунов такого уровня берёте, поделитесь секретом? Ни разу таких не видел.
Dmitry21 Автор
27.04.2026 17:18я в свое время их промышленно выращивал из студентов технических вузов
martelle
27.04.2026 17:18клава на тактическом уровне уже давно синьёр. видит и сама репортит edge-case-ы, находит баги в concurrency и всё такое.
Dmitry21 Автор
27.04.2026 17:18вы там на мой вопрос о вашем опыте не ответили. соблаговолите, все же. а то уж больно круты, больно матеры
martelle
27.04.2026 17:18>это вообще мой первый опыт. поэтому я не имею право на обобщения
>вы там на мой вопрос о вашем опыте не ответили. а то уж больно круты, больно матеры
шизофрения?
тебе уже несколько человек отписалось, что если не писать ахинею в промты то описанных проблем НЕТ ВООБЩЕ. Итого - статья мусор.
akod67
27.04.2026 17:18Опасно для кармы такие вещи на хабре писать. Луддиты мелкие и мстительные. Мне уже терять нечего, своё отписал =)
i-yard
27.04.2026 17:18У меня прямо такие же выводы напрашиваются. Только что закончил средних размеров проект с claude code. Да, у меня есть скилы, иногда, особенно в начале, я много смотрел что он делает, но потом все скатилось в автоапрув. В итоге, ближе к релизу, просто куча багов: фиксим в одном месте, ломается два других, все по классике. Сейчас попросил claude code провести анализ логов задач и комитов (у меня claude коротко логирует свои действия чтобы можно было начать новую сессию и продолжить там где остановился) и один из выводов то же что и автора: тесты писались под код. Короче статье точно плюс
akod67
27.04.2026 17:18Проблемы “фиксим в одном месте, ломается в другом” сто лет в обед. Как это раньше решали? Почему сейчас так же нельзя?
amazingname
27.04.2026 17:18Впечатления близкие, тоже читаю всю логику пока не пойму, но пишу без юнит тестов, только с интеграционными, потому что так мне не надо заранее знать архитектуру, не надо ревьювать ещё и тесты.
А ещё пользуюсь почти чистым контекстом с минимальным md и не замечал чтобы агенту сильно сложно было въехать в код с нуля. Несколько минут анализа и обычно он уже знает все что нужно.
Кроме того, перед ревью прогоняю десяток заранее заготовленных промптов для улучшения кода - лишние логи, лишние проверки, смешение уровней абстракции и прочий рефакторинг. Но пока недостаточно опыта для уверенности что все это оптимальный путь.
Dmitry21 Автор
27.04.2026 17:18с промптами интересно, можете поделиться?
amazingname
27.04.2026 17:18Это прямо очень интимный вопрос.
Скрытый текст
Проанализируй все текущие незакоммиченные изменения по проектам (git diff HEAD) исключая проекты тестов. Вот текст постановки задачи по которой сформирован этот diff: … Проанализируй логику кода и составь список решений, которые не были в явном виде сформулированы в постановке задачи и приняты дополнительно при реализации. Возможно эти решения требуют обсуждения и корректировки.
Проанализируй все текущие… Проанализируй код на наличие параллельных решений, которые решают одну и ту же по сути задачу различным образом. Эти решения могут быть вынужденными, обсусловлены особенностями архитектуры или фреймворков. В любом случае опиши подобные особенности кода, чтобы обсудить возможность рефакторинга.
Проанализируй все текущие… При доработке часть функций (новых или ранее существующих) кода могли утратить свое исходное значение. Такие функции возможно нужно срефакторить или переименовать. Дай список таких возможных мест для рефакторинга.
Проанализируй все текущие… Новый код может содержать функции или блоки кода, могут быть вынесены в хелперы. Проанализируй код проекта: возможно подобные хелперы уже реализованы и ты можешь их переиспользовать. Дай список таких возможных мест для рефакторинга.
Проанализируй все текущие… Новый код может содержать захардкоженные магические значения, которые либо уже есть в константах в другом коде, либо могут быть вынесены в константы. Дай список таких возможных мест для рефакторинга.
Проанализируй все текущие… Новые классы могут быть размещены в существующих папках, назначение которых не совсем соответствует функциям этих классов. Проанализируй структуру папок проекта и размещение новых классов. Дай список таких возможных мест для рефакторинга.
Проанализируй все текущие… Новый код может содержать излишние подстраховки отсутствия или несоответствия данных. Удали проверки для случаев, когда логика кода такова, что проверяется условие которое никогда не случается.
Проанализируй все текущие… Код может содержать излишние FallBack на запасную логику при отсутствии данных или несоответствии данных текущей логике. Как правило подобные FallBack не нужны. Дай список таких возможных мест для исправления.
Проанализируй все текущие… Опциональные параметры некоторых функций на самом деле могут передаваться всегда, согласно текущей логике программы. Дай список таких возможных мест для исправления.
Проанализируй все текущие… Некоторые комментарии могут быть избыточными, если их смысл дублироуется в названиях функций. Удали такие комментарии.
Проанализируй все текущие… Некоторые комментарии могут отражать не текущую работу кода а как было раньше и как стало сейчас. Комментарии должны отражать только текущее состояние кода. Удали или поправь такие комментарии.
Проанализируй все текущие… В некоторых функциях, где логика разворачивается в коде последовательно, она может плохо секционироваться в коде или явно хорошо изолированные задачи не вынесены в отдельную фукнцию. Например, шаги одной задачи чередуются с шагами другой независимой задачи. Предложи список возможных мест для улучшения.
Проанализируй все текущие… В некоторых случаях локальные приватные переменные в классах могут быть созданы избыточно, там где проще было бы передать эти значения параметром в одну или максимум две приватные функции. Предложи список возможных мест для улучшения кода.
Проанализируй все текущие… В некоторых случаях в объекты могли быть добавлены поля, которые читаются потому что они есть в источнике, но затем никогда не используются. Предложи список возможных мест для удаления созданных “про запас” полей.
Проанализируй все текущие… В некоторых случаях в новом коде может встречаться смешивание уровней абстракции, усложняющее понимание кода. Например, в цикле или в последовательности действий выполняются некоие общие функции но одновременно в цикл или последовательность вставляется код с более низким уровнем абстракции, оперириующий деталями, или код который выполяет отдельную задачу и мог бы быть выполнен позже или раньше.
Проанализируй все текущие… В некоторых случаях новый код недостаточно выразительно отражает смысл происходящего. Т.е. технически переменные и условия верные, но архитекрута кода не отражает основые ключевые выбираемые варианты и пути обработки. Если код решает некую задачу и имеет ветвления, то эти ветвления и подзадачи должны быть более очевидными. Например, отражаться в названиях функций, избегать смешения уровней абстракции и др. Предложи список возможных мест для рефакторинга.
Antra
27.04.2026 17:18Раз уж тут такая тема "неожиданная" обсуждается, может ли кто своим опытом по использованию obra/superpowers и graphify.net поделиться?
OhSirius
27.04.2026 17:18Промышленная разработка с агентами странная - тонны документации, чтобы контролировать кодогенерацию. По сути нам нужно описать все решения своим языком в надежде, что получится создать лаконичную и точную спецификацию.
Geratron69
27.04.2026 17:18Это мой стек 3 месяца назад. Только чуть другой - главное правило - не плодить мусор. Клоауд после сессии обязательно захочет еще написать отчет о сессии и отчет об отчёте сессии. Сейчас полностью переехал в посгресс и всем советую. Заведите бд, возьмите хороший просморщик, организуйте тикеты, таблицу с тестами, базу знаний. ОБЯЗАТЕЛЬНО ПОДКЛЮЧИТЕ GITNEXUS !
Я пишу архитектурные документы, в них BDD таблица с чекбоксами критериев успеха, чёткая структура, тикеты. Далее тикеты забирается агентами кодерами и по критериям успеха строят тесты и уже от этих тестов пишут код. Поэтому тоже переходите на BDD - клауд расскажет что это и как использовать
d3d14
27.04.2026 17:18Я пишу архитектурные документы
У вас своя специфика. Вряд ли она универсальная.
KEugene
27.04.2026 17:18Мне кажется проблема подобного поведения как раз избыточность инструкций. Если нет разграничения сферы влияния всех этих md, то они и накладываются. Если внутри сессии будет прочитано несколько md, то, если нет взаимоисключающих директив, информация сложится. В результате гиперактивность. Я специально прописал в скилле сферы влияния и у меня нет подобного хаоса.
spirit1984
27.04.2026 17:18Прочел статью, впечатлился:
В моем проекте документация устроена слоями.
Набор слоев и того, что надо сделать, чтобы клод не унесло не в ту степь - внушает. В связи с недавними изменениями ценовых подписок и грядущей перспективой того, что Anthropic все-таки переведет большинство клиентов с request based на token based price, вопрос автору - нет ощущения, что с определенного момента работа в связке с клодом станет дороже, чем нанять реально человека? Ряд знакомых в самых разных компаниях уже отзываются примерно в таком стиле.
Dmitry21 Автор
27.04.2026 17:18есть такое чувство. особенно понимая, что потребление токенов сильно растет, а инфраструктура их генерации - нет
Format-X22
27.04.2026 17:18Меня наняли переписать с нуля финансовый софт, который был навайбкожен на питоне. Он был с большими затратами на оплату токенов, зарплату для вайбкодера и оплату серверов. В итоге оно сколлапсировало в черную дыру багов и его решили сжечь.
Зато теперь у меня есть работа, спасибо нейросетям за их вклад в мой доход. Чем больше вайбкодеров - тем лучше для меня, мне нравится, продолжайте.
d3d14
27.04.2026 17:18Тоже самое бывает с плохим ручным кодингом.
kovdmm
27.04.2026 17:18Конечно бывает, только оно не коллапсирует в чёрную дыру за несколько месяцев, а идёт (шло когда-то) к такому результату годами.
akod67
27.04.2026 17:18Вы не находите, что для бизнеса это всё равно громадный плюс, что он получил результат и пофиг как написанный так быстро? Бизнес проверил гипотезу и понял, что вот теперь имеет смысл инвестировать в грамотную разработку. А не похерил кучу денег в архитектурно-масштабируемое решение, что бы через год узнать, что оно нафиг никому не нужно. Считаю, что зла тут нет. Причём выигрывают все, разработчики в том числе. Обидно столько сил вкладывать в мертворождённый продукт, коих большинство.
SkillMax999
27.04.2026 17:18Хорошая статья. Я согласен с тем, что документация - это мастхэв для нормальной работы. И тезис некоторых "ну дока у нас лежит где-то в сторонке" теряет свою актуальность.
maxxant
27.04.2026 17:18У меня очень похожая ситуация, agent engineering только зарождается и всегда интересны чужие подходы. Нащупал для себя "перекрестное опыление" когда в пайплайне разные модели делают перекрестное ревью, сначала независимо, а потом читают чужие ревью и выносят общий вердикт с чем все соглашаются. Вроде похожее идея в moltbot но тут ключевое "пайплайн" для разных моделей и подходящих инструментов почти нет (я пробовал jrswab/axe). К слову sonnet & opus не всегда по умолчанию лучший выбор, иногда GPT сильнее в некоторых вещах (или его меньше заносит) при этом китайские kimi / mimo бывает находят существенные замечания которые claude/gpt изначально пропускают но соглашаются когда их тыкают носом.
SergeMNE
27.04.2026 17:18Согласен. Тоже опытным путем пришел к 3 решениям:
Использую мультимодельность при планировании и написании кода. СС планирует - Кодекс проверяет. СС пишет код - Кодекс оценивает результат.
Сделаны специальные скиллы по разработке и доработке. Если затрагивается более 3 файлов, то скилл код- ревью от Антропика обязателен ( это еще до внешнего аудита через Кодекс)
Для планирования и работы с кодом работать только через Serena MCP! Никаких встроенных инструментов
Dmitry21 Автор
27.04.2026 17:18а не происходит наслаивание глюков моделей?
SergeMNE
27.04.2026 17:18Если работать в эту сторону (СС пишет, Кодекс как аудитор кода), то нет. Более того, Кодекс всегда находит какие-то «косячки», с которыми СС соглашается, что это его промашки )
Но основное - это все-таки Серена. Вот это просто маст хэв! Да вам лучше спросить напрямую у СС о сравнении с Сиреной или без планировать и писать код
LeVoN_CCCP
27.04.2026 17:18Claude Code это инициативный junior с памятью золотой рыбки. 5 правил контроля для production
У меня тут небольшой когнитивный диссонанс. Один риторический вопрос - как можно пускать инициативного джуна с памятью золотой рыбки в прод (даже после контроля и перечтений)? Правило только одно и оно немного более расширенное от 4… Вообще мне чем-то напоминает 2007-2008, тогда было такое же отношение - берите/покупайте/нанимайте/делайте. Если у вас есть бюджет, то и потом скорее всего найдётся на тех, кто будет исправлять.
OhSirius
27.04.2026 17:18так и получается, что пытаются ограничить этого джуна, придумывая обвязку вокруг него. В итоге все-равно копится технический долг и еще когнитивный.
Dmitry21 Автор
27.04.2026 17:18Простой ответ - хайп и FOMO. Более сложный - ИТ, к сожалению, в большой степени дискредитировало себя, я имею в виду своеобразное отношение к пользователям, особенно в отделах внутренней автоматизации. Можно сказать проще - снобизм. Вижу в этом некоторую справедливость: мы много лет кривили бровь и показывали, что мы самые умные. Теперь бизнес отыгрывается, наивно думаю, что LLM что-то решит без нас. Отсюда столько воплей про "профессия программист умерла". Думаю, что как любой маятник, и этот скоро качнется в обратную сторону.
martelle
>постоянно управлять моделью, которая инициативно вносит изменения, на которые ее не просили
какая-то у вас неправильная клава.
p.s. статья на километр и даже не указано opus xxx, sonnet xxx или что это было и сколько лет назад?
p.p.s. а не слоп ли это всё?
>Если попросить «поправь баг в функции X», есть существенная вероятность, что заодно будут переименованы две переменные в соседнем модуле
ни разу не было
Вывод: сначала обвешаются всякими рюшками (CLAUDE.md, architecture.md, ecisions_log.md итд итп) потом страдают, что у gpt мозги набекрень
Dmitry21 Автор
подскажите, чтобы я правильно интерпретировал "сначала обвешаются", а вы что писали с llmкой? ну примерно так, чтобы масштаб понять?
jlllk
Значит не существует
martelle
>Значит не существует
зависимость настолько очевидна, что даже смешно это обсуждать.
некий
инфоцыганин не осилил агентыгендиректор курсов напихал в промт несколько килобайт инструкций, а потом плачет что клава делает нетипичные вещи.ниже в коментах уже отметился человек, который не загаживает промт и у него подобных явлений так же не возникает. ну, не хотите учиться, не учитесь, страдайте дальше.
Dmitry21 Автор
ну как неприлично, детский сад просто. вы с прошлой недели на Хабре, а я - с 13 года. Поверьте, таких как вы тут не любят.
haaji
поверьте надутых "я тут уже 13 лет на сайтике" не любят еще сильнее
amazingname
Тоже заметил. И тоже за полгода агентного кодинга не заметил такого поведения. Возникает вопрос - какая это модель и если хорошая, то может что то особенное есть в документации что мотивирует ее такое творить.
У меня скорее обратная проблема - модель по заданию расширяет логику, но оставляет имена и архитектуру как для старой логики.
Dmitry21 Автор
opus 4.6
amazingname
Тогда пусть будет несколько гипотез, почему слишком инициативный агент, в порядке убывания правдоподобия.
Специфическая архитектура с тестами, которая всегда кажется агенту стоящей доработки.
Что-то в описательных md, что агент каждый раз воспринимает как часть новой задачи а не как описание существующих решений.
У нас в проекте опус 4.6 через копилот. Может быть, в Claude Code есть какие вводные промпты повышающие инициативность, которых нет в других агентах.
Когда ставится задача, она сопровождается формальными требованиями делать хорошо и не делать плохо, на которые агент начинает слишком стараться.
Но все эти предположения это больше болтовня. Настоящего опыта у всех ещё мало. Все гадают как правильно работать, мне кажется.
Dmitry21 Автор
да, я согласен. более того - это вообще мой первый опыт. поэтому я не имею право на обобщения, просто описываю кейс и выводы на его основе. мне показалось любопытным то, что поведение Клода очень похоже на поведение моего джуна много лет назад, который только-только закончил ИУ5 Бауманки )
DarthVictor
Ну у меня было с нашими репозиториями поверх DynamoDB таблиц, пока шаблоны не положили в md-файлы. А пока схему проекта не прописали, так он и в базовый класс репозитория мог начать писать. И пофиг, что он может в двух сотнях таблиц использоваться. Любые вещи, специфичные для вашего проекта и нужные в разных местах этого проекта, как то структура библиотек, описание деплоя приходится описывать в md-файлах.