I was doing research on what to build next in the AI world. I’ve done a few hobby projects that have gone nowhere. I was fishing for the next. I was looking for an interesting idea to implement. So, I decided to take a look at recent job descriptions to see what companies want and where they want to go.
To my surprise, companies in very different domains look like they are asking for similar capabilities. Initially, most of the conversation around AI driven development was about producing and understanding code. Now, the problems are gradually moving to agentic development. Job descriptions talk about skills and MCP, standardized environments, reusable patterns, service metadata and permissions. Then there is evaluation, traceability, audit and the cost of work done by LLMs. These are different industries, different names, but they appear to be converging on the same question. How do we get LLMs to do repeatable, trustworthy and usable work?
We’re well past the stage where LLMs were autocomplete. We’ve been putting them deeper and deeper into the SDLC. The bizarre thing is that producing software is starting to move beyond human speed, while the rest of the system still assumes a human is on the other side.
Where Human Approval
We Put AI Into the Old Machine
When we first interacted with LLMs, we put them into our existing human workflows. That was rather a practical approach. Now, with the advent of agentic workflows, they are expected to be side by side with humans. The trouble is that almost everything around software development was designed around humans. Our throughput, permissions, development environments, review systems and ownership models all fundamentally assume that the actor doing the work is a person.
Our existing system looked roughly as follows.
Classic SDLC
Agents are different, for one, there can be many, and they do not necessarily operate at human speed. One engineer can have several agents making changes at once. That changes the assumptions underneath our entire development pipeline.
A pull request assumes changes arrive slowly enough for another human to inspect them. CI capacity roughly follows the pace at which humans produce code. Service ownership assumes teams create software slowly enough to absorb it. Permissions assume the actor exercising them is a person who can be held accountable later. All of that starts to break when the worker is an agent, because our system was never designed for something that can produce this much shit this quickly.
Humans Have Been Filling the Gaps
Today, humans are filling the gaps. For instance, we have been writing our documentation in markdown files, even more, we have been even writing ticket description, designs in such a way. That helps give context for AI because it can then pattern search what happened.
We have also been building paved paths for years to repeat quality across repositories. The difference is that another consumer has arrived. Now, we need to do the same for LLMs but the trick is to get them to consume it. Companies are investing in reusable patterns, reference architectures, service metadata, machine-readable instructions, skills, templates, development environments and explicit context delivery. Hence, standardization and paved paths appear again and again.
A surprising amount of what we will call LLM-ready platform engineering is really the work of converting organizational knowledge into something a machine can consume. Things engineers used to learn from another engineer, infer from a repository, or discover by asking around now have to become explicit. We have wanted better documentation for years and there is never enough of it. Apparently agents are finally going to make us write the damn thing, pro bono.
The Developer Platform Gets a New Persona
If you think about modern platform engineering, we standardized a few good things. With the new persona coming in, we need to think a bunch of these capabilities in terms of agents. Standard questions like how do I deploy, how do I create a ticket, where are my logs, how do I get credentials, who owns this service and so forth need to be calibrated against both humans and agents.
Developer experience, AI platform, security and developer productivity are already bleeding into each other. I don’t think the names will matter for long. Call it whatever you want. We are going to end up with a platform that has to work for both humans and agents.
Once an agent needs to discover a service, figure out who owns it, get credentials, make a change and prove what it did, our concerns start collapsing into each other. Humans have been filling the gaps with judgment, memory, reputation and the ability to ask someone what the hell is going on. Agents need those things represented in the system.
Limits will be Part of Control Plane
Now, we are solving the problem of what LLMs are allowed to do and what they aren’t. If you wrote something as follows.
Use Java 24.
Follow our repository pattern.
Do not access production.
Run integration tests.
Ask before changing schemas.
We are using prose as permission and LLMs occasionally don't give a shit. If we are going to give an agent consequential work, that’s not gonna fly. These are also represented in every repo, so they will drift. I think these will converge into controlled permissions, policy, traceability, auditability, validation and reproducible environments alongside ordinary agent instructions. And again there seems to be startups around that. Missed the train!
One thing that I have never thought of is that instructions become executable constraints. That’s essentially what we wanted in platforms but we also valued engineering freedom to an extent. We are now treating this as non-negotiable given that agents can mess things up big time.
Rules like “Do not access production” or “Ask before changing schemas” can’t be soft prompts. The platform has to say no. Maybe that’s policy-as-code at the API layer, maybe something else, but the agent shouldn’t get to negotiate. The same goes for execution. If an agent gets a working tree, give it a reproducible, isolated environment too. A short-lived container, for example. Let it loop there instead of running its nonsense on shared infrastructure. And keep a record of what it did and why, because “it ran” isn’t much help when something goes wrong.
On the flip side, not every instruction needs enforcement. “Prefer this repository pattern” can remain guidance. Instructions can express taste. Anything that defines what an agent is allowed to do has to live in the platform constraints.
The Unit of Work Introduces New Metrics
Developer productivity was about enabling engineers to get their best work with the least amount of friction. We tracked a few good metrics such as lead time for changes, deployment frequency, change failure rate and so on. They became part of the DORA metrics. Yet metrics are indicators, not guarantees. With LLMs, I think something closer to time to safe merge starts becoming interesting because the developer is no longer necessarily the unit producing the work.
Suppose five agents are working for an engineer, assuming the token cost will go lower. Each agent gets a sandbox, a working tree. That means pressure on compiling, testing, and other resources because these agents can spend a lot of time doing the work, e.g. loop engineering. In the end, someone takes a look at the work and says this is ready.
The imbalance is interesting. Five agents can generate fifty candidate changes while the engineer is still one person who has to establish whether any of them are safe. We can increase production upstream without increasing safe throughput downstream. That means the metric cannot simply be how much code the agent produced or how many tasks it completed. The useful boundary is how much of the path to a safe merge the system can complete without creating more work for the human at the end.
What the Next SDLC Looks Like
This research made me ask the same question again and again. How does SDLC look like in the future? I think it has drastically changed for some companies already, not so much for others. Some companies are already defining an agentic SDLC while others are still putting agents into the existing one.
I think we are going to go to something like standardized environments, skills, permissions, evaluation and lifecycle controls rather than something the sources describe as one finished system. When you have a task like moving the payments service to the new authentication mechanism. It would look quite different. It’s more like as follows.
Agentic SDLC
In this world, agents become replaceable. It’s like switching from one electricity provider to another. The important point is that the surrounding engineering platform knows enough to let either of them work safely. In a few years, we came to a quite different place from where we started with coding assistants.
And once the platform knows enough to let an agent do the work, the interesting problems start moving outside the agent. Who can do what, what happens when work collides, who owns the result, and eventually, how the agents deal with each other.
What’s the Bottleneck?
Our development environments are assumed and designed for humans. If code takes thirty seconds and CI takes twenty minutes, CI becomes the problem. If five agents can work in parallel but their changes collide, integration becomes the problem. If agents can create services faster than teams can operate them, ownership becomes the problem. If agents can execute production actions, authorization becomes the problem. If agents can create hundreds of internal skills and workflows, lifecycle and reuse become the problem. More ifs to come. However, that’s not where this ends.
The bottleneck keeps moving because the constraint we removed was human production speed. We did not remove everything that surrounded it.
It comes back to a question I asked earlier: where does the automation have to stop? I thought the answer was humans, one way or another. Perhaps. The strange part is that the further we automate the SDLC, the more it starts to resemble the thing we were supposedly automating away. Good old engineering organization.
Parallel agents need to divide work without making the same bet. They need to distrust bad information, resolve conflicts, establish hierarchy and remember what happened. They also have to deal with actors whose goals do not quite line up. Humans have norms, reputation, incentives and recourse because intelligence is never enough to make coordination work.
It looks like agents are going to discover the same problem very quickly. So perhaps the final bottleneck is not only humans but also coordination of agents. We can replace more of the people doing the work, but then we have to rebuild, in software, many of the systems humans invented to make groups of people work together.