ИИ в разработке: карта пайплайна
Модель пишет код быстро, и на этом разговор обычно заканчивается. Вопрос в другом: на каких этапах она окупается, а на каких создаёт долг, который придётся разгребать. Ниже карта шести этапов — с тем, что на входе и выходе, какой метрикой этап измеряется и где он ломается.
Этап 1. Требования
Начинается всё не с кода, а с постановки. Если спецификация двусмысленная, дальше модель добросовестно размножит эту двусмысленность по всей реализации.
Ломается на выдуманных требованиях: модель добавляет то, чего в постановке не было, и это уходит в разработку как договорённость.
Этап 2. Генерация кода
Здесь ожидания выше всего и здесь же быстрее всего приходит разочарование: код компилируется, проходит ревью по формальным признакам и плохо стыкуется с тем, как устроен проект.
Ломается на конвенциях: работает, но не так, как принято в проекте, — и разбирать это дороже, чем написать заново.
Этап 3. Ревью
Ревью — самый недооценённый этап. Модель здесь полезна не как автор, а как второй читатель: она умеет проходить по коду много раз и не уставать.
Ломается на вежливости: вместо поиска проблем модель пересказывает, что код делает, и одобряет его.
Этап 4. Тесты
Тесты модель генерирует охотно и в больших объёмах. Проблема не в количестве, а в том, что именно они проверяют.
Ломается на проверке реализации вместо поведения: тесты зелёные, а неверная логика так и осталась неверной.
Этап 5. Документация и передача
Самый дешёвый этап для внедрения и самый быстрый по отдаче: документация — это переработка уже существующего текста и кода, то есть ровно та работа, где модель сильна.
Ломается на описании того, чего нет: модель описывает задуманное поведение, а не фактическое.
Этап 6. Инциденты и сопровождение
Ночной инцидент — момент, когда ценность гипотезы максимальна. Модель хорошо сокращает путь от стектрейса до списка версий, но плохо переносит этот этап в одиночку.
Ломается на уверенном неверном диагнозе: гипотеза звучит убедительно и уводит дежурного на несколько часов в сторону.
Что мерить суммарно
Метрик много, но решение о внедрении принимается по трём: время до первой рабочей версии, доля дефектов, найденных до мержа и время до подтверждённой гипотезы при инциденте. Если хотя бы одна из них не улучшилась за квартал, значит, модель встроена в процесс формально.
И одно правило поверх метрик: мерить надо процесс, а не объём написанного моделью кода. Строки — самая бесполезная из доступных цифр.
Как этот пайплайн стыкуется с работой аналитика и дизайнера — в статье «ИИ в аналитике и UXUI: пайплайн от требований до прототипа». А чем проверить сгенерированный интерфейс на соответствие канону — в «ИИ для интерфейсов».
Разбираю пайплайн команды и показываю, на каких этапах ИИ даёт эффект, а на каких создаёт долг. Телеграм: @darkclaus