AI Agents Aren’t Replacing Developers — They’re Cleaning Up After Us
- Mark Kendall
- 6 days ago
- 3 min read
AI Agents Aren’t Replacing Developers — They’re Cleaning Up After Us
If you’ve been paying attention to the AI space lately, you’ve probably heard a lot about agents.
Agent-first development.
Autonomous coding agents.
AI engineers replacing teams.
If you’ve actually shipped software at scale, that narrative should make you uncomfortable — and for good reason.
The reality is much simpler, much less exciting, and far more useful.
AI agents aren’t heroes.
They’re janitors.
And that’s exactly why they might finally work.
The Problem We’re Actually Trying to Solve
Modern software development isn’t slow because developers are bad at writing features.
It’s slow because of:
repetitive cleanup work
inconsistent standards across repos
endless dependency upgrades
mechanical refactors
policy enforcement by humans
cognitive overload
Senior engineers end up spending time doing things machines are better at, just to keep the system healthy.
That’s the problem this model addresses — not “AI writing your product.”
What This Diagram Is Really Showing
The chart above is not an autonomous development system.
It’s a controlled, event-driven cleanup model for the SDLC.
Here’s the simple version:
Something happens
a Jira ticket is ready
a security alert fires
a policy is violated
a maintenance window opens
Context is fetched safely
Jira, GitHub, Datadog are accessed through MCPs
MCPs are just controlled context services
no raw credentials
no unrestricted access
Janitor agents are called
they are not running all the time
they act only when triggered
they are told exactly what to clean up
A bounded plan is created
no redesigns
no “improvements for improvement’s sake”
just the task that was requested
Code changes are proposed
tests run
pipelines validate
humans review and approve
That’s it.
No magic.
No continuous evolution.
No loss of control.
Why “Janitor” Is the Right Metaphor
Janitors:
don’t decide what the company builds
don’t redesign the office
don’t work unless asked
follow a checklist
leave the place better than they found it
Good janitors are invisible — until they’re gone.
That’s how AI agents should behave in engineering organizations.
If your agents are constantly opening PRs, refactoring code, or “improving” things you didn’t ask for, the system is broken.
What This Model Is
Not
This is not:
AI replacing developers
autonomous product development
agents controlling releases
always-on optimization loops
Those ideas sound impressive in demos and fail spectacularly in production.
Real organizations care about:
intent
cadence
release control
auditability
predictability
This model respects all of that.
Where the Intelligence Actually Lives
The intelligence isn’t in the agent.
It lives in:
your architecture rules
your standards
your quality gates
your definition of “done”
The agents just apply those rules consistently.
That’s why this scales:
across repos
across teams
across languages
And why it belongs as a shared platform capability, not something feature teams reinvent.
Why This Actually Saves Money
Companies don’t save money by replacing engineers.
They save money by:
reducing rework
reducing review fatigue
reducing inconsistency
keeping senior engineers focused on design and delivery
You don’t pay janitors like architects —
but you also don’t ask architects to take out the trash.
This model respects that distinction.
The Real End Game
The end game isn’t “agent-first development.”
It’s:
cleaner repos
fewer dumb tasks
more focus on real problems
healthier software over time
AI agents don’t need to be heroes to be valuable.
They just need to show up when asked, do the job, and get out of the way.
Coming Next
Next, we’ll walk through what a minimum functional product of this looks like — something a real company could build, fund, operate, and trust without turning their SDLC upside down.
No hype.
No moonshots.
Just a practical starting point.
Comments