"Drinking the Kool-Aid" (c)

Обращаю внимание, что пост помечен как "юмор"

В далёкие годы, когда «хайп» назывался даже не «ажиотажем», а просто «угаром», оптимистично настроенные авторы вписали вот такой выразительный фрагмент в свою апокалиптическую повесть о людях:

— ...Например, Массачусетская машина. — Альпа покивал. Горбовский обратился к нему. — Вы, конечно, должны помнить. Сейчас о ней вспоминают редко. Угар кибернетики прошел.
— Ничего не могу вспомнить о Массачусетской машине, — сказал Банин. — Ну, ну?
— Знаете, это древнее опасение: машина стала умнее человека и подмяла его под себя… Полсотни лет назад в Массачусетсе запустили самое сложное кибернетическое устройство, когда-либо существовавшее. С каким-то там феноменальным быстродействием, необозримой памятью и все такое… И проработала эта машина ровно четыре минуты. Ее выключили, зацементировали все входы и выходы, отвели от нее энергию, заминировали и обнесли колючей проволокой. Самой настоящей ржавой колючей проволокой — хотите верьте, хотите нет.
— А в чем, собственно, дело? — спросил Банин.
— Она начала вестисебя, — сказал Горбовский.
— Не понимаю.
— И я не понимаю, но ее едва успели выключить.
— А кто-нибудь понимает?
— Я говорил с одним из ее создателей. Он взял меня за плечо, посмотрел мне в глаза и произнес только: «Леонид, это было страшно».
— Вот это здорово, — сказал Ганс.
— А, — сказал Банин. — Чушь. Это меня не интересует.
— А меня интересует, — сказал Горбовский. — Ведь ее могут включить снова. Правда, она под запретом Совета, но почему бы не снять запрет?

Стругацкие, "Далекая Радуга" (1962-64)

К счастью, или наоборот, реальность оказывается несколько иной.

И содержание новостных лент гораздо ближе к описанному К.И. Чуковским в стихотворении «Телефон»

“И такая дребедень
Целый день:
Динь-ди-лень,
Динь-ди-лень,
Динь-ди-лень!
То тюлень позвонит, то олень…”

Меж тем в замке у шефа

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

Про вайб и прочих ИИ агентов в ретроспективе "лихих 90-х"

90-е годы в новой демократической России, двигавшейся в правильном направлении неправильными путями, были эпохой расцвета местных и суверенных ERP-систем, многие из которых живы до сих пор.

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

Будучи разработчиком одной из небрендовых ERP-систем, приходилось участвовать в предпродажных сессиях. Ярким воспоминанием остались контакты с "девопсом" потенциальных клиентов. Никаких "девопсов", конечно, тогда не было: инфраструктурой или, как иногда говорят, "ландшафтом" занимались системные администраторы, инженеры и ДБА.

Приходишь на презентацию, и видишь суровые скептические лица сисадминов, которые, не скрывая чувств, заявляют нечто вроде: "Жаль, времени нет, а то мы бы сами на Delphi за выходные написали бы, то что вы нам за деньги предлагаете..."

Когда сейчас натыкаешься на очередную "джинсу" по вайбкодингу и прочему агентскому клепанию "типа софта", нередко выясняется, что авторы - спецы в инфраструктуре. И тогда сразу становится ясен смысл написанного: "Да мы сами на выходных на Delphi сделаем, то что вы нам за немереные деньги пытаетесь впаривать".

Откровения евангелистов БЯМ (LLM) для целей софтостроения генерируются публикуются с высокой скоростью. Не только на хабре, LinkedIn заполнен ими "под завязку". Прочитывать всё невозможно, да и не нужно, но некоторый тренд в изложении присутствует.

К сожалению, авторы много пишут о процессе, забывая собственно цели. Упоминание о функциональной сложности программы, как правило, отсутствует. Длина описаний процесса может создать ложное впечатление о развесистой функциональности, хотя большинство примеров находятся на уровне "записная книжка". В этом нет ничего плохого, просто не забываем, что 30 лет назад RAD типа Delphi умели создавать такие же "книжки" без написания кода вообще: достаточно было "накидать" компонентов на форму, настроить, связать их, и нажать "Run".

Накидали, и что дальше?

За словами "писать на близком к естественному языку", скрывается постепенное создание быстро растущего "промпта" - детальной спецификации, местами - псевдокода. Как следствие, необходимо иметь версии таких "исходников", как и раньше для кода (об этом практически не пишут). Для сторонних пакетов, API служб и прочих зависимостей не забываем указывать версии. По сравнению с таким "псевдокодом" техзадание может показаться увлекательной беллетристикой. Речь идет по сути о конечных спецификациях, ведь программирование - не столько кодирование (от силы 20% времени), сколько детальное проектирование и стабилизация.

Размер спецификаций псевдокода вкупе с описаниями контекста среды могут превзойти собственно размеры генерируемого кода, написанного программистом на формальном ЯВУ. Спецификации придется так же хранить в Git, и нервно просматривать, что же изменилось в сценариях, почему, ***, вместо слова "опять" кто-то написал "снова".

Для детерминированности процесса желательно, чтобы моделька была в том же состоянии, что и на предыдущем этапе генерации, но для внешних БЯМ-сервисов это недостижимо. Напомню, что компиляторы и классические генераторы кода (CASE, MDD) - детерминированные.

На первый план выходят тесты, их нужно писать "больше и лучше", потому что под капотом теперь только "черный ящик", "белого" больше нет. Тесты нужно постоянно обновлять в зависимости от объема изменений. Если ваши новые спецификации меняют 20% существующей кодовой базы, то тестов придется менять вдвое больше, принимая 2:1 за стандартное соотношение тестов к коду. Для языков без статической типизации тестирование еще более усложняется.

В реальных проектах написание сотен строк в день - это режим стартапа, причем на "нулевом цикле". Достаточно быстро программист приходит к естественной норме десятков строк в день, остальное время занимает понимание текущего потока проблем, поиск ошибок, интеграция и стабилизация. Хороший программист минимизирует объем порождаемого кода. Нужно ли включать БЯМ для написания 50 строк в день - вопрос.

В процессе не предусмотрена роль юниоров. Перспектива - "уйти со сцены", не воспитав смены, достаточно сомнительная для бизнеса и весьма печальная в личном плане.

Напоследок накину немного философского. Евангелисты любят упоминать, что человеческий мозг и БЯМы работают на одних и тех же принципах. Часто выясняется, что курса "Аналоговые ЭВМ" на их потоке уже не было, что несколько удручает. Еще более простой вопрос на примере несуществующей (пока?) телепортации: "Человек на входе телепортера и на выходе - это одна и та же личность?"