You are still valuable

A colleague recently shared a Reddit post with our team. A developer wrote about how their company had turned them into a supervisor for AI agents. No more writing code, only reviewing what the machine spits out, all day long. The comments were full of people feeling the same way. One of them summed it up: "You're just a condom between Claude and your production server getting fucked." Another one said that most of them feel like a background character in a sci-fi dystopia.

Overview

The exact opposite of diminished

I had one or two moments this year where I genuinely thought: "Whoa, this is an order of magnitude more capable than it used to be." But I never felt like AI is diminishing my own value as an engineer. If anything, it's the opposite.

The amount of output I'm able to generate in a given week is absolutely mental compared to two years ago. In a normal week I'm working on around ten tickets at my day job. In the evenings I'm prompting agents to work on my wife's website or to implement services on my home infrastructure. They work on those things overnight and I review the results the next morning on the go. I have voice conversations with an LLM to understand concepts or think through problems wherever I happen to be.

The header image is from a repository I worked on recently. I did not write most of the code in those pull requests. I do decide what goes in.

This can be mentally draining. There are a lot of context switches and more and more of my time is concentrated on the two cognitively expensive parts of the job: concept work and reviews. But I think that is mostly the skill set shifting. We're moving up the abstraction layer. We spend more time thinking about business requirements, application behaviour, architecture, trade-offs and whether the thing we're building actually makes sense.

The models are ahead of our processes

A lot of the way we work today was designed around the assumption that humans implement features by writing the code themselves. Two-week sprints, estimating individual tickets, manually reviewing every changed file in a pull request. These processes evolved over decades around that constraint.

Honestly, I don't think two-week sprints make much sense anymore when I'm working on four tickets in parallel. The more relevant question becomes: how much throughput can I achieve at a given level of quality? Two or three day cycles might make a lot more sense. We just haven't figured out how to do that in teams and larger organisations yet.

The same applies to code review. I don't think I need to review pull requests the way I used to. Probably half of the changed files in a typical PR are extremely low risk. Boilerplate, mechanical changes, mapping code, translation files, supporting work that had to happen around the core of a feature. Treating every line and every file as equally deserving of human attention doesn't scale when the volume of generated code goes up by an order of magnitude. The interesting question is where human attention actually has the highest value.

What I actually review

This is what my review has shifted towards. A colleague of mine put together a very similar list in that same thread, and I agree with all of it, so this is a mix of both.

• The business logic layer. This is where the real risk lives and I read it properly.
• Database changes, migrations, policies and anything touching permissions or security.
• The tests, and whether they have decent coverage. If a unit test is overly detailed, I don't care, they are cheap. If an end-to-end test is overly detailed, I do care.
• The end-to-end specs themselves. I want to know what we're actually validating.
• CSS tokens and theming. I want that simple and controllable.
• The running app. I click through it, figure out what could be better, think about the feature. This is where a lot of my review time goes now.

And what I mostly skip:

• Generated code, DTOs, request objects, mapping extensions, controllers and command classes that follow our architecture pattern.
• UI components. I look at them rendered instead of reading the markup. They have unit tests anyway.
• Translation files.

The reasoning: there is no harm in those files that couldn't be fixed within an hour, and the end-to-end suite covers the important use cases. In months of working like this I haven't had a single instance where the agent wired things against our architecture, like putting real logic into a controller.

Boilerplate used to be expensive, so we optimised for less of it. Now it's cheap. Give me six layers, I'll pay attention to the one with the business logic and let the agent one-shot 30 tests for the controller.

One fair pushback came from a colleague who thinks a lot about security: if an agent's context gets compromised, a generated/ folder is exactly where you'd hide something nasty. That's true. The skip list is not a free pass, it's a risk decision. Pair it with a strict end-to-end suite, dependency scanning and a good look at anything that touches the network or the file system. Smaller, step-wise PRs with a commit per plan step help here too. Chunking and narrowing what you read are not in conflict.

Did you check the diff?

If the output meets my quality bar, if I stand behind it and if I am accountable for everything in it, how important is it that I read every single word? At which point do I trust the tooling enough to accept the output as mine?

That is exactly for any type of work. Nobody would argue that I should retype a message an assistant cleaned up for me. But we still argue that we have to read every line of a mapping extension. The answer in both cases is the same: it depends on the risk, and deciding that is the job.

Critical thinking doesn't disappear, it moves

Another colleague raised a fear I think is justified: that we hand over too much critical thinking over time. You can automate a lot of what was considered valuable work until recently, feel good about it and think it's enough. Expectations haven't caught up with what is possible yet, so it's easy to rest on that. If you don't set yourself a higher bar, you end up exactly where the Reddit poster is.

He also pointed out something about ways of working. Some people can hold many things at once and dive deep into a new topic quickly and repeatedly. Others need time to think their way into a problem, go really deep and handle interruptions badly. The second group has a much harder time with a multi-agent workflow, and that's not a character flaw. Not everyone will switch modes the same way or at the same pace. Someone who spends a lot of time thinking about how to use these tools well can still struggle to let go of the involvement in the code. Both things are true at once.

My take is that critical thinking mostly shifts levels. If you spend your thinking on abstractions, trade-offs and architecture instead of on loops and null checks, you're still exercising judgment. You're just doing it with more leverage. The one thing that stays hard is the same as before: use your brain.

Judgment is the product

I've been helping my wife use Claude for her website and it works surprisingly well for her. But even relatively simple diffs are difficult for her to judge. She can't tell whether what the AI did is sensible, whether something is unnecessarily complicated or whether there is a subtle problem hiding in there.

I can glance at the same diff, understand what it's doing, steer the agent in a different direction or approve it.

That ability is going to become more important, not less. Knowing what needs a thorough review and what doesn't. What needs changing and what is good enough. When to say no. Where to deliberately cut corners. Where the risk actually is. Where another hour of polishing adds nothing.

No matter how good the agent harnesses become, some skilled humans will still need to exercise that judgment. AI can't be held accountable. We can.

The Reddit post is a management failure

Reading the original post again, the frustration is real, but the diagnosis is off. What the poster describes is not "how AI-assisted engineering works now". It's a company that enforced a technology on its people without useful structures around it and without listening to the senior engineers who use it every day. Every one of those seniors would have told them that reviewing an endless stream of unstructured agent output is nonsense.

The companies that are actually successful with this run very different policies. They invest in tooling, guardrails, test suites and review culture. They let the people closest to the work shape how the work is done. Enforcing agents top-down and calling the humans "reviewers" is not adoption, it's abdication.

There is also a missed opportunity on the employee side: stand up for yourself and exercise your own judgment. Say the process is broken. Propose how it should work. That is exactly the value you bring.

We've been here before

I keep thinking about our parents' generation. They ran offices on paper and fax machines and then the computer showed up. Then the internet. I'm fairly sure they had similar reservations and fears. Some of them adapted and got a lot out of it, some spent years being annoyed at the new thing.

Now we have a major technology shift in the middle of our own careers and we get to figure out what it means for us. It's not comfortable. It also doesn't make us less valuable.

And even if AI eventually does 90% of what we currently consider "our job", that doesn't mean there is only 10% of the work left. It means we can be a lot more ambitious about what we achieve as engineers, as teams and as individuals.

The only part I'm really sad about is the coding flow state. A colleague of mine isn't, because he finally has time for the test coverage, monitoring and observability he was always too busy for. Maybe he has a point.

Cheers,
Flo