Comments 13
Ни примера получившегося кода/архитектуры/дизайна, ни описания проекта и его масштаба, ни высокоуровневого описания логики для определения ее сложности и развесистости, разумеется, снова не будет. У вас получилось, хорошо. Теперь можно узнать, ЧТО у вас получилось? У меня вчера получилось написать хеллоуворлд, нафантазировав себе, что этим зачем-то занимается команда агентов-программистов. А встроить небольшое изменение в реальный сервис на работе - как-то не получилось, руками вышло быстрее и качественнее.
Хотелось бы, чтобы писатель очередной, тысяча первой статьи про агентскую разработку, помнил, что программирование в целом - разное настолько, насколько может быть разной, к примеру, медицина, начинающаяся с прикладывания подорожника к ране и кончающаяся нейрохирургией. Советы по автоматизации разработки и выводы об их успешности не имеют практического смысла без ссылки на сложность решаемой задачи и её контекст.
К сожалению, проект над которым я работаю - под NDA. Я обязательно позже напишу более подробную статью на качественном проекте с открытым кодом. Но на это требуется намного больше времени и усилий. Так же полностью согласен: создать LLMDD проект с нуля намного проще, чем добавить что-то к существующему проекту. Я бы даже сказал так, что это - задача совсем другого уровня и, вполне возможно, тупиковая по своей сути.
Кто-то разве просит нарушать NDA ? Но разве сложно было запилить крошечный проект для этой статьи на Хабре? К тому же, руками писать код и не надо - "впахивают роботы". Глядишь, и люди поверили бы вам ))
Вы, кстати, можете приложить этот крошечный проект-пример дополнительно ;)
Проблема в том, что если это будет крошечный проект, то люди скажут: конечно, такой крошечный проект можно и одним промптом написать. Поэтому проект должен быть более-менее серьёзным. Хотя бы на 50К строк. А значит, он потребует где-то месяца разработки, что будет эквивалентно 3-м месяцам классической разработки командой. Быстрее и дешевле? Да, но всё равно это труд. И статью описывающую такую разработку тоже не получится быстро написать. Но я всё равно планирую сделать такое, как будет побольше свободного времени.
В какой момент, по-вашему, проект, написанный с нуля, переходит в разряд "существуюших"? В статье идет речь про итеративное добавление изменений к проекту - просится сказать, "к существующему проекту". Как тогда понять утверждение о том, что задача добавления чего-либо к существующему проекту - возможно тупиковая? Где проходит граница, и чем она, по вашей практике, определяется? Размер, покрытость тестами, объем и доступность исторических итеративных требований по изменениям? LLM изначально поддерживает архитектуру и дизайн проекта, подходящий для внесения изменений с её же помощью? Или что-то еще?
Под "существующими" проектами я имел в виду созданные с использованием других методологий и для которых предусматривается разработка людьми. LLM пишет посредственный некрасивый код, который придётся допиливать вручную, чтобы добавить в человеческую продкутовую кодовую базу. Если не покрыть имеющийся код множеством слоёв избыточных для человеческой разработки тестов, агент будет коммитить забагованные изменения ломающие всё подряд. Такие требования, ИМХО, делают взаимную разработку сложных проектов человеком и моделью нецелесообразными.
Естественно, проект созданный по LLMDD поддериваем как LLM, так и людьми (но это будет пытка для них). Притом, тесты показывают, что в принципе не важно какая модель используется. Claude Sonnet 3.5 и более совершенные модели могут быть применены в этой методике, но могут потребоваться различные донастройки и адаптации.
Спасибо за статью! Действительно интересно было бы посмотреть на готовый проекты и все промпты итераций.
По моему опыту, LLM лучше воспринимают промпты на англ (как язык на котором в основном выстраивались веса). Также по возможности надо стараться избегать негативных инструкций ("Я НИКОГДА НЕ ОТКЛЮЧАЮ ТЕСТЫ самостоятельно" -> "Я оставляю все тесты в их первоначальном состоянии и отключаю их только после требования пользователя").
Раньше язык запроса был важен, а сейчас я не замечаю разницы. Не русском я быстрее читаю, воспринимаю, и легче формулирую промпт. Но видно, что размышления у модели нередко происходят таки на английском. Негативные инструкции были добавлены самим Клодом (по моему запросу) после того как не сработали позитивные.
были добавлены самим Клодом (по моему запросу) после того как не сработали позитивные.
увы, он способен до бесконечности усложнять. Если что-то не работает в промпте, то стоит добавить пример, как обрабатывать эту ситуацию.
Да, у меня есть опыт решения такой проблемы. Если в цикле разработки (код, тесты, дебаг, фиксы) начинаются неприятные итерации:
Пофикшено, но снова поломано
Никак не получается получить требуемый результат
Раз за разом LLM считает, что поймала багу, но исправления не дают результатов
Нужно обратиться к нейронке как к человеку:
Спросить что может быть не так
Почему не получается то, что она пытается сделать
Что можно поменять, чтобы работать стало удобнее
LLM напоминает скромного исполнителя, который всегда готов делать то, что ему скажут, и редко предложит сделать что-то иначе. Но ответ на прямой запрос может весьма удивить своей продуманностью. Из него легко сделать план работ, следуя которому LLM сама себе поможет выбраться из болота.
По моему опыту, вот кому и нравится бесконечно усложнять — так это DeepSeek'у.
"Проверь тождественность двух if'ов", а на выходе: "вот 1-й.., вот 2-й.., а из 1-го следует.., вместе с тем во 2-м..." и начинается прямо рекурсия, очень забавно получается :)
Подход, безусловно, интересный, но насколько он универсальный? Когда у нас есть фронтэнд/бэкэнд, более-менее понятна логика взаимодействия между ними, и ИИ сможет справиться с написанием как функционала, так и тестов. Тут все упирается в степень формализованности постановки задач и критериев качества.
А можно ли использовать этот подход для написания, например, игр на Юнити или программы для управления роботом?
Агентное кодирование. Инструция по созданию надёжного программного продукта (LLMDD)