За пределами кода: чего не хватает ИИ-помощникам в разработке

Мы подошли к точке, когда ИИ уже уверенно пишет код. Дайте ему понятную задачу и достаточно контекста — и он выдаст рабочий результат. Но между «функциональным кодом под конкретную задачу» и «кодом, которому можно доверять в enterprise-проекте», всё ещё огромный разрыв.

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

Проблема контекста: почему ИИ постоянно всё забывает

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

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

В итоге разработчик вместо того, чтобы писать код, становится «менеджером контекста» — постоянно объясняет ИИ, что уже было решено раньше.

Проблема верификации: ИИ не может сам проверить свою работу

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

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

Что изменится, когда эти проблемы будут решены

Представьте агента, который помнит все архитектурные решения команды, знает доменную логику и помнит, какие подходы уже не сработали в прошлом. И при этом он может самостоятельно запускать тесты и проверять изменения в условиях, близких к production.

В этом случае инженер перестаёт писать код руками. Его задача — формулировать требования, описывать критерии приёмки и задавать направление. Всё остальное — реализация, тестирование, рефакторинг — делает машина.

Что это значит для вашей инфраструктуры

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

Начните с трёх вопросов:

• Как безопасно дать автоматизированной системе возможность проверять изменения?
• Как у вас сейчас фиксируются архитектурные решения и командные знания?
• Готова ли ваша CI/CD-инфраструктура к автономной верификации?

Дальше дело будет не в мощности моделей, а в том, насколько ваша инфраструктура и процессы позволят этим моделям реально участвовать в командной разработке.