Programming in 2027: when writing code stops being the job

There is a simple way to summarize much of the current AI-agent revolution:

the bottleneck is moving from code to intent.

For decades, turning an idea into software required a huge amount of intermediate work: choosing tools, writing functions, remembering APIs, debugging syntax, connecting libraries, reviewing pull requests and repeating the cycle until the system finally did what we wanted.

Current models are compressing a large part of that chain.

That shift sits behind the predictions Thorsten Ball published in September 2026 about the future of software development, later discussed in the Spanish-language video “Así Será Programar en 2027 (Esto Es Lo Que Se Viene)”.

Ball makes deliberately aggressive claims:

traditional code review will die;
writing code will stop being a central craft;
the terminal will lose importance as a human interface;
tokens will become a new form of computing capacity;
the separation between PM, design and engineering will shrink;
much of the UI may be generated on the fly;
many bugs will no longer be implementation errors, but specification errors.

Some of those ideas sound futuristic.

Others are already starting to look like descriptions of the present.

One clarification matters from the beginning: “2027” is the framing of the video, not a precise deadline set by Ball. In his original post, he explicitly says that part of this transition could take a generation and that people will still be paid to write code manually ten years from now.

The interesting question is therefore not whether every prediction becomes true next year.

It is this:

what changes in our profession when producing code is no longer the scarce part?

1. From code as the product to code as a byproduct

Until recently, software implementation was expensive.

A seemingly simple feature could consume days or weeks because teams had to:

understand the problem;
design the solution;
write the code;
integrate dependencies;
test;
debug;
review;
deploy.

AI does not eliminate all of those stages, but it dramatically lowers the cost of several of them.

An agent can open a repository, inspect its structure, implement a feature, run tests, interpret failures, modify multiple files and try again without the human writing a single line.

That changes the economics of the work.

When code was expensive to produce, code itself captured a large share of the value.

When code becomes abundant, value moves toward other questions:

what should we build?
for whom?
which constraints must never be violated?
what architecture will survive growth?
how do we know it works?
what new risks appear when it touches real systems?
how do we distribute the product?
how do we know anyone actually needs it?

Ball summarizes that shift by arguing that the craft of writing code may disappear while the craft of building software becomes more important than ever.

That distinction is fundamental.

AI can generate an impeccable implementation of a bad idea.

2. Code review does not vanish: it moves up a level

One of Ball’s most provocative predictions is that traditional code review is already dead.

The logic is easy to understand.

If one agent produces 300 changes in seconds and one developer coordinates five agents in parallel, asking another human to carefully inspect every line simply does not scale.

The volume exceeds human inspection capacity.

But that does not mean review disappears.

It means review moves up a level.

Instead of asking:

Is this variable name good?

review can focus on questions such as:

does the feature do what the product needs?
does it violate an important system property?
does it introduce a new security surface?
does it respect data and permission boundaries?
what happens during partial failure?
is the migration reversible?
do metrics confirm the expected behavior?
did the agent understand the task correctly?

The unit of review is no longer necessarily the line of code.

It can become the system, its behavior and the evidence supporting it.

That also means tests, evals, observability, invariants and test environments may become more important, even if some forms of routine manual testing decline.

The future does not look like “less verification.”

It looks like verification at a different scale.

3. The new bug: “you asked for the wrong thing”

This may be the most important idea in Ball’s post.

When a model can correctly implement a specification, many failures stop looking like:

the programmer wrote the code incorrectly.

and start looking like:

nobody specified the important case.

Imagine a booking platform.

We tell an agent:

Build a website where users can reserve hotel rooms.

The agent implements it.

The interface works.

The database works.

Payments work.

But two users can reserve the last room at the same time because nobody considered concurrency.

Is that a programming bug?

Strictly speaking, the software may be doing exactly what it was asked to do.

The mistake happened before the code.

The domain was not modeled deeply enough.

A crucial property was never stated:

one room cannot be confirmed for two incompatible reservations.

That kind of failure increases the value of skills that used to look secondary next to implementation:

specification;
systems thinking;
domain modeling;
identifying invariants;
adversarial scenario design;
risk analysis;
deep business understanding.

Paradoxically, the better AI becomes at coding, the more visible our inability to express what we actually want becomes.

4. The terminal may die as an interface, not as infrastructure

Ball also says the terminal is dead.

Taken literally, that is probably an exaggeration.

Shells, CLIs, APIs, databases and traditional tools will continue to exist because agents still need deterministic mechanisms to act on systems.

What may disappear is the requirement for humans to learn every interface directly.

Before:

human → SQL
human → git
human → bash
human → kubectl
human → API

Each tool required us to learn its language.

With agents:

human → natural-language intent → agent → tools

The terminal stops being the primary interface.

Not because bash disappears, but because the agent becomes a translation layer.

You can ask:

Show me the twenty most recent users who failed onboarding and group them by cause.

The agent can decide whether it needs SQL, logs, a script or several APIs.

Machines still speak formal languages.

Humans simply stop having to speak all of them all the time.

5. Tokens as a new production resource

Another of Ball’s most interesting predictions is economic:

tokens become the new computing paradigm.

His analogy is the early personal-computer era.

There was a time when the ability to produce software depended partly on access to expensive hardware.

In an agent-driven world, the constraint can shift toward a different question:

how much inference can you afford or run?

A team with access to better models, larger contexts and millions of tokens can apply far more “artificial cognitive capacity” to a problem.

That introduces a new variable into software projects.

We traditionally measured:

engineering hours;
number of developers;
servers;
storage;
bandwidth.

We may increasingly measure:

tokens per task;
cost per agent;
iterations per feature;
inference spent on validation;
parallel agent capacity.

That does not mean tokens replace all traditional computing.

Nor does it mean access must stay concentrated forever: open models, local hardware and efficiency improvements push in the opposite direction.

But a new form of productive capital is clearly emerging:

reasoning capacity on demand.

6. Smaller teams, but not automatic companies

The video takes Ball’s predictions toward an organizational consequence: teams capable of producing far more with far fewer people.

That is plausible.

If one person can coordinate several agents, a product vertical may need fewer humans to:

prototype;
implement;
design;
document;
analyze data;
automate operations.

But we should not jump too quickly from smaller engineering teams to effortless businesses.

Building software is not the same as building a company.

Even when implementation becomes cheap, hard problems remain:

distribution;
trust;
brand;
customer acquisition;
sales;
support;
compliance;
regulation;
relationships;
market knowledge.

If anyone can reproduce a feature, competitive advantage may move toward precisely the things that cannot be cloned with a prompt.

That can strongly benefit small teams and indie developers, but it does not turn every generated application into a viable business.

7. Does the PM + design + engineering triad disappear?

Ball argues that the traditional separation between product management, design and engineering will lose meaning.

It may be more accurate to speak about role compression than outright disappearance.

A product-minded person can ask agents for prototypes, evaluate alternatives and produce an initial implementation.

An engineer can explore UX flows without waiting days for a mockup.

A designer can build functional prototypes.

Operational boundaries become more porous.

But different forms of judgment still exist:

product vision;
visual taste and coherence;
architecture;
security;
domain knowledge;
user research.

AI reduces the cost of execution.

It does not guarantee good judgment.

The valuable professional may therefore look less like “a specialist who produces one artifact” and more like someone who can make complete end-to-end decisions.

8. On-the-fly UI and personalized software

The prediction closest to science fiction is that models become fast enough for parts of the interface to be generated in real time.

Many UI elements exist because traditional software cannot understand user intent.

We need:

menus;
filters;
dashboards;
forms;
settings screens.

They are a kind of visual API for humans.

If a system understands what we want directly, it can generate the right interaction for the current situation.

Instead of hunting for a hidden filter, we could simply say:

show me only high-risk customers whose usage dropped this week.

The system could generate a temporary view for that request.

The idea becomes even more radical when software generation becomes cheap enough: applications personalized for individuals or for each customer.

Not one app for a million users.

Potentially a million variants of an app.

9. What this vision underestimates

Ball’s thesis is useful precisely because it pushes the argument to extremes.

But there are good reasons to remain skeptical.

Models still make mistakes

Even as they improve quickly, we still see:

hallucinations;
context failures;
silent errors;
bad assumptions;
security vulnerabilities;
regressions;
outputs that look correct without being correct.

Automation increases production speed, but it can also increase the speed at which mistakes propagate.

Responsibility cannot be delegated to a token

When software moves money, handles sensitive data or touches real infrastructure, someone still has to be accountable for its decisions.

Legacy software will not disappear quickly

Governments, banks and large corporations operate systems that live for decades.

The technology frontier changes faster than institutional adoption.

Judgment remains scarce

An agent can generate ten solutions.

Knowing which one is correct still requires understanding.

That may become the real bottleneck.

10. The new hierarchy of skills

If this transition continues, developers do not become irrelevant.

They become different.

Skills that may gain value include:

1. Specifying

Turning an ambiguous intention into clear, testable conditions.

2. Designing systems

Understanding dependencies, data, failures, permissions, concurrency, security and architecture.

3. Verifying

Building evals, tests, invariants, observability and feedback loops.

4. Coordinating agents

Decomposing a problem, parallelizing work, managing context and knowing when to escalate.

5. Understanding product and business

Knowing why a feature exists and what outcome it is supposed to create.

6. Maintaining technical judgment

You may not need to memorize every CLI flag, but you still need enough understanding to notice when an agent’s decision is dangerous or absurd.

The great paradox of AI-assisted programming is that writing less code may require understanding more systems.

11. The real change: moving up one abstraction layer

The history of software is partly the history of abandoning details that used to be mandatory.

We moved from:

voltages
→ machine code
→ assembly
→ high-level languages
→ frameworks
→ cloud services
→ agents

Each jump made some previously essential knowledge less relevant to everyday work.

But engineering did not disappear.

It moved to a higher level.

That appears to be happening again.

The developer interface is shifting from:

write this implementation

toward:

define the result, the constraints and the evidence that proves it works.

That may be the best way to understand the future described by Thorsten Ball and the video.

It is not a future without programmers.

It is a future in which programming no longer necessarily means writing code.