A New Approach to Technology

The previous chapters built a method: foundations, configured intelligence, discovered intent, an understood world, bounded work packages, an equipped machine. This chapter steps back and asks what all of that means. I believe something larger than a workflow is happening — a change in humanity’s relationship with technology itself — and machine coding is one early instance of it.

The purpose of machine coding is not to make the programmer perform more operations. It is to make more of those operations unnecessary for the programmer.

The Mountain of Clay

Imagine a mountain of clay that must be moved. One person works with bare hands: honest effort, strictly limited capacity. A second brings a shovel and a wheelbarrow — the same human strength, multiplied through levers, containers, and wheels. A third operates a massive excavator, and what took the first two weeks takes an afternoon.

The goal never changed. What changed was the technology between the intention and the result — and with it, the human’s role. The first person does the work. The second operates tools that amplify effort. The third directs machinery whose power dwarfs their own, through controls they had to learn: levers, gauges, gradients, the feel of the ground under the tracks.

Now imagine a fourth possibility. The person describes what needs to happen — the shape of the excavation, where the clay should go, what must be preserved — and the machine works out much of the operation itself, asking where the description was ambiguous and reporting what it did. The human no longer operates every control. They communicate the outcome and judge the result. Notice what has vanished along the way: the years the operator spent acquiring feel — for the levers, the ground, the machine’s moods. That learning was real skill, and it deserves respect rather than dismissal. But it was skill in service of the controls, and when the controls cease to be the bottleneck, the skill that matters becomes something else: seeing clearly what the finished work should look like, saying so precisely, and recognising the difference when it arrives. I do not offer this as a report on autonomous heavy machinery, which has its own unsolved problems. I offer it as the shape of the transition: from doing, to operating, to directing — with each step moving the human further from the mechanism and closer to the intention.

What We Call Artificial Intelligence

Before going further, I should say what I mean by the term, briefly and without pretending to settle what the field itself has not. AI is not one algorithm or one kind of intelligence. It is a broad family of methods — statistical learning, predictive models, search, optimisation, neural networks, embeddings, generative models, planning, and related approaches — that produce behaviour we associate with intelligent work: recognising, predicting, generating, deciding, adapting.

Sorting a list is not automatically AI, and a generative system is not merely choosing from a predefined menu, however tempting either simplification is. Behind one conversational surface may sit a retrieval index, a ranking model, a generator, a verifier, and an orchestrator — distinct technologies, each with its own failure modes, each improvable independently. That matters for everything this book teaches about configuration: when I equip a coding machine, I am assembling several of these families at once, and diagnosing a failure means asking which one misbehaved. My point is narrower than a definition and more important for this book: the underlying mechanisms are diverse, yet the human experience of them is converging toward intention-shaped interfaces — conversation prominent among them today, but the direction points beyond any single medium. Speech, text, visual interaction, documents, demonstrations: what they share is that the human expresses a desired outcome rather than operating the mechanism. Conversation is the most accessible present example of that shift, not necessarily its final form. The same spoken or written request can now reach into many different kinds of machinery. That convergence of experience over diversity of mechanism is what makes the rest of this chapter possible — and it is also what makes Chapters 03 and 07 necessary. A single conversation can now reach retrieval, generation, verification, and orchestration, but those remain different technologies with different failure modes, and treating the interface as the whole system is how confident nonsense gets built. The interface is the achievement; mistaking it for the machinery is the hazard. I make no claims here about consciousness, understanding, or machine minds; none of the argument requires them.

Technology on Its Own Terms

For most of technological history, every new capability arrived with new controls to master. Computers, communications, databases, industrial machines, transport systems, networks — each demanded its own interfaces, procedures, languages, and limitations, and people learned technology on its terms or not at all.

Software development is the clearest example I know, because it was my apprenticeship. Programmers learned languages, compilers, libraries, frameworks, build systems, interfaces, and deployment procedures — an entire stack of translation between what was wanted and what the computer would do. Those mechanisms were genuine achievements, not primitive fumbling; they remain useful and will for a long time. But the structure of the work was fixed: the human performed the translation, line by line, and the machine executed the result. Fluency in the mechanism was the price of admission to the outcome — years of it, before you were trusted with anything that mattered. The same pattern held everywhere else: the pilot’s hours, the machinist’s feel, the network engineer’s command-line reflexes. Every field paid its fluency tax, and every field called the payment mastery, because at the time there was no other way to get the work done.

I should be precise about what the fluency tax actually covers. For the programmer it was mostly operational knowledge — syntax, tooling, procedure — and that is exactly the part AI absorbs first. For the pilot, the surgeon, the engineer signing off a structure, the expertise includes safety judgement, physical understanding, and consequential responsibility that no interface improvement dissolves. The claim is not that all expertise was mere interface friction. It is that AI steadily reduces the amount of specialised operational knowledge each task demands — and wherever that reduction happens, the gate it guarded opens a little wider.

There was a further consequence nobody much remarked on: the fluency tax gated who could participate at all. The person with the idea but without the years of mechanism was, for practical purposes, silent — dependent on finding someone fluent to speak for them. Any technology that lowers that tax does not merely speed up existing practitioners; it admits new ones, with new problems worth solving.

When Technology Understands the Request

AI introduces a different arrangement: the human expresses what they want, and the machine increasingly handles the translation itself — interpreting the request, choosing or coordinating the appropriate tools, using information systems, and returning a result.

Research shows the pattern in miniature. The old work meant manually searching, browsing, comparing, extracting, and synthesising across dozens of sources. Increasingly, an AI can perform or coordinate much of that activity from a conversation, while the browser and the source documents remain — chiefly as the place where claims get verified rather than where every step gets operated by hand. Anyone who has watched a researcher work both ways recognises the shift: the hours move from gathering to judging, and the skill that gains value is knowing which claims need checking, not how fast you can open tabs. The person is not removed; the person is moved, from operating each step to directing and checking the whole.

Software follows the same shape, and this book has documented it in detail rather than merely asserting it. A person describes an application; the machine generates an implementation; conversation directs successive improvements. What current systems demonstrably do is produce working starting points and respond to directed correction. What still depends on context, tools, and human supervision — the subject of Chapters 02 through 07 — is everything that turns a starting point into software worth trusting.

A future demonstration worth imagining, though not yet built, makes the trajectory concrete: a person describing an application aloud, trying what the machine produces, and continuing entirely by voice — “make the restart obvious”, “that broke the permissions, put them back” — until the software is right. I claim no such demonstration as executed. Its purpose here is to show the direction the interface is travelling: steadily toward the intention, steadily away from the mechanism.

Compression Before Expansion

Here is the chapter’s central idea, stated in my own terms. Call the first effect interface compression: AI reduces the number of specialised interactions a human must perform directly. Fewer consoles, fewer query languages, fewer manual translations between intention and execution. That alone would be a productivity story — and it is genuinely happening wherever conversational systems absorb routine operational work.

But compression is only the first effect. The greater one is amplification: with fewer interfaces to master personally, a person can direct more capabilities, combine technologies they could never each have learned deeply, and attempt projects previously beyond their available time, skills, or resources. A single developer can now direct database design, interface construction, document processing, and deployment orchestration in one sustained effort — not by mastering each discipline’s controls, but by stating intentions clearly and judging results carefully.

Compression, then amplification, then an expansion of possibility: people attempting things that were previously out of reach, not because the underlying technologies got simpler — much of that complexity merely moved behind the AI interface, where it still matters and still fails — but because the cost of reaching through it fell. Chapters 02 through 07 of this book can be read as the manual for that reaching-through: each is a discipline for managing complexity that did not vanish but relocated. Foundations keep the ground solid; configuration keeps the machine honest; intent keeps the purpose visible; the system keeps the world in view; packages keep the work bounded; evaluation — the subject waiting ahead — keeps the results true. Compression without those disciplines is not amplification; it is abdication with better tooling.

Consider, hypothetically, what this means concretely for one person: a local historian with a lifetime of parish records, photographs, and taped interviews — no database training, no web skills — directing the creation of a searchable, cited archive that scholars can actually use, drawing on storage, retrieval, interface design, and preservation practice in a single sustained effort. No one constituent technology is novel; the novelty is that one non-specialist intelligence can compose them all toward a purpose only they fully understand. Technologies that lived in separate professions, each with its own fluency tax, can now be combined by a single directing mind — which is why the expansion matters more than the compression that enabled it. I am not promising that every technology becomes fully accessible, reliable, or autonomous. I am describing the direction: the bottleneck moves from operating the machinery to imagining what is worth directing it toward.

Drive the Steamroller

There is a metaphor I keep returning to, and I will state it plainly: get out of the way of the steamroller — and start driving it. Capable machines are absorbing, one by one, the manual responsibilities software developers historically performed. That absorption will not pause for anyone’s comfort, and standing in front of it — defending each operation as the indispensable craft it once was — is not a strategy. Learning to direct the machinery is.

This is not an abandonment of responsibility; it is a change in its level. The developer who once proved their worth by writing every line now proves it by deciding what should exist, under what conditions, and whether the result is good enough — the entire argument of Chapters 02 through 07, compressed into a working stance.

Concretely, the working day is already changing shape: less time translating requirements into syntax, more time stating requirements so they can be tested; less time debugging one’s own typing, more time evaluating whether the machine’s output matches the intention; less time memorising APIs, more time maintaining the charters, packages, and records that let many machine efforts accumulate into one application. Those structures are today’s mechanisms for direction — the present engineering of Chapters 02 through 07 — not the destination. As machines grow more capable, maintaining the charters, organising the packages, and keeping the records current are themselves the kind of work that can migrate upward; the objective was never a larger administrative workload for the human but greater amplification with less of me in the loop. What I must preserve is control over the direction of the work: what I want to achieve, what matters to me, and whether the result is worth pursuing. How much of the thinking, evaluation, and organisation the machine performs will continue to change — that movement is the book’s whole subject. Responsibility stays with me; the labour may not. I make no claims about employment schedules or the fate of professions; those depend on economics and institutions far beyond this book’s evidence. And traditional expertise keeps real value: the judgement to recognise good and bad results was earned the hard way, and it transfers directly to directing machines. What does not transfer is the reflex that every problem must be solved by hand. That reflex is what the steamroller is for — to be driven, not admired, and not stood in front of.

The Advantage Changes

This shift treats newcomers and experienced developers differently, and honesty requires saying how.

Newcomers may take to conversational creation naturally. With fewer assumptions about implementation, they ask for outcomes rather than mechanisms — which is exactly the posture machine coding rewards. But freedom from habits is not the same as judgement: without experience of failure, they may accept poor design, incomplete outcomes, or confidently misleading results at face value. The specific danger is fluency without scepticism — everything the machine produces looks equally authoritative, because the newcomer has never watched authoritative-looking work fail. That scepticism cannot be downloaded; it is earned by being wrong in public, by shipping the bug, by trusting the green suite that lied. The question is whether machine coding lets newcomers earn it faster, by encountering more failures per month under supervision, or slower, by insulating them from consequences. I do not know the answer yet, and the book will not pretend otherwise.

Experienced developers bring the complementary strength: technical judgement, architectural knowledge, and a catalogue of failures that teaches what to distrust. Their risk runs the other way — the instinct to seize the keyboard, to reimplement by hand what direction would have accomplished faster, to mistake familiarity with the controls for superiority of the method. I recognise the reflex because I have felt it: watching a machine fumble something I could have typed in a minute, and having to remember that the minute was never the point. The discipline for experience is restraint in one direction and assertion in the other: hold back the hands, but do not hold back the judgement. What the experienced developer brings right now is a stock of hard-won patterns — recognising the shape of a bad design, smelling the incomplete result, knowing which confident claim needs checking. Those patterns make them effective directors of machines today. Over time, machines may acquire many of those abilities themselves, and some they may exceed; testing, review, diagnosis, and integration assistance are already migrating upward, unevenly but visibly. My responsibility therefore is not to preserve every manual review activity as permanently human territory. It is to understand what constitutes a satisfactory outcome, and to know, case by case, when to trust, when to question, when to redirect, and when to demand more evidence. The judgement that matters most is the one about where judgement itself is still required.

The opportunity belongs to neither group exclusively. It belongs to whoever combines freedom from unnecessary implementation habits with the ability to recognise good and bad results. Quality — taste, individuality, the recognition of the genuinely good — is where this chapter stops, deliberately. Those questions deserve a chapter of their own, and they will get one.

From Coding to Machine Direction

Return now, decisively, to the practice this book teaches. The earlier chapters described mechanisms that work today: communicating intent, establishing constraints, decomposing packages, configuring agents, invoking skills, setting up runtimes, preserving memory and continuity. None of these should be mistaken for permanent human duties. As AI systems grow more capable, more of the work — selecting tools, arranging packages, configuring runtimes, retrieving context, testing, correcting, integrating — may itself become machine work, directed rather than performed by people. Some of this is already visible in miniature: agents that choose their own search strategies, runtimes that recover from their own failures, test loops that run without supervision. Each step follows the same pattern as the larger transition — a responsibility moving from operation to direction — which is why the book’s method scales downward as well as upward. Progress will be uneven, with real limits, and nothing in this book claims otherwise. But the direction is visible: the developer moves steadily upward, from implementation toward intention.

I sometimes call current practice machine direction, because guiding machinery describes the daily work better than writing code does. The book keeps the name Machine Coding for a simpler reason: the discipline grew out of programming, its practitioners are programmers, and its product is software. The name honours where we came from; the practice points at where we are going. And nothing in this chapter retires Chapters 02 through 07. Their methods are the present engineering of this emerging discipline — the way direction is actually exercised, today, with evidence, rather than a vision of direction replacing the need for method.

We Are Only Beginning

I believe this transition is in its earliest stages, and I expect substantial further change over the coming five years. That is a considered forecast, not a measured trajectory: no exponential curve is claimed, no percentage of eventual capability is asserted. What supports it is the pattern of this book — each chapter moving the human one level further from mechanism — combined with the visible rate at which the machinery improves. Forecasts can be wrong about timing while being right about direction, and I offer this one in that spirit. And forecasts should state what would change their author’s mind: if progress in directing machines stalls while implementation fluency keeps improving — ever more eloquent output, no better judgement — then the chapters of this book become a complete method for a stable plateau rather than the opening of a larger transition. I do not expect that outcome, but the book is honest enough to name it.

Return once more to the clay. The opportunity was never to become the most skilled person at moving clay with a shovel. It is to learn to direct machinery capable of moving the mountain — and then to decide which mountains are worth moving. The reader’s future projects are the point of everything before this page: the charters, the packages, the configured machines are all means to the moment when someone with an idea discovers they can build it.

What that building is worth — whether the result shows judgement, taste, and individuality, or merely competence — is the question I have deliberately held back. Answering it requires looking hard at quality itself: how to recognise it, how to demand it. That is the subject waiting a few chapters ahead — after learning to read the machine, keep its history, and keep it from slopping.