April 28, 2026
Building with agents has been fun in a way software has not been for a while.
Not because it removes the work. It does not. But it changes the shape of it. The feedback loops are tighter. The blank page is less blank. The little bits of friction that used to push good engineering hygiene onto the "later" pile are much easier to deal with now.
For me, I have always enjoyed the engineering process. I like testing ideas over and over until I am confident the system will behave in production the way it does in my head.
I am finding I can finally do things I always meant to do properly, but often did not have the time or energy to get to. Cleaner boundaries. Better validation. Properly stress testing applications. The kind of work that is not glamorous, but makes the difference between a demo and a system.
I did not learn anything new. I just finally have enough leverage to do what I already knew was right.
A recent example is an application I built for GOcxm. I was able to put it through proper stress testing using k6. I pushed it to failure in staging and improved response times by two orders of magnitude. That is an incredibly satisfying thing to do. It is also exactly the kind of work that usually sits on the pile of "I will get to it later."
Work like this often sits in the icebox until it becomes a fire that we engineers have to fight.
There's another side to this that's less fun: you own your slop.
The first pass of my agentic orchestrator was admittedly janky. It worked, but it was loose. Outputs were not tightly constrained. Responsibilities were not clearly separated. I let agents step on each other's toes.
I have been describing this to my brother using a mechanical analogy. Imagine a system with a bit of slop in a bearing. One wobbly joint might be fine. Two and you start to see drift. Three and the tolerances stack up and the whole thing binds or grinds to a halt.
That is what happens here.
One agent with loose output might be fine. Add another that consumes it loosely and you amplify the error. Add a third and now you are not debugging a bug. You are debugging a system that is internally inconsistent.
In my case, agents started reimplementing functionality that should have lived in the service layer. The boundaries were not clear, so the system filled in the gaps in ways that looked correct but were not. Now I have to go back and unwind that. Retire the duplication. Enforce the contracts. Put structure where I skipped it.
The slightly alarming part is that the system might appear to work, until it does not. It is a bit like the dreaded "it works on my machine" scenario, but with a blast radius that might actually threaten your business.
The upside is that it is easier than ever to identify and fix these problems. The downside is that it is also easier than ever to ship them. When code like this reaches production, the cost is not just technical debt. It is downtime, broken flows, and sometimes real consequences.
We are definitely seeing early versions of this. Systems making destructive decisions. Outages triggered by automated tooling. Failures that are not loud but cascade quietly through dependent systems. [1] [2]
That is where the earlier point lands for me.
You can still move fast. You can still be sloppy.
You just do not get to stay sloppy.
Because the system will not hold together if you do.
And honestly, that is part of why it is fun again.
The loop is tighter now. You can try something, see where it bends, fix the structure, and keep going. The reward for doing things properly is not theoretical anymore. You feel it immediately.
Agents did not change how I build. They removed the ability to get away with not doing it properly.
There is no place to hide anymore, and I am into that.