Лаборатория Математики и Программирования Сергея Бобровского

Решил расширить свои лингвистические/блогерские изыскания немного в сторону художественную. Если программирование пока ещё сопротивляется пришествию AI, то вот художественную литературу пора уже уничтожать более чем полностью :) Ну, и там и там мэйнстрим/попсу/хипстерство имею в виду конечно.

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

И у кода, и у худ.текста очень много общего, причем как in small, так и in large. Я за свою жизнь прочитал немалые тысячи книг (и продолжаю активно), из них немало по лингвистике и литературоведению (у нас в редакции в 90-е работали суровые литературные редакторы советской школы), и на лит.курсах занимался, и вот теперь хочу в заключение немного поэкспериментировать в смежной сфере.

Книги пишутся обычно по двум схемам.

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

Писательская (это удел чистых талантов, но при этом здесь также довольно велик процент сумасшедших :). Автор задумывает некоторую идею, делает конечно какие-то очень схематические наброски, но пишет текст в некотором трансе: на сознательном уровне он реально не знает, как будут вести себя его персонажи! он их просто вводит в контекст и конфликты, задаёт общее направление, но последующий сюжет развивается "естественно" как бы самими персонажами (в подсознании автора).
Вы не поверите, но 80% великих книг были написано именно так. Ну максимум 20% "инженерии".

=

И так как я совершенно бесталанный в художественном плане, то хочу довести до идеала инженерный подход. Ведь "проектирование" книги in large -- это по сути процесс, изоморфный проектированию системы, разве что менее формальный. А нейронки сегодня пишут код художественный текст вот точно уже лучше 98% не только литературных негров, но профессиональных авторов — на уровне хорошего PhD.

То есть и тут на первый план, как и в IT, выходят скиллы "техлида": качественные замысел, сюжет, драматургия, умение зацепить/увлечь, примерно как и в геймдеве кстати. Ну и стиль/in small самого текста конечно важен (как картинка в игре).

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

Продолжаю работу с ментатами (и ментатками 🌷) 🤓

5 задач ужасающей сложности оказались правда ужасающими сложными для меня. С такой сложной схемой БД, где более 50 таблиц, мне работать не приходилось. И задачи правда оказались невероятно сложными с требованием сложной аналитики. Обычно в работе сталкиваюсь с БД до 10-15 таблиц, а то и меньше.
Очень сложно (практически невозможно) выполнять такую работу с незнакомыми для тебя сущностями. Я привык к продажам, остаткам, логистике, БД различных пользовательских сервисов. С играми я никогда не работал. И продумывать аналитику влияния погоды на атаки или влияние лунной фазы на что-то невероятно сложно. И все это без боевых данных...

Получили трёхкратную разницу. Я не ожидал, что hibernate будет тащить так много лишних данных. В изначальном варианте с orm было очень много джоинов. Кажется это связано с тем, что сущности тесно связаны друг с другом и такая длинная цепочка джоинов является попыткой распутать клубок связей. Однако данные, которые достаются с помощью такого объёмного запроса нам не нужны и эти длинные запросы избыточны...

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

Для себя я сформулировал простой принцип, который хочу применять дальше: перед тем как писать или менять код, стоит задать себе вопросы «зачем это существует?», «в каком месте системы это используется?» и «что нельзя делать с этим кодом». Если ответы не очевидны из сигнатур и структуры — они должны быть записаны в комментариях...

Тесты не спасают от всех багов — только от тех, на которые ты догадался написать проверку.
Например, что должен вернуть метод CalculateAverage для массива { 1, 2 } — 1 или 1.5? Если такой тест не написан,
баг может жить в коде годами, пока кто-нибудь не столкнётся с ним в продакшене...

Если честно, то я не задумывался о таких мелочах. Теперь понимаю, насколько это было недальновидно. Особенно мне казалось использование словаря в подобных случаях избыточным. Теперь вижу, что result['fresh_messages'] намного понятнее, чем fresh, old = some_function(). Не нужно держать в голове порядок возвращаемых элементов.
На будущее:
Нужно регулярно задавать себе вопрос: "А не скрыта ли здесь логическая связь?"
Чаще использовать словарь вместо кортежа...

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

Затем я попытался достичь 10k RPS создав 10 тысяч пользователей(хотя для такого rps это, как будто, много). Но прогон завершился с ошибками и я даже не получил отчёт. Ещё впервые за долгое время услышал как мак гудит вентиляторами :)

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

Чувствую, что надо переходить к AI-темкам, так как бизнес хочет вокруг AI строить все решения.
...В этом проекте я вообще максимально долго пытался сохранить монолит, но так как приходит вторая большая команда, то придется делить его как минимум на 2 (микро)сервиса, чтобы команды не толкались в одной кодовой базе...

Ну, "поделить монолит на несколько частей и будет проще автономным командам", это уже многократно проверенная иллюзия. Сейчас весь FAANG наоборот уходит в монолиты, на днях как раз несколько постов на эту тему выложу. Кодовую базу надо делить не на микросервисы (это техническое решение), а на правильную доменную логику, из которой архитектура будет следовать уже естественно и легко.
Как? Вот уже прям в марте будет вам гайд "Функциональные Архитектуры" 🔥

Фигня этот ваш жпт5.4.

Попросил его написать скрипт на питоне где-то на 500 строк, причём вся логика линейная, просто надо условно говоря давать агентам те или иные инструкции в зависимости от десятка счётчиков. Так он начал концептуально тупить уже на первых 50 строках, кое-как вроде что-то собрал, где-то час я на общение с ним потратил, а как стал тестировать, и оказалось, что он так всё напутал со счётчиками, что надо вообще всё переделывать заново с нуля, а если делать точечные фиксы, то он сразу превращает всё в little ball of mud. А внимательный джун сделал бы, ну пусть за 4 часа, но как минимум чтобы всё работало по тикету.

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

Когда делаешь презентацию своего проекта перед солидным заказчиком, и из него непосредственно на ходу начинают вываливаться куски твоего движка :)
Как давеча из "Мерседеса" Кими.

У нас уже и были, и остаются огромные проблемы с объёмом легаси-кода, который существовал, когда его писали люди. Почему мы думаем, что ускорение этого процесса будет улучшением?? )))
Откуда мы знаем, что терабайты вайб-кода вообще работают?

Наиболее распространённый ответ: я просмотрел код, прогнал тесты, и все в порядке.

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

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

(В целом странно конечно, что умение хорошо просматривать код теперь гораздо более ценно, чем умение хорошо писать код.)

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

Вместо того, чтобы самому/агентами писать код в прод, и затем просить нейронку покрыть это всё тестами, почему бы не написать сперва тесты, и только потом не попросить агентов реализовать их?

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

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

Ну ладно мэйнстриновские проекты, фиг с ними, с интересами пользователей в них никогда не считались, и десятилетиями сбрасывали на юзеров все проблемы с выявлением багов в духе "раннего доступа".

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

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

Красивое: GlimpseOfLean : an introduction to theorem proving in Lean for the impatient.

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

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

(как например Калифорнийский университет Беркли, который на днях (следом за Йелем) признали нежелательной экстремистской организацией, и даже просто за ссылки на его научные труды - или за использование FreeBSD :) - можно легко получить штраф, если не что похуже -- от низовых исполнителей для лёгкой статистики, разбираться никто не будет),

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

p.s. Забыл, в их последнем деплое закомментите
import Mathlib.Data.Complex.Trigonometric

Я кстати нашёл язык, минимально из мэйнстрима, который идеально подходит в качестве протокола общения с LLM-ками.

Это ЛИСП! )))

Что смешного? Ну, лисперы в своё время считались куда хардкорнее чем сегодня хаскелисты и юникс/линукс-оиды. А уровень токсичности темки вообще зашкаливал :)

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

Точнее, сегодня это Racket (потомок Scheme).
Чистый АланКеевский путь - язык описывает сам себя.

(define-language my-domain
    (agent (knows abstractions) (does task)))

Плюс: это буквально родной инструмент для создания DSL.
Минус: далековат от прода, хотя... Поддерживают Racket финансово NSF, DARPA и др.

Racket is a language for making languages, so that a programmer can write every module in a well-suited language.
Often an application domain comes with several languages. When you need a new language, you make it - on the fly. Open an IDE window; create a language right there, with just a few keystrokes; and run a module in this new language in a second IDE window. Making new languages really requires no setup, no project files, no external tools, no nothing.

Вот реально, колеблюсь между хакселем и ракетом. Мощная формальная математика и система типов против абсолютной гибкости (кстати именно racket код нейронкам заходит лучше всего).

...В следующий раз, когда кто-то из вашей команды заявит, что вам не нужна DI, потому что например в качестве СУБД мы решили навсегда взять Постгрес, вы можете сказать им, что это не имеет значения. Выбор в ООП стоит между DI и говно/спагетти-кодом.

Смешное: мэйнстрим открывает для себя функциональное программирование =>

Sinks, Not Pipes: Software Architecture in the Age of AI

Пока на уровне "оркестрация синков" вместо "композиция чистых функций", ну ок, постепенно разберутся :)

Понимаю и кривизну понимания темы как следствие ООП -- например про зависимости в интерфейсах... Засада в том, что зависимости нечисты систематически (подсказка: юзайте свободную монаду + AST), а по каждому интерфейсу задавайте вопрос: почему вообще он потребовался? как вы собираетесь его использовать? Паттерн Стратегия? Ок, но а зачем ещё-то?
Рекомендую в частности вместо интерфейсов с одним методом использовать делегаты/лямбда-функции.

Всё это подробно разбираем с примерами уже скоро в гайде "Функциональные архитектуры".

Пользователь запрашивает отчёт, твой API ставит задание в очередь, worker генерирует PDF-файл.

Это pub/sub или очередь с воркерами?

(пауза)

Мнения в команде наверняка разделятся, и это будет похоже на спор о терминологии.

Но это не так.

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

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

При том, что сегодня для создания такого стартапа даже знания программирования не требуется, достаточно базы в devops, вот весь его стартап -- это одни выходные для миддла. И так же очевидно, что он просто тупая обёртка вокруг жпт, потому что от школьника глупо ожидать хотя бы какого-то оригинального наполнения агентов профильными скиллами (хотя сейчас-то он набрал рабов-кодеров, чтобы всё было "по взрослому" :). Но это норм, лохов-инвесторов так и надо разводить.

Меня в этой ситуации поражает, что на его сервис активно подписываются не только отдельные разработчики, но и компании! Это на каком же дне должны быть рабочие процессы, и каким же дебилом должен быть CTO, если они не могут в свои ci/cd впихнуть за пару часов агента с шаблонным скиллом ревью кода.

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

Код сейчас пишется быстро, большие объёмы за минуты, и если ещё вчера типичный программист мог весь день одним пальчиком кодировать типовые рабочие задачки на быстром мышлении S1, на автомате/интуиции, мозг по сути не напрягая, уже прокаченным скиллом, то теперь от него требуются, как уже говорил, навыки сеньорские архитекторские техдирские системно-аналитические. Разница по сути (пока) только в масштабе. Ну и так как эти навыки подразумевают уже в первую очередь необходимость принятия решений в нечёткой и неполной среде, едва ли не весь день разработчику приходится включать в голове на полную медленную сеть S2.

AI автоматизировал всю лёгкую работу, но нам оставил все трудные решения -- как низкоуровневые технические, так и высокоуровневые архитектурные и абстрактные, а также всяческую генерализацию, поток которых бесконечен, и для разбирательства с которыми надо постоянно включать мозг. Главная же засада, что обучиться этому, чтобы переключаться на S1, практически нереально.

Ну как бы думать интенсивно каждый день по 8-10 часов, и так без пауз неделями и годами, думаю, вообще никому не под силу, и нас ждёт эпическая волна выгораний в айтишке. В таком формате даже сильные сеньоры способны продуктивно работать только короткими блоками по 1-2 часа - один или изредка два раза в день, даже при большой практике. Максимум 3-4 часа, после чего разработческая активность становится контрпродуктивной и начинает только вредить (например, вносятся трудно находимые баги).

Раньше у нас был объективный предел: скорость набора текста, скорость мышления и время, требуемое для поиска информации. Теперь же этот предел ликвидирован, и рабочие дни программистов быстро становятся всё тяжелее. Не легче: тяжелее.

Кстати темку DSL я изучал ещё почти лет 20 назад, где-то ещё заметки сохранились, как только вышли соответствующие работы Алана Кэя по тысячекратной компактности кода. Потом, в частности, купил книгу Фаулера "DSL", игрался с JetBrains Meta Programming System (создай свой собственный предметно-ориентированный язык), вчера посмотрел, а она жива! Синхронизм - там на форуме по теме буквально 10 дней назад было обсуждение в контексте использования AI + DSL. Не удивлюсь, если тут именно жб сделает что-то продвинутое.

Кстати, в 2013-м я ездил по приглашению в Питер, в гости к Олегу Степанову, CEO JetBrains на тот момент, где-то ещё интервью с ним лежит в сети, и сходил на несколько их семинаров -- как раз по MPS, а также по гомотопической теории типов, после чего этими темками отдельно увлёкся.
Их тематическая лаборатория по HoTT ещё работает, я и не знал, оказывается теорем-прувер Arend -- это их работа.

Кстати, когда жб массово отчалили, я к этому относился сильно негативно, но в последние месяцы думаю: а может быть правы были они, а я ошибался? Ну когда уже совсем скоро пропадёт даже потенциальная возможность читать даже через впн западных топовых математиков и святых computer science в твиттере, тг, потом забанят сабстек и гитхаб... Ну, да, тор какое-то время поработает еле-еле...

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

.

Облако драгоценностей за неделю.

"Функциональное Проектирование" дополнено второй частью: реализуем проект дополнительно в многослойной архитектуре, причём весь код будет писать нейронка. Попутно коснёмся важной темы языков предметной области (DSL). Допройти можно бесплатно.

Приватный клуб.

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

8 базовых фактов о рынке ИТ-труда в 2026-м, и что из этого следует. Часть 2
6. Фильтр высокой квалификации.
Я постоянно слышу от ит-менеджеров, и даже основателей стартапов:
"У меня есть деньги, но я не могу найти способных людей".
Звучит безумно, не так ли? Когда так много безработных программистов?..

Для донов-начинающих:

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

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

Для донов-неначинающих:

А зачем человеку уровень PhD, если в плане карьеры уровень FAANG куда перспективнее во всех отношениях?

Продолжаю выкладывать для донов материалы СильныхИдей.
77. Функциональная архитектура - что это?
Давайте более глубоко погрузимся в тему функционального проектирования, для чего однако предварительно надо разобраться, а знаете ли вы, что такое функциональное программирование?
Да, например, те кто у меня занимается, получили базовое теоретическое представление из "Основ ФП", а затем полноценно попрактиковались в функциональном стиле на функциональном языке F#. Но даже если вы пишете на Хаскеле, можно ли сказать, что ваш код действительно функционален?

(все старые материалы для донов быстро сгорают)


=

Новые материалы для ментатов Лаборатории.

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

В СильныеИдеи добавлен материал "135) Моделирование времени в ФП".
В данном контексте мы постоянно упоминаем Haskell как единственный по сути более-менее массовый язык, подходящий для этого. Это не значит, что вы должны переходить на него: наша задача встроить в голову соответствующую думательную машинку...

💪🏻

Лаборатория идёт со скоростью самых лучших ментатов.

=

"ЛаМПовое": rust в духе си, формализация хаскелевского ghc, анти-macos, база по резюме-26, coq как макроассемблер.

Но переходить в Макс совершенно не планирую: это ещё больший зашквар чем принять FanID. Как в апреле забанят Телеграм, так Лаборатория закроется.

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

Гайд про функциональные архитектуры, 55 топиков (+2), как наберётся 64, дам ментатам доступ. Мои ближайшие планы на эту весну планирую реализовать в первом приближении в рамках этого гайда.

=

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

Вот куда сегодня активно идёт мэйнстрим: все делают агентов сложнее.
Больше инструментов, больше памяти, больше координации, больше токенов...

Вот например свежая реклама:

"Вы научитесь строить ReAct-циклы, работать с LangGraph и AutoGen, внедрять продвинутый RAG, протоколы MCP и AgentOps. Все ключевые навыки в одном месте: измеримость систем, time-travel дебаггинг, управление браузером, human-in-the-loop и развёртывание в закрытых контурах."
Курс такой стоит 90(!) тысяч рублей. Ничего не хочу сказать, это всё конечно знать надо, и польза определённая будет.
Но по сути это про чистые технологии, и по большому счёту про текст, про текстовое взаимодействие.

Я же стремлюсь в другую сторону: в формальные нотации. Точнее, даже не в другую сторону, а ортогонально. Все сейчас соревнуются в том, кто построит лучшего агента, а я иду в сторону "кто построит лучший язык для нейронки" (и пока буквально по единичным академическим работам могу сказать, что вся работа что здесь ведётся, ведётся втихомолку:).

В чём засада?

Человек вполне может работать с плохой архитектурой, постепенно улучшая её изнутри. Нейронка же усиливает то, что есть. Хорошая структура -- фигачит быстро и правильно. Плохая структура -- фигачит быстро и неправильно с уверенным видом :)

И если просто в лоб пытаться ей зафигачить какие-то руководства из computer science, толку никакого не будет.

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

А что бы это всё заработало, надо готовить компактный формальный DSL, специфичный для домена, и с тщательно подобранной грамматикой - как инструкция для LLM. Но зато полностью избавляемся от промптов и агентов!

DSL тут выступает как (почти) гарантированно работающий протокол общения с LLM вместо агентской архитектуры.

Всё это буду пояснять и показывать в рамках гайда "Функциональные архитектуры".

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

Альтернативные издержки работы на себя составляют миллионы рублей.
Альтернативные издержки работы в компании/на дядю составляют десятки миллионов рублей.
Выбирайте с умом.

Все наши требования к работе постепенно сводятся к умению чётко формулировать свои мысли во внешнем мире (а также иметь сами эти мысли достаточно чёткими).

Короче говоря, после активного мышления письмом в последние дни, я наконец-то сложил в уме весь паззл!!1

Модельки конечно здорово помогли, последние версии 4.6 5.3 прям хороши (правда едва ли не каждый день по 100 долларов уходило на интенсивное общение и эксперименты:).

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

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

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

Основная идея, что это будет нейро-DDD + метапрограммирование + LLM как компилятор DSL.

Как до сего года ещё работали сеньоры, да и миддлы, в своём поддомене?

Написал код - боль :) - отрефакторил - домен немного прояснился. И так по кругу.

А в этом году нейронка этот цикл убила:
Написал промпт - ллм сгенерила 5000 строк -
рефакторить уже почти нечего, всё "работает" :)
А домен закостенел кривым, неполным и противоречивым образом, и ничего ты с этим уже не поделаешь.

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

Я же хочу автоматически генерировать всю инфраструктуру домена полностью под правильную математику.

То есть от тебя требуется совсем пустяк:)
A) Найди, какая математическая структура уже описывает твой домен;
Б) Дай её нейронке явно в виде соответствующей грамматики (иерархии грамматик с наследованием);
В) Профит!

Пока конечно пункт A -- на 80% искусство, но думаю что со временем его получится снизить до прикладного мастерства. А вот пункт Б уже и сейчас можно достаточно прямо формализовать.

Главное, понимаю, как этому продуктивно обучать. С прицелом в ближайшее нейро-будущее 2-3 года!

Начинаем с базы DDD, перекраивая её под специфику нейронок, формализуем постепенно, всё более сильную математику добавляем, генерим инфраструктурные паттерны сперва на хаскеле, с которого нейронка уже очень хорошо сгенерирует код на этих ваших python go c# java, потом будем подключать system f, хотт/кубики...

"Люди стоят дорого. Мало того, люди, способные выполнять работу по преподаванию нетривиальных определений в современной исследовательской математике, представляют собой редкую породу. При нынешнем положении дел, если бы человек приступил к проекту по более подробному изучению философии Ленглендса с помощью компьютера, он должен был бы быть экспертом как в философии Ленглендса, так и в языке рассматриваемого ITP. Я пытался обучать аспирантов и докторантов этим навыкам, но их расхватывают технологические компании!" (c)

Этой весной.

Лично для себя после серии агентских экспериментов со всеми тремя топовыми моделями - жпт5.3 гемини3.1 клод4.6 - я понял, что в разы, a может и на порядки, продуктивнее остаётся что-то вроде обычного чата.

Какой-то cli я сперва сказал "напиши консольный калькулятор на питоне с парсингом скобок", а агенты зафигачили веб-версию на ts и ноде )))
и потом заныли что дескать уже то что я сгенерировал удалить не могу.

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

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

Никаких текстовых skills md у моих агентов нету в принципе -- их скилы я описываю формально, пока на питоне как скрипт-языке, что где куда и как им делать в этом конкретном проекте, а в перспективе планирую какие-нибудь завчипчики System F вроде Lean4 приделать, а потом и HoTT.

(на самом деле эту идею я похитил у классной агентской библиотечки
"smolagents: barebones library for agents that think in code" от самих huggingface, где в качестве скиллов применяют питон)

Думайте, как думаете.

Но так как денежки нам пока ещё платят сегодня, возвращаемся к нашим искусственным баранам )))

В чём на мой взгляд ключевой недостаток сегодняшних агентских систем?
Ну вот ровно в том же, в чём и недостаток классического мэйнстрима -- они слишком поверхностные, хипстерские и универсальные, их реальный кпд я оцениваю менее 1% (а то и менее 0.1%).

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

Примеры которые я недавно приводил -- тысячи skills md на все случаи проектов -- но каждый из них к твоему проекту так-то вообще никакого отношения не имеет, кроме разве что совпадения по названиям технологий.

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

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

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

В частности, к агентским системам тут у меня отношение однозначное =>