Комментарии 28
Хорошая статья. От себя добавлю некоторые нюансы, через которые мы прошли.
1. Арьергард кнутом не били. Просто не трогали их и расширяли авангард. По мере увеличения авангарда и появления все новых пруфов эффективности использования ИИ арьергард потихоньку сам сдался по своей воле.
2. Отдельный прорыв произошел, когда массово внедрили MCP. Написали рабочие инструкции по подключению и использованию самых нужных нам MCP для всех ОС и описали рабочие кейсы. Это дало мощный буст.
3. В т.ч. благодаря MCP удалось подключить к использованию ИИ не только аналитиков, но множество "неразработческих профессий" типа коммерсантов или экономистов. Так что вполне работает схема по внедрению сразу во все направления.
4. По отслеживанию статистики стало очень удобно, когда внедрили LiteLLM. Стало удобно смотреть кто когда сколько токенов жгет. И я лично выловил благодаря нему нескольких кадров, юзающих мощности LLM не по назначению.
5. Бывают проекты в закрытом контуре, где не допустят, чтобы код уходил в Anthropic. Там пришлось использовать локальные ресурсы железа с открытыми моделями за неимением альтернативы. Да, они более тупые. Но тем не менее это успешно сработало хотя бы частично: сняло нагрузку на рутинных простых задачах, на которые раньше все равно приходилось тратить время.
6. По поводу метрик оценки ИИ все просто. Чтобы получить профит от ИИ надо взять метрики ПОСЛЕ внедрения ИИ и сравнить их с метриками ДО внедрения ИИ. Очень просто. Только одна проблема: с метриками ДО внедрения ИИ. Потому что если их нет (а так бывает, да?), то и сравнивать не с чем. Поэтому в командах, которые грамотно применяли метрики оценки работы ДО, было очень просто увидеть результаты ПОСЛЕ.
Интересны детали:
Между тем правильное и грамотное использование ИИ в разработке реально ускоряет выпуск продукта, улучшает его качество и снижает его стоимость
На сколько снизилась стоимость?
улучшает его качество
Вы это как-то измерили?
Про стоимость - на реальной задаче стоимость разработки снизилась в два раза. Пока мало статистики, чтобы сказать на сколько ИИ снизит стоимость в среднем. Продолжаю наблюдение.
Про качество - вижу, что ИИ, в отличие от людей, не допускает глупых ошибок. Число багов, которые находят тестировщики радикально снизилось. Боюсь конечно сглазить, но похоже ИИ не подвержен "человеческому фактору", т.е. баги появляются только концептуальные, запланированные, так сказать изначально в ТЗ, а не "недосмотр" разработчика.
Так и вижу, как 50-и летнего зубра, который может три дня анализировать код и логику, и потом одной строчкой решить проблему, заменяют со словами "он не любил синематограф" на бойкого юношу с клод и суперпауэрс, выдающего 1000 строк в день. А потом Антропик выходит на IPO и повышает цены в 10 раз. И/или окончательно вас банит. И это совпадает по времени с утратой компетенций и потерей контроля над кодовой базой.
Да, такой риск безусловно есть. Как есть, например риск того, что во всем мире повысят стоимость электричества и/или его окончательно отключат, тогда нам всем придется готовить себе обед на костре. А компетенция добыть огонь трением давно утрачена.
Аналогия хромает. Зрелость индустрии производства, доставки и использования электроэнергии несравнима с использованием llm программировании.
Да и речь о другом. Если в команде есть сеньоры или тех лиды, отказывающиеся от "синематографа", то нужно оставить их в покое. Возможно, они спасут фирму, если что-то пойдёт не так. А оно обязательно пойдёт не так.
Антропик выходит на IPO и повышает цены в 10 раз. И/или окончательно вас банит.
Переходим на GLM. Сейчас он уже где-то недалеко от Claude.
GPT-5.5 от OpenAI достойная замена Claude. Kimi 2.6 внезапно хороша. Не думаю, что Anthropic на столько недальновидные, что будут повышать стоимость в 10 раз, конкуренцию ни кто не отменял. Скорее наоборот, получив на IPO кучу бесплатных денег начнут демпинговать, чтобы захватить как можно больший рынок.
Посмотрим ))
у нас в компании стали всем разработчикам/аналитикам оплачивать pro подписки на их любимую AI
"Кто и сколько токенов потратил" позволяет судить только о том, применяет ли человек ИИ вообще, но ничего не говорит об эффективности применения. Человек может успешно сжигать больше всех токенов, но при этом наносить больше всего вреда (или сжигать токены на личные проекты).
"Соц.опросы" - это совсем плохо. Люди врут, додумывают, заблуждаются. Я использую такие штуки для проведения 1-1 и "психотерапии", но никак не для оценки работы с агентами.
Если приходится спрашивать у человека даже какие модели он использовал - у меня плохие новости, это значит что работа с агентами в команде не контролируется и не управляется вообще никак.
Я раделяю метрики на метрики глубины внедрения ИИ в процесс человека, метрики работы человеком по процессу и метрики успеха ИИ и качество архитектуры/кода.
Глубина внедрения = это те самые токены, типы/число взаимодействий и итераций (hooks дергает нужные ручки, собирающие стату и метаданные), объемы диффов, объемы артефактов-документов и т.д. Эти метрики говорят лишь о том, начал ли разраб использовать ИИ, но никак не говорят о том, насколько эффективно и для чего.
Метрики работы человеком по процессу = у меня есть автоматизированное ревью агентских сессий - насколько соблюдались командные правила работы с агентами, как использовались командные плагины, были ли применены/нарушены ключевые паттерны и т.д. В моих командах автоматически это делается у новичков. Ручной запуск одной кнопкой при неудачных PR, ломающих правила и архитектуру (проверки агентами на уровне CI по архитектурным докам и правилам с разных углов + прохождение ревьювером), при инцидентах. Но даже на вроде бы уже "наученнных" людях - при случайной проверке иногда выявляется дичь, от которой волосы дыбом.
Метрики успеха ИИ - не число измененных строк в диффе, а число успехов/неудач в прохождении CI, ревью агентами в CI и людьми, диффы дополнительных ПРАВОК после коммита/PR и т.д.
Был бы Вам крайне благодарен за ссылку на годную статью про "автоматизированное ревью агентских сессий". Пока что не могу найти какого-то стандарта или best practices в этой области. Не хочется изобретать велосипед с нуля, наверняка уже что-то придумано и активно используется в индустрии.
Я тоже изобретал этот велосипед с нуля. Ничего вменяемого не нашел, но это нормально, учитывая что почти вся инфра для агентов сейчас вращается вокруг соло-разработки.
С чего оказалось полезно начать:
1. анализа данных из хуков (вызов тулов/компакта/сабагентов)
2. ручного ретро-анализа сессий по факту кривых комитов (в клоде).
3. "когда какие скиллы вызывались, для чего", "когда какие сабагеты вызывались, для чего, сколько токенов сожрали"
Неспецифичные метрики (plan_before_write, tests_after_write, review_after_finish) оказались почти бесполезны.
Полезными оказались структурированные деревья метрик по специфичным скиллам. Например, метрики по кастомному аналогу superpowers - иновукился ли скилл вообще, были ли ревью спеки с x, y, z, были ли проверены выводы ревью-сабагентов перед правками, сколько итераций ревью проведено и сколько блокеров найдено, записаны ли follow-ups, записаны ли issues итд.
Честная рекомендация: начните с ручного анализа сессий. Поймете где болит конкретно у вас в сравнении с воркфлоу, который вы ожидали увидеть. Далее тестируйте метрики на своих и чужих транскриптах, чтобы понять что хорошо, что плохо.
А далее уже метрики -> оценка более умной моделью по чеклисту с подсветкой проблемных мест, дешборды, нотификации себе и самому разрабу и т.д.
Свахе первые тумаки©
Эта статья в первую очередь для менеджеров, руководителей проектов, CIO, CTO и т.д. Менеджеров, которые нутром чуют, что настало время ИИ, но не знают как подступиться к задаче: “перевести команду разработки на рельсы ИИ”
Да вы опасный диверсант! Пожалуй, я подкараулю вас в темном переулке.
У нас в компании начали с самого базового — всем оплатили Pro-подписки на ИИ-инструменты. Параллельно осторожно продвигали идею, что хотя бы часть кода должна писаться с помощью ИИ, звучала даже цифра “40%”, хотя как это объективно измерять — до сих пор не очень понятно.
Потом запустили пилот с Devin AI — агентом, который умеет самостоятельно брать тикеты, писать код и открывать PR практически end-to-end. Но пилот быстро уперся в безопасность: секьюрити-команда не согласовала передачу потенциально чувствительных клиентских данных внешнему AI-провайдеру. В итоге Devin не взлетел, и сейчас основной рабочий сценарий у всех — Claude в режиме чата/агента.
Параллельно у нас создали отдельный департамент AI Enablement, который должен заниматься внедрением ИИ во все процессы компании. Я сейчас как раз участвую в этом со стороны обучения — пытаемся выстроить системную теоретическую базу для мидлов и сеньоров в виде серии курсов. Пока полуготов только один из десяти https://stepik.org/288745
И вот что интересно: я бы не сказал, что с ИИ работы стало меньше. Скорее наоборот. ИИ генерирует настолько много кода, что человеку становится сложно это качественно ревьюить. Пока у нас получается примерно так: один разработчик “гоняет” ИИ на генерацию, второй — использует ИИ уже для ревью этой генерации.
Сейчас дополнительно строим систему автоматического ревью через Claude. Причем пришли к интересной архитектуре: у ревью два выхода — один упрощенный и читаемый для человека, второй представляет собой специализированный промпт для следующего ИИ. По сути, context engineering уже начинает выделяться в отдельный инженерный слой.
Спасибо за комментарий, очень интересно. Скажите, пожалуйста, а Вы виртуальных работников уже тестировали? Сейчас многие экспериментируют с полностью автономными ИИ "сотрудниками". Первый шаг сделать так, чтобы не вредили )), следующий шаг - чтобы помогали, хотя бы чуть-чуть.
Devin AI как раз и есть такой виртуальный сотрудник, работающий на своем виртуальном компе: даешь ему тикет, он читает его из Jira, скачивает репо, анализирует, создает ветку, коммитит туда фиксы, создает ПР, и ждет чтобы его отревьюили. Экономит время на шагах, связанных с “бумажной работой”: созданием ПР, и красиво заполняет все поля в тикете.
Но львиная доля времени все равно уходит на ревью человеком.
Еще у нас любят заставить ИИ писать тесты. Размер тестов уже превышает размер многих приложений. Каждый ПР изза тестов делается в несколько раз больше чем раньше, и где-то за гранью способностей человека все это понять.
А самое неприятное, что я пока ни разу не видел ситуацию, чтобы изза изменений вдруг упал тест, и чтобы ИИ пофиксал бы код. Он всегда фиксает тест.
Может тесты теперь уже не так актуальны, ведь они писались чтобы ловить ошибки людей, которые ИИ не делает?
В общем чувство такое, что вообще все что мы знали о нашей работе теперь надо пересматривать…
Про "ревью человеком" есть вопрос, ревью же делает человек, вооруженный ИИ, правильно? Т.е. один разработчик с помощью ИИ пишет, а другой разработчик с помощью (как правило другой модели) ИИ ревьювит. У меня это именно так устроено, а как у Вас?
Да, тоже также. Но ревью остается узким местом. И, честно говоря, с ИИ крайне редко на ревью что-то годное происходит. В основном косметические изменения, которые только тормозят процесс (потому что менеджеры меряют вовлеченность девелоперов в ревью по количеству комментов). Говоря о процессах, который надо менять, я имею в виду процесс ревью тоже, так как время он отнимает много, а выхлоп дает мало. Может ревью надо переносить на шаг раньше, туда где формируются требования. Но так пока не принято.
Хорошая статья. От себя добавлю некоторые нюансы, через которые мы прошли.
1. Арьергард кнутом не били. Просто не трогали их и расширяли авангард. По мере увеличения авангарда и появления все новых пруфов эффективности использования ИИ арьергард потихоньку сам сдался по своей воле.
2. Отдельный прорыв произошел, когда массово внедрили MCP. Написали рабочие инструкции по подключению и использованию самых нужных нам MCP для всех ОС и описали рабочие кейсы. Это дало мощный буст.
3. В т.ч. благодаря MCP удалось подключить к использованию ИИ не только аналитиков, но множество "неразработческих профессий" типа коммерсантов или экономистов. Так что вполне работает схема по внедрению сразу во все направления.
4. По отслеживанию статистики стало очень удобно, когда внедрили LiteLLM. Стало удобно смотреть кто когда сколько токенов жгет. И я лично выловил благодаря нему нескольких кадров, юзающих мощности LLM не по назначению.
5. Бывают проекты в закрытом контуре, где не допустят, чтобы код уходил в Anthropic. Там пришлось использовать локальные ресурсы железа с открытыми моделями за неимением альтернативы. Да, они более тупые. Но тем не менее это успешно сработало хотя бы частично: сняло нагрузку на рутинных простых задачах, на которые раньше все равно приходилось тратить время.
6. По поводу метрик оценки ИИ все просто. Чтобы получить профит от ИИ надо взять метрики ПОСЛЕ внедрения ИИ и сравнить их с метриками ДО внедрения ИИ. Очень просто. Только одна проблема: с метриками ДО внедрения ИИ. Потому что если их нет (а так бывает, да?), то и сравнивать не с чем. Поэтому в командах, которые грамотно применяли метрики оценки работы ДО, было очень просто увидеть результаты ПОСЛЕ.
Готов обменять бесплатные подписки на топ модели (и те, что с сиськами тоже) + настроенную под них инфраструктуру на +10% к перформу. На большее не подпишусь.
Между тем правильное и грамотное использование ИИ в разработке реально ускоряет выпуск продукта, улучшает его качество и снижает его стоимость. Да, все три параметра (качество, скорость и стоимость) одновременно. И секрет очень прост, ИИ надо использовать грамотно, как любой дорогостоящий и сложный инструмент
Не понял, где "секрет" ?
Расскажу, как одномоментно получилось поменять менталитет в моей команде. Я нашел хорошего знакомого, который успешно пишет код с помощью ИИ и попросил его сделать online демонстрацию его работы.
Напоминает сеансы исцеления в церквях
Программисты уверовали, что можно заставить ИИ работать и больше никогда не писать код руками.
не зря напоминало
Авангард - это те, кто с радостью начнет использовать ИИ не особо задумываясь над эффективностью. На данном этапе всячески поощряйте и хвалите их, демонстрируйте им свою благосклонность. Подчеркивайте их исключительность. Пусть остальная команда смотрит и думает, что они выскочки и хайперы, не страшно. Ваша задача как менеджера показать, что вы поддерживаете ИИ-нутых людей, какую бы дичь они не творили
ну-ну
Сильнее всего цапнула мысль про то, что ИИ надо внедрять не только у разработчиков. По моему опыту в веб-разработке, если аналитика, постановка задачи и проверка результата остаются как раньше, то разработчик с ИИ просто быстрее въезжает в ту же стену. Только раньше непонятная задача долго шла до кода, а теперь она довольно бодро превращается в код.
Я бы к этому добавил еще один фильтр между AI-вариантом и обычным code review. Надо отдельно смотреть не только на качество реализации, но и на то, где ИИ предлагает чинить задачу. Он может дать рабочий и на вид вполне приличный вариант, но увести правку не туда. То есть вопрос не только «нормально ли написан код», а еще и более скучный, но важный: «мы вообще там чиним?»

Как подсадить разработку на ИИ