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

99% звучит эффектно, но без контекста это почти ничего не говорит о качестве и сложности кода. иногда важнее не доля сгенерированного, а сколько решений ты реально можешь объяснить и поддерживать

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

Да, я в ии кодинге новичок. Но, очень хочу разобраться. Хорошо что нейронка "ведёт" по задачам. Пока, конечно, я в роли "первый день творения" 🖐🤣

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

Спасибо за поддержку, Денис 🫶

да не за что, сам пока пытаюсь понять, где тут реальная польза, а где просто смена роли на надсмотрщика

Приведу пример... Запрос делала последний раз по шалфею, мне нужны фитоэстрагенах в травах... Дак пока не задала наводящий вопрос, а точнее конкретно. Почему ты не говоришь про фитоэстрагены в шалфее!? Она мне, о да! Как же я это могла упустить! Я порой ловлю себя на мысли что моих знаний личных больше чем у ии и точнее.

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

Я, обычно, глазами бегаю по её правкам и если там очень много кода нового или изменённого, начинаю просить расписать что и как она сделала и для чего это надо. А если правки пара строчек на файл, то бегло, если повезёт - выцеплю, если не повезет - потом повезёт.

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

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

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

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

Есть такое. По этому когда чувствую, что теряю понимание - требую отчёт о сетке

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