Высокая скорость и атрофия навыков из-за ИИ: какие риски несут и как им противостоять
О том, что ИИ ускоряет работу, говорят все. О том, что ИИ снижает глубину понимания, слышали все. И высокая скорость работы, и трудности с пониманием и передачей знаний становятся источниками рисков и проблем внедрения ИИ. Как снизить эти риски — в статье.
Проблемы возросших скоростей работы и атрофии навыков из-за ИИ поднимает в недавнем объемном эссе Сау Шеонг Чанг (Chang Sau Sheong) — эксперт в области программирования, автор книг и разработчик, заместитель гендиректора по вопросам продуктов и разработки сингапурского Агентства правительственных технологий (GovTech). В блоге — практические рекомендации из эссе, как нивелировать риски.
ИИ ускоряет разработку — и меняет одно бутылочное горлышко на другое
Еще недавно главным дефицитом в ИТ были люди, время, инженерная мощность. Теперь ИИ-агенты берут рутину на себя. Они умеют писать код, собирать прототипы, проверять некоторые гипотезы, предлагать архитектуру и исправлять часть ошибок, особенно в типовых сценариях — и все это быстрее человека. На этом фоне остальные процессы затягиваются. Так узким местом вместо скорости разработки становится скорость принятия решений.
Отсюда и главный вывод: выиграют не те, у кого сильнее команда разработчиков, а те, у кого между «сделать» и «разрешить сделать» лежит гибкая система проверок, и путь от решения до запуска короче.
Как быстрее принимать решения и сохранить надежность
Чем больше контроля, тем медленнее все решается. Контроль нельзя убрать, но можно перестроить. Помогут это сделать:
- заранее одобренные среды развертывания, где типовые, низкорисковые решения запускают без индивидуальной проверки;
- проверки разных уровней: ускоренные для простых сервисов, всесторонние — для критичных систем;
- периодический аудит вместо предварительного контроля, а для этого —
- передача части полномочий ближе командам, которые реально строят продукт.
Конкретные механизмы будут различаться, но общий смысл в том, чтобы ИИ-ускорение не упиралось в старую бюрократию.
Еще важно учесть, что относительно скоро процессы под управлением ИИ-агентов станут нормой. И тогда платформы, простые в использовании для людей, но непрозрачные для агентов, тоже станут тормозить работу.
Это значит, что при проектировании АПИ (API) уже сегодня надо начать учитывать, как их будут использовать и люди, и ИИ-агенты. Метаданные системы должны быть полными, чтобы агенты могли анализировать зависимости и их влияние. А модели разрешений должны быть детализированными, чтобы предоставлять агентам необходимую автономию, не подвергая системы неприемлемому риску.
Как решать вопрос ответственности
Если ИИ-агент внес ошибку в код, кто виноват? Разработчик, который нажал «одобрить»? Компания, которая внедрила инструмент? Поставщик модели?
Так все важнее становится управленческая ясность. Нужно четко определить: кто принимает решение о запуске, кто отвечает за последствия, где проходит граница между автономией ИИ-инструментов и контролем человека и т.д. Чем выше скорость, тем точнее должны быть роли сотрудников и агентов. Иначе компания будет либо слишком тормозить, либо слишком рисковать.
Почему ИИ вызывает атрофию навыков
Атрофия навыков, которую некоторые называют даже «AI-деменция», развивается постепенно. Сначала программист перестает читать код, потому что ИИ может его пересказать. Затем перестает отлаживать, потому что ИИ-агент сам исправляет ошибки. В итоге человек перестает проектировать, потому что ИИ предлагает архитектуру. Со временем программисты все хуже понимают сгенерированный ИИ или написанный другими людьми код и теряют навыки его написания.
Чем чревата атрофия навыков из-за ИИ
Пока система работает, команда продуктивна, скорость работы высока, атрофию навыков не видно. Но уходят «мышечная память» и интуиция: навыки работы с кодом и способность чувствовать, что в системе не так, замечать слабое место до того, как это приведет к инциденту. Выявлять и исправлять ошибки ИИ тоже становится непросто. Интуиция, постоянная погруженность в контекст, опыт выделяют сильного разработчика. Если все промежуточные действия берет на себя ИИ, человек рискует стать быстрым в нормальных условиях, но беспомощным, когда что-то действительно новое пойдет не так.
Для бизнеса всё это опасно. Потеря понимания — это риск простоя, сбоев, регуляторных нарушений и дорогостоящих ошибок в критичных системах.
Как минимизировать риски
Вместо борьбы с ИИ как с угрозой, во-первых, стоит проектировать работу, чтобы сотрудники продолжали работать с кодом и понимать его. Во-вторых, нужно сделать ИИ-агентов управляемыми.
Как позаботиться о сохранности навыков сотрудников
- Например, требовать спецификацию до того, как ИИ начнет писать код. Это простое правило заставляет сначала подумать, что именно надо сделать, а уже потом отдавать работу машине.
- Еще полезно чередовать ручную работу и работу с ИИ. Человеку нельзя полностью выпадать из процесса, чтобы навыки не деградировали.
- Поспособствует сохранности знаний ревью не только как контроль качества, но и как обучение. Во время проверки кода программист будет глубоко вникать в написанное.
Смысл мер один: не повышать скорость работы ценой понимания.
Как сделать ИИ-агентов управляемыми и надежными
Здесь помогут архитектурные меры защиты. Традиционные программные примитивы, такие как АПИ (API), базы данных и конвейеры развертывания, важно дополнить новыми решениями, разработанными для взаимодействия с ИИ-агентами, поскольку они читают документацию не так, как люди, и не перемещаются по пользовательским интерфейсам. ИИ-агентам необходимы машиночитаемые описания возможностей, структурированный контекст о системах, с которыми они работают, и четкие границы того, что они могут и чего не могут делать. То есть следует внедрить:
- реестры инструментов, чтобы ИИ-агенты динамически обнаруживали и использовали подходящие возможности;
- контекстные протоколы, чтобы ИИ-агенты обменивались состоянием и контекстом принятия решений;
- системы разрешений и доверия, которые определяют, что ИИ-агенты могут делать автономно, а что требует одобрения человека;
- системы памяти и обучения, с помощью которых ИИ-агенты смогут совершенствоваться на основе опыта, то есть сохраненных в базе знаний удачных траекториях решения задач;
- графы знаний в дополнение к файлам Markdown, чтобы зафиксировать связи между концепциями;
- рассмотрение истории как данных, потому что история итераций и решений ценнее, чем конечный код;
- ориентация на источник знаний: вместо копирования документации в промпт, агент должен иметь доступ к актуальному единому источнику данных (Single Source of Truth, SSoT), чтобы не было проблем с синхронизацией;
- использование модели «запроса» (Pull), а не «выдачи» (Push), чтобы ИИ- агент сам делал поисковый запрос в базу знаний или АПИ в нужный момент («Pull») во время выполнения, а не чтобы правила поддавались в промпты («Push»).
Нужны также опции для корректного отката без повреждения базы данных, агенты управления инцидентами, чтобы скоординировать реакцию, а также унифицированные реестры, где разрозненные журналы сведены в единый источник достоверной информации. Если агент что-то изменил и «все сломал», компании понадобится возможность полностью и корректно откатить все изменения, в том числе состояние данных. Без этого автономность становится слишком рискованной для важных систем.
* * *
ИИ действительно ускоряет разработку. Но из-за этого компаниям приходится учиться быстрее принимать решения, сохранять понимание и удерживать контроль над рисками. Победят не те, кто просто первыми внедрят ИИ в разработку. Победят те, кто перестроит управление, ответственность, безопасность и память организации под новую скорость.