Лишь около 5 000 человек действительно увидели, на что способен современный ИИ, — такую оценку привёл Андрей Карпати, один из участников ранней команды OpenAI. Его тезис не о том, что остальные не пробовали чат-боты, а о том, что между разовой генерацией текста и работой с ИИ как с инструментом есть огромный разрыв возможностей ИИ. Для русскоязычных разработчиков, продактов и руководителей это повод смотреть не на громкие демо, а на то, какие рабочие процессы уже можно перестроить.
Как сообщает The New Stack, Карпати считает, что большая часть людей пока имеет весьма поверхностное представление о реальном потенциале моделей. В публичном поле ИИ чаще выглядит как собеседник, генератор писем, иллюстраций или кратких резюме. Но у специалистов, которые много и системно работают с моделями, опыт другой: они разбивают задачи на шаги, задают контекст, проверяют промежуточные результаты, подключают инструменты и получают результат, близкий к работе цифрового исполнителя.
Число «5 000» здесь, конечно, не статистика переписи пользователей. Это намеренно резкая оценка масштаба: круг людей, которые успели проверить современные модели на сложных, многошаговых задачах, пока несопоставим с аудиторией популярных AI-сервисов. Миллионы могут пользоваться функцией «написать текст», но гораздо меньше команд пытаются поручить модели подготовку исследования, разбор репозитория, сбор вариантов решения, работу с документацией или последовательную обработку большого массива данных.
Именно отсюда возникает разрыв ожиданий. Один пользователь делает несколько неточных запросов и заключает, что ИИ красиво формулирует банальности. Другой строит вокруг модели повторяемый процесс: даёт ей исходные данные, ограничивает задачу, разбивает работу на этапы и вводит обязательную проверку человеком. В первом случае это занятный интерфейс. Во втором — новый слой в инженерном или операционном процессе. Качество модели важно в обоих сценариях, но качество постановки задачи и контроля результата меняет эффект не меньше.
Для разработчиков тезис Карпати особенно практичен. Генерация фрагмента кода сама по себе редко решает проблему: его нужно встроить в архитектуру, покрыть тестами, проверить безопасность и сопровождать после релиза. Более полезный сценарий — использовать модель там, где она ускоряет понятную часть цикла: разбор незнакомого кода, подготовку тестовых случаев, объяснение логов, черновик миграции, поиск несостыковок в требованиях. Это не отменяет ревью и не превращает LLM в ответственного инженера. Зато снижает стоимость первого прохода по рутинной, но интеллектуально ёмкой работе.
Для продуктовых и бизнес-команд вывод не менее неудобный. Если измерять внедрение ИИ числом купленных лицензий или количеством сгенерированных сообщений, легко получить презентацию вместо эффекта. Важнее выбрать конкретную цепочку действий, определить владельца процесса и заранее решить, где модель может действовать самостоятельно, а где обязана передать результат человеку. Например, служба поддержки может поручить ИИ подготовку черновика ответа и поиск релевантной информации, но не отправку чувствительных сообщений без контроля. Команда разработки может автоматизировать первичный анализ тикетов, но не закрытие инцидентов по ответу модели.
Разрыв возможностей ИИ также объясняет, почему рынок одновременно слышит две противоположные истории. Одни компании сообщают о заметном росте скорости отдельных операций, другие не находят убедимого эффекта от пилотов. Обе реакции могут быть честными. Пилот, который добавили к старому процессу без доступа к данным, без понятной цели и без обратной связи, почти неизбежно останется игрушкой. Пилот, встроенный в повторяемую задачу с измеримым результатом, способен дать пользу даже при ошибках модели — если эти ошибки ловит процесс.
В оценке Карпати есть и важное предупреждение против технологической самоуверенности. Увидеть сильную демонстрацию ещё не значит получить готового автономного сотрудника. Модели могут ошибаться, терять контекст, уверенно выдавать неверные сведения и плохо справляться с нестандартными ограничениями. Поэтому зрелая работа с ними строится не на вере в «магический промпт», а на проверяемых данных, ограниченных правах доступа, логировании действий и понятных критериях качества.
Вероятно, ближайшая конкуренция развернётся не только между самими моделями, но и между командами, которые научатся превращать их возможности в надёжные рабочие контуры. Вопрос уже не сводится к тому, пробовал ли сотрудник чат-бот. Вопрос в том, смогла ли организация сократить время на конкретную задачу, не потеряв в качестве, безопасности и ответственности за результат.