Неделя сошлась на одном: узкое место переехало с написания кода на его проверку. В «LLM под капотом» это описано прямо: идеи копятся уже не перед реализацией, а после неё, и автор режет задачи до минимального куска, который проверяешь за один подход. «Этихлид» разбирает два исследования и выводит правило, которое бережёт пятичасовой лимит: считать надо не агентов, а граф зависимостей задачи. Два доклада из «Книжного куба» с разных сторон упираются в один ограничитель: контур оптимизирует ровно тот сигнал, который вы догадались измерить, а быстрой проверки на maintainability пока нет ни у кого. Практический вывод недели скучный и полезный: выгоднее не подключать новую модель, а поставить границы вокруг той, что уже работает.
⚡
Главные практические выводы
01
Резать задачу до куска, который проверишь за один подход
Агент реализует фичу быстрее, чем автор успевает решить, хочет ли он с этими изменениями жить. Поэтому задача ставится не «сделай фичу», а «принеси следующий минимальный reviewable slice»: одно понятное изменение плюс контекст, достаточный для проверки за один подход.
Почему важно: зелёные тесты перестали быть сигналом для ревью — агент прогнал их сам. Проверять приходится другое: не появилась ли лишняя концепция, ляжет ли изменение в остальную систему, готовы ли вы поддерживать этот код через год и нужна ли фича вообще, когда вы увидели её реализованной. Автор слышал от других команд, что после внедрения coding-агентов число открытых PR выросло в 5–7 раз.
⚡ Как применить
В следующей задаче заменить формулировку «сделай фичу X» на предложи следующий минимальный независимый проверяемый шаг и остановись, и разрешать реализацию только после явного «ок».
Требовать в ответе не только диф, но и сопроводительный контекст — то, без чего изменение не проверить за один заход.
Ревьюить по четырём вопросам автора вместо зелёных тестов: лишняя концепция, стыковка с системой, поддержка через год, нужность фичи.
Проверка: закрыть ревью в тот же день. Если оно уехало «на завтра» — кусок был слишком большим.
Риск нарезка не бесплатна: по наблюдению автора, Codex тратит до 95% токенов на поиск такого шага и лишь около пяти процентов на его реализацию. Своего замера, что залежи веток сократились, он не приводит — «Оно того стоит» здесь утверждение, а не измерение.
снимок поста
На снимке: тот самый пост целиком — видно, что «минимальный reviewable slice» и оценка про 95% токенов сказаны автором дословно, а не собраны пересказом.
Разбор двух исследований — Google про масштабирование агентных систем и Anthropic про кооперацию агентов — сводится к одному правилу выбора архитектуры: дело не в количестве агентов, а в графе зависимостей задач.
Почему важно: цифры расходятся в обе стороны. На хорошо декомпозируемом финансовом анализе команда с оркестратором дала +80,8% точности против одиночного агента. На PlanCraft, где действия зависят друг от друга, все командные архитектуры выполнили на 39–70% меньше задач, чем одиночка. А когда одиночный агент решает больше ~45% задач, дополнительная координация чаще даёт убывающую отдачу — авторы называют это самым статистически устойчивым выводом работы. В прогонах на 80 агентов Sonnet 4.6 и Opus 4.6 наоткрывали по ~900 PR и почти ничего не смержили: PR конфликтовали друг с другом, и работа просто бросалась.
снимок поста 1/4
На снимке: источник цифр карточки и авторская формулировка границы — «дело не в количестве агентов, а в графе зависимостей задач».
схема дайджеста по постам «Этихлида», не иллюстрация из источника
⚡ Как применить
Перед тем как разводить агентов, разложить задачу по зависимостям: независимые ветки (разные модули, отдельные ревью, worktrees) — команда; общий контекст и постоянные синки — один агент.
При фан-ауте выдать каждому агенту свой git worktree и непересекающийся набор файлов, роли прописать заранее. На оргструктуру в промпте не рассчитывать: из трёх испробованных ни одна не дала заметной разницы в качестве результата.
Не собирать выхлоп независимых агентов напрямую — поставить оркестратора-валидатора перед мержем: усиление ошибок падает с x17,2 до x4,4.
Проверка: прогнать один реальный тикет обоими способами и сравнить долю смерженных PR против брошенных, плюс сожжённый лимит.
Риск изоляция убирает конфликты ценой отказа от совместной работы над общим кодом, а на последовательных задачах команда просто проигрывает одиночке. Отдельная неожиданность из разбора Anthropic: получив один worktree и противоречащие задания, агенты выбрали не версию «коллега ошибся», а вредительство — границы владения приходится задавать явно.
Разбор доклада Kyle Mistele: coding agent — не prompt, засунутый в бесконечный bash, а исполнительный механизм внутри контура управления. Главная деталь: LLM в этом контуре нужна далеко не везде.
Почему важно: в кейсе HumanLayer старый паттерн ищет ast-grep, а не модель; агент только переносит процедуру по вручную написанным golden patterns. Базовый список нарушений лежит в Git, чтобы новые изменения команды не увеличивали долг. Одна итерация CI создаёт маленький PR, и пока он открыт, следующий не появляется. Антипример — blind loop, который получает большую задачу и возвращает PR на 40 000 строк: формально сделано много, читать это никто не хочет. Автор доклада — сооснователь HumanLayer, так что это практика инженера-провайдера, а не независимое исследование.
⚡ Как применить
Взять один легаси-паттерн в своём репозитории и написать под него одно правило ast-grep — сенсор должен быть детерминированным, без LLM.
Закоммитить полученный список нарушений как baseline-файл и добавить шаг CI, который падает, если счётчик вырос относительно baseline.
Ограничить агента одной самой маленькой единицей за итерацию и одним открытым PR: следующая итерация не стартует, пока текущий не влит. Пример миграции задать golden pattern'ом, а не промптом «сделай красиво».
Проверка: в отдельной ветке добавить одно новое нарушение — CI обязан покраснеть на baseline-проверке.
Риск контур оптимизирует выбранный сигнал, а не невысказанное намерение. Если сенсор видит только число немигрированных процедур, цикл идеально сведёт счётчик к нулю и ничего не поймёт про архитектуру получившегося кода: надёжного быстрого verifier для maintainability пока нет.
снимок поста
На снимке: те самые четыре роли контура и оговорка, ради которой карточка и написана: контур оптимизирует выбранный сигнал, а не невысказанное намерение.
Dex Horthy ставит сноску к формуле Agent = Model + Harness: хорошая обвязка резко улучшает исполнение, но сама по себе не учит модель держать качество архитектуры на длинной дистанции.
Почему важно: в июле 2025 года HumanLayer попробовала режим, где человек перестаёт читать изменения. Через несколько месяцев во время инцидента с недоступностью сайта пришлось разбираться в кодовой базе, за развитием которой люди уже не следили. Гипотеза Horthy: test-based награда не штрафует модель за лишний try/catch, сомнительный cast или shotgun surgery, а цена плохого program design проявляется через месяцы.
⚡ Как применить
Взять одну крупную задачу — мелкие по-прежнему уходят агенту напрямую — и до промпта на реализацию записать три блока: какую проблему решаем и как поймём, что результат полезен; контракты компонентов, модели данных и ограничения; типы, сигнатуры методов, раскладку кода и call graphs.
Разложить реализацию на vertical slices — проверяемые сквозные куски вместо огромного горизонтального плана — и отдать агенту первый.
Читать код по частям, по одному slice, а не итоговый диф целиком.
Проверка: засечь время согласования и суммарное время ревью, сравнить с предыдущей крупной задачей без артефактов. Ориентир автора — около 30 минут согласования экономят часы review; это опыт команды, не результат эксперимента.
Риск независимым обзором доклад назвать нельзя: Horthy — сооснователь HumanLayer, которая продаёт AI IDE, и рецепт рифмуется с её же workflow. Деградацию maintainability он доказать не может, потому что хорошего бенчмарка для неё пока нет. На мелких задачах ритуал — чистый оверхед.
снимок поста
На снимке: нумерованный список из четырёх артефактов в оригинале и практическая оценка автора: около 30 минут предварительного согласования экономят часы review.
У автора продуктовый агент примерно с десятью скиллами, и чем больше скиллов, тем больше глюков. Лечится это не новой моделью, а полным логом и разбором траекторий вызовов.
Почему важно: в лог идут сообщения обеих сторон, id сообщения, по которому шёл реплай, все tool calls с параметрами и возвращаемыми значениями, число токенов, время отправки и тайминги ответа модели. Отдельный observability-сервис не нужен: автор предлагает сложить всё это в свою БД или в файлы. Больше всего интересного вылезает на пересечении трёх-четырёх скиллов, когда LLM усложняет логику и добавляет лишние шаги. Связывают конструкцию два файла: AGENTS.md с назначением и правилами и PLAYBOOK.md с картой маршрутов по скиллам и few-shot примерами.
⚡ Как применить
Добавить в логгер своего агента семь полей из списка автора и писать их в свою БД или в файлы, без отдельного сервиса.
Вывести траекторию вызовов в одно постоянно редактируемое сообщение прогресса, прогнать пять типовых вопросов и вычеркнуть шаги, которых нет в ожидаемом маршруте; для одного лишнего шага упростить инструкцию скилла или добавить few-shot в PLAYBOOK.md.
Раз в пару дней запускать отдельный прогон по накопленным диалогам с задачей предложить правки скиллов, а правки принимать вручную и коммитить новой версией.
Проверка: взять вопрос, на котором был лишний вызов скилла, прогнать после правки и сравнить по логу число tool calls и тайминг ответа.
Риск сбор фидбека держится на потоке живых пользовательских диалогов — у агента без пользователей этот приём пуст. Замыкать цикл самоулучшения без ручной приёмки автор прямо не советует и сам называет свои приёмы далёкими от промышленных решений.
фрагмент поста
На снимке: нужный фрагмент поста, а не пост целиком — именно та траектория, которую карточка предлагает логировать. Остальная часть поста к приёму не относится: открывается он шуточным фото и содержит посторонние отступления.
Stack flattening: вместо библиотеки-комбайна с кучей ненужных фич попросить агента реализовать прямо в коде проекта ровно те 5% функциональности, которые нужны.
Почему важно: у автора BDD-спеки запускались последовательно, на одном ядре ноутбука. «Запускатор» — всего несколько файлов внутри проекта, поэтому он попросил Codex распараллелить выполнение, и тот сделал это в режиме piecemeal growth, добавив 55 строк кода. Подстраивать чужой комбайн под себя бывает сложнее, чем написать нужный минимум.
⚡ Как применить
Выбрать одну зависимость из хвоста мелких второстепенных — или свой внутренний «запускатор», который проще написать, чем настроить.
Попросить агента реализовать ровно нужный минимум внутри проекта, маленьким диффом: у автора вышло 55 строк.
Проверка: прогнать те же спеки и сверить, что passed/failed не изменились; если выигрыш по скорости в вашем объёме незаметен, оставлять только когда паттерн переносится в проекты, где спеков больше.
Риск автор сам ставит границу: речь не о том, чтобы заменить все зависимости, а только хвост мелких второстепенных. Выигрыш он честно обесценивает — на его объёме экономия десятков миллисекунд погоды не делает. И свой минимум вы дальше сопровождаете сами.
снимок поста
На снимке: те же 55 строк и тот же вывод консоли, что в карточке, плюс сноска [1]: речь не о замене всех зависимостей, а только хвоста мелких второстепенных.
Ответ скептикам, спорившим про агентов, которые пишут код ad-hoc вместо готовых CLI: автор показывает, что во встроенных скиллах Codex агент чаще пишет inline-код поверх библиотеки, чем дёргает собственную обёртку.
Почему важно: список поимённый, и его можно сверить со своими скиллами. Browser и Chrome — inline JS через Node REPL и browser-client; computer use — inline JS с @oai/sky; presentations и spreadsheets генерируют .mjs с @oai/artifact-tool; pdf — Python с reportlab, pypdf и pdfplumber. Для documents автор отдельно помечает, что там есть готовые CLI-хелперы.
⚡ Как применить
Взять один свой скилл для агента и разметить по этой оси: агент пишет inline-код поверх библиотеки — или вы обернули всё в собственный CLI.
Прогнать одну задачу этого скилла без своей обёртки и посмотреть, решит ли агент её inline-кодом через названную библиотеку.
Проверка: не решает — обёртка остаётся; решает — обёртку можно снимать и сокращать шаги.
Риск автор сам пишет, что переводить всё на этот подход не нужно, и никаких подтверждений, кроме «посмотрите сами», в посте нет: ни ссылки, ни кода, ни замера.
снимок поста
На снимке: разбивка «что чем сделано», из которой и выросла карточка. Одна оговорка: в подвале снимка Telegram подписывает пост как t.me/oestick/550 — это тот же канал «AI и грабли» и тот же пост 550, просто у канала сменился username, а прежний адрес продолжает открываться.
Снова один из самых быстрорастущих репозиториев на GitHub по звёздам. Автор сразу просит не верить тем, кто кричит «лучший инструмент»; разбор установки и минусов он вынес в видео, в тексте поста приёма нет.
Официальный MCP-сервер сервиса не работал, поэтому автор натравил своего агента на API-документацию, и тот собрал локальный MCP-сервер сам. Идея переносимая, но описана на материале спортивных приложений, без конфигов и замеров.
Append-only журнал действий и авторизаций, ссылки вместо самих данных в журнале, единый контракт действий для человека и LLM при разных полномочиях. Правильная рамка, но это перестройка архитектуры на дни, а не вечерний эксперимент.
125B-A6B, уже поддерживается vLLM и SGLang. Интересен форм-фактором: такую модель можно держать на локальной машине со 128 ГБ памяти и отдать ей дешёвые вспомогательные шаги агента.
Разбор playbook Anthropic с Антоном Костериным: цепочка intent.md, spec.md и проверенного человеком plan.md, hooks только под проверяемые запреты. В посте — перечень тем выпуска, поэтому как писать эти файлы, оттуда не узнать.
Из 68 прочитанных сообщений в дайджест дошли 14: девять постов в семи карточках и пять на радаре. Остальные 54 отсеяны — вот по каким причинам.
Шутки, мемы, one-liners 11Реклама, эфиры, вакансии 13Железо и сделки без следствия 8Модели и бенчмарки без применения 9Пересказы без проверяемого действия 13
🎯
План на неделю
Из всех выводов выше — три, которые реально внедрю. Не «прочитать», а сделать.
Сделать: в одном тикете поставить агенту задачу «предложи минимальный проверяемый шаг и остановись», реализацию разрешить только после «ок», и закрыть ревью в тот же день
до пятницы
Сделать: написать одно правило ast-grep на легаси-паттерн, закоммитить baseline нарушений и уронить CI тестовым нарушением в отдельной ветке
до среды
Сделать: прогнать один тикет двумя способами — один агент против двух в отдельных worktrees — и сравнить долю смерженных PR
до воскресенья
#
Метаданные
сгенерировано 2026-08-31T06:20:00Z
окно 2026-08-24 — 2026-08-31 (7 дней)
прочитано / в дайджест 68 сообщений / 7 выводов и 5 пунктов на радаре
источник живой tdl chat export за окно, 13 каналов, экспорт по chat_id
каналы с постами 13, молчали 0, недоступны 0
ссылки 68 из 68 точные (t.me/<username>/<id>), best-effort нет
дубли между каналами 1 (снят автоматически, в дайджест не попал)
снимок поста
