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, in my reading, is the most important thing happening in software right now. The pattern, in my reading, is also the most dangerous thing happening in software right now. 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 pushing in the same direction, the same direction the agent ecosystem is now accelerating. 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, in my reading, 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, in my reading, 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 agent will write the migration. The agent will wire the queue. The agent 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, in my reading, a literacy of concepts, not of implementation. The implementation is becoming free. The concepts are becoming more valuable, not less. The concepts are the part the agent cannot do. The concepts are the part that decides whether the system I am building, with the help of the agent, is going to be a system I can live with for the next five years, or a system I am going to be refactoring every quarter for the rest of my life.
Where agents are great, and where they are not
The agent is, in my reading, an extraordinary tool for one specific kind of work, and a very poor tool for another. The line between the two is, I think, 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. The agent is, in my experience, 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. For the from-zero work, the agent is the most leveraged piece of equipment I have ever used.
The agent is, in my reading, 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 a system that was built two years ago, by a different person, with a different mental model. The first time a field needs to be renamed, in production, without losing the data that was already collected under the old name. The first time a foreign key needs to be added, after the table has been written to for two years, in a way that does not lock the system for an hour.
The reason the agent struggles here, I think, 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 of understanding that lives in the heads of the people who built it, in the way the data was shaped, in the comments in the code that no one reads, in the deployment scripts that no one touched because they worked, in the schema migrations that no one remembers writing. The agent can hold a schema in context. The agent cannot hold a history. The history is, in my reading, 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, in my reading, 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. 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, in my reading, 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. The system is built — in many cases by a vendor — to a specification written by a non-technical stakeholder. The specification is, in most cases, a list of features: the things the system should do, without an architecture underneath. The system ships. The system is presented to the grassroots staff. The grassroots staff is told to use it. The grassroots staff, asked in private, says the system is not useful, does not fit the workflow, and does not solve the problem they actually have. The system continues to be used, because the system has been mandated. The system is used, by the grassroots, in the most minimal way possible. The system produces no data. The system produces no behavioral change. The system sits, in production, in the most literal sense of the word — 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 to build was made, in my reading, by people who did not have the professional background to make the call. The decision to build was made by people who had a real problem — a real problem, in a real workflow, with a real cost — and who responded to the problem in the only way the agent era has made available: build something. The response is, in my reading, almost always wrong. The response is, in my reading, the failure mode of the unbundling.
The right response, in most of these cases, was not to build. The right response, in most of these cases, was to change the workflow. The right response, in many of these cases, was to do nothing. The right response, in almost all of these cases, was to consult the people who would actually use the system, before any system was built, and to listen to what they said, and to act on what they said. 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 dropped to zero. The cost of building something nobody uses is, in my reading, larger than it has ever been — because the system is now invisible, and the cost of maintaining an invisible system is the cost of a person who does not know the system exists, and the cost of a person who does not know the system exists is the cost of a person who will leave the company, and the cost of a person who will leave the company is the cost of a system that no one can maintain. The cost compounds. The cost compounds quietly. The cost compounds in a way that the company will not see until the person leaves, and then it will be 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. The cost of building, for as long as I can remember, has been higher than it needed to be, and the cost of building being lower is, in my reading, 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, in my reading, very easy to forget in the moment the tools become available. The tools are new. The position is old. The position is older than the tools. The position is older than the industry. The position is 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 are well-modeled, in the well-modeled parts of the system, in the well-modeled parts of the workflow. 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, in my reading, 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, in my reading, the same principle in a different costume. The KPI is a system that pretends to be the professional. The KPI is a system that pretends to be able to make the call. The KPI is, in my reading, 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 judgment is 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. The work of a professional 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 that the rule-based system — the rule-based expert system, the rule-based agent, the rule-based anything — cannot do. The reflection is the part that requires the kind of knowledge that comes only from having been inside the situation before. The agent has, in my reading, no situation. The professional has a situation. The situation is the difference. The situation is 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 work of the manager is fragmented, intuitive, context-driven, and largely invisible. The work of the manager is not the application of a process. The work of the manager is the judgment call. The judgment call, in Mintzberg's reading, is the part that no system can replace, and no system can teach, and no system can 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, in my reading, the deepest layer of the principle I am trying to articulate. The professional knows things they cannot articulate. The professional knows, in their hands, in their gut, in the way they look at a problem, that this is the right call and that is the wrong call. The professional cannot always explain the call. The professional does not need to explain the call. The professional just makes the call. The agent cannot make this kind of call. The agent can only make the calls that can be articulated. The professional is, in Polanyi's reading, the part of the system that holds the unarticulated knowledge. The agent is the part of the system that holds the articulated knowledge. The two are not in competition. The two are in complement. The system that loses the first one, 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, in my reading, 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, in my reading, is the gap the principle is trying to close.
I do not have a formula. I do not have a checklist. I do not have a way to make the principle operational, in the way the agent makes the system operational. The principle is, in my reading, the kind of principle that has to be held by a person, and held loosely, and held against the temptation of the moment. The principle is the kind of principle that has to be re-stated, again and again, every time the tools change. The principle is the kind of principle the agent era, in particular, is going to make it easy to forget.
I am going to keep stating it. 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 whether to 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. The principle is going to be more important in the agent era, 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.