Key takeaways

Code is no longer the scarce input. Product cost used to track hours spent typing and tending lines. A first cut of a module now often appears in tens of minutes. What stays rare is a precise problem statement, context, quality, and a person who will sign the release.

Writing code and shipping a working system are different jobs. A model will generate an API endpoint, a class, a component, a SQL query. An engineer still has to decide why it should exist, where it fails under load, what happens in an outage, and how it will be operated years later.

Strong people get stronger; the on-ramp gets harder. Someone who can judge and steer output can, with AI, cover work that used to need a small team. The simple tasks juniors used to learn on are the first to be automated.

Prompt craft is a skill, not a career. Good results come from decomposition, domain knowledge, review, and tests. Clever instructions without engineering judgment yield a pretty draft, not a durable product.

In five to ten years the role boundaries blur. Developer, architect, and tech lead increasingly sit in one person who sets goals and constraints while agents write code, run checks, and absorb routine. Pay follows what should be built and why, not the size of the diff.

What changed in a programmer’s job, 2023–2026

Before assistants went mainstream, a typical day looked like this: open a ticket, write a function, run tests, patch edge cases, add docs, open a merge request. Speed was bounded by typing, hunting through documentation, and keeping context in your head. “Being a programmer” almost meant “being able to write code by hand.”

Then, in a short window, completion at GitHub Copilot quality, chat with ChatGPT and Claude, and agent modes in Cursor and similar tools landed in daily work. A model no longer only suggests the next line. It edits several files, sketches a service, writes tests from an example, explains someone else’s module. 2023–2026 were a break not because “neural nets appeared,” but because code generation entered the everyday pipeline of millions of developers instead of staying a conference demo.

That is why this essay exists. If AI can write code, why do we still need programmers? The short answer: a software product is not a pile of functions. The long answer is below. I already wrote the sibling frame — where generation stops and engineering starts — in where code generation ends and engineering begins. This piece is about the profession: who stays hireable, how the career ladder breaks, and what to study when lines of code are no longer scarce.

A maturity map of AI by domain shows the same shift from another angle: programming is one of the most mature applications, but mature generation is not the same as mature autonomous product development. See the AI maturity map.

How much of the work AI already takes

The wrong question is “can AI write code?” It can. The useful question is: what share of the work of building a software product can you now hand to a model, if a human who can check the result is in the loop.

On typical tasks the share is already high. Functions and classes from a description. A CRUD skeleton: models, routes, forms, basic checks. A client for an external API from its docs. SQL and draft migrations. Unit tests against existing code. Mechanical renames and extracting duplication. Module documentation. Finding obvious bugs from a stack trace. A first-pass UI. A Dockerfile, a CI template, an explanation of an unfamiliar fragment, a commit message, a whole-app prototype in an evening.

This is not a “ten years from now” story. In 2026 it happens in an ordinary editor — when the task is local, the pattern is well known, and a mistake does not stop the business. How the IDE pipeline works under the hood is in how AI IDEs work with code.

What that list does not include: deciding which service should exist; choosing module boundaries that must last years; knowing why a “weird” legacy rule cannot be touched before month-end close; judging whether a generated patch is safe; owning the case where optimized SQL is technically faster and still violates a business constraint.

Four short plots I keep seeing.

First: the model assembles a CRUD app in hours. The demo looks like a product. A month later there is no migration strategy, secrets live in the repo, and a “temporary” flag already drives a calculation.

Second: an agent fixes a bug and picks the wrong architecture — duplicates an entity, hides a rule in the client, bypasses a database constraint “for now.” Tests are green. Six months later the change costs an order of magnitude more. That is why review after an agent patch is not ceremony. It is the new bottleneck.

Third: the model rewrites SQL, cuts query time, and does not know that a closed-month report must count differently from the live screen. The optimization is technically correct and domain-dangerous.

Fourth: a prototype in a few hours. That is a real win — if the team remembers to throw it away or deliberately turn it into a system.

When code becomes cheap

Software used to be expensive largely because human labor was: write, debug, maintain. More lines and integrations meant a more expensive team. The scarce resource was the typing itself.

Now a first version of a task that used to take days often appears in tens of minutes. A human reviews, corrects, and integrates. The loop “type → see → fix” shrinks. Code as raw material cheapens the way text cheapened after word processors: writing is easier; thinking is not.

If producing lines gets cheap, the lines stop being the scarce resource. What becomes scarce is problem framing, architecture, context (why the system is shaped this way), quality, accountability, business understanding, and the ability to choose when no option is clean.

That is harsh if your career was “I close tickets that say add an endpoint.” It is good news if you already lived on the design side. Companies do not pay for characters in an editor. They pay for predictability and lower risk. When generation speeds up the bricklaying, a wrong foundation gets poured in a day instead of a week — and still has to be ripped out.

Why a good engineer is not replaced yet

The gap between “write code” and “create a working system” is not a speech about the word engineering. It is a horizon of consequences.

A model can emit an API endpoint, a class, a component, a SQL query. That is execution of a known pattern. A system appears when someone answers different questions. Why this belongs in the product, not only in the demo. Whether it is correct across a document’s life cycle, not only in a unit test. What the constraints are: load, regulation, a four-person team, fifteen years of legacy. How it behaves at peak. What happens when a neighbor service fails. How safe it is: secrets, permissions, injection, data leaking through a model prompt. How it will be maintained in three years when the authors of the agent patch have left.

AI is not “stupid” on these questions. It does not carry responsibility and it was not in the meeting where people agreed not to touch a table until period close. Even a strong model fills gaps from public-repo patterns. In an enterprise those patterns often lie: a “correct” REST design can break a bank contract or a regulator report. Legacy work shows this the hard way: AI on a 15-year-old project.

You do not hire an engineer to race a model at CRUD speed. You hire them to set a frame in which generation is safe, and to stop a patch that “works” while building the wrong system.

A new hierarchy: from coder to product engineer

Junior / middle / senior labels will not vanish from job posts, but they describe what you pay for worse than they used to. Four levels of value are more useful — not as HR grades, but as what remains scarce when code gets cheap.

Coder. Value is lines from a finished spec. This is the layer models cover best: typical CRUD, layout from a mock, obvious tests, template backend code. If your whole expertise is “I write framework X quickly,” the market will offer fewer roles and lower rates.

AI-assisted developer. Can split a task, give the model enough context, read the diff, fix a miss, and land the result without breaking neighbors. This is not “chat operator”: without reading code and a basic feel for runtime you cannot tell a working patch from a plausible one. Outlook is good — if the skill does not stop at “I know how to ask for generation.”

Software engineer. Designs boundaries, lives with constraints, understands system trade-offs, finds causes of odd failures, owns quality. AI is an execution accelerator, not a substitute for thinking. This level was valuable before assistants; after them it is more visible, because the background of coders automates faster.

Product and systems engineer. Holds technology, product, business, users, architecture, and AI tools at once. Rare, and this is the combination agents amplify most: one such person can cover a loop that used to need a small team of specialists. This is not “everyone must become a product manager.” It is the requirement to understand why the system exists, not only how a module is wired.

The ladder is deliberately crude. In a real day you jump between levels. The point is an honest answer: if typing typical code gets another 2× cheaper tomorrow, what part of my work stays scarce?

The paradox: the strong get stronger, juniors sit in the blast radius

Before assistants, a strong developer might write a few hundred lines of careful code in a day, holding the module’s invariants in their head. With AI they can assign a module, tests, migrations, a documentation draft, mechanical refactoring. They still judge the result: does the patch match intent, did architecture drift, were assertions weakened so the pipeline would go green.

That yields a formula more useful than any “+55% productivity” slide:

A good engineer + AI ≫ a good engineer without AI.

AI raises the output of people who can evaluate and steer. For someone who cannot tell a correct design from a plausible one, the model mainly helps manufacture mistakes faster. Agentic engineering says the same thing at process level: value is not agent autonomy, it is the verification loop. See agentic engineering.

The sharp edge of the paradox is the junior.

The old ladder was simple: junior → middle → senior. Newcomers got simple work — CRUD, mock-driven UI, tests by example — and on that work they learned to read other people’s code, fail cheaply, and grow taste. That layer is the first to automate.

The industry has not closed the question: how do you get experience if AI already does the work juniors used to learn on?

Effects are visible even if labor-market stats are noisy. Entering the profession is harder: employers are less willing to pay for “a person who types what the model types faster.” Juniors are asked to be more independent earlier — to understand the system, not only the syntax. Learning shifts from typing to reading, debugging, constraints, domain. AI is both a competitor for starter roles and the best personal tutor a newcomer has ever had: any fragment can be explained, any exercise generated. Used as a gym, it accelerates growth. Used as a substitute for thinking, it stalls it.

This is not an argument that juniors are unnecessary. Systems still need people who will be third- and fourth-level engineers in five years. The path no longer looks like “two years of simple tickets.” A practical compass for the newcomer is the junior-to-senior path: fundamentals and reading code beat chasing the next framework.

What to study in 2026

A list like “React, Python, Java, Go, SQL” did not become useless. It became insufficient. Language and framework still matter so you can read a diff and understand runtime. Competitive advantage moves into foundations: algorithms and data structures, databases, networks, operating systems, concurrency, distributed systems, architecture, security, testing, debugging, profiling, Git, how a program behaves while it runs.

Why do foundations beat the slogan “prompts are the real skill”? Because a model emits plausible code. To see why it is bad you have to see the system: queries in a loop, a race, a leaked connection, the wrong isolation level, a permission hole, a test that asserts the implementation instead of the intent.

Six rules that I treat as working practice in 2026.

Study the foundations; do not become a chat operator. Without a feel for runtime you will not tell acceleration from quiet architectural rot.

Use AI from day one. Racing a model at template code is a losing game. Racing it at framing and verification is not.

Learn to read code. In the next years, judging other people’s (and generated) code will often be worth more than typing it fast. Review is the main gesture, not an optional ritual.

Learn to design. Service boundaries, API contracts, data models, a neighbor node dying, reversibility. Spec before code, not “generate first, think later”: spec-driven development.

Grow a domain. Finance, manufacturing, medicine, logistics, embedded. Domain is what generic model patterns do not contain and what costs the most in an incident.

Treat agents as a pipeline, not a magic chat window: goal, constraints, check, rollback. That is already process skill, not prompt skill.

Prompts are a skill, not a profession

A popular 2023–2024 idea: “the programmer’s main skill is now writing prompts.” There is a grain of truth and a dangerous overclaim.

The grain: wording changes whether you get a useful draft or three pages of confident hallucination. Narrowing the task, giving examples, stating constraints, attaching a code fragment — that is literacy, like writing a clear ticket.

The overclaim: a good result almost never follows from one clever instruction. It follows from context (repo, rules, schema), architectural judgment (what is even allowed to be generated here), decomposition (an agent needs a boundary, not “do the right thing”), verification, tests, and domain. Without those a “prompt engineer” produces attractive text that does not survive the first incident.

The useful conclusion is boring: prompt craft is a useful skill, not a substitute for engineering competence. Selling it as a new profession instead of systems thinking sells a finish coat without a load-bearing structure.

From writing code to directing agents

A realistic picture of the next years is not “AI ships the product alone.” It is a human who holds the goal and the constraints, and several agents with different jobs.

flowchart LR
  H[Engineer] --> A[Architecture]
  H --> B[Backend]
  H --> C[Frontend]
  H --> D[Quality checks]
  H --> E[Infrastructure]

The human sets the goal, states constraints, chooses architecture, makes decisions, checks the result. AI writes code, runs tests, reads traces, does routine, calls tools. That is already close to agent modes in an IDE — with a caveat: without a human verification loop, change volume grows faster than the team can digest it.

The engineer then looks more like a director than the only actor. They do not have to speak every line. They do have to know whether this is the right play and whether the set will fall on the audience. One strong specialist with a set of agents already covers a loop that yesterday needed a small team — on a prototype, an internal tool, a well-bounded module. On a regulated core the picture is humbler, and that is fine: accountability does not get cheaper at the same rate as generation.

Three market scenarios: who is exposed

Will there be fewer programmers? Three processes are plausible at once.

Optimistic. AI lowers the cost of building software → more software gets built → demand for engineers stays high, even as the work changes.

Headcount automation. Companies ship the same volume with fewer people. Especially where the product already exists and development is mostly typical change requests.

New market. Cheap software makes products viable that could not pay for a team before. Internal tools, narrow industry systems, personal agents around a process — a layer that did not exist when code was expensive.

The likely path is all three at once, in different companies and even in different teams of one company. Arguing which scenario “wins” is less useful than asking whose work is algorithmizable.

Most exposed are specialists whose daily value is typical CRUD, simple integrations, layout from a finished mock, template backend code, mechanical refactoring, obvious tests, and well-specified tickets with no ambiguity. The risk test: how easily the work decomposes into an algorithm, and how easily the result can be checked automatically. The closer a task is to “there is a spec and green tests = done,” the harder automation presses.

More valuable are people who design complex systems, work under uncertainty, make architectural calls, understand the business, read legacy, find causes of unusual failures, tune performance, own security, stitch many systems together, and can direct agents rather than only invoke them.

Historical analogies help as analogies, not as a guarantee. Calculators did not erase mathematicians — they moved work off arithmetic onto formulation. CAD did not erase design engineers. Photoshop did not erase designers. Compilers did not erase programmers, even though “writing machine code” stopped being a mass skill. Web search did not erase research — it erased the value of “I remember which manual page that was on.” Autopilot did not empty the cockpit where the cost of error is maximal. Automating operations changes the level a specialist works at. It does not have to kill the profession — but it does kill the layer that consisted only of those operations.

A five-to-ten-year forecast

With high probability, AI becomes as standard in development as Git or continuous integration once did. Hand-typing typical code declines. Small teams ship noticeably more. The share of generated code in repositories rises — and so do demands on architecture, review, and observability, or the patch stream will drown the product. Entry-level gets harder. Senior engineers get more productive. The line between developer, architect, and tech lead blurs: those roles already overlapped; agents only increase the overlap.

A possible, no longer science-fiction case: one strong engineer with a set of agents does the work of a small team — not “any team in a bank,” but a team whose product fits inside checkable boundaries. Critical loops will still need several people with different kinds of accountability. The economic unit “a square developer who closes tickets” will weaken.

The central paradox of the next decade is short:

The better AI becomes at programming, the less the skill of writing code is worth — and the more it is worth to understand what should be built and why.

How this Lab looks at systems is in a short Chemistry of Code intro. One method line is enough here: an accelerator (an agent) does not cancel the cost of failure; it makes assembly cheap and a wrong invariant expensive.

FAQ

Further reading

• Where code generation ends and engineering begins — product versus lines
• How far has AI come — mature generation is not a mature profession
• Code review in the AI era — what to check after an agent patch
• How IDEs work with code — the assistant pipeline in the editor
• Agentic engineering — process around agents, not “vibe”
• AI on a 15-year-old project — where a model helps you understand a system
• Spec-driven development — intent before code

Conclusion

The programming profession is not dying. What is dying is the idea that a programmer is valuable mainly for how much code they personally typed.

A strong developer of the next decade holds understanding — of the product and of the system — and only then launches agents to execute.

                 UNDERSTANDING
                     │
          ┌──────────┴──────────┐
          │                     │
        PRODUCT              SYSTEM
          │                     │
          └──────────┬──────────┘
                     │
                ENGINEER
                     │
                  AI × AI × AI

The move from writing code to building systems may be the largest change in the profession in the history of software development. Code got cheap. Scarcity moved up: what to build, why, and who answers when the built thing meets reality.