За последние несколько месяцев мне довелось пообщаться с тремя компаниями по поводу роли руководителя кросс-функциональной команды или CTO в зрелом бизнесе. У каждой были свои ожидания от роли и свои цели на год. Но одна задача повторялась почти у всех: внедрить ИИ в команды разработки и за счет этого повысить их эффективность<\/b>.<\/p>\n
Контекст обычно был примерно такой. Есть устоявшаяся команда, есть зрелый продукт, но, по мнению менеджмента, разработка идет слишком медленно. ИИ-инструменты и кодинговые агенты внутри команды либо почти не используются, либо используются точечно, каждым по-своему, без общего подхода. Иногда их уже пробовали, но результат оказался слабее ожиданий. А на рынке в это время появляются истории о том, как CEO или CPO за ночь собирают прототипы с помощью Codex или Claude Code.<\/p>\n
Выслушав такой запрос, я начинал задавать не вопросы про модели и инструменты, а совсем другие:<\/p>\n
На этом месте можно возразить: «А какое вообще отношение процессы разработки имеют к внедрению ИИ?» На мой взгляд — самое прямое. Чтобы объяснить почему, представим себе две команды.<\/p>\n
У первой команды процессы более-менее выстроены. Люди умеют фиксировать мысли в текстовом и визуальном виде и передавать контекст друг другу. Типичная цепочка выглядит так:<\/p>\n
идея → бизнес-требования и макеты → системные требования → архитектура → задачи на разработку<\/p>\n
В такой команде разработчики не ждут, что аналитик, менеджер или кто-то еще полностью упакует контекст за них. До того как задача попадает в работу, команда уже думает про качество, риски, архитектуру и критерии приемки. В результате заранее появляются артефакты, которые сильно упрощают реализацию.<\/p>\n
Обычно такие команды неплохо умеют работать асинхронно. Люди пишут документы, оставляют после себя след в виде решений, описаний и ревью-комментариев. Это помогает не только людям, но и ИИ.<\/p>\n
Во второй команде тоже может быть формальный Scrumban, но по факту работа устроена иначе. Задачи сразу падают в таск-трекер. Требования, если и пишутся, то вперемешку: бизнес-логика, технические детали и допущения лежат в одном месте. Критерии приемки толком не продуманы. Архитектура рождается уже после того, как задачу взяли в работу. О рисках вспоминают позже. Фичи выкатываются быстро, а инциденты тушатся ситуативно.<\/p>\n
Снаружи может казаться, что команда движется быстро. Но внутри там обычно много недосказанности, устного контекста и зависимости от конкретных людей.<\/p>\n
Теперь представим, что мы хотим внедрить ИИ в обе команды. Условный критерий успеха простой: команда должна делать больше тем же составом, без выгорания и без просадки по качеству.<\/p>\n
Допустим, разработчику выдали доступ к ChatGPT, Claude Code или другому ассистенту. Внутри такого инструмента — большая языковая модель. Она генерирует ответ, опираясь на тот контекст, который ей передали.<\/p>\n
И вот здесь возникает ключевой вопрос: какая из двух команд быстрее получит реальную пользу от ИИ?<\/b><\/p>\n
Очевидно, первая.<\/p>\n
Почему? Потому что у нее уже есть зафиксированный контекст: требования, ограничения, архитектурные решения, стандарты разработки, критерии приемки. Разработчик может взять эти артефакты, явно обозначить границы задачи и начать работать с агентом почти сразу.<\/p>\n
Пример запроса может выглядеть так:<\/p>\n
\nТы — опытный backend-разработчик. В приложенном документе описаны бизнес- и системные требования для фичи обработки банковских выписок. В RFC-123 зафиксирована текущая архитектура. Предложи вариант реализации нового метода API GET \/bank-statements\/. Также учти наши стандарты разработки: стиль кода, подход к REST API и требования к автотестам. Сначала предложи план реализации, затем список изменений по слоям системы и набор тест-кейсов.<\/p>\n<\/blockquote>\n
То есть разработчик из первой команды за несколько минут собрал хороший контекст и получил шанс на действительно полезный результат.<\/p>\n
Во второй команде тот же разработчик, скорее всего, останется один на один с агентом и начнет вручную восстанавливать недостающий контекст: что именно нужно сделать, какие ограничения есть у системы, какие договоренности приняты в команде, какие риски важны, как вообще здесь пишут код. Даже если в итоге что-то получится, путь будет долгим, а вероятность хорошего результата — заметно ниже.<\/p>\n
Вывод<\/h2>\n
Из этого следует простой вывод: внедрение ИИ зависит не только от интереса к технологии, но и от зрелости производственных процессов.<\/p>\n
Context is king — и в общении с людьми, и в работе с ИИ.<\/b><\/p>\n
Если команда не привыкла фиксировать решения, оформлять требования и создавать артефакты, на которых потом строится работа, ей будет трудно быстро получить заметный эффект от ИИ. В такой ситуации лиды начинают выгорать: сверху ждут роста эффективности, снизу люди пробуют агентов, но результат не совпадает с ожиданиями.<\/p>\n
Поэтому, когда меня спрашивают про внедрение ИИ в продуктовой команде, мой ответ обычно один и тот же: сначала выровняйте delivery-процесс, а потом уже системно внедряйте ИИ<\/b>.<\/p>\n
Современные модели и агенты действительно могут сильно ускорять работу. Но в хаотичных и плохо оформленных процессах они гораздо менее эффективны. ИИ хорошо усиливает уже существующую инженерную дисциплину. Если дисциплины нет, он редко становится волшебной таблеткой.<\/p>\n", "summary": "Почему внедрение ИИ в продуктовых командах часто не дает результата? Разбираемся, как delivery-процессы, требования, архитектура и рабочий контекст влияют на эффективность AI-инструментов и кодинговых агентов.", "date_published": "2026-04-08T18:40:09+03:00", "date_modified": "2026-04-08T18:40:06+03:00", "tags": [ "delivery-процессы", "LLM", "ИИ", "управление разработкой" ], "_date_published_rfc2822": "Wed, 08 Apr 2026 18:40:09 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "2", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [] } } ], "_e2_version": 4199, "_e2_ua_string": "Aegea 11.5 (v4199)" }