The operations manager who didn't need engineers
In 1994, an operations manager at a mid-sized company could build an entire procurement tracking system over a weekend. Microsoft Access open on one screen. Excel macros on the other. Purchase orders, supplier follow-ups, delivery tracking. Done.
No engineering team. No Jira ticket. No sprint planning. No architecture board. He built the thing the business needed and started using it on Monday.
That wasn't unusual. It was normal.
Back then, business users still owned more technology than people remember. A logistics coordinator could build a database that ran the department. A sales leader could automate pipeline tracking in Excel. An HR admin could put together a leave-management workflow in Lotus Notes before lunch.
No one called it digital transformation. Technology was just part of the job.
No gatekeepers. No handoffs. No six-week wait for the next sprint.
My brother was an engineer in France during that period. He had stretches of unemployment. The early 90s recession hit hard. Software engineering was not yet the protected, high-status profession it later became. It was a useful skill. Not an institution.
Business people didn't need engineers for a lot of the systems they wanted to build.
That world feels strange now. But it wasn't that long ago.
Then the internet turned software into a profession
I started my career in 2000, right at the inflection point. The internet had arrived. Suddenly the market wanted software engineers at a scale it had never needed before.
Computer Science stopped being niche. Salaries jumped. Career ladders appeared. Conferences, hiring funnels, titles, professional identity. "I'm a software engineer" started to carry the same social weight as being a doctor or a lawyer.
And to be fair, the profession earned its place.
Building for the internet was not the same thing as building a VBA macro in a back office. Distributed systems, databases at scale, security, networks, reliability. The complexity was real. The business user with Access was not going to build Amazon.
So specialization made sense. At first.
But something else happened along the way. Technology stopped being something the business wielded and became something the business requested.
The ticket queue was born. Then the requirements document. Then the handoff. Then the governance layer around the handoff. Then the governance layer around the governance layer.
We didn't just professionalize software. We pushed it away from the business.
We built a taller and taller stack
Every wave added another layer.
- Product wrote the requirement.
- Architecture interpreted it.
- Engineering designed it.
- QA validated it.
- Operations released it.
- Offshore teams scaled it.
- Program management reported on all of it.
Each layer had a reason to exist. That's what made the model so durable.
But every added layer increased the distance between the person who understood the business problem and the people actually implementing the solution.
That distance became so normal that whole companies stopped noticing it.
Offshoring industrialized the distance
The 2000s added another force multiplier. Cost arbitrage went global. India. Eastern Europe. The Philippines. Engineering became a supply chain.
I lived through that model from the inside. It made sense in context. It more or less worked on cost. But it also made the stack taller.
Offshoring solved cost. It never solved distance.
It added more translation, more process, and more delay between the business problem and the people building the solution.
Define upstream. Hand off. Wait. Inspect. Rework. Escalate. Repeat.
And once you build a system around handoffs, you start optimizing for handoffs: more documents, more checkpoints, more status calls, more layers.
That was another hidden tax.
Now agents are collapsing the stack back upward
This is why agentic software matters so much. Not only because it writes code faster. Not only because it drafts emails. Not only because demos look clever.
It matters because agents compress the distance between intent and execution.
A business user, or anyone close to the business problem, can now express the outcome in plain language, keep the context attached to it, and push work through systems that used to require several specialist layers before anything happened.
That changes the shape of the company.
The old model was built on scarcity. Scarce engineers. Scarce testers. Scarce integrators. Scarce release people. Scarce delivery managers coordinating all of them.
The organization mirrored that scarcity, so we built long chains and called it governance.
Agents change the economics of that chain.
They reduce the cost of translation. They reduce the penalty for iteration. They reduce the need to shuttle a problem across six desks before the first useful version exists.
The real shift-left is not about testing earlier. It's about moving execution power back toward the people who understand the work.
That's the part most people haven't absorbed yet.
What moves back to the business
Not everything. Engineering is not disappearing. Security is not disappearing. Data is not disappearing. Offshoring is not disappearing either.
But the center of gravity is moving.
The business side gets more leverage again because the system can absorb intent faster and with less friction. The people closest to the customer, the workflow, and the P&L can shape more of the solution without waiting for the full machinery of the old stack to start grinding.
The practical consequences are obvious:
- faster path from idea to working system
- fewer handoffs between request and delivery
- more direct ownership of workflow by the people who understand the outcome
- less dependence on coordination layers for relatively small changes
This is not some abstract future-state slide. It's what happens when the cost of expressing, checking, and executing intent drops hard enough.
This is why the 90s comparison matters
When I say agents are sending us back to the 90s, I don't mean we are going back to Access databases and Excel macros. We are not.
The systems are far more powerful now. The stakes are higher. The infrastructure is infinitely more complex.
What is coming back is something else. Business proximity.
In the 90s, the person who owned the problem was often much closer to the system solving it. Over the last thirty years, we inserted a professional stack between those two points. In many cases that stack was necessary. In plenty of cases it became bloated.
Agents don't erase the need for expertise. They reduce the amount of translation required before expertise can act.
That's why the movement feels like a return, even though technically it's a leap forward.
Full circle. One level up.
What breaks first in the old model
The first thing to break is not engineering capability. It is the justification for all the intermediate layers.
If an agent can produce a useful first pass in minutes, why does a small workflow change need three meetings and a ticket queue.
If the business side can shape a solution directly with guardrails, why does every low-risk improvement have to travel through the whole machine.
If engineering can focus on the hard parts while agents absorb more of the translation and boilerplate, why is the organization still staffed as if every unit of progress requires a human relay race.
Those questions are uncomfortable because they are structural questions, not tooling questions.
And structural questions threaten structures.
The winners will be the companies that shorten the loop
A lot of leaders will respond to this shift the wrong way. They will keep the old operating model and drop agents into it like a productivity plugin.
That helps a bit. It does not change the game.
The real winners will be the organizations that redesign the loop itself.
They will let business operators stay closer to execution. They will use engineering talent where it actually creates leverage. They will strip out avoidable handoffs. They will stop confusing process density with control.
The agentic advantage is not just cheaper execution. It is shorter distance between problem and solution.
And once a company learns to operate that way, going back feels absurd.
The Agentic-Native Company
The agentic-native company does not treat technology as a priesthood isolated from the business. It treats technology as part of how the business thinks, decides, and executes.
That doesn't mean everybody becomes an engineer. It means the people who own the problem regain much more influence over the system that solves it. Agents compress translation. Engineers focus on enabling and optimizing this business-first technology operating model. The stack gets shorter, faster, and more accountable.
That's the pattern Agentic Native keeps documenting. Not nostalgia for the 90s. A return to business proximity, rebuilt with much more powerful systems. Full circle. One level up.
