Где AI уже меняет разработку — и где пока создаёт только иллюзию скорости

Фраза «мы внедрили AI» почти ничего не сообщает без контекста. В одной компании это автодополнение в IDE, в другой — параллельные агентные сессии, внутренние инструменты и автоматизация целых рабочих процессов. Модели меняют не только SDLC, но и продукт: персонализированный текст, иллюстрации и внутренние операции становятся экономически доступнее. Однако дешёвое производство контента само по себе не создаёт ценности — результат должен решать задачу пользователя и проходить проверку качества. Поэтому сравнивать компании по числу выданных лицензий бессмысленно: одинаковый инструмент может экономить минуты отдельному разработчику или менять всю цепочку от постановки задачи до обратной связи. Единицей анализа становится завершённая работа, а не факт обращения к модели.

Эта неравномерность создаёт информационные пузыри. Инженер легко принимает собственный способ работы за новую норму, а руководство — покупку лицензий за организационную трансформацию. У аналитика или операционного специалиста, напротив, впервые появляется возможность самостоятельно автоматизировать давно понятную задачу, на которую раньше не выделяли разработчиков. Поэтому участники предлагают обсуждать не абстрактную «зрелость AI», а конкретную проблему, исходный процесс, доступный контекст и измеримый результат. Такой разговор защищает и от FOMO, и от преждевременного скепсиса. Он также делает видимыми разные стартовые условия: качество данных, доступ к системам, готовность владельцев процесса и допустимую цену ошибки. Без этой конкретики демонстрация легко выглядит универсальной, хотя повторить её в другой среде невозможно.

Агентам нужен другой интерфейс к организации. Красивый портал для человека может быть хуже машинно-читаемых спецификаций, доступных репозиториев, воспроизводимой среды и ясных проверок. Поэтому простое переименование DevEx- или platform-команды в «AI productivity» редко решает задачу. Рабочая модель из разговора — временно встраивать AI-чемпионов в продуктовые команды, давать им несколько итераций на совместный эксперимент и распространять уже проверенные приёмы через реальные задачи, а не через единый набор советов сверху. Встроенный специалист видит не только удачный промпт, но и организационные разрывы: где нет владельца данных, какое разрешение приходится получать вручную и какая проверка существует лишь в голове эксперта. Эти наблюдения и становятся очередью улучшений платформы.

Эксперименту требуется защищённое пространство: ограничения безопасности и production-политики обязательны, но если применить весь контроль до первого обучения, команда не узнает, что вообще работает. После нескольких циклов находки можно превращать в правила, доступы и поддерживаемую платформу. При этом внедрение остаётся социально-техническим. Страх потерять работу, стыд за помощь модели и синдром самозванца заставляют людей скрывать практику. Масштабирование требует одновременно решений сверху — бюджетов, поставщиков и границ — и разрешённого обмена снизу, где использование AI признаётся нормальным способом инженерной работы. Полезно отделять безопасную учебную среду от production и заранее договариваться, какие данные и действия запрещены. Тогда неудачный опыт остаётся источником знания, а не поводом закрыть инициативу или скрыть ошибку.

Агентная работа возвращает старым инженерным практикам буквальный смысл. Спецификация, тесты, линтеры, компилятор, моки и локально воспроизводимая среда становятся не документацией «на потом», а условиями делегирования. В примере с массовой миграцией Pydantic один инженер может автоматизировать большой объём изменений, если владельцы сервисов обеспечат review и smoke-тесты. Там, где этого нет, агент не столько ускоряет систему, сколько проявляет накопленный долг контекста и проверок. Локальная скорость одного разработчика поэтому не равна пропускной способности всей организации. Чем больше изменений агент способен породить за час, тем опаснее оставлять в конце ручную очередь проверки. Ускорение исполнения имеет смысл только вместе с ускорением обратной связи и ясной ответственностью за принятие результата.

В прикладных примерах агенты собирают доказательства для визового досье, инвентаризируют книжные иллюстрации, разыгрывают продуктовые гипотезы и превращают интервью с человеком в повторяемую спецификацию. Общий принцип — выбирать задачи с наблюдаемым результатом и помещать исполнение в проверяемую среду. Формальная математика допускает proof checker, код — тесты и статический анализ, цифровой продукт — telemetry и пользовательские сигналы; физический мир проверять труднее. Прогнозы о сверхкрупных моделях и автономных лабораториях остаются мнениями участников, но практический вывод уже применим: человек всё больше отвечает за намерение, архитектуру, критику и последствия. Это не исчезновение инженерной роли, а перенос усилий к формулировке задачи и устройству контура проверки. Автономность можно увеличивать лишь настолько, насколько система способна вовремя обнаружить и ограничить неверное действие.