Вайбкодинг

[amarao]

Я посмотрел как коллега пытается это делать. Wow, там серьёзный скилл нужен. Человек не понимает что ожидать от LLM, пишет странное, хочет слишком много за раз, не готов подстраиваться под ограничения и допиливать напильником.

Выглядит так, что скиллы для vibe'а ровно так же надо нарабатывать, как и все остальные.

Comments

[kondybas]

Я сильно сомневаюсь, что возможно качественно вайбить, не зная язіка. Слепить без знания язіка прототип, массо-габаритній функциональній макет системі - возможно. Но добиться єффективности/надежности/сопровождабельности продукта... крайне маловероятно.

[cali4nickation]

А "єффективности/надежности/сопровождабельности" точно еще кому-нибудь нужны в мире полном даже не golang а python и nodejs backend? В общем то и доминирование условного AWS уже сильно понизило планку необходимого опыта и его ценности.

[kondybas]

Возможно, у меня профдеформация. Меня, как DBA-контрактора, зовут на проекті, где случились проблемі с єффективностью/надежностью/сопровождабельностью БД.

Ясное дело, віборка нерепрезентативна, потому что нужно сочетание сразу двух условий. Во-первіх, проект должен біть достаточно крупнім, чтоб архитектурніе ошибки уже нельзя біло решить єкстенсивнім разбуханием хардвера, а во-вторіх - біть в фазе активного роста и привлечения бабла, чтобі проблемі є/н/с прямо мапились на проблемі маркетинговіе -> финансовіе.

Из последнего: одинокая промежуточная реляционная БД, куда агрегируются данніе с монго-шардов, а оттуда уже разносятся по фронтовой ферме. Уже 64 ядра дали, и ОЗУ 256ГБ, и десятій рейд из нвме - а больше 400 запросов в секунду хост не вівозит. А после оптимизации - вівозит 17-20kqps. Решить проблему с єффективностью заметно дешевле, чем заводить стойло из 40 доп.хостов.

[cali4nickation]

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

С другой почти всегда в таком случае видишь в наши дни Databricks DynamoDB и только изредка AWS Aurora в которой кажется далеко не все настройки доступны для подкручивания. Что как раз я и пытался сказать изначально.

[anonim_legion]

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

Вообще хорошо бы этот самый SQL засунуть туда же, где сейчас находится ассемблер, и сделать новый язык для БД, с нормальными абстракциями. Не ОРМ, разумеется.

[cali4nickation]

Я недостаточно причастен чтобы самому таким заниматься всерьез (не в последнюю очередь потому что уже давно не работал в местах где это возможно или необходимо) но достаточно чтобы понимать саму деятельность и требуемую квалификацию ;)

А движение продвигающее эту идею назовем скажем noSQL :))) Ведь если серьезно то все мы кто пронаблюдал это с начала до конца получили богатую пищу для размышлений. Сила любого DSL в документации и распространенности так что лучше уж SQL. А в смысле ORM-подобного разумнее jooq никогда не видел. Apache Spark идеальный пример как сделать API который вроде SQL но вообще то Scala с легкими unit tests и полной type safety.

Я бы сказал что движуха вокруг Apache Arrow и в частности gRPC протокол для транспорта от сервера самое интересное/многообещающее в этом мире сейчас.

[anonim_legion]

У меня есть ощущение, что все русские* более-менее соображающие в этой теме, и при этом пишущие в блогах, давным-давно взлетели куда-то в недоступные выси, на должности принципалов, CTO или на пенсию, и витают там, курлыкают, вспоминая минувшие дни**, и изредка поглядывают (поплёвывают) вниз***, но чаще смотрят на свой инвестиционный портфель. А там внизу, в многочисленных биллингах и прочих системах с 30летней историей и десятками мегабайт кода, копаются либо индусы, либо новое поколение - вроде меня, либо люди, которым господь языка не дал, поэтому они только работают, но не говорят и не пишут.

Поэтому беседы получаются не очень осмысленными.

В движении NoSQL, к которому сказанное мной отношения не имеет, я говорил об абстракции НАД SQL, нет ничего нового. Когда-то давно были dBase/Paradox/whatever с ручным подключением и обходом индексов, SQL там не было, а базы были самая что ни есть реляционные. Потом примерно в 2006 году момент выяснилось, что людям иногда надо в таблицу с одним индексом писать, из таблицы с одним индексом читать, и делать это нужно за предсказуемое время. Поскольку в реляционных БД зачем-то по сей день не существует возможности написать план запроса вручную**** (хотя в DB2 это есть, потому что в IBM всё же когда-то работали умные люди), появилась и получила популярность MongoDB.

Я не видел ни одного биллинга или системы, по сути являющейся биллингом/CRM, написанной на Apache Spark или Arrow. Судя по описанию, это очередная высокоскоростная штука, созданная для отслеживания миллионов случайных нажатий на экран телефона пользователями, чтобы в самое захватанное место подсунуть баннер, списать за клик деньги с рекламодателя, как за настоящий и выплатить наконец ипотеку. Как, знаете, в ютубе при постановке видео на паузу в приложении на андроиде справа появляется баннер размером с пол-видео, как раз там, где человек касается пальцем кнопки паузы.

Все биллингоподобные системы, о которых говорю я, написаны на километрах PL/SQL в Оракле и T-SQL в MS SQL, и именно они будут списывать с вас деньги по ошибке, а вы потом будете доказывать, что вы не верблюд и деньги списаны неправильно. Хотя возможны и более интересные ошибки, например медицинские.

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

А люди, с хранимками работающие, пишут в шапке процедуры, в многострочных комментариях, какие были сделаны изменения. Дата, описание, автор. Git у них есть, да. Но как-то он им побоку. Наверное потому, что этот git почему-то по сей день не встроен в SQL Server Management Studio, впрочем я уверен, что в pgAdmin, переписанном на Electron c wxWidgets, чтобы тормозило сильнее, тоже ничего такого не сделано. Нету в базах и средств отслеживания истории изменений объектов, тех же хранимок, и поэтому чтобы сравнить 2500 хранимок в файлах в каталоге и 2500 их же в базе, нужно прочитать все их из базы. Почему в БД не добавляют таких средств? Вроде как одним из основных и знаменитых пользователей самой большой в мире базы на Постгресе в мире является некая обсерватория. Там работают жутко талантливые люди, с головой большой, как у лошади. У них туда всё помещается, поэтому что им не нужно - то и другим не нужно.

Когда-нибудь эта замечательная индустрия достигнет предела: простые в общем задачи, обеспечиваемые сложным кодом, станет просто невозможно изменить для реализации новых требований, например законодательных. Потому что километры кода на этом реляционном ассемблере будут требовать гениальных людей для понимания (и нет, ИИ тут не поможет), а таковых людей попросту не найдётся.


*рождённые на Родине, той самой, воспетой Пелевиным и Сорокиным, и говорящие на русском от рождения
**см. х/ф "Зелёный слоник": "...хочешь, постою как цапля?... я когда служил нормально - отжимался 20 раз"
***См. https://web.archive.org/web/20191113095925/https://gans-spb.livejournal.com/20663.html , читать с фрагмента "фотку "Я и мой дом и моя тойота, а вы все поцы"
***я говорю не о хинтах