Dagens Vibes — 18. juni 2026

Block@blocks

We built an internal AI system called Builderbot. It coordinates agents across our entire codebase. Engineers tag it in Slack, and it researches, plans, and ships. The story so far: - 200,000 operations per day. - 1,500 pull requests merged per week. - 15% of all production code changes across Block. What used to take months now takes days. How we built it: block.xyz/inside/block-r…

Vercel@vercel

Introducing eve, an agent framework. 𝚊𝚐𝚎𝚗𝚝/ 𝚊𝚐𝚎𝚗𝚝.𝚝𝚜 𝚒𝚗𝚜𝚝𝚛𝚞𝚌𝚝𝚒𝚘𝚗𝚜.𝚖𝚍 𝚝𝚘𝚘𝚕𝚜/ 𝚜𝚔𝚒𝚕𝚕𝚜/ 𝚜𝚊𝚗𝚍𝚋𝚘𝚡/ 𝚜𝚌𝚑𝚎𝚍𝚞𝚕𝚎𝚜/ Like Next.js, for agents. vercel.com/blog/introduci…

fks@FredKSchott

Just Shipped: Flue 1.0 Beta Flue is the TypeScript framework for building the next generation of agents, designed around an open agent harness with zero LLM lock-in. It’s like Astro, for agents. Flue 1.0 has been redesigned around three core primitives: 🔁 Workflows — structured automations designed for background work, where your code drives the agent from start to finish. 🧭 Agents (New!) — autonomous, stateful loops where the model drives itself to complete a given task. 📡 Channels (New!) — connect agents to Slack, GitHub, Linear, Discord, Teams, and more. Flue handles the boilerplate for you. Everything shares the same durable foundation, powered internally by Pi, Vite, and Durable Streams. Deploy anywhere, use any LLM, and recover running agents across restarts and downtime. We’ve talked to a lot of teams building agents, and keep hearing the same thing: getting to production is hard work. We built Flue to help change that. Flue 1.0 Beta is available today. Give it a try and let me know what you think!

Z.ai@Zai_org

Introducing GLM-5.2: Frontier Intelligence, Open Weights - Significant improvements in coding and agentic tasks - Strong long-horizon capabilities with a 1M context window - Two levels of reasoning effort: GLM-5.2 (max) pushes the limits, while GLM-5.2 (high) strikes a strong balance between performance and token efficiency - MIT-licensed open weights - Same API pricing as GLM-5.1 Tech Blog: z.ai/blog/glm-5.2 Weights: huggingface.co/zai-org/GLM-5.2 API: docs.z.ai/guides/llm/glm… Coding Plan: z.ai/subscribe Chat: chat.z.ai

OpenSquilla@OpenSquilla

Run the same coding tasks while varying the model and the harness (the layer wrapped around the model that actually drives it), and the spread is wild: Change only how the agent hands in its work → the success rate jumps from 19% to 73%. Change only the harness → success rates differ by up to 27 points. Change only the model → the bill can differ by up to 170×, even when the final results are just 8 points apart. You really should dig into Claw-SWE-Bench, just released on GitHub. It's the latest paper-and-benchmark jointly released by TokenRhythm Technologies, Infinigence AI, City University of Hong Kong, SEE Fund, Peking University, Shanghai Jiaotong University, Beijing Jiaotong University, and Tsinghua University — a remarkably principled benchmark that actually reflects what a harness can do. Picking the right harness matters a lot. But among OpenClaw, Hermes, ZeroClaw, GenericAgent, and NanoBot — which one is actually best at coding tasks? Gut feeling? Or a real test? And if you test, how? You test it your way, I test it mine — so how do the results even compare? Claw-SWE-Bench's point is simple: every harness reports its score bundled with its own tasks, budget, prompts, and model — so you can never tell whether a high score comes from a strong model, a strong harness, or easy problems. Claw-SWE-Bench ends this "everyone-tests-their-own-way" mess by building one shared exam that isolates the harness as the single variable being compared: Same exam paper: 350 real GitHub issues across 8 languages and 43 repositories — every harness solves the same set. Same rules: identical problem statements and the same budget (max 1 hour per task, one attempt only, fixed concurrency), all scored by the same official SWE-bench grader. The key move — judge the code, not the talk: whether a harness outputs JSON, plain text, or nothing at all, none of it counts. The grade rests solely on which files it actually changed in the repo. That's what finally lets wildly different harnesses sit at the same table. Anti-cheating: some test environments let the AI peek at "the answer from the future." The paper scrubbed all of these leaks. It scores cost, not just correctness: every harness must also report how much money it burned, how long it took, and its cache hit rate — because two setups with near-identical accuracy can have bills that differ by 100×. Adding a new harness? Just write a small adapter. Any harness that implements a handful of fixed interfaces plugs straight into the exam — no changes to the task set or grader. So it's not a one-off test of these five; it's a standard that can keep growing. It also ships an 80-task Lite version that costs only ~23% of the full run yet reproduces roughly the same rankings — handy for fast iteration. Paper & code: github.com/opensquilla/cl…

Sam Bhagwat@calcsam

Yesterday, Mastra was hit by a supply chain attack. A malicious postinstall script that exfiltrated credentials and then self-deleted was added to specific versions of our npm packages. Most importantly: the incident is over. All relevant package versions are unpublished. The root cause is that one of our maintainers was compromised. Between 6:12 PM and 6:37PM PT yesterday, a token associated with their account published 116 malicious NPM packages, almost all in the `@mastra/` namespace. We became aware of this at 8:45pm PT. We immediately contacted npm as well as trusted third parties (eg @SocketSecurity). We also began unpublishing, and unpublished 59 packages. As part of the attack, we lost access to some packages. Around 10:15pm PT, we were able to re-add our accounts to those packages. We began unpublishing the rest. In total, we unpublished 110 packages, and deprecated 6. By 11:57pm PT, all affected packages were unpublished or deprecated. At around 1am PT, we also published new, safe versions of each package affected (github.com/mastra-ai/mast…), so that installs would resolve We have always required MFA on NPM for maintainers, but we also allowed (mistakenly) token bypass. Also around 1am PT, we removed token bypass across all packages. At 2:25am PT, we established contact with the compromised maintainer. He is a current, active Mastra employee. His machine was compromised via a social phishing attack. A compromised LinkedIn account reached out to him as well as maintainers of other prominent TypeScript open source packages. He was on a call and clicked a suspicious link. This was the same attack vector as other open-source maintainers have reported (eg x.com/aidenybai/stat…). Around 4:40am, npm responded to the security ticket we'd filed and confirmed the breach. They unpublished the last 6 affected packages. For a third-party report on the incident / malware, including a list of package versions affected, and the mechanisms of the RAT: socket.dev/blog/mastra-np…. We're continuing to keep reducing scope of sensitive credentials and enhance our use of MFA. Security is an ongoing process of review and hardening. Thanks for the hugops. Stay safe out there. I'll be here answering questions.