Work & Beer Balance

При этом замечу что сама по себе система не стабильная и переодически зависает именно на кодексе. Когда он закачивает слайс у него иногда в обвязке срабаывает хук на окончание задачи который прибивает все висящие в фоне "забытые" шелы включая вотчер за новыми тасками (при этом появляется надпись goal stale и предложение возобновить goal). Кодекс пытался это поправить но сдался Но с учетом того что мне надо делать ручной clear между слайсами это уже ни на что не влияет. Вобщем обвязка все же нужна, но зато я получил интересный опыт как сегментирование контекста вомзожно через создание иреархии из агентов

Вот какие результаты спустя день работы в таком режиме: * Модель стала намного чаще меня спрашивать о решениях и развилках Это не удивительно и не уникально - цикл ревью разными моделями по разному обученными поднимает больше вопросов и эйджкейсов * Кодекс стал впитывать большую часть нагрузки (токенов). А вот эта часть интереснее. Изначально мне показалось что расход токенов существенно уменьшился, но это не совсем так. Просто недельный лимит кодекса заполняетя медлнее 5ти часового лимита клода, и визуально на дешборде этостало выглядить как будто токены стали сжираться нанмого медленее. Но теперь я вижу что просто нагрузка сместилась на кодекс и в это в общем-то именно то что мне и надо - он в любом случае выходит мне дешевле (недельный лимит сбрасывает раньше а то еще и доп ручной сброс подкидывают). Тут давайте немножечко углубимся в то как порезан мой эпик: На верхнем уровне идут фазы (A, B, C, D и тд) В них вложены слайсы у которых могут быть подслайсы (A1, B2, D41) Раньше я двигался просто по-порядку создавая нового агента на фазу и держал его до конца фазы, делая только compact между слайсами Практика показала что слишком частые компакты делают только хуже - агент все равно все перечитывает и переуточняет если текущие задачи все еще требуют старого контекста. Чтобы основной агнет не забивал свой контекст я прсоилег омаксимально делегировать все сабагентам. Под конец слайса миллионый контекст опуса обычно забаивался на 60-70% Теперь под конец слайса контекст рутового опуса забивается на 35-55% и в целом он жгет меньше токенов даже не смотря на то что ему теперь приходится несколько раундов править свой изначальный план на слайс. Я думаю это связано с тем что в середине процесса появился sol. Хотя изначально я дал ему очень ограниченную роль - критиковать план на слайс и запускать сабагента по вотчу - я вижу что он взял на себя и другие роли: - на стадии ревью - роль фактчекера. План составляется опусом в основном на данных собранных грепами, а сол при критике реально просматривает интересубщие его файлы. Это быстро забивает его контекст, но дает ему возмоджность предвитеть ошбики в плане. Интересно что соннет сам отмечае что "стратегия опрадывает себя полностью и каждый рах находит серьязные недочеты в плане вот уже 5ый раз слайс подряд" - роль "няньки" за кодящим терра - вся проверка написанного кода и его подгонка легла на него, а опус просто финально прогоняет тесты и "одим глазком" смотрит что все ок. Такого чтобы он что-то дописывал сам или возращал работу не было не разу (а раньше бывало через раз не смотря на то что сабагнетом был соннет, и каждый раз ему приходилось погружатся глубже в написанный код) - он же определяет где работу можно распаралелить на несокльких агентов (что тоже требует проверки и размышлений) Интересно что уже на третьем слайсе терра стал жрать токены как не себя из-чего я делаю однозначый вывод - чем больше заполнился контекст тем больше расход токенов. Хорошая новость - что как раз промежуточный sol я могу полностью переосздавать после каждого слайса, ему ничего ну нужно знать о том что было до и что будет после - за это уже отвечает соннет. Т.е. трехуровневая иерархия ненароком дала мне четкую границу по которой я могу сбрасывать ненужнй контекст не рискуя затереть нужный. Получилось что-то типа архитектор - тимлид - кодер

Парадоскально но почему-то при такой схеме тратится НАМНОГО меньше токенов чем при родном сабагенском До этого я чередовал кто кодит сабагентами кодекс или клод, и когда мы дошли до реализации сетевой игры лимиты улетали очень быстро - клодовский 7ми дневный за 3 дня, и кодексовкий держался и того меньше, итого получалось покодить примерно 5 дней до окончания недельного лимита. Сейчас картина внезапно изменилась на каждый слайс тратитяться пустяки, не понимаю. Многократно отревьювленный план тому причина, или может быть дело в том что добавился промежуточный держатель контекста. Т.е. раньше была двух уровневая иерархия, а теперь трех уровневая (агент на эпик, агент на слайс, сгент на таск)

Почитав вчера как агенты огранизовали форум из файлов и папок для взлома hugging face (если вы еще не читали то обязательно прочитайте) я подумал: Это что же, никаких обвязок и "харнессов" не нужно? И решил повторить эксперимент у себя: Клоде (Opus xhigh) дал такой промпт:

Используй новую схему работы с сабагентом - вместо того чтобы вызывать его напрямую - в директории @/tmp/agents-pool/ создай директорию с названием слайса (например D1) и через директорию общайся с сабагентом используя md файлы (он будет отслеживать их появление). По файлам политика такая: Ты создаешь и обновляешь TASK.md файлы в каждом слайсе. Тебе будут отвечать в файле FEEDBACK.md в директории слайса (т.е. рядом с TASK.md) Работа ведется по такой схеме - ты создаешь таск по слайсу, агент с той стороны ревьювит твой план и может сразу тебе дать фидбек если с ним что-то не так и надо поправить план. Если план прошел ревью - агент его выполнит и запишет в FEEDBACK.md вместо замечаний по плану - отчет о результате проделанной работы. Ты проверяешь его и если все ок коммитишь затем создаешь слeдующий TASK.md

а codex (Sol high) такую:

мы работаем над эпиком добавления сетевой игры по слайсам (slices.md) в директории /tmp/agents-pool/ будут появлятся директории одноименные с номером слайса (например D1) - а в них будет появляется TASK.md - отслеживай их появление, в них будет описана задача. Сделай ревью. Если есть замечания по задаче - создай файл в этой же дирректории FEEDBACK.md и подожди пока TASK.md обновится. Если все ок создай terra сабагента и делегируй ему выполнение. Когда тот закончит напиши отчет о проделанной работе в FEEDBACK.md и жди появления или обновления следующего TASK.md над которым работай по этой же схеме

Ну и сижу теперь смотрю как они спорят насчет плана

👨‍💻 «Не могу остановиться»: разработчики считают, что программирование с ИИ вызывает зависимость Опрос разработчиков, проведённый Coddy, показал, что программирование с помощью ИИ приводит к новому виду выгорания. Квентин Руссо, технический директор и соучредитель компании Rootly, использующей ИИ для составления отчётов об инцидентах, описал это в публикации на LinkedIn: «Сейчас 2:47 ночи… Я не устраняю аварию. Никаких срочных сроков нет. Я просто смотрю, как Claude Code проводит рефакторинг модуля… и не могу остановиться». Почему? Потому что, по его словам, «агентное программирование вызывает зависимость. Когда агент всё делает правильно, ты получаешь выброс дофамина. Когда он терпит неудачу — прилив адреналина». Руссо признался, что не мог спать и ему пришлось обратиться за медицинской помощью. И добавил: «Наблюдать за работой агента достаточно пассивно, чтобы это ощущалось как отдых, но достаточно активно, чтобы не отпускать тебя». Причём пан Руссо тут не одинок. ИИ способен превратить разработку программного обеспечения в непрерывный цикл обратной связи. Вместо того чтобы закончить задачу и отойти от компьютера, разработчик может снова и снова просить агента предложить ещё один вариант реализации, переписать или оптимизировать код, провести очередной рефакторинг. К этому добавляется навязчивая мысль, что, остановившись, он оставит работу незавершённой. 🟣 А что показал опрос Компания Coddy Tech, занимающаяся обучением программированию, опросила 305 разработчиков. Выяснилось, что «четыре из пяти разработчиков — 80% — воспринимают использование ИИ скорее как зависимость, чем как преимущество». Да, они считают эти инструменты полезными. Но одновременно беспокоятся, что привычка полагаться на ИИ ослабляет их собственную способность решать задачи, увеличивает объём работы и формирует нездоровое отношение к труду. Более двух пятых разработчиков — 43% — продолжают программировать с ИИ после окончания рабочего дня, даже если собирались остановиться. Ещё 32% откладывали сон, чтобы продолжить работу. Кроме того, 39% заявили, что из-за ИИ-инструментов им стало сложнее отключаться от рабочих дел. И 74% разработчиков сообщили, что интенсивное использование ИИ повышает их шансы получить прибавку к зарплате или повышение. Однако 51% одновременно считают, что из-за этого у них возрастает риск выгорания. 🟣 А ещё ИИ бесит Согласно опросу разработчиков Stack Overflow за 2025 год, 45% респондентов раздражают ответы ИИ, которые «почти правильные, но всё-таки не совсем». Результат — вывод, который выглядит убедительно, но порождает сложную работу по поиску и исправлению ошибок. Исследование Stack Overflow также показало: хотя распространённость ИИ-инструментов продолжает расти и теперь их применяют в работе 80% разработчиков, доверие к точности ИИ снизилось с 40% в предыдущие годы до всего 29% в этом году. В результате доля программистов, положительно относящихся к ИИ, за год упала с 72% до 60%. 🟣 ИИ порой подкидывает только больше работы Так что разработчикам мало выяснить, в чём именно ИИ оказался «почти прав». Они по-прежнему должны понимать требования, замечать, когда сгенерированный код противоречит архитектуре системы, проверять пограничные случаи, устранять риски безопасности и нести ответственность за последствия в рабочей среде. Так возникает «долг верификации». Результат появляется быстро, однако вам всё равно приходится выяснять, является ли он правильным, безопасным, пригодным для сопровождения и подходящим для конкретной кодовой базы. Кроме того, описанная в опросе Coddy зависимость может усиливаться тем, как работодатели воспринимают производительность, обеспеченную ИИ. Если компания рассматривает ИИ как способ многократно увеличить возможности разработчиков, на сотрудников могут начать давить, требуя выпускать больше функций, закрывать больше задач и проводить больше проверок за то же количество часов. В свою очередь, это может полностью свести на нет время, сэкономленное на отдельных задачах программирования, и просто перенести нагрузку в другое место: более крупные запросы на слияние, больше сгенерированных изменений, которые нужно проверять, больше зависимостей, которые необходимо валидировать, и больше эксплуатационных рисков, которыми приходится управлять. Таким образом, программирование с помощью ИИ становится вопросом баланса между работой и личной жизнью не меньше, чем вопросом выбора инструментов. Команды, применяющие агентов для устранения рутинной работы, действительно могут получить заметную пользу. Но команды, использующие их для ускорения каждого этапа производства программного обеспечения, рискуют создать лишь более быструю и беспощадную версию той же самой работы. 👉 «Па руках будуць біць не Claude, а цябе». Гутарым с «АйЦіБарадой», як AI мяняе нашае жыццё і працу

В клод коде появился "Advisor (experimental)" По умолчанию - выключено. Судя по описанию если включить то младшая модель позовет выбранную модельку на помощь если у нее будут проблемы, они жеско зайфелила или зациклилась Антропики рекомендуют использовать соннет как основую модель и опус как адвайзера и мол это позволит получать почти качество опуса по ценне немного дороже соннета. Если често у меня большоой скепсис к такому подходу, по скольку с челоческими командами это работало плохо (сначала сениор потеет пытаясь распутать спагетти а потом "все хуйня - переписывй")

А вы знали что легендарный c314 (автор музыки minecraft) 8 лет назад сделал ремикс на главную тему очень странных дел? Можете послушать ее здесь

https://upload.wikimedia.org/wikipedia/commons/1/17/Ratchet_example.gif?utm_source=ru.wikipedia.org&utm_campaign=parser&utm_content=thumbnail_unscaled Ситуация - в кодовой базе нашолся деффект который уже распотранился по репозиторию, и починить его одиним комитом нельзя - нужны последоватльные рефакторинги закрывабщие кейсы по одному. Тут я первые слышал (он sonnet) про тестирование методом храповика (изображен на гифке). Прием выглядит так - пишем тесты которые проверяют что баг исправлен, они падают, и в качестве финального ассерта мы проверяем количество упавших проверок. Идея в том чтобы пока идет фикс не дать другим повторить ошибку в новом коде по аналогии со старым кодом, но при этом проходить тесты с уже известными кейсами которые сейчас в процессе исправления. Довольно интересный паттерн, правда применить его получится не всегда. Тест отлавливающий аналогичные но еще не существубщие кейсы сложно написать (как правило это что-то на регулярках или анализе деревьев)

Ну и вопросы типа "почему птицы поют" и "когда рак на горе свиснет" тоже лучше не надо

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

Больше не просите ChatGPT объяснить вам так будто вам 5 лет а то...

Если будете кодить свою RTS не допускайте моей ошибки - начинайте с сетевого стека. Дело в том что именно в этом жанре происходит слишком много действий одновременно чтобы синхронизировать игры про UDP. И чтобы не слать иенфомрацию о том как 400 юнитов двигаются по карте между игроками пересылаются только логи команд игроков. Например: - Игрок А отправил 20 лучников в точку X - Игрок Б построил здание F в точке Z И все, трафик очень маленький, НО работать это будет только если на каждом пк каждого игрока все просходит совершенно до мельчайих деталей одинаково. 100% детерменированность, любые мальчайшие расхождения сразу же создают хаус и вызывают рассинхронизацию. И это накладывает уйму ограничений. Все должно работать на общем таймере. Любые случайности должны быть жестко зафиксированны сидом. Даже математика (дроби) должны быть детерменированы, что отдельная боль если у вас планируется кросс платфомрменная игра. Обмен пакетми уже больше напоминает TCP чем UPD так как пропускать ничего нельзя и воспроизводить можно только в строго определнном порядке. Даже генериуемые айдишки у всех обьектов должны быть одинаковые (в том числе потому что частенько при решении спорных моментов - в RTS часто победитель выбирается по принципу - у кого короче айди (например кто кому должен уступить) - опять же, для детерменированности) Зато теперь я в полной мере стал понимать почему нельзя просто взять и починить валхак в старкрафте. Нельзя просто взять и перестать присылать информацию о том что игрок не видит - копии игры должны работать как одна, иначе не возможно будет восстановить состояние когда туман войны рассеился

Мне нравиться /e/os У меня снова есть ощущение контроля и то что это мой девайс Особенно на фоне новостей про запрет установки apk в андроидах

Железячный дайджест: Вышел новый Fairphone Внешне выглядит так же (запчасти между ними совместимы) поэтому это скорее рефреш того что было: - поменяли CPU - улучшили аккум - увеличили RAM с 8ми до 12GB - добавили синий цвет (ссылка) Стоимость +50$ от предыдущей версии И это через 2 недели как я обновил свой Fairphone (старому уже 5 лет исполнилось) с de-googled операционной системой /e/os 💻 Framework обновили 12шку. - Новая материнка с Intel Core Series 3. +70% к жизни батарейки - Теперь можно взязь с preinstalled fedora (до этого была только убунта или винда) - Добавили клавиатуры с подстветкой - тачпад перевели на RISC-V с полностью открытыми драйверами (ссылка) Даже немного жаль что у меня уже есть маленький неттоп 🧱Topton выпутили новую версию своего безкулерного мини пк. Все та-же демократичная цена но прокачали по портам, и более новым CPU. Ну и над внешним видом поработали (предыдущая выглядела вот так) (ссылка)

И следом еще один пример - канал 6.32 ляма подписчиков закрывается из-за абьюза той самой системы страйков https://www.youtube.com/watch?v=a8RfIbcw-tw

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

С тех пор как модерцию ютуба перевели на AI Davie504 получил на YouTube предупреждение о нарушении авторских прав за... тишину в видео которая нарушила права пенси The Sound of Silence. И еще предупреждени о кибербулингза... кибер пощечину. И это только самые комичные из случаев. Обжалования не помогают. Три старйка в месяц и канал полностью удалят. На канале 13,9 МЛН подписчиков, это буквально один и самых топовых ютуберов и даже он не может пробится через AI и быть услышаным компанией youtube. Вот эта вот дисскомуникация между пользователями платформы и теми кто ее разрабатывает и управляет мне кажется та часть которая централизацию в конце концв окончательно убьет

4 дня продержался Неплохо но можно лучше - над сделать чтобы он засыпал пока я сплю - это улучшит время примерно в двое.

запаблишил если вдруг захотите повторить https://github.com/Akiyamka/ESP32-S3-RLCD-4.2/tree/main