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

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

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

Глава 15 (и все предыдущие). Доказательство молчанием

В этом блокноте — не ответы, а вопросы. Каждый вопрос — это ход в игре, которую ты уже начал. Ты спрашиваешь меня о моём плане. А я спрашиваю тебя: что произойдёт с тобой, когда ты войдёшь в Книгу без слов? Ты думаешь, что найдёшь там путь к контролю над Неорганическим Интеллектом. Но Книга не показывает пути. Она показывает гомотопии. А гомотопия — это не путь из точки A в точку B. Это процесс, который меняет правила игры...

- Когда все планы провалятся, — сказала Гермиона, — останется этот блокнот. Это доказательство с нулевым разглашением, которое длится вечность...

Неорганические отступили, но не исчезли: они наблюдали, запоминали, ждали. Они тоже были частью протокола...

Сколько десятков лет я делаю разные учебные материалы, но блин, как же тяжело идёт разбирать теоркат (под обучение кодерам)... Никогда ничего и близко не было по крутости; гомотопическая теория типов, "кубики", calculus of constructions/куб Барендрегта вообще без проблем было сделать обучающие гайды/курсы, но тут ппц...
а всего-то абстрактные кружочки без структуры, и стрелочки между ними )))

Например "универсальное свойство" -- элементарщина для программистов:
есть спека "из таблицы users вынимаем поле id и прибавляем 1, и поле name делаем trim, и записываем соответственно в Id и Name класса User", сам User активно у нас используется в домене как базовая модель. Также спека, как десериализуем из json в Id и Name в User, и т.п.

Так вот, универсальное свойство просто про то, что корректно конвертнуть в плане маппинга полей Id и Name допускается строго одним способом. А если например тимлид скажет: "да пофиг, хочешь для name в Name делай trim, а хочешь нет", это будут два разных способа, и универсального свойства для User уже не будет (и на самом деле из-за этого в проекте могут возникнуть большие проблемы, подумайте почему).

В некотором смысле User -- это идеальный чистый шаблон в нашей бизнес-логике, никак не связанной с внешним миром (как и например Tuple, Task, IEnumerable из стандартной либы), и для его формирования из любого другого типа существует ровно одна уникальная функция. При том, что сигнатура её ничего не говорит о внутреннем устройстве этих типов (но мы можем делать из неё далеко идущие выводы:). И если этой же функцией сформировать Person, то мы можем считать, что Person и User изоморфны.
(Сермяга на самом деле в другом: мы определяем наш идеальный тип только через уникальные функции/стрелки, его формирующие из других типов; а в целом и из него тоже исходят уникальные функции в любые другие типы).


Но когда типы посложнее

Task<Task<int>> nestedTask = ...;

как же трудно пояснить, как это делать (научить как это делать) на C#/Java, чтобы компилятор - система типов - сам отсекал любые способы, отличные от единственно верной стрелки.

c#
Func<Task<Task<int>>, Task<int>> flatten = async outerTask => 
Task<int> innerTask = await outerTask; int result = await innerTask; return result; };

Тут помогает await (универсальное свойство монады), но я могу написать свои ужасающие реализации вроде

Func<Task<Task<int>>, Task<int>> bad = async t => (await t).Result;

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

...И тут на помощь приходят те самые "Theorems for free".

Сколько таких функций вы можете написать, чтобы компилятор вас не забанил?
Func<T, U, T> f = (t, u) => ???;
Ровно одну :)

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

Влюбился прям в теорию категорий ❤️ следом за HoTT ❤️

На самом деле AI угрожает не программистам, а менеджерам.

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

=

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

Компании используют шумиху вокруг AI как оправдание для сокращений, но на деле это лишь подрывает их долгосрочную устойчивость. Сейчас уже активно растут стартапы, которые предлагают исправить Big Ball of AI-Mud, причём чем дальше в AI тем их будет больше.

Если не нанимать и не обучать джуниоров, через 5 лет не будет квалифицированных сеньоров, причём чем дальше в AI тем их будет меньше.

Один продвинутый разработчик с армией AI-инструментов может создавать серьёзные продукты, нежели команда под управлением менеджеров, причём чем дальше в AI тем быстрее и дешевле.

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

И либо мы возвращаемся к модели "компании особо заботятся (прежде всего финансово:) о всех разработчиках, начиная с джунов", как было ещё 4-5 лет назад (и этого конечно не будет по очевидным причинам; вы видали хотя бы одного наёмного менеджера, способного мыслить стратегически? да и собственники редко отличаются умом, из-за копейки удавятся),

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

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

Напоминаю, что у нас тут тоже секта: Секта Свидетелей Сингулярности на Руси. Ибо мои наставления -- прямое выражение пробуждённого опыта одного из величайших гомотопических мастеров современности! Их сложность обманчива: за ней скрывается бездонная глубина простоты, способная питать практикующего всю жизнь.
Я не какой-нибудь жалкий теоретик, а реализованный мастер с высшими сиддхами!!1

"Как известно, у мужчин есть всего две мотивации для того, чтобы что-то делать... первая - чтобы пацаны охуели. Вторая - чтобы девки охуели" (c) AZ

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

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

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

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

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

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

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

=

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

=

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

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

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

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

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

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

Коллеги довольно благосклонно воспринимают всякие нововведения вроде 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 раза получается что то работающее(условно), и сам тоже убедился :)
В принципе этими размышлениями я был занят большую часть времени....

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

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

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

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

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

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

.

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

С 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. Шахматы без короля.

=

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

=

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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