Организация процесса agent-assisted разработки

26 июля 2026 г.

За последний год профессия инженера-разработчика ПО изменилась до неузнаваемости. Вместо кода мы стали писать документы и делегировать реализацию AI-агентам, а сами же сфокусировались на более высокоуровневых вопросах:

Хорошо ли вносимые изменения согласуются с планами дальнейшего развития проекта? А с другими проектами? С проектами других команд?
Какие требования к фиче, к проекту? Все ли заинтересованные стороны одинаково видят эти требования? Может быть, можно сделать что-то другое, у чего ценность в этот момент намного выше?
Что и когда делегировать агентам? Сделали ли агенты то, что ты их попросил сделать? Обработаны ли крайние случаи? Не сломалось ли что-нибудь вне области изменений?
И многое другое…

Когда начинаешь работать в AI-assisted парадигме, обязательно появляется желание запустить бесконечное количество сессий параллельно (ведь их запуск часто почти ничего не стоит) – продуктивность, пусть машина работает!

Но это ловушка. Да, реализация стала кратно дешевле, но пропускная способность человека осталась такой же, а ведь в конечном счёте именно человек должен принять финальные решения и быть ответственным за результат.

Промежутки на механическую работу – написание кода – пропали. А вот количество умственной работы, смены контекстов и принимаемых решений увеличилось кратно. Каждый справляется как может. Многие, с кем я обсуждал эту проблему, приходят к мысли, что работать стало намного интереснее, но при этом усталость накапливается с новыми темпами.

В последние месяцы, прилично походив до этого по граблям, нашёл оптимальный для себя способ организации рабочего процесса. Он сводится к нескольким незамысловатым правилам, которые помогают меньше уставать, извлекать из агентской разработки максимум пользы и стабильно поставлять результат.

Рабочий процесс выстраиваю интервалами по 25-40 минут: как для работы, так и для личных проектов. Да-да, тот самый 🍅. В перерывах стараюсь на пару минут встать с рабочего места и развеяться, например, выйти на балкон.
Для каждого интервала выбираю до двух задач, над которыми буду работать. Задачи выбираю по совокупности факторов: срочность, количество оставшейся работы, насколько эта задача блокирует других людей и т.д. – факторов много, но на практике чаще всего сразу понятно, что с приоритетом топ-1, что с топ-2, а что может и подождать. В каждом новом интервале могу взять две другие задачи, если приоритеты изменились или какая-то из задач осталась заблокирована.
По обеим задачам запускаю асинхронные процессы. Чаще всего эти процессы связаны либо с агентами – отправить их что-то делать – либо с коммуникациями с людьми.
Полностью фокусируюсь на топ-1 задаче. Ревью, обсуждения, написание спецификации или других документов – всё, что может приблизить задачу к завершению.
Перехожу к топ-2 задаче, только если первая заблокирована: агенты работают, люди отвечают, документы согласуются, и всё в таком духе.

Почему именно две задачи? Не знаю. Как и любые правила, они зачастую не срабатывают, и параллельно начинают идти 3 или 4 задачи… Но я чувствую, что, когда задач больше двух, внимание расплывается и переключение контекстов становится многократно дороже.

Для меня этот набор правил точно работает, несмотря на периодические нарушения. Однако, как я для себя выяснил, если совсем на них забить и перестать следить за своим контекстным окном, то всё становится сильно хуже.

Буду рад, если заметка поможет кому-то обнаружить эту проблему в своих процессах и задуматься о её решении.

AI-assisted engineers are burning out, is this fine? – Evil Martians

The reality of AI-Assisted software engineering productivity – Addy Osmani

Другие статьи по теме