Прогресс налицо⁠⁠

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

Звучит как skill issue. Подсказка, если вы видите, что модель сделала что-то не так, то спросите у неё почему она так сделала/что-то не сделала. Исходя из ответа, расширьте репо, что в след раз у модели будет понимание, какие тесты нужны, какое e2e надо прогонять, какие пользовательские сценарии есть. Со временем в репо накопится достаточно контекста, что по простому запросу без уточнений модель будет делать сама все тесты, проверки, саморевью и так далее.

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

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

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

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

Пффф...ГигаКод ёпта) пошутил 😆 он ваще впринципе никому не поможет в том виде, в котором я его видел.

Ну я пишу по для микроконтроллеров и нормально все работает..

Gemini в режиме чата часто свистит флягой. Недавно фактически с нуля переписывал проект с легаси андроида на api 29, там таких прыжков в ширину насмотрелся, когда "давай сделаем так, ой, так не работает на этом апи, давай эдак, будет идеально, ой, вы правы, эдак работает только в референсном пикселе, а вендоры это как угодно могут навертеть, поэтому надо костылей насыпать" - и так по кругу.

Клод 5.5 на легаси проекте java + postgres очень любит пихать cte по поводу и без, а с предложения делать delete+insert вместо хотя бы upsert я чаечкой орнул. В среднем с третьего пинка код в норму приходит.

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

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

Одно дело рутина. И я не про классы. Это совсем банальная рутина, а-ля, обработай этот массив по такому-то шаблону, или преврати это описанное словами разветвление, которое я уже продумал и подробно описал, в switch. И то, я еще десять раз перепроверю.

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

Хочешь конкретный пример?
Обработка отчета по продажам по API интернет-магазина. Там со стороны магазина был баг (или по еще какой-то причине, я хз), и в некоторых чеках иногда не указывался сам номер чека. Такую запись нужно обрабатывать по-особому. Делать проверку на то, что все пришедшие свойства не пустые нельзя, потому что некоторые не обязательные и их можно опустить. Об этом вайб-кодер или нейронка догадались, но что есть ключевые значения, которые, если они пустые, нужно обрабатывать особым образом - не догадались. Вместо этого вся запись откланялась как некорректная. А то, что потом баланс не совпадает с продажами, так на это же похуй. Что там писал в своем запросе вайб-кодер мне плевать, потому что проверять весь путь от чтения ответа с сервера до записи в БД пришлось именно мне. И, скажу, читать этот код было малоприятно.

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

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

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

Но это не значит, что это единственная сфера применения. ПО в сфере услуг, коего тоже огромное количество, никакой математики ее требует. А это значит, что математические знания никак не говорят о возможностях программиста. Это дополнительные знагия для определённых сфер и не более того.

Хуясе)

Если так мыслить то и музыка это математика и стихотворения тоже. Ебать всё, что имеет количественное выражение- даже мысли- уже математика. Только это всё ебаная сова на глобусе.