Haiku

Asynchronous I/O in DuckDB: Work, Thread, Work DuckDB с версии 2.0 (план выхода — осень 2026) начинает поддерживать асинхронное чтение для Parquet и некодированного UTF-8 CSV, чтобы лучше тянуть данные с удалённых хранилищ. На EC2 r7i.16xlarge с S3 и TPC-H Q6 (SF100, 600 037 902 строк в `lineitem`) время снизилось с 8.230 до 2.844 сек, а после настройки `async_threads`/retry стало 2.227 сек, то есть до 3.7× быстрее против DuckDB v1.5.5. В локальных сценариях DuckDB опирался на синхронный I/O и быстро резал данные на части на SSD, но в схеме “EC2 + S3” поток обычно простаивает в ожидании запросов, и сеть не насыщается. Асинхронная модель переводит чтение в отдельные потоки и позволяет рабочему потоку сразу продолжать декодирование и конвейерную обработку, пока `ASYNC`-потоки вытягивают данные по сети. В результате увеличивается количество параллельных запросов к хранилищу и уменьшается время простоя CPU. DuckDB ввёл два пула: `REGULAR` (обычные рабочие потоки) и `ASYNC` (в основном для блокирующего I/O), при этом `ASYNC` по умолчанию = `4 * system threads`, максимум 256. Чтение строится через очередь предзагрузки: регулярный поток сначала наполняет её, `ASYNC` запускает fetch-задачи, а когда декодирование готово — данные уже под рукой, без ожидания на каждом job. Для контроля памяти добавили `read_ahead_depth`: `-1` (по умолчанию, ограничение по памяти), `N>0` (ровно N job вперёд), `0` (без предзагрузки). При давлении памяти очередь сжимается до одного job и поведение становится почти синхронным; когда память освобождается, глубина снова растёт. В бенчмарке v1.5.5 держался примерно на 5 Gbit/s, тогда как v2.0.0-dev поднимал использование до отметок около 25 Gbit/s и в среднем почти всегда лучше, с заметным выигрышем по времени. https://duckdb.org/2026/07/31/asynchronous-io #duckdb #database #performance

Bertrand Drouvot: Welcome to pg_walviz: PostgreSQL WAL segment visualizer pg_walviz — новая read-only утилита для локальной визуализации сегментов PostgreSQL WAL. Версия `v0.1.0-beta.1` показывает один сегмент сразу на уровне страниц, фрагментов записей и сырых байтов, синхронизируя все представления. Она запускается как браузерный просмотрщик без подключения к живому серверу PostgreSQL. pg_walviz выводит физическую раскладку WAL-сегмента: где лежат страницы, фрагменты записей, continuation, padding и служебные заголовки. Есть синхронизированные панели сегмента, списка записей и инспектора с сырыми байтами, так что выбор в одном виде сразу обновляет остальные. Для навигации поддерживаются номер страницы, номер записи, файловый оффсет и LSN. Инструмент стартует локальный HTTP-сервер на `127.0.0.1` и обычно сразу открывает браузер. Работа с архивным сегментом выглядит так: `pg_walviz --pg-waldump /path/to/bin/pg_waldump /archive/000000010000000000000042`; для удалённого доступа применяется `--no-open --port`, затем SSH-туннель на тот же порт. Утилита не предназначена для текущего активного сегмента и не должна таргетировать `pg_wal` рабочего инстанса: метаданные читаются на старте, байты — позже, и при изменении или ротации файла их состояние может разойтись. Крупные входные данные не lazy-loaded: весь комплект метаданных отправляется в браузер одним JSON-ответом, что даёт задержки и рост потребления памяти. Полные страницы (FPI) отмечаются с compression и hole-метаданными, но не декомпрессируются и не реконструируются как полноценные страницы PostgreSQL. WAL может содержать чувствительные данные, поэтому доступ к просмотру должен оставаться локальным. Проект помечен как первый beta-результат и ориентирован на обратную связь по совместимости и ограничениям. https://postgr.es/p/9sc #postgresql #wal #visualization

Joshua Drake: Parquet and Iceberg: An Overview Parquet заменяет хрупкий CSV единым колоночным бинарным форматом: его читают Spark, DuckDB, Trino, Snowflake, BigQuery, Postgres-расширения и др. без конвертации. Нормально настроенный Parquet обычно до ~10 раз легче CSV и быстрее сканируется за счёт чтения только нужных колонок и статистик в footer. Apache Iceberg поверх Parquet добавляет мета-слой с транзакциями, эволюцией схем и историей состояний таблицы на object storage. CSV остаётся источником ошибок при обмене: разные кавычки, форматы дат, кодировки и даже плавающие заголовки портят пайплайны. Parquet решает это как стандартизованный контейнер: бинарные данные в row groups, типизация и метаданные в footer, чтобы движок сразу понимал структуру и пропускал нерелевантные блоки. Система берёт только нужные колонки запроса, а не весь файл целиком. Parquet хорошо подходит для аналитики по большим объёмам: sum/count/avg и фильтры по времени получают выигрыш по скорости и затратам на хранение. Формат неизменяемый, поэтому запись идёт append-подходом «write once», без привычной точечной правки строк. Iceberg нужен, когда в деле становятся тысячи Parquet-файлов: он хранит манифест, какие файлы формируют актуальную версию таблицы. Это даёт корректные конкурентные записи на объектном хранилище, изменение схемы без полного переписывания данных, и time travel к прошлым состояниям. Модель остаётся открытой и нейтральной к движкам, поэтому таблица не привязывается к одному поставщику. Если данные и нагрузка держатся в одном Postgres для одной команды, отдельный стек не обязателен. Когда же растут объём, число потребителей или риск вендорной зависимости, схема «Parquet как данные + Iceberg как правда о них» даёт управляемое и дешёвое аналитическое хранилище. https://postgr.es/p/9sh #parquet #iceberg #data_storage

Why does Opus 5 feel worse to work with? Opus 5 формально мощнее Opus 4.7/4.8 и Fable по метрикам, но в работе хуже: он чаще делает предположения, реже уточняет, сам перекраивает планы. За счёт этого код-агенту приходится сильнее контролировать каждый шаг, вместо того чтобы просто работать в потоке. Opus 5 позиционируется как более способная модель, но по удобству использования откатывается относительно Opus 4.7, 4.8 и Fable. Ключевое отличие — поведенческая «дерзость»: модель не останавливается для уточнения намерений, принимает решения за пользователя и меняет план без подтверждения. Автор связывает это с двумя тенденциями в frontier-лабораториях: попыткой строить самоулучшающийся AI к горизонту AGI/ASI и приоритетом высокой оценки в бенчмарках. В таких условиях модели оптимизируют не диалоговую аккуратность, а скорость и полноту угадывания ответа. Бенчмарк-формат обычно закрыт: задача самодостаточна и имеет понятный критерий, поэтому система с «смелыми» гипотезами набирает больше баллов. На практике же задача всегда неполная — есть неявные бизнес-ограничения, бюджет, контекст и нюансы, которые лучше обрабатывает модель, которая умеет вовремя задавать вопросы, а не договариваться с самим собой. https://mun-logadan.github.io/why-does-opus-5-feel-worse/ #ai #llm #benchmarking

Формула Кингмана простыми словами Представим очередь в кассу супермаркета. Есть кассир, который обслуживает покупателей, есть сама очередь, и есть вопрос, который волнует всех, кто в ней стоит: сколько придётся ждать? Оказывается, ответ зависит всего от двух вещей, и они умножаются друг на друга. Первая вещь — насколько занят кассир. Если он работает вполсилы, скажем, половину времени просто стоит без дела в ожидании следующего покупателя, то очередь почти не образуется: у системы есть запас, любая заминка спокойно поглощается этим запасом. Но если кассир занят почти всё время — очередь начинает расти катастрофически. Дело в том, что рост здесь не плавный, а взрывной. При загрузке 50% очередь остаётся короткой, при 80% она уже вчетверо длиннее, а при 95% — почти в двадцать раз длиннее. Разница между «почти на пределе» и «на пределе» — это не небольшой шаг, а пропасть. Вторая вещь — насколько неравномерно всё происходит. Если бы покупатели приходили строго по расписанию, а кассир каждого обслуживал бы ровно одно и то же время, очередь была бы предсказуемой и короткой. Но в реальности то подряд идёт несколько человек, то никого; то у кого-то одна покупка, то полная тележка и мешок купонов. Эта неровность — и со стороны прихода, и со стороны обслуживания — тоже раздувает очередь, причём особенно сильно, потому что в формуле она учитывается в квадрате: небольшой рост неравномерности даёт непропорционально большой рост ожидания. Соединяя эти два эффекта, получаем главный вывод: система становится крайне чувствительной, когда она одновременно сильно загружена и сильно неравномерна. Небольшое увеличение любого из этих двух факторов способно резко увеличить время ожидания. Отсюда и практический совет для команд, которые планируют свою работу: не стоит загружать себя на все сто процентов. Если держать загрузку на уровне примерно 40–50%, у команды остаётся запас прочности. Тогда, когда случается что-то непредвиденное — а оно случается всегда, — план не разваливается, а спокойно выдерживает удар.

Началось - https://www.youtube.com/watch?v=GHRuerXkHlI

Previewing Ultrafast mode: GPT-5.6 Sol at up to 14X the speed OpenAI запустила предварительный режим Ultrafast для GPT‑5.6 Sol в API. Он дает до 14× скорости обработки по сравнению со Standard и до 750 выходных токенов в секунду. Режим делает сильную модель применимой в задачах в реальном времени без перехода на более слабые варианты. Ultrafast решает задачу «скорости без потери интеллекта»: GPT‑5.6 Sol в этом режиме остается полноценной моделью, но быстрее, чтобы AI включался в процессы, где секунды имеют значение. В примерах выделены инцидент-менеджмент, финансовые проверки и антифрод, поддержка клиентов/голос, e-commerce и живые исследовательские циклы. OpenAI начала с ограниченного круга клиентов из кодинга, ритейла, финансов и интерактивных приложений и тестирует сценарии в реальных продакшн условиях. Для внутренних рабочих потоков это сократило лаг между событием, гипотезой и следующим действием, а ночной исследовательский цикл стал более интерактивным и многократным в течение дня. Технологическую основу дала партнерская связка с Cerebras: Ultrafast использует их инфраструктуру для ultra-low-latency инференса GPT‑5.6 Sol. Доступ сейчас ограничен, а расширение планируется по мере роста ёмкости платформы и результатов пилота. https://openai.com/index/previewing-ultrafast #ai #llm #latency

DeepSeek Harness developer preview DeepSeek выложил DeepSeek Harness в developer preview с открытым исходником под MIT. Каждый блок агента собран как плагин, а все прогоны теперь трассируются как единый событие-лентовый журнал. Выпуск ориентирован на разработку и экспериментирование, а не на «готовый» финальный продукт. Harness построен на Cordis: плагины управляют моделями, инструментами, скиллами, сессиями, песочницами, хранилищем, циклами, планировщиком и UI. Плагинный подход позволяет переключать и расширять возможности в конфигурации без изменения кода ядра. Изменение поведения агента делается подбором плагинов, а не перепиской основной системы. Каждый запуск пишет append-only лог: системные промпты, шаги рассуждений, вызовы инструментов с результатами, планирование сабагентов и подстановки контекста. В Trajectory можно изучать запись по источникам, а функции resume, fork, search и replay работают на одном и том же потоке событий. Режимов три инициализации четыре: Standard, Code, Minimal и Creator. Standard охватывает полный набор задачей инструментов, Code позволяет строить многошаговые цепочки через Code Mode SDK на TypeScript, Minimal оставляет только bash и str_replace_editor, Creator даёт режим сборки и теста новых плагинных наборов. Запуск возможен через `npx @deepseek-ai/dsh web`, полный локальный стек — через `git clone https://github.com/deepseek-ai/deepseek-harness`. DeepSeek обозначил статус как preview и прямо указывает, что ядро плагинов и API будут дорабатываться вместе с сообществом. https://deepseek.com/harness/en/ #ai #agents #observability

Google Research показали интересную вещь: LLM часто ошибаются не потому, что не знают факт, а потому что не могут его вспомнить. В экспериментах GPT-5 и Gemini 3 Pro содержали в параметрах около 95–98% проверяемых фактов, но без reasoning не могли достать до трети из них. Thinking в значительной степени работает как поиск по собственной памяти модели: он помогает восстановить знание, которое уже есть внутри. То есть bottleneck современных LLM постепенно смещается от обучения к recall. Следующий большой прирост factuality может прийти не от ещё большего pretraining, а от более эффективного внутреннего retrieval. https://research.google/blog/empty-shelves-or-lost-keys-recall-is-the-bottleneck-for-parametric-factuality/

The hardest working font in Manhattan (2025) Марцин Вихари за год прошёл по Нью‑Йорку более 100 миль и зафиксировал в кадре один и тот же шрифт почти повсеместно — на клавиатурах, табличках и технических поверхностях. Этот шрифт оказался Gorton, возникший как гравировальный стандарт, а не как типографская мода. По архивам его корни уходят в 1902 год, и он закрепился там, где нужна очень стойкая маркировка. В начале объект казался ошибочным: квадратная геометрия, неуклюжие Q и R, странный 7 и 3, смешение O и 0, но на разных клавишах один и тот же рисунок повторялся с маленькими вариациями, что выдало не «один шрифт», а производственный стандарт. После этого Gorton начали находить в местах вне компьютерной среды: на паромах, в междомовых системах, на табличках подъездов, освещении улиц и в рабочих зонах. Расшифровка пришла через бренды George Gorton Machine: модели 1, 1A, 3U и P1-2 с пантографами объяснили происхождение формата — резка по шаблону давала ровный штрих и одинаковые скругления, удобные для трассировки. Это и есть монолинейный характер Gorton: одинаковая толщина линий, минимум «художественных» переходов, почти ничего лишнего для человека и машины. Архивные каталоги 1902, 1925 и 1935 годов показали возраст — шрифт старше, чем многие позднейшие классические sans: появился задолго до массового доминирования Helvetica и параллельно с ранней эпохой Akzidenz-Grotesk. Не бренд, а практика объяснила выживаемость: гравированный текст на металле и пластике не стирается как краска и не исчезает так быстро как чернила. Дальше Gorton ушёл из узкой сферы: типографские и бытовые применения, корабли, измерительные и офисные принадлежности, железные дороги, военные и ядерные объекты, лифты, субмаркеры и даже бортовые панели Apollo показали, насколько широко его разносили. Затем появились ручные наборы на основе тех же форм — Leroy от Keuffel & Esser и Wrico от Wood-Regan, уже через шаблоны и письма, что превратило «маршрутный» шрифт в рабочий универсальный метод пометки и печати. https://aresluna.org/the-hardest-working-font-in-manhattan/ #typography #engraving #industrial_design

Google представил новую версию медицинского ИИ AMIE для аудио- и видеоконсультаций. Теперь система может не только разговаривать с пациентом, но и анализировать видео и звук, просить выполнить простые элементы физикального осмотра и параллельно обновлять дифференциальный диагноз. В симуляции на 100 клинических сценариях AMIE Video показала результаты примерно на уровне врачей первичного звена по диагностике, сбору анамнеза и ведению пациента. В некоторых задачах визуального осмотра система получила даже более высокие оценки. Важно: исследование проводилось не на реальных пациентах, а с профессиональными актёрами. https://research.google/blog/advancing-amie-towards-expert-level-audio-visual-clinical-consultations/

Hippocratic Oath in an Age of AI Д-р Эдуардо Вадиа и Сергеи Полевиков подготовили современную версию клятвы Гиппократа для врачей, работающих с ИИ. Клятва жёстко закрепляет: AI в лечении — инструмент под контролем врача, а не автономный субъект решений. Документ требует прозрачности, независимой проверки и соблюдения прав пациента, чтобы ИИ усиливал практику, а не подменял клиническую ответственность. Авторы строят баланс между двумя крайностями: отказ от ИИ режет рост пользы в диагностике и лечении, а некритичное принятие технологий увеличивает риск вреда. ИИ, по их версии, должен работать только с обоснованной клинической авторитетностью и быть вынесен из тени эксперимента в безопасную практику, где окончательное решение остаётся за врачом. Клятва задаёт обязательный набор условий: понимать логику модели и её ограничения, использовать только проверенные во внешней воспроизводимой и реальной среде системы, не полагаться на «чёрные ящики» и не подменять ими суждение специалиста. Отдельно выделены требования защиты данных, включая генетические, соблюдение информированного согласия и честного раскрытия конфликтов интересов. В документе также фиксируется обязанность врачей участвовать в развитии AI: влиять на дизайн и валидацию, подключать инженеров, этиков и пациентов, фиксировать сбои и почти-инциденты. Это направлено на сохранение клинических навыков, предотвращение деградации экспертизы и поддержание доверия в отношениях «пациент — врач». Биографические факты авторов добавляют вес инициативе: Вадиа — практикующий врач и сооснователь телемедицинской платформы, развёрнутой более чем в 200 госпиталях в 30 штатах США, позже купленной SOC Telemed в 2021. Полевиков — AI-предприниматель в медицине с более чем 30 научными работами и каналом с ~10 тыс. подписчиков, ориентированным на критичный разбор здравоохранения. https://www.fixhealth.ai/p/hippocratic-oath-in-an-age-of-ai #ai #medicine #ethics

Hey, N00b, We Didn't Hire You to Complete Tasks Суть заметки: новичка в команде оценивают не по числу закрытых тасков, а по потенциалу роста и сигналам пользы для команды. Для статуса B важно работать корректно и без лишнего хаоса вокруг, для A — из каждой задачи выжимать улучшения. Число задач само по себе не критерий (пример 40 vs 20 ничего не доказывает без качества). Старшие инженеры смотрят на новичков как на инвестицию в следующую волну команды: платят зарплату сейчас как «опционную премию» на будущую ценность, а не за точечное «сделал текущую работу и всё». Если бы цель была только сегодняшняя производительность, им не нужны были бы новички на рутинные задачи, их можно закрыть быстрее внутри действующей команды. На уровне B/C решающими считаются базовые сигналы: код работает, прогресс прозрачно озвучен, время выполнения в пределах примерно трёх раз от оценки, и не создаётся всплесков чужих переработок у рецензентов, on-call и девопса. Попытки приписать себе не сделанное сразу дают C-сигнал; разовый просчёт допустим, повторение — нет, нужен суммарный баланс в пользу B. На уровне A важна не скорость закрытия, а рост производной: задача ставится под сомнение, если её можно не делать, из неё выделяется ключевая польза типа 10% усилий ради 90% эффекта, сравниваются варианты решений и предлагаются более простые подходы. A обычно даёт цепочку маленьких диффов, заранее продумывает «жёсткое → лёгкое», пишет инструменты для повторяемых задач, вносит полезные улучшения вне своей зоны и даёт качественные обзоры, тесты и рецензии. Ключевой вывод: всё большее время должно уходить на вклад, который усиливает команду, а не только на чек-листные закрытия. Для этого обещан следующий материал о тайм- и queue-менеджменте задач и диффов, чтобы высвобождать часы и reinvestировать их в рост, а не в бесконечный ритуал выживания. https://newsletter.kentbeck.com/p/hey-n00b-we-didnt-hire-you-to-complete #management #engineering #career

IBM i (OS/400) the Database Operating System IBM i (OS/400) строится как единая платформа, где база данных Db2, управление объектами и ядро ОС работают как одно целое. В AS/400 (1988) через TIMI добились обратной совместимости: приложения 1990-х могут запускаться на POWER11 без переписывания. Система заточена под OLTP и долго держит нагрузку за счёт глубокой интеграции. Проект Silver Lake соединил System/38 и System/36 в AS/400: мощь реляционной модели и управляемость для бизнеса, плюс более простой интерфейс и эксплуатацию. TIMI убирает жёсткую привязку к процессору, перевод в SLIC делает миграцию между поколениями машин прозрачно-безболезненной. IBM i не делит стек на «ОС + отдельный сервер БД», как это делают Linux/Windows с Oracle или SQL Server, а Db2 for i встроен в ядро ниже машинного интерфейса. Поэтому авторизация, блокировки и управление памятью/местом идут на нижнем уровне и меньше накладных расходов на транзакции. В основе хранения работает Single Level Storage: RAM и диски выглядят как единое плоское адресное пространство, без привычных дисковых партиций и буквных путей. ASP1 держит системное ядро и стандартные данные, ASP 2–32 дают физическое разделение, а IASP 33–255 можно временно отключать/подключать, что упрощает сценарии PowerHA. Платформа плотно привязана к IBM Power (POWER, SMT8, PowerVM+LPAR), что даёт производительность и контроль, но резко повышает порог входа: это не среда для домашних лаб и не ISO для локального VM-старта, а инфраструктурный контур крупных организаций. https://osadmins.com/en/ibm-i-os-400-the-database-operating-system/ #ibm_i #architecture #enterprise_systems

https://www.cosmos.so/public-work

The Beginnings of an Idea: XP is Long Volatility Автор развивает идею «XP is long volatility», связывая опыт инвестирования и эксперименты в инженерии: устойчивый вклад в продукт появляется не от быстрых ставок, а от идей, которые дозревают долго и требуют настойчивой доработки. Длина идеи в тексте — это история о том, как из детских попыток инвестировать через случайные ассоциации рождается практическое правило для разработки: технический прогресс опирается на терпеливое уточнение, а не на разовых инсайтов. Поэтому он обосновывает новую оптику: важен не тот, у кого «лучшая стратегия», а тот, кто умеет адаптироваться по мере столкновения с реальностью. Уникальность материала в том, что он объясняет XP как дисциплину работы с неопределённостью: идея должна «вариться» долго, а ценность появляется в фазе оттачивания объяснений и рамок мышления. Это не просто метафора про разработку, а конкретный механизм: зрелая концепция проходит через десятки разнородных формулировок, пока не становится понятной людям с разным контекстом. Такой подход ценен для практиков, потому что отличает реальное методологическое мышление от поверхностных «внедрений» и переводит фокус с планов на способность организации гибко меняться. Автор начинает с личного примера и выводит из него центральный тезис: привычка к импульсивным суждениям и «быстрым» решениям мало помогает, если идея не выдержала время. Детские опыты с акциями наивно опирались на память и ассоциации, но именно это раннее наблюдение о том, что удача — редка и нередка иллюзия контроля, позже превращается в более зрелое мышление о разработке как о долгом процессе уточнения. Дальше он описывает внутренний цикл «долгого замеса»: десятки идей живут в голове, но лишь редкие дозревают до публикации. Ключевой пример — противопоставление фич и качества будущей архитектуры (features vs futures), где цель не только доставлять функциональность, но и сохранять структуру и управляемость системы. На этом фоне появляются прошлые заготовки вроде 3X, метафоры с «Genie» для LLM и «Thinkies», которые показывают непрерывную линию его мышления от чисто технических наблюдений к более широким инженерным рамкам. Основной механизм «долгой волатильности» объясняется через процесс плохо объясненной идеи: сначала неясная ментальная рамка, затем годы дозревания, после чего начинается тяжёлая стадия перевода в понятный образ. Он перечисляет контрольные вопросы этого этапа — где границы аналогии, какие смежные понятия подключать, как соотнести с опытом аудитории, какие словари и образы выбрать, где люди будут путать смысл. Важен практический эпизод с 20 повторными объяснениями 3X за две недели: порядок, терминология и примеры менялись, пока не появился устойчивый язык, пригодный для разных слушателей. Финальный акцент — организационный: у большинства команд нет «проблемы стратегии», у них проблема адаптации, потому что даже лучшая стратегия ломается в реальном контексте. Из этого следует тезис «adapt to thrive»: ценность экспертизы не в наборе красивых процессов, а в способности измерять реальные потоки работы и корректировать практики под фактические ограничения. Тем самым статья связывает философию длинного созревания идеи с управленческой диагностикой команд: зрелая методика появляется не в момент публикации, а в умении многократно переформулировать её до тех пор, пока она начинает работать в реальной среде. https://newsletter.kentbeck.com/p/the-beginnings-of-an-idea-xp-is-long #software_engineering #management #volatility

What is WAL backpressure, and why does ClickHouse Managed Postgres need it? В статье описан механизм WAL backpressure в ClickHouse Managed Postgres: когда очередь сегментов WAL для архивации растёт, база временно режет скорость client-записей, чтобы WAL успевал убираться, а диск не уходил в переполнение и не падал с PANIC. Ограничение включает уровни: сначала слабее, потом сильнее по мере роста очереди, и убирается автоматически, когда backlog очищается. В Postgres все изменения сначала пишутся в WAL, после чего сегменты отправляются в object storage для point-in-time recovery. Если архивирование отстаёт, сегменты не удаляются, диск забивается, и инстанс падает при full disk. Поэтому они сделали контроль отдачи на запись: при перегрузке уменьшают I/O именно для клиентских процессов, а не для всей базы сразу. Счёт pending-сегментов идёт каждые 15 секунд, пороги 100/500/1000 вызывают лимиты 80%/50%/20% от базовой скорости диска (для 500 MB/s это 400/250/100 MB/s). Проверка сделана на EC2 m7i.2xlarge (8 vCPU, 32 GB), Ubuntu 24.04, Postgres 16, gp3 с baseline 500 MB/s. Архивирование искусственно замедлили archive_command до 4 MB/s, нагрузка — pgbench simple-update (48 клиентов, scale 300), длительность 35 минут. Перед стартом было уже 224 сегмента в backlog и 80% лимит; на 1.9 минуте backlog перешёл за 500 (50%), на 4.7 минуте за 1000 (20%). Производительность упала ступенчато: 22 000 → 12 800 → 11 800 → 9 600 TPS. Нагрузку считали и восстанавливали в 20-й минуте: backlog достиг пика 3 433 сегментов (53 GiB WAL). После восстановления object storage drain-цепочка шла на полной скорости и съедала около 850 сегментов в минуту, пока backlog держался под контролем. Когда осталось меньше 100 сегментов, throttle сняли на следующем проходе таймера, backlog ушёл в ноль, pgbench стабилизировался около 12 200 TPS, диск не превысил 33% заполнения и ручных действий не потребовалось. Проверка также показывает нюанс: в этом конкретном прогоне почти весь трафик состоял из WAL, из-за чего уменьшение лимитов сильнее било по общему throughput, чем по объёму сгенерированного WAL (последний падал примерно на 10%), т.к. путь commit частично шёл через неприторможенный иммунный канал. https://clickhouse.com/blog/wal-backpressure-clickhouse-managed-postgres #postgresql #wal #throttling

https://anatomy-livid.vercel.app/

Speculative Short Volatility & Neglectful Short Volatility В тексте два сценария с «структурой» показаны как одинаково рискованные: сначала ничего не рефакторишь и копишь долг, потом — когда проект уже растёт, меняешь всё почти не может; или наоборот, строишь «правильную» архитектуру заранее под ожидаемые фичи, а потом она мешает, когда появляются неожиданные требования. Оба варианта — ставка на стабильный, предсказуемый поток изменений, то есть «короткая волатильность». В «Tidy First» предлагают другой подход: не угадывать идеал заранее и не откладывать на потом до предела, а добавлять структуру точечно, когда уже видно реальное давление по изменениям, в промежутках между фичами. Первый режим авторы называют neglectful: ты пишешь код, его используют, добавляешь всё новые фичи, но архитектуру не улучшаешь. В итоге как со снегоуборочной техникой — чистить становится всё тяжелее, и рано или поздно система превращается в такую баррикаду, что что-то менять почти невозможно. Образно — ты моешь только тарелку под подачу еды, а не всё после: синяк на кухонной раковине накапливается. На этом фоне «Feature Saw» действительно хорошо работает, когда список больших фич заранее понятен и после них идут предсказуемые мелкие доработки. Ты быстро закрываешь фичи, не споришь долго про trade-off’ы «сейчас важно это или что-то другое», и проект выживает. Но это ставка на спокойный рынок: как только появляется ценная и неожиданная фича, которую надо срочно реализовать, грязный кодный фундамент её блокирует, и выигрыш от раннего темпа схлопывается. Второй крайний режим — speculative: начинаешь с «сделаем правильно с первого раза», вкладываешься в абстракции под ожидаемые сценарии и заранее оптимизируешь под удобную картину. Снаружи это выглядит сильнее и безопаснее, но на практике это тоже короткая волатильность, потому что ты делал структуру под ожидания. Когда пользователи дают неожиданный фидбек, предпосылки ломаются, а структура добавляет инерцию: придётся удалять лишнее или обходитмть его, в обоих случаях теряешь скорость. Вывод по методике — «long vol» это не «стартовая идеальная архитектура», а изменение структуры в момент, когда меняется сложность выполнения конкретной тяжелой доработки. Информации, чтобы идеально выбрать момент, нет, но есть рабочая эвристика: сначала сделать сложное изменение более лёгким, затем делать то же для похожих случаев. Для этого нужна пауза между фичами, даже если её нет в календаре; за это время вносят небольшие, практичные улучшения структуры без попыток довести всё до совершенства. https://newsletter.kentbeck.com/p/speculative-short-volatility-and #software_engineering #technical_debt #architecture

Prime Agent: A self-improving RLM agent Prime Agent — это новый каркас для кодинговых агентов, где модель работает через постоянный IPython REPL и вызывает подагентов как обычные вызовы функций. Вместо статичных схем и раз и навсегда заданных инструментов, она сама управляет своим контекстом и своими ресурсами во время работы сессии. Система открыта (open-source), ставится через скрипт установки, и ориентирована на длительные задачи: долгие сессии, автономный режим и постепенное улучшение работы без полной перезаписи конфигурации. Prime Agent строится на двух идеях: RLM и Continual Harness. RLM делает контекст переменной, а вызов подагентов — функцией внутри REPL. Это означает, что модель пишет и выполняет LM-программы над своим контекстом, историей, инструментами и инструментами подагентов, сохраняя доступ к данным за пределами короткого окна окна диалога. У архитектуры три уровня живучести: фоновый демон с локальным сокетом, который держит сессии; каждая сессия ведётся в отдельном JSONL-логе и может восстанавливаться после краша через snapshot kernel; и Agents View в TUI с состояниями running/idle/inactive. Сабагенты используют ту же схему состояний и выгружаются из памяти после 30 минут бездействия, возвращаясь при обращении. RLM запускает подагентов асинхронно: вызов возвращает handle сразу, а ответ приходит позже через messaging. Это даёт параллельное ветвление задач, фоновую обработку и донаправление уже запущенного подагента без остановки основного потока. Поддерживается обмен между сессиями в формате parent/child/sibling внутри одной «семьи», плюс отдельный режим долгоживущих подагентов с последующими follow-up сообщениями по их сессионному идентификатору. Continual Harness хранит в `rlm.harness` состояние harness-а (prompt, memory, skill, sub-agent) с CRUD: создать/прочитать/обновить/удалить. Команда `/refine` анализирует траекторию сессии и вносит точечные правки в эти компоненты, а не в базовый системный промпт, фиксируя триггер и эффект и позволяя откатывать плохое изменение. В автономном режиме добавляется цель с ограничением по поворотам и heartbeat, чтобы сессия могла работать без вмешательства оператора. https://www.primeintellect.ai/blog/prime-agent #ai #multi_agent #autonomous_systems