Заметки с полей
Наблюдаю одну и ту же ситуацию уже который раз: CEO подружился с Claude Code, в считанные минуты строит прототипы и делает работу, которая занимала часы или вообще никогда не делалась, и пушит CTO, чтобы была автономная разработка, релизили фичи быстрее или команду сокращали. В общем, всем AI.
При этом CTO
цитирует исследования а-ля Стенфордское, нутром чувствует всю боль в шутке а-ля аттач, и не хочет на курсы про автономную AI разработку. Хочет по старинке или хотя бы в управляемом режиме. Иногда, возможно даже "запугивает", что "все похерится к черту и кто тогда будет отвечать?"
CEO хочется продавить, но одновременно боится и спугнуть, и предвзятости, если отдать на откуп CTO. С другой стороны - по этим же причинам CTO тяжело обьяснить, как дела на самом деле, потому что есть недоверие в обьективности.
В "правильном" мире есть некоторый "судья", который рассудит. Но реальность не всегда такова.
Так что же делать? Кто прав? Можно ли действительно в разы ускорить разработку? Или все это брешь заморская, пиар лабораторий и раскручивание капитализации?
Сначала по существу, а потом чуть абстрагируемся (следующий пост):
1) AI assisted кодинг работает, мы все это знаем - и CEO, и CTO; для одноразовых прототипов, для некритичных приложений, для вещей, до которых никогда не доходили руки, но которые надо делать регулярно. Зачастую основной апсайд от вайбкодинга не в customer facing продуктах, а во внутренних админках и других некодинг функциях.
2) Для применения оного же в продуктах, которыми пользуется много людей, в которых цена ошибки высока, или стеке, редком в тренинг данных модели - необходимы инвестиции: в подготовку контекста, в harness, в инфраструктуру верифицируемости, в системы обратной связи. Тут 2 барьера: а) CTO не знает, какие именно инвестиции, что конкретно нужно делать; б) знает, что делать, но не готов на них.
3) вариант вида "пусть AI генерит код, а разработчики - ревьюят" быстро упирается в то, что я описывал в этом
посте: кризис идентичности, самоотбор людей в профессию программиста, comprehension debt.
4) и уж точно вариант считать количество pull request-ов на пару с дружбаном - не самый лучший.
Так как же быть?
1) Первое, что необходимо
признать - разработка с дружбаном это не ускоренная разработка, это другая разработка. У традиционной разработки, где человек пишет (и понимает, что пишет) код есть большое количество предпосылок, которые разбиваются об AI реальности; другие узкие места; от участников требуются другие компетенции и, возможно, личные характеристики. Поговорим еще в будущих постах об этом.
Забавно, кстати, сравнить разработку с AI как разработку аутсорсинг командой —> очень многие претензии похожи 😉 Кроме, пожалуй, скорости все-таки
2)
Разделить задачи на разные категории вместо того, чтобы спорить сразу и обо всем:
a) внутренная тулза, которой пользуется сам CEO, прототип для фидбека от клиентов, proof of concept для проверки новой идеи или однотипная работа а-ля интегрировать нового поставщика по образу и подобию - пожалуйста, вайбкодим наздоровье.
b) customer facing фичи или продукты, в которых цена ошибки
