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

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

С тех пор как модерцию ютуба перевели на AI Davie504 получил на YouTube предупреждение о нарушении авторских прав за... тишину. По мнению youtube это нарушило права пенси The Sound of Silence. И еще предупреждение о кибербулинг за... кибер пощечину.

И это только самые комичные из случаев.

Обжалования не помогают.
Три старйка в месяц и канал полностью удалят.

На канале 13,9 МЛН подписчиков, это буквально один и самых топовых ютуберов и даже он не может пробится через AI и быть услышаным компанией youtube.

Вот эта вот дисскомуникация между пользователями платформы и теми кто ее разрабатывает и управляет мне кажется и есть та часть которая централизацию в конце концов окончательно убьет

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

Скажите, это я под камнем живу и не знал что есть такое жаргонное название, или у нас тут реально свой новояз образовался?

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

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

100% детерменированность, любые мальчайшие расхождения сразу же создают хаус и вызывают рассинхронизацию.

И это накладывает уйму ограничений. Все должно работать на общем таймере. Любые случайности должны быть жестко зафиксированны сидом. Даже математика (дроби) должны быть детерменированы, что отдельная боль если у вас планируется кросс платфомрменная игра. Обмен пакетми уже больше напоминает TCP чем UPD так как пропускать ничего нельзя и воспроизводить можно только в строго определнном порядке.

Даже генериуемые айдишки у всех обьектов должны быть одинаковые (в том числе потому что частенько при решении спорных моментов - в RTS часто победитель выбирается по принципу - у кого короче айди (например кто кому должен уступить) - опять же, для детерменированности)

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

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

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

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

gif

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

Тут я первые услышал (от sonnet) про тестирование методом храповика (изображен на гифке).

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

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

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

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

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

Антропики рекомендуют использовать соннет как основую модель и опус как адвайзера и мол это позволит получать почти качество опуса по ценне немного дороже соннета.

Если често у меня большоой скепсис к такому подходу, поскольку с человеческими командами это работало плохо (сначала сениор потеет пытаясь распутать спагетти а потом все равно будет "все хуйня - переписывй")

Sonnet c эскалацией до фейбла - может быть

управляется командой /advisor

👨‍💻 «Не могу остановиться»: разработчики считают, что программирование с ИИ вызывает зависимость

Опрос разработчиков, проведённый 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 мяняе нашае жыццё і працу

Почитав вчера как агенты огранизовали форум из файлов и папок для взлома 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 над которым работай по этой же схеме

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