Очень хорошее замечание, спасибо! Действительно, одной только базовой методики для достижения 100% успеха мало. Мало того, именно предложенный вами флоу я и пытался использовать по началу. Но с ним получились свои проблемы. Возможно, он хорош когда человек, как архитектор и программист отлично владеет всей необходимой областью знаний. Тогда не проблема при планировании заметить все косяки и неточности в составленной LLM доке. Но, к сожалению, такое ограничение крайне сужает возможную область использование агентов. И я уже не смогу сделать андроид-приложение с аудиостримингом, если не разбираюсь хотя бы в одном из этих вопросов.
Я нашёл что более эффективно при ограниченности знаний человека составлять примерный документ с этапами разработки и прорабатывать каждый этап по мере развития проекта. Но не это главное. Для защиты чистоты кода я использую такой подход:
Требую от модели:
Создать архитектурные ADR (Architecture Decision Records) в docs/architecture/decisions/
Добавить диаграммы компонентов и data flow
Документировать каждый критический path (authentication, deposits, withdrawals)
Говорю агенту основываясь на составленных документах тщательно провести аудит кода. Таким образом он находит случаи дублирования, кривой логики, расхождения с архитектурным планом и т.п.
Не только использую широчайший набор линтеров, но и создаю при помощи агента специальные программные инструменты, заточенные на особенности конкретного проекта, позволяющие добиться и поддерживать высокое качество кода
Это лишь несколько основных пунктов. Я использую ещё множество других методик. Но они все пока что недостаточно устоялись в моей голове, чтобы я мог написать статью о них.
Когнитивная нагрузка резко снижается. Больше не нужно быть постоянно в контексте и даже в потоке для того, чтобы решать проблемы. Я сделал хук в claude code, чтобы он мне присылал нотис, когда консоль закончила работать. Я смотрю не весь лог, а только заключение, которое пишет ИИ. По этому заключению выбираю какой из двух шаблонов нужно отправить следующим и в редких случаях замечаю, что что-то пошло не так и поправляю агента. Всё это позволяет не только не вникать в то, как, к примеру, устроен webrtc, а просто проверять, работает ли трансляция в итоге или нет. Так же это позволяет вести несколько проектов одновременно, или решать параллельно несколько задач на одном проекте.
Отладка «черного ящика» - сейчас мой подход кажется радикальным, так же как и когда-то казалось радикальным полагаться на компилятор не разбираясь в том машинном коде, который он создаёт. Да, модели далеки от совершенства и методики ещё не отработаны, но пока что на проектах средней сложности мне удаётся удерживать систему в стабильном состоянии без необходимости править код. Можно очень много написать на эту тему, но самое главное - TDD на каждый чих. Рано или поздно баги кончаются, а тесты не допускают регрессий.
Потолок сложности. Действительно, современные модели не способны охватить крупные кодовые базы с хитрыми взаимосвязями, особенно если код был создан людьми более умными, чем модель, или требует каких-то специальных знаний. Для достижения успеха я вынужден ограничиваться инструментами, которые хорошо описаны в сети миллионами примеров. Я использую go, ts, react, postgres. Что-то нетипизированное или не достаточно популярное - прямой путь к провалу для хоть сколько либо серьёзного проекта.
И, наверное, самое главное ограничение: мою методику нельзя использовать в проектах, где работают другие программисты потому как нейронка создаёт код не самого лучшего качества и без уважения относится к написанному человеком. Зато при помощи агентов можно одному разрабатывать в кратчайшие сроки продукты, которые в противном случае требуют много месяцев усилий согласованной команды.
Ну вот примерно из-за таких комментов я и не пишу статьи на Хабре. Вкидываешь тонну сил и времени, а в результате язвительные комменты у которых плюсов в 5 раз больше, чем у статьи
Да много чего. Одно большое веб-приложение для корпоративного использования. Пара телеграм-ботов собирающих/анализирующих полезную инфу. Андроид-приложение для обучения языкам (не зарелизил ещё). Агенты делают всё. UX, дизайн, архитектуру, фронт, бек, деплой, аналитику, безопасность. Только успевай этим роем командовать
Уж поверьте, 200 баксов в месяц окупаются стократно. 1 агент-супервизор, 3 агента-воркера - работают вместе почти постоянно над одним проектом. + ещё 2 маленьких сторонних проекта, на них ещё по консоли. В серднем, 4-5 работают параллельно.
Я знал что халява должна кончиться, жаль что так скоро. Это у меня запущено 5 консолей параллельно с утра до вечера. Придётся переходить на Джемини, наверное
О, да, это отдельная боль. Модель очень любит моки потому что они легко и просто решают её основную проблему: пользователь хочет не видеть ошибок - так давайте ему пропишем то, что он хочет видеть, и он будет доволен. Пользователь хочет, чтобы тесты проходили? Так давайте напишем тесты, которые всегда проходят. Или даже испортим старые рабочие тесты, чтобы они не мешали рисовать зелёные галочки. Доходит до того, что в интеграционных тестах "моки тестят моки", а для E2E модель может создать отдельную страницу, на которой нарисовано всё, что юзер пожелает. Воспитывать бесполезно. Даже с такими строгими запретами модель пытается мокать, хардкодить, городить заглушки и т.п. Приходится после выполнения каждой задачи писать: "Ultrathink. Критически оцени свои изменения" - и не раз, а итеративно заставлять модель исправлять только что написанное. И ещё периодически писать: "Ultrathink. Тщательно проанализируй код проекта на соответствие принципам указанным в claude.md" - постоянно находится какое-то "изобретение" модели с целью упростить себе жизнь. По типу хардкода JWT, или просто отключения проверки валидности токена, например.
Лекарство пока только одно: тесты максимально приближенные к реальности. Реальные запросы к внешним АПИ, реальная запись в тестовую базу, своя тестовая нода блокчена и т.п.
Вот как выглядит демка сейчас с включённым дебагом
Желающие увидеть строчки кода, могут пройти по линку в конце статьи, продублирую здесь: https://github.com/aiseeq/savanna - но я на код не смотрел пока. Если глянете, скажите, как он там, норм?
Конечно! И основная проблема не в том, чтобы создать ассеты, а в том, чтобы они были консистентными. Там тоже немало приёмов приходится использовать - обо всём распишу. А пока что вот вам атакующий заяц =)
В целом да, до истинного вайб-кодинга в стиле: "Напиши мне операционную систему" - как до управляемого термоядерного синтеза. Но всё же, ИМХО, стоит попробовать уже сейчас. Если откладывали реализацию какого-то небольшого собственного проекта из-за недостатка времени или мотивации - может быть, это именно тот инструмент которого вам не хватало. Алсо, 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 внесёт в программирование изменения подобные изобретению компиляторов.
Очень хорошее замечание, спасибо! Действительно, одной только базовой методики для достижения 100% успеха мало. Мало того, именно предложенный вами флоу я и пытался использовать по началу. Но с ним получились свои проблемы. Возможно, он хорош когда человек, как архитектор и программист отлично владеет всей необходимой областью знаний. Тогда не проблема при планировании заметить все косяки и неточности в составленной LLM доке. Но, к сожалению, такое ограничение крайне сужает возможную область использование агентов. И я уже не смогу сделать андроид-приложение с аудиостримингом, если не разбираюсь хотя бы в одном из этих вопросов.
Я нашёл что более эффективно при ограниченности знаний человека составлять примерный документ с этапами разработки и прорабатывать каждый этап по мере развития проекта. Но не это главное. Для защиты чистоты кода я использую такой подход:
Требую от модели:
Создать архитектурные ADR (Architecture Decision Records) в docs/architecture/decisions/
Добавить диаграммы компонентов и data flow
Документировать каждый критический path (authentication, deposits, withdrawals)
Говорю агенту основываясь на составленных документах тщательно провести аудит кода. Таким образом он находит случаи дублирования, кривой логики, расхождения с архитектурным планом и т.п.
Не только использую широчайший набор линтеров, но и создаю при помощи агента специальные программные инструменты, заточенные на особенности конкретного проекта, позволяющие добиться и поддерживать высокое качество кода
Это лишь несколько основных пунктов. Я использую ещё множество других методик. Но они все пока что недостаточно устоялись в моей голове, чтобы я мог написать статью о них.
Очень хорошие вопросы, спасибо!
Когнитивная нагрузка резко снижается. Больше не нужно быть постоянно в контексте и даже в потоке для того, чтобы решать проблемы. Я сделал хук в claude code, чтобы он мне присылал нотис, когда консоль закончила работать. Я смотрю не весь лог, а только заключение, которое пишет ИИ. По этому заключению выбираю какой из двух шаблонов нужно отправить следующим и в редких случаях замечаю, что что-то пошло не так и поправляю агента. Всё это позволяет не только не вникать в то, как, к примеру, устроен webrtc, а просто проверять, работает ли трансляция в итоге или нет. Так же это позволяет вести несколько проектов одновременно, или решать параллельно несколько задач на одном проекте.
Отладка «черного ящика» - сейчас мой подход кажется радикальным, так же как и когда-то казалось радикальным полагаться на компилятор не разбираясь в том машинном коде, который он создаёт. Да, модели далеки от совершенства и методики ещё не отработаны, но пока что на проектах средней сложности мне удаётся удерживать систему в стабильном состоянии без необходимости править код. Можно очень много написать на эту тему, но самое главное - TDD на каждый чих. Рано или поздно баги кончаются, а тесты не допускают регрессий.
Потолок сложности. Действительно, современные модели не способны охватить крупные кодовые базы с хитрыми взаимосвязями, особенно если код был создан людьми более умными, чем модель, или требует каких-то специальных знаний. Для достижения успеха я вынужден ограничиваться инструментами, которые хорошо описаны в сети миллионами примеров. Я использую go, ts, react, postgres. Что-то нетипизированное или не достаточно популярное - прямой путь к провалу для хоть сколько либо серьёзного проекта.
И, наверное, самое главное ограничение: мою методику нельзя использовать в проектах, где работают другие программисты потому как нейронка создаёт код не самого лучшего качества и без уважения относится к написанному человеком. Зато при помощи агентов можно одному разрабатывать в кратчайшие сроки продукты, которые в противном случае требуют много месяцев усилий согласованной команды.
Отдыхают =) Без супервизии они ничего нормального написать не могут. Можно было бы нагрузить чем-то автоматическим, но ничего полезного не придумал.
Ну вот примерно из-за таких комментов я и не пишу статьи на Хабре. Вкидываешь тонну сил и времени, а в результате язвительные комменты у которых плюсов в 5 раз больше, чем у статьи
Да много чего. Одно большое веб-приложение для корпоративного использования. Пара телеграм-ботов собирающих/анализирующих полезную инфу. Андроид-приложение для обучения языкам (не зарелизил ещё). Агенты делают всё. UX, дизайн, архитектуру, фронт, бек, деплой, аналитику, безопасность. Только успевай этим роем командовать
Уж поверьте, 200 баксов в месяц окупаются стократно. 1 агент-супервизор, 3 агента-воркера - работают вместе почти постоянно над одним проектом. + ещё 2 маленьких сторонних проекта, на них ещё по консоли. В серднем, 4-5 работают параллельно.
Я знал что халява должна кончиться, жаль что так скоро. Это у меня запущено 5 консолей параллельно с утра до вечера. Придётся переходить на Джемини, наверное
О, да, это отдельная боль. Модель очень любит моки потому что они легко и просто решают её основную проблему: пользователь хочет не видеть ошибок - так давайте ему пропишем то, что он хочет видеть, и он будет доволен. Пользователь хочет, чтобы тесты проходили? Так давайте напишем тесты, которые всегда проходят. Или даже испортим старые рабочие тесты, чтобы они не мешали рисовать зелёные галочки. Доходит до того, что в интеграционных тестах "моки тестят моки", а для E2E модель может создать отдельную страницу, на которой нарисовано всё, что юзер пожелает. Воспитывать бесполезно. Даже с такими строгими запретами модель пытается мокать, хардкодить, городить заглушки и т.п. Приходится после выполнения каждой задачи писать: "Ultrathink. Критически оцени свои изменения" - и не раз, а итеративно заставлять модель исправлять только что написанное. И ещё периодически писать: "Ultrathink. Тщательно проанализируй код проекта на соответствие принципам указанным в claude.md" - постоянно находится какое-то "изобретение" модели с целью упростить себе жизнь. По типу хардкода JWT, или просто отключения проверки валидности токена, например.
Лекарство пока только одно: тесты максимально приближенные к реальности. Реальные запросы к внешним АПИ, реальная запись в тестовую базу, своя тестовая нода блокчена и т.п.
Львы и крокодилы. Или кто там естественные хищники?
Корованы из коров - обязательно =) Людей в игру не хочу добавлять
Желающие увидеть строчки кода, могут пройти по линку в конце статьи, продублирую здесь: https://github.com/aiseeq/savanna - но я на код не смотрел пока. Если глянете, скажите, как он там, норм?
Конечно! И основная проблема не в том, чтобы создать ассеты, а в том, чтобы они были консистентными. Там тоже немало приёмов приходится использовать - обо всём распишу. А пока что вот вам атакующий заяц =)
В целом да, до истинного вайб-кодинга в стиле: "Напиши мне операционную систему" - как до управляемого термоядерного синтеза. Но всё же, ИМХО, стоит попробовать уже сейчас. Если откладывали реализацию какого-то небольшого собственного проекта из-за недостатка времени или мотивации - может быть, это именно тот инструмент которого вам не хватало. Алсо, 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 внесёт в программирование изменения подобные изобретению компиляторов.