Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 19
На выходе получается отчёт с приоритетами: красное — критично, жёлтое — стоит поправить, зелёное — мелочи. Отдельно есть блок «что сделано хорошо». Я пробегаюсь по отчёту и решаю, что нужно чинить, а что не критично. Тем не менее ревьюить написанный код своими глазами тоже можно нужно.
Переименовать зелёный приоритет из "мелочи" в "проблема (соответствующий красный приоритет) решена"
Если приоритет "мелочи" не позволяют спать спокойно, то перейдите от светофор-палитры к четырех цветной, например, красно-желто-сине-зеленой (RYBG-палитре), как на майкрософтовском лейбле-флаге, отдав приоритету "синий" Ваши "мелочи", а не "зеленому".
Ещё один важный скилл в арсенале — systematic-debugging. Он срабатывает на любую ошибку, упавший тест или странное поведение агента. Скилл не даёт ИИ с разбегу влезть в код с фиксом, а заставляет пройти четыре фазы: корневая причина → анализ паттернов → гипотеза → реализация.
Странная цепочка фаз... А можете пример в двух...трёх словах, поскольку, по-логике, фаза "корневая причина" должна встать после "проверки гипотезы", а не в самом начале пищевой цепочки возникновения проблем(-ы)?
Спасибо за комментарий! Хорошее замечание про цвет, зеленый действительно может в заблуждение вводить, учтём!
Про systematic-debugging: на первом этапе размышлений происходит исследование проблемы и поиск корневой причины (читаются stack trace’ы, проверяются последние изменения и т.д.). Следующий этап - это про поиск решения: анализ похожих (но работающих корректно) паттернов в проекте. Потом уже тестируем гипотезы «причина + решение» и реализуем. Согласен, что в статье очень куцо описал процесс и формулировка вызывает вопросы.
По сути бесполезная статья - все знания элементарны и любым мало-мальски умным разработчиком активно используются уже несколько месяцев.
Узнал свой рабочий процесс, тот же подход, только чуть усовершенствованный: разведка -> спека -> план -> реализация, TDD, ревью только последних изменений и отдельный шаг, где агент обязан доказать, что всё работает, а не просто сказать - я сделаль. До разведки дошел сам, иногда в общем и целом знаю, что должна делать фича, но подобрать компоненты, либы и тд не могу, тут мы с клодом делаем миниресерч по тому что подходит, у кого и как реализовано, и из этого меню я уже выбираю.
Один момент про оркестратор и правило «есть 1% шанс - вызови скилл». Вариант конечно, но это ведь снова инструкция для модели, а её модель так же стабильно забывает, как и само описание скилов. У меня часть таких правил исполняет не модель, а хук на старте сессии, который сам подгружает нужное и проверка на pre-commit/CI.
И отдельно про update-claude-md - боль знакомая, доки правда тухнут. Но автосверка через ещё один проход LLM сама по себе ненадёжна, что-то поправит, что-то забудет. Написал простой линтер на js, проверяет, что пути в CLAUDE.md существуют, команды валидны, ссылки не побиты.
ЗЫ С предидущим коментом не согласен, большинство вообще забивает на элементарные настройки клод кода, будут такие статьи может кто-то задумается)
если сперва реализация а позже TDD, то это уже не тдд, или вы имели ввиду что то другое, например реализацию через TDD?
Спасибо большое за комментарий!
Разведка действительно может быть полезна на какой-то не самой тривиальной задаче. Классная идея, подумаю над добавлением! Если научить агента на этом этапе еще по корпоративной системе контроля версий побегать - вообще пушка будет :)
Да, хук понадежнее будет, согласен. У меня на моделях Антропиков работает пока неплохо. Надо бы на чем-то послабее потестировать мне и доработать.
Согласен про линтер, но вот новый функционал например он не опишет. Так что тут, думаю, самое правильное - и линтер, и LLM, и делать это почаще!
Кафедра велосипедостроения весьма многолюдна. Благо сами принципы довольно просты, и каждый второй лепит свой `фреймворк`, подсмотрев идеи у всяких superpowers и spec kit. Это вообще без упрёка, если что.
Спасибо за комментарий! Да! Именно такую идею и хотелось донести в статье: пока у нас не появился индустриальный стандарт, выбираем то, что удобно. И частенько нам удобен наш велик:)
А я хотел рассказал, как мой фреймворк хорошие идеи и принципы реализует. Возможно это поможет кому-то своё решение написать, адаптированное конкретно под его задачи.
Сейчас все так быстро меняется что "полгода назад" это уже жутко давно, в трех поколениях назад. Qwen 3.5 plus еще пару месяцев назад был тупой как валенок, 3.7 max сегодня уже вполне ничего. У меня нет подписок на claude и gpt а через api они дорогие, так что только периодически, после выхода 3.7 пользуюсь на 95% qwen. И ревью лучше делать в другой нейросети, сами себя сильно хуже проверяют. Я обычно закидываю в deepseek. Писать он непригоден но ошибки за другими искать - вполне неплох. После его проверок и замечаний руками мало что приходится делать. Иногда Gemini привлекаю, для финального обзора и вердикта. В целом пока получается нормально.
Стандарта действительно нет, и каждый пилит свой велосипед. У меня вообще есть ИИ фреймворк для создания ИИ фреймворков :) потому что пет и продакшн проекты на разных стеках и вот это вот всё. Так что правильной дорогой идёте, товарищ!
Единственное, я бы советовал всё же больше субагентов. Они как раз и нужны, чтобы экономить контекст, и делать этапы максимально изолированными. Конда один агент пишет тест, второй никак не подстроится, чтобы код был зелёным :)
Скажите, пожалуйста, а чем принципиально «пушить в гит только руками» отличается от «агент делает ПР, человек делает ревью»? Нутром чую, что разница в процессах есть и важная, но опыта не хватает сформулировать и осознать.
Это моё личное недоверие к LLM и желание ограничить её влияние на инфраструктуру. Имею ввиду доступы на редактирование чего-либо дальше, чем файлы на моём компьютере (в том числе write операции в удаленную систему контроля версий).
Сложилось у меня такое отношение после ряда увиденных мной аварий, виновником которых были ошибки LLM :(
Расскажу небольшую историю про конкретно git. У нас в компании есть корпоративный GitLab. Одним прекрасным днём я вижу сообщение, что меня тегнули в каком-то PR’е и, зайдя в него, обнаруживаю, что тегнули в нем еще кучу других людей, не относящихся к изменениям (потом выяснилось, что так решил кодинговый агент). Ажиотаж в том PR’е образовался такой, что это повлекло проблемы с доступностью GitLab. Было смешно и страшно одновременно!
Возможно моя позиция - это паранойя.. Также не отрицаю, что когда-нибудь LLM вполне могут вернуть моё доверие!
Я одного не пойму - Claude Code не запоминает предыдущие сессии? Каждый раз начинает сессию с нуля?
Да, всё так. Каждая новая сессия запускается в новом контекстном окне и ничего не знает о предыдущих сессиях. Но есть механизмы наделения агента памятью, о них в статье написал (не обо всех), более широкую информацию можно посмотреть в документации claude code: https://code.claude.com/docs/en/memory.
Вы не упомянули openspec. На мой взгляд, он как раз адресует часть проблем которые вы пытаетесь решить своим фреймворком
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как я прошёл путь от «сам быстрее напишу» до своего фреймворка для агентной разработки