Александр Сиволобов: «Искусственный интеллект – это новый тип рабочей силы»

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

Скорость прототипа

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

Вторая область применения связана с догоняющим развитием. Небольшая команда ArtCraft из США воспроизвела интерфейсы и значительную часть функций Adobe Photoshop, Adobe Premiere Pro и программ Microsoft Office за недели и месяцы. По оценке Сиволобова, возможности больших языковых моделей за последние полгода выросли настолько, что круг программных продуктов, которые нельзя повторить в ограниченный срок, заметно сократился.

С оборудованием сложнее. Физическое клонирование остаётся тяжёлым инженерным процессом, и перенести этот эффект на железо пока нельзя. Отдельный сценарий, который Сиволобов приводит для обоснования скорости, связан с устранением уязвимостей. По его словам, без ИИ такие задачи раньше занимали годы, а Линус Торвальдс теперь готовит доработки ядра Linux с его помощью. Здесь особенно важна проверка результата: высокое темпо исправлений само по себе не является гарантией безопасности.

Граница применимости

Самый жёсткий показатель у Сиволобова связан с текстом. Тексты ИИ-агенты пока создают хуже всего: приемлемый результат, не требующий глубокой переработки, получается примерно в 20% случаев. В первом полугодии года этот показатель был ниже 5%.

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

«Иртея» пока не перевела на ИИ основную деятельность: разработку оборудования и ПО для базовых станций, интеграцию и испытания. Перестройка идёт частично. Одновременно компания создаёт инфраструктуру для моделей в собственном контуре, on-premises.

Что проверять до переноса задачи

До включения агента в разработку нужен короткий, но строгий протокол:

• Единица работы. Сравнивать с человеком нужно один законченный и принятый модуль, включая тесты, исправления и документацию.
• Полная стоимость. Учитывать API, повторные запуски, проверку и переделку результата.
• Граница данных. Если модель нельзя размещать во внешнем контуре, инфраструктура on-premises становится частью проекта, а не техническим дополнением.
• Разделение генерации и приёмки. Код, документацию и аналитику от агента следует принимать независимо, по заранее заданным критериям.
• Ограничение охвата. Физическое оборудование, интеграция и испытания пока остаются зоной, где прототипный выигрыш ИИ нельзя автоматически переносить на весь процесс.

ИИ-слой уже выходит из инженерных лабораторий в цифровые сервисы. Смежный материал: смотреть дорамы и азиатские сериалы онлайн бесплатно. В инженерном контуре действует то же правило: быстрый результат имеет цену только после проверки.