The Expanding (Software) Engineer
What AI Actually Means for the People Who Build Software
Shaun Archer
6/19/20268 min read
The Expanding Engineer: What AI Actually Means for the People Who Build Software
Software engineering has a habit of doing this. Every time some capability becomes cheap enough to democratise, engineers don't get to do less — they get to do more. The perimeter of the job expands, expectations quietly shift, and the engineers who saw it coming look prescient. The ones who didn't tend to spend a few years feeling aggrieved about it.
We're in the middle of exactly that kind of shift right now. And it's bigger than the last few.
We've Been Here Before
Think back to how software teams worked in the early 2000s. Development and operations were separate jobs, separate teams, often separate buildings. Developers wrote code; operations ran it. The handoff was formal, the feedback loop was slow, and both sides largely preferred it that way. If something broke in production, that was ops' problem. If the deployment process was a nightmare, that was ops' fault. The wall between them was structural and, for a long time, considered sensible.
Then it wasn't. Cloud infrastructure matured, deployment pipelines became programmable, and a generation of engineers started arguing that if you built a thing, you should own what happens to it in the wild. The DevOps movement dismantled the wall. Not overnight, and not without resistance — "that's ops work" was a phrase you heard a lot, usually from people who shortly afterwards found themselves learning YAML and writing Terraform. The job expanded. The engineers who leaned into it thrived. The ones who held the line found the line moving without them.
Then came security. As systems sprawled across cloud providers and compliance requirements multiplied, the old model of a security team reviewing code before release became a bottleneck and, frankly, a fiction. DevSecOps pushed security left — into the development process itself, into the pipelines, into the way engineers thought about what they were building before they built it. Again, the job expanded. Again, the people who adapted early had an advantage that compounded.
There's a pattern here. Some domain that previously required a specialist — running infrastructure, securing systems — gets codified and tooled well enough that it folds into the generalist engineer's baseline expectations. The specialists don't vanish; they move to harder problems. But the floor rises for everyone else.
AI is the next expansion. Except this one doesn't just add another domain to the list. It goes at the core of what engineering is.
When Writing Code Stops Being the Bottleneck
For most of the industry's history, the constraint was implementation. Turning a vague requirement into working, tested, deployable software took time and skill. That gap — between having an idea and having a thing — was large enough to organise entire companies around. You needed product managers to translate customer problems into specifications precise enough for engineers to act on. You needed QA teams to catch the inevitable gaps between what was specified and what was built. You needed project managers to track progress across the weeks that all of this took.
AI collapses that gap. Not to nothing — not for complex systems, perhaps not ever entirely — but enough to change where the constraint sits. An engineer working with decent AI tooling today can prototype, test, and iterate at a pace that would have looked absurd five years ago. The question shifts from "can we build this" to "do we actually understand what we're building and why."
That's a meaningful inversion. The premium used to sit with people who could translate intent into implementation — who could hold a fuzzy requirement in one hand and produce working code in the other. That translation is increasingly automated. What remains irreplaceable is the intent itself: understanding the domain, the customer, the actual problem underneath the stated problem, and having the judgement to know when what you've built genuinely solves it.
The Vibe Coding Problem
Here's what makes this expansion different from the DevOps and DevSecOps shifts: it's not just happening inside engineering teams. It's happening to the people engineers work for, and the customers they build for.
Non-engineers are now building functional software. Not elegant software, not secure software, not software anyone would want to maintain — but working software, quickly. A product manager can produce a demo in an afternoon. A customer with a problem your product doesn't quite solve can prototype something themselves over a weekend. The term that's attached itself to this is "vibe coding": describe what you want in natural language, iterate until it mostly does the thing, ship it.
This changes the comparison class for delivery speed. Your customers are no longer benchmarking you against other engineering teams or other software companies. They're benchmarking you against their own ability to hack something together. When someone can go from idea to working prototype in a day, a three-week sprint requires explanation.
The feedback loop expectation is collapsing, and it's going to keep collapsing. This is uncomfortable, but it's also clarifying. The distance between a vibe-coded prototype and something with real reliability, proper security, and the kind of maintainability that doesn't cause a crisis eighteen months later is enormous. The engineer's job is to deliver that difference — quickly enough that the gap is obviously worth it.
Domain Expertise Is the Thing That Doesn't Automate
If execution is getting cheaper, understanding becomes the scarce resource. And here's the thing about domain expertise: it has always been what separated the engineers who were genuinely valuable from the ones who were merely competent.
The engineer at a fintech company who actually understands settlement and reconciliation can spot a requirements gap before it becomes a production incident. The engineer at a healthcare company who understands clinical workflows makes API decisions that fit how practitioners actually work, rather than how a product spec imagined they work. This kind of embedded knowledge has always been valuable. In an AI-enabled environment it becomes essential, because the part of the job it enables — rapid, accurate iteration on real problems — is exactly what's now possible if you have enough context to move quickly without making expensive mistakes.
The mechanism is the feedback loop. When implementation is slow, you want requirements to be thoroughly specified before work begins, because the cost of discovering a misunderstanding late is high. When implementation is fast, the bottleneck moves to requirements clarity — and the engineer who knows the domain well enough to work from a rough brief, or to push back intelligently when a brief doesn't make sense, is worth considerably more than one who needs a detailed specification before they can start.
This is the product management expansion. Just as DevOps brought operations into engineering's remit and DevSecOps brought security, the AI era will bring product thinking more deeply into what engineers are expected to carry. Not to replace product managers — roadmap strategy, stakeholder alignment, and commercial trade-offs will remain specialist work — but to raise the baseline. Engineers who understand why they're building what they're building, and for whom, will operate faster and make better decisions than those who don't.
Talk to the Customers
The practical implication of all this is that engineers should expect to interface more directly with customers, and they should probably start before they're asked to.
Engineering culture has historically kept a healthy distance between builders and users. Requirements arrive filtered through product management and design. Feedback arrives as tickets, analytics, or the occasional escalation. The direct signal from the person with the actual problem has been mediated to the point where it's often unrecognisable by the time it reaches the team building the solution. This made sense when engineering capacity was the scarce resource and every customer conversation represented a potential context switch that needed to be managed carefully.
But when the cost of responding to feedback drops dramatically, the economics change. Unfiltered customer signal becomes much more valuable, because you can actually act on it before the context expires. Engineers who talk to customers regularly develop a different mental model of their product — one built from real usage patterns and genuine frustrations rather than aggregated metrics. That model shows up in better prioritisation decisions, more accurate estimates, and — not incidentally — better software.
There's an external visibility angle here too. Engineers who write about their domain, speak at relevant events, or engage seriously with the conversations happening in their field attract better signal. Interesting problems find people who demonstrably understand the space. Some of the best feedback any team ever gets arrives unsolicited, from people who recognised someone worth talking to.
Organising Your Own Work
The other thing AI changes is the value of good prioritisation. When you can build faster, the cost of building the wrong thing goes up proportionally. Spending a sprint on something that doesn't matter is more expensive when a sprint's output is twice what it used to be.
Engineers who can think clearly about what's worth doing — who have enough product and customer context to prioritise without constant direction — will be able to operate with more autonomy. This requires skills that engineering culture has tended to treat as secondary: writing clearly, communicating decisions and their rationale, understanding the commercial context of technical choices well enough to explain them to people who don't share your technical vocabulary. These aren't soft skills in the dismissive sense. They're the capabilities that let you operate independently, reduce how much coordination overhead your work generates, and expand the scope of what you can actually get done.
Learning AI as a Craft
One more thing, and it's worth being direct about it: the gap between an engineer who uses AI tools well and one who uses them badly is already significant, and it will grow.
This isn't about volume of usage. It's about the same kind of judgement that distinguishes a good engineer from a mediocre one in any tool context. Earlier generations had to learn to type quickly, navigate IDEs efficiently, write shell scripts, use version control with real fluency. Each of these felt like overhead and then became invisible infrastructure. AI tooling is the next layer of that.
The engineers who will get the most from it are those who understand its failure modes — where it confabulates convincingly, where it produces code that looks right and isn't, where it's overconfident about its own suggestions. They know how to give it sufficient context, how to decompose a problem so that AI can contribute to part of it while they retain judgement over the parts that actually matter, and how to review AI-generated work with the same critical eye they'd bring to a colleague's pull request. They treat prompting as a skill worth developing rather than something you're either naturally good at or you're not.
The Line Is Moving
The through-line across all of this is the same as it was in the DevOps and DevSecOps eras. The job isn't fixed, the expectations aren't fixed, and the engineers who treat them as fixed tend to have a difficult time of it eventually.
The expanding engineer learns the product domain they work in — not superficially, but well enough to have genuine opinions about it. They talk to customers regularly enough to hold a real model of their problems. They organise their own work with enough clarity to operate without constant direction, and communicate well enough that stakeholders trust them to do so. They build some external presence, because external presence attracts better signal. And they invest in AI tooling as a craft, the same way they once invested in learning to code well.
None of this is mysterious. It's just the job, expanding again — as it always has, as it always will.
The question is whether you're ahead of the expansion or behind it.