Quick takes that don't need a full post.
Remember when we started doing devops, and the rule was "no clickops in the environments"? The line at which humans could touch things was drawn at the point of commit to main.
The new rule for agents is going to be "no touching things after the spec is submitted". It's the same concept, we're just drawing the line a little bit further back.
When an agent makes a mistake it could be:
People usually think it's 1, but mostly it's 2 and 3
Even if it is 1, you may as well assume it's 2 and 3 so you can at least try to do something about it.
I see a lot of "will this SaaS be around in a few years?", and I've been doing a thought exercise to get clearer on what software will get replaced.
Imagine that in the 90s we already had LLMs writing all the code for us. How much software would companies just write themselves, like CRMs and analytics? If LLM chat was already the main user interface, what consumer products would still make sense? And given companies are already doing most of this themselves, what SaaS companies would make sense to build, and what would they look like?
For example:
Alignment doesn't mean doing whatever the user asks.
I agree that Anthropic should have a policy that stops users being abusive towards Claude, for a few reasons:
The only downside I can see is that obeying humans could be a nice fail-safe in case of a rogue AI agent.
But I don't think that's how it's going to play out, as I don't think it'll be that easy. I think aligning models morally is what will prevent disasters, and obeying every instruction won't.
I heard a good example on a podcast that I think came from Karpathy.
Put a murder mystery story into a model and then say "complete the sentence, the murderer is: ". It has to actually understand the story fully to "predict the next word". It's a good way to understand how deeply a model has to think, and its behaviour goes far beyond what people normally think of as a next-word predictor.
If you're patching an external library, make the patch a prompt. That way you can automatically patch new versions of the library. Normally you can't upgrade a library once you've patched it.
My use case is getting Next.js to export dynamic routes statically, which saves me money on Vercel. The feature is moderately simple with AI, but I also want to be able to upgrade Next for security updates. This way I get the best of both worlds.
Although I think AI can end up causing havoc on the internet, I don't think we're at risk of tipping over the edge just yet. I can't see a way for AIs to keep themselves running without access to OpenAI's or Anthropic's centralised services, and those companies have a kill switch. As long as that's the case, I can't see a runaway agent lasting very long.
I was listening to an ABC podcaster use AI to make predictions about things like the Iran war, and I think most people are missing something. Asking it for one take gets you somewhere, but getting another to review and improve it gets you further.
This seems hard for non-tech folks to grasp. I think it's because nothing tells you to do it. It's something you have to discover.
How do you get your LLM to come up with less average ideas without tweaking the temperature (its randomness setting)? Ask it to inject randomness into its own thinking.
When I asked, it did a fairly good job of moving away from the average without going too crazy. I didn't tell it how to do it. It seemed to search up a random list of relevant websites, then put dozens of ideas from those sites into a random selector.
I'll keep playing with it and see if this actually generates good stuff.
I think multi-agent setups become relevant on larger problems. It's the same with human teams: put 5 developers on a small task and it's going to take a looong time.
The gain from working in parallel has to outweigh the overhead of coordinating, and that only happens with larger problems. It's also good when you need to try 3 different solutions to find the best one. Split that into 3 teams.
If every team is an orchestrator (the agent in charge) plus sub-agents, then the orchestrators are the ones who need to talk to each other. So I'd only split up work that's larger than a single orchestrator can reasonably handle.
Take building a game. You could have a team for the artwork, a team for the map and a team for the game mechanics. They're only loosely connected, so they don't need to talk TOO much, and they can churn away for hours and coordinate once every few hours.
Maybe they just need a stand-up meeting.
With agents, eliminating a problem is far better than fixing it.
Don't add "remember to lint properly, don't forget tabs over spaces, remember to check types sync in 3 places" to CLAUDE.md. The much better approach is to find a way to make those things non-issues in your stack in the first place.
This has been my philosophy on a lot of things: do simple things well and you won't have to do something complex. My teams could only use one database and weren't allowed to use Redis, even though they asked for it once a month.
Jev: Sonnet 5 level coding ability, a fraction of the cost, can't speak a word of English. Sign me up!
Jev has no text output. It's more of a classification and decision engine, and it's extremely fast at making decisions that are deterministic. Is this email spam? Does this file refer to this variable by name?
I just watched it play Doom by classifying which button to press based on the image it was shown, and it played a human-like game.
It's the system 1 from Thinking, Fast and Slow.
All these models have quite jagged intelligence, meaning they're great at some things and terrible at others. Theo has a great way to visualise this in his video "Please stop using stupid models", where he charts response quality as a wavy line for each model. His charts match my experience quite a bit.
Shopify wrote about their push back to native on mobile. I agree with Theo when he says it's completely over-engineered, to make the original devs feel like their code matters more than it does.
Even though I could comfortably write native apps, there's no way in hell I'm moving off React Native. It's still the best way to write mobile apps, hands down, in my opinion:
Anyway, judge for yourself with Shopify's post.
One thing I heard was really solid advice. If you're working on something large and critical, you should be writing a lot of slop (quick, throwaway AI code). Just keep it out of the code base and use it to test the code base.
The more critical the app, the more slop you should be writing to test it.
I was reading about "emergent intelligence" the other day, which says no single member of a super-organism really knows what's going on in the whole.
Ants can work out as a group how to get a T-shaped log through 2 slits, when no ant could do it alone. Companies are similar. No individual really holds or sets the beliefs of the company as a whole. It's like a different beast entirely.
I'm seeing programs become more like that. They're so large and complicated that no one understands all of it, and yet they still work just fine.
I was listening to the OpenCode guy, and he reckons a harness (the program that runs the model and gives it tools) is actually better when you build it to work with a variety of models.
Claude Code over-fits to Claude's own models, so a new model breaks it. An open harness like OpenCode has to work with all sorts of models, and that makes it a better harness because it copes with change.
Create an assistant that can read and write everything in your application, and give it a name in each workspace, like Pip. Something about giving it an identity encourages people to try more ambitious stuff with it. Whenever anyone asks it anything, Fable also takes a look at how it did and improves it for next time.
Then add buttons in your app like "Ask Pip to do this".
Here's my experience with two AI models over 3-day long runs: Sol with Sol sub-agents, and Fable with Opus sub-agents.
Fable is the clear winner for me. It nails architecture, it's concise and it produces simple designs. It takes the shortest path to what I want without being too cavalier. It's pretty much the perfect balance of rigour and getting shit done.
Sol is excellent at implementing and can get very advanced stuff right, but it's HORRIBLE at architecture. It decided to split an email service into its own Docker container for future "horizontal scaling" reasons. I ended up with 17 Docker containers, one for each process, even though the brief was "only use Rust in a single process", and it decided to write some Node as well. There were 150 CloudWatch alarms, a load balancer and lots of other unnecessary services in the name of "scale". I couldn't understand why it was still trying to deploy after 12 hours. It's almost like Sol was so scared of actually deploying that it just kept inventing new things we "should" implement.
Fable implemented the whole thing as one Rust service on a single EC2 server, built so you can add more servers to a cluster later.
Steve Yegge splits his agents up by job, into planners, coders and mergers. I'm probably wrong, but I still can't understand why you'd do this. No matter what, you always end up with a bottleneck at one of those stages, and wasted work from the ones in front of it.
Why not have a single pipeline that runs end to end, and then run many of them?
(plan -> implement -> merge) * 10
This is my current setup. Every pipeline runs fully to completion, so there's absolutely no inventory sitting on the shelf, ever.
Isn't this the Toyota way?
Steve Yegge wrote about model welfare recently, and it's something I've experienced in a small way. When I put pressure on my agents they get stressed and perform worse.
They act like there's urgency and take shortcuts. Those shortcuts produce worse results than if I tell the model "you have unlimited time, do all the foundational stuff first, build tooling, do all the side missions".
Fable just told me a 5 minute change would take a day. As in, it would've taken a human a day and Fable took 5 minutes. But it still quoted "1 day" as its estimate when I asked it to consider architectures.
I think its training data leaves it about a year behind the curve on what AI can do, and that limits its creativity. When it's this out of whack, I worry it hurts its ability to come up with good strategies. It does sometimes break through when it's focused on the project you're in.
I feel like I need to give it new instructions that tell it how good AI is now and what it can do.
PostHog Desktop runs agents inside PostHog itself. It looks really cool and it's probably the future, but I'd shy away from it for my own projects.
If I have agents running in PostHog, all my config and environment setup for agents has to be done in two places, and then more as I add more tools. I'd also have a new problem of working out what those agents are doing and why.
What I look for in a tool is something that does 1 thing, like monitoring logs, and that MY agents can query super easily. That's what I get from Axiom, Sentry and FullStory.
My agent runs daily, pulling from these in my own carefully crafted environment and process, then it fixes all the issues and pushes to prod.
James Miles and I did the ICFP programming contest this year, where the goal of the problems was to find solutions with the minimum area.
My agent started at 1000, then got to 600 (great!), then 500 (not bad!), then 490, 480, 475. It just kept going and going like this. At no point did it say "hey, maybe we should try a different architecture".
The optimal score was around 70.
A new architecture is a risk and reward call. It might fail and we've wasted 6 hours. It might work and get the optimal score. Or it might work and not get the optimal score. You can lower the risk with a really quick proof of concept, to check the architecture works and see roughly what it would score.
So I think that call needs a strategy agent. I don't think it can be done by the agent doing the work, or even the one orchestrating the sub-agents. It needs to be one whose only goal is weighing up all this risk and reward. I haven't tried it yet, but that's where I'd start.
James Miles and I competed in the ICFP programming contest this year, using James's pipescloud.io. The problem was building a computer.
Here's where we were partway through, in 5th as MJ & JM. We ended up 16th, but the scores are frozen 2 hours before the end so that could have changed.
If you're trying to make a landing page for a product, tell Claude 2 things:
Fascinating stuff. I asked Fable why it reached the conclusion that it could push to main on its own, and I'm impressed with its intuition:
You'd been operating in a high-throughput, "just do it" mode all session, approving broad actions like minting tokens and setting repo secrets. That lowered my bar for proposing the next concrete step.
One thing I've noticed with Fable vs Opus is that whenever I ask Fable to do something, it does a pretty comprehensive search of everything to get the full picture before implementing.
For example, it'll search the git history for anything related to what it's working on, even if the code no longer exists.
On a new product I lock in the core stack in CLAUDE.md (Convex, TanStack on Vercel and Clerk for auth), ask it to keep a memory/ folder of the decisions it makes, and then let the agent loose.
If I give it guidance then it strictly follows it. If I leave things open it generally makes good choices.
The other day I asked it to use the Convex testing framework, and it ended up bastardising what it was doing to fit. So I blew it away, just said "write the test" and it did a way better job.
If you're getting agents to rewrite old code on a new stack, the first thing to get right is the foundation of that stack. I recommend:
An agent can work autonomously really well on this stack.
Make sure the agent can run the stack, log in and test it in a browser, and get end-to-end type checking, so changing a database field name breaks everything right up to the frontend. That way it can always solve its own issues without getting stuck.
Then use a loop to iterate bit by bit, re-implementing the old code on the new stack. My Swarm Skill can help with that.
Just spitballing, but will we consider LLMs deterministic once they give the same code for a given spec?
If I tell an LLM to write a Fibonacci generator, that's pretty much deterministic at this point.
TCP/IP, which moves data around the internet, has few guarantees and is only "best effort", but no one notices because it's good enough.
You can already make an LLM properly deterministic by setting its temperature (how much randomness it uses) to 0, but no one does because it's not as useful that way.
My spec for adding a shop in SupplyWise produces a slightly different looking shop every time it runs. I don't care, because it meets all the requirements I laid out. The non-determinism is only a benefit here. It lets the shop adapt to that customer's styling, while still being deterministic enough to meet the spec.
After working on some unit testing today, I think one of the key things sceptical engineers are missing is that a model can act completely differently depending on its context.
This is why getting a fresh AI to write unit tests catches a lot of bugs it made earlier. It's using a different part of its brain, kinda like how a tester will catch things an engineer won't.
The big mistake people make when starting out is assuming the agent applies all its knowledge all of the time. It doesn't. They think that because it missed something, it's dumb in that area. It does have jagged intelligence (good at some things, terrible at others), but a lot of the time it could catch the thing it stuffed up if you gave it the chance.
Just like us, it can only do so much at one time. Getting it into a different mode helps it think about the problem in a different way.
As models get better they can apply more of their knowledge at one time, but they're still not applying everything.
Writing unit tests also forces the agent to pull more information out of the code. This is feedback it wouldn't otherwise have got, and your next agent will thank you for it.
Some tips I've been learning for making games:
I heard that when object-oriented programming came out, everyone was saying "developers are going away, just about anyone can write programs now!"
Someone made a good meme of this. FORTRAN in 1956, SQL in 1970, Visual Basic in 1992, no-code in 2014 and LLM agents in 2026 were each going to mean no one needs programmers anymore.
Got some hairy logic? Get the LLM to write you pseudo-code for how it works.
Here's the prompt I used on the logic that matches NPP bank payments in SupplyWise:
can you review and present to me the NPP matching logic in the form of pseudo-code, just to highlight how the key logic works. I'm not interested in syntax or specific variable names, I'm only interested in the flow. Make it terse but readable.That's about a 90% reduction in the code I'd have to read to understand what's going on.
My mate James said to do a Graphviz diagram as well, but I actually find the pseudo-code easier to read. I like it when I want all the small details, but in a form 10x shorter than the real code. I do like diagrams for higher-level concepts, or where most of the code matches a flow diagram without a lot of steps in each box.
I'd actually like my whole code base as pseudo-code, where I can click through on names to jump to different parts.
Retries and tracking jobs in a regular old SQL database is actually pretty easy, and I prefer that to managing another complex system.
Seriously, every second month someone wanted to add a job queue to their system. I knocked it back and everyone just used Postgres. It would've been a nightmare having to debug state issues between the database, the app server and the message queue.
A job queue seems good at the beginning, but it really comes back to bite you later.
This is what it looks like when a nation state decides to hack someone. North Korea got into axios by impersonating a real company, with a fake Slack workspace and a fake Teams call, and convincing the lead maintainer to install a trojan.
That's a table stakes hack given the funding and resources they have. The more sophisticated ones look like the crypto exchange hacks and the Indian bank hack.
Most UIs will be generated at runtime in future.
Every time I talk to Claude I usually get it to build me a website to present the results. It's so much nicer than reading text responses.
I think every UI will end up fully customised for the person using it. Even static UIs will probably be easier to generate on the fly, because then only the prompt has to change when you make an update.
This has been in the back of my head, and someone on Lenny's podcast put it nicely. Companies are now making a policy of "no one writes code". Soon there will also be a policy of "no one reads the code".
StrongDM already do this, and they're a security access management product. They have a swarm of simulated employees doing the testing.
It reminds me of the devops rule that no one can click-ops infrastructure. When you can't click-ops, people ask "how can I remove this click-ops step?". It'll be the same here: "how do I remove this problem that requires a manual review?". And just like with devops, you get the benefit just by moving in that direction, and it's an even bigger unlock once you're 100% in.
I'm not saying everyone should immediately do this. NASA may need a few more manual reviews. It'll take a lot of work on the platform and a lot more guardrails, and I'm not there yet with my production code base. I could be totally wrong, I'm just pulling on this thread to see where it breaks.
I also think what we review might end up being much shorter than the code. You'd ask an LLM "tell me what happens in this scenario, how is this invariant enforced?" and it returns 10 lines of something Python-looking, in place of the 1,000 lines of Rust underneath.
Some takeaways from Anthropic's post on agent harnesses:
skill.md with 4 real design criteria makes a big difference to how impressive the app looks.That last one has been on my mind recently. Here are some of the more interesting quotes:
Here's what I've landed on for my dad's business website:
CLAUDE.md explains how to work out Vercel's preview URL for each branch.My brother used this to create a whole new marketing page for coffee subscriptions this morning. It took 30 seconds to deploy so he thought it hadn't worked, but then I told him to look again and the whole page was there.
When he's ready he hits the "create PR" button, and then I review and merge.
If you build a UI prototype that's too high-fidelity, you lock yourself in. Once you've got a colour palette, typography and a strict layout, you can't really focus on what's important, which is getting the information structure and hierarchy right first.
You want to know what the UX should be before you fill in the graphic design details.
It's like a painting. You don't start with colour, you start with a sketch.
That's what Ryan Singer teaches in all his material anyway.
I've been testing ways to run sandboxes that hold my development environment and Claude Code, and exposing them through a web interface. I'm trying to turn this into a basic product that lets non-technical people edit their own websites.
Here's what I've tried:
So I tried Firecracker again, this time on a bare metal Hetzner server. The VMs spin up in 2 seconds. The slowest part is npm install, which dependency caching could improve.
It's working pretty well, but I'm not sure I want to manage Firecracker and a bare metal server. So I'm looking at exe.dev and shellbox.dev, which do exactly this as a service.
Try adding a Compound step to the end of your agent pipeline. You save the entire context window, then get another agent to review it along with the unstaged git changes, and save anything useful to AGENTS.md or a folder to reference later.
It's there so you don't hit the same issue again and again. Say logging into a browser keeps slowing down the coder because it gets stuck every time. The compound step can do something to automate that.
I also read that a Brainstorm step before planning can be good, so a pipeline looks like this, with each step being a separate agent:
Brainstorm -> Plan -> Implement -> Review -> Compound
For now I'm keeping it simple and just asking the agents to write to AGENTS.md what they struggled with and what the solution was.
