"Заметки с полей: CEO vs CTO Наблюдаю одну ситуацию уже который раз: 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 фичи или продукты, в которых цена ошибки << выигрыша от скорости c) платежи, безопасность, данные клиентов Фокусируемся сначала на a & b. 3) инвестировать в верифицируемость: автоматические проверки работоспособности системы, голден датасеты, эвалы и тесты. Обычно в такое не всегда хочется и есть время, и могли обходиться без этого, когда люди писали и читали весь код; но, если мы хотим пожинать плоды AI разработки, то без этого далеко не уйдешь. В противном случае - либо все опять упрется в человека, либо жди алертов в проде. 4) договориться, что роль разработчика меняется с AI - если CTO рассматривает внедрение AI как экзистенциальную угрозу, то имхо никакие рациональные доводы не помогут, ситуация политическая будет маскироваться под техническую. Кто из команды готов к этой новой реальности, где удовольствие от написания кода смещается удовольствием от более быстрого цикла ~~разработки~~ обучения у рынка? (продолжение - на днях; welcome в комментарии, давайте покрутим тему)"