Phenomenal game and a fun fact: Grim Fandango was AFAICT the first high-profile game built on Lua and became the catalyst for industry adoption

While I am skeptical of the results here, I am very excited for this new trend of making models faster. Running capable models at 1k TPS is more valuable for me than running better models at 30 TPS. I can only imagine the trend continues to move from "let's only make models smarter" to just incremental intelligence gains but with step improvements in speed.

Indeed. For me opus 4.8 is good enough. If only it would be 100 times faster. You could run it in self verification loops much much faster. It sometimes takes 15 minutes for me to complete a simple task. For example configuring AWS agentcore and deploying an agent on it. Takes forever with Claude with constant issues it tries to solve.

Why? I'm personally on the opposite end. Less babysitting/higher quality means more time goes back to me/the user. 1000tps of bad code means you have to keep validating the output and circling back.

id rather iterate multiple times than wait 15 minutes to notice it made a mistake.

Again, my point is exactly the opposite. Higher quality implies a mistake isn't made in a significant % of cases.

It's a lossy conversion though. "Mistake" is relative to the stated goals and specifications which are often heavily lacking. So unless you write with a high degree of architectural and implementation specificity then it might make very high quality code that is still not what you wanted.

You can ask for a complete feature/app/business. Or you can split up the work into verifiable/testable pieces and rely on a high quality AI to deliver. As time goes by the pieces will get larger as capability grows. I still trust myself and my experience when arch is involved, but AI has been great at tackling lower level stuff. And with Fable I don't really care it takes a while for it to complete, as I know I can trust it a lot more (which is what I personally prefer). Yes, with a 10k tps model you can iterate quickly. But that's not me personally.

But some requirements you don't realize you have until you start building. With a fast model, you can surface those really quickly and have more time to iterate and explore different solutions. With a slower but smarter model, you just hope that what it produces after an hour is what you were imagining.

And yes, with Fable, the chance of that is higher than with SWE/Composer, but in my experience it's not so much higher that the extra time and cost is worth it. But it certainly depends on your goals and what you're building.

High tps is good for deeper agent thinking loops and openclaw etc. I was running cerebus recently doing some data heavy tasks, it managed to crash the server I was submitting posts to. 6 hour task down to ~1hr

So i agree with you, but there's no SOTA model that i don't have to babysit. I'm not going to just throw a large pile of code in there unreviewed, and so what i want is faster iteration on code in logical, reviewable chunks. Ie just like i'd normally write myself; small, logical commits.

Faster iteration means i mentally checkout less and am more involved with the code being created.

My hope is that in the far far future, we can get LLMs so fast that i can work in my IDE like normal and the LLM will just be an extension of autocomplete. I can state a goal, rough out functions, code, etc, and it'll just work around me like a very fast pair programmer / autocomplete.

The chat interface is an intermediate step that frankly i hate. The faster it is the less i wait.

Now for vibe-slop i'm making on the side, yea i don't care about speed. But that's not something i'm employed to do or anything i truly care about. It's a different workflow entirely.

I get it, you just prefer to do things differently

> Faster iteration means i mentally checkout less and am more involved with the code being created.

This is a good point I didn't consider and you're right. More interaction brings you closer to the code.

I still think that this is the opposite of what I personally want. Either I write the code (or a large majority of it), and be fully involved; or be more disconnected but more free to focus on other things. The middle ground removes me from the equation, but also requires me to babysit.

Hey HN, author here.

The thing that makes this work is where in the loop the review happens. CodeRabbit, Greptile, etc review at the PR level after the agent is done. The findings go to a human who has to interpret them. The agent that wrote the code never sees the critique. We find that most people just spin up a new agent and ask "Are these review findings correct?" anyways.

Saguaro reviews during the agent's session and sends findings back to the same agent. Because the agent still has its full context window, it knows why it made each decision, it can evaluate the findings intelligently. "I made this choice for X reason, but this review shows a gap in my thinking, let me fix that." Or "This finding isn't relevant because of Y." The agent has the context to make that judgment call. That's why false positives are lower.

The daemon is completely invisible to the user. It self-spawns from the Claude Code stop hook, runs a SQLite-backed job queue on localhost, and auto-shuts down after 30 minutes idle. The review happens in the background while the user keeps working. We feed context from the original programming session into the review process. The findings surface on the next stop hook, your agent just starts fixing things.

For teams that want more precision, there's a rules engine: markdown files with YAML frontmatter that enforce specific patterns (architectural boundaries, security invariants, etc). But the daemon works with zero rules out of the box. The rules engine works great for teams with well-defined rules.

Some technical decisions: - SQLite (via better-sqlite3) as job queue, right amount of infrastructure for a local dev tool. - The daemon reviewer gets the original agent's summary ("the developer described their work as...") for context - Agent gets read-only tools (Read, Glob, Grep) with up to 15 tool calls per review, it can inspect the full codebase for context but can't edit.

Limitations: - The daemon review is async. Findings arrive on the next stop hook, not the current one. Fast iterations may miss a cycle. - Review quality depends on the model. We default to your configured model but you can override for daemon specifically. - Cost is your normal AI provider usage. `sag stats` tracks it.

Happy to answer technical questions about the architecture.

Unfortunately I'm not sure anybody will solve the issue of "quantization of the confidence level", a senior reviewer in a PR doesn't even do this. We believe that when agents are writing 10x more code than humans, the bottleneck is review throughput, not review precision. The measurable metric isn't "confidence level", we think it's "how many issues reached production that a 10-second rule check would have caught." That number is going up a ton as code volume scales.

We designed our integration with Claude code to reject edits before it's written if it violates a rule via an exit 2 code. Also don't think any system will be 100% on rule enforcement, senior reviewers included. We can't be perfect but we can raise the floor.

Actually our approach is the opposite. Writing rules forces teams to articulate what their standards are. Mesa makes you write them down, version control them, and review them as code, similar to a linter. This specificity is why this system works much better than a standard AI code reviewer that checks for general issues.

We aren't trying to replace tests or humans. The goal is to make them more effective by filtering out the noise before it reaches them.

Then Mesa is the bottleneck, only swiped under the rug. Right now you show you are confident enough in Mesa role, but can't prove its actual quality impact, only its quantitative impact.

FYI I went to your website and was thoroughly confused about the product.

So it’s trying to be like lovable, n8n, etc?

Then there’s stuff about Postgres and S3? I just closed the tab cuz I was completely lost.

Great catch thank you