Начало

Продолжу описывать процесс работы длиной в (предыдущую) неделю,мысли подходы в формате:
* Затраченное время
* Какие изменения вносил
* Какие выводы сделаны/инсайты получены


пнд-втр, 10+14=24ч.
- Загружен проект, проведена первичная оценка имеющейся кодбазы. У меня есть целый гуглдокумент на 9 страниц с говной, где я выписывал как на ревью все проблемы исходника.
Мы хотели во имя науки скормить его в таком виде ИИ чтоб он составил себе подробное ТЗ и по нему прошёлся, закрыв дыры
Эксперимент признан неудачным

Сводка самых критичных моментов:
- отсутствие БД(!), консистентного хранилища состояния.
- Фронт на сырых HTML шаблонах
- ЯндексS3 как единственное хранилище файлов (я не планировал использовать внешнее S3)
- Также наблюдалось огромное количество дыр в безопасности и производительности: по моим подсчётам, оно не должно было вытягивать больше 2-3 человек одновременно
- Модели кэшировались очень частично и вызывали зависания на несколько минут из-за подгрузки гигабайтов весов каждый первый запуск
- В некоторых кейсах происходили очень неявные критические баги. К примеру, если первая задача в систему не была с флагом на разделение спикеров, то ни одна последующая эту функцию запустить уже не сможет

Я очень недооценил на старте сырость исходника.
Вместе с тем, и это очень важно, Оно работало! Легаси кодбаза уже выступала в роли технического концепта желаемого функционала, а значит все ответы и фичи, хоть и реализованные криво уже были в ней, и моей задачей стал перепил структуры и организации кодбазы


Инсайты
- Я долго пытался понять, с какого бока приступить, это было очень сложной задачей - найти точку входа для изменений на легаси в 2-3к строк. Начал с фронта, философски отнесясь к бэкенду как к чёрной коробке с публичным контрактом, и потом уже переходить к бэку

- Фронт перепилился в TS+Vite приложение на удивление спокойно. Я, как совсем не фронтендер, не догадываюсь, какие ужасы там творились. Оно и к лучшему.
Самый важный инсайт - если позаботиться о хороших подробных описаниях-промптах и приложить референсы - ИИ может осилить даже объёмные структурные изменения.

- Хорошо показал себя метод, где сначала ИИ переписывает всё в один более большой файл и потом уже разбивает на несколько маленьких отдельной цепочкой рефакторинг промпт-задач

- Бэк представлял собой зрелище, не самое страшное в моей практике, но опасное ввиду неявно заложеннных бомб

ИИ плохо справляется с уменьшением сложности/вложенности кода и не всегда понимает проблему асинхронности, организации IO/Heavy задач.
Фокус на локальном решении текущей мелкой проблемы осложняет использование общих абстракций, моделей. Это должно фокусироваться отдельно через Rules, промпты.

Ненужная вложенность кода (функция обращается к функции которая обращается к функции и на каждом этапе размазан какой-то минимум важного кода) - характерная особенность ИИ стиля

- Очень приятный момент, можно спокойно писать "форму с логином" или "таймер в главном окне рядом с окном загрузки" - ИИ прекрасно оцифровывает и меняет нужные компоненты

- Курсор очень хорош в поиске и анализе кода. Можно спокойно спрашивать за незнакомый код и получать качественные вменяемые ответы

- Нужно следить за обезличенностью речи и не давать ему понять, что ты не согласен с решением/говнишься. ИИ тут же начинает всё срочно переделывать.

Никогда не спрашивайте ИИ напрямую, почему оно что-либо сделало, оно засчитает это за предъяву

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

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