Пара слов о ткущей работе - прикрутил к движку spine. Это распространенная тулза и runtime для скелетных анимаций. Интересно то, что фактически в движке у меня уже есть аналогичная система скелетной анимации, в т.ч. с поддержкой скиннинга.
Но для стороннего использование наличие интеграции spine в движок все же важна, т.к. банально у многих уже настроены пайплайны под него. И, так как мой движок отчасти позиционируется как встраиваемый в другие движки и проекты, то там вероятно уже есть ассеты spine анимаций и их нужно уметь использовать.
Своя система, конечно же интегрирована в движок более нативною Она построена на иерархии сцены и она более плотно интегрирована со всеми подсистемами движка: те же анимации и частицы. Мой классический пример: в UI есть скелетная анимация персонажа с эффектами частиц в руке (фаерболл например). Если пытаться все это связать из сторонних инструментов, получается франкинштейн: spine и UI не связаны, придется делать какие-то мокапы и подложки. То же самое с частицами, их не получится увидеть в редакторе spine. В этом плане свое решение гораздо более выигрышно, ведь все находится в одной экосистеме и нативно состыкуется друг с другом.
Однако, в текущее время spine - это стандарт индустрии, и, с учетом вышеперечисленных доводов, без его поддержки не обойтись. Хотя, у меня есть идея попробовать сделать конвертер spine анимаций в мой нативный формат. Тогда получится взять плюсы с обоих подходов.
Тем не менее, я стараюсь сделать все чтобы тот же сторонний spine как можно лучше был интегрирован в экосистему движка. Его анимации для движка выглядят как реализация интерфейса IAnimation, соответственно их можно использовать как и нативные анимации движка - делать саб-треки, использовать из кода и т.п.
Так же сейчас делаю аналог Animator'а из Unity3D - граф анимационных состояний. Он сможет работать как с нативными анимациями, так и со spine.
Но для стороннего использование наличие интеграции spine в движок все же важна, т.к. банально у многих уже настроены пайплайны под него. И, так как мой движок отчасти позиционируется как встраиваемый в другие движки и проекты, то там вероятно уже есть ассеты spine анимаций и их нужно уметь использовать.
Своя система, конечно же интегрирована в движок более нативною Она построена на иерархии сцены и она более плотно интегрирована со всеми подсистемами движка: те же анимации и частицы. Мой классический пример: в UI есть скелетная анимация персонажа с эффектами частиц в руке (фаерболл например). Если пытаться все это связать из сторонних инструментов, получается франкинштейн: spine и UI не связаны, придется делать какие-то мокапы и подложки. То же самое с частицами, их не получится увидеть в редакторе spine. В этом плане свое решение гораздо более выигрышно, ведь все находится в одной экосистеме и нативно состыкуется друг с другом.
Однако, в текущее время spine - это стандарт индустрии, и, с учетом вышеперечисленных доводов, без его поддержки не обойтись. Хотя, у меня есть идея попробовать сделать конвертер spine анимаций в мой нативный формат. Тогда получится взять плюсы с обоих подходов.
Тем не менее, я стараюсь сделать все чтобы тот же сторонний spine как можно лучше был интегрирован в экосистему движка. Его анимации для движка выглядят как реализация интерфейса IAnimation, соответственно их можно использовать как и нативные анимации движка - делать саб-треки, использовать из кода и т.п.
Так же сейчас делаю аналог Animator'а из Unity3D - граф анимационных состояний. Он сможет работать как с нативными анимациями, так и со spine.
This media is not supported in your browser
VIEW IN TELEGRAM
Немного красоты 🤩
анимация переключения стейтов графа анимаций в редакторе. Синенькое - запланировано, красное - пройдено
анимация переключения стейтов графа анимаций в редакторе. Синенькое - запланировано, красное - пройдено
Самое важное качество UID'ов заключается в их уникальности. Случайно сгенерированный 128-битный UID практически гарантирует абсолютную уникальность. Конечно, теоретически повтор возможен, но вероятность этого настолько ничтожна, что на практике, даже если генерировать по несколько идентификаторов в секунду, вы не столкнётесь с таким событием на протяжении всей своей жизни.
Дополнительно некоторые «взрослые» реализации UID'ов включают в себя временную метку (таймстемп) генерации, что ещё сильнее снижает вероятность дублирования. Также типичная реализация UID может включать информацию о версии UID (тип генерации: рандомный, с таймстемпом или на основе MAC-адреса), данные о машине или устройстве (например, MAC-адрес, идентификатор узла или процессора) и служебные или зарезервированные биты для совместимости и будущих расширений.
Но зачем вообще использовать UID'ы? Ответ прост: они незаменимы для идентификации уникальных сущностей. Например, в разработке игр и движков часто возникает необходимость чётко различать различные игровые ассеты.
Кажется, можно просто использовать строковый идентификатор на основе имени ассета. Такой подход удобен, но быстро проявляется проблема повторяющихся названий. Например, часто возникает необходимость назвать два разных объекта одинаково, скажем "door". Тогда можно было бы использовать префиксы и суффиксы (например, "door_left", "door_right") или включать в идентификатор путь по папкам и подпапкам (например, "rooms/left/door", "dooms/right/door").
Однако, если возникает необходимость переместить ассет в другую папку или переименовать его, строковый идентификатор становится неактуальным. Вместо строки можно использовать уникальный идентификатор или индекс. Например, последовательный счётчик, увеличивающийся с каждым новым ассетом, обеспечивает простой и понятный способ генерации идентификаторов. Но если ассеты генерируются независимо на нескольких компьютерах или в разных точках проекта, счётчик не будет синхронизирован, и повторения идентификаторов гарантированы.
Здесь идеально подходят UID'ы. Их уникальность достигается за счёт случайной генерации и большой разрядности, что исключает повторения даже при параллельной генерации.
Внутри же других ассетов (префабов, конфигов, сцен и т.д.) ссылки могут быть сохранены в виде UID'ов. Пользователям не важно, в каком виде хранятся эти ссылки, главное — удобство и понятность названий в редакторе.
Ассеты — не единственная область применения UID'ов. Они отлично подходят для идентификации любых уникальных объектов, таких как ноды на сцене, ключи анимаций и многие другие.
Дополнительно некоторые «взрослые» реализации UID'ов включают в себя временную метку (таймстемп) генерации, что ещё сильнее снижает вероятность дублирования. Также типичная реализация UID может включать информацию о версии UID (тип генерации: рандомный, с таймстемпом или на основе MAC-адреса), данные о машине или устройстве (например, MAC-адрес, идентификатор узла или процессора) и служебные или зарезервированные биты для совместимости и будущих расширений.
Но зачем вообще использовать UID'ы? Ответ прост: они незаменимы для идентификации уникальных сущностей. Например, в разработке игр и движков часто возникает необходимость чётко различать различные игровые ассеты.
Кажется, можно просто использовать строковый идентификатор на основе имени ассета. Такой подход удобен, но быстро проявляется проблема повторяющихся названий. Например, часто возникает необходимость назвать два разных объекта одинаково, скажем "door". Тогда можно было бы использовать префиксы и суффиксы (например, "door_left", "door_right") или включать в идентификатор путь по папкам и подпапкам (например, "rooms/left/door", "dooms/right/door").
Однако, если возникает необходимость переместить ассет в другую папку или переименовать его, строковый идентификатор становится неактуальным. Вместо строки можно использовать уникальный идентификатор или индекс. Например, последовательный счётчик, увеличивающийся с каждым новым ассетом, обеспечивает простой и понятный способ генерации идентификаторов. Но если ассеты генерируются независимо на нескольких компьютерах или в разных точках проекта, счётчик не будет синхронизирован, и повторения идентификаторов гарантированы.
Здесь идеально подходят UID'ы. Их уникальность достигается за счёт случайной генерации и большой разрядности, что исключает повторения даже при параллельной генерации.
Внутри же других ассетов (префабов, конфигов, сцен и т.д.) ссылки могут быть сохранены в виде UID'ов. Пользователям не важно, в каком виде хранятся эти ссылки, главное — удобство и понятность названий в редакторе.
Ассеты — не единственная область применения UID'ов. Они отлично подходят для идентификации любых уникальных объектов, таких как ноды на сцене, ключи анимаций и многие другие.
ps: текст помогал генерировать GPT, интереса ради, как интереснее читать, когда автор сам пишет в своем стиле или все мысли укладываются и усредняются через AI?
Понабрасываем на хайповую тему - AI.
Нынче такое время, что из каждого утюга только и звенит "AI нас заменят, разработчики с AI в 10 раз производительнее, джун с AI лучше заменит трех сениоров" и так далее. У многих, не буду скрывать и у меня, это вызывает естественные опасения за свою профессию, достаток и свое будущее. Раньше мы смелись над таксистами, что яндекс и убер схавали их рынок, а скоро так вообще роботы заменят
Ладно, к чему я. Так ли все круто? Не тот ли это случай, когда какая-то новая штука так впечатляет своей новизной, что люди начинают верить в чудеса и светлое будущее которое настанет прямо сейчас? Ну, такое было, знаете, про VR шлемы и криптовалюты... Не буду даже вспоминать про 3D телики, которые уже скоро станут раритетом
Я попробовал поразмышлять, в более реалистичном и может быть даже пессимистичном ключе, насколько все хорошо в текущем AI, в разрезе программирования. Я с интересом наблюдаю за другими, провожу свои эксперименты и пытаюсь нащупать границу возможного
Нынче такое время, что из каждого утюга только и звенит "AI нас заменят, разработчики с AI в 10 раз производительнее, джун с AI лучше заменит трех сениоров" и так далее. У многих, не буду скрывать и у меня, это вызывает естественные опасения за свою профессию, достаток и свое будущее. Раньше мы смелись над таксистами, что яндекс и убер схавали их рынок, а скоро так вообще роботы заменят
Ладно, к чему я. Так ли все круто? Не тот ли это случай, когда какая-то новая штука так впечатляет своей новизной, что люди начинают верить в чудеса и светлое будущее которое настанет прямо сейчас? Ну, такое было, знаете, про VR шлемы и криптовалюты... Не буду даже вспоминать про 3D телики, которые уже скоро станут раритетом
Я попробовал поразмышлять, в более реалистичном и может быть даже пессимистичном ключе, насколько все хорошо в текущем AI, в разрезе программирования. Я с интересом наблюдаю за другими, провожу свои эксперименты и пытаюсь нащупать границу возможного
Расскажу свою точку зрения, на текущий момент. Да, черт возьми, меняется все так быстро, что нельзя загадывать даже на год вперед!
Итак, мы определенно идем в этом направлении: AI развивается и он уже имеет прикладное применение. Это невозможно отрицать и сопротивляться этому, это нужно просто принять. Иначе ты окажешься "за бортом", вопрос лишь в том насколько быстро
И насколько быстро? Да хер знает. Может быть generai AI (в моем понимании это AI, который может мыслить как человек) выкатят вот завтра, а может лет так через 20. Мне кажется сейчас две ключевые проблемы, которые осталось преодолеть:
- понимание как в принципе сделать general AI. Мы либо очень близки, либо уже умеем, но это не афишируется (рен-тв в чяте)
- вычислительные мощности
И мне кажется мы упремся во второй пункт, как ни странно. Где-то слышал, что тот жe OpenAI работает в минус, и доступные возможности заканчиваются (тут я очевидно дилетант, возможно несу чепуху). И что уже все доступные текста человечества стравили в сеть, то есть учить ее больше нечему. То есть, возможно, мы уже "уперлись". Мы определенно упираемся в текущий прогресс по чипам, используем максимум того что сейчас есть.
Здесь выплывает сразу два фактора:
- верхняя планка возможностей железа (точнее кремния, хех)
- экономическая целесообразность
Уверен чипы будут прогрессировать. Ну, прогрессируют пока что. А вот экономическая целесообразность - это прям то что будет определять заменить ли робот человека
Давайте представим, что УЖЕ изобрели general AI. Это точно он и все понимают что это работает. Но что если он будет занимать целую комнату и жрать гигатонну электричества ежесекундно, как первые компьютеры? То есть штука рабочая, но жутко затратная, и все таки офисный клерк, кушающий еду, спящий ночью и уходящий в отпуск на месяц в год тупо оказывается дешевле
Да, человечество поставит галку "искусственный интеллект", но экономически людей заменять будет не эффективно. Самый замес произойдет тогда, когда это станет выгоднее хотя бы на доллар, чем мясной скафандр для органической нейросети
А пока этого не произошло, можно не бояться что нас заменит яндекс или OpenAI
Моя "экспертная оценка пальцем в небо" - у нас есть 20-30 лет. Мы пройдем через стадии: изобретение general AI, наращивание мощностей и запихивание комнаты в наладонник, замещение человека на рабочих местах,матрица революция гххмм тут я думаю будет что-то вроде ассимиляции, то есть мы просто соединим свои мозги с электронными и продолжим развиваться дальше
Итак, мы определенно идем в этом направлении: AI развивается и он уже имеет прикладное применение. Это невозможно отрицать и сопротивляться этому, это нужно просто принять. Иначе ты окажешься "за бортом", вопрос лишь в том насколько быстро
И насколько быстро? Да хер знает. Может быть generai AI (в моем понимании это AI, который может мыслить как человек) выкатят вот завтра, а может лет так через 20. Мне кажется сейчас две ключевые проблемы, которые осталось преодолеть:
- понимание как в принципе сделать general AI. Мы либо очень близки, либо уже умеем, но это не афишируется (рен-тв в чяте)
- вычислительные мощности
И мне кажется мы упремся во второй пункт, как ни странно. Где-то слышал, что тот жe OpenAI работает в минус, и доступные возможности заканчиваются (тут я очевидно дилетант, возможно несу чепуху). И что уже все доступные текста человечества стравили в сеть, то есть учить ее больше нечему. То есть, возможно, мы уже "уперлись". Мы определенно упираемся в текущий прогресс по чипам, используем максимум того что сейчас есть.
Здесь выплывает сразу два фактора:
- верхняя планка возможностей железа (точнее кремния, хех)
- экономическая целесообразность
Уверен чипы будут прогрессировать. Ну, прогрессируют пока что. А вот экономическая целесообразность - это прям то что будет определять заменить ли робот человека
Давайте представим, что УЖЕ изобрели general AI. Это точно он и все понимают что это работает. Но что если он будет занимать целую комнату и жрать гигатонну электричества ежесекундно, как первые компьютеры? То есть штука рабочая, но жутко затратная, и все таки офисный клерк, кушающий еду, спящий ночью и уходящий в отпуск на месяц в год тупо оказывается дешевле
Да, человечество поставит галку "искусственный интеллект", но экономически людей заменять будет не эффективно. Самый замес произойдет тогда, когда это станет выгоднее хотя бы на доллар, чем мясной скафандр для органической нейросети
А пока этого не произошло, можно не бояться что нас заменит яндекс или OpenAI
Моя "экспертная оценка пальцем в небо" - у нас есть 20-30 лет. Мы пройдем через стадии: изобретение general AI, наращивание мощностей и запихивание комнаты в наладонник, замещение человека на рабочих местах,
Ладно, тут не рент-тв, а про программинг. Перейдем к конкретным кейсам
У меня, где-то год с лишним назад, когда ChatGPT вот вот вылупился, были пару экспериментов.
Первый - написать скрипт по граббингу банковскийх данных из csv в гугл-таблицу в определенном формате и с небольшой логикой: группировать покупки по дням не более 7 штук в день, с переносом на следующий если не влазит. Тогда ChatGPT фактически не справился и я буквально диктовал ему что нужно делать. Но, конечно, он снимал все проблемы по работе с google sheets api
Второй - рефакторинг движка с сырых указателей на умные, и там GPT тоже обосрался, выдавай хороший результат вперемешку с несусветной херью, из-за чего время на ручную фильтрацию было равносильно тому, чтобы сделать все самому вручную. О нем даже писал ранее
Первый - написать скрипт по граббингу банковскийх данных из csv в гугл-таблицу в определенном формате и с небольшой логикой: группировать покупки по дням не более 7 штук в день, с переносом на следующий если не влазит. Тогда ChatGPT фактически не справился и я буквально диктовал ему что нужно делать. Но, конечно, он снимал все проблемы по работе с google sheets api
Второй - рефакторинг движка с сырых указателей на умные, и там GPT тоже обосрался, выдавай хороший результат вперемешку с несусветной херью, из-за чего время на ручную фильтрацию было равносильно тому, чтобы сделать все самому вручную. О нем даже писал ранее
С тех пор многое шагнуло вперед, и сами сетки подросли и поумнели, и появились классные инструменты, например cursor. Если кто не знает, это форк от VS Code, в редактор текста которого плотно интегрирована работа с GPT. Он просто делает всю ту ручную херню, когда тебе нужно копипастить из ChatGPT в IDE
Cursor
Cursor - The AI Code Editor
Built to make you extraordinarily productive, Cursor is the best way to code with AI.
Уже давно я плотно подсел на copilot. Я никогда не ждал от него качественных решений, для меня это был умный автокомплит, просто ускоряющий набор текста для меня. Плюс справочник прямо на месте - либо комментом можно было спросить, либо он по контексту сам понимал что мне нужно и предлагал. Это очень полезно при работе с неизвестным API или языком, этап гуглежки сводится практически к нулю
microsoft утверждает что copilot может бустануть скорость программирования до 30%. Ну как мы понимаем до 30% может быть что угодно, хоть 29%, хоть 10%, хоть 0%. У меня по ощущениям это где-то 20%. И, вообще-то, это не мало!
Но подчеркну, это не замена моих инженерных навыков, думал и придумывал я сам, а copilot помогал мне набирать код значительно быстрее
microsoft утверждает что copilot может бустануть скорость программирования до 30%. Ну как мы понимаем до 30% может быть что угодно, хоть 29%, хоть 10%, хоть 0%. У меня по ощущениям это где-то 20%. И, вообще-то, это не мало!
Но подчеркну, это не замена моих инженерных навыков, думал и придумывал я сам, а copilot помогал мне набирать код значительно быстрее
Visual Studio
Visual Studio с GitHub Copilot — парное программирование с использованием ИИ
Новейшее взаимодействие GitHub Copilot интегрировано в Visual Studio и объединяет возможности Copilot и Copilot Chat в одном пакете.
Теперь кейсы из нынешних дней. И для начала не про кодинг, а про гугл-доки. Угу, туда тоже воткнули GPT, а точнее gemini. Блиин, я так ждал! Так хотелось длинные доки на работе скипать и читать выжимку, писать конкретные вопросы и тд. В общем тупо экономить время и силы
Эхх, разочарование. Я честно пробовал и хотел чтобы это работало, но мои последние результаты были из разряда "даептвоюжемать", то есть буквально бесполезны. Например, у нас в команде уже месяц с лишним есть док с краткими статусами по задачам 2 раза в неделю. Я подумал "а было бы прикольно спросить кто чем занимался, сколько времени в процентах от всей команды ушло на то и се". Этот "заменитель человеков" мало того что сожрал половину важной информации (просто скипнул задачи, которые точно были), так еще и начал придумывать что-то свое и ... барабанная дробь... слазил в чужие документы в пространстве (к артовикам) и приплел какую-то херню из него
Не, я понимаю, нужно точно задавать запросы, промт-инжиниринг и так далее.. Но камон, с таким запросом справится же буквально дебил, без объяснения деталей. Я очень надеюсь что он прокачается и моя рабочая рутина станет сильно легче
Сейм шит был и с таск-трекером asana. Там тоже есть кнопочка со звездочками, задача которой правдоподобно выдавать чепуху
Эхх, разочарование. Я честно пробовал и хотел чтобы это работало, но мои последние результаты были из разряда "даептвоюжемать", то есть буквально бесполезны. Например, у нас в команде уже месяц с лишним есть док с краткими статусами по задачам 2 раза в неделю. Я подумал "а было бы прикольно спросить кто чем занимался, сколько времени в процентах от всей команды ушло на то и се". Этот "заменитель человеков" мало того что сожрал половину важной информации (просто скипнул задачи, которые точно были), так еще и начал придумывать что-то свое и ... барабанная дробь... слазил в чужие документы в пространстве (к артовикам) и приплел какую-то херню из него
Не, я понимаю, нужно точно задавать запросы, промт-инжиниринг и так далее.. Но камон, с таким запросом справится же буквально дебил, без объяснения деталей. Я очень надеюсь что он прокачается и моя рабочая рутина станет сильно легче
Сейм шит был и с таск-трекером asana. Там тоже есть кнопочка со звездочками, задача которой правдоподобно выдавать чепуху
Google
Collaborate with Gemini in Google Docs (Workspace Labs) - Google Docs Editors Help
With Gemini in Google Docs, you can: Write and refine content in context. Summarize your files from Drive and emails from Gmail. Create images. Get creative ideas. Feature avail
Забавно, а ведь я думал что с задачей агрегации GPT справляется хорошо. Это ведь буквально то, как он устроен. Но из раза в раз замечаю закономерности, что GPT сглаживает какие-то важные детали, что-то упускает и забывает, и выдает максимально пресную, толератную информацию.
Особенно настораживает что он просто опускает какие-то детали, а это может быть очень важно в исследованиях
Особенно настораживает что он просто опускает какие-то детали, а это может быть очень важно в исследованиях
окей окей, скоро будет про код, обещаю.
Попробую обрисовать мои ощущения от вайб-программинга, использования современных сеток и самого топчика - ide cursor.
Вкратце - это все еще очень умное автодополнение, без какого-то нормального инженерного мышления. И это не инструмент замены инженера, но инструмент устранения рутины и соответственного буста производительности. Но нужно уметь "правильно его готовить"
Они все еще не решают мои инженерные задачи - там где нужно придумать, решить и построить цепочку выводов. Да, есть "мыслящие сетки", которые буквально строят цепочку размышлений, проверяют свои идеи. Но то что они выдают все еще похоже на шаблон, скелет или просто как отправную точку, с которой начинается инженерное дело.
Здесь снова эффект "экономической целесообразности". Иногда генерятся просто лишние вещи, очевидно ненужные. Можно попросить в чате "удоли это и то", а можно руками выделить текст и нажать backspace. Что быстрее? Вот вот, GPT будет раздупляться почти минуту, плюс руками набирать запрос, а ты сам почикаешь это за пять секунд мышкой и курсором
Попробую обрисовать мои ощущения от вайб-программинга, использования современных сеток и самого топчика - ide cursor.
Вкратце - это все еще очень умное автодополнение, без какого-то нормального инженерного мышления. И это не инструмент замены инженера, но инструмент устранения рутины и соответственного буста производительности. Но нужно уметь "правильно его готовить"
Они все еще не решают мои инженерные задачи - там где нужно придумать, решить и построить цепочку выводов. Да, есть "мыслящие сетки", которые буквально строят цепочку размышлений, проверяют свои идеи. Но то что они выдают все еще похоже на шаблон, скелет или просто как отправную точку, с которой начинается инженерное дело.
Здесь снова эффект "экономической целесообразности". Иногда генерятся просто лишние вещи, очевидно ненужные. Можно попросить в чате "удоли это и то", а можно руками выделить текст и нажать backspace. Что быстрее? Вот вот, GPT будет раздупляться почти минуту, плюс руками набирать запрос, а ты сам почикаешь это за пять секунд мышкой и курсором
Черт, если он пишет не финальный текст программы, а тебе его нужно доделывать... тебе нужно понимать что он написал!!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, казалось бы поженить их совсем не проблема. При этом писать виджеты - это довольно рутинная работа, но местами нужно подумать. Такой виджет сложнее среднего, поэтому стало интересно, какой профит я смогу получить. Я стал записывать все свои шаги
Сразу скажу, у меня плохо с промт-инжинирингом, поэтому мои запросы были довольно туповаты и короткие. Но черт, в этом ведь смысл, если запрос будет сложным и длинным, то это равносильно написанию кода