Почему готовые решения ИИ разочаровывают команды — и что с этим делать

В случае большинства технологий, чем дольше вы их используете, тем более спокойно вы начинаете на них полагаться. С инструментами ИИ все происходит наоборот: в своем ежегодном опросе более 49 000 разработчиков Stack Overflow зафиксировал рост использования до 84%, в то время как доверие к точности этих инструментов упало с 40% до 29% за один год.

Этот эффект знаком мне. Наш первый опыт работы с инструментами ИИ в разработке мало чем отличался от того «вау-эффекта» более быстрой работы и меньшего количества рутинных задач, о котором писала техническая пресса. Наши разработчики были разочарованы: ИИ производил посредственный код, который требовал много времени на проверку и в конечном итоге должен был быть переписан. Команда ожидала, что ИИ сэкономит время, но вместо этого получила дополнительную работу. Итак, вскоре после первых попыток интегрировать инструменты ИИ в ежедневный рабочий процесс команда вернулась к своей привычной работе.

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

Почему код, написанный ИИ, разочаровывает разработчиков

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

Но «среднее» не является потолком того, что возможно — это просто то, что модель выдает, пока не узнает ваш проект: его соглашения, структуру кода, архитектурные решения. В опросе более 600 разработчиков Qodo обнаружил, что среди тех, кто был недоволен качеством кода ИИ, 44% связывают это именно с отсутствием контекста. Это то, что держит вывод на среднем уровне.

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

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

В своем отчете Octoverse 2025 GitHub описывает именно этот сдвиг: разработчики, которые продвинулись дальше всего с ИИ, больше не называют себя «авторами кода» и становятся чем-то ближе к его «креативным директорам», где ключевым навыком является управление и проверка. Но путь к этой роли проходит через ошибки и разочарование, пока человек не увидит результат в своей собственной работе.

Что превращает ИИ из источника разочарования в рабочий инструмент

Когда наша команда впервые начала использовать ИИ, некоторые разработчики работали с Claude Code, другие пробовали OpenAI Codex, GitHub Copilot или Gemini CLI, и каждый инструмент давал разный результат. Итак, когда мы начали наводить порядок в том, как команда работает с ИИ, первое, что мы сделали, — это выбрали единый инструмент.

Это не только наша практика. Возьмем историю команды Linear: до начала 2026 года они работали по принципу «пусть каждый работает так, как ему нравится», и в январе руководство отказалось от этого подхода и перевело всех на единый способ работы — ограничив выбор двумя инструментами ИИ и попросив разработчиков писать код только с их помощью, а не вручную. Согласно компании, средняя производительность возросла уже на следующий месяц на 30% по объединенным запросам на слияние и на 33% по задачам, закрытым на каждого инженера.

Тем не менее, единый инструмент сам по себе не улучшает код — его необходимо настроить: установить правила, что-то вроде rules.md, которые определяют, как писать код — какие подходы следует использовать, что следует избегать. Затем следуют пользовательские навыки для задач, типичных для вашего проекта, чтобы не объяснять одно и то же несколько раз. И, наконец, стоит указать агенту на ваш существующий кодовый фонд: он анализирует, как написан проект, и производит новый код в том же стиле, а не в общем. Чем больше контекста получает инструмент, тем меньше вам приходится переписывать вручную позже.

Но самая сложная часть не техническая. Сдвиг от автора кода к его оценщику не происходит сам по себе — этот переход требует помощи. Самый прямой путь — обучение и сертификация. В нашем случае, например, десять разработчиков проходят партнерскую программу с поставщиком инструмента, а вместе с ними работает человек, ответственный за внедрение, который объясняет, почему инструмент дал тот или иной результат и как его исправить.

Как только команда начинает работать в координированном порядке, остается одна узкое место — проверка — и стоит ее укрепить с помощью ИИ. Агент проходит через каждый запрос на слияние и берет на себя очевидное: рутинные ошибки, стиль, повторения, пробелы в безопасности. Человеческий проверяющий больше не смотрит на все без разбора, а только на архитектуру и критические решения. Эффект заметен даже внутри компаний, которые строят эти инструменты: в Anthropic после введения такого агента доля запросов на слияние, получивших существенную проверку, возросла с 16% до 54%, и инженеры не согласились с менее чем 1% его комментариев.

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

Где доверие к инструментам ИИ оправдывается

Прежде всего — в написании кода: когда инструмент знает проект, а агент занимается первой проверкой, команда пишет больше и лучше за то же время. В нашем случае инструменты ИИ ускорили работу примерно на 30-40%.

Кроме того, ИИ сделал процесс интеграции новых сотрудников проще. Когда новый человек присоединяется к проекту, обычно кто-то опытный должен ответить на десятки вопросов о том, как устроен код проекта. Теперь агент берет на себя эту роль: если проект хорошо документирован, новичок направляет до 95% этих вопросов к нему, а не к коллегам.

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

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

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