Что там по вайб-коду?

Снова делюсь промежуточными итогами и мыслями по ИИ-разработке.

Мой процесс устаканился

В общем, вопреки ожиданиям, мой процесс разработки с агентами с конца марта практически не изменился. Фреймворк чуть поумнел, но не радикально.

И это приводит меня к тому, что я начинаю уже всерьёз рефлексировать на тему самого процесса, и того что в нём можно поменять. И тут я смотрю на 2 направления: что у других и что смущает меня в текущем процессе.

Что меня смущает?

Больше всего - скорость итерации. Сейчас средняя скорость разработки находится в районе 1 кейса в час работы. При 8-часовом рабочем дне и ~30 кейсах на историю - это 4 дня на одну историю.

Это не сильно быстрее, чем ручная разработка. При этом из-за работы в параллель lead time по средней истории в таком цикле занимает 2-3 недели. То есть вы выдаёте не одну историю через неделю, а 4 истории разом, но через 3 недели.

И тут я вижу следующие сдерживающие факторы:

1. Ошибки ллм.

Я тут вижу тезисы, что для разработки нынешние модели - это уже оверкилл и очень круто. А если вам не хватает, то это вы неправильно их используете. Короче, мне не хватает. Чувствую, что это решается только ожиданием новых версий более умных ллм.

По ощущениям каждый второй-третий запрос в агента - просьба что-то доделать или поправить. Это х1.5-2 к времени реализации.

Это при том, что в фреймворке уже лежат списки с проверками на десятки типовых косяков, которые бы иначе пришлось править еще большим количеством запросов. И это приводит ко второй проблеме.

2. Скорость ллм.

В текущем процессе Клод у меня молотит итерацию по 10 минут минимум. Чаще всего это связано с большим количеством проверок (на ревью-агентах и на тестах) и (через часик-другой) перегревом ноута, который в параллель крутит 6 ide, 6 сессий и 6 копий приложения и инфраструктуры в докере. Причём, тут есть положительная обратная связь: чем медленнее едет сессия, тем больше надо открывать в параллель, чтобы работа не простаивала, тем медленнее идёт сама сессия.

По окончанию подписки клода попробую модели пошустрее. Возможно, мне удастся сократить таким образом количество параллельных сессий.

3. Количество кейсов.

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

Так что моя задача на следующую историю - постараться упихать её в 15 кейсов за счёт выкидывания второстепенного функционала. Тот самый Lean. Это даст выигрыш в скорости 2 раза. Впрочем, трудно поверить, что можно реализовать нормальную историю в 15 кейсов на фронте и бэке.

4. Частота ревью.

Сейчас в процесс на бэке встроена гексагональная архитектура, на фронте - humble object. Это модульные архитектуры, поэтому изменения в каждом модуле отсматриваются дважды: сначала на этапе тестов, потом на этапе реализации.

В итоге, вместо того, чтобы просто дать агенту кейс, посмотрев на результат в самом конце, я останавливаюсь на ревью и корректировки примерно 3-9 раз за один кейс.

Хочется ли мне пожертвовать этими промежуточными ревью? Скорее, нет. Много коротких ревью лучше, чем одно длинное. Как минимум, потому что лучше понимаешь, что где происходит.

Хочется ли мне пожертвовать многослойным тестированием в пользу однослойного? Скорее нет, многослойное тестирование даёт слишком много, чтобы я готов был им пожертвовать. Но обходится при этом не настолько дорого.

5. Противоречия в требованиях.

Вот это прикол последних недель разработки. Короче, на 450+ кейсов начинается ситуация, когда одни кейсы начинают ломать другие кейсы. Общую картину искусственный интеллект, как и обычный, в уме держит, а вот какие-то мелочи упускает.

Это выражается в том, что каждый третий новый кейс ломает какой-то другой. Разбор этих конфликтов начинает заметно отнимать время. Судя по всему, придётся на этапе создания кейсов добавлять шаг ревью со сверкой кейсов на момент противоречия другим.