Альтернативные издержки работы на себя составляют миллионы рублей.
Альтернативные издержки работы в компании/на дядю составляют десятки миллионов рублей.
Выбирайте с умом.

Вот куда сегодня активно идёт мэйнстрим: все делают агентов сложнее.
Больше инструментов, больше памяти, больше координации, больше токенов...

Вот например свежая реклама:

"Вы научитесь строить ReAct-циклы, работать с LangGraph и AutoGen, внедрять продвинутый RAG, протоколы MCP и AgentOps. Все ключевые навыки в одном месте: измеримость систем, time-travel дебаггинг, управление браузером, human-in-the-loop и развёртывание в закрытых контурах."
Курс такой стоит 90(!) тысяч рублей. Ничего не хочу сказать, это всё конечно знать надо, и польза определённая будет.
Но по сути это про чистые технологии, и по большому счёту про текст, про текстовое взаимодействие.

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

В чём засада?

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

И если просто в лоб пытаться ей зафигачить какие-то руководства из computer science, толку никакого не будет.

Пишем в skills требование соблюдать инварианты типов - нейронка их не проверяет при рефакторинге.
Задаём законы (монады, функторы) - нейронка при формировании структуры их нарушает.
Напоминаем про когерентность - нейронка теряет её между файлами/сессиями.
Пытаемся использовать зависимые типы - нейронка уже симулирует, не понимает.
Добавляем доказательства уровня кубической теории типов например - нейронка галлюцинирует "очевидные" шаги.

А что бы это всё заработало, надо готовить компактный формальный DSL, специфичный для домена, и с тщательно подобранной грамматикой - как инструкция для LLM. Но зато полностью избавляемся от промптов и агентов!

DSL тут выступает как (почти) гарантированно работающий протокол общения с LLM вместо агентской архитектуры.

Всё это буду пояснять и показывать в рамках гайда "Функциональные архитектуры".

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

.

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

"Функциональное Проектирование" дополнено второй частью: реализуем проект дополнительно в многослойной архитектуре, причём весь код будет писать нейронка. Попутно коснёмся важной темы языков предметной области (DSL). Допройти можно бесплатно.

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

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

8 базовых фактов о рынке ИТ-труда в 2026-м, и что из этого следует. Часть 2
6. Фильтр высокой квалификации.
Я постоянно слышу от ит-менеджеров, и даже основателей стартапов:
"У меня есть деньги, но я не могу найти способных людей".
Звучит безумно, не так ли? Когда так много безработных программистов?..

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

База по карьере, серия 24.
...И в качестве глазури на этом дерьмовом пирожном — помимо того, что оно подталкивает нас стремиться к вещам, которых мы на самом деле не хотим, отрицать желания, которые мы испытываем в глубине души, бояться того, что не опасно, и верить в то, что не соответствует действительности — общепринятая "мудрость" во всеуслышание заявляет нам, что "карьера это туннель", вместо того, чтобы помочь нам избавиться от этого дерьма...

Позвольте мне на минутку поговорить с вами как с профессиональными разработчиками. Если вам 20-30 лет, и вы действительно хотите преуспеть в ИТ, то одна из важнейших вещей, которая определяет ваш результат — это не искусственный интеллект, не быстрые технологические фишки, и не модные в этом месяце фреймворки.
Всё сводится к тому, сможете ли вы...

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

А зачем человеку уровень PhD, если в плане карьеры уровень FAANG куда перспективнее во всех отношениях?

Продолжаю выкладывать для донов материалы СильныхИдей.
77. Функциональная архитектура - что это?
Давайте более глубоко погрузимся в тему функционального проектирования, для чего однако предварительно надо разобраться, а знаете ли вы, что такое функциональное программирование?
Да, например, те кто у меня занимается, получили базовое теоретическое представление из "Основ ФП", а затем полноценно попрактиковались в функциональном стиле на функциональном языке F#. Но даже если вы пишете на Хаскеле, можно ли сказать, что ваш код действительно функционален?

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


=

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

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

В СильныеИдеи добавлен материал "135) Моделирование времени в ФП".
В данном контексте мы постоянно упоминаем Haskell как единственный по сути более-менее массовый язык, подходящий для этого. Это не значит, что вы должны переходить на него: наша задача встроить в голову соответствующую думательную машинку...

💪🏻

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

=

"ЛаМПовое": rust в духе си, формализация хаскелевского ghc, анти-macos, база по резюме-26, coq как макроассемблер.

Но переходить в Макс совершенно не планирую: это ещё больший зашквар чем принять FanID. Как в апреле забанят Телеграм, так Лаборатория закроется.

- Вы видели, как китайские роботы прыгают, кувыркаются? А мы так можем?
- А мы можем заблокировать видео с этими роботами.

Гайд про функциональные архитектуры, 55 топиков (+2), как наберётся 64, дам ментатам доступ. Мои ближайшие планы на эту весну планирую реализовать в первом приближении в рамках этого гайда.

=

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

Кстати темку DSL я изучал ещё почти лет 20 назад, где-то ещё заметки сохранились, как только вышли соответствующие работы Алана Кэя по тысячекратной компактности кода. Потом, в частности, купил книгу Фаулера "DSL", игрался с JetBrains Meta Programming System (создай свой собственный предметно-ориентированный язык), вчера посмотрел, а она жива! Синхронизм - там на форуме по теме буквально 10 дней назад было обсуждение в контексте использования AI + DSL. Не удивлюсь, если тут именно жб сделает что-то продвинутое.

Кстати, в 2013-м я ездил по приглашению в Питер, в гости к Олегу Степанову, CEO JetBrains на тот момент, где-то ещё интервью с ним лежит в сети, и сходил на несколько их семинаров -- как раз по MPS, а также по гомотопической теории типов, после чего этими темками отдельно увлёкся.
Их тематическая лаборатория по HoTT ещё работает, я и не знал, оказывается теорем-прувер Arend -- это их работа.

Кстати, когда жб массово отчалили, я к этому относился сильно негативно, но в последние месяцы думаю: а может быть правы были они, а я ошибался? Ну когда уже совсем скоро пропадёт даже потенциальная возможность читать даже через впн западных топовых математиков и святых computer science в твиттере, тг, потом забанят сабстек и гитхаб... Ну, да, тор какое-то время поработает еле-еле...

И всё как есть, похоже на обман,
Где я вот-вот проснусь...
А на душе снегами лёг туман --
Незаживающая грусть...
"Алиса"

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

Код сейчас пишется быстро, большие объёмы за минуты, и если ещё вчера типичный программист мог весь день одним пальчиком кодировать типовые рабочие задачки на быстром мышлении S1, на автомате/интуиции, мозг по сути не напрягая, уже прокаченным скиллом, то теперь от него требуются, как уже говорил, навыки сеньорские архитекторские техдирские системно-аналитические. Разница по сути (пока) только в масштабе. Ну и так как эти навыки подразумевают уже в первую очередь необходимость принятия решений в нечёткой и неполной среде, едва ли не весь день разработчику приходится включать в голове на полную медленную сеть S2.

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

Ну как бы думать интенсивно каждый день по 8-10 часов, и так без пауз неделями и годами, думаю, вообще никому не под силу, и нас ждёт эпическая волна выгораний в айтишке. В таком формате даже сильные сеньоры способны продуктивно работать только короткими блоками по 1-2 часа - один или изредка два раза в день, даже при большой практике. Максимум 3-4 часа, после чего разработческая активность становится контрпродуктивной и начинает только вредить (например, вносятся трудно находимые баги).

Раньше у нас был объективный предел: скорость набора текста, скорость мышления и время, требуемое для поиска информации. Теперь же этот предел ликвидирован, и рабочие дни программистов быстро становятся всё тяжелее. Не легче: тяжелее.

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

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

Меня в этой ситуации поражает, что на его сервис активно подписываются не только отдельные разработчики, но и компании! Это на каком же дне должны быть рабочие процессы, и каким же дебилом должен быть CTO, если они не могут в свои ci/cd впихнуть за пару часов агента с шаблонным скиллом ревью кода.

Пользователь запрашивает отчёт, твой API ставит задание в очередь, worker генерирует PDF-файл.

Это pub/sub или очередь с воркерами?

(пауза)

Мнения в команде наверняка разделятся, и это будет похоже на спор о терминологии.

Но это не так.

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

Смешное: мэйнстрим открывает для себя функциональное программирование =>

Sinks, Not Pipes: Software Architecture in the Age of AI

Пока на уровне "оркестрация синков" вместо "композиция чистых функций", ну ок, постепенно разберутся :)

Понимаю и кривизну понимания темы как следствие ООП -- например про зависимости в интерфейсах... Засада в том, что зависимости нечисты систематически (подсказка: юзайте свободную монаду + AST), а по каждому интерфейсу задавайте вопрос: почему вообще он потребовался? как вы собираетесь его использовать? Паттерн Стратегия? Ок, но а зачем ещё-то?
Рекомендую в частности вместо интерфейсов с одним методом использовать делегаты/лямбда-функции.

Всё это подробно разбираем с примерами уже скоро в гайде "Функциональные архитектуры".

...В следующий раз, когда кто-то из вашей команды заявит, что вам не нужна DI, потому что например в качестве СУБД мы решили навсегда взять Постгрес, вы можете сказать им, что это не имеет значения. Выбор в ООП стоит между DI и говно/спагетти-кодом.

Я кстати нашёл язык, минимально из мэйнстрима, который идеально подходит в качестве протокола общения с LLM-ками.

Это ЛИСП! )))

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

Ну я подскочил и резко въехал ему в щщи с вертушки и пояснил криком "не люблю ооп", потому что я угорел по лиспу, пацаны дух старой школы живёт только в функциональном программировании, где угорают по хардкору, где пацаны живут линейными символами и хвостовой рекурсией! только лисп только функции, только скобки!!! юнити ультрахардкор лисп!!! пацаны угарайте по рекурсии любите лисп, списки и скобки! говорите открыто и смело прямо в лицо! ЛИСП!

Точнее, сегодня это Racket (потомок Scheme).
Чистый АланКеевский путь - язык описывает сам себя.

(define-language my-domain
    (agent (knows abstractions) (does task)))

Плюс: это буквально родной инструмент для создания DSL.
Минус: далековат от прода, хотя... Поддерживают Racket финансово NSF, DARPA и др.

Racket is a language for making languages, so that a programmer can write every module in a well-suited language.
Often an application domain comes with several languages. When you need a new language, you make it - on the fly. Open an IDE window; create a language right there, with just a few keystrokes; and run a module in this new language in a second IDE window. Making new languages really requires no setup, no project files, no external tools, no nothing.

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

Красивое: GlimpseOfLean : an introduction to theorem proving in Lean for the impatient.

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

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

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

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

p.s. Забыл, в их последнем деплое закомментите
import Mathlib.Data.Complex.Trigonometric

У нас уже и были, и остаются огромные проблемы с объёмом легаси-кода, который существовал, когда его писали люди. Почему мы думаем, что ускорение этого процесса будет улучшением?? )))
Откуда мы знаем, что терабайты вайб-кода вообще работают?

Наиболее распространённый ответ: я просмотрел код, прогнал тесты, и все в порядке.

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

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

(В целом странно конечно, что умение хорошо просматривать код теперь гораздо более ценно, чем умение хорошо писать код.)

TDD? Да, это мощная штука, близкая к формальным спецификациям, если ей следовать вдумчиво, но как вы проверите, что агент действительно этому следует? На уровне агентов это чистый карго-культ. Агент заявит, что якобы тестирует систему, и даже следует базе "красный-зелёный-рефакторинг", но откуда вы знаете, что это не симуляция? Что это, весьма вероятно, программа, которая только выглядит так, как будто она проходит все тесты, но на самом деле не имеет отношения к реальным требованиям?

Вместо того, чтобы самому/агентами писать код в прод, и затем просить нейронку покрыть это всё тестами, почему бы не написать сперва тесты, и только потом не попросить агентов реализовать их?

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

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

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

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

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

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

Фигня этот ваш жпт5.4.

Попросил его написать скрипт на питоне где-то на 500 строк, причём вся логика линейная, просто надо условно говоря давать агентам те или иные инструкции в зависимости от десятка счётчиков. Так он начал концептуально тупить уже на первых 50 строках, кое-как вроде что-то собрал, где-то час я на общение с ним потратил, а как стал тестировать, и оказалось, что он так всё напутал со счётчиками, что надо вообще всё переделывать заново с нуля, а если делать точечные фиксы, то он сразу превращает всё в little ball of mud. А внимательный джун сделал бы, ну пусть за 4 часа, но как минимум чтобы всё работало по тикету.

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

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

5 задач ужасающей сложности оказались правда ужасающими сложными для меня. С такой сложной схемой БД, где более 50 таблиц, мне работать не приходилось. И задачи правда оказались невероятно сложными с требованием сложной аналитики. Обычно в работе сталкиваюсь с БД до 10-15 таблиц, а то и меньше.
Очень сложно (практически невозможно) выполнять такую работу с незнакомыми для тебя сущностями. Я привык к продажам, остаткам, логистике, БД различных пользовательских сервисов. С играми я никогда не работал. И продумывать аналитику влияния погоды на атаки или влияние лунной фазы на что-то невероятно сложно. И все это без боевых данных...

Получили трёхкратную разницу. Я не ожидал, что hibernate будет тащить так много лишних данных. В изначальном варианте с orm было очень много джоинов. Кажется это связано с тем, что сущности тесно связаны друг с другом и такая длинная цепочка джоинов является попыткой распутать клубок связей. Однако данные, которые достаются с помощью такого объёмного запроса нам не нужны и эти длинные запросы избыточны...

Однажды я полагал, что в одном из методов данные выдаются в упорядоченном виде, ну и закладывался на такое поведение. Потом выяснилось, что во время проверок так складывались звёзды и данные выдавались по возрастанию id...

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

Тесты не спасают от всех багов — только от тех, на которые ты догадался написать проверку.
Например, что должен вернуть метод CalculateAverage для массива { 1, 2 } — 1 или 1.5? Если такой тест не написан,
баг может жить в коде годами, пока кто-нибудь не столкнётся с ним в продакшене...

Если честно, то я не задумывался о таких мелочах. Теперь понимаю, насколько это было недальновидно. Особенно мне казалось использование словаря в подобных случаях избыточным. Теперь вижу, что result['fresh_messages'] намного понятнее, чем fresh, old = some_function(). Не нужно держать в голове порядок возвращаемых элементов.
На будущее:
Нужно регулярно задавать себе вопрос: "А не скрыта ли здесь логическая связь?"
Чаще использовать словарь вместо кортежа...

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

Затем я попытался достичь 10k RPS создав 10 тысяч пользователей(хотя для такого rps это, как будто, много). Но прогон завершился с ошибками и я даже не получил отчёт. Ещё впервые за долгое время услышал как мак гудит вентиляторами :)

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

Чувствую, что надо переходить к AI-темкам, так как бизнес хочет вокруг AI строить все решения.
...В этом проекте я вообще максимально долго пытался сохранить монолит, но так как приходит вторая большая команда, то придется делить его как минимум на 2 (микро)сервиса, чтобы команды не толкались в одной кодовой базе...

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

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

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

И у кода, и у худ.текста очень много общего, причем как in small, так и in large. Я за свою жизнь прочитал немалые тысячи книг (и продолжаю активно), из них немало по лингвистике и литературоведению (у нас в редакции в 90-е работали суровые литературные редакторы советской школы), и на лит.курсах занимался, и вот теперь хочу в заключение немного поэкспериментировать в смежной сфере.

Книги пишутся обычно по двум схемам.

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

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

=

И так как я совершенно бесталанный в художественном плане, то хочу довести до идеала инженерный подход. Ведь "проектирование" книги in large -- это по сути процесс, изоморфный проектированию системы, разве что менее формальный. А нейронки сегодня пишут код художественный текст вот точно уже лучше 98% не только литературных негров, но профессиональных авторов — на уровне хорошего PhD.

То есть и тут на первый план, как и в IT, выходят скиллы "техлида": качественные замысел, сюжет, драматургия, умение зацепить/увлечь, примерно как и в геймдеве кстати. Ну и стиль/in small самого текста конечно важен (как картинка в игре).

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

.

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

В отчётах по карьере теперь обязательно пояснять, как вы используете AI в своей работе (если не знаете как, я подскажу).

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

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

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

С вероятностью 98% обучение теме искусственного интеллекта с обещаниями научить на этом зарабатывать, получить новую профессию — классическая схема мошенничества. И вот почему...

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

Продолжаю выкладывать для донов материалы СильныхИдей — доступны моим курсантам, но тут расширенные и дополненные версии.
78. Микросервисы должны умереть
Никто из крупных компаний не начинал с микросервисов. Никто не загружался с помощью service mesh. Они начинали с простого. Они развивались осознанно и эволюционно. Они масштабировались, когда к этому вынуждала реальность, а не хайп на конференции.
И после многих лет наблюдения за тем, как компании масштабируются и перестраиваются, вот что сегодня выделяют гуру программной инженерии:
только три модели архитектуры стабильно работают в условиях реального роста...

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


=

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

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

В СильныеИдеи добавлен материал "136) SOLID26: LSP".
Единственный в SOLID хороший принцип :) И теперь я понимаю почему: он был изобретён людьми, которые знали математическую теорию типов...

💪🏻

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

=

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

=

— Это произойдёт, и вы ничего не сможете поделать!
В этих словах прозвучала надменность, свойственная ментатам, когда они попадают на поле своей логики.
"Еретики Дюны"

Порассуждаю письмом на эту темку.

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

Sentiment analysis, Topic modeling & thematic analysis, Стилеметрия etc. То есть сегодня количественно можно мерять семантическую глубину, энтропия vs. шум (база хорошего текста, на самом деле), и ещё много чего. В computer science активно ведутся исследования, например свежее
Machine Learning-Based Sentiment Analysis in English Literature: Using Deep Learning Models to Analyze Emotional and Thematic Content in Texts

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

Там не упоминается ещё RuLingva лаборатории КФУ «Мультидисциплинарные исследования текста» (везёт же тамошним студентам аспирантам :). В МПГУ ведутся исследования по многослойному анализу текста с акцентом на ритме, ярославские учёные разработали ProseRhythmDetector.

Почему такой акцент на ритме? Потому что это характеристика подсознательная, подпороговая, но при этом крайне важная. Буквально только в этом столетии появилось математическое подтверждение гениальной идеи Андрея Белого, который предполагал, что ритм связан со смыслом. А теперь ещё оказывается, что и обратное тоже верно! То есть в частности анализировать чисто человеческие характеристики восприятия текста можно формально через ритм.

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

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

Святые писатели говорили, что все великие тексты написаны по одному рецепту: 1% гениальности и 99% радикального редактирования, и я хочу этот рецепт автоматизировать.

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

И ты, огневая Музыка слов,
Безумствуй, сжигая меня,
Россия, Россия, Россия,–
Мессия грядущего дня!
А.Б.

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

Гениально: "CashClaw - опенсорсный ИИ, который будет просто грести деньги лопатой и постоянно обучаться, становясь всё лучше и лучше в заработке"

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

"Гуру объяснил (менеджерам Сбера), что менеджер должен постоянно пребывать в моменте, потому что все бабло исключительно там
Гуру из Индии – святой. Настоящий. Его в «Роллс-Ройсе» возят. Цветы под ноги кидают, все дела. А учитель йоги, если его за сто долларов нанимают – это эрзац. Там только слова такие же, а то, что за ними стоит, внутреннее состояние, оно может быть совсем-совсем другое. Особенно если он на свои курсы йоги в метро ездит и все эти хари ежедневно видит."
-- Пелевин