Семь принципов, которые улучшат ваш вайбкод
1. Декомпозиция рулит. Тут все как с людьми: не стоит давать ИИ сложных задач одним промптом. У каждой задачи на входе должны быть полноценно описанные исходные условия и желаемый результат. Если задача настолько большая, что описание выходит слишком объемным, эффективнее будет разбить её на серию небольших задач и делать последовательно, шаг за шагом.
2. Контекстом памяти нужно управлять. В целом, базовые инструменты управления встроены в движок самих моделей, но полагаться на них полностью и неделями работать в рамках одной сессии неэффективно и очень дорого. Научитесь делать точки восстановления контекста, чекпоинты и качественную связанную документацию. Очищайте сессию каждый час-полтора.
3. Не пользуйтесь ИИ там, где нужен воспроизводимый результат. С расчетом сложных формул или заполнением документа по заданному шаблону лучше справится старый добрый детерминированный код. Где не нужны рассуждения, там не нужна языковая модель и reasoning.
4. Не теряйте контроль над кодом. Я не говорю о том, что нужно дотошно вычитывать каждую строчку кода. Но, как минимум, вы должны понимать архитектуру того, что написали — то, как код работает и почему работает именно так. Если вы потеряли контроль над кодом, самый простой способ его восстановить — удалить непонятный фрагмент и переписать с нуля, уже тщательно контролируя каждый шаг.
5. Ограничивайте модель там, где вам требуется соблюдение определенных правил и процедур. Дизайн-системы, стили кодирования, правила декомпозиции задач, Tone Of Voice ваших документов — для ключевых регламентированных процессов должны быть созданы письменные инструкции для ИИ.
6. Не пренебрегайте практикой ревью (аудита) кода. Правило вытекает из предыдущего. По своей природе LLM могут терять куски контекста и понемногу от них отступать (дрифтить). Поэтому автоматизируйте процедуру периодического аудита уже написанного на соответствие заданным правилам. Время от времени стоит проводить “ручное” ревью. В Amazon, к примеру, после серии крупных инцидентов в прошлом году, завели правило ручного code-review перед раскаткой кода на боевые сервера.
7. Не работайте в одиночку. Самое, пожалуй, сложное правило. Но большие проекты по-прежнему не делаются в одиночку. Ключевых причины две. Первая — человек теперь главное ограничение ИИ-систем. Именно он должен успевать осознавать то, что создает, а еще человек может уставать, терять энергию, выгорать. Во-вторых, не бывает универсальных экспертов и человек, который очень хорош в коде, может быть не так хорош в дизайне или текстах. Отчасти проблема решается созданием агентов с нужной экспертизой, но если такой агент создан и обучен человеком с низкой квалификацией в предметной области, то результаты его работы будут соответствующими.
1. Декомпозиция рулит. Тут все как с людьми: не стоит давать ИИ сложных задач одним промптом. У каждой задачи на входе должны быть полноценно описанные исходные условия и желаемый результат. Если задача настолько большая, что описание выходит слишком объемным, эффективнее будет разбить её на серию небольших задач и делать последовательно, шаг за шагом.
2. Контекстом памяти нужно управлять. В целом, базовые инструменты управления встроены в движок самих моделей, но полагаться на них полностью и неделями работать в рамках одной сессии неэффективно и очень дорого. Научитесь делать точки восстановления контекста, чекпоинты и качественную связанную документацию. Очищайте сессию каждый час-полтора.
3. Не пользуйтесь ИИ там, где нужен воспроизводимый результат. С расчетом сложных формул или заполнением документа по заданному шаблону лучше справится старый добрый детерминированный код. Где не нужны рассуждения, там не нужна языковая модель и reasoning.
4. Не теряйте контроль над кодом. Я не говорю о том, что нужно дотошно вычитывать каждую строчку кода. Но, как минимум, вы должны понимать архитектуру того, что написали — то, как код работает и почему работает именно так. Если вы потеряли контроль над кодом, самый простой способ его восстановить — удалить непонятный фрагмент и переписать с нуля, уже тщательно контролируя каждый шаг.
5. Ограничивайте модель там, где вам требуется соблюдение определенных правил и процедур. Дизайн-системы, стили кодирования, правила декомпозиции задач, Tone Of Voice ваших документов — для ключевых регламентированных процессов должны быть созданы письменные инструкции для ИИ.
6. Не пренебрегайте практикой ревью (аудита) кода. Правило вытекает из предыдущего. По своей природе LLM могут терять куски контекста и понемногу от них отступать (дрифтить). Поэтому автоматизируйте процедуру периодического аудита уже написанного на соответствие заданным правилам. Время от времени стоит проводить “ручное” ревью. В Amazon, к примеру, после серии крупных инцидентов в прошлом году, завели правило ручного code-review перед раскаткой кода на боевые сервера.
7. Не работайте в одиночку. Самое, пожалуй, сложное правило. Но большие проекты по-прежнему не делаются в одиночку. Ключевых причины две. Первая — человек теперь главное ограничение ИИ-систем. Именно он должен успевать осознавать то, что создает, а еще человек может уставать, терять энергию, выгорать. Во-вторых, не бывает универсальных экспертов и человек, который очень хорош в коде, может быть не так хорош в дизайне или текстах. Отчасти проблема решается созданием агентов с нужной экспертизой, но если такой агент создан и обучен человеком с низкой квалификацией в предметной области, то результаты его работы будут соответствующими.