The observation
Over the last year, I have been watching the same thing happen across three different jobs, with three different sets of people, in three different verticals. The tool is new. The pattern is the same.
A sales lead opens Codex. She describes, in a paragraph of plain English, the exact field she wants to behave differently in the customer quote. Forty minutes later, she is reviewing a diff. She merges it. The customer sees the change the next morning.
An operations lead opens Cursor. He describes the script that has been eating two hours of his Monday morning for the last three years — the same script, every week, the same five sources, the same output. The agent writes the script in an afternoon. The Monday-morning block is now fifteen minutes.
A finance lead, who has never written a line of code in his life, sits down with Claude Code and a description of the Excel report that has been quietly broken for two years. The report has thirty pages. Each page has thousands of rows. The format is so specific to this one team that the IT department has, for two years, called it out of scope. The agent writes it in an afternoon. The report has not broken since.
These are not hypotheticals. These are the people I work with, in the systems I help run. The pattern is the most important thing happening in software right now — and also the most dangerous. The two observations are not in tension. They are the same observation, looked at from two angles.
What I decided, and why
About a year ago, I made a decision I have not talked about publicly yet. I decided that, in the long run, I do not want to spend the rest of my career inside the developer line of an org chart.
The decision was not against software. The decision was for the same reason most of the people I respect have made the same kind of decision: the thing I used to be paid for is, slowly, becoming the thing everyone can do. The bundle of skills that used to make a person "a developer" — the syntax, the framework rituals, the discipline of pull requests and dependency graphs — is being unbundled. The pieces are being redistributed into the hands of every person who has a real problem and a Saturday afternoon to spend on it.
I have been watching this happen for longer than the public AI moment. I have been watching it, in some form, since I first saw a friend with a finance background build a small internal tool in Flask over a weekend, and the IT department tell her, with a straight face, that the request was "out of scope" and would take "two quarters to evaluate." She shipped the tool anyway. It ran for two years. The team never went back to IT.
What I was watching, in that story, was not a finance person learning to code. What I was watching was the cost of writing software dropping toward zero, faster than the institution could keep up. Flask, FastAPI, Python, Go, Rust — the entire language ecosystem of the last decade has been moving in one direction, and the agent ecosystem is now accelerating in the same one. The frameworks have been getting lighter. The runtime costs have been getting lower. The on-ramp has been getting shorter. The agent era is not the cause of the unbundling. The agent era is the moment the unbundling became visible to everyone.
If you are betting on the inside-the-org-chart version of being a developer, you are betting against a curve that has been in motion for a decade and is now, by every measure I can see, steepening. I would not make that bet. I did not make that bet. I made the other one.
The new literacy
The new literacy is not the old literacy with a thinner wrapper. The new literacy is almost entirely conceptual.
I do not need to know how to deploy Docker to use Docker. I do not need to know how to configure a Kubernetes cluster to run one. I do not need to write a Dockerfile from memory, or wire a docker-compose file, or debug a container that fails to start. An agent will do all of this, in the time it takes me to write a paragraph describing the system I want.
What I do need to know is why Docker exists in the first place. What problem does it solve. What problem does it create. When is the right time to introduce it into a system, and when is the right time to wait. What does containerization buy me that a virtual machine does not. When does the abstraction start to leak. The agent can do the syntax. The agent cannot tell me when the abstraction is wrong for the problem in front of me.
The same is true for the entire stack.
I do not need to know how to implement a microservice architecture. I do not need to write the gateway, the service discovery, the auth layer, the inter-service communication. I do not need to know what gRPC is, or when to use it, or what its trade-offs are. An agent will do all of this for me, if I tell it the shape of the system I want.
I do need to know what a microservice is. I do need to know when a system should be a monolith and when it should be a set of services. I do need to know what a service boundary looks like, and why the boundary is there, and what the cost of the boundary is, and when the cost stops being worth paying. The agent will not tell me this. The agent will not even know to ask. The question is not in the agent's domain. The question is in mine.
The same is true for yaml and json. The same is true for the choice of database. The same is true for the choice between a relational store and a document store, between synchronous and asynchronous communication, between an event log and a queue. The agent will write the YAML, the migration, the queue wiring. It cannot tell me, in advance, which of these choices is the right one for the system in front of me — because the answer depends on the system, and the system is mine, and the trade-offs are mine, and the consequences of the choice are mine.
This is the new literacy. It is a literacy of concepts, not of implementation. The implementation is becoming free. The concepts are becoming more valuable, not less — the part the agent cannot do, and the part that decides whether the system I am building, with the agent's help, is going to be one I can live with for the next five years, or one I will be refactoring every quarter for the rest of my life.
Where agents are great, and where they are not
The agent is an extraordinary tool for one specific kind of work, and a very poor tool for another. The line between the two is the most important line to draw right now.
The agent is extraordinary at the part of the work that goes from zero to one. The first prototype. The first screen. The first endpoint. The first draft of the schema, the first pass at the API, the first version of the deployment pipeline. In my experience, the agent is almost as good as a competent mid-level engineer at the from-zero work — and the agent does not get tired, does not lose the thread, does not need to be paid, and does not need to be told twice. For the from-zero work, the agent is a near-perfect tool — the most leveraged piece of equipment I have ever used.
The agent is a very poor tool for the part of the work that goes from one to one hundred. The first bug fix. The first refactor. The first migration. The first time the system has to talk to another system built two years ago, by a different person, with a different mental model — a field needs to be renamed in production without losing old data, a foreign key added after years of writes without locking the table.
The reason the agent struggles here is not that the agent is not smart enough. The reason is that the work the agent is being asked to do is the kind of work that depends on a long, contextual, mostly-implicit understanding of the system — the kind that lives in the heads of the people who built it, in the way the data was shaped, and in every comment, deployment script, and schema migration no one touched because they worked. The agent can hold a schema in context. The agent cannot hold a history. The history is the part of the system that matters most at the one-to-one-hundred phase, and the history is the part the agent cannot see.
This is why the people I respect are careful, right now, about which work they hand to the agent. The 0→1 work, they hand over completely. The 1→100 work, they keep. The reason they keep it is not vanity. The reason they keep it is that the work depends on the history, and the history is not yet in a form the agent can read.
The principle, in one sentence
There is a principle I have come back to, again and again, in every job I have had. I have come back to it because it is simple, and because the simpler the principle, the more often it gets ignored. The principle is this:
Professional matters should be handled by professionals.
The sentence is, on the face of it, almost embarrassingly obvious. The reason I am putting it on the page is that the principle is the one most likely to be forgotten in the moment the agent becomes available to everyone.
When the cost of building drops toward zero, the temptation is to build — in every direction, for every problem, with every tool that has just become available. The temptation is also the failure mode. The failure mode is the version of the company that wakes up one morning with fifty internal tools, none of them architected, none of them connected, none of them maintained, all of them running on the local machine of the person who built them, all of them quietly breaking in production, all of them waiting for the day the person who built them leaves the company.
What this looks like, in practice
I have been watching a version of this failure mode unfold, slowly, at the company I currently work at.
The HR director has been pushing, for the last several months, the development of various internal systems. The push has been real, and the budget has been real. Tens of thousands to hundreds of thousands of yuan have been spent. The list of systems is long, and the list grows every quarter.
I have been watching, with some care, what happens to these systems after they ship.
The pattern, with a few exceptions, has been the same. A vendor builds the system — or a non-technical stakeholder commissions it — to a list of features rather than an architecture. The system ships. The grassroots staff is told to use it. Asked in private, they say it does not fit the workflow and does not solve the problem they actually have. Asked in public, they say it is useful. The system, having been mandated, gets used in the most minimal way possible. It produces no data, no behavioral change. It sits in production — running, taking up resources, not doing anything useful.
This is not a failure of the people who built the systems. The vendors are competent. The engineers they hired are competent. The systems, taken on their own terms, work.
This is a failure of the decision to build the systems at all. The decision was made by people who did not have the professional background to make the call. They had a real problem — a real problem, in a real workflow, with a real cost — and they responded in the only way the agent era has made available: build something. The response is almost always wrong. It is the failure mode of the unbundling.
The right response, in most of these cases, was not to build. It was to change the workflow, or to do nothing, or to consult the people who would actually use the system, before any system was built, and to listen. The system, in most of these cases, was the answer to a question that should never have been asked.
The cost of building has dropped to near zero. The cost of building something nobody uses has not — it is larger than it has ever been. The system is now invisible. The person who maintains it is invisible. The person eventually leaves, and the system no one can maintain is the one no one can replace. The cost compounds, quietly, in a way the company will not see until the person leaves. Then it is too late.
What I am not saying
I am not saying agents are bad. I am not saying the unbundling of coding is bad. I am not saying the cost of building should be high. The cost of building should be low. It has, for as long as I can remember, been higher than it needed to be — and the cost being lower is one of the best things that has happened in the industry in my lifetime.
I am not saying everyone should not build. I am not saying the HR director should not be curious about building. I am saying that being curious about building, and being qualified to make the call to build, are two different things. The first is good. The second is a professional judgment. The second should be made by a professional — the person who can name the trade-offs, who has built systems before, who has seen systems fail before, who has rebuilt systems that should never have been built before, and who has the scar tissue to know the difference.
I am not saying this is a controversial position. I am saying it is a position that is very easy to forget in the moment the tools become available. The tools are new. The position is old — older than the tools, older than the industry, the same position that, in any profession, separates the people who can make the call from the people who cannot.
Where this connects
This is the same principle I keep returning to, in every system I have built and in every essay I have written on this site.
The agent-pipeline post is the same principle applied to a smaller surface. The pipeline exists to dissolve the bottleneck of the developer, in cases where the requirement is small, the workflow is clear, and the system model is well-known. The pipeline does not exist to make every decision. The pipeline exists to make the decisions that fit inside a known model — the well-modeled parts of the system and the workflow alike. The decisions that are not well-modeled — the ones at the edges, the ones about what to build and what not to build — those are the decisions the human keeps. The pipeline is not a replacement for the professional. The pipeline is a tool the professional uses.
The dirty-work piece is the closest cousin. The argument there was that creative work should be done by people, and dirty work should be done by systems. The argument here is that professional decisions should be made by professionals, and the decision to build a system is a professional decision. The two arguments are the same argument, applied to two different layers of the same problem.
The KPI piece is the same principle in a different costume. The KPI is a system that pretends to be the professional — pretends to be able to make the call. The KPI is exactly the kind of system the agent era is going to produce more of, faster, and cheaper, and at scale. The system that builds KPIs in the agent era will produce more KPIs. The system that builds KPIs in the agent era will not produce more judgment. The judgment is the part that is becoming more expensive, not less — the part the agent cannot do.
What the literature already says
I did not invent any of this. The framing here is borrowed, openly, from work that has been around much longer than I have.
Donald Schön, The Reflective Practitioner. Schön's argument, which I have come back to repeatedly in the last two years, is that the work of a professional is not the application of a rule. It is the recognition of the situation, the framing of the problem, the naming of the trade-offs. Schön calls this reflection-in-action. The reflection is, in his reading, the part the rule-based system cannot do — the rule-based expert system, the rule-based agent, the rule-based anything. It requires the kind of knowledge that comes only from having been inside the situation before. The agent has no situation. The professional has one. The situation is the difference, and the part that matters.
Henry Mintzberg, The Nature of Managerial Work. Mintzberg's study of what managers actually do, as opposed to what management textbooks say they do, came to a similar conclusion. The manager's work is fragmented, intuitive, context-driven, and largely invisible — not the application of a process, but the judgment call itself. The judgment call, in Mintzberg's reading, is the part no system can replace, teach, or pretend to do. The agent will not make the judgment call. The agent will not even know that the judgment call is happening.
Michael Polanyi, The Tacit Dimension. Polanyi's argument that we know more than we can tell is the deepest layer of the principle I am trying to articulate. The professional holds things in their hands and gut that they cannot put into words. The knowing is in the way they look at a problem, in the instinct that comes from years inside it. The professional cannot always explain the call, does not need to, and just makes it. The agent, by contrast, can only make the calls that can be articulated. The professional, in Polanyi's reading, is the part of the system that holds the unarticulated knowledge; the agent is the part that holds the articulated. They are not in competition but in complement. The system that loses the first in favor of the second is the system that produces the failure mode I have been describing.
I am not going to re-explain them here. The point is the same point.
A postscript
I am writing this in the back half of 2026. The agent era is still early. The cost of building is still dropping. The number of people who can build is still rising. The number of systems being built, in every company I work with, is rising faster than the number of people who can decide whether the systems should be built. The gap is what the principle is trying to close.
There is no formula here, and no checklist. This is the kind of principle that has to be held by a person, and held against the temptation of the moment, because nothing in the tooling will hold it for you. It has to be re-stated every time the tools change, and the agent era in particular is going to make it easy to forget.
I am going to keep stating it. In the systems I build. In the meetings I have. In the small decisions about whether to build or wait. I am going to keep stating it because the principle is, in my reading, the most important thing I have learned in the last year. The principle is older than the agent era, and more important in it, not less.
The hardest part is not the principle. The hardest part is the discipline to apply the principle, in the moment, when the tools are right there, and the budget is approved, and the team is ready, and the only thing missing is the call to wait.