ИИ в разработке: опыт и выводы

Разговоры об использовании ИИ в разработке давно ушли от уровня «генерировать код» к более сложной теме - как встроить LLM в реальные процессы так, чтобы они приносили пользу, а не создавали иллюзию автоматизации. На практике выясняется, что подключить ИИ к пайплайну - самая простая часть. Сложнее добиться предсказуемого и воспроизводимого результата.

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

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

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

Отдельная проблема - изолированность задач. В реальных проектах тикет почти никогда не существует сам по себе. Он связан с другими задачами, входит в эпик, может пересекаться с соседними изменениями. Если ИИ анализирует только одну задачу, он может выдать логически корректный, но системно вредный результат. Например, предложить проверки, которые конфликтуют с требованиями другой части функциональности. Поэтому важным элементом становится кросс-анализ: сопоставление требований внутри эпика, поиск противоречий и проверка согласованности ещё до этапа тестирования.

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

Отдельного внимания заслуживает вопрос хранения и поиска знаний. Популярный подход с семантическим поиском по текстам выглядит привлекательно, но на практике часто даёт нестабильный результат. Поиск по «похожести» неизбежно приводит к тому, что в контекст попадают нерелевантные фрагменты. Для задач, где важны точные зависимости и причинно-следственные связи, это становится критичным. Более надёжным оказывается использование структурированных форматов, где явно заданы связи между сущностями. В таком виде ИИ не ищет похожее, а читает конкретное и заранее определённое.

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

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

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