Part one of three in a series that starts with AI Native Is Not a Tool Decision.
Somebody in Sales Wants to Deploy Something
Start with a scene that has nothing to do with engineering.
Someone on your sales team wants an automation. Something that screens a list of prospects before anyone picks up the phone, so the calls that do get made are worth making. It is not a complicated idea. It is the kind of idea a good salesperson has roughly every week.
In the old world, what happens next is well understood by everyone involved. They write it up. It goes to a product team. It gets weighed against the roadmap, lands somewhere in the middle, and turns up in four months or, far more often, never. Nobody behaves badly in this story. The engineering capacity is genuinely spoken for, and screening prospects is genuinely less important than the things it would displace.
In the new world, that salesperson can probably just build it. Sitting with an agent for an afternoon gets them most of the way there, and I have watched it happen often enough to stop being surprised.
The word doing the work in that sentence is probably. Building the thing is no longer the hard part. The hard part is that it now has to run somewhere, on a schedule, touching real customer data, without anyone noticing three weeks later that it quietly stopped, or that it was never quite as private as everyone assumed.
Which is a platform question. It is the same platform question engineering has been answering for fifteen years, asked by somebody who has never heard it before.
For context, I work at AutoUncle, a Danish company of sixty-one people selling software to car dealerships. Fewer than thirty of us are engineers. That matters for this post mainly because everything below used to be considered something only large companies could justify.
What the Version Numbers Actually Mean
I have been calling this DevOps 3.0 since May, first as a placeholder and then, having failed to find anything better, as the name. It is worth being precise about what each number refers to, because the middle one is where people get muddled.
DevOps 1.0 dissolved the wall between the people who built software and the people who ran it. You build it, you run it. Two departments became one practice.
DevOps 2.0 was platform engineering. Rather than have every team work out its own way to run, watch and update its software, one team builds the paved road and everyone else drives on it. You want to launch something new, so you pick it off a menu and it arrives configured correctly, instead of assembling it yourself and hoping. This was invented at scale, by companies with hundreds or thousands of engineers, because only at that size did the coordination cost justify the build. It was built by engineers, for engineers.
DevOps 3.0 is that same discipline with a different customer. Not the engineering department. The company.
That distinction is the whole post, so let me put it plainly. Platform engineering is not something 3.0 invents. It is the thing 3.0 inherits, and then points somewhere it was never pointed before. The practice is thirty years of accumulated craft. What is new is who it serves, and the fact that a company far too small to have earned it can now afford to build it.
DevOps 3.0 is not a new practice. It is platform engineering with a new customer: everyone.
Why It Is Affordable Now
A few years ago, a company of sixty people building its own paved road would have been premature scaling, and anyone who said so would have been right. Roads are expensive. You need a lot of traffic before one pays for itself.
Two things moved at once.
Output per person went up several times over, by a factor of about five in our case, with no change in headcount. The coordination problem that platforms exist to solve scales with throughput, not with payroll, so it turned up at a company size that has never had to deal with it before.
And building the road got dramatically cheaper. If you can describe what you want, clearly and in enough detail, you can now have it. Work that would have been a year of platform engineering is a few focused weeks. The thing that used to be over-engineering became affordable and necessary inside the same twelve months.
Why It Is Necessary Now
Affordability is the boring half of the argument. This is the half I think matters more, and it took me a while to see it clearly.
Every company runs on tolerances it does not write down.
This service was configured by hand in a console two years ago and nobody documented it. That one has no production monitoring, because it was only ever meant to run for a month and then it just kept running. That third thing never had a security review, because it is internal and small and who would bother.
None of that was ever good practice. It was survivable, and it was survivable for one reason: a human was in the loop. Somebody knew that box was fragile. Somebody noticed the numbers looked wrong on a Tuesday. The gaps were closed continuously, by judgment that nobody ever wrote down and mostly could not have written down.
Hand the work to an agent and you remove exactly that person.
An agent acts when it is asked, on what it can see. It is very good and it is not suspicious in the way a person who has been burned before is suspicious. It does not know which box is fragile, because nobody ever said so out loud.
So the tolerances stop being survivable. Not for compliance reasons, and not because anything got riskier in itself. Because the duct tape was always human, and you just took the human out.
The duct tape was always human. Take the human out of the loop and you have to build the thing properly.
The upside is the better half of that trade, and it is genuinely better. Instead of applications held together with human attention, you get something much closer to the practice we always claimed we wanted: monitoring that exists from the first deploy, a deployment path that is the same everywhere, security designed in rather than retrofitted. Not because anyone got more disciplined. Because it is now cheap to build it that way and expensive not to.
And once that foundation is real, you can let agents run on top of it and actually collect the velocity they promise, instead of spending the velocity on anxiety.
A Platform for People Who Are Not Engineers
Everything to this point is recognisable platform engineering, done earlier than usual. Here is where it stops being a familiar story.
AI pulled people who would never have opened a terminal into technical work. Nobody planned this and nobody particularly wants it. It is happening because the abstractions are young: the fastest route to getting real work out of an agent today still runs through repositories, command lines and deployments. Give it two years and most of that will be hidden. We do not have two years, because the companies that build this muscle now are the ones that will have it when it matters.
Which means the platform team's users include someone in sales with a screening automation and someone in finance with a reconciliation job that should run every Monday.
What those people need is not what an engineer needs. They need somewhere to put a thing so it runs, reasonable confidence it will not quietly break, and to be told when it does. They do not need the forty technical choices an engineer would want to make along the way. Handing them the engineering platform unmodified is like handing someone a pile of engine parts when they asked to be driven to the station.
This is where our own command-line tool comes in, and I want to be careful about why it is interesting, because the obvious reading is the wrong one. Plenty of companies have an internal tool that sets up a developer's machine and launches new projects to a standard. That is not the story.
The story is that ours does not ask whether you are a developer. It asks which team you are in, and marketing is one of the answers. Pick that, and it installs what knowledge work actually requires and nothing else. The person who maintains our pricing guidelines does not need the machinery an engineer needs, and making them install it is how you lose them in the first ten minutes.
Underneath, it is the same platform. The standards are the same, the runtime is the same, the monitoring is the same. What changes is how much of it you are asked to understand.
Democratising code and technical runtimes, without handing everyone a degree in software engineering.
I wrote in Everyone Produces Code Now about non-developers starting to ship software. This is the other half of that story: the infrastructure that has to exist underneath for it to be anything other than chaos.
Not Police. Track Layers.
The obvious objection to all of the above is that it sounds like the Wild West with extra steps.
It is, if all you do is hand out access. But the two instinctive answers are both worse. A gate puts sales back in the queue behind engineering, which is the problem you were solving. A policing function, where somebody chases people about unpatched dependencies for the fourth week running, fails on human grounds before it fails on technical ones. Nobody wants to be the babysitter, and nobody responds well to being babysat.
The useful framing is that a platform team is not a police unit. It is closer to an entrepreneurial one. It goes out ahead, lays the track, makes the journey possible, and then helps you travel it.
Concretely that means three things.
- Decide once. One deployment format, one place things run, one monitoring standard. The specific choices matter far less than the fact that they are choices, written down, and the same everywhere.
- Make the standard path the easy path. Setting something up happens through the tool, not by clicking through a console and hoping you remembered everything. The template is itself a piece of software we keep updated, so when we discover a gap we fix it centrally and everyone gets the fix, rather than sending a memo asking people to go and change something.
- Let machines do the enforcement. Monitoring switched on by default rather than remembered. Checks that fail loudly. A routine that walks through everything running and flags whatever has drifted out of date, which is a much better colleague than the person who has to keep raising it in a meeting.
The general form of that argument, applied to code rather than infrastructure, is Don't Just Tell It. Enforce It. The security version, about why agents need a perimeter rather than a content filter, is It's All About Trust.
The Engineering Half
None of this means the engineering-specific job went away. Inside engineering, DevOps 3.0 has a second and narrower mandate, and it arrives from a change in how teams are shaped.
Software teams used to be assembled from specialists: someone for the part users see, someone for the part they do not, someone for the plumbing underneath. Those boundaries have collapsed toward the middle. You no longer need the specialist to make a routine change in their territory. The distinctions did not vanish, but they stopped being load-bearing for most of the work most weeks.
One competence did not collapse: prioritisation, direction, taste, closeness to customers, being on the hook when it ships. There is a hard limit on how much of that you can make more efficient and still ship something good, because it needs human capacity. So the product manager becomes the constraint, and it is not the kind you fix by working smarter.
The way out is smaller teams. One PM and at most two senior developers, rather than one PM and five. Which means more teams, which means more places for someone to invent their own approach to hosting, and suddenly you are back at the platform problem from a completely different direction.
I find that reassuring rather than annoying. The whole-company argument and the engineering-internal argument arrive at the same answer from opposite ends. That is usually the tell that the answer is right.
What It Costs
Three honest things, because this is not free.
The time is already being spent. A large share of our infrastructure team's week used to go on ad-hoc firefighting that never stopped. That is the budget you are buying back, and it is also precisely why you never have time to build the thing that would stop it. Somebody has to decide to eat the cost first.
Teams have to accept ownership. Your application in production, including being on the hook when it breaks, in exchange for considerably more autonomy. That is a real trade and not everyone wants it.
Sometimes a feature waits. This is the one that actually hurts. Adapting to the standard has to win occasionally, even when it delays something a customer is asking for. That only holds if the goal is clear enough that people can see why. Otherwise the individual feature wins every single time, and it wins quietly.
And to be clear about where we are: we do not have a finished platform, and I would not believe anyone our size who claimed they did. We have the decisions, the tool, somewhere for things to run, and a list of blind spots we are working through one team at a time. Somebody will turn up next month with a need nobody designed for. That is fine. It is a far better problem than the one where every team invents its own answer in private.
Why This Is Post One of Three
Before we put an agent on a job, four things have to be true, and the third post lays all four out. The second of them is whether the agent can actually reach the systems: does it have the tools, the accounts, the permissions, and can it act rather than only talk. That question is this entire post. An agent with no reach is an expensive chatbot.
The third of the four is whether it knows us. Our products, our rules, our edge cases, written down instead of living in somebody's head. That is the next post, and it is the one that changed the most.