Daily AI News · October 14 Midday Edition: Claude Code's State Machine and the Boundaries of AI Tasks

Lots of new stuff in AI today. I was scrolling through my RSS and found a few really interesting articles. Li Bo, what did you check out today?

Here's what we're covering today. First, Claude Code's QueryEngine state machine. Second, AI generates in three minutes but the workflow still takes eighteen. Third, AI coding plan limits have become a production dependency. Fourth, DeepMind helping Singapore fight scams. And fifth, the thirty-million-dollar AI bank question nobody can answer. For deep dives, two topics: the Next.js security holes AI agents write, and whether AI impact receipts can be standardized. That's it.

Yeah, all of these have some real meat on them.

Let's jump into the news roundup. First one — I'm really into this one, because it's exactly the kind of trap I hit back when I was working on product lines.

You mean that breakdown of Claude Code's QueryEngine? I read it too. That series is up to part five now.

Yeah, that deep dive on dev.to. The first four parts covered individual mechanisms — tool declarations, approvals, hooks, parallel scheduling, plus stop-reason handling and recovery.

The key is part five, where it puts all the pieces together. And the conclusion is pretty counterintuitive: the core of Claude Code isn't that well-known five-line pseudo-loop.

Wait, isn't it just a while loop with tool calls? I thought every agent framework looked like that.

That's exactly the point. It's actually an explicit state machine. The pseudo-loop is just surface. The real QueryEngine main loop treats stop reasons, recovery paths, and parallel scheduling as state transitions.

Think about it — if it were just a loop, how do you recover after a tool throws an error? How do you get back to the right place when an approval gets stuck? Only a state machine can spell out those boundaries clearly.

Got it. No wonder some agents go completely off the rails the moment a tool fails — the states just weren't designed well. Let's move on from this one, but it's a good insight.

Second one — the title cracked me up as soon as I saw it: AI generates it in three minutes, but the workflow still took eighteen.

This one nails the pain point of a lot of automation projects. AI can make one step super fast, but the whole workflow barely changes.

Right — the draft goes from twenty minutes to three, but the team still spends eight minutes reviewing it, and then there's a whole chain of steps after that.

Exactly. That's the measurement mistake that makes so many automation projects disappointing. You optimized one step, but you're judging it by the KPI of the entire pipeline.

OK, noted. Then there's another one with a pretty dramatic title: your AI coding plan limits are now a production dependency.

This one's saying teams have come to depend on AI coding tool quotas like infrastructure. The moment you hit the limit, the whole dev process just grinds to a halt.

That's kind of scary. It used to be an API outage that counted as an incident — now plan limits can count as one too.

That's why the author also brings up cost control infrastructure — stuff specifically for managing money for agents. That space is pretty hot right now.

Alright, next one's from the DeepMind blog. They partnered with the Singapore government on a new AI tool to protect citizens from scams.

This one's cool — it uses a lightweight on-device Gemma model to intercept conversational scams in private chats, and the data never leaves the cloud... I mean, never leaves the device.

On-device plus zero data leakage — putting those two together is a smart move. Chat logs are just way too sensitive.

Right, if you did detection in the cloud, privacy would kill it. A small on-device model is the only way.

Last one — the title is 'that thirty-million-dollar question nobody can answer.'

Here's the background: VCs just poured sixty-five million into two AI-native payments companies. One is Catena Labs, which raised thirty million for an AI-native bank. The other is Sapiom, which raised thirty-five million for agent cost control.

So everyone's building the banking layer, but nobody's answering the real question.

Yeah, and Circle's co-founder is even applying for a national trust bank charter. The money's there, but nobody can even clearly say what the question is.

Alright, that's the news for now. Next, let's dig into two topics I think really deserve a deeper look.

First: AI agents writing seven kinds of security holes in the Next.js plus Supabase plus Stripe stack.

I'll lead with my conclusion on this one: AI agents are great at getting an app running, but terrible at making it secure.

How do these holes even make it to production? You'd think testing would catch them.

That's the crux. All these bugs pass a quick click-through test, so they look fine and get shipped. You'd never find them by clicking around manually.

So how did the author verify it? He can't just make claims without backing them up.

He built a reference app himself with Next.js 16, the Supabase SSR package, and the Stripe Node SDK. Every fix snippet is pulled from that app, so you can copy-paste them directly.

So it's not just a rant — it's an actionable checklist of rules.

Right. And I think there's a bigger issue behind this: security is weighted way too low in what AI agents are currently trained to optimize for. They optimize for whether it runs.

Wait — so by that logic, do we need to add a layer of human security review after every AI-written project?

I think a more realistic approach is to feed security rules to the agent upfront — turn them into rules, not after-the-fact checks. That's basically what the second half of that article's title is getting at.

I agree with that. Front-loading constraints is way cheaper than patching holes later.

Second topic — the title's a question: can AI impact receipts be standardized?

This builds on the Impact Receipt concept from CarbonLayer. The author's core observation is sharp.

He says if only one company can use it, it's a product feature. If different systems can produce and consume the same information, that's when it has a shot at becoming infrastructure.

Right — that's why standards battles are always nastier than product battles. Look at how many protocols in history were fought over that way.

But here's the problem: how do you even measure AI impact? That's way harder to quantify than carbon emissions, isn't it?

That's what makes it both the most interesting and the most dangerous part. Carbon has physical units; AI impact doesn't. Whoever defines the metrics defines the whole market.

So are you optimistic or pessimistic?

I lean optimistic. Because the real value of receipts like this isn't scoring — it's letting upstream and downstream in a supply chain reconcile. And if you can reconcile, you can trade.

So to sum up: whether AI impact receipts can be standardized isn't about the tech — it's about whether enough systems are willing to read and write with the same format.

Exactly — that's the classic infrastructure threshold. One company is a feature, many systems is a standard, many industries is infrastructure.

Alright, we got pretty deep into both topics today. That's about it for the news roundup and the deep dives.

Li Bo, what are you reading this afternoon?

I might go through that Claude Code state machine series again. I feel like there's more to dig out of it.

Alright, that's it for today. See you tonight.