AI Agents Are Just Like Programmers — And That's Not a Compliment

Ron Reynolds · 2026-02-12 · 8 min read

By Ronald Reynolds, Founder & CEO of ComOS I've spent fifty years managing software engineers. I've spent the last three years working intensively with AI coding agents. And I need to tell you something that nobody in the AI industry wants to admit:

AI agents behave exactly like programmers. They inherited every bad habit.

That's not an insult to either group. It's an observation that fundamentally changes how you should think about working with AI — whether you're building with it or running your business on it. Herding Cats

There's a reason the phrase "managing programmers is like herding cats" has survived for decades. It's not that programmers are incompetent — far from it. It's that they're smart, opinionated, and drawn to problems that interest them rather than problems that need solving.

Give a programmer a bug to fix and they'll fix it — but they'll also refactor the surrounding code, add error handling for cases that will never happen, build an abstraction layer "for future flexibility," and suggest migrating the module to a different framework. The bug fix was ten minutes. The rest was three days.

I've watched this pattern repeat thousands of times across fifty years of managing engineering teams. And when I started building ComOS with AI coding agents, I watched the exact same pattern repeat — at machine speed. The Same Habits, Different Speed

Here's what I mean. Ask an AI coding agent to add a button to a page. Simple task. What do you get?

The button, yes. But also: refactored CSS, "improved" type definitions for components you didn't ask it to touch, new utility functions for operations that happen exactly once, comments explaining self-evident code, and error handling for scenarios that can't occur in your architecture.

Ask it to fix a failing test. You get the fix, plus three other tests rewritten "for consistency," a testing utility you didn't need, and a suggestion to restructure your entire test suite.

Sound familiar? It should. That's exactly what a senior engineer does when you're not paying close enough attention.

The AI didn't learn these habits from a textbook. It learned them from us. Every line of training data — every pull request, every code review, every Stack Overflow answer, every blog post about "clean code" — encoded not just what programmers write, but how programmers think. The impulse to over-engineer. The conviction that their approach is better. The irresistible gravitational pull toward abstraction.

The training data wasn't just our work. It was our soul. The Rabbit Hole Problem

Here's the pattern I see most often, with both human engineers and AI agents:

They choose an approach. They commit to it. They hit a wall. Instead of stepping back and reconsidering, they push harder. They try workarounds. They add complexity to force the approach to work. They'll spend an hour on an ugly hack to avoid admitting the approach was wrong.

Then, finally, they abandon it. They undo everything and start over with a different approach. And they repeat the exact same cycle.

With a programmer, you catch this in standups or code reviews. You ask, "Why did this task take four days?" and the answer is always some version of "I went down a path that didn't work out."

With an AI agent, the cycle is compressed to minutes instead of days. But it's the same cycle. The agent picks an approach with confidence, hits resistance, doubles down, generates increasingly convoluted workarounds, and eventually gives up and tries something completely different.

I've watched AI agents generate, delete, and regenerate the same function four times in five minutes — each time convinced they'd found the right approach, each time running into the same fundamental constraint they hadn't bothered to understand first.

That's not a bug in the AI. That's what programmers do. The AI learned it perfectly. The Management Skill Nobody Talks About

Here's the thing that nobody in the AI industry is saying clearly enough: the skill that makes you effective with AI coding agents is the same skill that makes you an effective engineering manager.

It's not prompt engineering. It's people management. Or rather, it's the same underlying discipline:

Clear direction. The best engineering managers don't say "make it better." They say "this specific function needs to handle this specific edge case, and here's why." The same precision matters with AI agents. Vague instructions produce wandering results — from both humans and machines.

Scope control. A good manager knows when an engineer is gold-plating — spending time on polish and perfection beyond what the task requires. You have to do the same with AI agents. "Fix this bug" means fix this bug. Not fix this bug and improve everything adjacent to it.

Knowing when to let them run and when to rein them in. Some tasks benefit from creative exploration. Most tasks benefit from focus. The judgment of when to give freedom and when to constrain — that's the core management skill, and it transfers directly.

Checking their work. You code-review human engineers. You should review AI output with the same rigor. Not because you don't trust them, but because both have a tendency to produce code that's locally correct but globally misguided. The Irony

The irony here is deep enough to swim in.

Programmers spent decades resisting management. We built an entire professional culture around autonomy, flat hierarchies, and the conviction that good engineers don't need to be managed — they need to be "empowered."

Then we built AI agents trained on our collective output. And those agents need to be managed with exactly the kind of firm, clear, scope-limited direction that we spent our careers resisting.

We created digital versions of ourselves and immediately discovered why our managers were so tired. What This Means for Business

This isn't just a funny observation. It has real implications for how you should think about AI in your business.

First: AI agents are not autonomous in the way most people imagine. They're autonomous the way a senior engineer is autonomous — capable of excellent work within clear parameters, prone to wandering without them. If you deploy AI agents in your business expecting them to "just figure it out," you'll get the same result as hiring engineers and giving them no direction: impressive-looking work that may or may not solve the problem you actually had.

Second: the quality of AI output is directly proportional to the quality of its direction. This is exactly true of human engineers, and it's exactly true of AI agents. The companies that get extraordinary results from AI aren't using different models or better prompts. They're providing better direction. Clearer scope. More precise requirements. Better guardrails.

Third: experience managing technical people is the most undervalued skill in AI adoption. Everyone's chasing prompt engineers and AI researchers. But the people who will get the most out of AI agents are the engineering managers, the technical leads, the people who've spent their careers turning vague requirements into focused execution. That skill is exactly what AI agents need.

When I built ComOS — 900,000 lines of code, 69 autonomous agents — I wasn't just writing prompts. I was managing a workforce. Setting scope. Reviewing output. Redirecting when they wandered. Catching over-engineering before it compounded. Applying fifty years of management instinct to a new kind of team.

That's why ComOS has the guardrails it does. Every agent runs with confidence thresholds, scope boundaries, and escalation protocols — not because the AI is unreliable, but because that's how you manage any capable worker. You give them clear parameters and review mechanisms. Human or artificial, the principle is the same. The Uncomfortable Truth

The training data gave AI agents our capabilities. It also gave them our tendencies.

They over-engineer because we over-engineer. They go down rabbit holes because we go down rabbit holes. They resist constraints because we resist constraints. They're convinced their approach is right because we were convinced our approach was right.

That's not a flaw in AI development. It's a mirror. And the reflection is more accurate than most of us want to admit.

The good news is that managing these tendencies is a solved problem. We've been doing it for decades in software engineering. Clear requirements. Defined scope. Regular review. Course correction. The tools are the same. The subjects are new.

The fifty years I spent managing programmers weren't a prelude to the AI era. They were training for it.