Инженеры FurtherAI стали мержить в 5 раз больше кода — и узким местом оказались решения, а не разработка
Building an AI-native engineering org
Sashank Gondala из FurtherAI за девять месяцев перестроил процесс выпуска кода: агенты пишут код и тесты, AI ревьюит 99% изменений, а до трети правок мержатся без участия человека. Число мержей на инженера выросло примерно в 5 раз при доле откатов ниже 0,5%. Но теперь тормозит не код, а планирование и ревью — на них уходит 70% времени. Ответ — передать инженерам больше ответственности и требовать от менеджеров погружения в продукт.
Мы стали гораздо быстрее писать код, но далеко не так же быстро решать, что именно строить.
- juancn
Ни слова о ценности или выручке.
Выросли только три метрики: LOC, расход токенов и, предположительно, скорость/частота релизов.
А как насчёт маржи (прибыль/COGS)? Она выросла?
Удовлетворённость клиентов? NPS движется в какую-то сторону?
- nater5000
Этот пост кажется мне забавным, потому что, как мне кажется, он сильно не дотягивает до того, как на самом деле должна выглядеть настоящая, прогрессивная «AI-native» инженерная организация. То есть автор подаёт это как своего рода радикальный отход от обычной инженерии, но я вижу в этом просто обычную инженерию с бо́льшим количеством ИИ. Я не считаю это AI-native.
Для меня настоящая «AI-native» инженерия будет такой, где вопросы о том, как люди будут делать что-то вроде ревью кода, не имеют значения. Вы явно отбрасываете любое понятие типичной разработки ПО и вместо этого полагаетесь на ИИ. Ваша задача как человека — исключительно делать то, что ИИ физически не может. Это не то же самое, что закрывать разрывы между тем, на что ИИ сейчас способен, и тем, на что вам нужно, чтобы он был способен. Это буквально означает, что всё, что ИИ способен сделать, считается правильным само по себе, а вы как человек только поддерживаете это своим человеческим присутствием.
Если это звучит дико, то потому что так и есть. У нас пока нет настолько способных систем ИИ. Возможно, никогда не будет. Но это не суть. Реальность такова, что попытка создать «AI-native» инженерную организацию, просто накладывая ИИ поверх существующих процессов и систем, бесполезна. Если вы ожидаете, что возможности ИИ будут продолжать расти с ускорением, то эти костыли бессмысленны. Можно просто игнорировать ИИ в целом, пока он не сможет полностью взять всё на себя, ведь это неизбежная цель, верно?
Если вы готовы купиться на то, что это будет возмож […]
- simonw
На данный момент, с примерно марта этого года, куча команд уже вовсю использует подход AI-first с не полностью проверенным кодом.
Это значит, что мы уже на 6–8 месяце, и недалеко до полного года опыта того, как это выглядит на самом деле, хотя на это странным образом повлиял рост возможностей моделей за этот период.
Я с нетерпением жду этих ретроспектив. Оказалось ли это нормально работающим для команд, которые так делают? Какими были крупнейшие провалы и/или сюрпризы? Оглядываясь назад, получилось ли в итоге качественное ПО?
- fg137
Я как раз смотрел на некоторые сообщения об ошибках для пользователей, которые сгенерировал для меня Claude: в них были ненужные/неуместные технические детали, но не было чётких инструкций или исправления.
Ранее я проверял код, который делает гораздо больше, чем указано в задаче, меняет публичный API и вводит новое поведение. Мне пришлось почти полностью всё переделать.
Я подумал: ни за что не выпущу код как есть, не прочитав его целиком (или, как некоторые говорят, глядя только на «намерение»). Я получу больше жалоб от пользователей, при этом совершенно не понимая, что происходит с кодом или его фактическим поведением.
Для меня загадка, как эти организации умудряются.
- liorgrossman
Я вижу, как многие билдеры (включая меня) попадают в ловушку фокуса не на том. Скорость разработки сама по себе не важна; важны такие вещи, как рост прибыли или тракшн. Очень легко путать автоматизацию/системы/процессы с реальными бизнес-результатами. Движение ≠ прогресс.
- simonw
Кстати: эта статья вряд ли попала бы на главную Hacker News из-за кликбейтного заголовка, но я всё равно рекомендую её прочитать: https://twitter.com/jsnnsa/status/2115623382721126826
В ней описывается команда, тратящая 30-кратный размер фонда оплаты труда на токены — $3 000 000 на токены в месяц — на создание многопользовательской игры, где инциденты и баг-репорты от пользователей передаются напрямую агентам Fable 5/5.1, которые затем действуют по ним и разворачивают изменения в продакшене.
«Мы считаем это простоем, если не выпускаем релиз каждый час»
Это стоит прочитать, потому что это либо полная катастрофа, либо проблеск будущего, а вполне возможно, и то и другое.
- mirmor23
Потратил несколько минут на чтение этой рекламы — пожалел. Инженерные принципы — это прежде всего фундамент, и AI-инструменты должны вписываться в них, а не наоборот, как утверждает эта реклама. Её LinkedIn-вая атмосфера тоже сильно отталкивает.
- DavCreator