Кажется, мы ищем форму

Привет, Хабр :3, что-то давно я не писал свое графоманство, что читается хуже нейрослопа, да и знаки препинания по паузам в уме моём, а еще я "–" умею ставить ввиду академической проф-деформации.

Итак, заваривайте чай, напрягаем мозг, сегодня поговорим в целом о программировании и его проблемах, а также экспериментах. Плана статьи не будет, до конца дочитают сильнейшие (изи байт). Ехала!

Проблема AI и LLM

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

Давайте договоримся, хотя бы на уровне этого графоманского текста, никаких искусственных интеллектов, LLM - это Т9 с SSD-шником, конец. Поэтому если далее упоминается в тексте хоть что-то связанное с ИИ либо лулз, либо речь о реальном ИИ. П-нятненько?

Мантра, LLM и их токены - это новое электричество и Интернет, я верю, что в ближайшем будущем банки и провайдеры сотовой связи, и не только сотовой, будут внедрять токены прямо в вашу коммуналку, домофоны с LLM-чекером, камеры с чекером, что Вы, действительно, вызывали курьера и что это курьер, а также прочая лабуба вокруг того, что в вашей подписке от банка появится N-ое кол-во токенов, которые уже другие сервисы будут принимать в качестве оплаты за сервис – вот это таргет, это да, это прикольно. Человек тут нужен чтобы это электричество не шарахнуло. Недавно читал в Иннополисе доклад на эту тему с тем же нарративом, наверное это и есть причина создания этого материала (или то, что на pos1 слишком долго матч в д2 ищется IDK)

В общем, рынок сейчас состоит из нескольких частей:

• Компании, что заставляют разрабов использовать LLM из-за неведения в рамках "ну это же производительно"

• Компании, где разрабы симулируют работу с LLM

• Компании, где разрабы втихую юзают LLM симулируя работу

• Компании, где строят harness в рамках своего домена

• Компании, которые сидят и дрожат, что LLM их заменит

• Компании, которые делают вид, что они и без LLM справятся

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

пояснения буду писать в таком виде, так как это отход от моего основного нарратива, но надо же объяснить, правда?

крч, девелопер - это как строительная к(о|а)мпания, студентам в ИГХТУ, кому читаю функциональное программирование и фундаментальную информатику и тестирование ПО, часто говорю, ребятки, современная разработка ПО и её SDLC (жизненный цикл разработки ПО от software development lifecycle, учите термины) это решение проблем бизнеса. Вы не приходите туда программироватъ, вы смотрите "ага, вот ресторан кафе, один афисант не может засервить все столы, а пациенты пришли и ноют мол че как долго, все простаивает", а дальше ваш внутренний оптимизатор говорит "давайте вам засунем айко, кнопки для вызова, QR коды для оплаты и вообще сделаем максимально автономный заказ, а член бригады ресторана будет уже не просто принеси-подай, а будет, прямо, консультировать что вкусно, что грустно, что вселенная сгорит рано или поздно неизбежно ведь теория хаоса, а там и тепловая смерть.

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

Так вот software developer заинтересован лутать бабки, просто индивидуалистический капитализм навязал ему прямую ассоциацию рабочей деятельности с его личностью, как итог ему просто жизненно необходимо не просто писать код, а быть связанным с определенным коммьюнити, если он жабаскриптизёр, то Дан создал сверхартефакт, если он шарпист, то он Мартином обмазывается с ног до головы, если он еще и в гошку ушёл, то все Си без памяти и натягивает там свой DDD. Это не программирование, это разработка ПО. Сорри.

Итак, harness. Это такая штука, чтобы исключить "man in the loop" (человек в цикле поставки чего-либо), следовательно это построение инфраструктуры вокруг LLM: промпты, mcp, skill, agents.md, policies, spec-driven development, любой драндулет, который даёт вашему агенту возможность работать максимально долго автономно. Часть компаний, кто давно устаканило свой стек и там разработчики это json-о-укладчики либо кнопко-красильщики с точки зрения написания кода, где увели в CMS или в свой самописный devkit, больше фокусится на feature development, попытке понять что хочет стейкхолдер, попытке сделать бизнес-пизнес ещё щуточку лучше.

Проблема первая

Ваши LLM не готовы к harness-у. Не тот подход, потому что harness вокруг вашего кода, например, это AWS, у которого уже всё есть и dynamodb и lambdas и nodejs маленькие alpine-ноды, а вам остается писать только business layer. Почему так? Нарратив этот транслировал на одном из стримов, один из видосов тут, либо левая палочка твикс, либо правая.

Суть такова, что лестница следующая: chat -> api -> agent -> cluster -> эшелоны. То есть, мы хотим сделать так, чтобы harness имитировал поведение сначала от исполнителя-аутсорсера до симуляции поведения организации-компании, с тимлидами агентов, транслирующие OKR-цели и key result-ы, и прочее. Только вот подход нужен другой. Субагентам не нужно общаться текстом, как они общаются с человеком. Форма не та. И про форму мы периодически тут будем рассуждать. А значит, все попытки засунуть его в симуляцию разработчика - взять таск с доски, провести код ревью, задеплоить и прочее - это не тот harness, это просто симуляция. Нам нужна среда, максимально автономная, без потребности хостить и обслуживать yaml-файлы и сервера и терраформы и прочее. Хороший пример - лет 6 назад были application в облаках, от тебя требовалось корректно настроить чтение stdin и знать куда писать в stdout, сам сталкивался с сетапом nodejs приложений на базе digital ocean, удобно, но дорого. Сейчас, условные gcp предлагают такой опыт, когда у тебя и шаблон github action есть и всё, что делает девелопер после пуша кода в мастер просто тыкает в GUI на портале гуглов, а значит уже лишен нагрузки в лице ops-а, только вот перегруз их интерфейса, где тысячи кнопок это та боль, которую тот же aws так и не прорешал, что приводит к тому, что поддерживать конфигурацию в одном файле проще чем разорваться в их интерфейсах.

Проблема вторая

Разработчики не промптят LLM, они не понимают нахрена это надо, зачем мне самому писать промпт если я могу попросить LLM запромптить другую LLM. Но вы симулируете работу, а не делаете её. Мне как тимлиду всегда нравится фреймить инженеров в команде, что задачу нужно оценивать до уровня 3 часов. Если вы понимаете что примерно чистового времени ушло 3 часа, то можно дальше не гранулировать и наоборот, если задача занимает несколько дней, то чел уйдёт в фрустрацию из-за гипер-свободы и прочее сами тут придумайте что вставить.

Так вот разработка с LLM выглядит также, ваши задачи, что вы хотите сделать с их помощью должны помещаться в условное трехчасовое окно. Опять эта чертова декомпозиция. Но в этом и прикол. За день можно сделать 1-2 задачи такого уровня и сильно не переживать что ты не долларовый миллиардер и держать свою кукуху в порядке. Потому что в таком уровне неопределенности вы понимаете когда произойдет переход из точки А в точку Б. Да, это не та автономность, но все как теперь в моем самом любимом видосе на YT: https://www.youtube.com/shorts/pU4PZ3hrfhg

Почему так? Потому что вероятно вы не любите свою работу ну или конкретных людей (а вообще надо улучшать пространство и давать ОС людям, они может даже не знают, что они что-то делают не так, некоторых надо гнать, но это для другого пространства разговор), либо свято верите, что личный сетап вашего vim-а и клавы на 60 клавиш это ваша айдентика, но по сути это капиталистический скам, вам не нравится задача, которую вы делаете, а следовательно если она еще и большая ну его нахрен, отдам все на откуп LLM, если она не справится или сэкономит мне время, значит, я смогу больше смотреть тиктоков и жрать читосов. Сорри за скрытую агрессию, но так и есть.

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

Иногда в вашей деятельности и причине полностью сделать все автономно с LLM прячется пара тейков (из множества других):

• а прикинь LLM сгенерит, что надо, значит я нашел золотую жилу и буду хоть на 100 работах работать

• или того хуже, вот если она с этим справится, значит я как специалист уже не нужен и надо срочно научиться копать грядки и делать отмостки

• или того хуже, мне что нужно будет общаться с людьми пока она генерится? а как же мой вакуум, я ваще-та интроверт!!1 (только у Юнга пограничных случаев было около 10% что ли, в остальном бОльшая часть людей по-Юнгу это нестабильные эмоциональные качели)

• или того хуже, LLM не справляется с такой тупой задачей, значит есть у мну комплекс превосходства

А если вашей интересной задачей будет спроектировать промпт? А зачем его проектировать? Мне лень тут расписывать все про промптинг, я ради этого на конференции езжу и рассказываю, чтобы потом была запись на ютубах этих ваших, или стримлю, чтобы скинул и не повторялся, но примерно объясню следующее:

ЕСЛИ ЗАДАЧА СВОДИТСЯ К ТЕКСТУ, ТО ВОЗМОЖНО ЕЁ НАДО ОТДАТЬ LLM.

Например, если Вы можете привести эксель или pdf через markitdown к тексту, супер, отдайте LLM. Если Вы можете аудио превратить в декартовом пространстве в функцию и посмотреть, где там у нее координаты в текст, супер, отдайте LLM. Если Вы картинку можете разобрать в текст, супер, отдайте LLM. Запись аудиоразговора и прочее-прочее. Тут вы сами знаете и лучше меня.

Есть по сути четыре ключевых направления промптинга, этот материал я частично читаю на лекциях и веду лабы в ИТМО на курсе по ИИ как раз:

• линейный промптинг (из А в Б) - zero shot, a few shot

• с промежуточными вычислениями (шаг за шагом, даём моделям опции не отдавать ответ сразу) - chain of X (chain of verification, chain of thoughts)

• ролевой - говорим модельке, что она senior devops yaml developer (ReAct, RCTF и tree of thoughts)

• накопительный - RAG, SDD и прочие подходы

Давайте сначала попробуем заземлиться и понять когда что применять, чем чаще ваш агент зависит от внешних знаний или адаптации модели тем сложнее будет промптинг. Конец. Если задача очень простая - чёрт с ним, пишите few shot (zero shot промпт "сделай хорошо", но с примерами), а если комплексная, то добро пожаловать в advanced prompting.

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

Марат, а зачем мне в RCTF-промпт писать вот эту "ты senior yaml engineer"? А всё просто, напишу по пунктам, чтобы было понятно

• Есть Вася Пупкин, он много контрибьютил и в закрытые репозитории и в публичные и вообще написал в профиле что он самый крутой девопсер

• Вася Пупкин имеет pulse по контрибьютам в yaml файлы

• Крупная компания коммуниздит код из github/gitlab и прочие гит/svn штуки

• Крупная компания тренирует на полученных векторизированных данных свои LLM

Угадайте в активных весах что активируется конкретно когда вы напишите "ты Вася" или "ты senior yaml develooper"? А если нет такого слова пойдет синонимами искать близкие по токенам цифровые значения. Магии тут нет. Писать что ты математик из будущего который решил p=np не получится, данных нет. LLM - это Т9 с SSD-шником. Даже хуже, это цепь Маркова с всякими эвристиками типа энкодеров, декодеров, ранкеров и прочей лабубы КВЧГ как говорится.

Какой способ разработки с LLM сейчас наилучший для бизнеса и почему?

Обратите внимание - для бизнеса, не для кода! А то будете потом умничать, а вы любите.

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

Тут на сцену выходит SDD, мне он нравится как идея.

Идея простая, разработчик - это пилот 4/5 команд в агентском окне. Сидишь такой и дёргаешь

• Сначала пишешь /specify хочу форму авторизационную сделать

• Потом ревьювишь доку и пишешь /plan и получаешь пошаговый план

• Потом ревьювишь план и пишешь /tasks и получаешь чеклист из задач, что можно параллелить, а что нельзя

• Потом дергаешь либо /analyze чтобы посмотреть все ли учтено, либо /implement

И дальше ожидаете структуру типа такой

• specs/001-форма-авторизации/

  • plan.md

  • tasks.md

  • spec.md

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

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

Проблема формы и куда идёт программирование как таковое

И вот мы здесь, что-то ты нам навещал коротких тезисов под пятницу и выходные, а что за форма и о чем речь?

Я упоролся в разработке и осознал для себя следующее - если моя работа тимлида-играющего тренера-программиста это общаться в чате с людьми и беречь их well-being, но быть требовательным и достигать с командой поставленных целей, но теперь еще и писать писанину в агентское окно для LLM, то я не хочу чтобы источников правды было четыре:

• мой вижн

• документация от discovery

• код

• мой промпт и нейрослоп от агента

Как же это можно подружить и можно ли?

этот материал и тезисы я буду рассказывать на holys.js на следующей неделе, поэтому когда дропнут записи через полгода, а может и раньше, то сможете по-другому посмотреть на текст этой публикации, но так как меня спрашивают и студенты и коллеги, я решил начать шарить эксперименты уже сейчас

А что если спецификация станет исполняемым кодом?

Первое, что нужно сделать - это исключить любую нелогичность из ваших промптов и сообщений. Тогда ваша спецификация станет логична, есть пересечение между математикой, физикой нашей вселенной и человеческой логики (соррян за диаграмму из Gemini, но это лучше чем я нарисую в excalidraw, а судя по стримам рисую я там крайне монструозно)

Второе, что нужно сделать - это сделать так, чтобы спецификация которую вы пишите не была маппером, например вот вам cucumber.js + gherkin.js

В-третьих, вам нужно мочь доказывать код, формальная верификация, мне нравится этот слайд, который ниже, потому что код для ракет, хирургии и спутников писать на c#, петухонах, жабах и жабастрипкризёрах - не то.

И получается, что ваша спецификация должен проходить минимум следующие стадии формальной-верификации:

• завершаемость функций - доказать, что код гарантированно закончится (это не совсем обычный тезис Тьюринга, а скорее сложный тезис Тьюринга-Черча)

• выполнение предусловий для функции

• выполнение постусловий для функций

• дефункционализация как основа проверок (почитать про LCF можно тут https://www.pls-lab.org/LCF_architecture)

• доказывание "на сетке", если написать, что функция вернет число больше нуля, значит это весь домен всех чисел в принципе, не просто IEEE-754, а всех точных целых

• доказывание через структурное убывание типов

• доказывание без аксиоматики - это самая сложная часть, в бизнесе фичи спецификаций являются аксиомами, но движок не должен заниматься тем, что он спеку проверит и все, он должен мочь ее выполнить, да надо давать ввод аксиом для математиков-логиков, но программисту достаточно будет верить компилятору, а-ля Lean, только вам придется написать к своему языку спецификаций не обычный DSL, а полноценный GPL, желательно чистый функциональный со строгой статической системой типов, без дефолтной рекурсии, переменных и прочей шляпы, а еще к нему чекер на C без зависимостей тысяч на 7 строк, чтобы прочитать можно было человеку, а еще к нему леммы на Lean, чтобы тоже была какая никакая гарантия

И разумеется там еще пачка пунктов будет, комментаторы сами порадуют вас.

В-четвертых, вам нельзя просто создавать отдельный GPL с компилятором, придется выводить программы в ключевые языки, например Go, C#, Java, JS/TS, Rust, C, C++ и так далее, например через режим интерпретации. Это должно работать так, чтобы постепенно вычленять всю бизнес-логику на такой язык, а остальные GPL были в роли оснастки, harness над спекой так сказать. Например бизнес-логика на Dafny для расчета зарплаты, на JS адаптер, на React отрисовка интерфейса. Если задача детерминированная, значит сразу пишете ее на языке спеки.

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

В-пятых, язык должен быть мульти-поверхностным, хоть на эсперанто чтобы писать можно было и прочитать имея базовое образование computer science ну или LLM запретить уйти от написания недоказуемого кода

И тогда ваши LLM будут использовать жесткую форму, которую вы будете писать на неформальном русском или китайском языке в окне чата, а она будет приводить это к жесткой структуре на таком языке GPL-спецификации, и не может породить баг, потому что ядро просто плюнет в лицо агенту и скажет: "недоказанный код, программировай занава!!11"

Только вот беда, я четвертый месяц разрабатываю (разумеется с агентами, но вычитываю и рефакторю time by time) такой язык. Примерно 3-4 подписки Claude Fable нон-стопом каждый день 24х7 4-ый месяц. Сейчас уже просто рефакторинг, удаление нейрослопов где они остались еще, строгое выравнивание наждачкой так сказать. Но уже работает, спросите вашего чатгпт и он вам сам все объяснит, что это такое и зачем. На данный момент это чистый функциональный язык программирования со строгой статической типизацией, компилятор написан на flang, умеет доказывать завершаемость функций, предусловия, постусловия, позволяет писать кванторы и логику, математику и прочие монструозные эксперименты.

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

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

Создавайте формы, тогда и программы станут надежнее, а я пошел дальше экспериментировать и создавать свой flang https://github.com/digitable-lol/flang

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