В целом да, до истинного вайб-кодинга в стиле: "Напиши мне операционную систему" - как до управляемого термоядерного синтеза. Но всё же, ИМХО, стоит попробовать уже сейчас. Если откладывали реализацию какого-то небольшого собственного проекта из-за недостатка времени или мотивации - может быть, это именно тот инструмент которого вам не хватало. Алсо, Breaking News! Гугл выкатил свою консольную кодерку совершенно бесплатно: https://github.com/google-gemini/gemini-cli - собираюсь сегодня потестить, но по описанию, должно быть не хуже Клода за 200 баксов.
Вот, я как раз в качестве проекта для следующей статьи, рассказывающий о подходе уже на конкретном примере, хотел взять идею не сложной игры. Правда, я хочу использовать go + Ebitengine, ибо статическая типизация и компилятор. Насчёт Юнити - не знаю, никогда его не использовал.
Да, у меня есть опыт решения такой проблемы. Если в цикле разработки (код, тесты, дебаг, фиксы) начинаются неприятные итерации:
Пофикшено, но снова поломано
Никак не получается получить требуемый результат
Раз за разом LLM считает, что поймала багу, но исправления не дают результатов
Нужно обратиться к нейронке как к человеку:
Спросить что может быть не так
Почему не получается то, что она пытается сделать
Что можно поменять, чтобы работать стало удобнее
LLM напоминает скромного исполнителя, который всегда готов делать то, что ему скажут, и редко предложит сделать что-то иначе. Но ответ на прямой запрос может весьма удивить своей продуманностью. Из него легко сделать план работ, следуя которому LLM сама себе поможет выбраться из болота.
Раньше язык запроса был важен, а сейчас я не замечаю разницы. Не русском я быстрее читаю, воспринимаю, и легче формулирую промпт. Но видно, что размышления у модели нередко происходят таки на английском. Негативные инструкции были добавлены самим Клодом (по моему запросу) после того как не сработали позитивные.
Под "существующими" проектами я имел в виду созданные с использованием других методологий и для которых предусматривается разработка людьми. LLM пишет посредственный некрасивый код, который придётся допиливать вручную, чтобы добавить в человеческую продкутовую кодовую базу. Если не покрыть имеющийся код множеством слоёв избыточных для человеческой разработки тестов, агент будет коммитить забагованные изменения ломающие всё подряд. Такие требования, ИМХО, делают взаимную разработку сложных проектов человеком и моделью нецелесообразными.
Естественно, проект созданный по LLMDD поддериваем как LLM, так и людьми (но это будет пытка для них). Притом, тесты показывают, что в принципе не важно какая модель используется. Claude Sonnet 3.5 и более совершенные модели могут быть применены в этой методике, но могут потребоваться различные донастройки и адаптации.
Проблема в том, что если это будет крошечный проект, то люди скажут: конечно, такой крошечный проект можно и одним промптом написать. Поэтому проект должен быть более-менее серьёзным. Хотя бы на 50К строк. А значит, он потребует где-то месяца разработки, что будет эквивалентно 3-м месяцам классической разработки командой. Быстрее и дешевле? Да, но всё равно это труд. И статью описывающую такую разработку тоже не получится быстро написать. Но я всё равно планирую сделать такое, как будет побольше свободного времени.
К сожалению, проект над которым я работаю - под NDA. Я обязательно позже напишу более подробную статью на качественном проекте с открытым кодом. Но на это требуется намного больше времени и усилий. Так же полностью согласен: создать LLMDD проект с нуля намного проще, чем добавить что-то к существующему проекту. Я бы даже сказал так, что это - задача совсем другого уровня и, вполне возможно, тупиковая по своей сути.
Я бы перевёл это как "Слепой режим" или "Командный режим".
Пользы очень много. Особенно в прототипировании. Очень помогает в работе с проектными документами и вообще любой документацией. Вообще, надо переключать работу на AI-First. Сейчас кажется, что LLM внесёт в программирование изменения подобные изобретению компиляторов.
В целом да, до истинного вайб-кодинга в стиле: "Напиши мне операционную систему" - как до управляемого термоядерного синтеза. Но всё же, ИМХО, стоит попробовать уже сейчас. Если откладывали реализацию какого-то небольшого собственного проекта из-за недостатка времени или мотивации - может быть, это именно тот инструмент которого вам не хватало. Алсо, Breaking News! Гугл выкатил свою консольную кодерку совершенно бесплатно: https://github.com/google-gemini/gemini-cli - собираюсь сегодня потестить, но по описанию, должно быть не хуже Клода за 200 баксов.
Вот, я как раз в качестве проекта для следующей статьи, рассказывающий о подходе уже на конкретном примере, хотел взять идею не сложной игры. Правда, я хочу использовать go + Ebitengine, ибо статическая типизация и компилятор. Насчёт Юнити - не знаю, никогда его не использовал.
Да, у меня есть опыт решения такой проблемы. Если в цикле разработки (код, тесты, дебаг, фиксы) начинаются неприятные итерации:
Пофикшено, но снова поломано
Никак не получается получить требуемый результат
Раз за разом LLM считает, что поймала багу, но исправления не дают результатов
Нужно обратиться к нейронке как к человеку:
Спросить что может быть не так
Почему не получается то, что она пытается сделать
Что можно поменять, чтобы работать стало удобнее
LLM напоминает скромного исполнителя, который всегда готов делать то, что ему скажут, и редко предложит сделать что-то иначе. Но ответ на прямой запрос может весьма удивить своей продуманностью. Из него легко сделать план работ, следуя которому LLM сама себе поможет выбраться из болота.
Раньше язык запроса был важен, а сейчас я не замечаю разницы. Не русском я быстрее читаю, воспринимаю, и легче формулирую промпт. Но видно, что размышления у модели нередко происходят таки на английском. Негативные инструкции были добавлены самим Клодом (по моему запросу) после того как не сработали позитивные.
Под "существующими" проектами я имел в виду созданные с использованием других методологий и для которых предусматривается разработка людьми. LLM пишет посредственный некрасивый код, который придётся допиливать вручную, чтобы добавить в человеческую продкутовую кодовую базу. Если не покрыть имеющийся код множеством слоёв избыточных для человеческой разработки тестов, агент будет коммитить забагованные изменения ломающие всё подряд. Такие требования, ИМХО, делают взаимную разработку сложных проектов человеком и моделью нецелесообразными.
Естественно, проект созданный по LLMDD поддериваем как LLM, так и людьми (но это будет пытка для них). Притом, тесты показывают, что в принципе не важно какая модель используется. Claude Sonnet 3.5 и более совершенные модели могут быть применены в этой методике, но могут потребоваться различные донастройки и адаптации.
Проблема в том, что если это будет крошечный проект, то люди скажут: конечно, такой крошечный проект можно и одним промптом написать. Поэтому проект должен быть более-менее серьёзным. Хотя бы на 50К строк. А значит, он потребует где-то месяца разработки, что будет эквивалентно 3-м месяцам классической разработки командой. Быстрее и дешевле? Да, но всё равно это труд. И статью описывающую такую разработку тоже не получится быстро написать. Но я всё равно планирую сделать такое, как будет побольше свободного времени.
К сожалению, проект над которым я работаю - под NDA. Я обязательно позже напишу более подробную статью на качественном проекте с открытым кодом. Но на это требуется намного больше времени и усилий. Так же полностью согласен: создать LLMDD проект с нуля намного проще, чем добавить что-то к существующему проекту. Я бы даже сказал так, что это - задача совсем другого уровня и, вполне возможно, тупиковая по своей сути.
Я бы перевёл это как "Слепой режим" или "Командный режим".
Пользы очень много. Особенно в прототипировании. Очень помогает в работе с проектными документами и вообще любой документацией. Вообще, надо переключать работу на AI-First. Сейчас кажется, что LLM внесёт в программирование изменения подобные изобретению компиляторов.