Паша AI AI AI

AI требует от компаний новой операционной модели

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

Консалтинговая фирма опросила 750 руководителей. Они говорят, что сотрудники с помощью чат-ботов и копилотов быстрее готовят письма и отчеты, но компании продолжают работать по прежним правилам. 70% опрошенных руководителей считают себя готовыми использовать AI, но лишь 27% уверены, что их компании способны перестроить связанные с ним процессы, роли и методы управления. При этом именно организационная готовность объясняет 48% различий между теми, кто уже получает измеримый эффект от AI, и теми, кто пока его не видит.

На основе исследования аналитики выделили три этапа перестройки компании вокруг AI:

• На первом сотрудники используют универсальные AI-инструменты на своих должностях. Даже здесь простого доступа к технологии недостаточно — руководители компаний, изменивших рабочие процессы, в 5,3 раза чаще сообщали о бизнес-эффекте.

• На втором — AI встраивается в процессы, проходящие через несколько подразделений. О заметном эффекте в этом случае сообщили уже 24% руководителей.

• Третий этап предполагает полное переосмысление работы — компания заново проектирует роли, процессы и модель с учетом возможностей сотрудников и AI-агентов. До этого уровня дошли только 11% организаций, однако уже 48% из них сообщили об измеримом бизнес-эффекте автоматизации.

Близкую к третьему этапу модель Gartner называет AI-shaped organization. В ней работа строится вокруг создаваемой ценности, а небольшие автономные команды объединяют техническую и отраслевую экспертизу. Платформенные команды поддерживают AI-инфраструктуру и контролируют качество решений, тогда как AI берет на себя отчетность и сбор статусов. В свою очередь, менеджеры сосредотачиваются на целях, развитии людей и ответственности за общий результат.

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

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

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

Зачем будущему инженеру писать код без ИИ

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

Успешное выполнение задания с ИИ не гарантирует освоения материала. В исследовании, опубликованном в PNAS, почти тысяча школьников изучала математику с помощью GPT-4. Участники, использовавшие обычного чат-бота, выполняли тренировочные задания на 48% лучше контрольной группы, но на последующем экзамене без ИИ показали результат на 17% хуже. Другая версия ИИ-тьютора опиралась на подготовленные преподавателями решения и подсказки, направляя ученика к самостоятельному ответу. Во время занятий результаты этой группы выросли на 127%, а на экзамене статистически значимого отличия от контрольной группы не обнаружили.

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

В инженерном образовании это различие можно учитывать, постепенно расширяя роль ИИ:

• На первых курсах — освоение основ через самостоятельную практику. Студенты пишут код, изучают алгоритмы, структуры данных и управление памятью, разбираются с ошибками. Инженерная интуиция формируется в том числе во время отладки, когда предположение о работе программы приходится проверять на ее реальном поведении. ИИ при этом может выступать помощником, который объясняет концепции и предлагает направление поиска, но не подменяет решение. Похожий подход используется в Harvard CS50: студентам доступен специальный помощник CS50 Duck, а использование ChatGPT для выполнения заданий ограничено правилами курса.

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

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

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

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

Кто будет становиться сеньором, если ИИ заберет задачи джунов?

Представьте команду, где пять разработчиков с ИИ-ассистентами справляются с работой, для которой раньше требовалось двадцать. Для бизнеса это звучит заманчиво. Но возникает вопрос: если модели возьмут на себя простые задачи, на которых набираются опыта начинающие программисты, кто через несколько лет станет сеньором? В марте 2025 года глава Anthropic Дарио Амодеи предположил, что вскоре ИИ будет писать до 90% кода. А Андрей Карпаты популяризировал вайб-кодинг — разработку, в которой программу создают через диалог с моделью, иногда даже не изучая полученный код.

ИИ уже активно используют для автоматизации разработки. Anthropic проанализировала 500 тысяч взаимодействий с Claude.ai и Claude Code. Среди популярных сценариев — те задачи, с которых обычно начинается карьера джуна. И хотя эти данные не доказывают исчезновение джуниорских позиций, они показывают, какие виды работы могут измениться первыми.

Но больше написанного кода не означает больше готовых продуктов. Исследование экономистов Гарварда, охватившее 718 компаний, показало, что после внедрения ИИ-агентов объем написанного кода вырос примерно на 30%, а время от создания pull request до его слияния — на 49%. При этом статистически значимого увеличения числа завершенных задач исследователи не обнаружили. Получается парадокс: генерировать код становится проще, но проверка, интеграция и сопровождение решений могут превращаться в узкое место разработки.

Главная проблема — как теперь выращивать опытных инженеров. Джуны учатся не только писать код, но и разбираться в чужих решениях, исправлять ошибки, проходить код-ревью и понимать последствия архитектурных компромиссов. Если значительная часть этой работы перейдет к ИИ, привычный путь профессионального роста придется пересматривать. Один из вариантов — создавать в университетах инженерные команды, которые поддерживают реальные системы, работают с техническим долгом и отвечают за качество решений. Параллельно усиливать фундаментальную подготовку: алгоритмы, математику, архитектуру, безопасность и верификацию программ.

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