I asked Claude Code to build an agent loop. It gave me eight appetizers, a fake, and a software engineering reading list.
I was recently building an AI agent harness with Claude Code.
I expected it to start with the agent loop. That’s the heart of an agent harness, right?
But Claude Code took a completely different path.
First, it started defining messages.
Then events.
Then interfaces.
And just when I thought it was finally getting somewhere, it created a fake implementation.
A fake? Seriously?
Where the hell is my agent loop?
It felt like I’d ordered a steak, but the chef kept bringing out appetizers—eight of them.
Still no steak.
But then something clicked.
I took another look at what Claude Code had built.
The message types, the events, the interfaces—and that seemingly unnecessary fake.
Wait a minute.
With the fake in place, I could test the agent’s behavior without even having a working harness.
That was clever—really clever.
I’ve been writing software for over 20 years.
And I have to admit, this one humbled me.
So, with my ego considerably smaller and my voice barely above a whisper, I asked Claude Code one simple question:
“What’s your coding SOP?”
The Seven Steps
And here’s the sequence I got:
Step 0 — Read Before Writing.
Read the steering documents, specifications, task descriptions, and existing code. Understand what already exists before changing anything.
No coding yet.
Step 1 — Scaffolding and Guardrails.
Set up the module structure and basic sanity checks before implementing features.
Step 2 — Define the Vocabulary.
Establish the shared data types: messages, events, and the objects that everything else will use.
Step 3 — Build the Small, Independent Pieces.
Implement leaf utilities first, especially security-sensitive ones. Test them with deliberately nasty inputs.
Step 4 — Define Ports and Build Fakes.
Separate the core logic from external dependencies, then create fake implementations for testing.
Step 5 — Finally, the Core Logic.
Write the agent loop, testing its behavior through the fakes—including the different ways a run can end.
Yes, the agent loop finally shows up at Step 5.
Step 6 — Connect the Real World.
Only now wire up the actual adapters: DynamoDB, Bedrock, and other external systems.
Looking at the whole sequence, I began to understand why Claude Code had spent so much time preparing the ground.
It wasn’t simply writing code in the order I expected. It was arranging the pieces so that each layer could be understood and tested before the next one arrived.
But one step in particular caught my attention.
Ports and Fakes? Where Did Those Come From?
Step 4 — Define Ports and Build Fakes.
Ports and fakes. Those sounded suspiciously like ideas borrowed from a software engineering textbook.
So I politely asked where those ideas came from.
Claude Code came back with a reading list.
Five or six books.
Not random blog posts, either. Actual software engineering classics, including Uncle Bob’s Clean Architecture.
And then, as if that weren’t enough, it told me that if I were to read just one, it would recommend Architecture Patterns with Python.
I had asked a coding assistant to write an agent loop.
Somehow, I’d ended up with a software architecture reading list.
The Part I Almost Missed
The more I thought about it, the more interesting Step 4 became.
A port defines the boundary between the core logic and something outside it.
A fake provides a lightweight implementation of that boundary.
Together, they make it possible to exercise the core logic without dragging real infrastructure into every test.
No real database required. No actual model service. No need to spin up the entire harness just to find out whether the agent handles an event correctly.
And that’s when I realized what had impressed me so much.
It wasn’t the fake itself. I’ve seen fakes before.
It was when Claude Code chose to introduce it.
Before the agent loop.
Before the real adapters.
Before much of the machinery I had been impatiently waiting for.
The design made the important behavior testable before the full system existed.
That’s a different way of thinking about the order in which software should be built.
Of course, this doesn’t mean every project needs a port for everything, or that creating a fake automatically makes a design good. Abstractions have a cost, too.
But in this particular case, the separation was doing real work.
I had been staring at the missing steak.
Claude Code had been making sure the kitchen could actually cook it.
What Was I Really Learning?
I kept thinking about those seven steps.
None of the individual ideas was revolutionary. Reading requirements, defining types, testing small components, separating dependencies—these are familiar software engineering practices.
You can find many of them in books that have been around for years.
What caught me off guard was seeing them put together into a working sequence, applied consistently, without me explicitly requesting most of it.
And this wasn’t something I’d noticed only once. I’d seen similar behavior in other projects.
I started with a simple question about why Claude Code was taking so long to get to the agent loop.
I ended up asking a much more interesting question:
What engineering reasoning led to that decision?
Why define the messages first?
Why introduce a port here but not there?
Why use a fake?
Why test this component before implementing that one?
And perhaps most importantly, which of these decisions are genuinely good engineering, and which are just unnecessary ceremony?
Claude Code can explain its choices, but that doesn’t automatically make every explanation correct. I still need to look at the code, challenge the assumptions, and judge the tradeoffs.
In fact, that may be where the best learning happens.
A Different Way to Learn From Claude Code
I think I’ve learned my lesson.
Next time I watch Claude Code write software, I won’t just be looking at the code it produces.
I’ll be paying much closer attention to the decisions it makes along the way.
The engineering SOP behind the implementation.
The design principles behind the abstractions.
And the reasoning behind each decision.
Not just what it wrote, but why it chose to write things that way.
After more than 20 years of writing software, apparently I still have plenty of homework to do.
And I’ve found a rather unusual teacher.
One that never seems to get tired of my questions.
Next time, I’ll probably ask “why” a lot earlier.
Preferably before complaining about the appetizers.
So next time you walk into a steakhouse and they bring you eight appetizers before your steak, congratulations. You may have just discovered a hidden gem.
Do me a favor and send me the address.
As for me, I’ve got some reading to do.
Leave a Reply