ИИ в бизнесе: скорость генерации — это ещё не продуктивность команды

Когда команда начинает выпускать больше, но не обязательно работать лучше

Мне кажется, один из самых опасных самообманов вокруг ИИ сейчас звучит очень привлекательно: если команда стала выпускать больше, значит, она стала продуктивнее.

Снаружи всё и правда выглядит красиво. Кода больше. Документов больше. Черновиков больше. Идей больше. Решения появляются быстрее. Но дальше начинается та часть работы, которую плохо видно в дашбордах: всё это нужно прочитать, проверить, связать с контекстом продукта и потом за это отвечать.

И вот здесь у меня всё чаще возникает ощущение, что весь разговор про ИИ в бизнесе сегодня вообще не про генерацию. Он про пропускную способность команды. Про то, сколько она реально успевает понять, проверить и довести до качественного результата.

Недавно на дне рождения подруга, которая работает кем-то между QA и product, рассказывала про свой проект. У них сервис-оркестратор для создания агентов, который регулярно дописывает и переписывает свой код сам. Снаружи это выглядит как праздник автоматизации разработки. Под капотом же это выглядит чуть менее празднично: несколько раз в день появляется новый объём изменений, который кому-то надо разобрать. Восторг и боль!

Для разработчика это может быть усталость от постоянной проверки. Для фаундера — уже другая тема: это вопрос управления скоростью. Потому что можно очень быстро ускорить выпуск артефактов и так же быстро перегрузить тех, кто отвечает за качество продукта, решений и релизов.

Новый Bottleneck: команда генерирует быстрее, чем успевает проверять

Последние месяцы я всё чаще вижу одну и ту же картину. Код, тексты, тесты, описания, варианты решений, аналитические отчёты, новые экраны и документы теперь появляются почти без паузы.

Раньше узким горлышком было само производство. Сейчас всё чаще оно находится в другом месте: в голове человека, который должен понять, что именно произошло, где тут мусор, где заготовка, а где уже действительно полезный результат.

Из-за этого история про ИИ в разработке быстро перестаёт быть локальной темой инженеров. Она становится темой для руководителей. Потому что bottleneck теперь часто уже не в написании, а в проверке и в том, чтобы за это отвечать.

AI productivity может быть всё-таки иллюзией?

Самое неприятное здесь даже не количество ошибок. К ошибкам рынок давно привык. Гораздо неприятнее другое: ощущение ускорения очень легко перепутать с реальным ростом эффективности.

В исследовании METR open-source разработчики ожидали, что ИИ ускорит их примерно на 24%. По факту задачи с разрешённым ИИ заняли на 19% больше времени. После эксперимента участники всё равно продолжали считать, что ИИ их ускорил.

Мне этот результат кажется особенно интересным не как аргумент против ИИ, а как холодный душ после всех красивых ощущений.

Когда ты меньше печатаешь руками, раньше видишь черновик и быстрее получаешь “что-то готовое”, очень легко решить, что работа стала идти быстрее целиком. Но сама работа никуда не делась. Она просто переехала.

В перепроверку. В повторные генерации. В доведение до ума. В попытку удержать контекст.

Поэтому, когда кто-то говорит про AI productivity, мне хочется сразу уточнить: ускорилось что именно? Скорость первого черновика? Количество артефактов? Или время до качественного результата, за который команда готова отвечать?

AI brain fry: когда ИИ добавляет ~~свободу~~ перегруз

В Harvard Business Review это уже описали как AI brain fry. Авторы из BCG опираются на исследование среди 1 488 работников крупных компаний в США и пишут про перегруз внимания, рост числа ошибок, перегрузку решениями и желание уйти с работы. В той же статье есть фраза пользователя Gas Town:

Too much going on for you to reasonably comprehend.

На русский это можно перевести как:

Столько всего, что тебе не осмыслить.

Мне кажется, она очень точно попадает в происходящее.

Мы привыкли думать, что автоматизация снимает нагрузку. На практике агенты и генеративные инструменты нередко добавляют новый слой контроля. За ними надо следить. Их надо ограничивать. Их результат надо интерпретировать. Их ошибки приходится разбирать уже в реальном продукте, а не в демонстрации.

LeadDev хорошо описывает это на примере agentic coding. Не как страшилку для противников ИИ, а как заметку о людях, которым всё это нравится. Из-за этого они начинают дольше сидеть за компьютером, уносить этот темп в выходные и жить с ощущением, что можно успеть ещё немного.

Для фаундера здесь важен не бытовой дискомфорт. Важнее то, что когнитивная перегрузка редко остаётся личной историей одного сотрудника. Через какое-то время она начинает бить по качеству решений, терпению руководителей среднего звена и общей ясности в команде.

Workslop: результат выглядит готовым, а работа только начинается

Есть ещё один полезный термин: workslop.

BetterUp Labs и Stanford Social Media Lab называют так результат, который выглядит прилично, но перекладывает реальную работу на следующего человека. В их выборке 1 150 full-time desk workers около 40% сталкивались с этим за последний месяц, а один такой эпизод в среднем съедал около двух часов.

Это очень знакомое ощущение... Документ, код, написанный текст уже есть. Стратегия как будто бы тоже есть.

Но потом выясняется, что это не совсем то, что требовалось. Это просто заготовка, которая выглядит достаточно убедительно, чтобы занять чужое время.

Нужно перечитать, проверить, убрать лишнее, переписать слабые места. Другими словами, нужно заново собрать мысль.

Собственно, в этом и проблема. ИИ действительно убирает часть дешёвой работы. Но он не всегда убирает работу вообще. Очень часто он просто переносит её на более дорогой уровень.

Почему это особенно опасно для фаундеров

Когда ИИ используется точечно, это обычно просто полезный инструмент. Когда он начинает менять ритм команды, он превращается в управленческую тему.

Для фаундера риск не сводится к тому, что модель иногда ошибается. Ошибается всё. Вопрос в другом: что именно вы ускоряете вместе с этим инструментом?

Если процесс в команде плохо продуман, ИИ может очень быстро:

• увеличить объём спорных изменений;
• добавить скрытую нагрузку на CTO, техлидов, продактов и QA;
• создать иллюзию роста качества без фактического прогресса;
• сделать релизы плотнее, а решения хуже.

В официальном анонсе отчёта DORA 2025 Google Cloud прямо пишет:

AI adoption continues to have a negative relationship with software delivery stability.

пер.: Внедрение ИИ по-прежнему отрицательно сказывается на стабильности выпуска программного обеспечения.

А на странице DevOps у них есть точная формулировка:

AI is an amplifier, not a fix.

пер.: ИИ — это усилитель, а не решение проблем.

Мне она нравится. В хорошо продуманном процессе ИИ может реально дать выигрыш. В слабом процессе он способен ускорить не только delivery, но и ошибки, организационный шум и цену чужого внимания.

Что происходит с качеством кода, продукта и решений

Сам по себе рост объёма ещё ничего не гарантирует. Особенно если смотреть не на демо, а на длинную поддержку продукта.

По Stack Overflow Developer Survey 2025, больше разработчиков не доверяют точности результата от AI-инструментов, чем доверяют: 46% против 33%. И только около 3% говорят, что “highly trust” такой результат. Для руководителя это полезный сигнал. Даже люди, которые потом доводят AI-код до рабочего состояния, не склонны считать его надёжным по умолчанию.

GitClear в исследовании на 211 миллионах changed lines пишет о 4x росте code clones, о том, что copy/paste впервые обогнал moved code, и о заметном падении доли изменений, связанных с рефакторингом. Это выглядит как довольно понятная картина: производить стало легче, а держать систему в порядке — не легче.

CodeRabbit проанализировали 470 open-source PR и получили неприятный результат: AI-authored PR в среднем содержали около 1.7x больше issues, чем human-only PR. Logic and correctness issues были чаще на 75%, readability problems выросли больше, чем в 3 раза, security issues доходили до 2.74x.

С безопасностью история тоже не выглядит безобидной. В отчёте Veracode и их разборе результатов говорится, что в 45% тестов AI-generated code приносил security flaws.

Мне здесь важен не моральный вывод “нельзя пользоваться ИИ”. Мне важнее другой, более приземлённый вывод: качество продукта, кода и решений не растёт автоматически вместе со скоростью генерации. За него по-прежнему платят вниманием, ревью, тестами и зрелым процессом.

Почему инциденты крупных компаний важны как сигнал

Я не утверждаю, что инциденты GitHub, OpenAI или Vercel вызваны AI-generated code. У меня нет таких доказательств. И подменять анализ красивой страшилкой здесь было бы просто нечестно.

Но публичные incident pages полезны по другой причине. Они показывают, в какой реальности вообще живут современные технологические компании. Даже очень сильные команды постоянно работают на фоне деградаций, сбоев, регрессий и уязвимостей.

У GitHub Status только в апреле 2026 можно увидеть и регрессию в Pull Requests, из-за которой merge queue могла неправильно мерджить PR, и отдельный инцидент с Pages, где статус-страница пишет о примерно 17.5 миллионах failed requests, и сбой Codespaces, где около 40% start operations failed.

У OpenAI Status History уже в апреле 2026 можно найти Codex unresponsive, elevated conversation errors, login issues, file upload failures и отдельные проблемы по разным продуктам.

У Vercel есть и официальная status history, и апрельский security bulletin 2026, где они прямо пишут про unauthorized access к внутренним системам. На статус-странице в те же дни отдельно зафиксированы elevated errors on Dashboard and API endpoints, из-за которых у части пользователей были проблемы с запуском новых deployment.

Для меня это не доказательство вреда AI-кода. Это напоминание о другом: современные системы и без того хрупкие и дорогие в поддержке. Поэтому безоглядно увеличивать поток изменений — идея сомнительная даже безо всякой магии вокруг ИИ.

Как фаундеру внедрять ИИ без потери контроля

Я бы смотрел на внедрение ИИ чуть приземлённее. Не как на соревнование по генерации, а как на попытку аккуратно настроить новый темп внутри команды.

Что здесь помогает на практике:

• Ограничивать количество параллельных AI-потоков, особенно если у команды уже не хватает времени на нормальное ревью.
• Проверять, сколько времени команда реально может тратить на проверку результата от ИИ без того, чтобы сыпались остальные задачи.
• Смотреть на дефекты, инциденты, нагрузку на ревью и качество решений.
• Требовать тестов и проверки безопасности для AI-generated изменений.
• Назначать ответственного за результат, а не за промпт.
• Регулярно спрашивать команду, где ИИ действительно ускоряет работу, а где просто создаёт шум.
• Не навешивать ИИ как ещё один слой задач поверх старого процесса, не меняя сам процесс.

Если упростить до одной мысли, то она для меня такая: управлять нужно не только качеством результата, но и тем, с какой скоростью он вообще попадает в систему.

Какие итоги

Мне не близка паника вокруг ИИ. Но мне и не очень понятна радость по поводу любого роста генерации только потому, что он выглядит как прогресс.

Для фаундера главный вопрос сейчас не в том, умеет ли команда выпускать больше с помощью ИИ. Главный вопрос в том, умеет ли компания управлять этой скоростью без потери контроля.

Как мне кажется, самый ценный навык ближайших лет будет не в промптинге. Он будет в дозировке, верификации, качестве проверки и способности вовремя остановиться.

ИИ полезен, когда встроен в зрелый процесс. В слабом процессе он вполне может ускорить и производство, и ошибки одновременно.