В продолжение постов об исследованиях от METR

На скриншоте — количество задач, которые мы закрыли в последнем спринте командой из двух человек: 25 задач.

Для нашей команды это много. Очень много. Можете не считать стори-поинты, так как вряд ли эти оценки будут информативны, ибо они учитывают разработку с агентами, и 0.1 для агента спокойно может быть 0.5-1 для человека.

Причём у нас не было цели «закрыть как можно больше задач» или «поднажать в этом спринте» — это самый обычный спринт.

За исключением того, что наш бекендер, Дима, адаптировал под нас систему, придуманную другой командой из Додо, которая позволяет прожаривать карточки с помощью LLM.

Суть простая: мы берём юзер-стори → LLM исследует кодовую базу и все открытые/архивные карточки → на основе юзер-стори LLM пишет описание для карточки с техническими деталями и закидывает её к нам на доску → that's it.

Казалось бы, ничего революционного, но на деле — это офигенный способ использовать LLM в уже устоявшейся кодовой базе, так как она имеет нужный ей контекст и почти без ошибок угадывает, какие паттерны применить, куда положить файлы, как задизайнить API и так далее.

Ниже — то, как новый подход ускорил нас.

1. Даже в нашей небольшой команде прожарка задач была бутылочным горлышком.

Помимо того, что она занимала огромное количество времени, зачастую она была очень муторной, и после неё зачастую не оставалось мыслетоплива для того, чтобы делать ещё что-то в течение дня.

2. Новый подход позволил нам распараллелить работу.

Так как все задачи прожарены наперёд, то я могу взять в работу задачу, для которой нужен бэк, понимая, что API не готово. И мне, в целом, без разницы, когда оно будет готово. Как будет готово — фича полностью заработает, а до этого момента просто будет скрыта от глаз пользователя.

Это особенно классно, учитывая то, что у нас есть много независимых задач, которые нужно делать только на фронте или только на бэке, из-за чего бывает очень сложно синхронизироваться, чтобы сделать/прожарить задачу, которая уже требует работы с обеих сторон. Сейчас эта проблема исчезла, ибо у нас просто отпала необходимость синхронизироваться друг с другом там, где это было необходимо раньше.

3. Мы можем брать задачи из другого домена.

Так на прошлой неделе наш менеджер, Оля, принесла юзер-стори, прожарила её через скилл в Claude Code, а затем на основе прожаренной карточки самостоятельно закрыла задачу.

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

Кстати, зацените распределение карточек по типам:
• 14 фичей
• 8 багов
• 2 технические задачи
• 1 исследование

То есть 32% закрытых карточек были багами. Думаю, что кому-то это число может показаться большим, поэтому давайте разберём, что там за баги:
• 4 бага связаны с огромной фичой на 70 тыс. строк (таблицы для Blok), которую я затащил за спринт до этого. Все баги — неучтённые edge-кейсы.
• 3 бага — те самые регрессии, которых все боятся при работе с агентами. Сценарии, в которых они возникали, уже покрыты тестами, так что снова не появятся:)
• 1 баг вообще находился не в нашем сервисе, но так как ребята из другого сервиса пока не могут пофиксить баг у себя, мы сделали изощрённую заплатку в нашем сервисе, до которой не додумались бы сами.

Так что, как видите, даже с учётом возросшей скорости и количества фичей, которые мы шипим, у нас произошло всего 12% регрессии за спринт. И это опять же очень классный результат!

P.S.
Уже в текущем спринте Оля закрыла ещё две задачи. Я их отревьюил и просто слил в мастер, так как доработки не требовались.

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