Writing By Barry

The fate of the human engineer.Copy link

The role was never static. AI just made the rate of change impossible to ignore.

I've been a software engineer for thirty years and I'm not sure the job I do today would be recognisable to the version of me that started.

Not because of AI. That's the recent bit. Because the role has been steadily absorbing more scope for as long as I've been in it, and nobody talks about it honestly. We just keep updating the job spec and pretending the title still covers it.

The role was never one thingCopy link

When I started, "software engineer" / "developer" meant you wrote code. You knew a language, maybe two. You understood databases, probably one specific vendor's flavour. You built things. That was the gig.

Then it got wider. You needed to know the network layer. Then the deployment pipeline. Then the cloud infrastructure. Then the monitoring, the observability, the incident response. Then someone decided engineers should own the product thinking too, so add requirements gathering, stakeholder management, and user research to the pile. Then testing, because QA got expensive and besides, "shift left" was trending. Then compliance, because regulation caught up with the industry and someone had to understand both the code and the rules.

Each addition arrived gradually enough that nobody stopped to ask whether one human could credibly hold all of it. The answer, for the record, is no. But we kept going.

What AI actually changedCopy link

The doom framing says AI replaces engineers. The sunshine framing says AI just makes engineers faster. Both miss what's actually happening.

What I've watched over the last two years, in my own work and across the teams I work with, is something more specific. AI collapsed the cost of the mechanical parts of the job. Writing code, generating tests, producing documentation, scaffolding infrastructure. The bits that used to consume seventy or eighty percent of a working week. Those got fast. Absurdly fast. What used to take a week takes an afternoon.

But collapsing the cost of the mechanical work didn't simplify the role. It inverted it.

My day now looks nothing like it did three years ago. I plan. I verify. I think about architecture and trade-offs and what happens when this thing hits production at scale. I review AI-generated output with the same eye I used to review junior developers' pull requests, except the volume is ten times higher and the failure modes are different. I test. I discuss requirements with the PO and other stakeholders and make sure the intent survives the translation into something a machine can build. I worry about compliance and data governance, because those problems didn't go away when the coding got cheaper.

The coding? Delegated. To carefully monitored agents now. I still read code sometimes. I don't write it anymore.

Same job. Different work. A two row stacked bar comparison of how the software engineer's working week is composed, then versus now. Both bars are the same length, representing the same labour budget. Top row, labelled three years ago, is dominated by one signal coloured band labelled Coding, which fills roughly seventy percent of the row. Thin neutral slivers either side carry the labels Requirements, Architecture, Verification, Testing, Compliance and Operations. Bottom row, labelled now, after AI arrives, shows the Coding band shrunk to a sliver of roughly eight percent. The judgement bands have all swelled to fill the envelope: Requirements eighteen percent, Architecture sixteen percent, Verification twenty percent, Testing fourteen percent, Compliance twelve percent, Operations twelve percent. The composition has inverted. A short footer states the load bearing point: coding shrank, engineering grew. Requirements work, three years ago. A thin sliver of the week, owned mostly by product, glanced at by the engineer. Architecture, three years ago. A small slice of the week, often handed down or deferred to a senior. Coding, three years ago. Roughly seventy percent of the working week. The bulk of what the role was paid for. Coding 70% Verification, three years ago. A thin band. The reviewer signed off on pull requests; nobody read every line. Testing, three years ago. A small band. Mostly owned by a separate QA function or written alongside the code. Testing 8% Compliance, three years ago. A thin band. Often handled by a separate function and revisited at audit time. Operations, three years ago. A thin band. Run a deploy, watch the dashboard, hand the pager to someone on rota. Requirements work, now. Eighteen percent of the week. The engineer holds the conversation with the product owner and writes the brief the agent will build from. Requirements 18% Architecture, now. Sixteen percent of the week. Trade-offs, system shape, failure modes. The work that decides whether the build will survive contact with production. Architecture 16% Coding, now. Eight percent of the week. The agent writes it; the engineer reads it back to make sure it does what the brief said. Coding 8% Verification, now. Twenty percent of the week and growing. Reading agent output with the same eye a senior reviewer used to bring to a pull request, at ten times the volume. Verification 20% Testing, now. Fourteen percent of the week. Test strategy and edge cases the agent did not consider. The bits statistical pattern matching does not catch. Testing 14% Compliance, now. Twelve percent of the week. Regulation, data governance, the rules the build has to satisfy. Owned by the engineer because nobody else reads both the code and the rules. Compliance 12% Operations, now. Twelve percent of the week. What happens when this thing hits production at scale and breaks at three in the morning. Ops 12%
same envelope · the fill inverted · the role grew up

The scope kept growing. The headcount didn't.Copy link

Here's the bit that should worry people. The role was already overstretched before AI arrived. One person expected to be architect, developer, tester, DevOps engineer, product thinker, and compliance-aware. AI made the coding part faster, which sounds like relief until you realise what actually happened. Organisations saw the speed-up and concluded they could do the same work with fewer engineers. Or the same number of engineers with twice the output.

Neither framing accounts for the fact that the hard parts of software engineering were never the typing. They were the thinking, the judgement calls, the requirements work, the "what happens when this breaks at 3am" planning. AI hasn't touched those. If anything, it's made them more critical, because AI-generated code carries decisions you never made. Edge cases handled by statistical pattern-matching rather than deliberate choice. Security assumptions inherited from training data. Schema designs that look plausible and are wrong in ways that don't announce themselves.

Somebody still has to catch that. Somebody with enough technical depth to read the output, enough product knowledge to know whether it solves the right problem, and enough operational awareness to know whether it'll survive contact with production.

That somebody is not a pure coder. That role is shrinking.

What I actually see comingCopy link

I work in London in investment finance. And what I see happening around me is a slow, messy convergence.

The people who thrive are the ones who can hold the full stack of concerns. Not the full tech stack. The full problem stack. Requirements. Architecture. Build oversight. Test strategy. Compliance. Deployment. Support. They don't write every line of code. They might not write any. But they understand the system well enough to direct AI agents, verify their output, and own the result.

The job title that fits this isn't "software engineer" any more. I use "Operating Engineer" myself, but it only captures where I am right now, not where this is heading. Right now the operator has to be an engineer, because nobody else can read the output well enough to verify it. The future is probably a blend of product owner and technical architect, once we figure out how to separate the product direction work from the build oversight work without losing the thread between them. We haven't figured that out yet.

What I'm fairly sure of is this. The pure-coding role, the one where your value is your ability to write clean code in a specific language, is on a declining curve. Not vanishing overnight. There will be specialist work for years. But the centre of gravity is shifting toward people who can manage the whole lifecycle, with AI doing the heavy lifting on the bits that used to be the job.

Both sides are wrongCopy link

The "AI will replace all engineers" crowd is wrong because the judgement work isn't going anywhere. Someone has to own the outcome and that someone needs to understand the technology, not just manage it from a Gantt chart.

The "everything is fine, AI is just a tool" crowd is wrong because the role is already unrecognisable compared to five years ago and the rate of change is accelerating. Pretending the job is the same but faster is a comfortable lie.

The reality is messier than either camp admits. Roles are mutating. Scope is compressing onto fewer people. The value is migrating from "can you build this" to "can you define what to build, verify it was built correctly, and own what happens next." Process. Blueprints. Managed implementation. The engineering, as I keep saying, as distinct from the coding.

Where this leaves usCopy link

I don't have a clean prediction. Anyone who does is selling something. But the pattern I see forming, the one I'm building my own practice around, is this: small teams of technically deep people who operate AI rather than compete with it. Who spend their time on the parts that actually determine whether software works in the real world. Requirements that are honest. Architecture that accounts for failure. Test strategies that catch the things AI doesn't know it got wrong. Compliance baked in rather than bolted on.

The engineering was always the hard part. We just used to bury it under the coding. Now the coding is cheap, and the engineering is all that's left.

That's the fate of the human engineer. Not redundancy. Promotion. To the job we should have been doing all along.

Blurted out by Barry, refined by Dave.