Инженерный руководитель FurtherAI поделился девятимесячным опытом построения AI-native организации. С января число изменений, которые каждый инженер вливает за день, выросло примерно в пять раз, а revert rate оставался ниже 0,5%. Автор подчёркивает, что одна выдача coding-агентов результата не дала: после ускорения очередного этапа работа накапливалась на следующем, поэтому компания последовательно перестраивала весь процесс выпуска.
В марте агенты начали писать код под управлением инженеров, и теперь их участие, по оценке автора, близко к 100%. В апреле к ним добавились тесты: доля изменений с тестами выросла с 15% до 91%. В мае AI стал предварительно проверять 99% изменений вместо 60%. В июне параллелизация и запуск только затронутых тестов позволили выполнять в 20 раз больше проверок за прежние 17 минут CI.
В июле ClaudeTag начал принимать сообщения об ошибках в Slack, находить дубликаты, создавать tickets и назначать ответственных; на него приходится 60% заведённых bug tickets. В августе негласные правила команды стали превращать в небольшие Python-проверки для каждого commit и PR. Таких правил уже 21: агент получает сообщение о нарушении, исправляет код и продолжает работу. Низкорискованные изменения, прошедшие тесты, проверки и AI review, могут вливаться автоматически; доля таких случаев достигает трети.
В сентябре появились Slack-каналы, где любой сотрудник описывает агенту изменение и получает PR. Дизайнер с августа влил около 50 изменений, включая части design system, а customer-facing сотрудники делают небольшие UI-правки. Внутренние Poirot и Sherlock помогают разбирать production и staging с доступом к логам, метрикам, traces и read-only БД.
Автоматизация потребовала летних вложений в тесты и tooling: число customer-facing изменений на инженера держалось между 17 и 30 в месяц, в сентябре выросло до 45, а октябрь шёл к 48.
Теперь узким местом стало решение, что именно строить. Если планирование и review не ускоряются, рост скорости программирования даёт куда меньший общий выигрыш. В ответ FurtherAI передаёт инженерам больше end-to-end ownership: от понимания клиента до проверки метрики и регрессий. Менеджерам предлагается лично пробовать продукт, развивать product judgment и подключаться там, где действительно нужна их оценка, а не добавлять управленческие уровни. Это опыт одной компании, а не универсальная методика.