Engineering
The End of Engineering as the Mandatory Tollbooth
What years of building self-service systems taught me about product autonomy, software engineering, and the AI-native shift.
TLDR
I've spent much of my career trying to make product teams less dependent on software engineers. Before generative AI, I saw agencies struggling to maintain software, specialists working late, and engineering teams blocked by poor alignment. I learned that specialists can turn their expertise into self-service capabilities, allowing other teams to act without having to understand the systems underneath.
AI extends that principle across the organization. Platform teams make infrastructure capabilities available to engineers; engineers, in turn, create governed capabilities for product teams. AI offers a more flexible interface between those layers. In some cases, the path from idea to production can shrink from weeks to hours.
That's why I partly agree with talk of "the end of software engineers"—but only as the end of an organizational dependency, not of engineering expertise. AI is an interface, not a safety guarantee. Specialists still design the contracts, permissions, checks, and operating boundaries that make autonomy possible at each layer.
I’ve spent much of my career as a software engineer trying to make product teams less dependent on software engineers. Not because engineering doesn’t matter, but because I believe good engineering should make other teams more autonomous. For years, though, there was a hard limit to that idea: at some point, turning a new product intention into working software still meant going through someone who knew how to build it.
AI is starting to break that constraint at more than one handoff. Work that once required days or weeks of implementation and coordination can, in some cases, become an experiment in production within hours. Product people can increasingly move from an idea to something testable without waiting for an engineer to manually translate every part of that intention into code. Meanwhile, engineers themselves can consume infrastructure capabilities through agent-facing tools instead of learning the operational details of every service. That changes more than development speed. It changes how specialist knowledge can be distributed across an organization.
So when people say AI might mean “the end of software engineers,” I don’t dismiss it as easily as I once would have. I kind of agree. And strangely enough, I started arriving at that conclusion long before an AI agent could turn a product requirement into working code.
The Bottleneck I Saw Before Generative AI
Around 2014, I was working with agencies that needed websites and e-commerce projects but couldn’t realistically maintain dedicated engineering teams.
Software development wasn’t their core business. Qualified engineers were expensive, and even a reasonably scoped project could take a month to build. To an agency under pressure from its clients, that could feel painfully slow.
Then came the less glamorous problem: keeping the software alive.
After launch, something would break. A library needed updating. A dependency would grow old. A production issue could take days to address, especially when the person who knew the code was juggling other projects.
The problem wasn’t just the cost of building software. It was the ongoing dependency on specialized engineering work, even for problems that looked remarkably similar from one project to another.
And I kept coming back to the same question:
Why did every new project have to start from scratch, requiring the same specialized work all over again?
That question eventually led me to start a business.
I wanted to explore whether recurring engineering work could become reusable self-service capabilities: a technical foundation agencies could use through a simple interface, without needing to understand the systems underneath or call a developer for every change.
At the time, I wasn’t thinking about the future of software engineering as a profession. I was trying to solve a practical problem: how to make technology more accessible to people whose business wasn’t building technology.
Looking back, I can see the principle behind that decision much more clearly.
I wasn’t trying to make engineering disappear. I was trying to put its complexity behind an interface that gave others more autonomy.
I didn’t have a universal solution. But I had found a question that would follow me throughout my career:
What if the value of engineering wasn’t just in what engineers could build, but in what they could enable everyone else to do?
Seven Specialists and a Lot of Midnight Pizza
Years later, I encountered a different version of the same bottleneck while working on a legacy-heavy operation with aggressive time-to-market demands.
There was a lot of accumulated technical complexity, a small group of specialists, and far more requests than the existing delivery process could comfortably absorb.
We worked long hours. Late-night pizza in the office wasn’t a charming perk; it was a symptom of an operating model under pressure.
We gradually modernized parts of the system. But one of the changes I’m proudest of wasn’t about making developers type faster. It was about identifying changes that the product team could safely make without opening a development request.
We created a way to expose selected behaviors as configurable capabilities instead of bespoke coding tasks.
That relieved some of the pressure on engineering. Product could act sooner, and specialists had more room to focus on the work that actually required specialized knowledge.
The lesson was not that product no longer needed engineers. It was that engineering could make itself less necessary for recurring, well-understood operations.
And that was a good thing.
Three Teams, Sixteen Engineers, One Project—and Not Enough Pizza to Fix It
At another organization, I saw a different variation.
The friction wasn’t just about implementation time. Product and engineering were not sufficiently aligned on what mattered, why it mattered, and how to make trade-offs.
Adding capacity can help, but more headcount alone doesn’t resolve a broken flow of decisions. More people can just mean more coordination and more work in progress.
My response there was less about creating another self-service platform and more about changing how we worked. I wanted engineers to understand the problems product was solving, share ownership of outcomes, and make technical decisions with urgency and business value in mind.
That meant challenging large refactors that lacked a compelling reason, reducing the distance between the person identifying a problem and the person solving it, and treating product delivery as a shared responsibility.
In one company, the answer involved reusable software capabilities. In another, it involved organizational culture. But the question was remarkably consistent:
How can engineering remove friction between a product idea and the value it is supposed to create?
Self-service was already the direction
One principle I picked up while studying DevOps has stayed with me: specialists can turn their expertise into self-service capabilities, allowing other teams to work at a higher level without becoming specialists themselves.
Infrastructure teams already do this for software engineers. They define the foundations and operating protocols; developers consume those capabilities without having to master every detail of provisioning or deployment. In turn, engineers can make selected product capabilities available for configuration and experimentation without implementing every change by hand.
It’s not a perfect analogy, but I think of this as ports and adapters applied to an organization. Each specialist layer defines a contract that the next can use without understanding its internals.
Before capable AI agents, specialists usually had to anticipate each operation and build an interface or workflow for it. AI adds more flexibility: people can express an intention in natural language, and agents can work with existing capabilities rather than requiring a new interface for every variation.
That’s why AI feels to me like a new IDE or framework: a way to access specialized capabilities, not a replacement for the systems behind them. The opportunity runs from infrastructure to engineering, and from engineering to product.
A prompt is not a production authorization
Being able to express an intention in natural language doesn’t mean being authorized to execute it automatically.
Specialists still decide which capabilities can be delegated and under what conditions. Permissions, preconditions, validation, auditability, and human approval where the risks demand it must be enforced by the underlying systems, not assumed because an agent was instructed to behave.
Responsibility exists at every layer: infrastructure specialists govern the capabilities exposed to engineers; engineers govern those exposed to product teams. The interface may be conversational, but accountability remains with the people designing and operating those systems.
As agents execute a growing share of implementation work, the engineering challenge shifts from personally handling every request to designing systems that can turn classes of requests into working, verifiable changes.
That is not necessarily a smaller problem. It’s a different one. A generated implementation remains a proposal; tests, reviews, operational evidence, and appropriately placed human decisions determine whether it is ready.
What might actually disappear
I don’t have a reliable forecast for software-engineering employment, and I don’t think a single organizational model fits every industry, legacy system, or level of risk.
Some businesses will need more engineering capacity as they discover new things they can afford to build. Others may need fewer people performing the same types of repetitive implementation. Many will experience both dynamics in different parts of the organization.
What I suspect is becoming less sustainable is a particular organizational dependency: every meaningful product change must wait for an engineer to implement it by hand.
I’ve spent years trying to reduce that dependency with SaaS, no-code interfaces, self-service capabilities, and better alignment between product and engineering. AI now offers a chance to extend the same principle across layers: from infrastructure to engineering, and from engineering to product.
Writing code remains a valuable skill. But it may no longer be the primary way a software engineer creates value.
For me, the more important questions are becoming: Which problem is worth solving? Which capabilities should exist? What can we safely delegate? What evidence tells us a change is working? And what should remain under specialist control?
Technology exists to serve the product. At the same time, product must respect the technical constraints and responsibilities that make its promises sustainable.
The future of software engineering might not be about writing more software. It might be about building the systems that allow everyone else to create it safely.
Maybe the real disruption isn’t that AI can write code.
Maybe it’s that engineering no longer has to be the mandatory tollbooth between an idea and a working product.