FurtherAI заявила: слияний кода на инженера стало в 5 раз больше

В треде на Twitter/X автор, работающий в FurtherAI, делится уроками девяти месяцев построения «ИИ-нативной» инженерной организации. Поводом стал вопрос Уилла Ларсона (@Lethain) о том, как руководители оценивают инженерных менеджеров по навыкам работы с ИИ; ответ автора со списком вопросов собрал много закладок. Все цифры ниже, самоотчёт компании, независимо они не проверены.

Главный результат: с января число изменений кода, которые каждый инженер сливает в основную ветку за день, выросло примерно в 5 раз, а доля откатов осталась ниже полупроцента. Но просто выдать инженерам кодовых агентов этого не дало: каждый раз, когда ускоряли один этап, работа накапливалась на следующем. Поэтому команда стала проходить весь путь выпуска ПО по шагам и оптимизировать каждый.

Шаги по месяцам. Март, код: агенты пишут код, инженеры ими управляют; чистой цифры на старте нет (ранние инструменты лишь изредка помечали изменения), но сейчас доля кода от агентов, по словам автора, почти 100%. Апрель, тесты: агенты пишут тесты вместе с кодом, тесты есть в 91% изменений против 15%. Май, ревью: ИИ проверяет 99% изменений до человека (было 60%), люди сосредотачиваются на тех местах, где нужно суждение. Июнь, CI (автоматическая сборка и проверка): тесты распараллелили и запускают только затронутые изменением, теперь CI прогоняет в 20 раз больше тестов за те же 17 минут. Июль, баг-репорты: ClaudeTag (@claudeai) принимает сообщения о багах из Slack, находит дубликаты, заводит тикет и назначает исполнителя; сейчас он заводит 60% тикетов. Август, правила: когда баг или комментарий ревью вскрывал знание, которым владели только инженеры, его превращали в небольшую проверку на Python, которая запускается на каждом коммите и PR, роняет сборку и подсказывает исправление; правил стало 21 вместо нуля. Август, слияние: малорисковые изменения, прошедшие тесты, автоматические проверки и ИИ-ревью, вливаются сами, до трети изменений теперь сливается без участия человека. Сентябрь, кодовые каналы: любой может открыть канал в Slack, описать агенту изменение и получить PR; с одним агентом в канале работают несколько человек. Там же команда активно использует облачные сессии Devin (@cognition).

Кроме того, собственные агенты Poirot и Sherlock расследуют и устраняют проблемы в продакшене и на стенде, имея доступ к логам, метрикам, трассировкам и базе данных только на чтение. Бывает, что агенты работают цепочкой: ClaudeTag разбирает запрос, Devin делает работу, Poirot достаёт внутренние данные. Побочный эффект: код стали отправлять не только инженеры, дизайнер слил около 50 изменений с августа, включая те, что собрали дизайн-систему, а сотрудники по внедрению и работе с клиентами правят интерфейс прямо из Slack.

Цена: летом значительная часть инженерных усилий ушла на тесты и инструменты, и число изменений для клиентов на инженера держалось между 17 и 30 в месяц. В сентябре оно выросло до 45, октябрь идёт темпом на 48 (это оценка, а не итог). Заметьте: пятикратный рост относится к слияниям в день, а не к изменениям для клиентов.

Во второй части автор говорит о новом узком месте: команда стала намного быстрее писать код, но не так быстро решать, что строить. Упрощённый пример: фича занимала десять дней, три на планирование, шесть на разработку, один на ревью. Если агенты ускоряют разработку в 3,5 раза, а планирование и ревью не меняются, фича целиком ускоряется лишь в 1,75 раза, а на планирование и ревью приходится уже 70% времени вместо 40%. Это иллюстрация, а не замер FurtherAI. Решения традиционно идут через инженерных менеджеров, продакт-менеджеров и дизайнеров, и с ростом скорости инженеров это всё труднее.

Ставка компании, передать больше ответственности инженерам, а не наращивать слои управления. Автор пока думает об уровнях так: младший инженер строит с агентом и замечает, когда тот ошибается; старший планирует и проверяет свою работу; ведущий (staff) берёт расплывчатую проблему, выбирает компромиссы и отвечает за число, показывающее, сработало ли решение. Инженеры должны быть ближе к клиентам и вести задачу от понимания проблемы до проверки результата и ответственности за регрессии в продакшене. От менеджеров автор ждёт двух вещей: быть «в работе», пробовать функции на стенде как конечный пользователь, а не только проверять, что код отревьюили, и лучше разбираться в продукте, иметь сильные продуктовые мнения и помогать инженерам развивать суждение, чтобы PM или дизайнер не требовался для каждого мелкого решения.

Итог: за год компания училась ускорять инженеров, а теперь пытается ускорить всю организацию; автор подозревает, что это будет сложнее, чем автоматизация кода, тестов и ревью. Он признаёт, что они ещё в начале пути, спрашивает, что ломалось первым у других команд, и в конце сообщает, что FurtherAI ищет Engineering Manager / Director.

Ключевые факты

По данным автора (самоотчёт), с января число слияний на инженера в день выросло примерно в 5 раз, доля откатов, ниже 0,5%.
Выпуск ПО автоматизировали по шагам с марта по сентябрь: тесты в 91% изменений (было 15%), ИИ-ревью 99% изменений до человека (было 60%), CI в 20 раз больше тестов за те же 17 минут, ClaudeTag заводит 60% баг-тикетов, 21 правило-проверка на Python.
До трети изменений теперь сливается автоматически без человека; дизайнер слил около 50 изменений с августа.
Изменений для клиентов на инженера: 17-30 в месяц летом, 45 в сентябре, в октябре темп на 48 (прогноз).
Новое узкое место, решение, что строить: в упрощённом примере автора ускорение разработки в 3,5 раза даёт лишь 1,75× на фичу; ставка, больше ответственности инженерам и менеджеры, глубже вовлечённые в продукт.

Почему это важно

Тред показывает практический опыт одной компании: простая выдача инженерам кодовых агентов не ускорила выпуск, пока не автоматизировали остальные этапы, тесты, ревью, CI, приём багов, проверки и слияние. Главный вывод автора: когда код пишется быстро, узким местом становятся планирование и ревью, то есть решение о том, что строить. Это перекликается с вопросами, которые сейчас задают многие команды.

Кому это важно

Инженерным руководителям и менеджерам, которые решают, как перестраивать процессы и требования к людям при работе с ИИ-агентами; техлидам, выстраивающим тесты, CI и ревью; тем, кто нанимает и оценивает инженеров и менеджеров. Также интересно командам, где нетехнические сотрудники начинают сами вносить правки.

Как это применить

Из треда можно взять последовательность шагов: двигаться по цепочке выпуска по одному этапу, не оставляя ускорение только в написании кода. Конкретные приёмы автора: превращать знание, которым владеют лишь инженеры, в небольшие автоматические проверки, которые роняют сборку и подсказывают исправление; пускать малорисковые изменения, прошедшие тесты, проверки и ИИ-ревью, на автоматическое слияние; принимать баг-репорты через Slack с автоматическим поиском дубликатов. Для менеджеров, пробовать функции на стенде как пользователь. Цены и условия инструментов в треде не названы.

Можно ли доверять

Это тред автора, работающего в FurtherAI, а не официальный релиз и не независимое исследование. Все метрики, самоотчёт компании: у 5-кратного роста нет абсолютной базы, ничего не проверялось со стороны. «До трети» автослияний, верхняя граница, а не точное значение. Расчёт 1,75× и 70%, упрощённый иллюстративный пример, а не замер. Тред заканчивается набором на должность Engineering Manager / Director, так что у текста есть и вербовочная цель. Автор сам оговаривается, что они ещё в начале пути и многое не поняли.

Риски и подводные камни

Автор отмечает, что это не бесплатно: летом много усилий ушло на тесты и инструменты, а число изменений для клиентов выросло лишь осенью. Пятикратный рост относится к слияниям в день, а не к изменениям для клиентов (там рост с 17-30 до 45-48 в месяц). Октябрьская цифра, прогноз. Новые ожидания к инженерам и менеджерам, пока рабочие гипотезы без результатов, а ускорение всей организации автор считает более трудной задачей, чем автоматизация кода, тестов и ревью.

«Мы стали намного быстрее писать код, но далеко не так быстро решать, что строить.»

— Автор треда, FurtherAI