Харпер классный мужик.
Никогда не слышал о нем и не читал.

Вот линк на его блогпост который в линкедине расхвалил Мартин Фаулер 😱

Харпер описывает свой воркфлоу по разработке программных продуктов.

Оставим в стороне на сей раз мои душные миллениалские негодования – чувак говорит дело 🚨

Если вкратце – сначала просим ллм нас итеративно опросить, чтобы собрать список проектных требований.

Потом просим сварганить подробную спецификацию для разработчика - с ТДД или без (лучше конечно с ним).

Потом эту спеку мы кормим штуке вроде курсора.

В целом подход хорош тем, что он системный. Харпер например упоминает что очень хорошо просить ллм сгенерировать чеклист тудушек, а чеклисты «многому голова» по Левенчуку :)

Я признаюсь, использовал менее системный подход, и обязательно попробую рекомендации Харпера в деле.

Разве что поправлю промпты, попрошу не просто ТДД чеклист, а внедрю степ на котором попытаюсь с ЛЛМ спроектировать систему хотя бы как то по ООАП кананоам.

Читайте!

Крутые чуваки из Стэнфорда продолжают арку "Давайте подружим LLM-ки!"

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

Что у меня вызывает вопросы, это то что они пришли опять к подходу когда "большая и умная, дорогая модель в облаке" генерирует куски кода, которые "локальные и маленькие, дешевые и более глупые" Миньоны выполняют, например на данных из PDF документов, и отдают результаты большой модели для генерации ответа ❓

Направление круто, но как же сильно это все еще пахнет ужасающим недетерминизмом.

1️⃣ Во-первых, со стороны пользователя - что с безопасностью? Какими средствами и в каких средах эти модели будут запускаться локально? В Ollama? Окей. Доверяем ли мы коду который генерирует LLM?

Абсолютно не доверяем. Я - не доверяю.

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

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

2️⃣ Во-вторых, со стороны разработчика такой системы - как это вообще отлаживать? Оправдана ли сложность такой недетерминированной системы? Тут я разглагольствовать не буду, ибо кажется очевидным.

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

3️⃣ В-третьих, попытка общаться даже маленькими кусками кода, имею в виду не tool-calls, а как в работе выше предлагают - это уже какая никакая, но минимальная инженерия. Инженерия которая требует аналитического мышления при первых же проблемках. К такок инженерии LLM совершенно не готовы.

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

Он может предложить вам удалить миграции, просто в тупую - "А давай перегенерируем!" Или откровенно галлюцинировать методами / классами из импортированных библиотек, которых там нет и отродясь не было.

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

Результат такой же.

Анализ Ошибок работает так же – часто и с простыми ошибками, аннотациями типов и прочим Cursor может справиться вполне хорошо, но как только мы сталкиваемся с дебагом проблемы хоть сколько нибудь более сложного порядка, где нужно проверить 2-3 зависимости - оно утыкается в стекляный потолок своих "когнитивных возможностей".

А это, на секундочку, очень классный 3.7 с "thinking" 🤪

Тем не менее, это все очень классные штуки! Они чертовски помогают ускорять работу! Но анализировать, хоть сколько нибудь __логически__ думать LLM не может.

***

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

Первые попытки (те которые мы сейчас наблюдаем) - промежуточного рассуждения на естественном, человеческом языке - разбиваются как мы видим дребезги на задачках требущих рассуждения уровня junior+

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

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

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

В этом свете мне более интересными кажутся следующие две работы:

🤖 DroidSpeak

Large Language Models (LLMs) are increasingly employed in complex workflows, where different LLMs and fine-tuned variants collaboratively address complex tasks. However, these systems face significant inefficiencies due to redundant context processing of the shared context. We propose DroidSpeak, a framework that optimizes context sharing between fine-tuned LLMs derived from the same foundational model. DroidSpeak identifies critical layers in the KV cache and selectively recomputes them, enabling effective reuse of intermediate data while maintaining high accuracy. Our approach balances computational efficiency and task fidelity, significantly reducing inference latency and throughput bottlenecks. Experiments on diverse datasets and model pairs demonstrate that DroidSpeak achieves up to 3x higher throughputs and 2.6x faster prefill times with negligible accuracy loss compared to full recomputation.

👩‍💻 Byte Latent Transformers

We introduce the Byte Latent Transformer (BLT), a new byte-level LLM architecture that, for the first time, matches tokenization-based LLM performance at scale with significant improvements in inference efficiency and robustness. BLT encodes bytes into dynamically sized patches, which serve as the primary units of computation. Patches are segmented dynamically based on the entropy of the next byte, allocating more compute and model capacity where increased data complexity demands it. We present the first flop controlled scaling study of byte-level models up to 8B parameters with 4T training bytes. Our results demonstrate the feasibility of scaling models trained on raw bytes without a fixed-vocabulary. Both training and inference efficiency improve due to dynamically selecting long patches when data is predictable, along with qualitative improvements on reasoning and long tail generalization. Overall, for fixed inference costs, BLT shows significantly better scaling than tokenization-based models, by simultaneously growing both patch and model size.

TL;DR:

DroidSpeak - делаем так чтобы модели общались между собой без токенизации; Byte Latent Transformers - тоже про отказ от токенов, в пользу байтовых представлений.

Оба этих подхода создают более "адекватное" пространство для рассуждений моделей, менее прерывное пространство - избавились от токенов и "думаем" непрерывными векторами!

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

С другой стороны - обучать модели логическому программированию на языке вроде Prolog выглядит очень и очень перспективно.

Хочется верить, что эти направления будут добиты, на загнутся, и революционно выстрелят в бурной синергии.

И верится в это - без особого труда.

***

P.S.

Удивительно, но ни один из каналов в телеграмме посвещенных ML или около того не написал вообще ничего про DroidSpeak (Byte Latent я не чекал, но скорее всего история таже). И большие (30, 50, 60к подписчиков) и маленькие, узко специализированные блоггеры.

Ну и в целом в Рунете всего ничего изданий об этом написало.

Да, я прошу поделиться с друзьями инженерами, кому это может быть хоть сколько нибудь интересно 🙂

Uh, oh. Надо все таки в telegraph такие лонгриды пихать.
Извините 🤨

Здравствуйте дорогие друзья 👋

Моя жена любит сюрпризы. Ну, наверное все (или большая часть) девочек любят сюрпризы 🌷

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

В общем да, сегодня про "плохие" сюрпризы, которые никто из нас (кроме мазохистов) не любит.

#оффтоп@ivanzakutnii

Армения - солнечная страна! ☀️
И развивается Армения достаточно ОКэй, последние 10 лет так точно.

Айтишка в общем и целом тоже окей, вызывают вопросы устаревшие UI, кривые мобильные клиенты (по сравнению с банками в РФ), но здравый смысл отвечает на все это - СПАСИБО что оно вообще есть, работает, и мне на надо идти в оффлайн банк чтобы чеки выписывать. 💵

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

Как бы не так!

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

Потом можете забрать столько кВт сколько отдали. Красота!

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

Хорошая электронная музыка, это когда задаешься вопросом:
- Это трек такой, или у меня комп лагает?

UPD. Все таки это комп. Не надо было запускать 12 потоков тестов после того как гвардрейлы впендюрил 🥲

Оказывается у меня была УЙМА бустов, потому что я частенько кому то дарил телеграм премиум за последние пару лет.

Ну… забустил канал себе 🔍

Накидал новых реакций, чтобы было молодежно и модно!


Ожидайте в сторис мемы 💃

Поздравляю вас с восьмым марта, дорогие подписчицы и подписчики!

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

Ада Лавлейс — первая в мире программистка! Она не просто перевела лекции Бэббиджа по аналитической машине с французского на английский, но расширила этот перевод инструкциями, которые по сути и есть программы.
Жаль что машину эту так и не построили 👎

Грейс Хоппер — разработала первый компилятор и создала язык COBOL, который до сих пор используется. Именно она ввела термин "баг", когда нашла мотылька, застрявшего в реле компьютера Mark II 🪳

Барбара Лисков — я пару раз писал о ней в последние дни. Помимо принципа подстановки Барбара получила премию Тьюринга за вклад в теорию абстракции данных (по сути - интерфейсы).

Радиа Перлман — "мама интернета", потому что разработала STP протокол что решил проблему сетевых петель и сделал возможным функционирование современных компьютерных сетей. Радиа считает это своим самым простым изобретением 😱

Фрэнсис Аллен — первая женщина получившая премию Тьюринга (в 2006 🫠) за за работу в области оптимизации компиляторов. Отдала 45 лет жизни IBM, которая учредила в ее честь премию в 2007.

Лоис Хайбт — в 23 года стала одним из ключевых разработчиков FORTRAN (а чего добился ты в 23? 😂). Она создала первый синтаксический анализатор для арифметических выражений, популяризировала термин «программная инженерия», и разработала концепцию асинхронного ПО 🤩

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

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

С праздником, дорогие!🌷👩‍💻

Приветствую.

Я несколько дней назад наконец начал изучать первый курс Школы Системного Менеджмента, называется он рациональная работа.

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

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

Сегодня я изучал и писал про _Собранность_ как фундаментальное мастерство.

Звучит громко, но это очень интересно, и спорить довольно сложно.

По ссылке ~9.5 тысяч знаков на эту тему 🔗

---

TLDR;

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

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

В общем зацените, там само мастерство тоже разбираем.

😐

За прошедшую неделю меня несколько раз спросили – а не наркоман ли я часом? какую LLM я жмав в cursor и неужели оно правда моросит?

Ну, если коротко: жмав куда надо, и да – моросит.

Более подробно – читать тут.

В посте я снова обьясняю свою позицию, нисколько не отрицая и не умоляя все прелести от работы с LLM.

Ток то куда не глянь – везде одними моделями пользуешься. Гугл хоть пока и не издох, но на две трети вопросов я иду сразу в Perplexity, например, и только потом и если нужно – в гулу-гулу.

😮 Кстати, по поводу Perplexity. У них оказуется апиха довольно дешевая, я собираюсь с ней поэсперементировать, хочу попробовать специлизированные микро-поисковые движки наколеночные проверить.
Если у вас есть опыт работы с этим API - напишите пару строк в комменты, буду признателен 😘

Ща будет 👌

В 1999 в Японии на ядерном объекте Токаймура чуть не жахнуло 💥

Это не АЭС, но там производили компоненты топлива для Японских АЭС.

Не жахнуло, но произошла критическая авария (самая серьезная в Японии на тот момент) – 2 человека погибло, и 667 облучило (не уверен насколько подсчеты верны, может и больше.) 🕯

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

До этого на заводе строго следовали лицензированной японским Управлением науки и технологий процессу - мешали компоненты в буферной емкости.

Емкость на то и буферная, чтобы компоненты там задерживались, и в управлении явно не идиоты сидели.

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

Пиздец! 😖

Люди которые принимали это решение, мало того что не подумали о том, что система сконструирована так не со злым умыслом, и не просто как следствие инженерной душной души, но еще основывались на такой идейке – "мы все равно производим слабо обогащенный уран, так что точно не жахнет! Врядли у нас будут заказы на другой уран! Погнали!" 🤑

MONEY!

30 сентября 1999 года на Токаймуре обрабатывали заказ с сырьем высокой степени обогащения.

30 сентября 1999 года на Токаймуре работала смена неопытных рабочих.

...

История эта хоть и кажется имеющей мало отношения к нашим IT реалиям, но имеет.

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

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

Заваливая команды 20-тью параллельными задачами, все из которых в приоритетах high и critical, мы ускоряем не скорость продукции, а скорость генерации технического долга, инцидентов, боттлнеков и "текучки".

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