← Все статьи

Где AI-конвейер ошибается: семь мест, за которыми всё равно нужен инженер

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

Ниже — семь мест, в которых сбои случаются регулярно. Это не теория: каждое встречается в работе, и для каждого есть проверка, которая его ловит.

1. Выдуманные факты, поданные уверенно

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

Как ловится. Только исполнением. Код, который не собирается, не проходит дальше; вызов несуществующего метода падает на первом же прогоне. Поэтому в конвейере ценность имеет не «прочитать и одобрить», а «запустить и посмотреть». Написанное, но ни разу не выполненное — это черновик, а не результат.

2. Правка не в том месте

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

Ошибка «мимо цели» опасна тем, что выглядит как успех: изменение внесено, ошибок нет, и только потом выясняется, что пострадала соседняя часть.

Как ловится. Сверкой перед выкладкой: не «что я хотел изменить», а «что изменилось на самом деле». Полезная привычка — держать список того, что проект умеет (страницы, методы, экраны), и перед публикацией сравнивать его с прежним. Если из списка что-то пропало, а вы этого не планировали, — это не выкладка, это авария.

3. Дубли вместо переиспользования

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

Как ловится. Правилом «сначала прочитать, потом писать». Прежде чем добавлять возможность, проверяется, нет ли её уже — и если есть, доводится существующая. На стороне заказчика этот сбой виден без всякого кода: если в системе появляются две похожие сущности, задайте вопрос, почему их две.

4. Права доступа и приватность

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

Как ловится. Проверкой из-под другой роли, а не из-под администратора. Это единственный надёжный способ, и он не требует программиста: заведите тестовую учётную запись с ограниченным доступом и открывайте новые разделы под ней. Отдельная тема — публичные ссылки: у них должны быть срок жизни, возможность отзыва и запрет на индексацию поисковиками.

5. Регресс: починили одно — сломали соседнее

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

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

6. Язык, локаль и мелочи, которые не мелочи

Целый пласт ошибок живёт в русском языке и в оформлении. Поиск не находит слово, набранное с заглавной буквы. Склонение съезжает: «5 задача» вместо «5 задач». В шрифте нет нужного символа — и вместо стрелки пользователь видит пустой квадрат. На бумаге пропадает колонка, потому что ширина листа оказалась меньше, чем ширина, на которой прячут лишнее на телефоне.

Как ловится. Проверкой на настоящих данных, а не на «test test». Русские названия, длинные строки, кириллица в разном регистре, печать реального документа. Это дешёвая проверка, которая ловит непропорционально много.

7. «У меня работает»

Последний сбой — не в модели, а в процессе. Результат объявляется готовым, потому что выглядит готовым: код написан, логика правильная. Но никто не открыл это в браузере, не нажал кнопку, не посмотрел на телефоне.

Как ловится. Требованием прикладывать к работе доказательство: снимок экрана, ответ сервера, результат прогона. Не отчёт о том, что сделано, а подтверждение того, что работает. Это же требование стоит предъявлять любому подрядчику независимо от того, применяет он ИИ или нет.

Что из этого следует для заказчика

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

Практический способ оценить подрядчика — задать три вопроса:

1. Чем измеряется, что задача сделана, кроме слова «готово»?
2. Что происходит, если выкладка сломала работающее, — есть ли откат и за сколько минут?
3. Как вы узнаёте, что правка задела соседнее?

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

Короткие ответы на частые вопросы

Можно ли доверить искусственному интеллекту разработку целиком?

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

Что такое галлюцинация модели простыми словами?

Это уверенно сформулированный, но выдуманный факт: несуществующий метод, поле или настройка. Опасность не в самой ошибке, а в её убедительности — выглядит как правда, поэтому ловится не чтением, а проверкой.

Как понять, что подрядчик действительно проверяет работу ИИ?

По следам проверки. Спросите, чем именно измерен результат: автотесты, проверка в настоящем браузере, сверка изменений перед выкладкой, возможность отката. Если ответ сводится к «мы всё смотрим глазами», проверок нет.

Кто отвечает, если ошибку допустил ИИ?

Подрядчик. Инструмент не может быть стороной договора. Ответственность за результат не делится на «это машина написала» и «это мы написали».

ИИ ускоряет разработку или только создаёт видимость?

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