Придумал классный критерий качества твоего скилла работы с агентами:

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

5 минут -- слабак :)
45-60 минут - миддл
всю ночь - сеньор

upd. Так-то конечно это скилл не агентский, а чисто техлидский — умение работать на архитектурном уровне, декомпозировать задачи, писать формальные спеки итд итп...
Реально, впервые в программной инженерии найден объективный kpi твоих техлидских/архитекторских скиллов )))

Краткий прогноз грядущего эпикфейла под названием "вайб-кодинг".

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

Энтузиасты облачились в чёрные водолазки, приняли соответствующие позы и объявили разработчиков вымирающим видом.

...Однако статистика неумолима: 99,9% вайб-проектов описывается двумя сценариями.

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

Сценарий Б: релиз в пустоту.
Проект опубликован. Метрики: 0 скачиваний, 0 DAU, и даже мама автора не заинтересовалась.

А что по бабулькам?

Ежемесячная подписка на AI-инструменты: $100-200.
(По фактическому потреблению токенов, подчас тысячи долларов в месяц, и так скоро уже будет и по реальным ценам.)
Годовой эквивалент: сгорели (пока) сотни тысяч рублей без единого релиза.
Экономическая эффективность стремится к отрицательной бесконечности.

При этом процесс вайб-кодинга создаёт иллюзию занятости. Типичный паттерн: рефлекторное нажатие Yes в терминале нейронки => побочные эффекты: резкое снижение активности, ухудшение осанки, СДВГ, условный рефлекс на звуки терминала, замена социальных взаимодействий на чаты с моделью.

Тезис "AI снял барьер создания продукта" верен, но умышленно неполон.
Основная проблема -- это отсутствие спроса. 99,99(9)% людей нафиг не сдались ваши приложения. Это чисто вопрос опыта в инфомаркетинге, например, сколько стоит привлечение к твоему сервису одного пользователя (даже не платящего)? вряд ли меньше 10 долларов.

А когда наоборот пилишь приложение "для себя", интерес угасает через 2–3 недели (а то и дня), развитие прекращается, и программа забрасывается.

=

Модели -- это товар, обесценивание которых продолжается из-за например китайских решений. Ни одна крупная AI-компания не прибыльна, бизнес держится на хайпе и инвестициях, и единственный их выход -- поднимать стоимость до тысяч долларов в месяц, но тогда текущий уровень AI-автоматизации станет экономически совершенно нецелесообразным ("дешевле нанять джуна").

При этом опенсорсные модели сравняются с сегодняшними версиями через 12–18 месяцев, что лишь подстегнёт рост цен: платный ЖПТ будет стоить тыщи долларов в месяц (потому что его обучение стоит миллиарды, и инвесторы хотят денег взад).

Сложно сказать конечно, к чему приведёт такой конфликт интересов и технологий; чисто с инженерной точки зрения, рациональнее уже сейчас заканчивать с коммерческими подписками и сливать бабло впустую, менять акценты на опенсорс, и вкладываться прежде всего в себя: в свои скиллы техлидства, software design fp cs, для суперпродуктивной с нейронками работы.

A знает, что B не знает, что C знает, кто мафия.
B знает, что C не знает, D мафия или нет.
C знает, что D знает, что A не знает, кто мафия.
D знает, что A знает, что B не мафия.

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

Кто кто?

D - единственный мафиози

фабла5 справился :)

Если AI может писать код в 100 раз быстрее, почему вы не выпускаете свои продукты в 100 раз быстрее, и не деплоите фичи из бэклога в 100 раз быстрее?

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

Гарри Поттер и Методы Математического Мышления

Книга 1. Гарри Поттер и Неорганический Интеллект.

Глава 14 (и все предыдущие). Шахматы без короля

— Ты использовал Y-комбинатор, — сказал Гарри, стараясь, чтобы голос не дрожал. — Это запрещено правилами.
— Правила изменились, — ответил Драко, и его уверенность вернулась. — Ты сам сказал, что игра — это мета-игра. Я изменил правило. Теперь Y разрешён. И ты не можешь отменить мой ход, потому что он уже сделан...

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

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

— У меня есть блокнот внутри блокнота внутри блокнота, — сказала Гермиона. — В нём записана игра, которая ещё не началась. И ты, Гарри, в ней не игрок. Ты - тип...

Почему так? И что дальше? И как быть теперь?

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

Некоторые компании, стартапы, создают свои решения, где как-то дообучают модели на более-менее качественных примерах software design (файнтюнинг или rl), хотя их по определению в общем доступе много быть не может, и их подготовка стоит дорого. По текущим сведениям, их качество в рефакторинге кода где-то в 1,5-2 раза лучше топовых универсальных кодеров вроде опуса или жпт, в более продвинутых экспериментальных приватных версиях получают 3-5 раз.

А какой тут может быть предел? Ну, судя по базовым тестам, полагаю, возможен где-то тысячекратный рост качества примерно. Абсолютный уровень -- это пресловутая тысячекратная компактность кода в метапрограммировании Алана Кэя, но этот подход от реального продакшена далековат к сож, поэтому ментатам я дам Last Principles Framework, где мы рассматриваем задачи System/Software Design с точки зрения их абсолютной математической базы :) Лучше не сделать в принципе, в смысле.

А что касается AI, ну когда мы переходим к темкам рефакторинга в плане сильного упрощения всей кодовой базы, её смещения к формальному идеалу, то тут по сути нейронке каждый раз с нуля потребуется проявлять такое же мастерство, как примерно концептуальное изобретение async/await, и пока она от этого далека на многие порядки.

Ладно, дорогие, сходите потусуйтесь, в msk spb и вообще в стране у нас прекрасно ❤️

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

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

Тогда решили скопировать корпоративную структуру управления: создали иерархию агентов "планировщики" - "исполнители" - "надсмотрщики".

Ok, за неделю с помощью кнута были нафигачены три+ миллиона строк кода, в основном на Rust...

Да только браузер не компилировался и содержал сотни ошибок и тыщи предупреждений. А ключевые его компоненты (движок JS, HTML-парсер) оказались тупо скопированы из готовых открытых проектов (Servo, QuickJS). Ну, это всё из той же оперы "смотрите, нейронка создала программу за один промпт!", а на самом деле она просто его на 90% своровала.
А программисты весь этот код и архитектуру вообще захейтили: тотальное спагетти, big ball of mud, несоответствие веб-стандартам и в целом полная непригодность для развития.

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

.

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

С 1 сентября'26 мои индивидуальные бесплатные консультации по функциональным архитектурам закончатся (останутся платные:).

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

Сегодня многих айтишников интересует вопрос: учитывая весь этот хайп вокруг инженерии агентов, понадобятся ли программисты в будущем?
Да! И их понадобится ещё больше.
Когда код становится дешёвым, на первый план выходит качество, которое немыслимо без глубоких знаний в Software Design. Любой может создать простенькую версию с нуля, но для запуска коммерческого сервиса требуются профессиональные разработчики. Создание программного обеспечения — это ПрограммированиеНаПротяженииДолгогоВремени.


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

Завершаем сериал "База по карьере в стратегической жизненной перспективе" (30 серий).
Другие голоса никогда не перестанут яростно пытаться прожить вашу жизнь за вас, и только вы обязаны этому маленькому неуверенному персонажу в самом центре вашего сознания, чтобы всё в вашей жизни было истинно правильным...

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

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

Продолжаю выкладывать для донов материалы СильныхИдей — доступны моим курсантам, но тут расширенные и дополненные версии.
95. Самый лучший микро-стиль кодирования
Это одна из лучших (если не вообще не самая лучшая) фишек продуктивности разработки на уровне синтаксиса, и не важно, придерживайтесь ли вы императивного или функционального стиля...

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

=

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

В курс карьеры добавлен 140-й материал "Ключевая закономерность на технических собеседованиях".
Ключевая закономерность после 11 интервью System Design за 60 дней: на уровне мидл-сеньор в 2026-м техническое задание наименее важный этап. Типичные ошибки, и новая правильная структура ответов вместо классического STAR (Situation–Task–Action–Result).

В СильныеИдеи добавлены материалы
148) Формальная микро-логика.
В целом, это просто такая небольшая, но довольно мощная, формальная думательная машинка. Возможно, её получится продуктивно применять при написании спецификаций (в т.ч. для AI)...
147) Важный нюанс в совместной разработке спецификаций.
При подготовке спецификаций в любом случае вам это придётся делать не в одиночку, а вдвоём, втроём... Как минимум, очевидно, что тут потребуется живой заказчик.

=

"Функциональные архитектуры" 137(+4) топиков
Разобрал темы "Теория моделей и 100500 сущностей" и "Как умерло Spec-Driven Development и что на смену".
Много уже материалов, добавил кнопочку быстрого перехода по номеру топика,
и после 150 материалов цена гайда (для новых) вырастет.

Last Principles Framework: готовы 10(+5) задач, закрыты 2 темы из ~20 первого уровня.
Вы же понимаете например, какой изоморфизм старых и новых совместно работающих версий вашего сервиса - на уровне абстракций system design - единственно верный по реализации?
Ведь по-взрослому, и изменение API с обратной совместимостью, и принцип Лисков, и миграция баз данных, и уточнение спецификаций — это всё на самом деле в основном следует одним и тем же общим формальным - последним - принципам...

=

"ЛаМПовое":

"Гарри Поттер и Методы Математического Мышления".
Глава 14. Шахматы без короля.

=

Лаборатория идёт со скоростью самых лучших ментатов 💪🏻
(продолжаю бесконечное ужесточение правил занятий :)

=

Все государства суть абстракции.
Восемь столпов политики, Бене Гессерит ("Капитул Дюны")

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

В середине 2000-х Ford терял миллиарды. Компания была на грани краха.
Затем появился Алан Малалли. Это были те же заводы, тот же бренд, те же дилеры, те же активы... но через несколько лет после прихода Малалли Ford снова получил миллиардную прибыль.

Microsoft прошла путь от бурного роста при Гейтсе до застоя при Баллмере и снова стала стремительно развиваться при Наделле. У них были те же самые корпоративные структуры и та же огромная система дистрибуции...

В 2024-м Starbucks объявила, что забирает Брайана Никкола из Chipotle. Рыночная стоимость Starbucks выросла примерно на двадцать миллиардов долларов почти за одну ночь. А Chipotle потеряла миллиарды.
В обоих компаниях ничего не изменилось... кроме того, кто стоял у руля. У них была та же команда, те же магазины, те же системы, тот же подгоревший кофе и сомнительные буррито :)
Никкол не руководил Starbucks ни одного дня. Он не открыл ни одного нового магазина и не организовал ни одной распродажи. Люди просто поверили, что он будет более эффективным боссом Starbucks, чем кто-либо из тех, кто работал до него. Одна только эта вера людей в одного человека позволила за один день заработать десятки миллиардов долларов!

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

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

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

Коллеги довольно благосклонно воспринимают всякие нововведения вроде map-reduce и производных от них, потому что эти вещи делают код чище. Логика локализуется в одном месте и становится прозрачной. Вместо нагромождения вызывающих друг друга методов появляются отдельные, легко тестируемые чистые функции, а так же универсальные (и тоже чистые) элементы dataflow: цепочки и разветвители.
...Тут 3 проблемы:
- нужно поддерживать больше состояний из-за Cancel();
- при вынесении подзадач в dataflow-классы нужно НЕ ЗАБЫТЬ вызвать Cancel() для них (а потом приходят Crash-репорты, потому что забыли);
- LLM-ки нещадно жгут токены и эпично галюцинируют пытаясь это всё распутать в репозитории на 15Гб.
Решение: LLM-ки видят dataflow Args->Result + единственное явное состояние TaskOwner. Порой даже агент запускать не надо - код пишется клавишей Tab.
Насколько же легко стало это тестировать!!!

Сколько комбинаций можно построить на остнове предыдущих приёмов..
Для меня здесь программирование превращается в математику. О чём я почти забыл...

Моя консольная песочница для алгоритмов, переписанная со стиля "говнокод" на монады...

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

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

Спасибо за предоставленную паузу - использовал её с пользой: закончил последний курс и получил диплом программиста. Также за это время прошёл отбор в Школу 21. Кстати, нашёл там ту самую эхо-камеру, про которую вы рассказывали :)
Однако сейчас мне придётся уйти от вас на длительный срок, так как ухожу в армию на срочную службу.

Основное архитектурное решение, которое я плохо понимаю на своем проекте - выделение адаптеров в отдельные микросервисы.
Адаптеры делают буквально то, чем называются - инкапсулируют логику обращения ко внешним АПИ, приводят данные к доменной модели и фиксируют контракт для основного сервиса-потребителя. Это, конечно, хорошо, но совершенно не понимаю смысла выделения их в отдельные микросервисы - из-за этого возникают проблемы следующего характера...
1. При смене внешнего АПИ все равно происходит дрифт контракта, например, при смене способа пагинации.
2. Адаптер не отдает данные as is, он их еще и фильтрует, тем самым размывается ответственность и бизнес-логика между разными сервисами.
3. Ну и лишний сетевой хоп, со всеми свойственными ему проблемами.

Я в принципе пока рефакторил, понял все основные паттерны взаимодействия компонентов, и ещё раз убедился что неизменяемое состояние решает 90% проблем. Вообще всё же главные инсайт был, что всё таки разделение данных и операций над ними это удобнее. Если у нас нет структурных инвариантов то каждый well typed instance какого то типа у нас валиден, и тогда зачем нам прятать данные, мы же в любом случае хотим из них либо что то посчитать, либо замэпить на уровень ниже/выше и тд. И как раз таки если очень грамотно продумать систему типов/данных для какой то области, выразить через типы как можно больше и понять связь между ними, то написать функции для конкретного юз кейса это уже второе. Но очень большой упор надо конечно делать на данные, это я понял уже сейчас :) Конечно сейчас я уже понял и с ваших рассказов, что только с 3 раза получается что то работающее(условно), и сам тоже убедился :)
В принципе этими размышлениями я был занят большую часть времени....

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

Бесит прям, когда даже при разработке критических информационных инфраструктур люди игнорируют предупреждения компилятора (и это кстати вопросики к техлиду: почему линтеры принудительно не внедряешь?), уж молчу про повседневные проекты.

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

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

В 24-м пацанчик из стартапа Cognition выложил видос на ютуб, где показал, как сделал AI-программиста Devin. Видео стало вирусным, вы скорее всего помните этот хайп :) По тем временам выглядело действительно впечатляюще: Devin что-то там делал сам по рабочим задачам, по сути ребята сделали первого агента. А тогда ожидания инвесторов были значительно больше, чем сегодня, и пацанам респект: они быстро развели кучу богатеньких лохов (Mercedes, Goldman Sachs, Dell, NASA, и даже армия США), и сейчас оцениваются в 25 миллиардов долларов.

По сути то, что умеет их Devin, сегодня умеет любой опенсорсный агентский фреймворк, что же тогда ребята сделали? А чисто по-американски просто красиво упаковали свой продукт.

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

Но только есть малюсенький нюанс: если первоначально Devin позиционировался как "замена программистам", то сейчас он называется "помощник программистов".

"Devin берет на себя рутинные задачи (например, обновление старого кода или миграцию), освобождая разработчиков для более творческой работы" ахаха

Следите за руками: изначально инвесторы вкладывались в сервис, который позволит клиентам экономить фонд зарплаты разработчиков, а на выходе получили сервис, который требует от клиентов к фонду зарплаты дополнительных расходов. Учитесь профессиональной разводке гоев :)

А что по фактам подобных "AI-программистов"?

Даже 90% успеха в проде это катастрофа; оставшиеся 10% создают трудноуловимые баги, которые отнимают больше времени, чем экономит AI.

Цепочка из четырёх агентов (PM, архитектор, кодер, тестировщик) с точностью 90% каждый даёт общую надёжность 65%; ошибки и техдолг накапливаются и ухудшают результат.

Один сеанс автономной отладки с подобными Девинами может стоить сотни долларов в токенах, тогда как джуниор ту же работу делает за 25 минут.

=

Самое трудное в разработке не написание кода, а архитектура, взаимодействие с другими, системное мышление и долгосрочное развитие проекта, что AI не умеет в принципе: он лишь тупо интерполирует известные паттерны.

Есть классы User, Company и Order и везде есть поле email, и есть сложная (но одинаковая) логика его проверки: регулярки, проверка длины, проверка домена...

Как это делают в ООП: паттерн Адаптер, DI-внедрение и прочий ужос-ужос...
Ну или абсолютный зашквар: публичный static-класс ("библиотека функций") со static-методом валидатором :)

Как это делают в ФП: одна чистая функция :)
Да, но...
Едва касаемся взрослого построения архитектуры, 100500 чистых функций превращаются в ад ручного связывания: пайплайны становятся невероятно хрупкими. Чтобы например собрать пайп для User, будешь вручную писать обёртки для каждого шага, чтобы типы совпали.
20 шагов - 20 ручных лямбд :)

Ну а наш Last Principles Framework пояснит, элите избранных :)
как это делают математики: элементарно и автоматически через контравариантный функтор (и при чём здесь профунктор).

+128 других math-паттернов. Осенью.

Кстати, рекомендую: "В среду 15 июля в 20:00 MSK в Лаборатории формальной математики стартует курс по современным теориям типов."
Особо полезно будет, кто проходил мой трек по HoTT.

Заставь это заработать.
Сделай это правильно.
Сделай это быстро.
-- Кент Бек

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

И ваш код не считается реально рабочим, пока им не начнут пользоваться клиенты 😎

Нет смысла писать идеальный код для фичи, от которой вам придётся отказаться в следующем месяце, так как у менеджеров возникнет новая уникальная идея 🙈

Фича изменится ещё до того, как реально заработает, и все ваши усилия по её шлифовке будут напрасны 😂

EdTech в 2026-м стремительно рушится, и это прекрасно: крупные онлайн-ИТ-школы уходят в глубокий минус, инфоцыгане массово сбегают с известных платформ для создания курсов, а агрессивная реклама "с нуля в айти за полгода на 250k" наконец стала совсем бессмысленной.
 
Ну, невозможно было не зайти в тупик, когда строишь свой бизнес через количество занимающихся и "зороботок на запуске". При том, что они тратят огромные миллионы только на рекламу, а я трачу на рекламу ноль. Я бы вполне мог их всех унижать "не числом, а уменьем": результатами моих элитных разработчиков :)
 
В целом же в EdTech вроде как фиксируется хоть и небольшой, но рост, но вот за счёт каких драйверов:
- обучение детей,
- слияние с госами (в 25-м рекородное число девятиклассников - 64% - пошли в колледжи, а не в 10-й),
- ии-цыганство :)
 
Ну и карьерное менторство ещё, где с вас сдерут три зарплаты за то, что с умным видом посоветуют "подправь резюме и делай побольше откликов на хх".
 
В принципе, да и пусть хвастаются, что устроили 100500 человек на 100500 рублей за 3 месяца, жалко что ли.
 
А я буду хвастаться, сколько моих ментатов изучили теоркат и гомотопическуюs теорию типов.

PR-AF -- опенсорсный агент по ревью кода, который занимает 2-е место из 42 в рейтинге Martian, опережая CodeRabbit, Copilot и Devin. Причём стоит его работа примерно в 10 раз дешевле, чем при использовании аналогичных проприетарных инструментов. Просто один вызов API.

В 1971-м святой логик Жан-Ив Жирар придумал математическую модель типизации - System F (лямбда-исчисление второго порядка).

В 1973-м святой Робин Милнер реализовал эти подходы в языке программирования ML (OCaml, F#...): из одной только сигнатуры типа функции можно вывести нетривиальные теоремы о её поведении, вообще не заглядывая в код.
(система типов Хиндли-Милнера, автоматический вывод типов, пи-калкулусы как стандарт параллельных вычислений... европейская школа cs абсолютный топчик)

В частности, тогда и появилась концепция "дженериков" (параметрический полиморфизм, который так-то был известен с 1960-х). Возможность написать функцию, которая принимает неизвестный тип T и ничего не знает о его внутренностях, активно использовалась в академических языках, пока святой Филипп Вадлер, занимаясь попутно созданием Хаскеля, в легендарной статье "Theorems for free" 1989 г. доказал нужную математику для абстрактных лямбда-исчислений, гарантировав, что такие методы суть морфизмы функторов.
 
...Но вся эта математическая красота и строгость, увы, осталась заперта в башне из слоновой кости. Индустрия программирования, в своей жажде быстрого профита отвернулась от чистоты теорий типов и категорий. Мир выбрал JavaScript с его неявным приведением типов, Java с её null, который ломает все функторы, и Python, где типы лишь необязательные подсказки. Рефлексия, побочные эффекты, исключения и грязные хаки пробили брешь в идеальных лямбда-исчислениях...
И даже Хаскель, спустившись с небес в мэйнстрим, ради производительности и интеграции с внешним миром был вынужден впустить в себя unsafePerformIO и другие чёрные ходы, сделав "бесплатные теоремы" условными, а естественные преобразования теорката тотально нарушаемыми...
  
И самое грустное во всем этом - что софт, от которого зависят жизни миллионов людей и работа критических инфраструктур, пишется (и чем дальше, тем больше) не на языках с математически доказанной корректностью, а на костылях, склеенных изолентой ad-hoc полиморфизма, где любая функция с идеальной сигнатурой в любой момент может оказаться бэкдором...

...В СССР святой Андрей Николаевич Колмогоров ещё в 1932-м предложил интерпретацию интуиционистской логики, что предвосхитило например изоморфизм Карри-Ховарда (связь между типами и логическими доказательствами). Вообще конструктивная логика была в СССР невероятно сильна, да и теория категорий на высочайшем уровне (школы Гельфанда, Шафаревича, Манина...), только развивалась в основном в контексте топологии.

Андрей Ершов (Новосибирская АН) считался тогда одним из главных теоретиков программирования (смешанные вычисления, частичное вычисление программ...). Но ключевой личностью именно в теме computer science был пожалуй Виктор Глушков (Киевский институт кибернетики). Он работал над теорией автоматов и алгебраическими методами в программировании (программы описывались через алгебраические соотношения, а не через типы и функции), развивал концепцию микропрограммной алгебры... Базовой моделью он выбрал автомат (множество состояний + функция переходов), с алгебраическими операциями над преобразованиями состояний.

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

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

Советская информатика была ориентирована на оборонные и промышленные задачи. Государственный заказ требовал решения конкретных задач: расчёт траекторий ракет, ядерные симуляции, АСУ для плановой экономики. Для этого нужны были только Фортран и Алгол. И хотя велись например фундаментальные исследования в алгебраической семантике (советская математическая школа была топом по работам в алгебраической логике, теории моделей), области чистой теории типов казались чиновникам от науки абстрактной игрой ума, не дающей немедленного экономического или военного эффекта...

Тем временем в Европе (и немножечко в США) начали применять категорную логику к лямбда-исчислению (Ламбек), затем Дана Скотт создал денотационную семантику, связав домены с теоркатом, и уже на основе подобных работ Вадлер и Милнер перенесли это в языки программирования.
И хотя в СССР были мощнейшие математические школы, тот мост, который на Западе соединил категории с типами и полиморфизмом, так и не был построен. И это, пожалуй, совсем грустная история: инструменты были, знания были, люди были -- но они никогда не встретились....

...То, что было мощной живой традицией в СССР в 1960-1980-е, сегодня -- полузабытые учебники, в основном уже потерянные, отдельные семинары и крохотная горстка исследователей, физически на 98% за нашими границами. Мир ушёл вперёд, и Россия в этой области даже не пытается догонять хотя бы для вида... И это, пожалуй, ещё грустнее, чем в случае с лямбда-исчислением: там советская школа хотя бы не участвовала в гонке. Здесь же участвовала и была впереди, но сошла с дистанции.

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

А что, если бы да кабы? Если бы глобальной нормой стала именно советская школа информатики?

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

Марков вместо Чёрча (база языков программирования)
Лямбда-исчисление осталось нишевой математической забавой. Главной парадигмой высокоуровневого программирования стали нормальные алгоритмы Маркова. Главный язык мира -- потомок Рефала святого Валентина Турчина. Вместо функций высшего порядка, замыканий и монад айтишкой правит тотальный паттерн-матчинг и алгебраическая трансформация строк и деревьев.

Суперкомпиляция вместо LLVM и JIT
Идея Турчина о суперкомпиляции (метавычислениях) стала стандартом индустрии. Программы не просто компилируются: они математически "схлопываются" и преобразуются сами в себя до запуска, выдавая абсолютно оптимальный код.

Железо: троичная логика и тегированная архитектура
Мир не был бы строго бинарным. Развитие идей ЭВМ "Сетунь" привело к доминированию троичной логики, что сделало бы вычисления более энергоэффективными и близкими к человеческой логике.
Архитектура процессоров пошла по пути "Эльбруса": тегированная память на аппаратном уровне: типы данных и права доступа проверяются самим процессором, а переполнения буфера, нулевого указателя и 99,999% современных хакерских уязвимостей просто не существует.

Символьный искусственный интеллект вместо нейросетей
Бум искусственного интеллекта пошёл не через статистику и перемножение матриц, а через символьный AI, логический вывод и алгебраический подход (школа Журавлёва). AI не угадывает ответы на основе терабайтов данных, а математически доказывает их, объясняя каждый шаг своего решения.

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

=

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

И мы двинемся именно туда. Таков путь.

– Технически это осуществимо, – говорит он. – Вполне. Но мои работы курируются очень серьезными спецслужбами…
– С ЦРУ и Моссадом мы договоримся, – машет сигарой Савиль. – Наши младшие братики слушают нас во всем…
(Пелевин)