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 твоих техлидских/архитекторских скиллов )))

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

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

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

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

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

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

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

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

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

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

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

=

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

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

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

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

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

Кто кто?

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

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

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

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

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

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

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

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

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

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

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