В смежных каналах все чаще вижу паттерн "ван-шот" кодинга – когда всю кодовую базу проекта или большого модуля сгружают в LLM (примерно такими же тулами, как я тут скидывал, только для кода, а не для телеграм чатиков). А потом в один-два промпта решают задачу.
Это стало возможным благодаря ai.studio – модельки гугла кушают до 1 млн токенов и при этом работают бесплатно в определенных лимитах. Так они видят весь контекст в противовес AI IDE'шкам типа Cursor, которые собирают только "нужный" контекст всякими хитрыми инструментами (и пытаются минимизировать количество отправляемых данных, чтобы снизить свои затраты – юзеры замечают падение качества)
Обновленные файлы можно вручную копировать из окна чата, либо скормить всю инфу в Cursor и попросить его обновить файлы ничего не меняя. Я для этого использую gpt-4.1, она очень хороша в роли простого исполнителя.
Инфу выше вы можете много где найти, а вот пару деталей чисто от меня:
1. Частые жалобы на LLM – они пропускают всякие важные нюансы в существующем коде. Но проблема тут не в LLM, а в том, как устроено хранение кода в существующих проектах – нюансы хранятся в головах у разработчиков. Если выносить их в readme файлы для модулей, то llm их учитывает. Если ожидать, что она сама разберется, то будет много случаев, когда нет
2. LLM может собрать эти нюансы и из существующего кода. Так что я прошу сгенерировать мне README файлы для каждого модуля, а потом вручную их проверяю (глупо ожидать, что она сама учетет всё – многие выборы в реальных кодовых базах обусловлены внешним контекстом и не выводятся из кода). Еще я добавляю в .cursor/rules или в системный промпт ai.studio явные инструкции обновлять README файлы когда меняется код. Так автоматически поддерживаем актуальную документацию.
3. Я постепенно перехожу на подход, где исходные файлы – это не код, а текстовая спецификация (Spec). Когда мне нужно обновить код, я просто обновляю эти specs. А код – это результат "компиляции" этого текста LLMкой
4. Но в таком подходе, код каждый раз будет сильно отличаться от предыдущего. Поэтому при генерации я передаю
* старую версию спецификации
* новую версию спецификации
* старую версию кода
и прошу новую версию кода
Получается такой diff-based подход.
5. Если я вижу, что модель работает нестабильно, то это не LLM – дура, а я плохо написал спецификацию. Добавляю уточнения. И иногда обновляю промпт работы с README, чтобы похожие нюансы там тоже учитывались.
Чем это отличается от вайб-кодинга в оригинальной формулировке? Тем, что я полностью контролирую и продуктовую составляющую, и техническую архитектуру. Все через текстовые спеки. То есть, я все еще занимаюсь разработкой. Просто на одном уровне абстракции выше. Получается, я скорее выполняю функции техлида, а не продакта. И вам советую.