Хабр Курсы для менеджеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Менеджмент доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 51
>постоянно управлять моделью, которая инициативно вносит изменения, на которые ее не просили
какая-то у вас неправильная клава.
p.s. статья на километр и даже не указано opus xxx, sonnet xxx или что это было и сколько лет назад?
p.p.s. а не слоп ли это всё?
>Если попросить «поправь баг в функции X», есть существенная вероятность, что заодно будут переименованы две переменные в соседнем модуле
ни разу не было
Вывод: сначала обвешаются всякими рюшками (CLAUDE.md, architecture.md, ecisions_log.md итд итп) потом страдают, что у gpt мозги набекрень
подскажите, чтобы я правильно интерпретировал "сначала обвешаются", а вы что писали с llmкой? ну примерно так, чтобы масштаб понять?
ни разу не было
Значит не существует
>Значит не существует
зависимость настолько очевидна, что даже смешно это обсуждать.
некий инфоцыганин не осилил агентыгендиректор курсов напихал в промт несколько килобайт инструкций, а потом плачет что клава делает нетипичные вещи.
ниже в коментах уже отметился человек, который не загаживает промт и у него подобных явлений так же не возникает. ну, не хотите учиться, не учитесь, страдайте дальше.
Тоже заметил. И тоже за полгода агентного кодинга не заметил такого поведения. Возникает вопрос - какая это модель и если хорошая, то может что то особенное есть в документации что мотивирует ее такое творить.
У меня скорее обратная проблема - модель по заданию расширяет логику, но оставляет имена и архитектуру как для старой логики.
opus 4.6
Тогда пусть будет несколько гипотез, почему слишком инициативный агент, в порядке убывания правдоподобия.
Специфическая архитектура с тестами, которая всегда кажется агенту стоящей доработки.
Что-то в описательных md, что агент каждый раз воспринимает как часть новой задачи а не как описание существующих решений.
У нас в проекте опус 4.6 через копилот. Может быть, в Claude Code есть какие вводные промпты повышающие инициативность, которых нет в других агентах.
Когда ставится задача, она сопровождается формальными требованиями делать хорошо и не делать плохо, на которые агент начинает слишком стараться.
Но все эти предположения это больше болтовня. Настоящего опыта у всех ещё мало. Все гадают как правильно работать, мне кажется.
Ну у меня было с нашими репозиториями поверх DynamoDB таблиц, пока шаблоны не положили в md-файлы. А пока схему проекта не прописали, так он и в базовый класс репозитория мог начать писать. И пофиг, что он может в двух сотнях таблиц использоваться. Любые вещи, специфичные для вашего проекта и нужные в разных местах этого проекта, как то структура библиотек, описание деплоя приходится описывать в md-файлах.
Где вы джунов такого уровня берёте, поделитесь секретом? Ни разу таких не видел.
Раз в десять лет встречаются у меня. Они редкие... И их так просто не "взять", или повезёт, или нет
я в свое время их промышленно выращивал из студентов технических вузов
клава на тактическом уровне уже давно синьёр. видит и сама репортит edge-case-ы, находит баги в concurrency и всё такое.
вы там на мой вопрос о вашем опыте не ответили. соблаговолите, все же. а то уж больно круты, больно матеры
У меня прямо такие же выводы напрашиваются. Только что закончил средних размеров проект с claude code. Да, у меня есть скилы, иногда, особенно в начале, я много смотрел что он делает, но потом все скатилось в автоапрув. В итоге, ближе к релизу, просто куча багов: фиксим в одном месте, ломается два других, все по классике. Сейчас попросил claude code провести анализ логов задач и комитов (у меня claude коротко логирует свои действия чтобы можно было начать новую сессию и продолжить там где остановился) и один из выводов то же что и автора: тесты писались под код. Короче статье точно плюс
Впечатления близкие, тоже читаю всю логику пока не пойму, но пишу без юнит тестов, только с интеграционными, потому что так мне не надо заранее знать архитектуру, не надо ревьювать ещё и тесты.
А ещё пользуюсь почти чистым контекстом с минимальным md и не замечал чтобы агенту сильно сложно было въехать в код с нуля. Несколько минут анализа и обычно он уже знает все что нужно.
Кроме того, перед ревью прогоняю десяток заранее заготовленных промптов для улучшения кода - лишние логи, лишние проверки, смешение уровней абстракции и прочий рефакторинг. Но пока недостаточно опыта для уверенности что все это оптимальный путь.
с промптами интересно, можете поделиться?
Это прямо очень интимный вопрос.
Скрытый текст
Проанализируй все текущие незакоммиченные изменения по проектам (git diff HEAD) исключая проекты тестов. Вот текст постановки задачи по которой сформирован этот diff: … Проанализируй логику кода и составь список решений, которые не были в явном виде сформулированы в постановке задачи и приняты дополнительно при реализации. Возможно эти решения требуют обсуждения и корректировки.
Проанализируй все текущие… Проанализируй код на наличие параллельных решений, которые решают одну и ту же по сути задачу различным образом. Эти решения могут быть вынужденными, обсусловлены особенностями архитектуры или фреймворков. В любом случае опиши подобные особенности кода, чтобы обсудить возможность рефакторинга.
Проанализируй все текущие… При доработке часть функций (новых или ранее существующих) кода могли утратить свое исходное значение. Такие функции возможно нужно срефакторить или переименовать. Дай список таких возможных мест для рефакторинга.
Проанализируй все текущие… Новый код может содержать функции или блоки кода, могут быть вынесены в хелперы. Проанализируй код проекта: возможно подобные хелперы уже реализованы и ты можешь их переиспользовать. Дай список таких возможных мест для рефакторинга.
Проанализируй все текущие… Новый код может содержать захардкоженные магические значения, которые либо уже есть в константах в другом коде, либо могут быть вынесены в константы. Дай список таких возможных мест для рефакторинга.
Проанализируй все текущие… Новые классы могут быть размещены в существующих папках, назначение которых не совсем соответствует функциям этих классов. Проанализируй структуру папок проекта и размещение новых классов. Дай список таких возможных мест для рефакторинга.
Проанализируй все текущие… Новый код может содержать излишние подстраховки отсутствия или несоответствия данных. Удали проверки для случаев, когда логика кода такова, что проверяется условие которое никогда не случается.
Проанализируй все текущие… Код может содержать излишние FallBack на запасную логику при отсутствии данных или несоответствии данных текущей логике. Как правило подобные FallBack не нужны. Дай список таких возможных мест для исправления.
Проанализируй все текущие… Опциональные параметры некоторых функций на самом деле могут передаваться всегда, согласно текущей логике программы. Дай список таких возможных мест для исправления.
Проанализируй все текущие… Некоторые комментарии могут быть избыточными, если их смысл дублироуется в названиях функций. Удали такие комментарии.
Проанализируй все текущие… Некоторые комментарии могут отражать не текущую работу кода а как было раньше и как стало сейчас. Комментарии должны отражать только текущее состояние кода. Удали или поправь такие комментарии.
Проанализируй все текущие… В некоторых функциях, где логика разворачивается в коде последовательно, она может плохо секционироваться в коде или явно хорошо изолированные задачи не вынесены в отдельную фукнцию. Например, шаги одной задачи чередуются с шагами другой независимой задачи. Предложи список возможных мест для улучшения.
Проанализируй все текущие… В некоторых случаях локальные приватные переменные в классах могут быть созданы избыточно, там где проще было бы передать эти значения параметром в одну или максимум две приватные функции. Предложи список возможных мест для улучшения кода.
Проанализируй все текущие… В некоторых случаях в объекты могли быть добавлены поля, которые читаются потому что они есть в источнике, но затем никогда не используются. Предложи список возможных мест для удаления созданных “про запас” полей.
Проанализируй все текущие… В некоторых случаях в новом коде может встречаться смешивание уровней абстракции, усложняющее понимание кода. Например, в цикле или в последовательности действий выполняются некоие общие функции но одновременно в цикл или последовательность вставляется код с более низким уровнем абстракции, оперириующий деталями, или код который выполяет отдельную задачу и мог бы быть выполнен позже или раньше.
Проанализируй все текущие… В некоторых случаях новый код недостаточно выразительно отражает смысл происходящего. Т.е. технически переменные и условия верные, но архитекрута кода не отражает основые ключевые выбираемые варианты и пути обработки. Если код решает некую задачу и имеет ветвления, то эти ветвления и подзадачи должны быть более очевидными. Например, отражаться в названиях функций, избегать смешения уровней абстракции и др. Предложи список возможных мест для рефакторинга.
спасибо
Офигенный набор проверок чтобы в пятницу вечером запустить, а в понедельник прийти к созданному MRу и код в проекте станет чуть лучше.
А "минимальный набор инструкций" это какой если не секрет?
Не, это же применяется к дифу в продукте. Он по определению не сильно большой и имеет специфические проблемы. Так что каждая инструкция минуты на две для агента и минут 15 для осмысления и подтверждения правок.
Но вообще этот набор очень сырой. Надо пару месяцев ещё чтобы его отточить под любой код.
А "минимальный набор инструкций" это какой если не секрет?
Может строк 20 текста. О чем приложение, что оно делает, пару не очевидных из кода нюансов, типа как мигрируется база.
Раз уж тут такая тема "неожиданная" обсуждается, может ли кто своим опытом по использованию obra/superpowers и graphify.net поделиться?
Промышленная разработка с агентами странная - тонны документации, чтобы контролировать кодогенерацию. По сути нам нужно описать все решения своим языком в надежде, что получится создать лаконичную и точную спецификацию.
Это мой стек 3 месяца назад. Только чуть другой - главное правило - не плодить мусор. Клоауд после сессии обязательно захочет еще написать отчет о сессии и отчет об отчёте сессии. Сейчас полностью переехал в посгресс и всем советую. Заведите бд, возьмите хороший просморщик, организуйте тикеты, таблицу с тестами, базу знаний. ОБЯЗАТЕЛЬНО ПОДКЛЮЧИТЕ GITNEXUS !
Я пишу архитектурные документы, в них BDD таблица с чекбоксами критериев успеха, чёткая структура, тикеты. Далее тикеты забирается агентами кодерами и по критериям успеха строят тесты и уже от этих тестов пишут код. Поэтому тоже переходите на BDD - клауд расскажет что это и как использовать
Мне кажется проблема подобного поведения как раз избыточность инструкций. Если нет разграничения сферы влияния всех этих md, то они и накладываются. Если внутри сессии будет прочитано несколько md, то, если нет взаимоисключающих директив, информация сложится. В результате гиперактивность. Я специально прописал в скилле сферы влияния и у меня нет подобного хаоса.
Прочел статью, впечатлился:
В моем проекте документация устроена слоями.
Набор слоев и того, что надо сделать, чтобы клод не унесло не в ту степь - внушает. В связи с недавними изменениями ценовых подписок и грядущей перспективой того, что Anthropic все-таки переведет большинство клиентов с request based на token based price, вопрос автору - нет ощущения, что с определенного момента работа в связке с клодом станет дороже, чем нанять реально человека? Ряд знакомых в самых разных компаниях уже отзываются примерно в таком стиле.
Меня наняли переписать с нуля финансовый софт, который был навайбкожен на питоне. Он был с большими затратами на оплату токенов, зарплату для вайбкодера и оплату серверов. В итоге оно сколлапсировало в черную дыру багов и его решили сжечь.
Зато теперь у меня есть работа, спасибо нейросетям за их вклад в мой доход. Чем больше вайбкодеров - тем лучше для меня, мне нравится, продолжайте.
Тоже самое бывает с плохим ручным кодингом.
Конечно бывает, только оно не коллапсирует в чёрную дыру за несколько месяцев, а идёт (шло когда-то) к такому результату годами.
Вы не находите, что для бизнеса это всё равно громадный плюс, что он получил результат и пофиг как написанный так быстро? Бизнес проверил гипотезу и понял, что вот теперь имеет смысл инвестировать в грамотную разработку. А не похерил кучу денег в архитектурно-масштабируемое решение, что бы через год узнать, что оно нафиг никому не нужно. Считаю, что зла тут нет. Причём выигрывают все, разработчики в том числе. Обидно столько сил вкладывать в мертворождённый продукт, коих большинство.
Хорошая статья. Я согласен с тем, что документация - это мастхэв для нормальной работы. И тезис некоторых "ну дока у нас лежит где-то в сторонке" теряет свою актуальность.
У меня очень похожая ситуация, agent engineering только зарождается и всегда интересны чужие подходы. Нащупал для себя "перекрестное опыление" когда в пайплайне разные модели делают перекрестное ревью, сначала независимо, а потом читают чужие ревью и выносят общий вердикт с чем все соглашаются. Вроде похожее идея в moltbot но тут ключевое "пайплайн" для разных моделей и подходящих инструментов почти нет (я пробовал jrswab/axe). К слову sonnet & opus не всегда по умолчанию лучший выбор, иногда GPT сильнее в некоторых вещах (или его меньше заносит) при этом китайские kimi / mimo бывает находят существенные замечания которые claude/gpt изначально пропускают но соглашаются когда их тыкают носом.
Согласен. Тоже опытным путем пришел к 3 решениям:
Использую мультимодельность при планировании и написании кода. СС планирует - Кодекс проверяет. СС пишет код - Кодекс оценивает результат.
Сделаны специальные скиллы по разработке и доработке. Если затрагивается более 3 файлов, то скилл код- ревью от Антропика обязателен ( это еще до внешнего аудита через Кодекс)
Для планирования и работы с кодом работать только через Serena MCP! Никаких встроенных инструментов
а не происходит наслаивание глюков моделей?
Если работать в эту сторону (СС пишет, Кодекс как аудитор кода), то нет. Более того, Кодекс всегда находит какие-то «косячки», с которыми СС соглашается, что это его промашки )
Но основное - это все-таки Серена. Вот это просто маст хэв! Да вам лучше спросить напрямую у СС о сравнении с Сиреной или без планировать и писать код
Claude Code это инициативный junior с памятью золотой рыбки. 5 правил контроля для production
У меня тут небольшой когнитивный диссонанс. Один риторический вопрос - как можно пускать инициативного джуна с памятью золотой рыбки в прод (даже после контроля и перечтений)? Правило только одно и оно немного более расширенное от 4… Вообще мне чем-то напоминает 2007-2008, тогда было такое же отношение - берите/покупайте/нанимайте/делайте. Если у вас есть бюджет, то и потом скорее всего найдётся на тех, кто будет исправлять.
так и получается, что пытаются ограничить этого джуна, придумывая обвязку вокруг него. В итоге все-равно копится технический долг и еще когнитивный.
Простой ответ - хайп и FOMO. Более сложный - ИТ, к сожалению, в большой степени дискредитировало себя, я имею в виду своеобразное отношение к пользователям, особенно в отделах внутренней автоматизации. Можно сказать проще - снобизм. Вижу в этом некоторую справедливость: мы много лет кривили бровь и показывали, что мы самые умные. Теперь бизнес отыгрывается, наивно думаю, что LLM что-то решит без нас. Отсюда столько воплей про "профессия программист умерла". Думаю, что как любой маятник, и этот скоро качнется в обратную сторону.
Claude Code это ваше зеркало. Если вы - инициативный Junior с памятью золотой рыбки, то и Claude Code тоже.
Ваша ллм наговнокодила вам в текст двумя тезисами про “пять правил контроля” на разные лады, и вам она как раз.
С общим посылом статьи: точные инструкции + постоянный контроль – согласен полностью:
LLM не делает junior’а senior’ом. Он просто позволяет тому, кто уже умеет, делать быстрее.
Да, как-то так. Это инструмент для тех, кто уже обладает серьёзными навыками проектирования. Для джуна, подозреваю, он будет скорее вреден, чем полезен.
Но есть нюансы. В частности:
и в ноль не помнит, что вы обсуждали в предыдущей сессии
Это не так. Он сохраняет историю работы с проектом в `~/.claude/projects/<project path>` и прекрасно помнит, что было не то, что в прошлой сессии – а вообще всё. Иногда удивляюсь даже, насколько уместно он напоминает о предыдущих решениях.
В моем проекте 814 unit-тестов, каждый написан до соответствующего кода.
Вот тут его приходится даже притормаживать – иначе он запускает тесты ещё не созданных модулей и радостно рапортует: О! Упало, так и должно быть! Что, разумеется, ничего не говорит о качестве кода – чисто перевод токенов. Я это явно запрещаю – причём иногда он об этом запрете "забывает", приходится напоминать.
"Анализ цен и продуктов конкурентов" - прикольный self-used продукт. Я пару недель назад делал исследование, можно ли сделать сервис по мониторингу цен на маркетплейсах для конечного покупателя, оказалось, что там красный океан; покрутил другие сегменты (закупщики, например), тоже не увидел рынка.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Claude Code это инициативный junior с памятью золотой рыбки. 5 правил контроля для production