Dagens Vibes — 24. juni 2026

Boris Cherny@bcherny

We're launching Claude Tag today. Tag Claude into Slack and it works in channel with you. It’s proactive, multiplayer, with its own identity and memory. But it’s not just a bot in Slack. Over the last few months, it’s totally changed how we use Claude

Citeret tweet

Claude@claudeai

Introducing Claude Tag, a new way for teams to work with Claude. In Slack, Claude joins as a team member with access to the channels and tools you choose. Tag Claude in and delegate tasks to it while you focus on other work.

♥ 17.6k↻ 1.2k💬 961🔖 7.7k

https://x.com/claudeai/status/2069468693017268244

Andrej Karpathy@karpathy

This is a new paradigm for interacting with Claude that is significantly more "inline" with all the other human activity org-wide. Once you do all of the under the hood engineering work to make this "just work" (e.g. across tools, integrations, compute environments, memory, security, etc.), Claude basically joins the team in a seamless way - you can talk to it as you would talk to a person and it can help with a very large variety of workloads. Imo this is the 3rd major redesign of LLM UIUX. The first paradigm was that the LLM is a website you go to, the second was that it is an app you download to your computer. This third one is that it is a self-contained, persistent, asynchronous entity with org-wide tools and context, working alongside teams of humans. It really takes a while to wrap your head around it, but it works and it is awesome.

Citeret tweet

Claude@claudeai

Introducing Claude Tag, a new way for teams to work with Claude. In Slack, Claude joins as a team member with access to the channels and tools you choose. Tag Claude in and delegate tasks to it while you focus on other work.

♥ 17.6k↻ 1.2k💬 961🔖 7.7k

https://x.com/claudeai/status/2069468693017268244

Armin Ronacher ⇌@mitsuhiko

Some more thoughts on looping in coding agents.

Nityesh@nityeshaga

Dynamic workflows might be the most underrated thing Anthropic shipped this year. I posted a mini vibe check on dynamic workflows last week @every because I've been making them left and right ever since they launched. I'm now convinced this is the next groundbreaking concept — the way Skills was last year — and that every major AI agent platform copies it in 2026. This is the way you get to Level 8 and beyond in the Levels of AI Adoption (from @hammer_mt). Commanding fleets of subagents. All because of a genius simple insight - LLMs are a poor orchestrator directly. They get commitment issues when you ask them to orchestrate fleets of subagents for any complex workflow. They start getting context anxiety, negotiating with the plan they may have formulated at the beginning. So you often hear them say things like "I don't need three independent reviewers - let me merge them into one," "this part is solid, I'll skip the review" or "The work is done. Let me know if you want me to launch the review phase." The fix: replace the flaky orchestrator with code. The LLM codifies the shape of the workflow once — then code runs it deterministically. Code doesn't get lazy. And it doesn't even touch the main Claude's context window. I built the entire 30-min deck behind this walkthrough video using four dynamic workflows — launching 100+ sub-agents in a single chat. Context used? 42%. This is a tool for non-technical people The folks most afraid of it have the most to gain. Most hear "JavaScript program" and assume it's for engineers. It's the opposite. Non-technical work — maintaining a Google Sheets dashboard, keeping an Asana board clean — involves hundreds of tool calls and tiny decisions. That's exactly a workflow's shape: different sub-agents, different jobs, in phases. If you have a chief of staff skill or project management skill, try turning that into a dynamic workflow. And you don't need to touch the code. Just ask Claude to write you a dynamic workflow and it knows what to do. Here's a detailed walkthrough of Dynamic Workflow and how I'm using it for this kind of work.

Teknium 🪽@Teknium

Not everything needs an llm involved - Hermes can run regular scripts through its cron system and use its gateway to update you on outcomes without the agent burning money 😇

Citeret tweet

Wolfram Ravenwolf@WolframRvnwlf

Found the dumbest useful optimization in my Hermes Agent setup today: Two hourly maintenance cronjobs were waking the full agent just to run scripts. Switched them to script-only no_agent mode. Savings: ~1.1M tokens/day, ~33M/month. Tiny fix. Huge leak plugged.

♥ 91↻ 5💬 12🔖 68

https://x.com/WolframRvnwlf/status/2069459858286346632

Vite ⚡@vite_js

🚀 Vite 8.1 is out ⚡ Experimental Full Bundle Mode: ~15x faster dev server startup & ~10x faster full reloads on large apps 🧩 Chunk Import Map to keep chunks stable & improve caching 🦀 WASM ESM integration 💡 Lightning CSS on the road to default 👀 and more! Blog post below.

Evan You@evanyou

To answer a common question - why not make React Compiler a plugin? It all comes down to practical trade-offs. Making it a rust-based plugin is already significantly faster than the Babel version (up to 15x), but still 50% slower than direct-in-oxc due to the data passing / AST cloning overhead for being a plugin. This is also different from e.g. Vue or Svelte where there are completely different AST formats; the React Compiler works on a JS/JSX AST that Oxc already supports (with only slight format differences). By integrating it in Oxc we can eliminate a lot of the AST cloning / transforming overhead, which isn't feasible for other frameworks. It'd be a shame to leave such a big perf opportunity on the table. We are also fully aware of how integrating it will result in bigger binary size for users who don't use React Compiler, which is why I personally blocked the version that resulted in a ~5mb increase. We are aiming to get it down to a reasonable level while optimizing binary size across the board to minimize the downside. For the long run, we are aiming to make raw AST transfer (which is already used in oxlint JS plugins) applicable to transform plugins. This would allow us to ship oxc plugins without AST cloning perf overhead.

Citeret tweet

Boshen@boshen_c

We withdrew the Rust React Compiler integration from Rolldown and Vite because it increased the binary size from 28.7MB to 33.8MB, a 17% increase, which cannot be justified for all Vite users. My current experiment is to have Claude understand our constraints. Preliminary results show up to a 2x performance improvement with only a 1.4MB increase in binary size. Next step is to de-slopify and get the code into a maintainable state, and also upstream some of the changes.

♥ 355↻ 15💬 8🔖 30

https://x.com/boshen_c/status/2069449703935336846

Mistral AI@MistralAI

Introducing Mistral OCR 4. It creates structure with bounding boxes, block classification, and inline confidence scores in 170 languages. 🧵👇

Ronan Berder@hunvreus

I got pretty bummed out by the eve release from Vercel. Not because it's bad (it's good). But it competes with , which I shipped 2 weeks earlier. Not being a multi-billion dollar company and all, it kind of felt like game over. Then @FredKSchott's takes on eve made me realize heypi is actually a different thing: - It's multiplayer. Built for teams: approval flows for risky actions, memory and runtimes scoped per channel/user, granular permissions, etc. - It's yours. No 10 serverless services. Just a good old Node.js process you run on Render, Hetzner, AWS, or your laptop. - It's built on Pi from @badlogicgames (or is it @mitsuhiko?). Honestly hard to build a better agent harness. - No filesystemmaxxing. Like eve, you can spin up an agent with a few files and folders, but you can also ship a single TypeScript file if that's not your thing. Give it a spin:

Citeret tweet

fks@FredKSchott

some thoughts on eve, especially re: @flueai and the larger agent builder space. The biggest surprise: eve is vercel-only. You can't deploy it outside of vercel and it requires a full bet on their stack -- vercel runtime, vercel sandbox, vercel workflows, vercel cron jobs, etc. etc. short-term limitation, or the start of a larger "managed agents" play by vercel? eve is filesystemmaxxing. this feels specifically optimized for agents, who love the codebase consistency and have no trouble keeping track of 10+ magic file and folder conventions as the project scales to 100s of files. (^^ this is probably the most interesting design decision here. I have a ton of respect for anyone taking a big swing like this if this is intentionally optimized for agents. makes total sense.) eve has a custom-built harness. probably not interesting to most people. I'm curious if they will leverage the new ai sdk HarnessAgent concept to swap different harnesses. otherwise there's a lot of great stuff here. lots of good features. The dev-server-as-TUI is great. you can tell how much attention and care went into this. excited to see our two projects continue to explore the same space from different directions!

♥ 470↻ 15💬 32🔖 194

https://x.com/FredKSchott/status/2067302366718947778

Daniel San@dani_avila7

This image says it all: Claude has evolved into a gateway to an organization’s tools, data, and contexts Managing access to repositories, applications, data warehouses, and internal systems is no longer just the responsibility of the person running Claude Access is now determined by the permissions granted to the agent and the environment from which it is invoked As agents become more integrated into daily workflows, access management must be designed with both organization-wide and fine-grained controls in mind, ensuring the right level of access across every system, team, and data source

Citeret tweet

ClaudeDevs@ClaudeDevs

The Claude Code team has been shipping with Claude Tag internally all year. It now writes 65% of our product team's code, including most of what built Claude Tag itself. Here are a few ways we use it every day: 🧵

♥ 3.9k↻ 174💬 183🔖 2.3k

https://x.com/ClaudeDevs/status/2069468900216234010

Erik Meijer@headinthebox

Oh my! After reading this, I found a potential hole where if an attacker can force an exception to happen that contains attacker provided text (i.e. it causes a parse error) then Automind can get role-confused. This is scary stuff.

Deedy@deedydas

Most software engineers are facing an identity crisis bordering on depression. As CTOs aggressively evangelize tokenmaxxing, a class divide ensues. The lazy. The lazy push code. They don't write it. They don't manually test it. They don't even read it. They're on autopilot. See Jira ticket, prompt for task, submit code. Many of them are barely on their computer the whole day. A comment on the PR asking why they did this? The lazy ask AI. A Slack message? The lazy ask AI. Need to prepare for standup? The lazy ask AI. As long as it sounds enough like them and isn't detected. Some of the lazy are even overemployed, and work multiple jobs. The lazy smart ones get away with this, and even rewarded. After all, software engineering for the lazy is just a dance to convince your colleagues you're smart and hard working. The craftsmen. The craftsmen are tired. Very tired. 15 PRs in queue. Slack blowing up. The entire burden of review falls on the craftsman. The burden of understanding. They try. They work their way through the code, thoughtfully commenting to improve what ships. The response? A lazy: "That's a clever idea! You're absolutely right." with an incorrect change. It's fine, the craftsman says. I can fix them. They write a doc urging his colleagues to be better. The next day? 20,000 line PR to review. Day after day, their workload grows. Bugs seep into production. No one seems to care. Another round of AI is thrown at it. Their animosity to their colleagues rises. Eventually, they give up. It's just not what it used to be. The craft they loved is dead. They eventually wake up, a lazy. This isn't all companies. Many companies are genuinely more productive, adopt the right set of principles and practices around AI development and have highly talented teams that trust each other. It tends to happen in bigger companies that are 10+yrs old with a higher talent variance. But it happens. A lot.