Три множителя для AI-ускорения

Минувшие две недели были крайне насыщенными: Podlodka AI, а вместе с этим подготовка и участие в TechLead. Всё это заняло большую часть моего свободного времени и отодвинуло все остальные активности на второй план. Но всё было не зря – концентрат полученной информации заставляет по-новому взглянуть на уже знакомые вещи или начать изучать что-то новое.

Вполне ожидаемо, что всё, что было на TechLead, так или иначе было вокруг темы ИИ, даже несмотря на отдельно выделенный ИИ-трек.

Ключевая мысль, которую я для себя вынес, выражается простой математической формулой:

AI_boost = AI_adoption × AI_infrastructure × SDLC

Иначе говоря, прирост производительности, который может дать ИИ, зависит от трёх множителей:

• Степень использования ИИ среди сотрудников. Как часто и какой объем работ сотрудники компании делегируют ИИ-инструментам? Насколько хорошо они знакомы с такими инструментами и понимают их границы применимости? Ответственные – сотрудники и AI-амбассадоры компании.
• Уровень развития ИИ-инфраструктуры в компании. Вам настроили VPN? Купили подписки? Обеспечили инструментарием? У вас есть базовый минимум, чтобы только начать пользоваться ИИ? Или каждый сотрудник обо всём этом должен заботиться сам? Ответственные – руководство компании.
• Процесс разработки программного продукта. Он у вас вообще начал меняться? Вы начали переход на SDD-like-фреймворк? Начали настройку контекста и пайплайна? Описание бизнес-требований адаптируется под AI-friendly-формат (например, Markdown)? Начали задумываться об evals и quality gates? Ответственные – техлиды и архитекторы.

Обнули хотя бы один множитель и получишь ноль.

Это чистая математика – для нахождения вероятности наступления двух и более событий нужно умножить вероятности наступления каждого. Аналогичный подход используется для определения уровня доступности сервиса.

За формулу можно поблагодарить докладчика из Яндекса – Олега Смолякова, который выступил с темой “Как ИИзировать 10 тысяч инженеров” (презентация). С его слов они пытаются достичь 0.75 по каждому показателю.

Всё это, безусловно, увеличивает стоимость владения проектом. Хочешь ускорение, тогда не получится “как раньше”, придётся подтягивать всё то, на что всегда не хватало времени. Вполне возможно, что для некоторых такая дисциплина может стать непосильной ношей, но двигаться в эту сторону всё равно придётся.

Продолжая тему, многие докладчики и участники конференции подтвердили необходимость пересмотра SDLC, выстраивания SDD-like-фреймворка, проектирования контекста и настройки пайплайна, который обязательно должен включать не только quality gates, но и fallback-стратегии на каждом шаге. Также пришли к практическому заключению, что использование большого количества параллельно работающих агентов (более 4) чаще всего приводит к деградации. В результате настраивают последовательный пайплайн, в котором каждый шаг выполняют, используя специализированную роль со своим набором skill-ов (архитектор, разработчик, тестировщик и т.д.).

---

Конечно, это не всё, о чём можно рассказать, но, пожалуй, это структура, на которой был построен этот сезон TechLead.

Второе важное отличие от предыдущих сезонов – это практическая направленность. Половина контента, как и обещали организаторы, была выполнена в виде воркшопов.

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