The Division of Intent and Implementation

In 1951, Grace Hopper wrote the first compiler.

Before her, programming was done in machine language. Humans translated instructions into binary, and binary was punched onto cards. Writing a program was writing the machine. There was no distance between code and hardware.

The compiler changed everything. The programmer no longer wrote machine instructions. She wrote "x + y." The compiler transformed that symbol into register loads, addition operations, result stores. The programmer did not need to know how many registers the CPU had. She did not even need to know which CPU she was running on.

This split — from machine language to high-level language — was the birth moment of software engineering as an independent discipline. Before it, software was not a discipline. It was an accessory to hardware. After it, a software engineer could go an entire career without reading a chip manual. She worked at the abstraction layer, and the compiler bridged downward.

Now, the second split has begun.

This time, what is being abstracted away is not the machine. It is implementation itself.

You are not writing "x + y." You are saying "sort this list," and AI generates the sorting implementation. You are not calling fetch(). You are saying "get data from this API, retry three times on failure, if all three fail log the error and return a default empty list," and AI generates the complete async error-handling logic.

The first split: you needed to understand algorithms, but you no longer needed to understand register allocation. The second split: you need to understand what you want, but you no longer need to know how to express it in code.

This change is not "programming got easier." It is that the core activity of software engineering — implementation — is losing its scarcity.

What does the loss of scarcity mean?

In economics, when a resource shifts from scarce to abundant, its price collapses, and the entire industrial structure built around it begins to reorganize.

The core of software engineering for fifty years — implementing requirements in code — is precisely this kind of resource now becoming abundant. Implementation capability — the ability to write code, modify code, refactor code — has gone from a scarce skill for which you paid high salaries, to a compute pairing you can obtain nearly for free.

This is not saying programmers will be unemployed. It is saying implementation is no longer the core bottleneck of engineering.

The bottleneck of the 1980s was hardware. CPUs were too slow, memory was too small. The 1990s bottleneck was operating systems and networking: how to make different machines talk. The 2000s bottleneck was scale: how to serve a million concurrent users. The 2010s bottleneck was data: how to store, process, and learn from massive information. Each era's bottleneck defined that era's engineering.

From the 2020s onward, the bottleneck is intent. Not "can you implement," but "what do you want," and "how do you know that what you wanted is the same as what was actually implemented."

When implementation is abstracted away, what is not abstracted away?

The first is requirements. You still need to know what you want. AI can help you refine requirements, but it cannot decide direction for you. You must, from vague and sometimes contradictory ideas, extract the one thread that truly matters.

The second is specification. Your requirements, as they become prompts, must be translated into verifiable expectations. Not "make search good," but "when the user types pinyin initials, return full-name matches sorted by relevance, with the most likely match first, no more than five results." In the AI era, a prompt is a degenerate form of specification. It is imprecise, but it is already specification, because it defines a boundary: AI's output must fall within this boundary, not outside it.

The third is verification. When code is not written by a human, the object of review changes. You are no longer reviewing "is the reasoning sound." You are reviewing "does the behavior match expectations." Testing — especially automated testing — shifts from safety net to the only anchor. In a sea of probability, passing or failing a test is the only deterministic event. Code review shifts from reading code to reading behavior.

What form will specification take in the AI era?

Traditional specification has three forms: natural-language requirements documents (vague, complete); formal proofs (precise, extremely slow, inapplicable to most systems); tests (incomplete, but within their coverage, absolutely precise).

AI adds a dimension to each of these three.

Natural language prompts: vague, but can be iterated rapidly. You write a prompt today. AI gives you output. You read it and realize "that's not it." You modify the prompt, try again. This is specification by gradient descent. You do not need to get it right the first time. You can converge to the right specification through a feedback loop.

Formal methods, with AI assistance, may become practical for the first time. Not writing a complete Coq proof, but having AI automatically generate the invariants this function must satisfy from your described behavioral constraints, then auto-check them. The cost of formal verification, once prohibitive, is being compressed by AI into viable territory.

Tests shift from verifying implementation to defining intent. Previously, you wrote the code first, then wrote tests to verify it. Now, you can write the tests first, then let AI generate the code that satisfies them. Tests are no longer merely checks. They are the target. They are the most precise form of specification you give to AI: what you generate must pass this set of tests. This shift — tests elevated from verification to definition — may be one of the most important methodological changes in the AI era of engineering.

So what are the core capabilities of a software engineer in the AI era?

The first capability: judgment. Can you tell whether what AI generated is usable without reading it line by line? Can you, in seconds, determine "is this right or wrong" for code you did not write? This capability, seemingly basic, may be the hardest step for junior engineers who have never independently verified code someone else wrote.

The second capability: decomposition. You have a vague requirement. You split it into what AI can do and what you must do yourself. Architectural decisions, for now, should not be made by AI. Because the cost of a wrong architecture is not writing it wrong — it is being unable to change it. A bad architecture, even if all the code is written by AI, will still prevent you from adding new features three months later.

The third capability: expression. Translating vague intent into verifiable specifications that AI can execute. Not prompt engineering tricks, but the translational skill of converting "what I want" into "what would count as correct from AI." This is the new fundamental, as foundational as knowing C was for engineers in the 1990s.

The first split — Hopper's compiler — separated software engineering from electrical engineering. Software engineers no longer needed to know hardware, but they needed to know algorithms, data structures, operating systems.

The second split — AI — is separating implementation from software engineering. The new generation of software engineers no longer need to know implementation, but they need to know intent. They need to be able to decompose, to express, to judge.

Implementation was never truly respected. It was the heaviest part of engineering: the most time-consuming, the most undervalued, simultaneously seen as the core of engineering and the thing most desired to be eliminated. The first split: you were still implementing, just not in assembly. The second split: you no longer implement directly. You define intent at a higher abstraction, and let AI search and sample implementation.

This is not the end of software engineering. This is software engineering, for the first time since it separated from electrical engineering in 1951, redefining the boundaries of its own discipline.