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

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 разрешён. И ты не можешь отменить мой ход, потому что он уже сделан... В нашей игре нет терминальной позиции. Мы играем бесконечно. Каждый наш ход создаёт новую игру, и эта новая игра создаёт следующие ходы. И мы не можем остановиться, потому что остановка — это тоже ход... Это закончится тогда, когда кто-то увидит всю игру целиком, — сказал Гарри. — Не как последовательность ходов, а как структуру. Как путь между всеми возможными играми.... — Ты прав, Поттер, - сказал Драко. - Я — неподвижная точка. Я — контейнер для ошибки, которую ты создал, когда переписал себя. Но ты забыл одну вещь. Настоящая игра начнётся в Книге без слов.... — У меня есть блокнот внутри блокнота внутри блокнота, — сказала Гермиона. — В нём записана игра, которая ещё не началась. И ты, Гарри, в ней не игрок. Ты - тип...

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

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

A знает, что B не знает, что C знает, кто мафия. B знает, что C не знает, D мафия или нет. C знает, что D знает, что A не знает, кто мафия. D знает, что A знает, что B не мафия. Мафиози может быть несколько, и все они знают друг друга, а мирные не знают никого (кроме явных упоминаний их знаний других в утверждениях). Сами высказывания истинны. Кто кто? D - единственный мафиози фабла5 справился :)

Краткий прогноз грядущего эпикфейла под названием "вайб-кодинг". За последний год 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, для суперпродуктивной с нейронками работы.

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

Ты -- это GIL в Python для своих агентов. Что толку, что ты можешь создать сколько угодно потоков, если мьютекс позволяет исполнять только один байт-код поток, захватывая блокировку. Также и твои агенты могут работать "одновременно", но когда какая-либо из их задач требует понимания архитектуры или разрешения конфликтов, она должна получить тотальную блокировку на всё остальное. И именно ты её удерживаешь. Создание агентов, да и их "инженерия", по большому счёту -- это не скилл а развод гоев. Любой школьник может скачать клешню или другой фреймворк оркестрации, и запустить 42 агента в параллель. Настоящее мастерство заключается в проектировании системы с использованием AI, с учетом единственного последовательного ресурса, который невозможно клонировать или распараллелить. Этот ресурс -- твоё внимание.

Как сразу всё получается стройно и элегантно, стоит всего лишь добавить терминальный объект с нулевой энтропией (т.н. uninhabited types). Почему бы вместо анти-паттерна void сразу не сделать Unit?? А в результате приходится пилить приляпки, как language-ext для шарпика. На треке ООАП разбираем лайт-версию этого, когда делаем свою замкнутую систему типов, от Object до Unit. Ну хотя бы public enum Unit : byte { Value = 0 } (хотя кардинальность его будет 256, а формально нужна единица) Подробно решаем и разбираем подобные задачки и как нормально делай, в Last Principles Framework.

c#
// Без Unit — два разных метода
Task DoSomethingAsync();
Task<int> GetValueAsync();

// С Unit — единый интерфейс
Task<Unit> DoSomethingAsync();
Task<int>  GetValueAsync();

// Можно писать обобщённый код:
async Task<T> WithLogging<T>(Func<Task<T>> operation)
{
    Console.WriteLine("Start");
    var result = await operation();
    Console.WriteLine("End");
    return result;
}

// Вызов для "void" операции:
await WithLogging(async () =>
{
    await DoSomethingAsync();
    return Unit.Value;
});

Продолжаю работу с ментатами 🤓 И еще хотел отметить как сильно нагрелся компьютер при тестировании Впервые мак настолько нагрелся за все время учебы и работы.. Понял, на что уходит непозволительно много времени. В топе самое банальное из того что можно было представить - отладка :) На второй работе распределенный монолит as is, пачка микросервисов, перекрестно зависимых друг от друга, чтобы завезти фичу, нужно внести изменения сразу в несколько сервисов, одновременно их задеплоить (при этом, окружение для тестирования одно, а разработчики все хотят задеплоиться), увидеть ошибку интеграции, повторить N раз... Делаю систему возврата товаров для маркетплейса. Была сложность в том, что у них информация о товарах передается в 4 модулях, при этом информация из модулей сильно связана между собой (например в модуле 1 находится информация о продукте, в модуле 2 его характеристики (цвет, размер), а в модуле 3 информация о его возвратности и гарантиях). И получается, что без получения самого продукта из модуля 1 некуда применять события из остальных модулей, пришлось думать над этой задачей. Плюс к этому они раз в день выгружали полный дамп базы в эти модули, получалось по 10 млн событий в каждом модуле, которые надо обрабатывать и дедуплицировать... Сложно придумать более наглядный анти-паттерн, когда доменную модель разрывают на несколько модулей :) Когда скорее всего есть связка по айдишникам товаров, но асинхронщина по времени. От free monad коллеги, скорее всего, в шоке будут, но уж больно хорошо она сюда подходит... Не забывать, что разница между «трачу на работу 50-70% времени» и «выполняю работу за 50-70% времени» существенная!!! Рефлексия! Ни в коем случае не забрасывать – очень мощный инструмент совершенствования себя и своих процессов... На проекте после выполнения задания решили уйти от генерации исключений в невалидных стейтах в пользу игнора ошибки и отправки специального события в аналитику. И не стоит забывать, что большое количество исключений могут быть заменены добавлением строгой системы типов... При выполнении очередного задания по Hard Work писал много кода на ассемблере. Заметил, что для меня это то самое программирование, которое привлекло ещё в школе. Глобальное состояние, императивный код, спагетти из goto jmp... Романтика. Видимо с тех пор у меня в голове сидит идея о том, что ядром программы является последовательность команд. В случае с GUI - это главный цикл приложения, которы обрабатывает системные сообщения. Но ведь это не так! Цикл - это технические детали, которые у всех программ более или менее одинаковы в рамках платформы/фреймворка, а основная логика вовсе не там. Отсюда и погружение в технические детали, много размышлений об ECS (который в итоге может и не понадобится). Это всё из-за глубокого внутреннего ложного убеждения, что тут находится главная часть приложения. Так вот почему лучше начинать изучения программирования с ФП! :) Теперь над каждой задачей буду принудительно думать сначала в терминах ФП, чтобы заменить вредную привычку полезной...

Люди не покупают программное обеспечение, они нанимают сервис. Вас не волнуют Word, Телеграм или Эксель, вы просто хотите писать о том, что у вас на уме, делиться этим с другими, делать полезные таблички со статистикой. И вам определённо всё равно, как взаимодействуют терминал платёжной сети и ваш банк, вы просто хотите, чтобы запасов вашего любимого кофе по 700 рублей хватило на неделю. Хорошее программное обеспечение невидимо. А это требует работы. Очень большой работы. Потому что первые 90% работающего прототипа получить несложно. Важны остальные 190%. И кодинга в этой работе от силы 10%. Подпишете ли вы юридически обязывающую гарантию, что ваше программное обеспечение будет работать так, как вы обещаете?