CEO навайбкодил прототип. Почему после этого команда не обязана работать вдвое быстрее

kir_pub12 часов назад

CEO навайбкодил прототип. Почему после этого команда не обязана работать вдвое быстрее

Уровень сложностиПростойВремя на прочтение4 минОхват и читатели8.3KУправление разработкой*Python*IT-инфраструктура*Управление продуктом*IT-стандарты*МнениеПриветствую, дорогие читатели. На протяжении последнего года мне посчастливилось пообщаться с несколькими десятками бывших и текущих коллег, от разработчиков до владельцев компаний, на тему внедрения ИИ, и, кажется, я открыл врата в ад.

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

— Пару дней назад наш CEO собрал всю команду и с громким воодушевлением и пафосом показал прототип, который он смог навайбкодить за пару недель. — Не поверишь, но у нас произошла точь-в-точь ситуация. — Да, наверное, сейчас в каждой компании приходит менеджмент и говорит "AI, AI, AI, AI". — Я ожидаю, пока такие парни и девчонки понавыпускают кучу прототипов в прод и получат репутацию low-quality продуктов. —Раньше был чайка-менеджмент, а сейчас ai-менеджмент.После всех моих разговоров с людьми у меня в голове сложилась следующая картина:

• БОльшая часть менеджмента переоценивает возможности ИИ.
• БольшАя часть разработчиков недооценивает возможности ИИ.
• БольшАя часть менеджмента не осознает, что разработчики уже используют ИИ достаточно глубоко.
• БольшАя часть разработчиков отрицает развитие ЛЛМок: попробовав что-то накодить однажды, они разочаровались и больше не развивались в этой теме.Я решил взять на себя задачу подружить менеджмент, разработчиков и владельцев бизнесов, которые испытывают глубочайший страх упущенной выгоды, и объяснить каждой из сторон, как вы и ваша команда можете начать двигаться в одном направлении.

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

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

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

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

• Бизнес решил протестировать гипотезу, мы имплементировали и поняли, что ЛЛМ не способна выполнить задачу - кто несет ответственность?
• Если мы даем ЛЛМ возможность выполнять деструктивные действия (запись в базу, POST-запрос на API), мы перекладываем ответственность за ошибки на юзера, бизнес или разработчика?
• Как тестировщик должен относиться к своей работе: должен ли он пропускать фичу в прод, если успешность выполнения 99%?
• Как в этой ситуации разработчик может обещать бизнесу, что фича точно будет работать в срок и что будет работать вообще?
• Очень неясные правила для скейлинга таких фич: частая ситуация - вы добавили новую фичу для вашего AI-агента, и из-за этого все старые фичи теперь работают хуже. Опять же, как разработчик в рамках стандартного процесса разработки может брать на себя эту ответственность?Вариант, который придумал я и который не сильно понравится любителям управлять - проверка двойной гипотезы, а именно: разработчик не может обещать, что фича будет готова в срок и будет работать идеально, но он может пообещать максимально качественно. То есть каждая фича - проверка сразу 2 гипотез: возможно ли реализовать фичу и полезна ли фича для пользователя. Это требует высокого уровня доверия и коммуникации внутри команды и на 99% является задачей руководства.

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

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

• Вы даете команде прямую задачу для ресерча/теста конкретных инструментов. Команда должна собрать честный фидбек и профит, если он есть, поделиться знанием со всей командой; если нет - избавиться от него, а не оставлять в качестве рудимента, который мозолит глаз.
• Внедрение в текущие процессы. Если у вас есть GitHub Actions, добавьте еще один шаг, который будет просить у ЛЛМ сделать ревью. Не нужно делать это обязательным шагом, нужно сделать так, чтобы полезные инструменты были частью текущего окружения сотрудников. Если что-то будет действительно полезным, они будут это использовать и без грозного взгляда менеджера. Заранее определите, что вы хотите получить: если ответа нет, возможно, не стоит интегрировать очередной суммаризатор чата в ваш корпоративный мессенджер.Очень важный принцип - мозг человека ленив. Если он увидит, что он может не писать фичу 2 недели, а это можно сделать в Cursor или Claude Code за 3 дня, он сам будет этим пользоваться, достаточно лишь 1 раз показать, что это возможно. Людей все еще не удалось заменить - задайте себе вопрос, почему.

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

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

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

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

Мой TelegramТеги:• AI
• менеджмент в it
• ии-агенты
• бекендХабы:• Управление разработкой
• Python
• IT-инфраструктура
• Управление продуктом
• IT-стандарты