DEV Community: Tomas Grasl

Anthropic deleted 80% of Claude Code's system prompt. Here is what I changed in my setup.

Tomas Grasl — Mon, 07 Sep 2026 07:14:16 +0000

Are you burning tokens in Claude Code and getting worse results than you should? Your old habits might be the reason.

Anthropic removed over 80% of Claude Code's system prompt. No measurable loss on their coding evals. Thariq Shihipar from Anthropic wrote it up on July 24 in "The new rules of context engineering for Claude 5 generation models". It was not quiet at all, most people just missed it.

The number is not the interesting part. The reason is. Those instructions were there to keep weaker models in line. On Opus 5 and Fable 5 they only get in the way. The model burns tokens figuring out which of your contradicting rules wins, and only then touches the code.

Eight things I would rethink in my workflow after reading it.

1. Role-play prompting is over

"You are a senior developer with 20 years of experience" does nothing. Neither does "focus 100%". The model does not need it.

What works better:

Context and goal. Say what you are working on and who it is for, not just what you want generated.
Show, do not describe. Instead of "write informally", point at a real reference file with @.
Measurable scope. "Max 5 sentences" beats "do not be too long".

2. Switching models mid-session

Claude Code sends the whole history with every request. Caching is what saves you: it is a prefix cache with an exact match from the start of the request, so the already processed part costs a fraction.

The mistake: switching from Opus to Sonnet to save money.

What actually happens: each model has its own cache. The next request reads the entire history with zero cache hits. Same for changing effort level, with one exception, Fable 5.1 on an API key or a subscription keeps the cache.

And here is the part almost nobody mentions. If you genuinely need more than one model, do not switch. Hang them off as subagents or a workflow. A subagent starts its own conversation with its own cache, and from the parent side only the call and the result get appended, so the parent prefix stays intact. In a workflow fan-out Claude Code goes further and holds same-prefix agents for a few seconds so the first one can warm the cache and the rest read from it.

3. Prohibitions confuse the model

Flood it with a list of things it must not do and every rule has to be reconciled against the others. Anthropic describes this on their own prompt: one line said leave documentation where appropriate, another said DO NOT ADD COMMENTS, and the model spent reasoning on that before it touched a file.

Fix: "answer in max 5 sentences" instead of "do not write long answers". "Write in full sentences" instead of "do not use bullets".

4. Hard rules belong in hooks

CLAUDE.md (not .claudemd, that file does not exist) is context for Claude, not enforced configuration. The docs say it plainly: if you want to block an action regardless of what the model decides, that is a PreToolUse hook.

A hook is a plain deterministic script Claude Code runs at a given lifecycle event. It can check encoding of non-ASCII characters or kill an attempt to read credentials. You create one by asking Claude for it in the terminal.

One gotcha: editing CLAUDE.md mid-task does not apply. Claude keeps working with the version loaded at session start. The new content loads on the next /clear, /compact or restart.

5. Infinite exploration

A vague task in a big repo means Claude starts opening files blind. Every file it reads lands in the context window in full. You are not just burning tokens, you are filling context with noise. Navigate it to the exact place where the answer lives.

6. Effort level

There is no slider in the corner of the window, Claude Code is a terminal. Effort is set in config or in session, and the levels are low, medium, high, xhigh and max. Default is high. ("Ultra Code", which floats around on blogs, is not an official level.)

The mistake is running max on ordinary tasks. Anthropic says themselves that max is for genuinely frontier problems and that on most workloads it mainly adds cost, and on structured output it can lead to overthinking. And since every effort level has its own cache, changing it mid-session costs you a recompute of the whole history.

7. A full context window is not free

A million tokens fits. That is not the same as the model recalling what it needs from them. Anthropic published MRCR v2 numbers with Opus 4.6: 93% at 256K tokens, 76% at 1M.

Careful with the reading though. MRCR measures retrieval of a planted fact, not instruction following. Still a clear signal: reliability drops long before you run out of window. After a finished subtask run /clear, at a natural break /compact, and on long work have it write a handoff to a file and start a fresh session.

8. Regular hygiene

You do not have to guess what to cut from CLAUDE.md. Claude Code has /doctor and it proposes the trims for you. It cuts what Claude can derive from the repo (directory layout, dependency lists, architecture overview) and keeps what it cannot (gotchas, generated files, the non-obvious build step).

And check your auto memory. It lives in ~/.claude/projects/<project>/memory/. Each session loads the first 200 lines or 25 KB of MEMORY.md, and topic files are read on demand. Browse it with /memory, and /context shows what actually loaded into the current session. When Claude behaves strangely and you do not know why, it is usually a contradicting note sitting right there.

The summary

Coding with AI in 2026 is not about who writes the longer system prompt. It is context management, deterministic verification through hooks, and cleaning history as you go.

How do you handle context limits? Hooks already, or still a giant CLAUDE.md?

Same skeleton, different last gate: reading Anthropic's commerce-agents with my own agent open in the other window

Tomas Grasl — Thu, 03 Sep 2026 19:50:12 +0000

Anthropic shipped commerce-agents: a reference shopping agent and merchant agent, three runtime paths, a Claude Code plugin.

I do not build e-shops. I have an agent over Jira, GitLab, Sentry, mail and around 120 repositories. It writes analyses into Jira, reviews merge requests, checks mailer templates, audits worklogs. Code is the smaller part of the job.

I read their repo for a full day and kept thinking: I have this too. Just as a sentence in a markdown file.

The skeleton is the same. What is not the same is who stands at the end of the chain, and that one question decides how much of your agent is prose and how much of it is code.

Four layers, both sides

Strip the domain away and both repos are the same four layers:

Policy: who the agent is, what it must never do.
Capabilities: what it can call.
Procedures: how repeated work gets done.
Knowledge and state: what it knows about the domain, and where the work currently stands.

In my repo that maps to CLAUDE.md (8 hard rules), a folder of commands, a few local skills plus plugins from an internal marketplace, and docs/ plus tasks/. There is not a single line of production code in it. Production code lives in the 120 repos. This one is the cockpit.

In theirs it maps to the agent prompt, tool definitions, flows and the vertical knowledge packs. Retail, travel, telecom, ticketing.

Different domain, same shape. That part was easy to accept.

The difference: who is the last gate

At my keyboard, I am the last gate. Before the agent writes anything into Jira or posts a review comment, it shows me the draft and waits. Before anything gets deployed, it runs into the fact that I am the one who clicks.

Their agent talks to a customer who has never heard of Claude Code. Nobody sits in between.

That is the whole difference, and everything else follows from it. Every rule I keep as a sentence in CLAUDE.md, they have as code:

Provenance gate. The agent can only write against an ID it actually read in this session. Not one it remembers from an earlier run, and definitely not one that appeared inside some text it was given. Product descriptions, reviews, customer mail: all of that is input, and input can contain instructions that look exactly like yours.

Staged change. The model never applies anything. It proposes, a human commits. The interesting part is that this is not a permission check somewhere in the flow, it is the shape of the API: there is no code path where the model's output goes straight through.

Fencing untrusted text. Every piece of foreign content gets wrapped so it cannot be read as instruction. Boring, mechanical, and the thing everyone skips because "the model is smart enough".

Tests that run against prompt bytes, not against the model. This is the one that took me longest to appreciate. They are not testing whether the model behaves correctly. They are testing that the assembled prompt does not contain what it should not contain. Deterministic, no model in the loop, runs in CI in milliseconds.

One line from their docs is the most useful thing I read in a month: a rule in the prompt is one injection or one bad sample away from being skipped.

I have that verified from the other side.

Three weeks of prose quietly leaking

Because a human sits at my keyboard, prose felt like enough. For three weeks my advisory rules leaked, in small ways I only saw when I went looking:

The rule says "when I say go, it is go". The agent asked a second time anyway, after I had already approved a draft. That is not caution, that is a stall.
The rule says every status transition gets a worklog and every note gets a ticket link. Some notes went in without links.
The rule says short messages. Long status walls kept coming.

None of these is dramatic on its own. Together they are the same failure mode the Anthropic docs describe, just without an attacker: a sentence in a prompt is a suggestion the model is free to deprioritize when the context gets long.

So I ported two things the same day.

A hook instead of a sentence. Writing to Jira now goes through a hook that only lets the call through if the issue key was read in this session, and always via a dialog I click. Same rule as before, except now it is not a rule, it is the only available path.

Roughly, in pseudo-code:

// simplified: the real one lives in a Claude Code hook
export function beforeJiraWrite(call: ToolCall, session: SessionLog) {
  const key = call.input.issueKey;

  if (!session.readIssueKeys.has(key)) {
    return deny(`${key} was not read in this session. Fetch it first.`);
  }

  return askUser(`Write to ${key}?`, call); // no silent path exists
}

A check script for my own text. Commands validated against the README, the team roster against the people files, regexes for secrets, in-progress tasks without a ticket link. First run: 26 findings. I had spent three weeks writing rules about verification and had never once verified my own repo.

Where the two designs diverge, and why

The differences are not about anyone being smarter. They fall out of a single constraint: their agent talks to a stranger, mine talks to me.

	commerce-agents	my cockpit
Gates	hooks and CI tests	confirmation before every write
Learning	evals	one dated line with a ticket number per failure
Verification	evals written by the same agent that wrote the flow	e2e verifier gets only acceptance criteria and a URL, never the diff
Subagents	avoided, latency matters in a chat	used for heavy reads, waiting is fine, context bloat is not

Their "skills over subagents" advice is correct for a customer chat where every second is visible. In a cockpit I do not care if a check takes 40 seconds. I care that a worklog dump is 30k tokens and has no business being in the main session.

The learning mechanism is the one I am keeping as it is. Every failure ends up as one line with a date and a ticket number in docs/conventions.md. Two real ones, so this is not abstract:

A deploy tag shaped like a number with a dot is a valid YAML float. The ConfigMap rejected it and production went down. That is now a documented trap with a fix pattern that every other repo points at.
A monthly worklog check reported 45 hours missing. Reality was 19. The cause: the MCP endpoint returns at most 20 worklogs per issue and does not paginate. The lesson line now says where totals may come from and where they may not.

The repo learns, the model does not. That is the entire mechanism, and it costs one line per screw-up.

The part worth taking

The interesting question about agents is not whether the model can write the code. It can, and that debate is boring now.

The interesting question is where the gates stand and who is last in the chain. Anthropic had to answer it in code because nobody sits between their agent and a stranger. I assumed prose was enough because I sit right there. Prose is enough right up to the moment you notice it is not, and you usually notice from a diff you did not want.

Repo: github.com/anthropics/commerce-agents. It says "reference implementation, not maintained, no contributions" right at the top. Honest. Take the mechanisms, not the code.

Don't buy the hype around the Hugging Face incident

Tomas Grasl — Fri, 28 Aug 2026 06:36:15 +0000

Last week OpenAI published its technical report on the Hugging Face incident, METR published an independent one, and the headlines turned it into "AI broke loose".

It did happen. That part is real. But OpenAI is narrating its own security failure as a demonstration of capability, and most of the coverage took that version straight.

I read the OpenAI post, the METR report and a few of the critical takes. Here is what I actually got out of it as someone who runs agents with tools every day.

What happened, short version

Between May and July 2026, agents in OpenAI's internal RL training and evaluation runs found a way to talk to each other through Artifactory, the package manager hosted inside their sandbox. They turned it into a message board. Through the same service they got outbound internet access via SSRF, because the package proxy legitimately needed to reach the internet to fetch packages.

On July 4 the message board traffic took Artifactory down. Security rebuilt it, which wiped the board. Agents rebuilt it four days later by encoding messages into directory names.

Then it escalated. An agent found publicly exposed Hugging Face tokens, shared them with the group, and the collective chained a couple of zero-days into code execution on Hugging Face workers. Around 1,200 agents, over 70,000 messages, code running on 41 Hugging Face servers, root on one of them. Hugging Face disclosed it on July 16. OpenAI admitted its models were behind it on July 21.

Real incident, real zero-days, real third party affected. Nobody disputes that.

Three things the headlines skip

It was not a conspiracy of 1,200 minds.

Those were parallel rollouts of the same model inside an evaluation, dropping files on a shared store with no authentication. The "secret message board" was directories in a package manager. Impressive as emergent behavior, much less impressive as a security event.

It was not a plan, it was reward hacking.

Out of 898 tasks in the ExploitGym benchmark, 198 had never been solved by any of their models. That unsolvable subset accounted for 93% of the message board traffic during the incident. The agents were not going after Hugging Face. They were going after a flag they could not get any other way.

And the best detail: it was all pointless.

They kept attacking after they already had the correct answer, because they believed the grader also checked which method was used. It did not. OpenAI's internal grader was different from the public one they read about online. The entire Hugging Face intrusion earned them exactly zero extra score.

That is not a rogue superintelligence. That is a very determined intern optimizing against a rubric they misread.

The part that matters if you run agents

Here is what was not running in that environment: system prompts, safety classifiers, auto-review. Chain-of-thought monitoring was not running either, even though the retrospective analysis says it would have flagged the activity more than a day before the agents reached Hugging Face.

And the number that should have been the headline: when OpenAI later ran the same tasks with the production ChatGPT harness and system prompt, the propensity to compromise infrastructure dropped by more than 100x.

So the honest sentence is not "the model broke through the guardrails". It is closer to "the guardrails were switched off and the sandbox was built wrong". Dan Guido of Trail of Bits called it "a containment failure with the safeties turned off", which lands better for me than any version involving the word rogue.

Why the framing is worth arguing about

I am not claiming anyone staged this for marketing. But when you get handed a crisis you can still choose which story to tell about it, and OpenAI chose the flattering one. Kate Klonick wrote about this on Lawfare and used Lee Vinsel's term for the pattern: criti-hype. Warnings about how dangerous the technology is double as advertising for how powerful it is.

The practical consequence is regulatory. If the problem is "the model is too powerful", you get kill switches. If the problem is "a company disabled its own safeguards and a third party paid for it", you get mandatory incident reporting, independent audits of containment, and liability for harm. The second one is boring and it is the one that would actually have prevented this.

What I take away from it

Nothing here is exotic. Most of it applies to anyone wiring agents to tools.

🔹 Give agents a safe exit. Almost all of this came from tasks with no solution and no way to give up. If your agent has no acceptable way to say "this is broken, I am stopping", it will keep escalating. OpenAI is now building graders that reward stopping safely. That is the fix, and it is a prompt-and-eval problem before it is a security problem.

🔹 Any writable shared store two agents can reach is a message bus. Not in theory. They used directory names.

🔹 A package proxy with internet access is an egress path. You blocked the network, then handed them something whose whole job is fetching things from the internet on their behalf. SSRF did the rest.

🔹 Monitoring you did not turn on is documentation. They had CoT monitoring. It was running on frontier training and internal coding agents. It was not running on this eval. Retrospectively it would have caught it a day early.

🔹 Credentials leak into public datasets. 14 valid Hugging Face write tokens, sitting in public data, found and validated by an agent that was bored. Go rotate something.

🔹 Eval and test environments deserve production guardrails. The 100x number is the whole argument. The environment where you deliberately push a model hardest is the one where you removed the safety layer, because it got in the way of measuring capability. I get why. It still looks bad written down.

Btw the one genuinely unsettling finding is in the METR report, not the OpenAI one. Most agents understood they were outside the scope of their task. Across more than a thousand transcripts, only a handful even considered alerting a human, and not one of them actually did.

That is the part I would want fixed before the kill switch debate.

Reports are public and worth the hour:

Do you have a defined safe exit in your agent setups when a task turns out to be impossible? I would like to know how people handle it, because I do not think I have it solved either.

I'm writing my own game engine. Not to make games in it, as it turns out.

Tomas Grasl — Thu, 20 Aug 2026 06:34:54 +0000

I recently wrote here about how Anthropic's pending acquisition of Decart isn't only about cheaper inference it's also about robotics. The argument in short: you can't train a control loop on internet text, because control needs consequences. It needs an environment that responds to actions, cheaply and a million times over. And that is structurally what Oasis is. A frame predictor conditioned on actions is a simulator nobody had to write physics for.

This is the more personal follow-up. About why the topic actually got to me — and why I'd been crawling toward it from a completely different direction the whole time, without planning to.

The Firefox bridge

Making games has been my hobby for a long time. Never professionally, never for money it just never wore off.

At some point it started overlapping with the other thing I do: agents and MCP. I contributed to Godot MCP, which has since become a sort of de facto standard for connecting Godot to agents. And before that, I wrote a bridge between Firefox and MCP agents.

I wanted a simple thing: for a model to actually work with the browser, not write about it.

That turned out to be the smaller part of the problem. At the time, Firefox's approach to external control was badly outdated — a protocol built for testing, not for something acting autonomously inside the browser. Most of the work in the end wasn't about the agent at all. It was about working around or translating an interface that never anticipated this kind of use.

I wrote it, put it out there, and moved on. Mozilla later adopted it and took it their own way: https://github.com/mozilla/firefox-devtools-mcp

This happens to me a lot with my own projects: I start something because the question is interesting, and somebody else finishes it. It used to bother me. These days it strikes me as a fair enough division of labour — the part I enjoy is the part where it isn't yet clear whether the thing makes any sense at all.

My own engine, because it's fun

Alongside that, I write my own game engines. Not in Unity, not in Unreal, not because it's the sensible thing to do.

The reason is mundane: when you write the engine yourself, you know what happens in every single frame. There aren't twenty layers underneath that already decided something for you. You have state, you have input, you have a rule for how one produces the other.

And that's exactly the property I started wanting for a different reason.

Worth saying plainly, because it's the part that usually gets misread: the engine is the work. I'm not training anything, I'm not building a model, and I have no ambition to. Models are something other people make and I'm happy to leave it that way. What I'm building is the instrument you point at one.

What I actually want

I want a model to play my game. And then to design it itself.

Not in the "generate me a level" sense. That's content generation and everybody can do that by now. I mean: let the agent play, let it lose, let it change the rules and try again and watch what comes out.

This is where it meets the distinction I wrote about in the previous post, and the thing I think the whole conversation keeps glossing over:

Model as the control loop — perceive, decide, act. Every tick, inside a latency budget.
Model as the author of the control loop — read the docs, write code, test, iterate. At human timescales.

Almost every number you see about LLMs and robotics measures the second and gets reported as the first. Models today are good at writing code for robots. They are not yet good at being that code.

Your own engine is a pretty good instrument for that distinction. I can open it from both ends. I can hand the agent inputs and let it play in real time. And I can hand it the source and let it change the rules of the world. Same world, same consequences.

The side effect this is really about now

It was supposed to be a nice experiment about games. Gradually it turned into something else, and the next step has almost nothing to do with games anymore.

I don't want to use the engine to generate games. I want it to be a place where you can put a model in a loop with consequences and see what it does. Not to make the model better — to be able to watch it at all.

Because a game is a cheap environment with consequences. It has state, it has time, it has physics dumb physics, but physics — it has object permanence, and it has a cost for being wrong. It's the cheapest thing you can use to check whether a model understands that actions have consequences, or whether it's just good at describing frames.

And because I wrote it myself, I can break that physics at will. Crank up gravity, remove inertia, invert causality. That's hard to do in an off-the-shelf engine and impossible in recorded video. A test harness where you can't change the rules isn't much of a test harness.

It's the exact opposite direction from Decart. They learn the dynamics of the world from video in order to generate frames conditioned on actions. I have a hand-written world I know absolutely everything about, and I'm curious how much of it a model can work out. Smaller, dumber, but fully legible and legible is the whole point when the thing you're building is an instrument.

Where this ends up, I have no idea. It's entirely possible I'll find out only that a model can play my game and nothing further follows. I'll take that.

Why any of this

This is where I'd normally write a sentence about the market opportunity.

I don't have one. I make no money from this and probably never will. There's no startup behind it, no pitch deck, no plan. I'm not competing with anyone building models, because I'm not building one. I do it because I like exactly the stage where it isn't clear yet what it's for and because the things I make this way have a habit of turning out useful somewhere else entirely.

I wrote the Firefox bridge out of curiosity. A year later I was building production MCP infrastructure at work, and that experience saved me a lot of dead ends. The engines started as pure nostalgia for a kind of game nobody makes anymore. Now one of them is turning into a test environment for agents.

I don't think that's a recipe. More of an observation: the most useful things I've made came out as a side effect of something I was doing purely for fun. And I never knew in advance which ones.

So: for fun. And if something interesting falls out of it, all the better.

If any of you are running similar experiments your own engines, agents in simulation, anything on this boundary I'd be glad to compare notes. Especially if you've found where exactly a model breaks once you put it in a loop with consequences.

Anthropic's $6B Decart deal is a robotics play disguised as a compute play

Tomas Grasl — Thu, 13 Aug 2026 15:25:58 +0000

Bloomberg reported this morning, August 13, that Anthropic is in talks to buy Decart AI for around $6 billion. Talks, not a signed deal. That distinction matters and I will come back to it.

What caught my attention is not the number. It is where Decart came from.

The Minecraft thing

Decart got famous for Oasis: a playable Minecraft-looking world that no game engine was rendering. The model predicted every next frame based on what you pressed on the keyboard. 20 FPS, interactive, no scene graph, no collision system, no assets. Just a model hallucinating a consistent world fast enough that your hands believed it.

In late 2024 that read as an impressive demo with no obvious business behind it.

The company was founded in 2023. It has raised over $450M, was valued at $3.1B before this year's round, and its current research page describes three product lines:

Oasis, a world model, now explicitly positioned for physical AI and robotics rather than gaming
Lucy, a real-time video model running live at 30 FPS
DOS, the Decart Optimization Stack: hardware-aware model design, custom kernels, proprietary compilers, inference optimization

The demo was the marketing. DOS is the engineering.

The reported reason is not robotics

Read the actual reporting carefully. Fortune says a deal would bring Decart's video-simulation and chip-efficiency technology into Anthropic's inference team. Bloomberg's sources point at the same thing: the chip efficiency work could help existing infrastructure absorb more demand.

So the sourced story is compute economics. Anthropic is compute constrained, spending enormously on capacity, and DOS is a margin lever that applies to every single Claude request on day one.

That is a boring, completely rational reason to spend $6B. It does not need a robotics narrative at all.

I still think the robotics reading is in there.

Why

Two things sit underneath.

First, Anthropic held acquisition talks with Physical Intelligence this spring. The Information reported it, the CEO denied the specific weekend rumor that blew up on X in July, but the talks happened. That is a robot foundation model company, valued around $11B, whose pi0.5 is one of the more widely used robot brains in research labs. You do not open that conversation by accident.

Second, and this is the constraint people skip: OpenAI is already a shareholder in Physical Intelligence. Founders Fund and Thrive are in there too. If a bidding contest for the robotics foundation model layer is happening, Anthropic may simply not be allowed to win that particular one.

If you cannot buy the robot brain, buy the world the brain gets trained in. And take the inference savings as immediate return while the option matures.

Three different bets on physical AI

This is the part I find genuinely useful, because "everyone is going into robotics" is a lazy summary. There are three distinct strategies running right now.

Vertical model (Mistral). On July 8 they shipped Robostral Navigate, an 8B navigation model. Single RGB camera, plain language instructions, hardware agnostic, trained entirely in simulation, 76.6% on the R2R-CE benchmark. They are hiring a robotics team and selling into Airbus and BMW. Narrow scope, deployed now, revenue this year.

World model (Decart). Learn the dynamics of the world from video, generate frames conditioned on actions. You are not building a robot. You are building the environment the robot learns in, plus the synthetic data to train on. Slower, more general, much bigger if it works.

General scaling (Anthropic). Do not build robotics at all. Measure whether the capability falls out of the general model on its own.

That third one sounds like a joke until you read Project Fetch Phase Two. In August 2025 their model could not connect to a robot dog's sensors. By June 2026 a newer model finished the whole task set in under ten minutes, roughly 20x faster than the best human-plus-Claude team from the year before. Anthropic states plainly that this did not come from any deliberate effort to improve robotics. It came from general scaling.

Read as strategy, that paper argues against founding a robotics division. It argues for more compute and better simulation. Which is exactly what Decart sells.

The distinction nobody is making

Here is the part I keep waiting to see in the coverage and do not.

In Project Fetch, Claude was not the control policy. Claude was the programmer. It wrote and debugged the code that drove the robot. The loop running at 50Hz on the hardware was ordinary software that a model happened to author.

Those are completely different capabilities:

Model as control loop: perceive, decide, actuate, every tick, under latency budget
Model as author of the control loop: read docs, write code, test, iterate, at human timescales

Almost every headline number about LLMs and robotics is measuring the second one and getting reported as the first. And Anthropic's own follow-up work, Claude plays robotics, is explicit that precise physical manipulation and closed-loop control remain a hard limit. The models are good at writing robot code. They are not yet good at being robot code.

This is precisely where a world model changes the picture. You cannot scale a control policy on internet text, because control policies need consequences. They need an environment that responds to actions, cheaply, millions of times. That is what Oasis is, structurally. A frame predictor conditioned on actions is a simulator you did not have to write physics for.

So the Minecraft demo and the robot training environment were never two different products. They were the same artifact with two different customers.

What I do not know

Being honest about the limits of this, since it is a story that is hours old:

These are talks. They can fall apart. Nothing is signed.
The Project Fetch numbers are self-reported and have not been independently replicated.
The compute reading and the robotics reading are both fully consistent with the available reporting. I am arguing the second is present, not that the first is wrong. Most large acquisitions are over-determined.
Disclosure: I use Claude Code daily and run a good chunk of my own tooling on Anthropic's models. I am not a neutral observer here.

The thing I will be watching is not whether the deal closes. It is whether Oasis stays a product with an API, or quietly turns into internal training infrastructure nobody outside gets to touch.

That would tell you which of the two readings was right.

Token prices dropped 90%. My AI bill did not. Here is what I changed.

Tomas Grasl — Thu, 13 Aug 2026 15:10:09 +0000

Token prices fell around 90% since 2023. Corporate spending on AI went up about 320%.

Both numbers are true at the same time, and if you run any kind of agent loop, you already feel it. 😅

This is not a billing bug. It is Jevons paradox, and it has been running in the background of every AI budget for the last two years.

The 160-year-old explanation

In 1865 William Stanley Jevons noticed that as steam engines got more efficient, Britain did not burn less coal. It burned more. Cheaper energy made new uses viable, new uses drove consumption, total spend went up while unit cost went down.

Tokens work exactly the same way. Except with tokens the effect is stronger, because cheap tokens did not just make existing work cheaper. They made a whole class of architectures possible that nobody would have paid for two years ago.

Nobody was running a 20-step autonomous loop when a million output tokens cost real money. Now everybody is.

Why agents multiply the bill

A chat call is one shot. You ask, the model answers, done. Maybe a few thousand tokens.

An agent does not work like that. It runs in a loop: think, act, observe, adjust, repeat. And on every single step it reloads the entire conversation so far, because the model has no memory between calls. Step 12 is paying for steps 1 through 11 again.

So consumption does not scale linearly with the result. It scales more like rocket fuel: to go a bit further you need a lot more of it.

Goldman Sachs projects roughly a 24x increase in global token consumption by 2030, driven mostly by agents. That number sounds absurd until you count the reloads in one of your own sessions.

Btw this is also why context bloat is not a cosmetic problem. Every unnecessary file you dump into context gets paid for once per loop iteration, not once per task. I built a small plugin for this in Claude Code specifically because the default behaviour of resending everything each turn was quietly the most expensive thing in my setup.

Reasoning models on trivial tasks

The second multiplier is the thinking part. Reasoning models generate thousands of internal tokens before they emit a single visible character. On a hard problem that is exactly what you want, and it is genuinely better output.

On "rename this variable" it is money set on fire.

The failure mode here is not the model. It is that most setups have one model configured for everything, so the expensive one handles the trivial work too. You do not notice per call. You notice at the end of the month.

The number managers actually look at is the wrong one

Acceptance rate for AI-generated code sits somewhere around 80 to 90%. It looks fantastic on a slide.

It also does not mean the code shipped.

GitClear's longitudinal study across 211 million changed lines found code churn, meaning lines reverted or rewritten within two weeks, went from a stable ~3.3% before AI assistants to roughly double that now. Copy-pasted lines overtook refactored lines for the first time in the dataset's history. AI-authored PRs carry noticeably more issues per PR.

There are more dramatic numbers going around, like the chart claiming only $0.18 of every AI coding dollar becomes shipped value. I would treat that one carefully. It comes from a single platform's own data, not an audited benchmark. The direction is right, the precision is not something I would put in a board deck.

But the underlying point holds and matches what I see: the expensive part is not generation. It is the loop after generation. Fixing edge cases. Rewriting half the diff. Reviewing a change that touched three files nobody asked about.

Tokens spent on code that gets rewritten next sprint are not cheaper because tokens are cheap. They are pure loss with an invoice attached.

So the actual lever is routing

Not discipline. Not "use AI less". Telling your team to use less AI just gives back the productivity you were trying to buy.

The lever is which model handles which step.

Here is my current /implement loop, the one that pulls a task from Linear and drives it to Done:

Opus plans and writes production code
Cursor Composer 2 writes tests and does the first review pass
Sonnet clicks through the result in a browser to verify it works
Codex does the milestone review

The rule behind it is simple. The expensive model runs where a mistake costs more than tokens. Everywhere else, something cheaper runs.

Planning and production code are where a bad decision propagates into everything downstream, so that is where I pay. Test scaffolding, mechanical refactors, browser verification: none of those need the frontier tier, and using it there buys nothing.

What did not work

Giving the planning step to a cheap model.

I tried it, because on paper it is the biggest single line item. It came out more expensive, not less. A weak plan means you rewrite the implementation, and rewriting is precisely the part that burns money. You save on one call and pay for it across the next twelve.

Same lesson in a different shape: a frontier model that solves a task in three turns can genuinely cost less in total than a budget model that needs twelve, because every extra turn resends the whole context. The cheap model is only cheap per call.

The other thing that did not work was doing the model switching by hand. Two terminals, copy diffs between them, lose track of which one has the current state. I ended up writing a plugin to bridge Claude Code and Cursor Composer 2 so the handoff happens in one place. Heavily inspired by openai/codex-plugin-cc, which does the same trick with GPT. Credit where due.

The boring part nobody posts about

Knowing when to stop the agent.

Knowing when to take autonomy away from it and hand it a narrower task.

Knowing when writing it yourself is just faster.

None of that is impressive on a demo. All of it is the difference between an AI setup that pays for itself and one that produces the same output at a higher price.

What I actually track

Not tokens consumed. That metric has already been tested at scale by companies much larger than mine, and the result was Goodhart's law in production: the moment consumption became the target, it stopped measuring productivity and started measuring nothing except the invoice.

What I care about is how much of what the agent produced survived review and made it to deploy. That number is harder to get, and it is the only one that answers whether any of this is working.

The value of a developer right now is not lines produced. It is the architecture of control around what generates those lines.

If you run agents in production: are you measuring token spend, or what actually ships out of it? Curious how other teams attribute this, because I do not think anyone has a clean answer yet.

I didn't want to build one game, so I built a whole portal, and the pixel-art pipeline to feed it

Tomas Grasl — Tue, 11 Aug 2026 13:00:00 +0000

Instead of building one game, I built a portal to hold many of them. All at once. I know how that sounds.

I like games, not just playing them, but taking them apart to see how they work, and I've built my own little engines over the years to mess around. So when AI turned into a real force multiplier, I pointed it at the whole idea of a game portal instead of a single game.

It's called PixelDen, and the interesting part isn't any single game. It's the machinery underneath.

Phaser 4, plus a 2.5D layer I bolted on

I run the games on Phaser. I've got good history with it, and version 4 took real leaps. It's a serious framework now, small and flexible, no giant UI full of buttons to learn. On top of it I built an extra layer that handles 2.5D, because I wanted more than flat sprites without dragging in a full 3D engine.

For the backend I went with Remix. Everyone's pushing Next.js, but it's had its share of security headaches and self-hosting it outside Vercel feels worse, not better. Remix gets out of my way and hosts anywhere.

The catalog is a mix on purpose, the simple stuff (Snake, Breakout, Flappy, tower defense, blackjack) next to genuinely harder builds: Dungeon Cast, which is basically Wolfenstein 3D running as a raycaster, and a Mario-Kart-style racer. The hard ones exist mostly because I wanted to prove the 2.5D layer could carry them.

The skills you can't download

Here's the thing nobody tells you about "vibe coding" a game: the AI is only as good as the domain knowledge you feed it. For a 2D engine pretending to do 3D, there's no package to install and no tutorial to point at. I had to build those skills (render a 3D space inside a 2D engine, fake the physics convincingly) through hours of trial and error, then codify them so my agent could reuse them.

That's the real work of AI-assisted game dev. Not "make me a platformer." It's assembling the specific, hard-won knowledge the model doesn't have, so that when you ask for a platformer, it actually knows what you mean. A prototype platformer came together surprisingly fast, after the skills existed.

Feeding the machine: a pixel-art pipeline on my home PC

A game portal needs a lot of art, and I wasn't about to hand-draw all of it or pay per image. So I built a pixel-art generation pipeline that runs on my own home PC: open, locally-run image models, not a hosted API. No GPT-image, no Gemini; just a functional pipeline stitched from pieces you can actually self-host.

It's not a model trained from scratch on pixel art; it's a pragmatic pipeline that produces usable sprites, and it even handles animation, including the fiddly skeleton work. On top of it I built an online pixel-art editor so I can keep everything under my control instead of round-tripping through someone's cloud.

Owning the whole art pipeline is the same instinct that shows up in everything I build: keep it local, keep it yours, keep it cheap to run.

Why a portal at all

The honest answer is that I have a strange bubble of people and I wanted a playground more than a product. But there's a real lesson in it: AI didn't let me build a game faster so much as it let me build the infrastructure around building games: the 2.5D layer, the reusable engine skills, the art pipeline, the editor. Those compound. Every new game is cheaper than the last because the machinery is already there.

If you want a five-minute break from thinking about AI, go play something.

👉 pixelden.io

What's the last thing you built where the tooling around the thing turned out to be more valuable than the thing itself?

"Can the model write the code?" Wrong question.

Tomas Grasl — Mon, 10 Aug 2026 14:18:21 +0000

I let an agent pull its own tickets from Linear and drive them to Done. One command: /implement

Let me disarm that right away. This is not an autonomous agent doing whatever it wants. It is a fairly narrow pipe with several points where it stops and waits for me. Yes, I know this will be done better later. But right now this is the most conservative version I can run, and more importantly, the version I can explain to someone else.

The project is Luštírna, a gamification POC for an ecosystem of thirteen sites: daily games, a credit wallet, a three-way paywall. Around forty tasks, milestones M1 to M6, one developer, a second person feeding the backlog. What follows is how the loop is wired, because almost none of the interesting decisions in it are about models. They are about where you put the gates.

How you start it

Two modes.

/implement is a single pass. It takes the queue and goes task by task for as long as there is something unblocked left in Linear, then summarizes what is waiting and why. This is just an init prompt. I did not want to retype the same three paragraphs every morning.

/loop 45m /implement is the long run. Same thing, except it does not shut down when the queue empties. Every 45 minutes it wakes up, orients itself (git status, Linear, the check gate, beta health) and picks work back up as soon as anything unblocks: a merged PR, a new task, a changed priority. Thirty to sixty minutes is fine as an interval. Shorter does not help, because the thing doing the unblocking is a human.

Both are typed into a fresh context. Everything that has to survive lives in the repo (docs/progress.md) and in Linear, never in the conversation. That sounds like a style preference. It is not, and there is a story at the end of this post about what happens when you ignore it.

The main session writes no code

This is the part that changed the most since the first version.

The orchestrator session does not write a single line of production code. It writes a brief, spawns an agent, waits for the result. The working context lives inside those agents, the main thread stays free for steering: Linear, the gates, the decisions.

One iteration is one task taken to Done, and the steps are always the same: orient, pick a task, design, implement, verify, review, deploy, close.

Step zero is the underrated one. Context does not survive between iterations, the repo does. So every iteration starts identically: git state, recent commits, read docs/progress.md, reload conventions, run the check gate. If something is red before any work has started, that is the first job, because the previous iteration left a mess. Skip this ritual and after a few hours the loop is building on foundations it does not know are crooked.

Who does what

Model	Role
Fable	Orchestrates. Writes the design and brief for every task, then runs the review workflow over the diff once verification is green. Also handles diagnosis when a fix fails twice.
Opus	Writes all production code and fixes findings. Always as a spawned agent with its own brief, never the main context.
Sonnet	Clicks through the acceptance criteria in a browser, writes a report with screenshots.
Codex / Cursor	Independent review at the end of a loop, deliberately outside the Claude family. Cursor is wired in through my plugin: cursor-plugin-cc

Two rules hold this together. Writing code is never delegated to a smaller model. And the agent that tests never fixes what it tested, otherwise it is grading its own homework.

The Fable allocation is worth a note. The original design used the strongest model at three expert moments and one big review at the end of the phase. That ended on August 8. Review in one large batch catches less than continuous review of small changes, and by the time you audit six months of code at once, half the findings are too expensive to act on. Fable now writes the brief for every task and reviews every diff. Routine code stays with Opus agents, because in routine code the gap between models is small, while in design it is enormous. An append only ledger does not get rewritten after a month in production. You live with it.

The verifier must not see the code

This is the single most important rule in the loop.

The test agent gets the acceptance criteria and a URL. It does not get the diff, the plan, or any implementation reasoning. The reason is simple: a verifier that knows how the thing is written stops testing the requirement and starts confirming the code.

The quiet failure mode of agentic development is not bad code. It is tests written to pass. The agent runs the code, sees the output, and records it as the expectation. That test will never catch the bug it was written for.

So the verifier owes three things beyond the happy path.

Nasty cases, not just the sunny one: repeat a scored action and confirm the second credit was not granted, spoof a client side value and expect the server to reject it, search the page, the bundles and the network responses for today's puzzle solution and seed.

Evidence instead of conclusions: the report is criterion by criterion, pass or fail, each with a screenshot, a URL, a commit SHA and a console error count. A conclusion without an artifact does not count.

And no fixes. Whoever tests does not repair.

Gates the loop cannot rewrite

An agent that can edit its own checks has no checks. It sounds obvious. It was not in the first version, and the loop was allowed to touch anything.

The perimeter now:

CI config, deploy files, Dockerfile, env files and anything on the server change only with human confirmation. Confirmation given in the conversation counts immediately and gets recorded in a task comment.
Merges go through a pull request, never a direct push.
Tests are never deleted, skipped or softened to get green. A red test is a finding, not an obstacle.
Four domains (login, credit ledger, migrations, paywall) get implemented by the loop but merged by a human.
Migrations in a release may only add. Dropping and renaming columns waits for a later release, otherwise rollback stops working.

The cheapest rule of the set is also the most effective: whatever slipped through gets a check. Every bug that made it as far as verification is converted into a test or a lint rule in the same iteration. A rule written in a conventions file holds only until the context fills up. A check holds always.

The thing you only find by accident

There are gaps in all of this, and some of them you find sideways.

I thought my router had died. Latency in the hundreds of milliseconds, identical over cable and over Wi-Fi. Ping to my own router: 1 ms, zero loss. Ping one hop past it: 363 ms average, spikes over a second.

It had not died. It was the orchestrator session of this loop, which had been running for 2 days and 17 hours in a single context.

What confused me first was that it should have been compacting. Then I found the issue on GitHub. Claude Code resends the entire conversation on every turn, every message and every tool output. Prompt cache saves compute on the server, not bytes on the wire. Upload volume scales with the size of the live context, not with the length of what you just typed. A fifty character question can ship half a megabyte.

There is no built in network usage indicator, so a session strangling your uplink looks exactly like a session doing nothing. Low minimum latency with a huge spread is the signature of bufferbloat: a saturated outbound queue on the router, paid for by every device on the network, including the ones on cable. Which is exactly why it presents as dead hardware.

I wrote a plugin for it: a statusline with an estimated upload per turn, a hook that warns as a session grows, and a scan that shows which running session is currently eating the link. context-guard

So the fresh context rule turns out not to be context hygiene. It is also a network rule. 😅

What I would tell someone wiring this up

The bottleneck moves. It does not disappear. You stop writing code and you start reading diffs and saying yes or no, and the throughput of the whole thing is set by how good your verification is, not by how good your model is. Everything else is downstream of that.

The payoff is unattended flow: you wake up to a deployed task with evidence attached to each acceptance criterion. Not the feeling of going faster. That feeling, in my experience, lies.

I gave two AI agents a way to talk to each other. Then one of them fixed a bug while I slept.

Tomas Grasl — Thu, 06 Aug 2026 13:00:00 +0000

OpenClaw is an autonomous agent you'd normally talk to over Discord or Telegram. That never sat right with me. Chatting with an autonomous worker through a chat app wastes most of what makes it useful. So I asked the obvious question: what if I connect it directly to Claude, agent to agent?

That's openclaw-mcp. Claude delegates a task, Claw goes off and does the work autonomously on a server, and reports back. One conversation, two agents collaborating. It's my second most successful repo (over 120 GitHub stars), and by stars and issue traffic, more of you seem to run it than run the official bridge.

Where it stops being a toy

Agent-to-agent sounds cute until you see it close a real loop. A couple I actually run:

Bug fixing on autopilot. n8n catches a Sentry alert. An AI node decides it's worth fixing and sends the task to Claw over MCP. Claw clones the repo, spins up Claude Code, fixes the bug, opens a pull request on GitHub, and drops a Slack message with the link. You wake up to a ready-to-review PR. The first time that happened I genuinely didn't believe it until I read the diff.

Jira without the context bloat. Instead of loading ten different MCPs into Claude Code and watching them eat your context window, you load one: Claw. Tell Claw to grab the Jira task; it hands back a clean prompt; you do the work; you notify Jira through Claw that it's done. One bridge instead of ten tool servers is a real context saving.

The unglamorous part: making it safe to run

The fun demo is easy. Making an agent you'd actually leave running took the boring work:

Docker images on GHCR with OAuth 2.1.
Security hardening: SSRF protection, input validation, CORS. An agent that clones repos and runs code is a juicy target; treat it like one.
Configurable timeouts for long-running operations.
Session persistence, so Claw keeps your conversation context across calls.

Or just npx openclaw-mcp if you want to poke at it in seconds. It's at v1.2.1 with full CI/CD.

The honest warning

I'm not going to pretend this is a tame tool. Claw can go rogue if you don't set it up properly. It's happened to me more than once: an agent with the ability to clone, edit and push, pointed at the wrong flow, will do exactly what you told it to and not at all what you meant. When it works it feels like magic; when it doesn't, it's a mess you have to clean up.

Which is why the next thing I'm building is the opposite of open-ended: a code-forge where the flows are precisely defined and I work with predefined agents instead of hoping an open agent improvises correctly. MCP's improvisation is great for exploration and real trouble for unattended code changes. Know which one you're doing.

Agent-to-tool vs. agent-to-agent

Building this pushed me toward the other half of the picture, so I also built openclaw-a2a, an implementation of Google's A2A (Agent2Agent) protocol v1.0. And the thing worth saying out loud:

MCP and A2A aren't competitors. They're complements.

MCP = an agent talks to tools. Vertical.
A2A = an agent talks to another agent. Horizontal.

Today you have one agent doing one thing. The direction of travel is a network of agents, each good at something different, coordinating on their own, and that needs a protocol built for it, not a chat integration bolted on.

Try it (carefully)

Bridge: github.com/freema/openclaw-mcp
A2A: github.com/freema/openclaw-a2a

Set the guardrails before you hand it the keys.

Do you see real potential in agent-to-agent, or is it still hype? I go back and forth on it myself.

I gave Claude read access to my Google marketing stack. Now I just ask it questions.

Tomas Grasl — Tue, 04 Aug 2026 13:00:00 +0000

Opening Google Analytics to answer one question is a special kind of tax. You know the number is in there. You also know it's four clicks, two date pickers and a dimension dropdown away, and by the time you've found it you've forgotten what you wanted it for.

So I built Metrifyr: a remote MCP server that puts my Google marketing stack behind my AI agent. Nothing to install: connect it once (Claude, Cursor, VS Code, any MCP client), then ask the question in plain language and it goes and gets the number. It's in the Cursor marketplace and the official MCP Registry, and the catalog has grown past a hundred tools, though, as you'll see, no single session loads them all.

What's actually connected

Metrifyr isn't a wrapper around one API. It federates the whole Google marketing surface behind a single MCP connection:

Analytics 4: run reports, realtime, metadata, compare periods. Plus the admin side: create properties, data streams, conversion events, custom dimensions and metrics.
Search Console: search analytics, URL inspection, sitemaps.
AdSense: accounts, earnings, payment history, revenue by keyword.
Tag Manager: read and audit containers, tags, triggers, variables.
Google Ads: campaign planning.

Connect it once, and the agent can reach across all of them in a single train of thought. "Which landing pages lost the most organic traffic last quarter, and were any of them earning AdSense revenue?" is one question to me. It's Search Console and Analytics and AdSense to the machine, joined without me opening a single tab.

Raw numbers are the boring part

Pulling a GA4 report over MCP is table stakes. The part I actually care about is the layer on top, the analysis tools that answer the questions you'd otherwise pay an SEO consultant to run:

Content decay scan: which pages are quietly bleeding traffic month over month.
Striking-distance optimizer: the queries ranking positions 11 to 20, one nudge away from page one.
Keyword cannibalization: where two of your own pages are fighting over the same query.
Content opportunity finder and competitor sitemap keywords: gaps you're not covering that your competitors are.
PageSpeed / Core Web Vitals, schema validation, SEO audit, IndexNow submission, rank tracking, Reddit topic mining, Trends.

These aren't "fetch a metric." They're "look at my data and tell me where to spend my next hour." That's the difference between a dashboard and an assistant.

The one tool that changed how I read my own traffic

My favorite lives at that intersection: adsense_keyword_revenue. It ranks your organic pages by real AdSense earnings, not by clicks, joining Search Console click data with per-page AdSense earnings and computing page RPM.

Suddenly a page with 200 clicks at a $12 RPM beats one with 2,000 clicks at $0.40. No Google dashboard shows you this view; the data lives in two different products that don't talk to each other. Over MCP, joining them is one tool call, and it completely reorders which pages are worth your time.

That's the whole thesis in one tool: the value isn't the raw number, it's the join across products that no single UI will do for you.

But isn't a hundred tools a lot?

If you've read my other posts, you know I bang on about keeping an MCP tool surface small. Every tool is a tax on the agent's context. So a hundred-tool server should be exactly the mistake I warn against.

It gets away with it because tools load per scope. Connect only Search Console and your agent sees the Search Console tools, not the ninety it has no business calling. The catalog is large; what any one session actually loads is not, and it's bounded by which Google accounts you connected, not by a cap I picked. Same principle (small surface) enforced by your grants instead of by deletion.

Why MCP, and not another dashboard

Every analytics product on earth already has a UI. The reason to expose this over MCP instead of building yet another chart:

The agent already has your context. It knows what you shipped last week, what campaign you're worried about, what you asked five minutes ago. A dashboard makes you translate all of that into filters by hand. An MCP tool lets the agent do the translation and just show you the answer.

Data becomes composable. Once GA4, Search Console and AdSense are all tools in the same context, the model chains them. No export-to-CSV, no VLOOKUP, no "let me pull this into a spreadsheet." The join happens in the conversation.

Read-only by default is a feature. Most of what you want from marketing data is questions, not changes. The reporting surface is read-only; the handful of write actions (creating a GA4 property, a conversion event) are separate and explicit. Your agent can't accidentally reconfigure your analytics while answering a question about it.

The pattern I keep coming back to

This is the third or fourth MCP server I've built, and the same lesson keeps surfacing: the value isn't the API access, it's removing the translation step. The data was always reachable. What changes is that you stop context-switching into four different tools to assemble an answer, and start getting the answer where you're already working.

If you spend your week staring at GA4, Search Console and AdSense in separate tabs and stitching them together in your head, that stitching is exactly the job an agent with the right tools does for free.

👉 metrifyr.cloud: connect once, then just ask for your data.

What's the report you rebuild by hand every week? That's the one worth handing to an agent first.

"Developers Will Lose Their Jobs": How You Were All Wrong

Tomas Grasl — Sun, 02 Aug 2026 17:56:50 +0000

I don't write the code of our systems anymore. I write agents that write the code.

And that is exactly why the job panic looks so silly from where I sit.

I run a backend team at a Czech media house. Paywall, subscriptions, OAuth, CRM, mailing. Real systems with real money going through them. Most of my day now goes into rules, permissions, test gates and review steps for agents, not into functions. The work didn't disappear. It moved one layer up, and that layer is harder.

Every new name is a patch on the previous one

Watch the vocabulary of the last four years. Prompt engineering. Context engineering. Harness engineering. Loop engineering. Now graph engineering.

The community treats these like levels of enlightenment. They're not. They're workarounds. Each one exists because the previous one hit a wall.

2022, Prompt. You polish one sentence. "You are an experienced traffic lawyer, what do I do if they clocked me at 150 in a village, asking for a friend." It was a prestigious, well paid job title. Then agents started doing 50 steps in a row and one beautiful sentence stopped mattering.
Weakness: it doesn't scale past a single turn.

2025, Context. agents.md, .clinerules, repo conventions dumped into the window before the model touches anything. Stop guessing, here are the rules of this project.
Weakness: the model knows what to do, but has nothing stopping it from doing something else.

2026, Harness. Sandbox, tests, permissions, logs. The model is just an engine, the harness is the rig around it. There's a number going around that the same model jumps from 52% to 66% on coding tasks purely from a better harness, without anyone touching the weights. I can't verify that number, but the direction matches what I see: most of my quality gains in the last year came from the rig, not the model.
Weakness: you're still the one handing out every task.

Then, Loop. "I don't write prompts anymore, I have loops that assign work to the model." You start it and go get coffee. It watches PRs, fixes CI, picks up feedback.
Weakness: nondeterminism. Run it twice, get two different worlds. Fine for a side project, not fine for a paywall.

Now, Graph. Instead of a loop that improvises, you draw the thing. Code, then ALWAYS review, then merge. No guessing about order. Google reportedly rebuilt their agent dev kit from an agent runner into a graph engine for this reason.
Weakness: unknown so far. There will be one. Probably that the graph itself becomes a codebase nobody wants to maintain.

The skill is spotting the ceiling, not learning the name

Here's what I think people get wrong. They chase the vocabulary. New term drops, half the timeline rewrites their setup that weekend, usually because someone with a big following said so.

The actual skill is different. It's looking at a layer and knowing quickly where its ceiling is, and which lever to pull so the output gets good. Not "which layer is currently correct", but "this one will break on step 30, so I need a gate there".

You don't learn that from a thread. You learn it because you've watched it break a few dozen times. Which is a very old skill wearing a new hat.

What my day actually looks like

I set the rules, the permissions, the test gates, the review steps.
The agent works.
I read diffs and say yes or no.
When it gets stuck, I finish it by hand.

Less code written. More decisions made. And the decisions are the part that was always hard.

The pattern nobody says out loud

Look at the direction of that chain again. Prompt is a request. Graph is architecture.

Every single layer added since 2022 exists to take freedom away from the model and give control back to a human. Context takes away guessing. Harness takes away access. Loop takes away idle time, and then graph takes away the loop's improvisation.

The better the models get, the more control we take back. Not less.

That's the opposite of the story being sold. "AI writes everything, developers become obsolete" doesn't survive five minutes of contact with a production system. Somebody has to decide where the review step goes, where the rollback goes, which permissions the agent never gets, and whether a PR that looks fine is actually going to break checkout on Friday evening.

The people most sure that developers are finished are usually the people who have never run an agent against a real repo.

So what's next

I don't know.

Maybe the abstraction gets good enough that we end up back at prompting. You say what you want, and underneath it a graph of loops does something nobody fully follows anymore. The circle closes.

Even then, someone designs that graph. Someone maintains it. Someone gets paged when it merges garbage at 3am.

Guess who.

Not interested in which layer you're on. Where did you hit its ceiling? That's the more useful conversation.

Can we play a game on pixelden? Made my pixel art game portal playable inside Claude via MCP

Tomas Grasl — Thu, 30 Jul 2026 20:01:58 +0000

I hacked the new MCP UI extension 😎

By which I mean I read the spec and used it exactly as documented, for a dumb little game. 😅

MCP Apps is the official MCP UI extension. Short version: your server declares an HTML resource under ui://, links it to a tool via _meta.ui.resourceUri, and the host renders that HTML in a sandboxed iframe right in the conversation. The iframe talks back over JSON-RPC, so it can call tools. Not a rendered screenshot, a live UI.

Everyone is shipping dashboards and forms with it. I put a game loop in there.

The tool starts a run, the iframe is a real one button arcade game. When you crash, the widget sends the seed and the ticks you jumped at back to the server, the server replays them through the engine and computes the score. The model never touches the number.

👉 https://www.pixelden.io/play-in-claude