Loops are magical.

I’m trying to build a one-person business that can scale up customers without having to scale up head count.

As such, I’ve been thinking a lot about loops lately.

Not the kind you write in code. The kind that keep running whether you’re paying attention or not.

For most of my career, fixing a bug looked something like this:

1. Someone runs into a problem.
2. Maybe they tell you. Usually they don’t.
3. If they do, someone writes it up. It sits in a queue. Eventually someone picks it up, figures out what went wrong, writes a fix, waits for a review, and ships it.
4. Days. Sometimes weeks. Sometimes never.

Over the last few weeks, I’ve built something different for Crafd.

Every page in the studio has a small “Bugs/Feedback?” button tucked in the corner.

Click it, and it grabs a screenshot of what you’re looking at, along with any errors the page has hit. Then it asks one question:

what went wrong, or what would you like to see changed?

Errors don’t even need someone to click anything. When something breaks, on the server or in the browser, it gets logged automatically.

Either way, a new issue shows up in Linear.

That’s where Conductor comes in.

Conductor is the little system I’ve been building on a Mac mini to run my AI agents.

Every minute, day and night, it checks Linear for anything new.

When it finds something, it claims it.

One agent reads the report, looks at the screenshot, digs through the code, and writes a fix. Tests included.

A second agent reviews it.

If the reviewer isn’t happy, it sends the fix back. They can go back and forth up to three times.

Once they agree, the fix is merged and shipped to staging.

Then a little note shows up on my dashboard with a link to the issue and the pull request.

That’s it.

But that’s magical!

No one gets paged. No one has to triage anything. A report that comes in at 3 a.m. gets the same treatment as one that comes in at 3 p.m.

This week, a maker left feedback on the new drop page. Less than three minutes later, the fix was on staging.

Another time, the database hit a deadlock. The reviewer sent the first fix back. Then the second one. The third one passed. Twelve minutes, start to finish.

I didn’t touch either of them.

Now, I didn’t just hand over the keys.

And nothing reaches production until I’ve reviewed it.

It isn’t perfect. Sometimes the agent looks at a report and decides it’s not really a bug, or that it’s too big to fix on its own. When that happens, it explains why, flags it for me, and moves on to the next one.

Honestly, that’s exactly what I’d want a person to do.

What surprised me most wasn’t the speed.

It was the shape.

• Feedback becomes an issue.
• The issue becomes a fix.
• The fix ships.
• Someone uses it, and leaves more feedback.

Around and around.

Every time the loop runs, the product gets a little better.

I used to think of bugs as interruptions.

Now they’re just inputs.

The loop takes it from there.

And I get to go for my run instead of being glued to my screen fixing bugs all day.