Черт, если он пишет не финальный текст программы, а тебе его нужно доделывать... тебе нужно понимать что он написал!!11
Дада, ты не пишешь код, но ты его ЧИТАЕШЬ. То есть нельзя сказать что вот тебе сгенеренный текст программы сэкономил ровно то время, которое ты бы сам его набирал. Нужно вычесть время, которое ты его читаешь
Вообще нужно много чего еще вычесть, и все время возвращаешься к формуле "экономической целесообразности". Да и код бывает откровенно говоря разным: иногда ты пишешь тонну простого кода в день, а иногда за три дня ты пишешь одну строчку. Где тут тебе GPT поможет, а где нет?
На мой взгляд, только там где ты пишешь много кода, без большой концентрации "инженерной мысли" - простая бизнес логика, UI и т.п. Не забываем про то, что на неизвестных утилитах и языках с GPT писать сильно проще, чем было без него, поэтому "пет проекты, сгенеренные с AI, в неизвестном тебе стеке технологий" могут давать несколько ложные представления о реальных возможностях AI. Обычно такие пет-проекты относительно простые, ведь хочется "просто погонять идею", и они отличаются от рабочих задачек. А раньше львиная доля времени уходила на изучение неизвестного стека
А вот на работе, в устоявшемся проекте и с понятным стеком, если у тебя ментально сложная работа, а не верстка 1000 страниц в день, то помощь от AI резко сокращается и может показаться что даже мешает
Дада, ты не пишешь код, но ты его ЧИТАЕШЬ. То есть нельзя сказать что вот тебе сгенеренный текст программы сэкономил ровно то время, которое ты бы сам его набирал. Нужно вычесть время, которое ты его читаешь
Вообще нужно много чего еще вычесть, и все время возвращаешься к формуле "экономической целесообразности". Да и код бывает откровенно говоря разным: иногда ты пишешь тонну простого кода в день, а иногда за три дня ты пишешь одну строчку. Где тут тебе GPT поможет, а где нет?
На мой взгляд, только там где ты пишешь много кода, без большой концентрации "инженерной мысли" - простая бизнес логика, UI и т.п. Не забываем про то, что на неизвестных утилитах и языках с GPT писать сильно проще, чем было без него, поэтому "пет проекты, сгенеренные с AI, в неизвестном тебе стеке технологий" могут давать несколько ложные представления о реальных возможностях AI. Обычно такие пет-проекты относительно простые, ведь хочется "просто погонять идею", и они отличаются от рабочих задачек. А раньше львиная доля времени уходила на изучение неизвестного стека
А вот на работе, в устоявшемся проекте и с понятным стеком, если у тебя ментально сложная работа, а не верстка 1000 страниц в день, то помощь от AI резко сокращается и может показаться что даже мешает
Мои промежуточные выводы: AI дает бОльший буст в относительно простых задачах, где много рутины. И такой работы в общей массе довольно много! Мой "палец в небе на чуйке" показывает буст наверное 30-40%. Нет, это даже не 100% и не 1000% как рисуют в интернете
В эти 40% включена рутина, которая уходит на последний план, и быстрое обучение тому, чего ты не знаешь. Я прямо даже забыл когда был последний раз на stackoverflow... Сюда НЕ входит проработка архитектуры и сложных алгоритмов, так как они в 95% случаев вытираются и переписываются либо с автодополнением, либо через директивные указания что конкретно рефакторить
В эти 40% включена рутина, которая уходит на последний план, и быстрое обучение тому, чего ты не знаешь. Я прямо даже забыл когда был последний раз на stackoverflow... Сюда НЕ входит проработка архитектуры и сложных алгоритмов, так как они в 95% случаев вытираются и переписываются либо с автодополнением, либо через директивные указания что конкретно рефакторить
Кейс! Добрались наконец до кода и конкретного примера
Захотел я тут написать себе относительно сложный UI виджет для движка - Edit Box Drop Down. Это такой выпадающий список, с возможностью писать в него текст, а он предлагает тебе варианты с фильтрацией по введенному тексту. У меня уже был EditBox и DropDown, казалось бы поженить их совсем не проблема. При этом писать виджеты - это довольно рутинная работа, но местами нужно подумать. Такой виджет сложнее среднего, поэтому стало интересно, какой профит я смогу получить. Я стал записывать все свои шаги
Захотел я тут написать себе относительно сложный UI виджет для движка - Edit Box Drop Down. Это такой выпадающий список, с возможностью писать в него текст, а он предлагает тебе варианты с фильтрацией по введенному тексту. У меня уже был EditBox и DropDown, казалось бы поженить их совсем не проблема. При этом писать виджеты - это довольно рутинная работа, но местами нужно подумать. Такой виджет сложнее среднего, поэтому стало интересно, какой профит я смогу получить. Я стал записывать все свои шаги
Сразу скажу, у меня плохо с промт-инжинирингом, поэтому мои запросы были довольно туповаты и короткие. Но черт, в этом ведь смысл, если запрос будет сложным и длинным, то это равносильно написанию кода
Он сгенерил мне два файла - .h и .cpp, в нем был нормальный код. На первый взгляд. Не компилируемый, конечно же. Вот примерно столько ошибок в нем было, все что отмечено красными линиями относительно всего текста.
Интересно что он умеет запускать линтер, то есть видит ошибки компиляции. Его даже можно попросить их пофиксить и он уйдет их фиксить пока они не закончатся... Но ошибки остаются, справедливости ради, не так много
Интересно что он умеет запускать линтер, то есть видит ошибки компиляции. Его даже можно попросить их пофиксить и он уйдет их фиксить пока они не закончатся... Но ошибки остаются, справедливости ради, не так много
Штош, такой файл мне самому наколякать копипастой весьма недолго на самом деле, но очевидно дольше чем через GPT. Друго дело что его и правда нужно вычитать чтобы понять, а там уже сходу лезут в глаза ошибки
Далее я старался уже "обточить болванку" до нужного состояния. Что-то, что попроще и побыстрее сделать самому - делал сам.
Например, удалял ненужное. Но один раз мне нужно было удалить пачку ненужных методов "чутка подумав": нужно было удалить работу со стейтами виджета при клике и наведении курсора. При этом работу со стейтом раскрытия нужно было оставить. Ох, еще подумал уточнить это в запросе, но не стал. Не нужно ведь делать то, о чем тебя не просили, правда же?
Например, удалял ненужное. Но один раз мне нужно было удалить пачку ненужных методов "чутка подумав": нужно было удалить работу со стейтами виджета при клике и наведении курсора. При этом работу со стейтом раскрытия нужно было оставить. Ох, еще подумал уточнить это в запросе, но не стал. Не нужно ведь делать то, о чем тебя не просили, правда же?
Еще одну вещь подметил, относящуюся скорее лично ко мне. Я сам по себе довольно быстро работаю (порой в ущерб качеству, буду честен), и для меня набрать 400-500 строк кода довольно просто. Поэтому для меня некоторые вещи банально быстрее и проще сделать самому, чем запросить это в GPT. Но я точно знаю что не все такие, и кому-то этот эффект внешнего помощника будет давать бОльший эффект
Так же обратил внимание, что во время ожидания ответа получается эффект "выпадения из потока". То есть я сделал запрос на изменение и сижу жду, начинаю неизбежно отвлекаться и как будто бы где-то начинаю терять фокусировку. Когда пишешь код сам, такого нет
Вообще это все звучит довольно негативно, но просто стоит понимать что я скорее ищу границы, где инструмент полезен, чем пытаюсь кому-то доказать что он плохой. Чтобы понять как мне его использовать наиболее эффективно. Но во много работа с GPT через запросы прям сильно по ощущениям смахивала на вот этого персонажа из криминального чтива
Так же обратил внимание, что во время ожидания ответа получается эффект "выпадения из потока". То есть я сделал запрос на изменение и сижу жду, начинаю неизбежно отвлекаться и как будто бы где-то начинаю терять фокусировку. Когда пишешь код сам, такого нет
Вообще это все звучит довольно негативно, но просто стоит понимать что я скорее ищу границы, где инструмент полезен, чем пытаюсь кому-то доказать что он плохой. Чтобы понять как мне его использовать наиболее эффективно. Но во много работа с GPT через запросы прям сильно по ощущениям смахивала на вот этого персонажа из криминального чтива
И я думаю этот эксперимент все еще кривой и косой, т.к. очевидно мои промты далеки от идеала, у меня не настроены правила для cursor'а, из-за чего получаю не совсем тот код, что хочу видеть. Этим определенно стоит заняться, почитать недавнюю статью по промт-инжинирингу
Kaggle
Prompt Engineering
Kaggle is the world’s largest data science community with powerful tools and resources to help you achieve your data science goals.
Попробуем подвести итоги.
В начале я задался задачей написать новый тип виджета, чуть выше среднего по сложности. Мне хотелось понять, насколько GPT в виде cursor бустит меня и нащупать границы эффективности.
Мои выводы:
- GPT отлично генерит "болванку", а сам cursor отлично заворачивает это в проект - создает файлы и тп
- но он хреново понимает что мне в действительности нужно. Практически всю логику виджета пришлось так или иначе переписать, остались буквально самые тупые методы где ошибиться было максимально сложно
- нужно прокачивать промт-инжиниринг, это влияет
- короткие простые действия проще сделать руками. Это тупо быстрее
Дополнительно отмечу что я сидел в двух IDE Одновременно - MSVS и Cursor. Это мягко говоря не удобно, а переучиваться на VS Code (коим по факту является Cursor) сходу сложновато. Нужно настраивать окружение, учить новые хоткеи, да и честно сказать по функционалу он похуже чем MSVS + Visual Assist X. В идеале бы иметь такой инструментарий прямо в MSVS. Оно есть вроде бы как, но у меня все разваливалось при любых попытках что-то поменять через чат
В начале я задался задачей написать новый тип виджета, чуть выше среднего по сложности. Мне хотелось понять, насколько GPT в виде cursor бустит меня и нащупать границы эффективности.
Мои выводы:
- GPT отлично генерит "болванку", а сам cursor отлично заворачивает это в проект - создает файлы и тп
- но он хреново понимает что мне в действительности нужно. Практически всю логику виджета пришлось так или иначе переписать, остались буквально самые тупые методы где ошибиться было максимально сложно
- нужно прокачивать промт-инжиниринг, это влияет
- короткие простые действия проще сделать руками. Это тупо быстрее
Дополнительно отмечу что я сидел в двух IDE Одновременно - MSVS и Cursor. Это мягко говоря не удобно, а переучиваться на VS Code (коим по факту является Cursor) сходу сложновато. Нужно настраивать окружение, учить новые хоткеи, да и честно сказать по функционалу он похуже чем MSVS + Visual Assist X. В идеале бы иметь такой инструментарий прямо в MSVS. Оно есть вроде бы как, но у меня все разваливалось при любых попытках что-то поменять через чат
Теперь циферки!
Изначально GPT сгенерил мне 860 строк кода, поверх них пришлось сделать 490 строк изменений. По количеству измененных строк получается что я переработал 55% кода, то есть тот самый code acceptance получился 45%. Забавно, что ранее я "на чуйке" предположил что мне cursor дает буст где-то в 40%, получилось довольно близко. Стоит понимать что почти все 45% - это то что было сгенерено в первом запросе, при генерации болванки. И это самый тупой и рутинный код, который остался. Везде, где была реальная логика виджета - все переписано. Местами вручную, местами через запросы в чат
Но мы ведь знаем, что не в строках дело, а во времени? Тут я бы сказал что профит у меня получился около 10%. Точно не замерял, ведь делал урывками на больничном. Плюс я постоянно экспериментировал, и бывало делал запрос, который обрабатывался явно дольше, чем я бы сделал сам. Например почистить работу с ненужными стейтами. Так что я думаю тут цифра должна приближаться к тем же 40% в идеале.
И опять же, зависит от задачи. Для такой средне-сложно это вполне реально. Для более простых эффект будет еще больше. Но не все задачи такие. Например, днем раньше я отлаживал неправильное перестроение виджета меню при изменении списка элементов. Они просто пропадали. В итоге я нашел проблему и само изменение довольно небольшое по диффу (вот он кстати), однако я потратил добрых несколько часов на отладку и попытки понять что происходит. Здесь GPT мне бы не помог совсем никак
Изначально GPT сгенерил мне 860 строк кода, поверх них пришлось сделать 490 строк изменений. По количеству измененных строк получается что я переработал 55% кода, то есть тот самый code acceptance получился 45%. Забавно, что ранее я "на чуйке" предположил что мне cursor дает буст где-то в 40%, получилось довольно близко. Стоит понимать что почти все 45% - это то что было сгенерено в первом запросе, при генерации болванки. И это самый тупой и рутинный код, который остался. Везде, где была реальная логика виджета - все переписано. Местами вручную, местами через запросы в чат
Но мы ведь знаем, что не в строках дело, а во времени? Тут я бы сказал что профит у меня получился около 10%. Точно не замерял, ведь делал урывками на больничном. Плюс я постоянно экспериментировал, и бывало делал запрос, который обрабатывался явно дольше, чем я бы сделал сам. Например почистить работу с ненужными стейтами. Так что я думаю тут цифра должна приближаться к тем же 40% в идеале.
И опять же, зависит от задачи. Для такой средне-сложно это вполне реально. Для более простых эффект будет еще больше. Но не все задачи такие. Например, днем раньше я отлаживал неправильное перестроение виджета меню при изменении списка элементов. Они просто пропадали. В итоге я нашел проблему и само изменение довольно небольшое по диффу (вот он кстати), однако я потратил добрых несколько часов на отладку и попытки понять что происходит. Здесь GPT мне бы не помог совсем никак
GitHub
Edit box drop down diff from AI · o2-engine/o2@eb701b3
2D Game Engine with visual WYSIWYG editor and JS scripting - Edit box drop down diff from AI · o2-engine/o2@eb701b3
This media is not supported in your browser
VIEW IN TELEGRAM
Редактор стейт мешины уже похож на что-то нормальное. Забавно, на него я уже убил х10 раз времени, чем на сам рантайм стейт машины
Небольшой детектив.
Ковыряю я в отпуске mac платформу. В основном это мелкие фиксы, но есть одна особенность под этой платформой - это масштабирование. Так как разрешение экрана довольно большое, 4к, то рендерить редактор в масштабе 1 к 1 получается так себе. Все слишком мелкое и с этим невозможно работать. Но при этом система предоставляет коэфициент масштаба равному двум.
Весь вопрос как его заиспользовать. Первый мой подход был довольно наивен - просто сделать масштаб камеры кратным двум. Изи-пизи, плюс изменить размер рутовой ноды UI редактора так же кратно двум. Сходу все работает, но есть нюанс с рендер-таргетами и интерактивной областью внутри них, а именно координаты курсора неправильно трансформируются в локальное пространство
Ковыряю я в отпуске mac платформу. В основном это мелкие фиксы, но есть одна особенность под этой платформой - это масштабирование. Так как разрешение экрана довольно большое, 4к, то рендерить редактор в масштабе 1 к 1 получается так себе. Все слишком мелкое и с этим невозможно работать. Но при этом система предоставляет коэфициент масштаба равному двум.
Весь вопрос как его заиспользовать. Первый мой подход был довольно наивен - просто сделать масштаб камеры кратным двум. Изи-пизи, плюс изменить размер рутовой ноды UI редактора так же кратно двум. Сходу все работает, но есть нюанс с рендер-таргетами и интерактивной областью внутри них, а именно координаты курсора неправильно трансформируются в локальное пространство
И вот незадача - они не совпадают. Сначала я подумал что где-то не учел масштаб х2 и нужно просто куда-то воткнуть этот коэфициент. Попробовав запихать его в разные места и даже немножко подумав, ничего не выходило.
В этот момент я обратил внимание на странную особенность - по Х позиция курсора высчитывается верно, а вот Y зависит от масштаба камеры внутри редактора сцены
WTF вообще подумал я сначала 🤨 иии тут меня повело в какую-то неправильную сторону... ведь я стал грешить на особенности mac платформы.
Такое бывает, компиляторы работают по-разному, стандартные библиотеки разные, даже вмешивается особенность процессоров. И я уже несколько таких артефактов поборол до этого. Поэтому мне показалось логичным что дело именно в этом.
Дошло до того, что я поставил рядом windows ноутбук и писал одинаковый отладочный код на win/mac сравнивая результаты. И что произошло? Правильно, различий никаких не было 🥲
Однако работало очевидно неправильно. На windows все впорядке, крестики 1 к 1 без всяких сдвигов вне зависимости от всего. В какой-то момент показалось что зависит от размера окна редактора, но нет...
Я вернулся к мысли что по Х все таки координата рассчитывалась верно, а по Y - нет. Точнее визуально было так. И я стал думать (эх, ключевое) где бы могла похериться Y координата. И я вспомнил про специальных хак для рендер-таргетов на mac: в определенном месте матрица трансформации переворачивалась по Y, это было сделано специально, тк рендер-таргет был перевернут.
В итоге я понял, что в математике проблем нет и процессор Apple считается все верно, а вот проблема как раз была в рендеринге картинки, частью которой был зеленый крестик все никак не совпадавший с красным
Переворот по Y для рендер-таргета пришлось переделать, сделать переворот еще ДО применения видовой матрицы, где задается трансформация камеры. И вауля, крестики совпали и проблема ушла
Такая вот поучительная история, которая в очередной раз показала: если тебе кажется что проблема в компиляторе/процессоре/частицах из космоса выбивающих бит из RAM, то проблема очевидно в тебе
В этот момент я обратил внимание на странную особенность - по Х позиция курсора высчитывается верно, а вот Y зависит от масштаба камеры внутри редактора сцены
WTF вообще подумал я сначала 🤨 иии тут меня повело в какую-то неправильную сторону... ведь я стал грешить на особенности mac платформы.
Такое бывает, компиляторы работают по-разному, стандартные библиотеки разные, даже вмешивается особенность процессоров. И я уже несколько таких артефактов поборол до этого. Поэтому мне показалось логичным что дело именно в этом.
Дошло до того, что я поставил рядом windows ноутбук и писал одинаковый отладочный код на win/mac сравнивая результаты. И что произошло? Правильно, различий никаких не было 🥲
Однако работало очевидно неправильно. На windows все впорядке, крестики 1 к 1 без всяких сдвигов вне зависимости от всего. В какой-то момент показалось что зависит от размера окна редактора, но нет...
Я вернулся к мысли что по Х все таки координата рассчитывалась верно, а по Y - нет. Точнее визуально было так. И я стал думать (эх, ключевое) где бы могла похериться Y координата. И я вспомнил про специальных хак для рендер-таргетов на mac: в определенном месте матрица трансформации переворачивалась по Y, это было сделано специально, тк рендер-таргет был перевернут.
В итоге я понял, что в математике проблем нет и процессор Apple считается все верно, а вот проблема как раз была в рендеринге картинки, частью которой был зеленый крестик все никак не совпадавший с красным
Переворот по Y для рендер-таргета пришлось переделать, сделать переворот еще ДО применения видовой матрицы, где задается трансформация камеры. И вауля, крестики совпали и проблема ушла
Такая вот поучительная история, которая в очередной раз показала: если тебе кажется что проблема в компиляторе/процессоре/частицах из космоса выбивающих бит из RAM, то проблема очевидно в тебе