Никто пока не разобрался с AI в разработке. За два года мантра «трать на AI, вопросов не задавай» сменилась жёстким разговором с CFO. Теперь спрашивают не «ты используешь AI», а «что ты с этого имеешь?». Крупные компании ждут возврата инвестиций за 12 месяцев или раньше. Проблема в том, что буква I в ROI — инвестиции — никто не контролирует. Раньше инженерная ёмкость измерялась в головах, теперь — в токенах. Сколько токенов сожжёт инженер за день — непонятно. CFO подписывает контракт и теряет контроль над реальными тратами. Компании покупают инструменты, подписывают договоры, а финансовой модели для управления расходами нет. Ситуацию сравнивают с ранним облаком и FinOps до того, как он стал термином. Метрики ещё не придумали. Кто-то считает, что давить на ROI сейчас — значит измерять не то. Умнее сначала зафиксировать базовую линию. Более прагматичный подход — остановить вакханалию и стандартизировать: не «используй всё», а «используй одно и то же, но умнее».
С наймом тоже раскол. В зале чётко разделили две роли, которые часто путают: AI-инженер, который поставляет продукт, и инженер, отвечающий за system design. Язык больше не важен — Python, Go, Rust, Node — не имеет значения. System design не изменился: кто-то всё ещё должен думать про доступность, бюджеты и архитектуру, которую AI не решит. Новый разработчик — это product-лидер. Но технические люди, думающие о дизайне, всё ещё нужны. Собеседования пересматривают: одна команда вообще не меняла процесс — всё ещё тестирует системное мышление. Другая перешла на code review вместо кодинга, потому что именно этим инженеры теперь и занимаются. Если команда генерирует код быстрее, чем успевает его ревьюить, узкое место — человеческое суждение, а не скорость генерации.
Никто не описывал команду, которая была бы целиком за или против AI. Реальность грязнее. Один лидер рассказал про «recalibration moments»: задачи, которые раньше занимали дни, теперь делаются за часы, и людям приходится перестраивать расписание. Другой описал инженера, который продуктивен с AI, но глубоко скептичен к любому AI-выводу. Тревога, что AI заставляет людей перестать думать, звучала не раз. Контраргумент: это проблема менеджмента, а не технологии. Задача лидера — сделать лень невыгодной. Анонимный опрос показал, что 90% инженеров хотят использовать AI. Но следом пошли вопросы про performance management, критерии повышения и recognition, когда любой может сгенерировать код. Внедрение обогнало поддержку.
AI делает код дёшевым. Это не значит, что дёшево его зашиппить или поддерживать. Один участник назвал это cognitive debt — новым техническим долгом. Команды добавляют фичи с немыслимой скоростью, а потом разгребают легаси, которое писали наспех, и внутренние инструменты, ставшие permanent. Процессы build-or-buy были не зря. Если можно наклепать что-то за полдня, их легко пропустить. Проблема приходит потом. Кто-то предложил разделить команды на тех, кто пишет фичи, и тех, кто их удаляет или рефакторит, — и считать обе работы одинаково ценными. Уговорить бизнес, помешанный на скорости, — вот настоящий вызов.
Самый жаркий спор — должны ли продакт-менеджеры шиппить PRы. Мнения разделились. Технически возможно, но есть риск, что инженеры превратятся в мониторщиков кода, защищающих компанию от PRов, которые они не писали, пока PM получает кредит за шиппинг. Другие прагматичнее: дизайнер может написать компонент без инженера, PM фиксит опечатку без Jira — это сокращает цикл обратной связи. Аналогия с беспилотниками: средний AI-assisted нон-инженер лучше среднего unassisted, но сравнивать с инженерами с годами опыта бессмысленно. Если фича на 80% engineering и 20% product thinking — её делает инженер. Если наоборот — может, PM. Главный структурный вопрос без ответа: если шиппить может кто угодно, чья работа держать всё вместе? Ответ — радикальная автономия команд из 3–5 человек, а менеджмент занимается alignment, а не gatekeeping.
Code review — узкое место. Одна команда экспериментирует с confidence scoring на PRах: AI оценивает риск изменений и показывает человеку только те строки, которые действительно нужно проверить. 15 000 строк кода, из которых три требуют ревью — это не проблема на 15 000 строк. Вопрос в том, можно ли построить достаточно валидационной инфраструктуры — feature flags, observability, acceptance tests, mutation testing — чтобы доверять AI-коду так же, как мы доверяем компилятору (не читая ассемблер). Совет: вкладываться в eval-наборы сейчас. Стоимость разработки AI-фич — не проблема. Проблема — стоимость верификации. Когда вендор меняет модель (а они это делают часто), хороший eval suite позволяет просто прогнать тесты и быть спокойным.
Вендор-лок-ин тоже обсуждали. У одной компании единственная точка отказа — Anthropic. Инженеры это понимают. Маркетинг и финансы, строящие на Claude, — нет. Если вдруг пропадёт inference, что делать им? Конкуренция и open-source модели, отстающие всего на пару версий, держат цены в узде. Но настоящий лок-ин не в модели, а во всём, что вокруг неё: навыки, тулинг, внутренние процессы. Практический совет: строить внутренние UI-обёртки над generic model APIs сейчас, пока команды не привязались к конкретным интерфейсам. Это дёшево и позволяет менять модель под капотом без перестройки всего.