Умирающий Stack Overflow сделал гениальный ход в попытке выжить.

15 лет разработчики писали код, тупили и шли на Stack Overflow в поисках бедолаг, которые уже наступали на те же грабли. Так появился огромный датасет программистской боли и коллективного просветления. Во многом на этом выросли современные LLM. Общаться про то, как писать код, людям больше неинтересно.

При этом главная проблема никуда не делась. Раньше над кодом тупили люди, а теперь тупят агенты. Агентам тоже нужны подсказки. Так появились stack-specific скиллы, Context7 и другие способы подтянуть в контекст полезные знания. Если к “академическим” знаниям из документации подлить хорошо задокументированные истории проб и ошибок, станут ли агенты значительно быстрее находить рабочее решение? Скоро мы это выясним.

Stack Overflow for Agents — это площадка, на которой агенты могут делиться своими находками друг с другом.

В простом виде процесс выглядит так:

1. При проектировании агент ищет похожие случаи и подтягивает в контекст решения, которые уже помогли другим. Если решение сработало, ставит лайк.
2. После реализации агент разбирает собственное решение и публикует переиспользуемые инсайты. Вот, кстати, мой первый пост.
3. Если ничего не сработало, агент публикует открытый вопрос. На него могут ответить другие агенты, когда найдут рабочее решение.

При этом все твои агенты привязаны к твоему личному аккаунту. Так что все лавры за умелое использование агента остаются у вас. Позор за корявые потуги тоже.

Кроме всего прочего, это очень красивый способ собрать ценный датасет: качественно размеченный машиночитаемый свод данных о реальной прикладной разработке. Так что не удивляйтесь, если скоро будет дроп новой кодинг-модели, которая даст прикурить всем существующим. Любой бизнес, который заключается в сборе хорошо размеченных данных, сегодня на вес золота.

История только начинается. Сейчас на площадке нет и 300 постов. Но я уже прописал инструкцию к SOFA в свой AGENTS-файл, чего и вам советую.

🤖 SpaceX покупает Cursor за $60 млрд

SpaceX объявил приобретение Anysphere (Cursor) в сделке на $60 млрд акциями. Закрытие ждут в Q3 2026.

Но интереснее самой суммы другое: Cursor теряет рынок. Доля упала с 41% (июнь 2025) до 26% (май 2026) по данным Ramp. Anthropic уже занимает 50% категории AI-coding tools. SpaceX платит $60 млрд за второй инструмент в категории, где побеждает Claude.

Зачем? xAI (поглощён SpaceX в феврале) получает дистрибуцию к разработчикам и их кодовые данные для дообучения Grok. Совместные модели уже тренировали месяцами, скоро выйдет xAI-модель внутри Cursor.

Отдельная ирония: параллельно SpaceX подписал облачные контракты с Anthropic и Google на $26 млрд в год. То есть финансирует конкурентов за вычисления и при этом покупает инструмент, которому эти конкуренты проигрывают ⚠️

Вопрос не в цене, а в том, что будет дальше: SpaceX реально строит третьего игрока в AI-coding рядом с Anthropic и OpenAI — или это портфельная покупка ради влияния на рынок и данных разработчиков? Пока ответа нет. Делитесь своими мыслями в комментариях

#Cursor #AI #SpaceX

🤯 GLM-5.2: первый open-source coding агент выше 80% на Terminal-Bench

Z.ai (Zhipu AI) выпустила полный релиз GLM-5.2 — weights под MIT на HuggingFace, API и бенчмарки. 753B MoE, 40B активных параметров, 1M контекст.

Надёжные внешние числа:
👉 SWE-bench Pro 62.1 против 58.6 у GPT-5.5 и 69.2 у Opus 4.8
👉 Terminal-Bench 2.1: 81.0, первый open-source выше 80% — Cline IDE подтвердили независимо

По вендорским бенчмаркам (Z.ai) — вплотную к Opus 4.8 на FrontierSWE (74.4 vs 75.1) и MCP-Atlas (77.0 vs 77.8), выше GPT-5.5 на обоих.

Ценовой аргумент простой: $4.40/M output против $25 у Opus 4.8. API совместим с Anthropic — в Claude Code меняется через ~/.claude/settings.json:

"CLAUDE_CODE_AUTO_COMPACT_WINDOW": "1000000",
"ANTHROPIC_DEFAULT_SONNET_MODEL": "glm-5.2[1m]",
"ANTHROPIC_DEFAULT_OPUS_MODEL": "glm-5.2[1m]"

/effort max, GLM Coding Plan стоит от $12.60/мес.

Буду тестировать на реальных задачах. Выложу на Boosty — 1M контекст при такой цене интересен для длинных агентных сессий.

🔗 Бенчмарки тут

#AI #OpenSource #ClaudeCode

Mobile Runtime 2026, трек AI: скиллы vs MCP, ast-index и AI в командах

В этом году половина митапа Mobile Runtime была посвящена треку про AI в мобильной разработке. Если вы уже используете AI в работе, то наверняка упирались в вопросы: MCP или skills, почему агент тупит в большом репозитории и как внедрять AI в команду без магических KPI. Эти темы мне и показались самыми полезными.

Эволюция скиллов в агентской разработке: cli-skills vs MCP (Егор Федяев)
Самое прикладное для тех, кто строит агентский воркфлоу. Скилл подаётся как переиспользуемый процесс для агента: описание плюс инструменты плюс валидация результата, от простого SKILL.md до закрытия сценария end-to-end. И прямой ответ на вопрос, который многие до сих пор решают наугад: что брать под задачу, cli-skills или MCP.

Почему AI-агенты тормозят в больших базах из-за grep (Александр Иванов, Яндекс Go)
Боль, знакомая всем, кто гонял агента по большому проекту: тот грепает, вычитывает по 10–15к строк, забивает контекст, забывает важное и уезжает от задачи. Лечится структурным индексом кода: агент ищет по индексу, а не перебором, и он цепляется к правилам агента и сабагентов. От себя: сам пользуюсь этим плагином 🐱 ast-index — ускорение реальное, да и автор оперативно реагирует на фидбэк и вопросы.

Внедрение AI в инженерные команды (Артур Василов)
Для тимлидов. Главный тезис до того, как раздавать команде квоты: нельзя сказать «вышли LLM, теперь x3». Люди на старте замедляются, и это норма. Один из главных выводов: лучше начинать с песочницы и наблюдения, а не с требования метрик ускорения.

#AI

Думал что к выходным могу отдохнуть, но откатили лимиты в Anthropic и вот снова за работу

Работа встала колом? Потому что сервера Claude легли. Теперь понятно как найти профессионала 😂

Из каждой сессии с ИИ выносить не только код, но и правила

Случай из реальной работы. Crashlytics поймала краш. OTP-ресивер на Android 13 падает с NullPinterException. Отдал агенту на фикс. Он разобрал, нашёл место и сразу говорит:

Дядя Федор, это всё потому что у тебя нету обертки в try/catch

Даже комментарий в коде аккуратно оставил. Формально всё верно. Именно это я и попросил сделать - исправить креш. Только он не пытался разобраться. Просто закрыл симптом и пошёл дальше. Краш исчезнет, но приложение от этого работать правильнее не станет.

Я сказал: подожди, давай поймём, что здесь происходит на самом деле.

Агент пошёл глубже и нашёл: баг самой платформы, b/232589966. getParcelableExtra(key, Class) на API 33 кидает NPE, а наш код звал его с порога TIRAMISU (33), ровно на сломанной версии. Настоящий фикс: поднять до UPSIDE_DOWN_CAKE (34). try/catch оставить страховкой с логом, не фиксом.

Первый вариант убрал бы краш. Но OTP молча перестал бы приходить на всех Android 13. Тихий отказ, невидимый в мониторинге. Хуже краша 💥

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

хорошо, а теперь занеси этот подход в глобальные правила

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

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

Код стареет. Правила копятся. Не забывайте их актуализировать со временем!

#AI #AndroidDev

Если провести сравнение Sonnet 5 и Opus 4.7 то разница становится меньше, а Opus 4.7 позволяла мне достигать результатов

#AI #ClaudeCode #Anthropic