Closing the loop

June 2026 – Jan Rietveld

I've got time on my hands. Besides the work I do for my clients, I'm in a phase right now where I don't have many new product ideas, and everything feels pointless because everyone will be able to vibecode it anyway once Fable drops.

What I do have is my regular job as a software programmer. That keeps going, and it's changed a lot over the past few years because of AI. And since I work for myself, I'm also highly motivated to optimize that work.

I want to walk you through how I use AI in my work as a software programmer right now, today. The concept I live by these days is called 'Closing the loop'. I'll tell you what it means and how I apply it.

AI models are good at programming. That has everything to do with what they call 'verification loops' in Silicon Valley. The moment you have a task where you know what the answer should be, you can set up a loop that doesn't stop until that answer is reached. Code is the perfect example: a piece of code passes or fails. Run that process often enough, and you make a model measurably better.

That works great for 'logical code': an API takes input and expects a certain output. It gets trickier with something like the design of a website. Under the hood that's also code, but an AI can't 'see' on its own. Yet this is verifiable too. We have a design in Figma, so we can tell the AI exactly how something should look. Give the model access to that design plus the ability to take a screenshot of its own work, and you've got a loop again.

We keep realizing more and more that a huge amount of what people do, especially at a computer, can be broken down into loops like this.

Let me walk you through how I apply this concept in my own work right now.

I've been programming with AI for years, but only since this year has it gotten really good. Where I used to use AI as a co-pilot that made suggestions, a few months ago I let go of the wheel. Every bug, feature or improvement now starts with an agent. Last year I still wanted to keep control myself; now the AI can simply do it better and faster. What I look for most are the spots where it can't yet. That's where I need to be.

I don't hand AI total control, and that's not the goal either. The goal is to build the right things faster. When AI gets something wrong, you can think 'fine, I'll just do it myself', or you can adjust your workflow so it doesn't make that mistake anymore. A lot of people get stuck on the first one: 'it can't do everything yet, so I'll do it myself'. But then you're investing in the wrong place. You're better off building a system where you sit exactly where AI isn't good (yet).

Back to practice. So everything starts with a request to an agent — Claude Code in this case, but next week it could be Codex again. Doesn't matter, these days they can all do the same thing. I tag Claude in our Slack channel and drop something like: 'this screen doesn't scroll smoothly, can you figure out what's causing it and fix it pls' with a screenshot attached.

Claude gets to work. It spawns subagents that search the codebase, spots a few possible causes, picks the best fix itself, edits the code and validates that everything still works.

Done. Right? Nope. My whole career I've worked with backend devs who say something's fixed when it doesn't work yet. 'Did you test it?' I'll ask. 'It runs', I get back. Yeah, great. But good code doesn't always mean something actually does what I want.

So I told Claude it also has to actually run the project. I work on a mobile app, so that's trickier than a website. That's why I gave Claude access to its own Mac Mini, where it can use an iPhone simulator via an MCP. It launches the app, logs in and visually checks whether the bug is actually gone. If not, it goes back and comes up with a different solution. The loop is only done when it works — not when it runs.

Once the bug is fixed, Claude opens a Pull Request describing what it did. A second, independent agent then does a code review: does it match what was supposed to happen, and does it break anything else? If feedback comes out of that, Claude wakes up and picks it up automatically.

But, as they say, trust but verify. Just to be safe, I have Claude record a screen capture while it validates, which it sends along as proof that things are going well. For something bigger or more important, I sometimes still want to test it myself. Claude then sends me a download link that lets me put this specific build straight onto my iPhone.

Recently I've had Claude write a short report to go with it: what was the cause, which solutions did it consider, and why is this the best one? That goes into the PR, short and sweet, so I can judge faster whether it made any reasoning mistakes in finding a solution.

And only then do I come back into the loop and look at the code.

What I mostly notice is that programming with AI is becoming more and more a matter of trust. Do you dare to hand over control? Most of the feedback I still have isn't about mistakes, but about taste: a different convention, or something I'd have solved just slightly differently myself. If a human colleague had done it that way, I'd have approved it. If it's an AI, suddenly I have different standards, apparently.

In the three days I got to try Claude Fable, even that last bit of doubt pretty much vanished. And that's what 'closing the loop' ultimately means. Technically we can almost close the loop now, but do we dare to?

I want to close with a little timeline of how I use AI in my work:

2026 is the year you can actually trust AI and hand things off to it. And whether you dare to.