The New Programming

The Introduction — An Opinion on the Future of Coding made a strong claim: the routine production of code is becoming a machine task, while the human task moves elsewhere. This chapter defines that move.

Traditional programming is about a human telling a machine how to perform a task. Machine coding is about a human organising machines to develop software.

That sentence is the distinction on which the rest of the book depends.

What programming assumed

For most of the history of software, the division of labour was fixed. The human understood the requirement, chose the algorithm and data structures, wrote the instructions in a programming language, and checked the result. The computer executed those instructions faithfully and quickly, but it did not decide what they should be.

Skill followed that boundary. A good programmer knew syntax, libraries, idioms, performance characteristics, and failure modes. Much of professional pride came from writing precise instructions with few defects.

The limitation was also clear. Every behaviour of the system had to pass through a human mind in implementation detail. If the requirement was vague, the programmer resolved it while writing code, often implicitly. If the system was large, no single person could hold all of it, so teams divided the code into parts and hoped the parts would fit together.

Tools improved this process without changing it. Better languages, better editors, better compilers, better tests, and better version control all helped humans produce instructions more reliably. The human remained the programmer.

A new participant

That boundary has now moved. A machine can read an existing repository, propose a change across several files, run the tests, examine the failure, revise the change, and present the outcome for review. It can do this at a scale and speed no human typist can match.

This is not a faster way of typing. It is a new participant in development.

The computer is no longer merely executing the programmer’s instructions. It is increasingly producing those instructions.

That does not mean the machine understands the product, the user, or the responsibility in the way a careful engineer does. It means the scarce resource has changed. Producing plausible code is cheap. Deciding what the code should do, whether it does it, and whether it is safe to accept remain difficult.

Central idea: the machine increasingly writes the instructions. The human increasingly defines the behaviour, organises the work, and judges the result.

Generating code is not developing software

It is easy to confuse a correct-looking change with a completed piece of engineering. Consider a small request: “reject expired credentials at login.”

A machine can produce the check in seconds. It may add a comparison in the login handler, write a test for an expired token, and report success when the test passes. All of that can be correct at the level of the edited lines and still be wrong as engineering.

The expiry may also need to be enforced in a refresh path, a remembered session, a migration for existing data, or a log message that currently records the credential. The new check may disagree with the documented policy. The test may cover the new branch without exercising the real login journey. None of these problems is visible in the diff alone.

This is why generating code is not the same as developing software. A change is only finished when its intended behaviour is stated, its effects on the existing system are understood, its tests examine the requirement rather than the implementation, its integration is verified, and its acceptance is recorded. Later chapters give each of those steps a name. The point here is that none of them happens automatically when code appears.

Success at one stage does not imply success at the next. Code can be generated without being correct, pass its tests without being integrated, be integrated without doing what the user needed, and do what was asked without being what was wanted. We do not claim to know how often each breakdown occurs. The structure matters more than the frequency: every stage needs its own check.

A different division of labour

Machine coding therefore reorganises the work rather than removing it.

In traditional programming, the human carried both the intention and the implementation. The human decided what was wanted and also wrote the lines that did it.

In machine coding, the machine takes a growing share of implementation: finding relevant files, drafting the change, running commands, and repairing simple failures. The human takes a growing share of direction and judgement: expressing the intended behaviour, setting constraints, providing the system context the machine needs, deciding what evidence counts as done, and remaining responsible for acceptance.

This is not abdication. Delegating implementation without delegating authority is the pattern. The machine may propose, but consequential actions — changing stored data, granting access, publishing a release, removing history — still require an explicit human decision and a reversible path back. We return to that boundary in the chapters on authority and evidence.

Nor does this remove the need for engineers to read code. It changes the purpose of reading. Instead of inspecting every line before it exists, the engineer samples, probes, and tests where the risk is highest, and relies on independent checks elsewhere. Judgement moves from production to supervision.

Why this needs its own name

Terms such as autocomplete, pair programming, and agentic coding describe useful interactions, but they do not describe a method. Asking a machine for code, accepting the result, and moving on can work for an isolated snippet. It does not reliably change a repository, preserve behaviour, or leave a trace that another engineer — human or machine — can use next month.

Machine coding, as used in this book, means a repeatable way of organising that larger task: bounded work packages, explicit system context, plans that can be reviewed before execution, tests and independent review before acceptance, verified integration rather than local passing tests, and retained experience that informs later work.

The difference is practical. A prompt disappears after use. A work package, a recorded decision, a review finding, and an acceptance record remain. They can be inspected, corrected, and reused. Without them, every task starts from zero and every defect is a surprise.

We do not claim this is the only way to work, nor that the method is finished. Our experience building a real system this way changed the method several times, and later chapters describe where it failed. What we claim is narrower: once the machine can produce code, the engineering problem becomes organisation, evaluation, and memory. That problem deserves its own name and its own discipline.

The loop, and where the evidence comes from

Stated as a practice rather than a definition, machine coding is a loop. Form an intention. Communicate it. Have machines implement it. Evaluate the result. Identify what is missing, wrong, or newly possible. Communicate the improvement. Repeat until the software meets its standard. One conversation rarely produces finished software; the loop does, provided each turn of it is directed and each result is judged.

Most of this book is about making that loop dependable. The early chapters prepare it: the foundations to build on, the intelligence to allocate, the intention to discover, the world the software must work within, the packages of work, and the machine that carries them out. Later chapters turn to judging the machine, keeping its history, and keeping control of what it produces.

The evidence comes mainly from one system. ALIVE is a persistent environment for doing real work with AI — a Python and PostgreSQL application in which the work, and what has been learned about it, survives across conversations, models, and restarts. It was built by machine coding, and its repository, review reports, and records are where this method was tested, broken, and revised. ALIVE appears throughout as evidence for the method, not as its subject; a reader building something entirely different should be able to use everything here. Where a whole system would be too much, a second example recurs: a small arcade game, used to illustrate single turns of the loop in a form any reader could try.

What comes next

The next chapter, The Foundation Charter, answers the first practical question: if the machine is going to do the coding, what should the human decide before the work begins. It argues for choosing dependable foundations the human understands well enough to supervise.