Я на работе показал что-то из старого проекта, где я читаю из Оракла, но убираю бинарные данные типа там PDF. Так он предложил убрать мои костыли, но добавить одну строку, где собственно включается опция коннектора Оракла. Я так понимаю он из комментариев понял что надо делать. Но я просто не знал что такая опция уже есть и сделал вручную. Можно сказать унизил.

А вы уверены, что он вас "унизил", а не просто использует новую опцию в новой версии коннектора, который во время написания вами "костылей" могло и не быть?

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

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

Если для того, чтобы объяснить ИИ, как писать, и добиться от него правильного результата, нужно процентов на 70-80 самому разобраться в вопросе, то нафига мне время тратить на объяснения ИИ? Оставшиеся 20-30% работы я и сам могу сделать.

Как вы правильно заметили, ваша продуктивная работа с ИИ заключалась в том, что вы недостаточно знали тему, поэтому писали костыли. И тут может быть ловушка. Если тему знаешь слишком недостаточно, то не сможешь проверить, верно ли ответил ИИ, а не сгаллюцинировал. Ну т.е. проверка будет лишь по факту запуска и возникновения ошибки. А если знаешь тему хорошо, то лучше писать самому, а не рисковать нарваться на глюки ИИ. Получается, ИИ полезен лишь в каком-то узком диапазоне соотношения ваших знаний и незнаний по данной теме. Сравните это со скриптами тожй же кодогенерации и сниппетов, которые полезны всегда, ибо результат их работы всегда детерминирован и предсказуем. Т.е. если скрипт составлен верно, он продуцирует всегда верные результаты. А если промпт составлен верно, то далеко не факт, что ИИ выдаст верные результаты, а если выдаст, то не факт, что они будут повторяться всегда.

При ошибке, полёт кубарем и вверх тормашками с очевидными последствиями будет аналогичным.

у каждого может быть свое мнение. По поводу полезности/не полезности ИИ дискутировать не собираюсь.

Мне подходит, вам нет - каждому своё.

Как вы правильно заметили, ваша продуктивная работа с ИИ заключалась в том, что вы недостаточно знали тему, поэтому писали костыли.

Просто мне надо решить проблему и я ее решил с помощью 10 строк кода, а выискивать нужну опицию коннектора времени нет да и риск тоже - а вдруг ее нет. Ну в общем, тут получается сотрудничество писателя и "литературного раба". Правда не ясно кто в нашем случае писатель (официальный автор произведеения), а кто "литературный раб".

Но а так потихоньку все больше привыкаешь нажимать клавишу Tab при разработке с ИИ помошником:

Всё, лично у меня на сегодня токены по печати текста закончились. )))

Как я понимаю no referrer страницы просто сами стираются и не выходят в транш. Токены не закончились, и работают только при активации объектов и субъектов с определенным уровнем задач и в определенное время. Никакого кода при этом не нужно. См.инструкцию "мои программы"

нужно процентов на 70-80 самому разобраться в вопросе

ну так это обязательное условие для любого использования ИИ. При этом не уверен, что и 80% будет достаточно.

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

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

Но похоже и старый и новый проекты слишком заумно сделаны и не следуют никаким рекомендациям.

заключалась в том, что вы недостаточно знали тему, поэтому писали костыли

не совсем так. Допустим, я не знаю как мне из ПДФ вытащить текст, но я точно знаю как должен будет выглядеть подобный код в общем.

Если общий вид подходит, то берём. А если там уже мелочи неправильно работают, то можно сделать или на следующей итерации или самому.

А если знаешь тему хорошо, то лучше писать самому,

зачем писать самому то что хорошо знаешь? Пусть тебе дают уже готовое сразу видно где проблема.

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

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

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

На своё время там всё было сделано по лучшим практикам - многослойность, всё через интерфейсы-контракты, хранимые вообще в отдельных проектах (даже не одном). Многосерверная архитектура с кучей сервисов. Чтобы сделать одну бизнес-операцию, нужно было столько действий выполнить. Многие сущности конструировались на лету из динамических конфигураций. Мы сейчас делаем проще, всё будет не на распределённой по городам системе выполняться, а в рамках одной локации, несколько сторонних сервисов отпадают, старые технологии отключаем. Но всё равно они хотят максимально абстрагироваться от всех гуёвых фреймворков, для чего вводят пару слоёв абстракций. Т.е. как бы MVC-MVVM, но с подвывертом. Раньше было сложнее. И это при том, что все эти абстракции, насколько я знаю, не понадобились за почти два десятка лет работы программы. Как был один гуй, так и остался. Базу данных лишь сменили, но и тут зачем-то пилят свой слой абстракций (раньше было два, включая свой язык запросов, приводимый к SQL и ещё паре других языков). И вот в таком проекте надо использовать ИИ. Интересно, сколько ресурсов ему надо будет, чтобы просто контекст всего проекта в памяти держать.

По мне, если сделать сейчас на одном фреймворке и одной БД и забить, оно ещё минимум лет 10-15 так проработает. А потом можно снова переписать. И это будет в разы быстрее, чем подгонять текущие абстракции под возможные будущие фреймворки (или наоборот - пытаться использовать новые фреймворки под старые абстракции). Но с другой стороны, идёт опыт с современным веб-фреймворком (модное веб-ассембли, PWA и что там ещё у смузихлёбов популярно), проект растягивается, работа есть... )))

А если знаешь тему хорошо, то лучше писать самому,

зачем писать самому то что хорошо знаешь? Пусть тебе дают уже готовое сразу видно где проблема.
У вас просто желания неправильные. Хочу всё и сразу, готовое и без ошибок.

Тут ещё есть тонкий момент. ИИ помощник работает хорошо у того, кто и так всё знает. А новые разработчики будут обучаться не свой код писать, а сходу использовать помощников. В результате их знания языка и фреймворков будут куда слабее чем у тех, кто сам всё писал и исправлял. Это же верно для "всё старое знающих", но изучающих новые для себя темы. Они уже даже близко не будут разбираться на 80%+, чтобы решать, годен ли код, предоставленный ИИ, или нет.

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

На своё время там всё было сделано по лучшим практикам

трудно судить, не видя проекта и не зная всех задач.

Но ваше описание говорит об обратном.

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

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

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

будут - значит опять фантазии. А они у вас очень необузданные.

Но ваше описание говорит об обратном.

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

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

будут - значит опять фантазии. А они у вас очень необузданные.

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

Скорее о том, что лучшие практики оказались не лучшими

не уверен, скорее о неадекватности разработчиков.

Любую даже самую хорошую идею можно довести до абсурда.

Помню времена, когда один коллега тащил в проект всё "интересное" что вычитал в своём любимом компьютерном журнале.

Не что...бизнес работает? На втором шагу показывает ошибки. Какой то деструктивный бизнес однако..

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

А у вас какой-то безудержный оптимизм

не думаю что где-то сильно на каком то "конце". Стараюсь не ударяться в крайности.

получал опыт, в том числе, как делать не надо

В этом я сомневаюсь.

если сделать сейчас на одном фреймворке и одной БД

опять-таки как сделать? Если всё в одном проекте и путём вызова "динамического" SQL на запрос, то лучше не надо.

опять-таки как сделать? Если всё в одном проекте и путём вызова "динамического" SQL на запрос, то лучше не надо.

Смотрите, какой классный фреймворк! Пользовались? (там надо вниз мотать, чтобы примеры увидеть)

Надо бы притащить в проект.

Вот, кстати, что-то подобное через активатор использовалось в старой версии нашего проекта - сущности хранились в БД и можно было их конструировать, заполняя эту БД. Потом через XML или ещё как пересылалось на нужный сервер, там создавался объект и использовался. Только то было написано для Дотнета 2.0, с кучей самописных костылей, т.к. много вещей ещё не существовало. А тут проще сделано

DynamicProperty[] props = new DynamicProperty[]
{
    new DynamicProperty("Name", typeof(string)),
    new DynamicProperty("Birthday", typeof(DateTime))
};

Type type = System.Linq.Dynamic.DynamicExpression.CreateClass(props);

object obj = Activator.CreateInstance(type);

Надо бы притащить в проект.

Извращенцы есть везде

У тебя деменция что ли? Ты этот Фреймворк года полтора назад уже рекламировал.

Список длинный будет особенно если взять 6 параграф .