Лидеры мнений

Когда корпоративный ИИ вступает в эпоху максимизации ценности: чему могут научиться команды разработки от цифровой доступности

mm
Добавьте Unite.AI в избранные источники в Google

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

Скрытая стоимость скорости ИИ

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

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

Согласно IBM, игнорирование технического долга может привести к снижение ROI от 18 % до 29 %. Такие результаты могут нивелировать любые выигрыши в скорости от ИИ. В опросе Deque 2026 года среди 200 лидеров корпоративных инженерных команд 64 % назвали доступность главным драйвером доработок после выпуска, хотя эти же команды явно просили своих ИИ‑агентов писать доступный код.

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

Стратегический ИИ против детерминированных инструментов

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

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

Некоторые инженерные команды решают это, повторно запускают один и тот же обзор и сравнивают результаты. Это работает, но не бесплатно. В собственных экспериментах Deque один проход код‑ревью потреблял примерно 60 % токенов, затраченных на задачу. Само кодирование занимало около 13 %. Написание тестов требовало сопоставимой доли. И один проход обычно недостаточен. Один и тот же обзор часто приходится выполнять от трёх до десяти раз над тем же кодовым базой, прежде чем он охватит полный список реальных проблем. Каждый проход — это новый поиск, а не накопительный, поэтому ничего не переносится от предыдущего запуска.

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

Использование контекста и человек‑в‑цикле

Другой подход, описанный в недавнем кейс‑стади, заключался в сочетании автоматизации и агентного ИИ с человеческим ревью. В новом рабочем процессе организации результаты проверки доступности передавались ИИ‑агенту, который с помощью инструмента исправления применял ожидаемые HTML‑правки непосредственно к исходному коду, а затем автоматически создавал и документировал pull‑request’ы. Инженеры затем проверяли изменения, сгенерированные ИИ, утверждали pull‑request’ы и поддерживали контроль качества и результатов. Итог: возвращено 253 часа инженерного труда, а исправления стали в 98 % быстрее в целом. По оценкам, рабочий процесс сэкономил более 25 000 $ расходов на инженерные ресурсы.

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

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

Но рост расходов не является неизбежным. Цифровая доступность предлагает решение — оно требует нескольких компромиссов: между ИИ и основанными на правилах детерминированными инструментами; между автоматизацией на базе ИИ и человеческой валидацией; и между масштабируемостью и экономичностью. Правильное нахождение этих балансов зависит от дисциплины организации. Чем быстрее организации выработают дисциплину целенаправленного, эффективного и корректного использования ИИ, тем быстрее они смогут ожидать положительные, измеримые результаты от своих инвестиций в ИИ.

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

В качестве технического директора в Deque Дилан имел привилегию возглавлять сторону Deque во многих масштабных проектах по исправлению доступности и консультировать клиентов Deque из списка Fortune 500 по интеграции доступности в их процессы разработки. Он основал семейство продуктов тестирования доступности axe и руководит командами разработки программного обеспечения Deque, расширяя границы масштабируемой доступности. Он опубликовал книгу о практиках успешной гибкой доступности: Agile Accessibility Handbook.