I believe the profession we call "developer" is about to turn into something fundamentally different. This isn't a matter of tools changing or productivity rising. The very identity of the job is shifting somewhere else. If I had to name it in a single word: the developer becomes a Pipeliner.
The developer was always an "intelligent executor"
To make this case, I have to start with what a developer has actually been doing all this time. We call developers "builders," but the essence of the work was translation. You take a spec someone else defined — a plan, a requirement, a ticket, words exchanged in a meeting — and render it into a form a machine can execute. The developer stood between human intent and machine execution as an interpreter.
But this translation was never mechanical. Specs are always incomplete, contradictory, full of gaps. Filling those gaps with judgment, imagining the edge cases, inferring what was never stated, and turning all of it into a working system — that was not manual labor but intellectual labor. So I'd describe the developer more precisely as an intelligent executor: someone who uses intelligence to execute. That is what made a developer a developer for the past several decades.
What's interesting is that this role survived several waves of "automation threat." From assembly to high-level languages, from high-level languages to frameworks, from on-premise to the cloud. Each time the abstraction rose one level, a large part of the execution got automated. You no longer manage memory by hand, you no longer stand up servers yourself. And yet the developer survived every time. Because what got automated was the mechanical part of execution, while the judgment execution required stayed with the human. The "execution" was shaved down bit by bit; the "intelligence" remained intact.
This time is different — AI took the "intelligence" side
Here is exactly where AI changes things. What's being automated now is not the mechanical part of execution but the judgment execution requires. Filling the gaps in an incomplete spec, imagining the edge cases, inferring the unstated and turning it into working code — the very definition of the intelligent executor — is now done by AI.
This is decisive. Every prior wave of automation peeled "execution" off the developer but never touched "intelligence." So the developer could climb to a higher abstraction and remain an intelligent executor up there. This time, the intelligence itself was taken. The core of what made a developer a developer is being transferred wholesale. The old formula — "just climb to a higher abstraction" — doesn't work this time, because the ladder itself has been handed to the AI.
So what remains — placing the intelligence
If execution has gone to the AI, what is left for the human? The answer is clear: making that AI do the work well. And that turns out to be a big job.
AI is a powerful execution engine, but on its own it does nothing. What should it take as input, what context should come with it, against what should its output be verified, where should it flow when it fails, and to what next stage should its output connect — someone has to design all of this. Deciding where to pour the raw material of intelligence, through which pipes to run it, and with which valves to control it. I call this the pipeline.
Here, "pipeline" is not a narrow technical term like a CI/CD pipeline or a data pipeline. It is much broader — designing and managing the entire path through which intelligence flows. It's less like laying bricks and more like being the water engineer who designs how a whole city's water will move. Bricks are now churned out infinitely by AI. The question is how to arrange those bricks into a flow, and the person who handles that flow is the pipeliner.
It means the developer moves from "the one who writes code" to "the one who designs flow." From the one who builds with their hands to the one who arranges the hands.
Why "developer" no longer fits
But a thought might arise here. If designing and connecting flow is the job, wasn't the developer doing that all along? Wiring functions together, connecting modules, designing data flow — isn't that itself pipelining?
At the micro level, that's true. In some sense the developer has always been pipelining, and there's no denying it. But the decisive difference lies in the unit — the level — at which that pipelining happened.
Until now, the developer's pipelining was locked inside the code level. Wiring functions and modules within a given spec, inside system boundaries already drawn. The level above — why are we building this, which customer problem does it solve, what should the flow look like in business terms — was usually decided and handed down by someone else (a planner, a PM, the business side), and the developer wove flow only inside that fence. Because the unit of pipelining stayed at the code level, the name "developer" — the one who develops — was enough.
What the era now demands is pipelining at a different level. Beyond the code level: designing flow at the business level where an actual customer problem gets solved, and at the level of the whole system that solves it. Because AI took the code-level pipelining, what's left for the human is the pipelining above it. And this work is no longer about developing code, so the narrow word "developer" can't contain it. Someone who isn't bound to code as a particular material but weaves flow across levels — that's why I think a new name is needed. A pipeliner.
The pipeliner's capabilities — ABCD2
So what capabilities does this pipeliner need? I organize them into five. Comprehend, Abstract, Dissolve, Build, Describe. Taking the initials, I call it ABCD2.
Listed abstractly they don't land, so let me thread them through a single scenario. Suppose a company says, "we want to automate customer refund processing with AI." How does a pipeliner handle this problem?
Comprehend. First you have to understand the world you need to connect. The job is grasping what the word "refund" actually touches in this company. A refund touches the accounting ledger, reverses inventory, affects customer trust, and runs into tax and legal. Someone who only sees the happy path has already failed here. If you don't know how the world actually turns, you misunderstand the very thing you're supposed to connect. Comprehension is knowing the material of the pipeline precisely.
Abstract. The reality you've comprehended is messy. Exceptions, special cases, and office politics are all tangled together. Stripping out only the essential structure you can work with, from that messy reality, is abstraction. Erecting a skeleton like: "a refund is ultimately five stages — (identify the transaction) → (judge refund eligibility) → (calculate the amount) → (get approval) → (execute)." Good abstraction simplifies reality without throwing away what matters. That sense of balance is the heart of abstraction, and the hardest part to learn.
Dissolve. Now break the abstracted skeleton into executable units. Why break it up? Because if you throw the whole thing at the AI — "handle the refund on your own" — there's no way to verify the output. In one lump you can't tell where it went wrong. You have to dissolve it so each unit is independently verifiable, so the AI can process each piece and a human can check each piece. Dissolving isn't just cutting things small; it's the sense for cutting along verifiable boundaries.
Build. Now weave the dissolved units into a single flow. Place AI at each stage, insert verification between them, design fallbacks that hand off to a human on failure, and put a human in the loop at the approval stage. Making units and making flow are different abilities. You can gather good parts and still have a system that doesn't run if the flow is tangled. Building is actually connecting the plumbing so the water moves.
Describe. Finally, you must be able to explain that flow clearly. This isn't an add-on ability; it's essential. If you can't put into words what you connected, why, and how, that pipeline can't be maintained, can't be audited, can't be handed to someone else, can't be sold. And more fundamentally, to describe is to own the definition yourself. Being able to say "I decided this refund logic should judge it this way," and bearing the consequences. The ability to describe is inseparable from ownership.
Comprehend, Abstract, Dissolve, Build, Describe. It called ABCD2. And as you may have noticed, none of these five is "the ability to write good code."
FDE as proof
This capability set isn't widely recognized yet, but its prototype already exists in the market. The FDE — Forward Deployed Engineer.
An FDE does different work from a traditional developer. They go into the customer's organization, comprehend their world, abstract the real problem, dissolve it into solvable units, build a flow that actually works, and describe and persuade the customer's organization of it. An FDE's value doesn't come from lines of code. It comes from the ability to connect the customer's chaotic reality with the tools.
In other words, the FDE is already a pipeliner. Before AI had even fully taken over execution, the market had already discovered the point where the value of "the one who connects and designs" overwhelms the value of "the one who executes." It's no accident that the FDE has become one of the most highly paid engineering positions in recent years. That's a leading indicator of the pipeliner era.
The real problem — the vanishing of "execution" as a buffer
While a few like the FDE rise upward, the opposite happens below. Until now, "execution" has been the vast buffer zone of knowledge work. Even without being exceptional, even without the full ABCD2, most people were useful simply by diligently executing well-defined tasks. The developer who turns a spec into code, the analyst who organizes data, the marketer who runs an assigned campaign, the office worker who produces documents to a template. They were all "intelligent executors," and they worked stably on top of the buffer of execution.
This buffer is disappearing. Once AI takes execution, diligent execution alone no longer creates value. What remains is designing the pipeline. In a world where the buffer is gone, the "middle" of the skill distribution collapses. The broad middle layer that used to sit between the top-tier pipeliner and the displaced executor — the place where most knowledge workers have lived — thins out entirely.
And this isn't only the developer's story
Here the scope of the argument explodes. ABCD2 is not a capability demanded only of developers. The moment you're working on top of AI as an execution engine, it's demanded equally of every worker who deals in knowledge.
The planner, too, is no longer someone who writes plans, but someone who comprehends the problem, dissolves it, and designs the flow so the AI produces good plans. The same goes for the marketer, the analyst, the consultant, the lawyer, the accountant. In each domain, "execution" goes to the AI, and what remains is the pipelining that directs it. The job titles differ, but the fundamental capability required converges on the single thing: ABCD2. So the pipeliner is the future of the knowledge worker before it is the future of the developer.
The problem is that the people who can actually do these five things are few. That has been true so far, and it will remain true. Comprehending, abstracting, dissolving, building, and describing cannot be taught by manual. They stand on top of judgment, taste, ownership, systems thinking — and abilities like these are not easily reproduced by training.
History has already shown this pattern. When the power loom automated weaving, the many weavers did not all convert into loom designers. The people who could design and run looms were a tiny minority, and the number needed was a tiny minority too. When execution is automated, the seats for designing that execution are always far fewer than the seats for performing it. What's happening now is structurally identical. The only difference is that what's being automated this time is not hands but intelligence — and so what's affected is not physical labor but the whole of knowledge work.
The anticipated objection — "won't AI end up doing the pipelining too?"
There's a question worth raising honestly. If AI took execution, won't it eventually take the pipelining too? Then isn't the pipeliner's seat also temporary?
Partly, yes. AI will keep getting better at pieces of the pipeline — especially the mechanical parts of Build and Dissolve. But the two ends of ABCD2, Comprehend and Describe, are different in nature. Deciding which reality to make the object of connection (comprehend), and owning that definition and explaining it to the world (describe), are fundamentally questions of what do we want and who bears responsibility. AI does not own the objective on its own, and does not bear the consequences on its own. The information asymmetry — AI doesn't know our organization's real context — the quality of task specification, and above all the attribution of responsibility: these are gaps that don't transfer easily.
So I don't see the pipeliner as a temporary role. If anything, the more the pipeline gets automated, the greater the value of the few who decide what it's built for and take responsibility for it. The vanishing of the buffer doesn't threaten these few. It only makes them scarcer.
How do we identify the few?
So the practical question that remains is this: how do we identify the few?
It's not an idle question. Right now nearly every company stands before the same wall — "how do we evaluate talent in the age of AI?" And most of the old yardsticks have already gone dead. Coding tests, algorithm problems, certifications, credentials. What these actually measured was, in the end, "execution ability," and that execution has gone to the AI, as we've seen. There's no guarantee that someone who aces a coding test is a strong pipeliner. If anything, the more someone is optimized for quickly solving well-defined problems, the clumsier they may be at defining the problem itself and connecting the world.
So what should we measure? I think ABCD2 can be the skeleton of the answer. Do they comprehend the world to be connected, abstract the essence, dissolve it into verifiable units, build the flow, describe it and take responsibility? These five axes reveal one's aptitude as a pipeliner regardless of coding skill and regardless of job function.
Add two more axes and you get an evaluation frame you can actually use. One is personality fit — does this person even have the temperament to bear that kind of thinking and ownership? The other is domain fit — is the world they must comprehend and connect precisely this domain? Put together: ABCD2 (capability) × personality fit (temperament) × domain fit (context). This combination of three axes, I believe, can set the direction for the very thing companies are desperately searching for — "how do we hire and place talent in the age of AI?"
And this frame coldly confirms what we said earlier. The people who pass all three axes are exceedingly few. The moment the criterion shifts from "execution" to these three axes, the very size of the population that will remain in knowledge work gets redrawn.
Conclusion — dealing in knowledge becomes the work of a tiny few
Let me sum up. The developer was an intelligent executor, and AI took that role. What remains is the pipelining that directs AI as an execution engine — and because it's pipelining not at the code level but at the business and system level, the narrow word "developer" can't contain it. So the developer becomes a pipeliner. The pipeliner's capabilities are comprehend, abstract, dissolve, build, describe — ABCD2 — and the FDE is its living prototype. And this ABCD2, with personality fit and domain fit added, can become a new axis for evaluating talent in the age of AI.
This capability is demanded not only of developers but of every worker who deals in knowledge. In a world where the buffer of execution has vanished, only those who possess ABCD2 remain in the territory of knowledge work. Such people are few. And so dealing in knowledge itself gets reorganized into the work of a tiny few.
This is the conclusion I really want to reach through the concept of the pipeliner. We are not watching a single job category change. In a world where intelligence has been productized, who can handle intelligence — we are standing at the threshold of being forced to ask that question.
This essay is also available as a GitHub Gist: The Future of Developer is Pipeliner
Would love to hear where you agree or disagree. 👇
Top comments (0)