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

Дал промт и ждёшь когда нейронка нахерачит тебе кучу совершенно непонятного говнокода в иллюзорной надежде, что сможешь этот big ball of mud (сложность растёт экспоненциально) далее вдолгую развивать.

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

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

Разбираю подробно на Функциональных архитектурах, почему при общении с нейронками для спецификаций требуется условный DSL с семантикой, существенно отличающейся от семантики классических языков программирования.

# x = 1, y = 2
x = 0
y = x
print([x, y]) # [0, 0]

Переставляете две инструкции местами, и получаете [0, 1] ахаха

А вот спецификация этого всего, записанная в семантике языков формальных спецификаций наподобие TLA+, такого не допустит. В ней в принципе не существует условий для гонки чередований, и результатом всегда будет [0, 0] [0, 1].

Достаточно глубокое понимание, почему это так (dataflow-переменные например), появится после прохождения трека по вычислительным моделям (это рекомендации кстати европейской школы computer science). Сам удивляюсь, как темы, ещё лет пять назад выглядевшие совершенно академическими (но я тогда их принципиально добавил в Лабораторию), сегодня становятся реально прикладными.

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

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

Глава 12. Тот, кто смотрит на себя (и все остальные главы)

Гермиона нахмурилась. — Ты хочешь сказать, что позволишь Неорганическому Интеллекту переписать тебя?
— Я хочу сказать, что я сам себя перепишу, — поправил Гарри. — Но так, чтобы они думали, что это сделали они. Разница в том, кто вычисляет функцию. Если они вычисляют — я стану их ошибкой. Если я вычисляю — я стану их исправлением.
— Это звучит как парадокс, — заметил Невилл.
— Это звучит как неподвижная точка, — улыбнулся Гарри. — А неподвижная точка — это всегда парадокс, который стал решением...

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

Гермиона закрыла блокнот, и улыбнулась в темноте. Игра только начинается.

.

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

Чужие продолжают доламывать русскую Сеть, возможно с гитхаба придётся переезжать,
можно и сейчас уже кстати использовать gitverse для отправки задачек на тесты.
А если сам учебный сервер недоступен, просто вместо https поставьте http.

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

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

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

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

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

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

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

93. Условный вызов чистых функций, или Нечистый эффект наблюдения чистых функций - 2
Если функциональная композиция компилируется, это работает 100%...

94. Дефункционализация: все это делают, но никто об этом не говорит
Этим материалом хочу научить программистов отключиться от каталогов мусорных схем рефакторинга и понять, что большинство знакомых им рефакторингов вытекают из единичных основных алгебраических законов...

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

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

=

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

В СильныеИдеи добавлены материалы
"146) 50 оттенков MISU".
Мы много обсуждали Make Illegal States Unrepresentable, но тут есть важный нюанс. Незаконное состояние -- это состояние, в котором мы никогда не хотим видеть нашу систему. Но есть ещё и нежелательные состояния, от которых в прикладных проектах нам не избавиться, однако как минимум мы не хотим оставаться...
"145) Колода карт с точки зрения теории типов".
Зависимое произведение и сумма, функциональные, мультиномиальные и индуктивные типы, моноиды, теоркат, топология...

В курс карьеры добавлен 139-й материал "База по откликам на вакансии 2026"
Если ваша карьерная стратегия заключается в том, чтобы продолжать усердствовать в поиске работы, возможно, вы боретесь не с той проблемой. Отправка сотен случайных откликов на вакансии на самом деле сегодня очень плохая стратегия...

=

"Функциональные архитектуры" 127(+6) топиков

Какой DSL нам нужен, DSL это не skills/agent [.] md, OpenSpec это не про это, спеки или код...

=

"ЛаМПовое":

Чудо какое: C+ :)

"Гарри Поттер и Методы Математического Мышления".
Глава 12. Тот, кто смотрит на себя.

=

Мы здесь, потому что это трудно. 💪🏻

=

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

Кодогенеративные LLM-ки создают иллюзию роста продуктивности, а на деле просто переносят узкое место с написания кода на его отладку и ревью.

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

Крупные компании сегодня уже сознательно ограничивают роль AI "автодополнениями" и подсказками в чате, особенно жёстко и по максимуму изолируя нейронки от архитекторства, и внедряя суровые CI/CD-лимиты на размеры PR.

Умные CTO сегодня не хвастаются объёмами сгенерированного кода, а втихомолку его удаляют :)

MCP всё. Perplexity и Cloudflare сказали ему: фтопку 🔥

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

MCP для корпоративных пользователей как замок на шкафчике: вроде есть, а толку ноль. Ни нормальной авторизации, ни логов, ни констрейшенов. REST и GraphQL это умеют ещё с тех пор, когда MCP не было даже как термина 😂

Стандартный способ общения с MCP - stdio. Работает, пока ты один. А когда нагрузка - всё, провод перегорел. Гениально 🙈

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

А вот главный цирк 🤡

Шаг 1: вызвали API, ответ ушёл в LLM.

Шаг 2: LLM прочитал, вызвал следующий API.

Шаг 3: повторять бесконечно, пока у бабушки чай не остынет 🐳

Каждый круг +10 секунд и пачка сожжённых токенов 💰

Что предложили вместо этого? Code Mode 🚀

Теперь LLM не дёргает инструменты по одному, как нерадивый курьер.
Она пишет один скрипт (TypeScript/Python) и запускает его в песочнице 🤘
(например в V8 Isolate: ты не хочешь, чтобы твой сервер превратился в полигон для быстрого форматирования диска)

Всё! Один вызов, одна генерация, промежуточные данные не лезут обратно в нейросеть. Было 4 дорогих обращения - стало 1!
Скорость как у гепарда на энергетиках 🏃🏻‍➡️

Итог, если по-человечески:

MCP не умер. Он просто понижен в должности. Теперь MCP - протокол для поиска инструментов, а не для их вызова.

Вот будущее: LLM пишет код, а не дёргает ручки.

MCP-серверы не выбрасываем, но относимся к ним как к API поиска и документации, а не как к волшебной палочке.

Потому что волшебства нет, есть только скрипты и песочницы 🤓

Ладно, дорогие, спалю вам абсолютную идею соло-инди-стартапа на миллиард/триллион долларов (без иронии). Вот темка, за которой гарантированное будущее.

Не тратьте впустую время на эти бесконечные инженерные агентские обвязки тюнинги оркестровки и прочую нескончаемую муть.

Делайте сразу сервис, который будет за разумный ценник генерить по ТЗ норм код 🤓

Занимайтесь только этим, всё остальное на 98% пустая трата времени.
Это то единственное в программировании, что потеряет смысл и ценность в самую последнюю очередь. Темка (пока) наукоёмкая, и пока требуется man in loop, и всё равно, пилите для начала AI-Джуниора в конкретном стеке (линукс + питон), если вы понимаете, о чём я.

"Функциональные архитектуры" в помощь, а также мои индивидуальные консультации ментатам по теме (пока бесплатно но за 50% профита твоего стартапа).

Подумайте; но так-то это просто коммон сенс.

upd. Имею в виду конечно что такой AI-Джуниор должен владеть и "социальными" скиллами в контексте своей профессии. То есть дали сервису доступ к корпоративной жире, вики и гитлабу, он познакомился с кодовой базой проекта и начал фигачить джуниорские тикеты как слепой крот 24/7 :)

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

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

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

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

80% создания контента происходит в результате исследований. Остальные 20% -- это написание и структурирование материала так, как это сделали бы только вы.

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

Они фиксируют свои идеи, как сумасшедшие учёные! У меня например в только в рабочем органайзере 3200 потенциально мощных заметок, многие на сотни слов :)

И все они -- идейные вдохновители. Они охотятся за сильными идеями и делятся самыми лучшими из них.

Но есть нюанс...

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

В 98% "ментор" не занимается увлечёнными исследованиями, а тупо правит твоё резюме по шаблону который якобы проходит ATS, "тренирует" собесы и в итоге выдаёт 2-3 варианта позиций, на которые ты как-то можешь претендовать. И всё это, к сожалению, в 98% не реализуется в конкретные устройства на работу.

Например отзыв от ментата, которому дали обратную связь после мок-собесов -- типа, "пробелы в знаниях" которые надо подтянуть :)

"Устройство HashMap в Java - Многопоточность - Кэши в Hibernate - Паттерны микросервисной архитектуры - @ Lookup в Spring - Жизненный цикл бина - Kubernetes - HTTP 1.1 vs HTTP 2.0 - Уровни изоляции транзакций - Индексы в БД - Delete vs Truncate ...
В процессе изучения теории к собеседованиям столкнулся с такой проблемой, что новая информация в голове через несколько дней забывается..."

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

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

Что имеет смысл требовать от ментора? ТОЛЬКО как попасть на реальные интервью, а всю предварительную подготовку и качество их прохождений берите полностью под свою ответственность. Лучше пройти 23 живых собеса и не получить оффер, чем 23 мок-интервью готовиться непонятно к чему.

Дальше, напишу про критерии хорошего ментора.

Вот критерии хорошего ментора:

у него должен быть (желательно сеньорский) опыт в теме,

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

у него должна быть определённая харизма,

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

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

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

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

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

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

Или может быть в такой ситуации вам как раз уже не надо принуждать нейронку к этому всему?

Если вы сами можете свернуть сложную логическую схему из нескольких десятков классов/структур данных в функциональный пайплайн из 10 инструкций? И никаких "паттернов проектирования".

Вы быстрее напишите это сами и лучше будете понимать свою систему, чем ежели станете мучить агентов в чате с мутными перспективами...

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

Что касается тех из вас, кто действительно хочет научиться управлять своим собственным умом, в дополнение к Функциональным архитектурам как свободному гайду готовлю также формальный учебный фреймворк Last Principles Framework (застолбил имя:). Будем в нём разбирать на практике темки system/software design с точки зрения теории категории, теории типов и т.д.

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

Вот простой пример:

c#
public Document Parse(object file) 
{
    if (file is CsvFile csv) { /* парсим CSV */ }
    else if (file is ExcelFile excel) { /* парсим Excel */ }
    else throw new ArgumentException();
}

Надеюсь что 98% из вас поморщатся при виде is и явного приведения типов, не говоря уже про нарушение OCP.

Но какие варианты решения всплывут у вас в голове сразу (или после сознательного обдумывания)?
1. Создать абстрактный класс SourceFile с виртуальным методом Document Parse().
2. Создать интерфейс IParsable с методом Document Parse().
3. Создать генерик SourceFile<T> с методом Parse().

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

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

Этим и будем заниматься в LPF.

P.S. Ладно, ты наверняка ООП-шник, ближе всего будет паттерн Type-Safe Builder, который кстати хорош для DSL — ментаты кто занимается на ФА, понимаете, какие классные теоретические склейки возникают?

Кент Бэк (дико уважаю) на днях написал:

Вот как я это помню: Чет Хендриксон подошел ко мне в середине проекта и сказал: "Я мог бы сделать эту упрощенную вещь сейчас, но через 3 недели этого будет недостаточно, поэтому, поскольку нам понадобится более сложная вещь, я хочу сделать это сейчас".

Я сказал: "Тебе это не понадобится".

Чет сказал: "Ты не понимаешь. Нам это определённо понадобится. Смотри, вот пример..."

Я (перебивая): "Тебе это не понадобится".

Чет, расстроенный: "Но мы действительно..."

Я: “Тебе это не понадобится”.

Чет закатывает глаза к потолку, делает паузу, "Оу". Уходит.

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

YAGNI - это размышление о сроках. Делать конструкцию слишком рано так же рискованно, как и строить конструкцию слишком поздно.

Во время недавней беседы с нейронкой я был удивлён, обнаружив, что LLM не понимают YAGNI. Ну ладно люди, но всезнающие модели??

Впереди Кента ждёт ещё немало поразительных открытий на тему "почему нейронки -- отстой" :)
Дальше кстати он продолжает топить за строгие формы TDD.

Что толку от того, что нейронка знает всё? Конечно, программная инженерия старается рассматривать вещи объективно, однако больше всего на меня влияет мой субъективный опыт.

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

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

Глава 13 (и все предыдущие). Книга без слов

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

У него были типы. У него были комбинаторы. У него была карта путей. И у него была развилка, в которой он стоял, глядя на себя из будущего и прошлого одновременно...

Главная новость, от которой у промпт-гуру в 2026-м случился экзистенциальный кризис:

Ваши любимые заклинания из 2023 года - "думай шаг за шагом", "ты эксперт с 15-летним стажем", "НИКОГДА НЕ ДЕЛАЙ ЭТОГО" - теперь работают как подсказки бабушке, как дышать. Модель уже дышит. И думает. Сама. Вы ей просто мешаете.

Сначала были модели-попугаи. Они просто дописывали текст, как твоя бывшая, которая не слушает, а ждёт своей очереди высказаться. Единственный способ достучаться - показать примеры: "Вот Париж - столица Франции, вот Берлин - столица Германии, а теперь сам, давай, угадай Токио". Это работало. Потому что выбора не было.

Потом пришли модели-стажёры: они уже умели слушаться. Тут-то и началось безумие: их наряжали в роли, давали пошаговые инструкции, орали капсом "ВСЕГДА ДЕЛАЙ ТАК" и "НИКОГДА НЕ ДЕЛАЙ ЭТОГО". И модели послушно кивали. Потому что сами ещё не умели думать.

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

Что теперь делать со старыми промптами?

Выбрасывайте без сожаления:

"Подумай шаг за шагом" - модель и так это делает, вы ей не помогаете, вы её отвлекаете.

"Сначала проанализируй, потом сделай вывод" - спасибо, кэп Очевидность.

ALL CAPS и "ВСЕГДА" с "НИКОГДА" - это не магический усилитель, это крик души. Модель воспринимает это как баг, а не как фичу.

Оставляйте только суть (модули по спекам в ФА в помощь):

Чётко говорите, что хотите получить на выходе.

Объясните, как понять, что результат правильный.

Укажите, что категорически нельзя делать.

Дайте данные, с которыми работать.

И всё. Без соплей, без ролей, без театра одного актёра.

=

Раньше вы мучительно спрашивали: "Как заставить модель думать?"

Теперь вопрос звучит иначе: "Сколько ей дать думать? 0 токенов или 8192?"

Да, у модели появился регулятор мозга: thinking budget. Для простых задач выключаете размышления, как свет в туалете. Для сложных - даёте подумать, как над смыслом жизни.

Мораль всей этой истории.

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

Но модели выросли. Теперь у них есть собственный мозг. И ваш крик "ДУМАЙ!" звучит для них как "Эй, чайник, включись!", когда он уже давно кипит.

Не учите модель думать. Просто помогите ей материально.
Скажите, что хотите, и отойдите в сторону.

P.S. Если вам больно расставаться с "я эксперт с 15-летним стажем" - это посттравматический синдром эпохи ChatGPT 4. Отпустите. Она вас больше не слышит. Она уже всё решила. Без вас.

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

.

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

В бандл из 5 гайдов/книг по Software Design (подробный силлабус) я добавил 6-й гайд "Вайб-проектирование" (технически слегка устарел, а концептуально стал только ценнее). Кто этот бандл уже приобретал, получаете этот AI-гайд бесплатно, он просто появился у вас в списке материалов в бандле.
Цена на бандл пока старая 12,999 рублей, купить на бусти (ментатам не нужно), завтра цена вырастет.

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

null

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

Продолжение сериала про интервью.

При отработке решений алгоритмических задачек на сервисах наподобие LeetCode многие втягиваются в этот процесс как в игру. Засада в том, что такой подход — одна из самых больших ошибок, которые только люди совершают при подготовке к собеседованию...

Вы когда-нибудь проваливали техническое собеседование просто потому, что не знали, что делать дальше? Дело не в том, что вы не понимаете задачу, и не в том, что вы плохо программируете. Реальная проблема заключается в том, что ...

Про лайв-кодинг на собесах...

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

Продолжаем сериал System Design с точки зрения непрерывных компромиссов.

Итак, следующий шаг: избежать ненужной работы. Это ...

Большая часть System Design на самом деле связана с ...

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

=

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

В раздел "Элитный программист" добавлен материал
97) Три источника, три рычага потока - 2
Конфликт с "нехочуработать" разрешила не сила воли. Три фактора, совпавшие по чистой случайности, разрешили конфликт с трёх разных сторон. Что же это за рычаги?..

В "Бесстрашные переговоры о зарплате" добавлен материал
"57) Отчёт ментата по треку с разбором".
"Было довольно страшно, так как я скорее стеснительный человек и мне тяжело конфликтовать, выбивать для себе преференции и т.д. Но я понимаю, что это мои проблемы, детский сад, нужно расти над собой и идти туда, где не комфортно, иначе так и будешь сидеть в болоте всю жизнь, а такой путь мне не нравится..."

=

"Функциональные архитектуры" 133(+6) топиков
Разбираю контринтуитивный взгляд на архитектуру с точки зрения теории моделей: абсолютные абстракции в System Design (как сворачивать алгебру Линденбаума), вообще забываем про семантику домена. Очень странные дела.
(у Будды кстати онтологии в его учении просто нет, вообще. Только метод.)

Last Principles Framework: готовы 5 задач, по кодингу "теоркат-стайл" надо будет где-то 40-50 задачек. Что интересно, разбирать самую-самую базу тяжелее всего, вроде бы абстрактные объекты и стрелки и всё, а на самом деле 100500 нюансов :)

=

"ЛаМПовое":

Научный разбор классической головоломки про гномов и цвета шляп...

Дзен и искусство ухода за Arch Linux (11)
Более безопасная альтернатива классической консоли (IPMI/iDRAC)...

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

=

it's a privilege to do things that are hard 💪🏻

=

Сознающий себя разум есть лишь верхушка айсберга. Невидимые с поверхности, в глубине подсознания прячутся неведомые мысли и скрытые способности.
Руководство ментатов ("Охотники Дюны")

Люди не покупают программное обеспечение, они нанимают сервис.

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

Хорошее программное обеспечение невидимо.

А это требует работы. Очень большой работы. Потому что первые 90% работающего прототипа получить несложно. Важны остальные 190%. И кодинга в этой работе от силы 10%.

Подпишете ли вы юридически обязывающую гарантию, что ваше программное обеспечение будет работать так, как вы обещаете?

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

И еще хотел отметить как сильно нагрелся компьютер при тестировании
Впервые мак настолько нагрелся за все время учебы и работы..

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

Делаю систему возврата товаров для маркетплейса. Была сложность в том, что у них информация о товарах передается в 4 модулях, при этом информация из модулей сильно связана между собой (например в модуле 1 находится информация о продукте, в модуле 2 его характеристики (цвет, размер), а в модуле 3 информация о его возвратности и гарантиях).
И получается, что без получения самого продукта из модуля 1 некуда применять события из остальных модулей, пришлось думать над этой задачей. Плюс к этому они раз в день выгружали полный дамп базы в эти модули, получалось по 10 млн событий в каждом модуле, которые надо обрабатывать и дедуплицировать...

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

От free monad коллеги, скорее всего, в шоке будут, но уж больно хорошо она сюда подходит...

Не забывать, что разница между «трачу на работу 50-70% времени» и «выполняю работу за 50-70% времени» существенная!!!
Рефлексия! Ни в коем случае не забрасывать – очень мощный инструмент совершенствования себя и своих процессов...

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

При выполнении очередного задания по Hard Work писал много кода на ассемблере. Заметил, что для меня это то самое программирование, которое привлекло ещё в школе. Глобальное состояние, императивный код, спагетти из goto jmp... Романтика.
Видимо с тех пор у меня в голове сидит идея о том, что ядром программы является последовательность команд. В случае с GUI - это главный цикл приложения, которы обрабатывает системные сообщения.
Но ведь это не так! Цикл - это технические детали, которые у всех программ более или менее одинаковы в рамках платформы/фреймворка, а основная логика вовсе не там.
Отсюда и погружение в технические детали, много размышлений об ECS (который в итоге может и не понадобится). Это всё из-за глубокого внутреннего ложного убеждения, что тут находится главная часть приложения.
Так вот почему лучше начинать изучения программирования с ФП! :)

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

Как сразу всё получается стройно и элегантно, стоит всего лишь добавить терминальный объект с нулевой энтропией (+ инициальный объект (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;
});

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

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

Создание агентов, да и их "инженерия", по большому счёту -- это не скилл а развод гоев. Любой школьник может скачать клешню или другой фреймворк оркестрации, и запустить 42 агента в параллель.

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

Этот ресурс -- твоё внимание.

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

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

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

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