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

Написать эту статью меня сподвигнул услышанный недавно краем уха разговор:

— Пару дней назад наш CEO собрал всю команду и с громким воодушевлением и пафосом показал прототип, который он смог навайбкодить за пару недель.

— Не поверишь, но у нас произошла точь-в-точь ситуация.

— Да, наверное, сейчас в каждой компании приходит менеджмент и говорит «AI, AI, AI, AI».

— Я ожидаю, пока такие парни и девчонки понавыпускают кучу прототипов в прод и получат репутацию low-quality продуктов.

—Раньше был чайка-менеджмент, а сейчас ai-менеджмент.

После всех моих разговоров с людьми у меня в голове сложилась следующая картина:

1. БОльшая часть менеджмента переоценивает возможности ИИ.

2. БольшАя часть разработчиков недооценивает возможности ИИ.

3. БольшАя часть менеджмента не осознает, что разработчики уже используют ИИ достаточно глубоко.

4. БольшАя часть разработчиков отрицает развитие ЛЛМок: попробовав что-то накодить однажды, они разочаровались и больше не развивались в этой теме.

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

Дружим менеджмент и разработчиков

Консервативная массовая разработка имеет следующий паттерн:

1. Бизнес хочет протестировать гипотезу (фичу).

2. На основе гипотезы менеджмент формирует задачу.

3. Разработчик оценивает задачу и дает обещание, что выполнит задачу в определенный срок.

4. Задача тестируется и отдается в прод.

5. Ответственность за неисправности ложится на разработчика и тестировщика.

6. Ответственность за успешность гипотезы ложится на бизнес или менеджмент.

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

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

1. Бизнес решил протестировать гипотезу, мы имплементировали и поняли, что ЛЛМ не способна выполнить задачу — кто несет ответственность?

2. Если мы даем ЛЛМ возможность выполнять деструктивные действия (запись в базу, POST-запрос на API), мы перекладываем ответственность за ошибки на юзера, бизнес или разработчика?

3. Как тестировщик должен относиться к своей работе: должен ли он пропускать фичу в прод, если успешность выполнения 99%?

4. Как в этой ситуации разработчик может обещать бизнесу, что фича точно будет работать в срок и что будет работать вообще?

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

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

Экологичные методы внедрения ИИ

Я не сторонник прямого управления и навязывания воли в контексте управления людьми и считаю этот метод порочным и признаком плохо выстроенной системы. Методы в духе «вот я навайбкодил за 2 недели, поэтому вы должны делать фичи в 2 раза быстрее» и «с этого дня 80% кода и 100% документации должны быть написаны ИИ» работают очень плохо. Вместо этого я вижу 2 пути:

1. Вы даете команде прямую задачу для ресерча/теста конкретных инструментов. Команда должна собрать честный фидбек и профит, если он есть, поделиться знанием со всей командой; если нет — избавиться от него, а не оставлять в качестве рудимента, который мозолит глаз.

2. Внедрение в текущие процессы. Если у вас есть GitHub Actions, добавьте еще один шаг, который будет просить у ЛЛМ сделать ревью. Не нужно делать это обязательным шагом, нужно сделать так, чтобы полезные инструменты были частью текущего окружения сотрудников. Если что-то будет действительно полезным, они будут это использовать и без грозного взгляда менеджера. Заранее определите, что вы хотите получить: если ответа нет, возможно, не стоит интегрировать очередной суммаризатор чата в ваш корпоративный мессенджер.

Очень важный принцип — мозг человека ленив. Если он увидит, что он может не писать фичу 2 недели, а это можно сделать в Cursor или Claude Code за 3 дня, он сам будет этим пользоваться, достаточно лишь 1 раз показать, что это возможно. Людей все еще не удалось заменить — задайте себе вопрос, почему.

Я сделаю все сам

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

Зачем бизнес продавливает эти решения?

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

Мой Telegram