Agent-driven improvements: How I let AI optimize korz.sh's infrastructure while I sleep
Built a system that runs performance and security improvements automatically overnight. Waking up to better code every morning is real. Here's everything I learned.
Every morning I do the same ritual. Wake up, make coffee, open my laptop. And every morning there’s something waiting for me — a notification, a PR, a diff showing what my agents improved overnight.
Security patches. Performance optimizations. Dependency updates. All applied while I was sleeping.
This didn’t happen by accident. I built it. And after months of running it, I have a lot to say.
The itch that wouldn’t go away
Korz.sh moved fast. Really fast. And like every startup that moves fast, we accumulated debt. Not the scary kind — the silent kind. Dependencies falling behind. Security vulnerabilities creeping in. Performance bottlenecks nobody had bandwidth to fix.
I was spending weekends on maintenance. Catching up on what I should have addressed during the week. It was killing my momentum.
So I asked myself: what if the infrastructure improved itself?
Not self-healing — that’s a different problem. Something more ambitious. What if there was a squad of agents that worked through the night, analyzing code, identifying improvements, applying changes — and all I had to do was review in the morning?
The failed attempts (before the right approach)
I didn’t get here on the first try.
The first version was a simple cron job that ran dotnet outdated and created PRs for minor updates. It worked, but it was dumb. It didn’t understand context. It would update packages that broke things, it couldn’t assess security implications, it had no concept of “this change might affect performance.”
Then I tried Temporal. Distributed workflows, activity handlers, the whole enterprise dance. It was powerful, but it was also rigid. Writing workflows felt like writing ceremony. Every improvement required defining a new workflow, writing activity handlers, managing retries. The system was solving orchestration, not intelligence.
What I actually needed wasn’t workflow orchestration. I needed agents.
Agents that could understand code. Agents that could make decisions. Agents that could learn from feedback.
That’s when I built Orch.
Building Codebot Workflow
The system I built has a dual-engine architecture. Two ways to run the same mission:
Orch is the new thing — a native multi-agent system with state machine. Three agents work together: an analyzer that studies code, an implementer that applies changes through an AI adapter, and a verifier that checks everything before it lands.
Temporal is the legacy path — kept around because some workflows are genuinely better expressed as workflows. The dual engine means I can use the right tool for each job.
The magic is in the abstraction layer. I called it IAiAdapter — a system that lets me swap AI backends. Currently running ClaudeCode, but it’s designed to work with OpenCode, Cursor, whatever comes next. The adapter interface stays the same; the model changes.
WORKFLOW_ENGINE=orch dotnet run --project src/Codebot.Workflow.ClientThat’s it. One command and the squad wakes up.
The real insight
Here’s what nobody tells you about building agent-driven systems: the hard part isn’t the agents.
It’s trust.
You have to build guardrails that let the agents be aggressive enough to actually improve things, but constrained enough that you don’t wake up to chaos. The analyzer identifies what could be better. The implementer makes the change. The verifier checks that the package is still valid, that the code compiles, that nothing broke.
Then it lands in my queue. I review with coffee in hand. I decide what ships.
Nothing goes to production without my sign-off.
The night it surprised me
Three weeks in, I woke up to a PR I didn’t expect.
The analyzer had found a dependency that wasn’t just outdated — it had a known vulnerability. The CVE was new, published the day before. The agent caught it, flagged it, the implementer applied the patch, the verifier confirmed the build passed.
I would have found it eventually. Maybe. Probably during a security audit that would have taken hours.
The agent did it in forty minutes while I was asleep.
That was the moment I knew this was real.
The benefits nobody talks about
Velocity compounds. When your infrastructure improves while you sleep, you’re not fighting entropy anymore. You’re working with it. Each morning you wake up to a better codebase than the one you left.
Technical debt becomes optional. You can defer maintenance knowing it will get addressed. Not perfectly — but addressed. The agents handle the obvious stuff. You handle the interesting stuff.
Context switches disappear. You stop context-switching between “building new features” and “maintaining old ones.” The maintenance runs in the background. You focus.
The system gets smarter. Every improvement the agents make becomes training data. The next iteration is better than the last. The system learns your codebase, your standards, your patterns.
The dark side (things that don’t work yet)
I want to be honest about the limitations.
Agents are bad at understanding trade-offs. They can tell you “this package is outdated” but they struggle with “this update is risky because of how you’re using it in your specific context.” That’s my job.
Agents don’t understand business priorities. They don’t know that a performance improvement on the authentication service matters more than fixing a logging inconsistency in the analytics pipeline. The pipeline config is my responsibility.
Edge cases are still hard. The verifier catches obvious breakage, but subtle bugs slip through. I’ve learned to be paranoid about anything that touches financial logic or security boundaries.
And there’s the trust problem at scale. Right now I review everything. That works for a startup. It won’t work at a company with 50 engineers and hundreds of repos. The system needs to get smarter about what requires human review and what can ship automatically.
What I’m building toward
The vision is an infrastructure agent that handles the boring stuff automatically.
Security patches? Automatic, reviewed, shipped. Performance improvements? Identified, tested, queued. Dependency hygiene? Continuous, no surprises.
I want to wake up and see what changed, not because something broke, but because the system found something clever. A better algorithm. A more efficient query. A pattern that could be refactored.
Right now the agents are reactive. They wait for the cron schedule and then run. I’m moving toward proactive — agents that watch the codebase, that understand the build pipeline, that flag issues in real-time as they’re introduced.
The tech choices (why .NET 10, why C# 14)
People ask why I built this on .NET.
Two reasons.
First, korz.sh is built on .NET. The infrastructure I was improving was already .NET infrastructure. Using the same stack meant seamless integration — the agents understand the project structure, the package ecosystem, the build conventions.
Second, and more importantly: C# 14 has features that make agent orchestration clean. The record types, the pattern matching, the source generators — they make it easy to define agent states, message passing, and verification logic without ceremony.
I could have built this in Python. But Python would have been the wrong tool for an agent system that needs to integrate tightly with a .NET codebase.
The question people always ask
“Doesn’t this make you replaceable? If your infrastructure can improve itself, what do you do?”
The opposite. This makes me more valuable.
I used to spend Friday afternoons updating dependencies. Now I think about architecture. I used to dig through changelogs trying to find what caused a regression. Now the agents flag anomalies before they ship.
The boring stuff got automated. The interesting stuff got my full attention.
That’s the deal.
The setup
Everything runs from a pipelines.yaml file. APIs to analyze, cron schedule, working directories, SDD configuration — it’s all declarative. I can trigger runs manually, schedule them, chain them together.
The agent squad (I call them codebot-squad) operates against this definition. They know what to look for, when to run, where to make changes.
The pitch
Look, I know this sounds like over-engineering. Why not just update dependencies manually?
Because manual maintenance doesn’t scale. Because every hour you spend catching up is an hour not building. Because infrastructure debt compounds the same way technical debt does — silently, until it becomes the bottleneck.
This system runs while you sleep. It improves your codebase overnight. And when you wake up, you review what changed, you learn what the agents found, and you decide what stays.
Your infrastructure becomes agent-improvement-driven.
The improvements don’t sleep. And neither does your startup’s competitive edge.
What’s next
I’m opening up the source eventually. The adapter system is generic enough to work with any codebase. The agent patterns are reusable.
If you’re a startup founder, SRE, or developer who’s tired of fighting entropy — this is for you.
The future of infrastructure isn’t infrastructure as code. It’s infrastructure as agents.
And korz.sh is leading that charge.
korz.sh — pingedbrain/korz Building infrastructure that gets better while you rest