amarao

Very convoluted way to ask not to bother

Sun, 18 Oct 2026 10:09:54 GMT

00000000  1f 8b 08 08 c2 8e d4 6a  02 03 31 2e 62 00 d3 d6  |.......j..1.b...|
00000010  86 81 68 3b 38 53 db 46  37 16 c8 d3 e3 d2 46 05  |..h;8S.F7.....F.|
00000020  7a 5c ba 18 00 a1 08 9b  2c d9 80 0b c3 72 ea 01  |z\......,....r..|
00000030  64 87 c2 ac d1 e3 02 00  19 be 99 38 0a 01 00 00  |d..........8....|

comments

... and slow down

Thu, 15 Oct 2026 06:10:07 GMT

И ещё: в эпоху всё большего codegen'а, замедляться очень полезно. Вот я сейчас вчитался в llm изменения. Он написал source_directory() в justfile'е.

Я пошёл почитать, чем оно отличается от justfile_dir(), оказывается, учитывает модули. justfile_dir() работает с путём к justfile'у (который был вызван), source_directory() содержит путь к файлу, в котором функция вызвана.

Потратил на это времени больше, чем на всё остальное (для тех изменений, что делал). Но, польза несравнимая, я теперь ещё кусочек just'а выучил, в хорошем, полезном контексте.

comments

baby steps, but forward

Thu, 15 Oct 2026 05:53:02 GMT

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

Вот сегодня я набрался силы воли и разобрался (ага, разобрался... спросил и настроил) с cwd в новой панели в tmux'е.

bind '"' split-window -v -c '#{pane_current_path}'
bind % split-window -h -c '#{pane_current_path}'
bind c new-window -c '#{pane_current_path}'

Выставляет для новой панели cwd (текущую директорию) такую же, как у foreground процессса в активном pane. Мелочь, ерунда, но до этого я делал cd, и тратил на это капельку внимания. Каждый раз.

Глупость? Было не до этого. Нашёл, поправил.

Теперь надо не забыть разнести всюду. Начинаю думать про синхронизатор tmux'ового конфига...

comments

LLM контекст

Sat, 10 Oct 2026 07:18:05 GMT

Вот такую вот проблему я нашёл ещё у людей.

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

"Оно" состоит из отсылок к этому самому общему контексту. Человек, который обсуждал это с llm, понимает о чём это. Окружающие люди (или тот же человек месяц спустя) - уже нет.

Вообще, современный аутпут от LLM сильно напоминает некоторые сцены FLCL - крайне плотные и набитые референсами, но совершенно incomprehensible для внешнего наблюдателя. В случае FLCL этот контекст ссылался на фэндом, "который поймёт", а LLM вывод - это ссылки на "вот тот вот чат", который видел один человек и то не до конца прочитал.

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

Моё личное мнение, что первый вариант - путь в никуда. Каждый в своём чатике, передачи контекста никакой, путь в полное ослопление.

comments

RFC 10500

Tue, 06 Oct 2026 13:48:36 GMT

Аллокация адресов идёт по хронологическому признаку.

В 2027 году адреса выделяются из 2027::/16

comments

Случайное число

Tue, 06 Oct 2026 13:26:54 GMT

Я вот задумался о том, что такое случайное число.

Допустим, мы делаем случайную выборку из любого из чисел. Из R.

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

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

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

А просто "случайное вещественное число" нельзя.

comments

Ошибки в прогнозах

Sat, 03 Oct 2026 19:42:00 GMT

Признавать ошибки неприятно. Быть правым приятно.

Во времена gpt4.5 и 4o я говорил, что llm вероятнее всего, уже прошли середину логистической кривой и никакого сверхинтеллекта нам не светит, а светит дурка... галлюцинации.

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

LLM действительно сейчас начинают двигать области, которые человеку были не по зубам. Recursive self-improvement - открытый вопрос, но с учётом, что их начинают тащить в разработку чипов тоже, ... Открытый.

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

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

Таким образом:

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

Не смотря на то, что в основе лежит детерминированная LLM.

Если этот тезис не совсем понятен, ещё раз раскрою. Решение LLM выглядит так:

(условно фиксированный ввод) - фиксированный ответ LLM с вызовом MCP - ответ MCP с малым возмущением, уже нефиксированный ответ LLM с следующим коэффектом, и дальше накопительное возмущение.

Получается, что в permutation city ответ был: в тот момент, когда эффекты и коэффекты прекратились, система стала детерминированной и потеряла свободу воли.

comments

Да они издеваются

Sat, 03 Oct 2026 08:35:06 GMT

Ещё и отформатировали в 4 колоночки.

https://lwn.net/Articles/1097401/

comments

Fri, 02 Oct 2026 11:59:23 GMT

А айтишникам за въедливые вопросы полагается отдельный ад, с таймзонами.

comments

школьное обучение

Tue, 29 Sep 2026 14:21:35 GMT

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

А на олимпиаду читать диффы диффов. Это там, где +-, ++, -+ и --.

comments

переделки

Tue, 29 Sep 2026 11:57:53 GMT

Идёт, бычок шатается

Вот-вот он упадёт

Пьянь-дрянь совсем качается

И матом речь ведёт

comments

final customization

Tue, 29 Sep 2026 11:56:02 GMT

А почему об этом никто не думал? Не писал? Я не видел?

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

Я знаю, какая это мрачная технология, но я хочу посмотреть на её светлую сторону.

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

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

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

Это же огонь. Персональный лендинг, который одинаково крут для компании и для клиента.

comments

pyandons is dope

Mon, 28 Sep 2026 09:20:47 GMT

Есть такой мод к Factorio, Pyandons. Совершенно следующий уровень сложности и инженерных вызовов. Идеально для внутренних постмортемов архитектурных ошибок.

И сегодня я нашёл потрясающий анти-паттерн, который я видел в жизни.

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

Новая технология Y, которая позволяет удвоить производство X, но требует много X для своего запуска. (В py это mk2 модули, которые требуют много mk1, а mk1 строго ограничен тем самым ресурсом).

Анти-паттерн: направлять ресурсы X на производство mk2. Каждый удачный mk2 (там шанс на успех, а не гарантированный результат) - это + сколько-то процентов к производству X. Но весь X потребляется на mk2, так что всё stalled и почти безнадёжно. Вместо обычно дефицита, супердефицит без шансов на разрешение.

Правильное решение: сначала разрешить дефицит X (линейная экспансия, scaleout), пока не начнётся образовываться избыток. Избыток направлять на mk2 (и тогда процесс runaway, потому что в итоге будет scaleout x2, много-много ресурса и о проблеме можно забыть почти навсегда).

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

comments

новый вид пытки

Sun, 27 Sep 2026 14:10:36 GMT

ai допрос в ходе которого человек должен ответить на вопросы ai без противоречий и в полном объёме

comments

благоглупость

Fri, 25 Sep 2026 12:28:53 GMT

Can you establish a secure connection between floating point and floating IP?

* Yes, bidirectional
* Yes, unidirectional
* Yes, but only if they have the same size (e.g. 32-bits)
* No, connection will be insecure
* No, communication happens with datagrams
* No, its unsound

comments

llm summoning

Thu, 24 Sep 2026 10:55:27 GMT

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

Ещё надо уметь разговариать на языке понятном демонам и знать их хитрости.

comments

Жизнь в Лимассоле

Thu, 24 Sep 2026 06:53:12 GMT

Деревня-деревней, а сервисы иногда тут огого.

Умер аккумулятор у машины. Позвонил в компанию, которая специализируется на замене аккумуляторов. Приехали, прикурили на ходу (чтобы не сбросились настройки), заменили. Цена удовольствия €80.

В 9:01 я им отправил локацию.

В 9:14 я уже выезжал с парковки.

comments

That was the right call. Honestly, no reason. The AI slop, not human written text.

Sun, 20 Sep 2026 11:19:21 GMT

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

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

Недавно его назвали "token golf" (в отношении кода) - попытка выразить максимум за минимум токенов. Я думаю, оно применимо не только к коду, но и к языку (особенно этим страдает Клод).

Так вот, человек подвержен этому языку. Как именно он влияет на язык человека?

Я вижу несколько вариантов.

* никак. Самый маловероятный (столько воздействия и ничего?)
* адаптация (люди начинают повторять за LLM'ками грамматически). Этот вариант исходит из первго параграфа - люди повторяют те грамматические конструкции, которые прочитали.
* избегание. Лично я уже натрернировал свою аллергию на llm тексты, и если я их вижу в неожиданном месте, мне неприятно. Соответственно, если в своём тексте я вижу что-то отдалённо напоминающее llm-текст (с тем же "запахом"), я это ощущаю как неправильно и стараюсь исправить. В такой модели, если это широко распространено, будет, наоборот, отмирание оборотов, которые используются llm. Примерно как дворовая лексика. Все наслушаны, и все знают, что так не надо говорить.

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

comments

произношение

Sat, 19 Sep 2026 12:23:23 GMT

Некотрым трудно даётся не-смягчение согласных перед "и" в инстранных языках. Я только что придумал как объяснить и научить.

τι κάνες - τι в начале звучит как в фразе "кот и собака" звучат звуки "...т и" (т в конце "кот" + союз "и").

li в "listen" звучит так же как "...л и" в фразе "Кирилл и Мефодий".

comments

офисное

Thu, 17 Sep 2026 08:59:51 GMT

Бурные обсуждения - результат противления сторон.

comments

Наблюдение

Sat, 12 Sep 2026 11:12:10 GMT

В разговорах про деградацию понимания кода, часто говорят про то, что LLM всё написало и за время написания человек ничего не понял. Это так.

А если другую метрику посмотреть? За 100 часов возни с кодом, кто больше поймёт про кодовую базу (и про продукт) - человек ручной печати, или llm'щик?

Это ведь крайне интересный вопрос. Например, сколько раз за 100 часов человек ручной печати запустит разные случаи (т.е. получит практические наблюдения за поведением), и сколько раз llm'щик? Если llm'щик запустит больше (разных) раз, то у него, получается, будет больше опыта и интуиции по поведению результирующего бинаря.

comments

CVD update

Sat, 12 Sep 2026 09:05:42 GMT

Работа над CVD продолжается.

(Я его ещё толком не аносировал - замена молекулы без молекулярных прибабахов, возможно, в будущем, с поддержкой terraform -> ansible inventory и генерации kube.conf). Смотреть пока рано, так что даже ссылку не даю. CVD = create-verify-destroy.

И вот мне пришла в голову фантастическая идея по решению одного большого неудобства.

Проблема:

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

Обычно это делается с помощью --keep флага (или --destroy=never) и т.д.

Проблема с флагом состоит в том, что мы хотим сохранить именно эту сессию (вдруг нам не повезло в этот раз и повезёт в следующий? Будет грустно получить красный тест с destroy, а потом зелёный тест с --keep - пол-дня на воспроизведение).

Идея:

SIGUSR1 включает keep режим на ходу. Даже когда бежит ансибл или pytest, можно послать сигнал и оставить сетап живым.
SIGUSR2 аналогично выключает --keep режим на ходу.

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

Третья идея: pre-signed links на которые можно послать "вкл/выкл" просто кликнув на ссылку в выводе CI сервера (не будет хорошо работать, если DNAT).

Четвёртая идея: во время sleep перед destroy, возможный поллинг внешнего ресурса на тему "удалять или нет?" (позвляет что-то сделать на внешней системе и сказать "не удаляй").

comments

late vibe coding

Wed, 09 Sep 2026 09:32:18 GMT

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

Это чистый vibe кодинг, в том смысле, что я вообще принципиально не смотрю в код.

Зона моего ковыряния: спецификация, документация для пользователя и примеры.

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

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

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

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

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

comments

Context locality from LLM outputs

Sun, 30 Aug 2026 12:39:14 GMT

Я только что осознал ещё один fault domain при работе с LLM: violation of context locality.

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

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

И вот в эту картинку рабочего процесса врывается LLM. Хорошая LLM, astra, whatever. Которая вобрала в себя всё и одинаково хорошо понимает и этот кусок и соседний кусок и ещё другой соседний кусок.

Если произошла мискоммуникация между намерениями в коде и новыми изменениями, LLM может это заметить и подсветить. И тут, и там, и вот там, и вот там вот concern. Человек в такой ситуации понимает, что взял кусок не по рту и сдаёт назад, начинает делать осторожнее.

LLM же делает (правильно! но не правильно! мисскоммуникация) и поднимает 100500 concerns из разных доменов. Человек это либо игнорирует и делегирует llm разобраться (vibe), либо пытается понять. И вот тут-то начинает он Страдать, и чем тщательнее он думает, тем больнее он страдает.

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

Это настоящий, самый страшный мультитаскинг, когда от человека ожидают peak competence в каждой подсвеченной проблеме. А каждая проблема со своим контекстом. И вот человек пытается это всё понять. А потом тут же понять. И снова понять. И снова. Это же невыносимая нагрузка, запредельная. Разумеется, человек ломается и впадает в vibe режим, либо ухватывается за маленький кусочек.

Мы долго ругали llm за то, что у них маленький контекст. llm отрастили контекст побольше. Помощнее. Их attention vector может придавить 20 человек насмерть своим размером.

Заметим, эта проблема одинаково болезненная как в plan стадии, так и в implement. Её нельзя решить с помощью лучших промптов или лучших скиллов. Это либо "поди сам разберись" (vibe), либо невыносимая нагрузка на человека.

Что делать? То же самое, что человек делает при знакомстве с большой кодовой базой большого проекта. Стремиться к локальности. Как? Не знаю. Очень чешутся руки сказать "делать как раньше делали и попроси llm проверить". Наверное, это не выход (нельзя игнорировать скорость и качество написания кода).

Значит, надо искать какой-то пограничный подход, который позволит человеку сохранять удобную для него структуру контекста. А вот как? (describe me problems with this idea within a human-comfortable context hierarchy... хаха, удачи с таким промптом).

comments

The other side of the slop

Sat, 22 Aug 2026 08:05:35 GMT

(продолжая думать о проблемах и анти-паттернах работы с AI)

Традиционно, текстовый slop ненавидем за водянистое "ни о чём". Форма и стиль есть, содержимое банально.

В интерактивном программировании и при чтении комментариев в коде от LLM (по крайней мере, у новых моделей Fable/sol), ситуация обратная.

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

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

Что приводит нас к ещё большей диспропорции человек-LLM. LLM потратила 21 минуту 46 секунд (5 subagentic self-reviews) и выдала полторы страницы текста. Для нормального текста это примерно те же 20 минут чтения.

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

Т.е. вдумчивое чтение вывода LLM - это самая сложная задача. И она может занимать больше дня.

20 минут LLM, полтора дня чтения человеком.

Альтернатива - vibe (написало - работает). LLM сама "address concerns", сама "set scope and expectations", сама определяет терминологию и направление.

Чем меньше кодовая база, тем лучше это срабатывает. Для меня моментом откровения стала autora, которая просто работает. Я кода не видел, я смотрел интеграционные тесты - что нужно делает, что не нужно не делает (вроде бы).

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

И вот тут-то надо понимать и вычитывать. А это долго и сложно. Непропорционально долго. На самом деле, не сильно быстрее, чем разобраться самому, потому что фактором ограничения становится время изучения новых проблем человеком.

Повторю мысль: failure domain для LLM-assisted таски поменялся. Сейчас это "задача сделана но никто не понял как". Для vibe режима это окей, для крупной кодовой базы - замаскированная мина замедленного действия.

comments