Что добавляется в процесс при ИИ-разработке? Наш кейс замены легаси

Со стартапами понятно: вайб-кодинг сильно ускоряет и удешевляет проверку гипотез на живом продукте. Но что если у вас уже годами отлаженные процессы, сотни страниц сайта или куча пользователей легаси-продукта? И вам все-таки хочется делать новое на порядок быстрее и дешевле, чем прежние ~10 дней и ~$1000 на фичу или на красивый лендинг?

Мы с Серёжей Липчанским это желание уже реализовали, не будучи программистами. Заменили основную легаси-систему ScrumTrek целиком: публичный сайт + CMS + CRM + автоматизацию работы с участниками и оплатами тренингов/конференций. У Серёжи, кстати, свои инсайты про это: например, вот про "парное программирование".

А ниже пара инсайтов от меня, Лёши Евдокимова.

1️⃣ Простые схемы типа "старый код ➡️ спеки ➡️ новый код" не работают. На каждой стрелочке ИИ что-то теряет (как, впрочем, и люди).

Поэтому на всех этапах стоит давать агентам доступ к максимально широкому контексту: например, ИИ-разработчик должен смотреть не только спеку и собственный код, но и легаси-код + данные легаси-базы + как те же данные выглядят в новой системе.

2️⃣ Когда нужно через ИИ делать не MVP, а систему для тысяч привыкших к хорошему пользователей, нужны дополнительные итерации (см. картинку 👆). Это для многократной ИИ-валидации/улучшения уже запрограммированного функционала. Без этого наше 10-кратное уменьшение усилий на разработку привело бы к неприемлемому 3-5-кратному росту числа критичных багов.

➿➿➿
Как был устроен весь процесс замены старой системы — в статье:
🔗 Вайб-кодинг больших систем: заменяем легаси без разработчиков
— Warning: там можно залипнуть на 20 минут, особенно если вам тоже нужно заменять легаси. А если интересны лишь общие принципы надежной ИИ-разработки — минут 10.
— Warning 2: от читателя нужен технический бэкграунд. Ну, или просите ваш ИИ объяснить главное попроще.

#статья #вайбкодинг