Главная новость, от которой у промпт-гуру в 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 разрешён. И ты не можешь отменить мой ход, потому что он уже сделан...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

.

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

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

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

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


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

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

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

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

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

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

=

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

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

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

=

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

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

=

"ЛаМПовое":

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

=

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

=

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

=

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