Speaker A
Всем привет. Сегодня расскажу, почему ты вайпкодишь неправильно, как я строил свой процесс разработки с нейросетями неправильно.
Видео объясняет, как правильно строить workflow с ИИ для разработки, включая промтинг, тесты, контекст и оркестрацию агентов.
Key Takeaways
- Грамотный промтинг с уточняющими вопросами улучшает качество задач для ИИ.
- Тесты до кода — ключ к контролю качества и предотвращению ошибок.
- Сохранение контекста и спецификации обеспечивает последовательность работы агента.
- Оркестрация и изоляция веток позволяют параллельно и безопасно работать с несколькими агентами.
- Использование мультиагентных систем значительно ускоряет и оптимизирует процесс разработки.
What the video covers
- Большинство разработчиков неправильно используют нейросети, давая простые промты без деталей и критериев проверки.
- Важно задавать уточняющие вопросы во время промтинга для создания глубокого и продуманного запроса.
- Сохранение контекста и спецификации помогает агенту не теряться и работать последовательно.
- Тесты должны писаться до кода, чтобы служить техническим заданием и контрактом с агентом.
- Тесты автоматически проверяют корректность кода и выявляют ошибки сразу в процессе работы.
- Использование изолированных веток (GitWK 3) позволяет параллельно работать нескольким агентам без риска сломать основную версию.
- Оркестратор распределяет задачи между агентами и следит за выполнением, оптимизируя затраты токенов и время разработки.
- Пайплайн из опроса, плана, тестов, оркестратора и изоляции улучшает качество и скорость разработки с нейросетями.
- Автор рекомендует использовать мультиагентную среду разработки Vibe Forge для автоматизации такого workflow.
- Видео содержит практические советы и примеры для эффективного взаимодействия с ИИ в программировании.
Chapters
- 00:00Введение и проблемы неправильного вайпкодинга
- 00:21Недостатки простого промтинга и его исправление
- 00:55Уточняющие вопросы и создание глубокого промта
- 01:27Важность контекста и спецификации
- 02:00Роль тестов в разработке с ИИ
- 02:32Почему тесты пишутся до кода и их значение
- 03:31Обратная связь и цикл разработки с тестами
- 04:56Оптимизация работы: оркестратор и изолированные ветки
- 05:55Заключение и рекомендации по использованию Vibe Forge
Full Transcript — Download SRT & Markdown
Speaker A
И как вам построить грамотный workflow работы с нейросетями. Давайте по порядку. А у большинства из вас процесс, скорее всего, выглядит так. Вы даёте промт агенту, ждёте его решения и смотрите на результат. Может быть, в лучшем случае используете какие-то скилы
Speaker A
в промтинге своих задач, но у такого пайплайна есть ряд уязвимостей, которые делают результат работы агента менее эффективным. Давайте разберёмся по порядку. Чаще всего ваша промта без деталей. Агент сам принимает решение, что и как делать. У него нет критериев
Speaker A
валидации и выполненности работы. Второе — это контекст. Агент забывает, что вообще делает в процессе работы. А третье — это проверка кода после выполнения. И четвёртое — это налаженный workflow. То есть, по-простому, работает только один агент. И у большинства
Speaker A
вайпкодеров так и есть. Закрываются все эти нюансы очень просто. А первое — во время промтинга попросите задать вам уточняющие вопросы или используйте для этого специальные скилы. Таким образом, даже неразвёрнутый промт приобретает за собой вес и обрастает мясом. А благодаря
Speaker A
вашим ответам на уточняющие вопросы нейросеть сформирует полноценный, глубокий, продуманный промт. А после того, как вы провели опрос, попросите и составить вам план на основе этого опроса и спецификацию, которые помогут сохранить контекст вашей задачи.
Speaker A
Контекст в целом очень важен при работе с нейросетями. А, и если вы сохраните контекст на длительный промежуток времени, агент не будет теряться в ходе работы, а сможет выполнять их более точно и последовательно. А нейросетям свойственно забывать, что они
Speaker A
вообще делают по мере развития диалога и количества выполненных задач. Спецификация, в свою очередь, помогает агенту всё время двигаться в одном и том же направлении и меньше галлюцинировать. Когда опрос проведён и план готов, вам может показаться, что дальнейшая работа остаётся исключительно
Speaker A
на агенте. Но как бы не так. На самом деле, после всего этого вам необходимо попросить и агент ставить тесты, которые будут валидировать дальнейший код, а и показывать вам, где он ломается непосредственно. А что вообще такое тест? Давайте разберём на пальцах. А
Speaker A
тест — это маленькая программа, которая проверяет другую программу. Она говорит: "Вот такой вход". И на выходе должно быть вот это. Например, если пользователь ввёл неправильный пароль, сайт должен показать ошибку, а не пропустить пользователя внутрь. А тест запускается одной командой, отрабатывает
Speaker A
за секунду, и у него есть всего два варианта: либо зелёный, либо красный. То есть либо сломанный, либо работает. А никакой магии, это просто автоматическая проверка, которую не нужно делать руками каждый раз. Почему тесты пишутся до кода? А это главный вопрос. И потому что
Speaker A
это ваше техническое задание, а, переведённое на язык, который нельзя понять двояко. То есть план говорит: "Сделай авторизацию". А тест говорит: "После логина с верным паролем в ответе должен быть токен. После логина с неверным — ошибка 401. После трёх неверных
Speaker A
попыток — блокировка на минуту". А это уже не пожелание, а контракт с агентом. Агент пишет код не как получится, а так, чтобы этот контракт выполнялся. Если же попросить тесты после кода, агент напишет их под то, что уже сделал. И
Speaker A
они, конечно же, будут зелёными всегда, потому что только проверять они будут не то, что вы хотели, а то, что он придумал сам. Вторая причина. Любой агент заканчивает ход фразой: "Готово, всё работает". Этого никто не проверял. Он не запускал проект, не открывал
Speaker A
страницы, не тыкал, не пробовал всё сломать. Всё работает. Это не отчёт, это простая вежливость. И тесты превращают вежливость в факт. Агент обязан запустить их и показать вам зелёный результат. Красные — значит, не готовы. И вам не нужно самому лезть в код и
Speaker A
разбираться в нём. Как это выглядит на практике? После плана пишите агенту буквально так: "Прежде чем писать код, составь тесты этой спецификации для каждого пункта плана, что мы проверяем, какой вход и какие ожидаемые результаты".
Speaker A
А, запусти их и убедись, что они красные. Да, красные — это нормально, потому что кода ещё нет и проверять пока что нечего. Потом даёте следующую команду: "Теперь пиши код, пока все тесты не станут зелёными". После каждого изменения запускай тесты сам. Если
Speaker A
упало, читай ошибки и чини, а не проси меня". И агент начинает крутить цикл. Написал, запустил, увидел красное, починил, запустил зелёное. Это и есть та самая обратная связь, которой не хватает обычному, дал промт и жду результат. А потому что без тестов
Speaker A
ошибку находите вы и не всегда вообще находите. А с тестами её находит сам агент и находит её сразу в процессе работы. Ну а теперь давайте поговорим, как оптимизировать дальнейшую работу и качество результата на выходе. План составлен, скоуп работ определён и тесты
Speaker A
написаны, но выполнять задачу агент может и часами, а мы хотим результат здесь и сейчас. И в этом нам помогут две вещи: это оркестратор и изолированные ветки. Изолированные ветки или же GitWK 3 — это копия папки вашего проекта, которые могут меняться независимо друг
Speaker A
от друга, не затрагивая основную версию проекта. Они необходимы для параллельной работы нескольких агентов одновременно, чтобы те ничего не сломали в основной версии в процессе работы. И оркестратор.
Speaker A
Им обычно выступает умная модель, например, Cloud Fable 5.1 или GPT-6 Astra. Он распределяет ваш план на подзадачи и отдаёт каждый своему отдельному воркеру, которыми могут выступать более дешёвые модели, например, Opus или GPT 5.6, Sol, Лунна, неважно. А далее он составляет пункты
Speaker A
валидации для каждой подзадачи и в соответствии со своими критериями начинает следить за выполнением каждого работника. А таким образом токены умной модели тратятся намного меньше, чем если бы она сама выполняла эту работу. А временные затраты на разработку оптимизируются за счёт нескольких параллельных исполнителей. А именно вот такого пайплайна,
Speaker A
я придерживаюсь своей разработки, когда создаю какой-либо проект с нуля или либо работаю над какой-то сложной фичей. А итак, давайте ещё раз суммируем всё, что я сказал в этом видео. Всё, что вам нужно — это опрос, план, тесты, оркестратор и изоляция. Вот пять вещей, которых
Speaker A
не хватает большинству для грамотной разработки с нейросетями. Вы можете уже сегодня попросить своего кодекса или клода разработать вам такой пайплайн, чтобы не выстраивать его вручную каждый раз заново. Или же можете попробовать его сразу в моём приложении мультиагентной среды разработки Vibe Forge. А можете найти её по ссылке в описании. Всем
Speaker A
спасибо за видео. Всем пока.
Speaker A
пока.
Topics:нейросетиworkflowпромтингтестыоркестраторизолированные веткиVibe Forgeавтоматизация разработкиИИ в программированиимультиагентная система
