Часть 1. Проблематика#
Наблюдаю за IT-проектами сегодня и вижу, как развитие LLM сократило дистанцию между бизнесом и разработчиками.
Бизнесу этого очень не хватало, потому что разработка всегда была для него непонятным чёрным ящиком, который с аппетитом поглощал бюджеты и не всегда качественно и своевременно выдавал результаты.
Что изменилось с появлением LLM#
Теперь на помощь бизнесу пришли LLM-модели. Изменилось многое. Мои наблюдения таковы:
- Бизнес перестал оперировать требованиями к системе, а сразу составляет ТЗ на разработку
- Бизнес сам ориентируется, какая задача сколько времени занимает
- Когда разработка буксует, бизнес консультируется с LLM и подсказывает разработчикам решения
- Если разработка всё равно не справляется, у бизнеса появляется большой соблазн самому с помощью ИИ-агентов погрузиться в вайб-кодинг
Давайте разберёмся, к чему это приводит.
1. ТЗ вместо требований#
Бизнес начинает формулировать технические задания без глубокого понимания архитектуры и ограничений системы. В результате ТЗ часто содержат противоречия, нереалистичные сроки или неучтённые технические риски. Разработчики получают на вход документ, который сложно реализовать без доработок, а бизнес не понимает, почему “всё так долго и дорого”.
2. Оценка задач за разработчиков#
Бизнес, опираясь на LLM, начинает самостоятельно оценивать трудозатраты, не учитывая специфику кода, технический долг и скрытые зависимости. Это приводит к нереалистичным дедлайнам, переработкам и выгоранию команды. Разработчики теряют мотивацию, так как их экспертное мнение игнорируется.
3. Подсказки разработчикам#
Когда бизнес, консультируясь с LLM, начинает давать технические рекомендации, это подрывает авторитет команды. Разработчики либо слепо следуют сомнительным советам, либо тратят время на споры, вместо того чтобы сосредоточиться на решении задач. В итоге страдает качество кода и скорость разработки.
4. Вайб-кодинг руками бизнеса#
Самое опасное – когда бизнес, вооружившись ИИ-агентами, начинает писать код самостоятельно. Это приводит к хаосу в архитектуре, неконсистентности решений и росту технического долга. Команда теряет контроль над проектом, а бизнес – время и деньги, так как такой код редко бывает поддерживаемым и масштабируемым.
Следствие#
Общее следствие этих 4 наблюдений заключается в том, что бизнес начинает брать ответственность за код. В то время, как компетенций для этого не хватает, разработчики не воспринимают нетехнического руководителя всерьёз и выполняют задачи из-под палки.
В итоге ответственность за реализованные решения размывается между бизнесом, LLM и разработчиками с этого момента фактически не принадлежит никому.
В такой ситуации проект очень быстро заходит в тупик, и кода бизнес в конце концов спрашивает разработку, как так вышло, разработка отвечает что-то в духе:
– Вы сказали, что надо делать так. Мы сделали
Один жизненный пример#
Работая в формате аутсорса над разработкой информационных систем, мы часто выполняем проекты, будучи внешней командой для бизнеса заказчика. Однажды у нас был пример клиента, настолько уверенного в своих возможностях с применением LLM, что в желании учить наших разработчиков писать код и оценивать задачи его было не остановить. Приводило это к тому, что мы с трудом удерживали ребят на проектах. Даже руководитель проекта боялась регулярных отчётных встреч с этим клиентом как огня, потому что чувствовала себя как на допросе. В итоге команда выгорала, а темпы выполнения работ на проекте снижались, и мы были в шаге от того, чтобы отказаться от работы с этим клиентом.
Риски для бизнеса#
С точки зрения бизнеса всё это создаёт повышенные риски:
Потеря контроля над проектом. Бизнес теряет фокус на стратегии, увязая в технических деталях.
Рост технического долга. Быстрые решения без архитектурного видения приводят к дорогостоящим переделкам.
Утечка компетенций. Разработчики, недовольные микроменеджментом, уходят из команды.
Репутационные риски. Нестабильный продукт подрывает доверие клиентов
Выход из ситуации#
И тут бизнес оказывается перед выбором из 2 вариантов:
Ещё глубже погружаться в разработку, чтобы исправить ситуацию, а это долго, дорого и почти невозможно, потому что совершенно невозможно совмещать бизнес и разработку, если изначально компетенций в разработке нет
Вернуться на бизнесовый уровень, а разработку оставить разработчикам. Однако учитывая, что отношения между бизнесом и разработкой уже испытывают сложности, бизнесу здесь важно открыто признать намерение изменить ситуацию и с этого момента доверить разработку техническому руководителю. Тогда у проекта есть шанс на успешное развитие.
В случае же выбора первого варианта – даже если бизнес погрузится в разработку, его, скорее всего, ждёт разочарование, потому что помимо перечисленных явных проблем с потерей ответственности за код, есть ещё и менее явные проблемы, которые обязательно дадут о себе знать в отсутствие технического менеджмента.
Часть 2. Решение#
Это первая часть статьи. Во второй части поговорим о менее явных проблемах и решении, которое кажется мне оптимальным в данной ситуации: Внешний CTO в помощь бизнесу в эпоху LLM и вайб-кодинга
Авторы
Юрий Абдуллин @yury_eaCCO/CTO, IT-предприниматель, ментор IT-стартапов.
25 лет в разработке информационных систем (обо мне)
Открыты к новым проектам
Выполняем профессиональную разработку информационных систем, сервисов и платформ:
- дорабатываем MVP до полноценных систем
- проектириуем и внедряем ИИ-агентов
- проводим аудит кода и процессов
- обеспечиваем качественный QA и DevOps