Язык, который вызывает те же драки, что и «Чёрный квадрат» Малевича Стоит упомянуть Оберон в сообществе программистов, и от него не остаётся камня на камне. Автор видел, как из-за этого языка умирали целые сообщества, а когда обмолвился, что собирается писать статью, ему в личку пришёл человек с просьбой не писать. Пазл сложился, когда он однажды услышал, как люди обсуждают «Чёрный квадрат». Реакция та же, что у зрителя перед Малевичем: «ну я так тоже могу, почему это в галерее, а не на помойке». Оберон устроен так же радикально. Нет привычного ООП, управление памятью отдано сборщику мусора, а цикла FOR просто нет. При этом на таком минимуме написана целая операционная система, запускающаяся прямо на голом железе, а Java и Go оказались его прямыми наследниками. Посмотрим, докуда дотягивается параллель с картиной, которую все ругают и все знают.

И еще одна интересная статья: главный навык агентного кодинга – знать, чего ты не знаешь Пишут, что Fable – первая модель, где качество результата упирается не в модель, а в вас! (та-даам) Точнее, в вашу способность прояснять свои unknowns. Типа карта – это ваши промпты, skills и контекст, то есть то, что вы даёте агенту. Территория – кодбаза и реальные ограничения, где работа на самом деле происходит. Разница между ними = unknowns. Чем больше объём работы, тем больше таких дыр агент встретит и тем чаще будет угадывать, чего вы хотели. Дальше они разбирают как раз классический квадратик 2х2: – Known knowns – то, что вы написали в промпте – Known unknowns – то, что вы ещё не решили, но знаете об этом – Unknown knowns – то, что для вас настолько очевидно, что вы никогда это не запишете, но узнаете, если увидите – Unknown unknowns – то, о чём вы вообще не думали Автор говорит: посмотрите, как промптят крутые программисты – у них почти нет unknowns, они в синхроне и с кодбазой, и с поведением модели. И это тренируемый и очень важный скилл. Чего делать-то надо: – Blind spot pass – перед работой в незнакомой части кодбазы прямо просить Claude найти ваши unknown unknowns, буквально этими словами. «Я ничего не знаю про auth-модули здесь, сделай blind spot pass и помоги мне промптить тебя лучше» (!) – Прототипы до имплементации – ловить unknown knowns дёшево. «Сделай HTML со страницей в 4 радикально разных дизайн-направлениях, я отреагирую» – Interviews – просить Claude интервьюировать вас по одному вопросу, приоритезируя те, где ответ меняет архитектуру – References – лучший референс не скриншот и не доки, а source code. «Вот Rust crate с нужным backoff, прочитай и реимплементируй семантику в нашем TypeScript-клиенте» – Implementation plan – но с фокусом на то, что вы скорее всего захотите поменять: data models, интерфейсы, UX. Ну и записывать артефакты, чтобы можно было понять, что и как создавалось и как теперь работает: – implementation-notes.md во время работы – логи отклонения от плана в раздел Deviations – Квиз после – просить Claude сделать отчёт по изменениям и квиз в конце. Мерджить только после того, как ты сдал квиз на 100%. Это прикольный конечно паттерн, типа: честный ответ на вопрос «а вы понимаете, что агент вам намерджил?» Короче, хватит уже модели ругать, пора смотреть в зеркало https://claude.com/blog/a-field-guide-to-claude-fable-finding-your-unknowns

Anthropic объяснила, когда стоит играться в effort level (спойлер - нечасто) Вышел пост от команды Claude Code про то, чем отличаются два главных «крутила» в Claude Code: выбор модели и effort level. Главные тезисы: – Модель = набор замороженных весов. Всё, что Claude «знает» про TypeScript и Go, зашито туда на этапе тренировки. Промпт и CLAUDE.md – это steering, а не teaching: модель ничему не учится, вы просто подсовываете контекст на один запрос – Effort – это НЕ «время подумать». Это сколько работы модель готова проделать за ход: сколько файлов прочитает, запустит ли тесты, будет ли перепроверять себя, и как далеко утащит мультишаговую задачу до того, как вернётся к вам – Effort передаётся в модель прямо в запросе, как ещё один input. Поведение на каждом уровне выучено при тренировке. На высоком effort та же задача может сжечь примерно в 7 раз больше токенов ради более уверенного ответа – При этом effort задаёт потолок, а не план: если первая гипотеза в дебаге сработала, модель скипнет остальные проверки, а не будет искусственно наматывать токены. Anthropic говорит, что специально борется с overthinking на тренировке. При этом пишут, что чаще всего дефолтных значений хватает 80% пользователей. Практическая эвристика, когда что-то пошло не так: – Claude всё прочитал, честно старался и всё равно ошибся – проблема в capability, берите модель побольше – Claude скипнул файл, не запустил тесты, бросил рефакторинг на середине – проблема в старании, поднимайте effort – Но сначала проверьте контекст: кривой промпт лечится не крутилками, а нормальным CLAUDE.md Есть и красивая аналогия: Fable – это узкий специалист, который видел проблемы, которых не видел никто. Opus – эксперт, Sonnet – хороший generalist. Opus на low effort = пять минут с экспертом, Sonnet на high effort = целый день работы толкового джуна-плюс, который вычитает весь ваш код. Fable даже на low effort замечает то, что остальные не увидят, но и стоит соответственно. Про экономику честно: на рутине большая модель просто дороже без прироста качества. На сложных multi-step задачах наоборот – маленькая модель идет итерациями к потолку своих способностей, а большая доходит до результата за меньше шагов, и cost per task может выйти ниже. Короче, главный совет от самой Anthropic – не трогайте крутилки. Дефолтный effort откалиброван под то, что «большинство людей хотело бы потратить на задачу», а модель меняйте не по вайбу, а по диагнозу: не знал или не старался. Прикольно, что антропик сам пишет «не платите нам за модельку, которая задаче не нужна». https://claude.com/blog/claude-model-and-effort-level-in-claude-code

Threat Modeling - это систематический процесс, при котором мы заранее думаем: «Как нашу систему могут взломать или причинить ей вред?» Это как "мозговой штурм по безопасности" еще до того, как написали большую часть кода. Мы пытаемся поставить себя на место атакующего и найти слабые места, пока их ещё можно легко исправить. Зачем это нужно? (Почему это важно) - Большинство уязвимостей появляется не из-за "сложных хаков", а из-за неправильных решений на этапе дизайна. - Исправить проблему на этапе проектирования в 10–100 раз дешевле, чем после запуска в продакшен. - Это помогает принимать осознанные решения: где нужно усилить защиту, а где можно сэкономить. И вот вам data flow диаграмма, составлял сам на примере сервиса доставки еды

Первый официальный State of PHP опрос открыт: https://jb.gg/php-survey-2026 В сообществе уже было много опросов, но официального охватывающего весь PHP-мир, до этого не было. И вот PHP Foundation запартнерился с JetBrains, чтоб провести такой и сделать его ежегодным. Мы взяли за основу вопросы из PHP-секции JetBrains DevEco. Обновили немного. Потом запустили сбор идей вот тут. После этого еще раз обновили на основе ответов в этой форме и комментариев. Не обошлось и без косяков. Сначала добавили секцию про AI, но фидбек был не очень, поэтому приняли решение сделать секцию полностью опциональной в опросе. В общем учтем недоработки обязательно в следующем году. А пока предлагаем пройти текущий опрос! Занимает около 15 мин. И конечно же, результаты будут полностью публичными, включая сырой датасет. Пожалуйста, помогите распространить среди коллег и сообщества – чем больше ответит, тем лучше будут данные. А если большинство проголосует за true async в вопросе про желаемые фичи, то это будет хорошим аргументом в пользу соответствующего RFC. Ну или против, если мало проголосует 😈

📌 Anthropic предлагает делать самоуправляемые циклы Команда Claude Code опубликовала в X руководство по loops. Это паттерны, в которых агент повторяет рабочий цикл, пока не сработает условие остановки.

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

Всего выделяют 4 типа циклов, различая их по способу запуска, условию остановки и степени автономии. Логически получается некая лестница делегирования, где на каждой ступени вы отдаёте агенту очередное полномочие. 🟡Агентный цикл запускается промптом и завершается, когда Claude считает задачу выполненной. Здесь вы отдаёте агенту проверку. Ручные шаги верификации заполняются вSKILL.md и чем более количественные критерии, тем точнее агент оценивает собственную работу. 🟡 Целевой цикл /goal забирает у вас условие прерывания Вы описываете, что значит готово, а дальше при каждой попытке Claude завершить работу отдельная модель-оценщик сверяет результат с вашим критерием (скажем, долей пройденных тестов) и возвращает агента к работе, пока цель не достигнута или не исчерпан заданный лимит попыток. 🟡Временной цикл /loop или /schedule берёт на себя триггер запуска. Это удобно для повторяющейся рутины и при работе с внешними системами (например, дайджест по таскам, реакция на новое ревью или упавший CI). 🟡Проактивный цикл убирает человека из контура. Рутина срабатывает по событию или расписанию и живёт, пока вы её не выключите. В связке с динамическими воркфлоу агенту передаётся уже сам промпт. Вот этот сценарий уже ближе всего к полной автоматизации. 🟡Дополнительные советы

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

@ai_machinelearning_big_data #news #ai #ml

Последние несколько месяцев наблюдаю, как около CG IT тусовочка сошла с ума по Threejs, React и webgl. Чего там только не пилят, но из интересного это всякого рода тулзовины, которые могут облегчать жизнь. Я честно говоря сам поддался на красивые риалтайм тулы и попробовал наковырять себе швейцарский нож, для проводов, всяческий скрэпных конструкций и т.д. Сложного по началу ничего нет, главное наличие Codex или Claude Code. В начале у вас эйфория, что первый пас такой быстрый, потом вы начинаете думать, что хотите улучшить, потом уходите в функционал который уже есть в других софтах или вообще делаете не то для чего изначально начинали заигрываясь. Так что тут тоже никуда не деваешься от планирования, от принципов построения систем, от каталогизирования, нумерации багофиксов, версионности, рефакторинга и всей прелести аккуратного креаторства. Очень важно не делать большие проекты не убедившить какой точно результат вы хотите получить в конце. Закладывайте архитектуру на расширение, на дополнительные модули и т.д. Обсуждайте в конце концов ваши идеи с гпт или клодом, они вам помогут составить правильную структуру, сформировать тз и заложить возможность безболезненной модификации на будущее. @CGIT_Vines

Мне повезло в начале 2010-ых застать всю ту пиздецому, которая происходила в период JS революции. Вот эти вот все бесконечные фреймворки, которые выходили по 10 штук в день, всякие коффескрипты, которые должны были стопудова похороноить жс и прочие приколы. И это даже близко не приближается к тому уровню треша, что сейчас происходит с этой вашей так называемой ИИшкой. КАК ЖЕ Я ЗАЕБАЛСЯ ЭТО ВСЕ РАСКУРИВАТЬ. Но это то ладно, после того как всё это будет впихнуто в примерно в 1.5-2 часовое видево. Мне вот интересно как оно будет восприниматься мимокрокодилами которые чето там слышали поверхностно, но особо никогда не вникали. И это при том, что у меня уже пошел 3-ий месяц на выкупание всего этого ИИшного и около-ИИшного шизобреда.

Глобальная чистка: Xiaomi готовит HyperOS 4 без старого кода MIUI Xiaomi в августе выпустит HyperOS 4, которая полностью избавится от наследия MIUI десятилетней давности. Разработчики переписали ядро системы с нуля, используя языки Rust и Flutter, что позволило радикально оптимизировать работу устройств. Отказ от старого кода снизит потребление оперативной памяти на 25–30%, приложения будут на треть лучше удерживаться в фоновом режиме, а плавность анимаций интерфейса вырастет на 40%. При этом деградация производительности смартфона после года использования составит скромные 5%. Визуально система перейдет на дизайн «Liquid Glass» с настраиваемой прозрачностью элементов. Главной фишкой станут локальные нейросети: ИИ-модель Xiaomi Mimo и голосовой помощник Miclaw будут обрабатывать запросы прямо на устройстве, без отправки данных в облако.

hh показал, что находится под капотом у корпоративного LLM-судьи для нейроразбора резюме и как он оценивает ошибки и галлюцинации. LLM-судья — это модель, проверяющая другие модели. «Наивные» судьи могут галлюцинировать оценки, поэтому для качественного вердикта от общей шкалы отказались в пользу чётких критериев — рубрик. Чтобы сформировать каждую из них, понадобились десятки позитивных и негативных примеров. «Грамотный» судья способен хорошо различать не только очевидные попадания и промахи, но и пограничные случаи. Из деталей — отказ от общей шкалы, около сотни положительных и отрицательных примеров для каждой рубрики, отдельная таксономия ошибок и вывод: маленькой модели иногда достаточно, если критерии хорошо разложены. Чтобы выявить дефекты рубрик, использовали подход RIFT — таксономию типичных ошибок в критериях оценки. Финальный продукт работает в четыре этапа: валидация входных данных, извлечение доказательств, вердикты по рубрикам и расчёт итогового скора. Последний этап вынесли в код: финальную оценку даёт не модель. О разработке LLM-судьи и вынесенных уроках вышла статья в блоге hh на Хабре.