Over the past few months, I have started noticing something unusual on GitHub. There are profiles that were almost empty, with very few historical commits and little previous activity, that suddenly, from July or August onward, began filling up with complete repositories, CI pipelines, tests, Docker, TypeScript, Python, Rust, web applications, and documentation.
The simplest interpretation would be that artificial intelligence has turned everyone into a programmer. I do not think that is really the point. What is happening goes deeper and has more to do with the way modern harnesses are lowering the threshold required to turn an idea into operational software.
A language model capable of generating code is no longer new. The real transformation is happening around the models. A modern coding agent can read an entire codebase, search through files, modify multiple components, execute commands, observe failures, correct itself, run tests, use Git, interact with browsers and APIs, and autonomously carry out an increasing amount of operational work.
The process that once required:
idea
→ technical knowledge
→ implementation
→ debugging
→ testing
→ deployment
is increasingly being compressed into something closer to:
idea
→ harness
→ verification
This does not mean that everyone has suddenly developed a deep understanding of software engineering. It means that it is becoming possible to obtain technically sophisticated results without manually passing through every layer of the underlying complexity.
This is where production and understanding begin to separate.
Production and Understanding Are No Longer the Same Thing
For a long time, the two were strongly correlated. If someone could build a complex system, it was reasonable to assume that they had been forced to understand at least a significant part of it.
Today, that relationship is far less reliable.
It is possible to end up with a well-structured repository, green tests, CI, deployment, and an apparently coherent architecture without necessarily having a complete mental model of what is happening underneath.
LLMs hide this distance extremely well, partly because they tend to return a clean, ordered narrative of their own work. We may read something like:
I analyzed the problem, identified the root cause, and applied the fix.
The actual process may have been far more convoluted, involving wrong hypotheses, exploration, signals from tools, corrections, and repeated reconstruction of context.
The result may still be correct.
The important point is that the correctness of the result does not necessarily imply an equivalent level of understanding on the part of the user.
The Real Limitation Today Is Context
The limitation I find most interesting is not the obvious hallucination, but the lost detail.
It may be a decision made fifty steps earlier, a premise that is no longer valid, a seemingly minor semantic distinction, or a dependency between components that changes the meaning of the entire system.
An agent can be extremely capable locally while still losing something fundamental globally.
This is why the human is still often the real continuity layer. The human remembers why a decision was made, notices when something feels wrong, recognizes when a green test is not actually proving what it is supposed to prove, and detects when a project is slowly drifting away from its original intent.
The important question is what happens when this limitation is overcome as well.
I do not mean simply a larger context window.
I mean systems capable of preserving, for months or years, persistent state, causality, provenance, previous decisions, obsolete information, assumptions, contradictions, and consequences.
At that point, we would no longer be dealing only with agents that execute tasks.
We would be dealing with systems capable of maintaining a trajectory.
That is where the nature of the problem changes completely.
When Programming Stops Being a Scarce Resource
If agents become far more reliable, persistent, and autonomous, programming itself may gradually stop being a scarce resource.
This does not mean that we will have billions of programmers.
It means something different, and perhaps more important: we may have billions of people capable of causing software to be produced.
An individual could generate tools for a single specific problem. A company could create hundreds of internal applications instead of purchasing them. A researcher could build software for one experiment and discard it immediately afterward. A person could describe a very specific need and receive a tool built almost entirely for that particular situation.
In such a world, software may become increasingly temporary.
Not necessarily a stable product designed to be used for years, but a transient state of intent:
I need this
→ it is built
→ I use it
→ it changes with my needs
→ when it is no longer useful, it can disappear
Coding, however, may only be the first visible signal of a much larger transformation.
The Internet Is Acquiring a New Population
Until now, the Internet has primarily been a network built and used by humans through software.
Even when bots, crawlers, and automations were present, humans remained the fundamental unit of economic and social activity on the network.
A human opened an account. A human performed a search. A human created a website, published content, purchased a product, or initiated a transaction.
Agents change this structure.
A single human can activate dozens of processes capable of browsing the web, querying APIs, modifying repositories, generating software, publishing content, analyzing data, using cloud services, and interacting with other agents.
A single human request can therefore turn into hundreds of machine-to-machine interactions.
From the outside, we may see:
1 prompt
while underneath there may be:
30 searches
12 API calls
5 temporary programs
20 tests
3 agents
1 deployment
This is not simply automation.
It is a multiplier of the number of actors present on the network.
We Are Not at Web 4
We have traditionally described the evolution of the Internet in generations: Web 1.0, Web 2.0, Web 3.
With agents, however, we are not simply adding another feature to the web.
We may be changing the scale of the network itself.
When I say that we may have metaphorically moved from Web 3 to Web 50, I am not proposing a new numbering system. I am describing the compression of change.
The same systems that acquire new capabilities can almost immediately be used to build other systems that exploit those capabilities.
The cycle can become:
better AI
→ software becomes easier to produce
→ more AI-based software
→ more experimentation
→ better tools
→ even more production
At the same time, agents are beginning to produce new digital artifacts that other agents can consume and use to produce additional artifacts.
agents
→ produce new digital artifacts
→ other agents consume them
→ produce more artifacts
→ the network keeps expanding
The Internet may therefore begin to expand not only through humans, but also through machines producing for other machines.
That is a much more radical shift than another version of the web.
The Internet May No Longer Be Human-First
One possible consequence is that an increasing part of the Internet will be built primarily for machines to use.
We may increasingly see services without a meaningful graphical interface, APIs designed for agents, capability discovery systems, machine-to-machine identity, autonomous payments, documentation optimized for models, and infrastructure created primarily for other agentic software.
A huge amount of digital activity could happen without a human ever directly visiting the service involved.
The human defines the objective.
The agents execute.
The Internet becomes the operating environment.
This means that the amount of activity on the network could grow much faster than the number of human users.
One billion people would no longer necessarily mean one billion actors.
It could mean billions of people setting vastly larger numbers of autonomous software processes into motion.
This is where the future becomes difficult to understand using our current categories.
The Real Problem Will Not Be Creation, but Governance
Much of the current discussion is still focused on present limitations.
We ask how to give agents better memory, how to make them program more effectively, how to coordinate them, how to improve browser use, and how to reduce errors.
These are real problems.
But they are also problems that the major labs are addressing at extraordinary speed.
Building a product around a temporary limitation means taking the risk that a month later the same capability will be integrated directly into the model or the harness.
The more interesting question is therefore different:
What problems will appear precisely because these systems succeed?
One of the largest may be control.
I am not talking about GDPR, a policy written in a document, or compliance in the traditional sense.
I am talking about operational control.
When millions or billions of agentic processes can act at machine speed, it will not be possible to place a human in front of every decision.
At the same time, it will not be enough to know who executed a certain action.
We will need to know:
- why the system believed that action was correct;
- what state of the world it was operating on;
- whether that state was still valid;
- which assumptions it was making;
- which other decisions depended on those assumptions;
- what the possible blast radius of an error was;
- whether the consequences could be revoked or reversed.
This is very different from traditional auditing.
It begins to resemble the need for an operating system for autonomy.
An Agent Should Not Have Direct Access to the World
A process does not directly access hardware. It goes through the operating system.
An application should not modify a database arbitrarily. It operates through permissions, transactions, and controls.
For the same reason, a future agent may not be allowed to act simply because it has decided that an action is correct.
A new layer may need to exist between the agent and the world.
AGENT
↓
PROPOSED ACTION
↓
CONTROL PLANE
├─ authority
├─ provenance
├─ context validity
├─ assumptions
├─ invariants
├─ falsification
├─ reversibility
└─ blast radius
↓
EXECUTION
↓
WORLD
↓
POST-CONDITION VERIFICATION
This layer should be able to evaluate the authority of the agent, the provenance of its information, the validity of the context, the assumptions it is operating on, the invariants that must not be violated, the reversibility of the action, and the possible impact if something goes wrong.
Only after this verification should the action be executed.
Immediately afterward, the system should verify that the real consequences correspond to the expected ones.
The goal would not be to prevent agents from acting.
It would be to make autonomy verifiable.
A New Form of Control
Today, much of our security infrastructure answers questions such as:
Who are you?
Do you have permission?
What role do you have?
Can you access this resource?
These are fundamental questions, but they may not be sufficient for agentic systems.
An agent may have the correct identity, every required permission, and no formal policy violation, yet still make the wrong decision because it is operating on an outdated or incomplete representation of the world.
The problem therefore becomes epistemic as well.
We do not only need to know whether the agent is allowed to act.
We need to know why it believes it should act.
A possible representation might include:
objective
known facts
├─ provenance
├─ freshness
└─ confidence
assumptions
unknowns
decision
evidence against
authorization
action
expected postconditions
observed postconditions
This would make it possible to construct a verifiable chain between observation, decision, action, and consequence.
Not simply:
Which agent called this API?
But:
What information led that agent to believe that calling this API was the correct decision?
These are two very different forms of control.
Control Will Have to Happen Before the Action
The speed of agents also makes purely retrospective auditing insufficient.
An agent may chain together a decision, an API call, a code modification, a deployment, and the involvement of another agent within seconds.
By the time someone checks the log, the entire chain may already have happened.
Control therefore has to become part of the operational path itself.
Before execution, the system could ask an independent verifier to search for contradictions, check whether the context has become stale, verify invariants, and attempt to falsify the proposed decision.
The question would not simply be:
Prove that you are right.
It would also be:
Try to prove that you are wrong before you act.
If this capability became infrastructural, we would be talking about something very different from conventional AI governance.
We would be talking about runtime governance of autonomy.
The Real Open Space May Be Here
Competing directly with OpenAI, Anthropic, Google, or other major labs on model capability is extremely difficult.
They have distribution, compute, capital, data, direct access to the foundational layer, and a development speed that makes any project built around one of their temporary limitations inherently fragile.
There is, however, another strategy.
Do not build something that gets replaced when they improve.
Build something that becomes more necessary precisely because they improve.
If agents become more capable, the need for control increases.
If they become more autonomous, the need for control increases.
If they maintain context for longer periods, the need for control increases.
If they receive more permissions, the need for control increases.
If they begin coordinating with one another, that need grows even further.
This is a fundamentally different kind of problem because it does not arise from the immaturity of these systems.
It arises from their success.
The Future Should Not Be Searched for in Today’s Limitations
Many AI projects are built around solving a current weakness of models.
Insufficient memory, retrieval, browser automation, code review, orchestration, context management, integrations.
The risk is that the problem does not actually represent a future market.
It may simply be a feature that the provider has not integrated yet.
In a field evolving this quickly, building around present limitations means continuously racing behind the major labs.
The opposite perspective is more interesting.
Do not ask:
What is missing from a coding agent today?
Ask instead:
If, a few years from now, these agents did almost perfectly everything we currently want from them, what new problems would be created precisely by that success?
That is where the infrastructural layers that do not yet exist may be found.
We Still Do Not Know What That World Will Look Like
The first industrial revolution made mechanical power abundant.
Computers made computation abundant.
The Internet made information distribution abundant.
Artificial intelligence may make something else abundant: the ability to transform an intention into a complex sequence of actions.
If that happens, it will not only change the work of programmers.
It will change the Internet.
It will change the meaning of software itself.
It will change who, or what, uses the network.
It will change the amount of digital activity that a single individual can generate.
And it will probably change what we mean by control.
Perhaps today we still look at agents as tools, but that description may not remain adequate for very long.
The Internet is slowly ceasing to be a network populated only by humans and passive software.
It is beginning to become an operating environment inhabited by general-purpose digital actors as well.
When that population truly begins to grow, the most important question may no longer be how intelligent these systems are.
The question may become much simpler, and much harder:
Who governs what they are allowed to do?
Top comments (2)
The distinction between production and understanding feels especially important for teams shipping AI-assisted systems. I’ve found a lightweight decision record with provenance, assumptions, and post-conditions does more for maintainability than another layer of prompt polish. It gives reviewers something concrete to challenge and gives the agent a bounded context to work within. The control-plane framing here is a useful way to connect governance with day-to-day engineering rather than treating it as a policy document.
Exactly and making the decision itself an inspectable artifact, rather than just the final output. Provenance, assumptions, and post-conditions already offer both humans and agents something far more stable than a long conversation history. But what happens when this pattern shifts from a "lightweight" engineering practice to the actual execution process where an action can be challenged or blocked before it is carried out? It is precisely at this point that "governance" begins to look less like policy and more like infrastructure.