The Three Types of Software Engineers in the Face of AI Agents

There’s a conversation happening right now, and depending on which room you’re in, it sounds completely different.

In one room, engineers are running twelve agents in parallel and complaining about their laptop running out of memory. In another, engineers are insisting that every line of a PR be read by a human or it doesn’t ship. On Hacker News, the comment section under any AI coding post feels like a war zone of opinions (yeah, even more than usual). At my company, we have an AI council where some version of this argument plays out every other week. My friends who are staff engineers at big-name companies are seeing it too.

It’s not really one argument, it’s three. Three groups of engineers who have reached three different relationships with AI tools, and who mostly cannot understand each other. I want to describe them, because I think naming them makes the conversation easier. And because I think one of the three is going to be in a much harder spot than they realize, soon.

The Agent Maximalist

There’s a usage dashboard at my company. Cursor publishes it: a leaderboard of who’s burning the most tokens. It’s a flawed metric, the same way lines-of-code was a flawed metric in 2015. Easy to game, doesn’t capture quality, etc. But it’s a signal, and the discourse around it is getting loud. Jensen Huang recently said he’d be “deeply alarmed” if a $500K engineer at Nvidia wasn’t burning $250K in tokens annually. Take that with the appropriate grain of salt (Nvidia sells the picks and shovels) but the directional point lands. And there’s one guy at my company who lives at the top of the leaderboard.

I remember when he first found Cursor, maybe a year and a half ago. Nobody else at the company was using it yet. He pulled someone aside to demo it. Look, you just tell it what you want, and it goes and does it. Reactions varied. A few people were genuinely impressed. Most were somewhere between skeptical and dismissive. He kept using it anyway.

His setup isn’t exotic. Cursor, cloud agents, sometimes local. Same as everyone else who’s gone deep. Some people use Claude Code, some Codex, it all converges. What’s different is his todo-list. He doesn’t say no to things anymore. He just adds them. Spin up a dev environment for the new product? In the old world, that’s two weeks of work, you scope it, you slot it for next quarter. In his world, it’s a line on the list. It’ll be done as soon as he can manually verify the result.

The output is real and the code mostly works. He ships more than anyone else on the team. But honestly, it puts strain on the rest of us. Reviewing what he produces is its own job now.

For example, we had a new hire recently: An “eager beaver”, agent-native from day one. End of his first week he opened a PR: a 200-file change. I had no idea what he was actually doing in there, and I didn’t have time to read 200 files, and I hadn’t worked with him long enough to just trust that it was fine. So the PR sat. The thing that took him a few hours to produce would have taken me days to review properly, and I didn’t have days. It created more work than it solved.

That’s the maximalist’s externality. The output is real but the cost of verifying it gets pushed onto everyone else, and it gets worse the less trust the maximalist has banked with the team. A senior engineer firehose-ing 200-file PRs is bad. A new hire firehose-ing 200-file PRs is unreviewable.

The unspoken question hanging over the maximalist isn’t can you ship this much? It’s what do you build around yourself so the rest of us can trust the output without drowning in PRs? Integration tests, CI that actually catches things, smaller PRs, better PR descriptions that explain not just what changed but why, tests written alongside the change that would credibly fail if the change were wrong. Infrastructure that earns trust on the maximalist’s behalf, because he’s moving too fast for trust to be earned the old way, by another human reading every line.

The Tab Completer

A year ago, this was me.

I started using Copilot the week it came out. I loved it. Writing a comment that described what a function should do and watching the function appear under my cursor felt like cheating, in a good way. My words-per-minute went up 2-3x. I was still writing the code, in the sense that I was reading every line as it appeared and approving it in my head before moving on. The AI was a faster keyboard and I was still the engineer.

When agents came along, I bounced off them. I’d ask for something small and they’d go off and write code I hadn’t asked for, touch files I hadn’t pointed at, make decisions I hadn’t made. It felt sloppy and out-of-control. So I stayed where I was, Tab, Tab, Tab, and told myself the agent thing wasn’t ready yet.

What I didn’t see at the time is that I was describing the experience of every engineering manager who has ever existed. You ask an engineer to do a thing. They go do the thing, plus four other things, because they thought those four things were implied, or because they had a strong opinion about the product, or because they noticed something broken on the way. Sometimes that’s great. Sometimes it’s a mess. Either way, you don’t get to be in the driver’s seat anymore. You get to set direction and review the work.

The gap between Tab Completer and Maximalist isn’t really about the tools. It’s about whether you’re willing to stop being the person who writes the code. Tab complete keeps you an IC with a faster keyboard. Agents ask you to become a manager. That’s the uncomfortable step, and a lot of good engineers (me, a year ago) refuse to take it because being an IC is what they like about the job in the first place.

The Skeptic

Every team has one. Often more than one. Usually they’re senior, often they’re the best engineer in the room by traditional measures, and they are not going to use agents.

Their position is principled, or at least it sounds principled. Every line of code in a PR has to be human-reviewed. If an agent wrote it, that’s not enough. A human has to have read it, thought about it, taken responsibility for it. Otherwise we’re shipping code nobody understands.

I’ve pushed on this. Okay, but when a teammate writes code and another teammate reviews it, how do you know it’s correct? The answer, when you keep asking, comes down to trust. You trust the human. You’ve worked with them. They’ve earned it.

Which is fair. But it also means the objection isn’t really about agents producing bad code. It’s about agents not having a track record yet. New hires don’t have a track record either, and we let them write code. The trust gets built over time, through the same mechanisms that build trust in any engineer: tests that catch regressions, benchmarks that catch drift, code that holds up in production. There’s nothing magical humans are doing in code review that an integration test can’t do better and faster.

The Skeptic’s other move is harder to argue with: the code agents produce isn’t as good as the code I produce. And honestly, often that’s true. The senior engineer with twenty years of experience writes cleaner, more thoughtful, better-factored code than an agent does on a first pass, and often even after several iterations. They’re not wrong about the quality gap. But that gap is shrinking, and I would bet it will soon invert.

That being said, businesses don’t really optimize for best, they optimize for good enough, shipped. You can spend eighteen months building the most beautiful version of a feature, and in eighteen months the market may not need it anymore. Speed plus good-enough beats craftsmanship plus late, almost every time, in almost every business that isn’t safety-critical. The Skeptic is solving the wrong problem with the right tools.

The shift

The thread running through all three types is the same. The Maximalist has accepted it. The Tab Completer (me, a year ago) was halfway there. The Skeptic is refusing.

The shift is from individual contributor to manager of agents.

I wrote about this recently from the system side: the point where AI stops being a tool you direct and starts being the thing that directs you. This post is the human side of the same shift. Three different reactions to the same thing happening underneath all of us.

If you’re an IC engineer right now, the question isn’t whether the agents are good enough yet. The question is whether you’re willing to stop being the person who writes the code and start being the person who sets direction, reviews output, and builds the systems that make that output trustworthy. Because the tools we use to gain confidence in agent-produced code are mostly the same ones we already use to gain confidence in human-produced code: tests, benchmarks, integration coverage, code that holds up in production over time, and a track record. The Skeptic insists on human review because humans have a track record and agents don’t yet. But the track record isn’t really the point. The infrastructure that generates the track record is the point, and it works the same either way.

A friend of mine works at a health tech company. The engineering team had been pushing back on a feature for months: too hard, too risky, too much work, slot it for next quarter. One of the cofounders, who has no technical background, opened Replit and built it in a day. Then he showed it to the team and said let’s ship this.

The engineers had real objections. It wouldn’t fit the existing system, there were security holes, scaling concerns, the usual list. All of that was probably true: there’s a real difference between a working demo and a production system, and engineers have hard-won insights that non-engineers don’t. But the cofounder had also just done, in an afternoon, the thing the team had been saying was too hard. And once that happens, you can’t un-happen it. He doesn’t fully trust his engineers anymore. He’s started asking why he needs them at all.

That’s the future the Skeptic is walking into. Not one where agents replace engineers, but one where the people paying engineers stop believing the old estimates, the old scoping, the old reasons something can’t be done this quarter. Engineers have had enormous leverage for twenty years because writing software was hard and expensive and only some people could do it. That leverage is getting repriced right now, and the engineers who are going to keep it are the ones who stop competing with agents on writing code and start competing on the thing agents still can’t really do, which is judgment. What’s worth building. What’s safe to ship. How to build the systems that make the whole machine trustworthy.

The Maximalist already figured this out. The Tab Completer is figuring it out now. The Skeptic still has time to, but probably less than they think.