Расхожий тезис про AI в разработке — что скорость разработки не нужна, потому что у бизнеса нет столько новых идей.
Если ты сидишь на уровне среднего тимлида, девопса или QA, и тебе кажется, что у бизнеса мало идей, — это может означать другое. Это не идей мало. Бизнес так задрала твоя низкая производительность, вечно проёбанные сроки и регулярные возвраты задач в багфиксинг с рефакторингом, что он плюнул на тебя и вбрасывает только неизбежные критичные задачи. Иначе невыносимо наблюдать, как ты медленно копошишься со своей архитектурой и паттернами — и всё равно на выходе косяки и переделки.
Как это обсуждают на уровне руководства
В обсуждениях с руководителями компаний я часто вижу одну и ту же логику. Там нет НИКАКИХ иллюзий, что вы делаете какое-то важное дело, обеспечиваете расширяемую и поддерживаемую архитектуру и предусматриваете стопицот эдж-кейсов. Никаких. В ряде компаний из ритейла и SaaS погроммисты всей толпой открыто считаются неизбежным злом, налогом на решение задач.
В управленческих обсуждениях это часто переводят в язык ROI, headcount-бюджета и стоимости задержки. Один раунд багфиксинга после релиза — и финансовый директор считает убытки по потерянным продажам, оттоку клиентов и мёртвому time-to-market. Разработчики в этой модели — строка расходов с непредсказуемой отдачей.
Просто вам это не говорят, чтоб вы не уволились нахер с тоски.
Вам говорят, что очень важно обеспечить непрерывность бизнеса, надёжность, гарантию доставки, геораспределённую устойчивость, низкое время восстановления после сбоев, дублирование данных — и всё такое. Такой нарратив часто используют, чтобы сделать инженерную работу управляемее.
С точки зрения менеджмента. Нельзя прийти к инженеру и сказать: «Ты — расходный материал, сделай фичу быстрее и дешевле». Он обидится и уйдёт. Или, что хуже, обидится и останется — только теперь будет тихо саботировать. Поэтому рассказывают про высокую миссию: SLA, отказоустойчивость, архитектурную чистоту, культуру инженерного мастерства. Надёжность правда нужна. Но функция этого нарратива — не надёжность, а управляемость. Инженер, который понимает смысл требований, обычно легче принимает ограничения процесса. Погроммист, который узнал, что он строка в Excel — нет.
В финансовой модели разработка часто выглядит как значимая статья затрат, которую нужно нещадно оптимизировать.
Ломка вчерашних тимлидов
У части тимлидов при переходе в менеджмент меняется взгляд на разработку. Ещё вчера человек жил в концепции архитектуры, рефакторингов и отказоустойчивости. Теперь его открыто и цинично принуждают воспринимать бывших коллег как тонер в принтере: пока есть — никто о нём не думает, как закончится — надо просто заменить.
Вчерашний архитектор садится на совещание с VP и CEO — и вдруг понимает: на этом уровне приоритеты смещаются от инженерных принципов к стоимости задержек и рискам. Архитектурные решения, принципы SOLID, ревью, стандарты кодирования — в этой комнате считают другое. Сколько стоит задержка фичи в деньгах. Сколько клиентов потеряли за квартал из-за бага в продакшене. На сколько процентов можно сократить engineering headcount, если перенести часть задач на AI.
CTO и VP Engineering покупают не «архитектуру» и не «процессы». Они покупают спокойствие и снижение когнитивной нагрузки — чтобы не дёргаться от каждого алерта, не разруливать конфликты между командами, не объяснять бизнесу, почему релиз опять перенесли. Если тот же результат можно получить дешевле и без роста рисков, руководители обычно рассматривают такой вариант.
Примеры внедрения
В одной компании с выручкой около $680M, 15 млн клиентов и 9000 сотрудников. AI-трансформация пришла не снизу — не энтузиаст-разработчик притащил ChatGPT. Инициатива шла от руководства, а не от отдельных разработчиков. За 6–8 месяцев выделился отдельный AI-департамент. Нетехнические сотрудники — маркетологи, аналитики, операционщики — сами начали собирать себе инструменты. Не потому что заставили, а потому что наконец-то появилась возможность получить результат, не дожидаясь очереди в JIRA.
AI-бот для запросов к data lake сократил время получения типовых ответов с нескольких дней до секунд. Буквально — вопрос и ответ вместо заявки, приоритизации, ожидания и отчёта.
В другом SaaS-продукте в трекере были тысячи багов и ежедневно появлялось 5–10 новых. Релизы раз в несколько месяцев. Клиенты боялись обновляться, потому что после каждого обновления что-нибудь ломалось. Это не гипотетическая ситуация — типичная ситуация для некоторых зрелых SaaS-продуктов с накопленным техническим долгом.
И вот в этом контексте появляется AI-assisted разработка, которая для части задач сокращает работу с дней до десятков минут. Тысячи автотестов перед каждым коммитом. По словам команды, за полгода не было критичных падений.
Почему тезис «всё останется по-прежнему» слабый
Все разговоры о том, что заказчикам не нужен AI-assisted кодинг, что у них якобы нет потока идей, что всё останется по-прежнему, никого не уволят, а те же погроммисты будут сидеть тем же составом и чуть-чуть кодить с помощью AI — это хуета, не учитывает уже идущие внедрения AI-assisted разработки.
Одна из частых реакций заказчиков на быстрый прототип: наконец-то можно получить результат без длинной очереди разработки.
Наконец-то можно не ждать три спринта, чтобы подвинуть кнопку. Наконец-то можно задать вопрос к своим же данным и получить ответ без тикета. Наконец-то фича, которую откладывали два года из-за «нет ресурсов», просто делается. Не через квартал. Сейчас.
Во многих компаниях проблема не в отсутствии идей, а в том, что их перестали формулировать из-за долгого цикла поставки.
Защитный рефлекс
Тезис «бизнесу не нужна скорость» часто работает как защитное объяснение для команд, привыкших к текущему темпу. Удобная мысль для тех, кто привык к текущему темпу и статусу: раз у заказчика нет новых задач, значит, всё нормально, меня не заменят.
Заказчик молчит не потому, что ему нечего хотеть. Он может перестать приносить идеи, если прошлые запросы месяцами не доходили до результата. Каждая озвученная идея — это месяцы ожидания, переделки, оценки «от 400 часов» и результат, который не совпадает с тем, что просили.
Теперь часть таких задач можно закрывать без полноценной инженерной команды. Не «с вами, но чуть быстрее». Без вас. Или с одним человеком вместо команды из двенадцати.
Тонер в принтере не обсуждает с принтером, нужен ли он. Его просто меняют, когда появляется более дешёвый картридж.
Что ломается и почему
Разберём, почему тезис «у бизнеса нет идей» не просто ошибочен, а опасен для тех, кто в нём укрылся.
Почему бэклог может казаться исчерпанным
Вам кажется, что продуктовый бэклог исчерпан, потому что вы видите только то, что до вас дошло. До вас дошла выжимка после фильтра «это реально дойдёт за разумный срок». Всё остальное заказчик даже не озвучивает — зачем формулировать ТЗ на фичу, которая попадёт в релиз через год? Пустой или слабый бэклог иногда означает не отсутствие спроса, а недоверие к срокам поставки.
Если срок поставки заметно сокращается, часть ранее неозвученных идей возвращается в обсуждение. И то, что никогда не подавалось голосом, потому что «бесполезно», вдруг становится актуальным. Аналитика в реальном времени. Персонализация для каждого сегмента. Интеграции, которые откладывались годами. Эксперименты, на которые не было слотов. Часть идей, которые продакт-менеджеры не заводили в JIRA из-за низкого шанса реализации, — потому что зачем.
Почему архитектура не гарантирует незаменимость команды
Вторая защитная мысль: «AI не умеет в архитектуру, а мы — умеем, поэтому нас не заменят». Это верно только там, где стоимость архитектурных ошибок для бизнеса очевидна. Бизнесу нужна фича, которая работает. Архитектура — ваша проблема, не его. Когда результат можно получить без команды из двенадцати человек, детали архитектурных слоёв редко являются темой C-Level, если риски не выражены в деньгах или сроках.
Это не значит, что архитектура не нужна. Это значит, что готовность за неё платить — ограничена. Во многих компаниях готовность платить за архитектурную чистоту ниже, чем предполагают инженеры.
Почему ускорение меняет процесс, а не только сроки
Третья: «AI просто ускорит нас, мы будем делать то же самое, только быстрее». Нет. При сильном сокращении цикла меняется не только длительность задач, но и набор нужных процессов. Когда спринт сжимается до получаса, меняется само понятие процесса. Ревью, планирование, оценки, стендапы — всё это было нужно для координации медленной команды. Когда отдельные задачи можно закрыть одним человеком за вечер вместо квартального цикла команды, — координация не нужна. Нужен результат.
| Было | Стало |
|---|---|
| Идея → ТЗ → оценка → спринт → релиз через 3 месяца | Идея → результат за вечер |
| Команда из 12 человек | Один человек с AI |
| Тысячи багов, релизы раз в квартал | Тысячи автотестов, ноль падений за полгода |
| Заказчик молчит, потому что устал хотеть | Заказчик говорит, потому что наконец-то слышат |
Где это уже применяли
Такие внедрения уже идут в отдельных компаниях.
Компания с выручкой $680M выделила отдельный AI-департамент за 6–8 месяцев. Нетехнические сотрудники сами собирают инструменты — потому что наконец-то могут получить результат без очереди в JIRA. Маркетолог не ждёт аналитика. Аналитик не ждёт разработчика. Операционщик не ждёт релиза.
SaaS-продукт с тысячами багов в трекере перешёл на AI-assisted разработку. Двухнедельный спринт — 10–30 минут. Тысячи автотестов перед каждым коммитом. Ноль падений за полгода. Клиенты перестали бояться обновлений.
В обоих случаях спрос на AI пришёл не от разработчиков. Инициатива шла от бизнес-подразделений, которым были важны сроки получения результата.
Где это ломается
У такого подхода есть ограничения. Вот где модель даёт сбои — и где AI-assisted разработка не даёт ожидаемого выигрыша.
Когда нет данных
AI-assisted разработка ускоряет написание кода. Она не ускоряет понимание предметной области. Если в компании нет документации, контрактов, спецификаций — AI может ускорить написание кода, но не исправит ошибки в требованиях и предметной модели. Скорость написания не компенсирует скорость misunderstanding.
Когда процесс важнее скорости
В регулируемых отраслях — финтех, медицина, оборонка — процесс проверки и соответствия стандартам занимает больше времени, чем написание кода. AI ускорит второе, но не первое. Ревью, аудит, комплаенс — это не «тормозят разработку», это часть продукта. Здесь выигрыш от AI меньше, и бизнес это знает.
Когда команда сопротивляется
Часто сбой связан не с моделью, а с сопротивлением команды. Команда разработчиков воспринимает AI как угрозу и саботирует внедрение. «Это код не нашего качества», «мы не можем это ревьюить», «это нарушает наши стандарты». В компаниях, где менеджмент не готов жёстко продавить изменение культуры, внедрение замедляется, если руководство не задаёт новые правила работы.
Счёт
Если этот тезис всё ещё кажется убедительным и всё ещё думаешь, что «бизнесу не нужна скорость, потому что нет идей» — пересчитай. Сколько фичей в вашей компании отложены «из-за нехватки ресурсов»? Сколько интеграций лежат в бэклоге годами? Сколько экспериментов не запущены, потому что «нет слотов в спринте»? Такой список показывает не отсутствие идей, а ограничение текущей пропускной способности разработки.
Если раньше заказчик не формулировал запросы из-за долгих сроков, с появлением более быстрого канала он начнёт приносить их снова, и команда разработки либо встроится в этот процесс, либо часть задач уйдёт в обход неё.