The question sounds provocative: if artificial intelligence can build an application from a natural-language description, do we still need programmers?

The debate gained new momentum around Andrej Karpathy, who popularized the term vibe coding, and the explosive growth of companies trying to make software creation accessible even to people who never learned to program.

One of the most visible examples is Replit. In March 2026 the company announced a $400 million funding round at a $9 billion valuation, three times its valuation just six months earlier. Its vision is simple to explain and enormous in its implications: let a person describe what they want to build and have the system handle much of the code, infrastructure, and deployment.

But reducing all of this to “AI will replace programmers” misses the most interesting part of the story.

The real shift appears to be different:

AI is reducing the need for humans to manually write every line of code, but it is not eliminating the need for engineering.

From writing code to describing outcomes

For decades, the basic software-development flow looked something like this:

idea
→ design
→ programmer writes code
→ compile
→ test
→ fix
→ deploy

AI autocomplete tools changed one part of the process:

programmer writes
→ AI completes fragments
→ programmer reviews

Vibe coding pushed the abstraction much further.

In February 2025, Karpathy used the term to describe a way of programming where a person explains what they want, lets the model produce the code, and continues iterating mainly through conversation.

The flow looks more like this:

human
→ prompt
→ AI generates code
→ human tests result
→ new prompt
→ AI modifies system

For prototypes, small projects, and experiments, this can be extraordinarily powerful.

A person who does not know JavaScript, Python, databases, or deployment can go much further than they could only a few years ago.

That is a real democratization of the ability to build software.

But vibe coding is not the same as professional engineering

The problem appears when the application stops being a demo and starts handling money, customer data, business operations, or critical infrastructure.

Then questions reappear that no prompt can simply ignore:

  • What happens when a dependency fails?
  • How are secrets and credentials protected?
  • How are data migrations performed without losing information?
  • What happens with concurrent operations?
  • What guarantees does the system provide?
  • How do we know a change did not break something that worked yesterday?
  • Who decides whether a solution is safe enough for production?

That is why Karpathy began distinguishing vibe coding from a more rigorous practice he calls agentic engineering.

The idea is no longer simply “let AI program.”

It is closer to:

human defines objective
→ agent analyzes repository
→ agent modifies code
→ agent runs tests
→ detects errors
→ fixes them
→ tests again
→ prepares change
→ another process reviews
→ QA validates

The person remains responsible for the outcome but stops participating in every microscopic operation.

Code stops being the center of human work

In that model, a skill such as memorizing syntax loses some of its relative value.

That does not mean understanding code stops mattering. It means other capabilities become proportionally more important:

specify correctly
→ design architecture
→ define invariants
→ create acceptance criteria
→ evaluate results
→ detect failures
→ manage context
→ decide when to trust
→ decide when to intervene

This looks more like directing a production system than manually writing every piece.

The engineer moves from being primarily the author of the code to also becoming the director, supervisor, and verifier of agents that produce code.

So do programmers disappear?

The word programmer will probably begin to cover increasingly different kinds of work.

One possible evolution is:

2015
programmer
→ writes code

2023
programmer + copilot
→ writes and accepts suggestions

2025
vibe coder
→ describes software and tests outcomes

2026
agentic engineer
→ directs agents that implement, test, and fix

next stage
human
→ defines specifications, constraints, and criteria
→ multiple agents build and verify the system

The result is not necessarily “zero programmers.”

It may be far more software produced by each person.

That has important economic consequences.

If a project once required a large team to produce a certain amount of functionality, a small group of very capable engineers coordinating agents may be able to produce much more.

At the same time, people who were previously completely outside software development can create applications themselves.

Pressure comes from both directions:

more people can build software
+
each engineer can build much more

Replit is a $9 billion bet on that transition

Replit’s valuation matters less as an isolated number than as a market signal.

Investors are betting that software creation can expand far beyond the traditional developer population.

Replit describes a vision in which teachers, entrepreneurs, students, designers, and workers in other industries can turn ideas into applications without mastering all the technical machinery underneath.

That does not mean the machinery disappears.

It means it becomes encapsulated behind higher-level agents and tools.

Something similar has happened repeatedly in computing history.

Programmers stopped managing processor registers directly and moved to higher-level languages. Later, they stopped manually operating much of their infrastructure and adopted clouds and managed platforms.

Now we may be entering another abstraction layer:

before:
human → programming language → computer

now:
human → agent → programming language → tools → infrastructure

The hard part moves

When generating code becomes cheap, other things become the bottleneck.

For example:

Specification. If the objective is poorly defined, the agent can produce enormous amounts of perfectly useless code.

Verification. If nobody knows how to prove that the result is correct, producing it faster does not solve the problem.

Architecture. Agents can implement decisions, but a bad boundary between components can multiply complexity for years.

Security. A functional application is not necessarily a secure application.

Context. An agent that does not know the system’s historical constraints can introduce changes that are technically reasonable but incompatible with the product.

Accountability. Someone has to decide when a change is allowed into production.

Engineering does not disappear. It moves up the abstraction stack.

From programming software to designing software factories

Perhaps the deepest transformation is not that AI writes code.

It is that we are beginning to build systems that produce software.

A mature flow can include different agents or specialized roles:

Specifier
→ defines what must exist

Architect
→ decides structures and boundaries when needed

Developer
→ implements

Reviewer
→ looks for defects and deviations

QA
→ proves the outcome satisfies the criteria

In that world, the human’s primary intellectual product no longer has to be every .py, .ts, or .cs file.

It can be the combination of:

specifications
+ invariants
+ tests
+ policies
+ tools
+ quality gates
+ project memory

In other words: the factory that produces and validates the code.

The right question

So perhaps we should stop asking only:

Will AI replace programmers?

And start asking:

Which parts of engineering work will remain a human responsibility when writing code becomes a mostly delegable task?

The answer is still evolving.

But the direction is becoming clear.

We will need less human work devoted exclusively to translating known instructions into lines of code, and more human capacity devoted to defining what to build, setting constraints, verifying outcomes, and directing systems capable of building for us.

Vibe coding was an early signal.

Agentic engineering may be the discipline that turns that signal into a new way of producing software.

Sources and reading