Как мы внедряли ИИ на проекте: успехи и провалы

Успехи: где ИИ реально дал value, но не без жертв

1. Документация: от творчества к аудиту (со скрытыми затратами).
ИИ превратил написание ТЗ в процесс "генерации противоречий" — модель системно находит edge-кейсы (пересечение смен с праздниками, отрицательные балансы), которые команда упускает.
Но цена вопроса — технический долг в документации: ИИ генерирует переписанные требования, которые потом нужно верифицировать на полноту. Экономия времени на аналитику нивелируется временем на редактуру.

ИИ — не замена аналитика, а инструмент выявления пробелов, требующий пост-фильтрации.

2. Data masking: прокси-слой между продакшеном и промптом
Ключевое внедрение — не "отправка чувствительных данных в ИИ", а создание изолированного пайплайна анонимизации перед генерацией документации. Маскирование ФИО и ID заказов позволило использовать production-like контекст для "Тарификации", но добавило точку отказа: если маскировка сломается или будет предсказуема, мы получаем data leak.

Безопасность — не параметр промпта, а отдельная инфраструктурная задача с собственными рисками.

3. QA-автоматизация: ловушка локального максимума
Генерация boilerplate для API/UI тестов и хелперов сокращает time-to-first-test, но создает хрупкое наследие. ИИ пишет тесты, которые проходят, но не проверяют интеграционные границы (mocks синхронизированы с реальностью только на момент генерации). Через три спринта такие тесты требуют полного рефакторинга.

Скорость покрытия ≠ качество покрытия. Автотесты от ИИ нуждаются в архитектурном ревью, иначе это мертвый код.

4. Opencode: когда агент начинает действовать против архитектуры
Переход от Copilot к агенту, который видит кодовую базу, — это не "code review на стероидах", а риск архитектурной деградации. Агент исправляет ошибки компиляции, подгоняя код под существующие костыли, вместо рефакторинга. Он оптимизирует локально (тест прошел), но деградирует глобально (цикломатическая сложность растет).

Автономность ИИ обратно пропорциональна контролю над архитектурой.

Провалы: системные ограничения, которые нельзя обойти костылями

5. Корпоративный периметр: конфликт zero-trust и cloud-AI Copilot не работает под корпоративным VPN не потому, что "плохой интернет", а потому что enterprise-политики DNS/DLP блокируют трафик в сторонние API. Попытки работать через VS Code extensions с включенным/выключенным VPN создают UX-ад и риски утечки (accidental exposure кода при переключении сети).

Это архитектурный конфликт между perimeter security и SaaS-ИИ. Решение — только on-premise модели или гибридные шлюзы, а не "костыли с VPN".

Контекстный голод: иллюзия понимания архитектуры
Невозможность скормить 500k строк кода приводит к "галлюцинации абстракций": ИИ предлагает использовать методы из версии библиотеки 2.0, когда в проекте 1.5, или создает "util-функции", дублирующие существующие, но с другим названием. Это не просто ошибки — это внедрение технического долга под видом оптимизации.

Partial context дает уверенные неправильные решения. ИИ не понимает архитектуру — он предсказывает токены на основе фрагментов.

7. RAG: векторный поиск не гарантирует истину Внутренний помощник на RAG (векторный поиск по Confluence) решает проблему галлюцинаций только если retrieved chunks содержат актуальную информацию. На практике: устаревшая документация, дублирующиеся конфликтующие страницы, и "ближайшие по смыслу, но нерелевантные" чанки дают правдоподобные, но неверные ответы. Фактчекинг в реальном времени требует human-in-the-loop.

RAG снижает галлюцинации, но вводит "ошибки релевантности" — когда модель находит похожий, но не тот документ.

Выводы: прагматичный подход или "как не сломать проект"

8. Граница ответственности: где ИИ — инструмент, а где — риск
Документация и edge-кейсы: ИИ как "второй мозг" для перебора вариантов (ACCEPT)
Маскирование данных: Автоматизированный пайплайн с аудитом (CONTROL)
Acceptance Criteria: ИИ для генерации draft, человек для бизнес-логики (REVIEW)
Архитектурные решения и рефакторинг: Только human (REJECT — ИИ не видит полной картины)
9. Метрика успеха: время на ревью ИИ-кода Нельзя мерить "скорость написания".
Нужно мерить:
Time-to-correct: сколько времени тратится на исправление сгенерированного кода/тестов -幻觉率 (Hallucination rate): процент предложений ИИ, которые пришлось откатить
Техдолг от ИИ: количество "временных" решений, оставшихся в коде
Акцент: Настоящий ROI — когда ИИ находит баги, а не когда он пишет код быстрее junior'а.

10. Организационная зрелость как prerequisite
Внедрение ИИ требует зрелости DevOps (настройка пайплайнов маскирования), зрелости архитектуры (чистые интерфейсы, которые ИИ может понять по контексту), и зрелости процессов (code review, который отлавливает ИИ-шные костыли). Без этого вы получаете "быстрый спагетти-код".

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