Gergely Orosz про AI в разработке: замедлиться, чтобы ускориться (Рубрика AI4SDLC)
Посмотрел keynote Gergely Orosz “Slow down to speed up: AI and software engineering” с Craft Conference, что проходила в Будапеште. Главная мысль у Gergely похожа на мои тезисы с выступления на Highload - AI упростил написание кода, но возникли вопросы доверия к этим AI изменениям. Если команда генерирует pull requests быстрее, чем умеет их понимать, проверять и связывать с продуктовым результатом, то локальное ускорение легко превращается в системное замедление.
Первую часть выступления Gergely разбирает текущее состояние дел в индустрии
- Историю Instagram/Meta с их инцидентом с account takeover через Meta AI. По его словам это был не просто баг, а симптом организации, где фокус на AI начал выдавливать безопасность, надежность и инженерную культуру
- Дальше он рассказывает про текущее состояние дел в Anthropic и OpenAI (примеры больших AI лаб), Cursor (пример компании, что делает инструменты для инженеров), Google и Meta (bigtech с большим разнообразием внутренних инструментов), а также Uber (пример компании с полноценной инфрой для инженеров вокруг AI)
Эти истории интересны, по ним видно, что индивидуальный output на разработчика действительно вырос, но продуктивность команд и качество не обязаны вырасти вместе с ним. Gergely делится данными Linear и Cursor: больше PR, больше строк кода, крупнее изменения, больше acceptance без человеческого review. Из этого видно, что кода действительно поставляется больше, но дальше он доезжает на этап ревью. И для того, чтобы это не стало бутылочным горлышком нам требуется архитектурное мышление инженерные практики вокруг тестирования, наблюдаемости, надежности, безопасности - раньше они часто были nice to have, а теперь must have. Только они позволяют как-то доверять тем объемам изменений, что сейчас стали нормой при помощи AI.
Интересно, что Gergely активно хвалит Uber и рассказывает про их а внутреннюю инфраструктуру: MCP Gateway, Agent Builder, Minion, Code Inbox, risk profiles, AI code review. То есть AI там встраивают не как игрушку рядом с IDE, а как часть системы поставки ценности: маршрутизации изменений, оценки риска, review-потоки, миграций, циклов обратной связи.
Отдельно Gergely активно ругает AI метрики, которые дают неправильную мотивацию сотрудникам. Если организация мерит token usage или просто adoption, люди будут максимизировать использование AI, даже когда это ухудшает результат. Это старая болезнь кривых метрик, умноженная на скорость генерации кода. Можно выглядеть очень современно и одновременно производить больше технического долга.
AI не отменяет хорошую инженерию, а делает ее более ценной. Naming, границы модулей, тестируемость, понятные контракты, нормальный review, умение удалить старый код - все это становится не эстетикой, а инфраструктурой доверия. Когда код пишет агент, человеку тем более нужен способ понять: что изменилось, почему это безопасно и какие последствия будут через три месяца.
Ближе к концу выступления Gergely делится рекомендациями 1️⃣ Замедляться надо не в смысле “не пользоваться AI”, а в смысле “не генерировать больше, чем можешь проверить”. Скорость должна подчиняться бутылочному горлышку (возможности ревью), а не наоборот. 2️⃣ Начинать надо не с инструмента, а с бизнес результата и слабого места процесса. Где теряется время: discovery, onboarding, review, тесты, миграции, incident response, документация, старый код? AI полезен там, где встроен в конкретную петлю обратной связи. 3️⃣ Стоит инвестировать в verification systems. Evals, тесты, статический анализ, risk profiles, наблюдаемость, staged rollout, code ownership - это способ масштабировать AI без полной потери контроля. 4️⃣ Инженеру будущего нужны навыки продакт менеджера, доменная экспертиза, архитектурный вкус и способность строить системы поверх LLM: RAG, agents, evals, workflow automation, внутренние платформы. Чем дешевле код, тем ценнее понимание, какой код вообще стоит писать. 5️⃣ AI adoption нельзя делегировать только энтузиастам и считать по лицензиям. Руководителям придется оставаться hands-on: понимать ограничения моделей, видеть реальные bottlenecks команды, защищать качество и перестраивать review. Средний слой руководителей, который только водит руками здесь не особо нужен
#AI #AI4SDLC #Engineering #Software #Architecture #Management