Comments 7
Тут есть несколько моментов.
У тебя напрочь упущен нюанс, который превратит более или менее сложный проект в фарш из повторяющихся файлов со схожими функциями, осиротевшими кусками и неиспользуемыми функциями. Это петля обратной связи на тесты и жесткое, распланированное ТЗ.
LLM - это туповатый, но очень начитанный агент, страдающий диким СДВГ. Как только ты отпустил контроль или допустил малейшую потерю жесткости задачи, он уже вкорячил внезапно тебе на прод какие-то сертификаты и ушел писать письмо в Google, чтобы они API починили.
Твоя конституция агента в виде claude.md так же превратится в бесконтрольный и внутренне противоречивый фарш крайне быстро. Агенты очень плохо умеют в консистентность в масштабе большой комплексной системы.
Более правильный флоу такой:
1. Проработка с LLM проекта до мельчайших подробностей и создание спецификации.
2. По ней нарезается 10-20 атомарных простых задач равной сложности для LLM в виде промптов.
3. По списку промптов-задач нарезается todo-лист, где агент будет отмечать свой прогресс, чтобы не делать дважды одно и то же.
4. Каждый атомарный промпт в обязательном порядке как можно быстрее заворачивается на формальные тесты, которые заставляют агента переписывать до тех пор, пока не будет строго соблюдено ТЗ и не будут пройдены тесты. Test Driven Development - твой лучший друг.
Короче, на простых вещах взлетит, но там такой фарш будет, что будет проще сжечь, чем поддерживать. Заставляй LLM писать задачи для LLM. Они это сделают лучше.
Я постоянно сталкиваюсь со скепсисом относительно самой возможности создания качественного программного продукта при помощи LLM, а когда говорю, что я создаю приложения даже не глядя в код, мне просто не верят.
Я и не поверю. Точнее, я поверю, что вы создаете приложения таким образом. Однако эти приложения либо ну очень простые, либо они представляют портянки кода, которые будет вскорости нереально поддерживать и устанавливать.
Спасибо, записал себе инсайты!
Прочитал пост. Методика интересная, но она вызывает много вопросов о практической стороне и реальных ограничениях. Хотелось бы обсудить эти подводные камни.
Когнитивная нагрузка. Первое, что бросается в глаза - ты меняешь одну сложную задачу (написание кода) на другую, возможно, еще более сложную (постоянный надзор за LLM). Нужно держать в голове весь контекст диалога, следить, чтобы модель не «уплыла», и вручную ее корректировать. Не получается ли так, что это утомляет даже больше, чем просто сесть и написать код самому?
Отладка «черного ящика». Второй момент - отладка. Рано или поздно LLM будет клясться, что всё готово, а код будет падать или содержать скрытые баги. Все равно ведь придется лезть в сгенерированный код, который ты не писал. Насколько тяжело дебажить такую систему, особенно если логика у машины получилась запутанная и нечеловеческая?
Потолок сложности. И третье - границы применимости. Твой пример с деплоем - понятная, изолированная задача. А что насчет более глубоких вещей, вроде рефакторинга ядра системы, который затрагивает десятки взаимосвязанных файлов? Или оптимизации производительности, где важна каждая мелочь? Есть сильное ощущение, что на таких задачах этот подход просто развалится, и агент утонет в контексте. Пробовал уже что-то подобное?
Пока это выглядит как очень мощный инструмент для решения стандартных или хорошо изолированных задач, но есть большие сомнения в его применимости для долгосрочной разработки сложной бизнес-логики. Интересно было бы услышать твое мнение именно по этим узким местам.
Очень хорошие вопросы, спасибо!
Когнитивная нагрузка резко снижается. Больше не нужно быть постоянно в контексте и даже в потоке для того, чтобы решать проблемы. Я сделал хук в claude code, чтобы он мне присылал нотис, когда консоль закончила работать. Я смотрю не весь лог, а только заключение, которое пишет ИИ. По этому заключению выбираю какой из двух шаблонов нужно отправить следующим и в редких случаях замечаю, что что-то пошло не так и поправляю агента. Всё это позволяет не только не вникать в то, как, к примеру, устроен webrtc, а просто проверять, работает ли трансляция в итоге или нет. Так же это позволяет вести несколько проектов одновременно, или решать параллельно несколько задач на одном проекте.
Отладка «черного ящика» - сейчас мой подход кажется радикальным, так же как и когда-то казалось радикальным полагаться на компилятор не разбираясь в том машинном коде, который он создаёт. Да, модели далеки от совершенства и методики ещё не отработаны, но пока что на проектах средней сложности мне удаётся удерживать систему в стабильном состоянии без необходимости править код. Можно очень много написать на эту тему, но самое главное - TDD на каждый чих. Рано или поздно баги кончаются, а тесты не допускают регрессий.
Потолок сложности. Действительно, современные модели не способны охватить крупные кодовые базы с хитрыми взаимосвязями, особенно если код был создан людьми более умными, чем модель, или требует каких-то специальных знаний. Для достижения успеха я вынужден ограничиваться инструментами, которые хорошо описаны в сети миллионами примеров. Я использую go, ts, react, postgres. Что-то нетипизированное или не достаточно популярное - прямой путь к провалу для хоть сколько либо серьёзного проекта.
И, наверное, самое главное ограничение: мою методику нельзя использовать в проектах, где работают другие программисты потому как нейронка создаёт код не самого лучшего качества и без уважения относится к написанному человеком. Зато при помощи агентов можно одному разрабатывать в кратчайшие сроки продукты, которые в противном случае требуют много месяцев усилий согласованной команды.
Тут есть несколько моментов.
У тебя напрочь упущен нюанс, который превратит более или менее сложный проект в фарш из повторяющихся файлов со схожими функциями, осиротевшими кусками и неиспользуемыми функциями. Это петля обратной связи на тесты и жесткое, распланированное ТЗ.
LLM - это туповатый, но очень начитанный агент, страдающий диким СДВГ. Как только ты отпустил контроль или допустил малейшую потерю жесткости задачи, он уже вкорячил внезапно тебе на прод какие-то сертификаты и ушел писать письмо в Google, чтобы они API починили.
Твоя конституция агента в виде claude.md так же превратится в бесконтрольный и внутренне противоречивый фарш крайне быстро. Агенты очень плохо умеют в консистентность в масштабе большой комплексной системы.
Более правильный флоу такой:
1. Проработка с LLM проекта до мельчайших подробностей и создание спецификации.
2. По ней нарезается 10-20 атомарных простых задач равной сложности для LLM в виде промптов.
3. По списку промптов-задач нарезается todo-лист, где агент будет отмечать свой прогресс, чтобы не делать дважды одно и то же.
4. Каждый атомарный промпт в обязательном порядке как можно быстрее заворачивается на формальные тесты, которые заставляют агента переписывать до тех пор, пока не будет строго соблюдено ТЗ и не будут пройдены тесты. Test Driven Development - твой лучший друг.
Короче, на простых вещах взлетит, но там такой фарш будет, что будет проще сжечь, чем поддерживать. Заставляй LLM писать задачи для LLM. Они это сделают лучше.
Очень хорошее замечание, спасибо! Действительно, одной только базовой методики для достижения 100% успеха мало. Мало того, именно предложенный вами флоу я и пытался использовать по началу. Но с ним получились свои проблемы. Возможно, он хорош когда человек, как архитектор и программист отлично владеет всей необходимой областью знаний. Тогда не проблема при планировании заметить все косяки и неточности в составленной LLM доке. Но, к сожалению, такое ограничение крайне сужает возможную область использование агентов. И я уже не смогу сделать андроид-приложение с аудиостримингом, если не разбираюсь хотя бы в одном из этих вопросов.
Я нашёл что более эффективно при ограниченности знаний человека составлять примерный документ с этапами разработки и прорабатывать каждый этап по мере развития проекта. Но не это главное. Для защиты чистоты кода я использую такой подход:
Требую от модели:
Создать архитектурные ADR (Architecture Decision Records) в docs/architecture/decisions/
Добавить диаграммы компонентов и data flow
Документировать каждый критический path (authentication, deposits, withdrawals)
Говорю агенту основываясь на составленных документах тщательно провести аудит кода. Таким образом он находит случаи дублирования, кривой логики, расхождения с архитектурным планом и т.п.
Не только использую широчайший набор линтеров, но и создаю при помощи агента специальные программные инструменты, заточенные на особенности конкретного проекта, позволяющие добиться и поддерживать высокое качество кода
Это лишь несколько основных пунктов. Я использую ещё множество других методик. Но они все пока что недостаточно устоялись в моей голове, чтобы я мог написать статью о них.
Ещё помогает при обнаружении неправильного поведения, особенно когда не совсем понятны ее мотивы - просить оценит саму себя и внести коррективы в системные инструкции, чтобы в будущем избегать такого поведения. Это лучше, чем самому вникать во все тонкости
Основы успешного агентного кодинга (LLMDD)