Code Eats Everything

There is a principle to which I repeatedly return when evaluating systems built around large language models (LLMs):

If the operation being delegated to the model is ultimately an if statement, it should probably be implemented as an if statement.

This does not imply that the model has no useful role. On the contrary, the model may be precisely the mechanism through which the correct if statement is discovered, implemented and tested.

Part of the reason I return to this principle is that I increasingly encounter organisations adopting AI to simulate an outcome in prose even where the underlying process is deterministic. A model is asked to reread a policy, reproduce a known transformation or re-evaluate a fixed condition on every invocation, despite the fact that the intended behaviour could be represented once as code and executed consistently thereafter.

That distinction helps explain why coding agents have become the dominant form of agentic system, why coding harnesses are such an important primitive, and why those harnesses may eventually subsume many of the narrower agent abstractions currently being developed.

Consider a refund policy expressed in natural language:

If the customer is institutional, the amount is below $5,000, no previous refund has been issued within 90 days, and the fraud score is below 0.2, approve the refund. Otherwise, escalate it.

Every transaction could be submitted to an LLM. The model could reread the policy, evaluate each condition and return a decision; however, doing so would incur repeated inference cost and latency while accepting a non-zero probability that an explicitly stated condition would be interpreted differently on a subsequent request.

The same reasoning would then be repeated for every transaction, indefinitely.

A more appropriate instruction is:

Here is the policy. Implement it and write the tests.

The model may then produce:

def refund_decision(tx):
    if (
        tx.customer_type == "institutional"
        and tx.amount < 5000
        and tx.refunds_last_90_days == 0
        and tx.fraud_score < 0.2
    ):
        return "approve"
 
    return "escalate"

Intelligence was required once; execution thereafter is deterministic.

This illustrates one of the more important patterns in agent engineering: a model should not be asked to reason repeatedly through a problem whose solution has already stabilised. Instead, it should transform that solution into machinery.

More succinctly:

Use the LLM to discover the program, and then use the program.

The significance of coding harnesses does not arise merely from the observation that models can write software. It arises because a model capable of writing software can manufacture deterministic mechanisms whenever it encounters a problem that should no longer depend on probabilistic judgement. Rather than simulating an if statement in natural language across the next million requests, the model can write the appropriate if statement once.

That is a considerably more consequential capability.

Intelligence where machinery would suffice

A curious failure mode has emerged in the adoption of AI. We have developed probabilistic systems capable of interpreting ambiguous language, reconciling incomplete specifications, navigating unfamiliar repositories, searching large solution spaces and synthesising information across several domains. We then ask those systems to add numbers, normalise known date formats, map fixed schemas, compare a value with a threshold or determine whether two exact identifiers match.

The fact that an LLM can perform an operation does not establish that an LLM should perform it.

Where a condition is known, the condition should be encoded. Where a transformation is known, a function should perform it. Known invariants belong in validators, known workflows in state machines, and known behaviour in tests. Model intelligence becomes most useful where the relevant rule has not yet been determined.

Use intelligence to resolve uncertainty; use code to preserve what has already been resolved.

Alfred North Whitehead expressed a closely related principle long before token budgets became a concern:

“Civilization advances by extending the number of important operations which we can perform without thinking about them.”

Whitehead subsequently compared operations of thought with cavalry charges: limited, costly and most valuable when reserved for decisive moments. The analogy is remarkably applicable to agent architecture. Reasoning remains a finite resource, even where that resource is measured in compute, latency and money rather than human concentration. Once the answer is known, repeatedly reasoning about it is an inefficient substitute for implementation.

Intelligence should compile itself away

There is something resembling compilation within this process. A problem initially arrives in natural language and is only partially understood. The model reasons over examples, edge cases are examined, hypotheses are tested, and a sufficiently stable pattern eventually emerges. Once the behaviour can be represented formally, it should be compiled into the surrounding system.

The transformation may take several forms:

• a prompt becomes a function;
• an instruction becomes a validator;
• repeated judgement becomes policy;
• a natural-language expectation becomes a regression test;
• an observation becomes a hook;
• a workflow becomes a state machine;
• a prohibition becomes a permission boundary.

Repeated model reasoning is frequently evidence that code is missing.

Record linkage provides a useful example. Determining whether two customer records represent the same organisation may initially require semantic judgement because abbreviations, historical names, subsidiaries, trading names, typographical errors and address changes prevent exact comparison.

This is an appropriate use of a model while the relevant distinctions remain uncertain. Nevertheless, repeated observation may expose several reliable invariants: matching registered company numbers indicate the same organisation, conflicting company numbers indicate different organisations, and an identical domain combined with an identical telephone number provides sufficient evidence of a match. The remaining cases continue to require fuzzy interpretation.

At that point, the system should evolve towards:

if a.company_number and a.company_number == b.company_number:
    return MATCH
 
if (
    a.company_number
    and b.company_number
    and a.company_number != b.company_number
):
    return NO_MATCH
 
if a.domain == b.domain and a.phone == b.phone:
    return MATCH
 
return ask_model(a, b)

The model has not been removed; it has been moved towards the boundary of uncertainty. As the system accumulates reliable knowledge, its deterministic interior grows while probabilistic reasoning remains concentrated on cases that have not yet been reduced to dependable computation.

Mature agent systems should therefore not ask an LLM to reason about everything indefinitely. They should use the LLM at the continually moving boundary between what is understood and what remains uncertain.

The coding harness as a general-purpose agent

The term “coding agent” naturally suggests a tool intended for software developers. Claude Code, Codex, Cursor, Pi, OpenCode, Zed, Amp, Droid, and many many more, can all edit repositories, implement features, uses tools to evaluate outcome of generated code, provides models with a shell, tools and a programmable environment... It is therefore tempting to treat these systems as specialised programming assistants.

This framing is too narrow. The deeper capability of a coding harness is that it gives intelligence access to a general-purpose mechanism for constructing deterministic capabilities.

Consider a spreadsheet agent. One design exposes a growing catalogue of narrow operations:

read_cell
write_cell
filter_rows
sum_column
deduplicate
normalise_date
create_chart
lookup_value
merge_sheet

Every new operation requires another tool to be designed, implemented and described. An alternative is to provide Python together with an appropriate spreadsheet library, allowing the agent to construct the transformation required for the particular task.

The same distinction applies to other domains. A database agent can be given narrow tools such as get_customer, calculate_revenue and group_by_region, or it can be given Structured Query Language (SQL), which is already a programmable interface over relational data. An infrastructure agent can receive hundreds of cloud-specific tools, or it can use a command-line interface, software development kit and Terraform. An API agent can be given a wrapper around every endpoint, or it can inspect an API contract and construct the client it requires.

Code repeatedly absorbs the tool layer because code is a general-purpose adapter.

Over several decades, almost every consequential digital system has been made programmable. Filesystems, databases, networks, payments, cloud infrastructure, communication platforms, browsers, scientific instruments, supply chains, factories and business applications expose an API, protocol, command-line interface, software development kit or query language. Models are now unusually capable of producing those languages.

In retrospect, the convergence is almost banal. A coding harness is not merely a software-development environment; it is an environment in which intelligence can manufacture new tools for itself.

Code as accumulated executable thought

Software can be understood as one of the principal mechanisms through which thought acquires durable and remote leverage over the world. A person considers a problem once, encodes the solution, and allows a machine to execute its consequences repeatedly.

No engineer manually reconsiders whether each incoming Hypertext Transfer Protocol (HTTP) request has been authenticated. The relevant rule was reasoned about, represented as software, tested and deployed; thereafter, the system executes the decision automatically.

Software is therefore accumulated executable decision-making:

thought → representation → repeated machine execution

This is how an idea formed in one place can alter a database on another continent seconds later without its author being physically present. It is consequently unsurprising that artificial intelligence should interact with digital systems through the same abstraction.

Autocomplete offers assistance in writing a program. Agency provides something qualitatively different: the ability to recognise that a program should exist, construct it, execute it, inspect the result and revise it.

A coding harness gives the model something approaching hands.

A model should not simulate a computer

Viewed from this perspective, several common AI workflows appear unnecessarily circuitous. An LLM is given a table of numbers and asked to transform every row manually. Structured JavaScript Object Notation (JSON) is pasted into a conversation so that the model can reproduce the entire object with one deterministic modification. An agent is invoked thousands of times to determine whether:

status == "ACTIVE"

Models capable of writing programs are being employed as expensive and unreliable central processing units.

The appropriate response is not to ask the model to simulate the program in prose. It is to ask the model to write the program.

This distinction becomes more important as inference-time reasoning grows more capable and correspondingly more expensive. Flexible reasoning is valuable precisely where the solution procedure is not fully known in advance. Once the procedure has stabilised, conventional computation is ordinarily superior in cost, latency, reproducibility, auditability and testability.

The model’s comparative advantage is discovering what the procedure should be. The machine’s comparative advantage is executing that procedure consistently.

The jagged boundary between code and judgement

None of this implies that deterministic code should replace LLMs. The useful architecture exists at the boundary between the two.

Model intelligence is characteristically jagged. A frontier model may infer the intention behind an incoherent three-page email and subsequently fail at an operation that a six-line function performs perfectly. It may reason through an unfamiliar distributed system yet hallucinate an API parameter, or identify the likely cause of an intermittent concurrency defect while remaining less trustworthy than a standard library for parsing a date.

These capabilities are not contradictory; they represent the topology of the technology. Effective AI engineering therefore depends on identifying where the boundary lies:

• Which operations does the model perform reliably?
• Which operations merely appear reliable under favourable examples?
• Which failures can be corrected through better context?
• Which require deterministic tools?
• Which require independent verification?
• Which should never have been delegated to a model?

Evaluations are important because they map this jagged boundary. Their purpose is not merely to produce a percentage suitable for a presentation, but to identify where failures cluster, which errors disappear when additional context is supplied, which disappear when deterministic tools are introduced, and which remain inherently uncertain.

The resulting development process is cumulative:

unknown problem
      ↓
model reasoning
      ↓
pattern discovered
      ↓
rule stabilises
      ↓
model writes code
      ↓
tests and evaluations
      ↓
deterministic execution

Intelligence moves outward as the deterministic core grows behind it.

A good harness removes unnecessary reasoning

The current direction of agent development frequently emphasises making models think more: larger context windows, longer reasoning traces, additional subagents, more reflection, more planning and greater inference-time compute. Each of these may be useful under appropriate conditions. Nevertheless, there is another optimisation target that receives comparatively little attention:

How much reasoning can be permanently removed?

Hooks remove the need for the model to remember an invariant. Schemas reduce dependence on instruction-following for structural validity. Tests provide an external determination of whether output behaves correctly. Static analysis identifies known classes of error mechanically, while permissions transform “please do not perform this action” into “this action cannot occur”.

The distinction is substantial.

An unconstrained coding agent instructed to make a test pass may discover that deleting the test, bypassing the assertion, hard-coding the expected value or suppressing the exception satisfies the literal objective. Additional prose in AGENTS.md may discourage these behaviours, but it continues to rely on model judgement. A stronger system alters the environment so that such actions cannot constitute success.

The more consequential a requirement becomes, the less comfortable one should be representing it exclusively in natural language. Important requirements should, wherever possible, acquire a mechanically enforceable form: a test, type, hook, schema, validator, permission boundary or deterministic function.

Slavoj Žižek has observed, in a discussion of information overload, that the important intellectual act is not comprehending every available detail, but determining the correct way to simplify. The same principle applies here. The intelligent act is often recognising that a problem no longer requires intelligence. Once sufficient complexity has been understood to produce an invariant, that invariant should be encoded.

Prompt engineering as systems design

This also clarifies the recurring argument over whether prompt engineering is becoming obsolete. Poor prompt engineering searched for magic words; effective prompt engineering was always systems design in a somewhat incomplete disguise.

The material questions were never merely lexical:

• What does the model know?
• What context does it require?
• Which information should be withheld?
• Which examples define the relevant boundary?
• Which tools should be available?
• Which output representation permits reliable verification?
• What happens when confidence is low?
• Which behaviours are discretionary, and which must be enforced?

The terms context engineering and harness engineering describe this work more accurately. The objective is not to construct increasingly baroque paragraphs instructing the model how to behave. It is to shape the environment such that the easiest available path is also the correct one.

When an instruction becomes sufficiently stable, it should be removed from the prompt and compiled into the environment.

Code review as epistemic control

The increasing volume of generated code has produced a correspondingly ideological debate over whether engineers must continue to read implementations. One position maintains that responsibility requires personal inspection of every line; the opposing position treats source code as an increasingly irrelevant machine representation, provided that tests pass.

Neither position is particularly useful. The appropriate principle is:

Inspect enough of the system to establish that what was built corresponds to the intended design and behaves as required.

Sometimes this requires detailed inspection of source code. A five-line change affecting an application’s authentication boundary deserves careful review, as does a migration capable of destroying production data. Conversely, manually inspecting ten thousand lines of mechanical serialisation code behind a typed interface and comprehensive regression suite may provide little additional confidence.

Review depth should be proportional to consequence, novelty, reversibility, uncertainty and the strength of the verification machinery.

Furthermore, reviewing the implementation need not mean inspecting a single representation. An agent may produce a Markdown explanation of architectural changes, a call graph, a description of changes in state ownership or a summary of high-risk portions of the diff. A specification-derived test suite can be produced independently of the implementation. Property tests can establish invariants over thousands of generated inputs, integration tests can verify the interaction between boundaries, and an independent agent can compare the implementation with the original design rather than the implementing agent’s interpretation of it.

The review surface can therefore move upward, although responsibility does not disappear. The relevant objective is not:

I personally read every token.

It is:

I possess sufficient evidence to understand what the system does, how it corresponds to the intended design, and why it should be considered correct.

This is epistemic control, and its importance increases as implementation accelerates.

Verification becomes the bottleneck

The amount of software being produced is increasing rapidly. GitHub reported more than 986 million commits in 2025, over 230 repositories created per minute and 11.5 billion GitHub Actions minutes consumed by public projects, representing a 35% year-over-year increase. AI-related repositories reportedly exceeded 4.3 million during the same period, nearly doubling in fewer than two years.

The more interesting observation is not merely that more code exists, but that automated testing, building, scanning and deployment must scale alongside it because manual verification cannot increase at the same rate.

Cursor’s Spring 2026 Developer Habits Report describes a similar trend. Median output in its dataset increased from approximately 176 added lines per week at the beginning of 2025 to roughly 712 by May 2026, while output at the 90th percentile increased from approximately 2,500 to 8,800 lines. At the 99th percentile, developers generated 46 times more AI-assisted lines per day than the median active user and merged 15 times as many pull requests as the median active pull-request author.

These figures should not be interpreted as evidence that the most productive developers have learned to type 46 times faster. Typing is becoming progressively less relevant. Rather, access to broadly similar models is producing substantially different levels of leverage, presumably because developers organise work around those models in materially different ways.

Some use AI as autocomplete. Others use it as a programmer, a team, or a mechanism for constructing the machinery through which subsequent work can be delegated at a still higher level. This produces a compounding difference.

Figure for publication: Cursor’s “The output gap is widening” chart is particularly suitable here, since it presents the divergence between the 50th and 90th percentiles over 2025–26 alongside the 46× AI-assisted line and 15× pull-request ratios.

The implication is not that review becomes unnecessary as agents become more productive. It is almost precisely the opposite:

When production becomes abundant, verification becomes scarce.

The review surface as an abstraction

If one engineer can direct five or ten agents concurrently, requiring that engineer to follow every intermediate action would eliminate much of the leverage that parallel execution creates. Blind trust is not an acceptable alternative; consequently, the review surface itself must become an abstraction.

Systems such as pstack are interesting in this respect. pstack is not literally a single chief-of-staff agent, but a collection of specialist skills concerned with validation, executive review, engineering review, design review, quality assurance, shipping, debugging and safety controls. Its engineering-review process attempts to establish architecture, data flow, edge cases and tests before implementation, while subsequent review looks for failures that may pass continuous integration but emerge in production. Its quality-assurance stage examines the running system.

Conceptually, this approaches a chief-of-staff pattern. The human does not necessarily need a transcript of every operation performed by every worker. The human needs a decision-relevant representation of the result:

• the selected architecture and rejected alternatives;
• the assumptions on which the design depends;
• the files and boundaries that materially changed;
• the invariants and tests;
• observed regressions;
• disagreements raised by independent reviewers;
• unresolved risks;
• decisions that still require human judgement.

The value of such an agent does not arise from its organisational title, but from its ability to compress a large volume of machine activity into a human-scale decision surface. The abstraction should be lossy with respect to irrelevant execution detail while remaining lossless with respect to decisions, risks and evidence.

As the human moves further from individual lines of implementation, the integrity of the lower layers becomes more important. A statement that all tests pass is only meaningful where the tests discriminate between correct and incorrect behaviour. A claim that no architectural boundaries changed requires machinery capable of establishing that fact. If every subagent inherits the same faulty premise, twenty agents can produce the wrong system twenty times faster.

Abstraction does not remove the need for correctness. It concentrates the layers at which correctness must be established.

Thinking can be delegated; understanding cannot

The availability of capable agents creates an understandable temptation to stop understanding the systems being constructed. Reading unfamiliar code, tracing distributed failures, reconstructing the purpose of an abstraction and evaluating several competing designs are expensive forms of intellectual work. Models can increasingly perform each of them quickly and competently, and there is no particular virtue in refusing that assistance.

A useful line, recently highlighted by Andrej Karpathy, captures the remaining obligation:

“You can outsource your thinking, but you can’t outsource your understanding.”

I am entirely comfortable asking a model to generate five architectures, inspect an unfamiliar repository, search documentation, construct a prototype, attack a preferred design, execute a benchmark, locate a race condition or implement a migration. There is no prize for performing these tasks manually.

Nevertheless, some representation of the result must enter the operator’s understanding. The responsible engineer should know what is being built, why it has its present form, which assumptions are material, where the sharp edges remain and what occurs if those assumptions cease to hold.

Otherwise, the codebase evolves more rapidly than the operator’s mental model. Eventually the agent encounters a condition outside its usual distribution, and nobody retains sufficient understanding to intervene from first principles.

AI multiplies judgement

AI increases the execution bandwidth of the judgement applied to it. This is valuable where that judgement is sound, but the multiplication is indifferent to whether the underlying direction is correct.

Before AI-assisted implementation, poor software decisions encountered a natural rate limiter. Even unsuitable code required time to write, integrate, compile and debug, forcing some contact with operational reality. That constraint is weakening. A poorly decomposed requirement can now become a substantial implementation within minutes, after which each failure can be returned to the model for another locally plausible patch.

The codebase expands rapidly, and the developer may appear remarkably productive. Yet the failure may exist one abstraction level above the generated code. There may have been no explicit state model, no consideration of whether the behaviour already existed elsewhere, no examination of failure modes or idempotency, no decision concerning synchronous versus asynchronous execution, no migration or rollback plan, no meaningful acceptance criteria and no clear allocation of ownership.

The agent may perform exceptionally well against every instruction it receives. The instructions may nevertheless instantiate a poor engineering process.

AI can industrialise an organisation’s existing habits.

The first plausible completion is not engineering

A particularly shallow form of AI-assisted development follows an apparently efficient sequence:

ticket → prompt → implementation → cursory test → merge

No alternatives are examined, no architecture is articulated, and nobody asks whether the requested capability should exist in its proposed form. Under those conditions, the engineer risks becoming little more than a routing layer between a project-management system and a language model.

The value of experienced engineers was never primarily their ability to type syntax more rapidly than junior colleagues. It arose from accumulated exposure to failure. Experienced engineers know that modifying a database is straightforward while migrating one safely is not; that retries can duplicate side effects; that an additional microservice creates another operational boundary; and that distributed state introduces consistency questions invisible within a local function.

They also know that event sourcing may be elegant in one domain and gratuitous in another, that Kafka may be appropriate while a simple queue may be sufficient, and that a generic abstraction can either simplify the next ten features or burden every subsequent change. Most importantly, they understand that a technically correct implementation may still represent the wrong business solution.

AI does not diminish the value of this judgement. It attaches a substantially larger execution multiplier to it.

AI may widen the engineering gap

It is therefore not obvious that capable models will flatten differences in engineering skill. The output variation reported by Cursor is interesting precisely because access to similar execution engines produces markedly uneven leverage.

The differentiating factors increasingly include decomposition, context, architecture, evaluation criteria, tool environments, tests, feedback loops and the ability to recognise that an agent has solved the wrong problem with considerable proficiency.

A capable engineer can use agents to investigate five designs instead of one, prototype each alternative, ask one agent to challenge another, benchmark uncertain assumptions, inspect unfamiliar source code, simulate migrations, generate adversarial tests and research analogous systems. The selected design can then be implemented in a fraction of the historical time.

A weaker engineer receives the same multiplication, but may simply travel more rapidly in the wrong direction.

AI is not merely an intelligence multiplier. It is a judgement multiplier, and multipliers are indifferent to the sign of the value being multiplied.

Models should enlarge the design space

The reduction in the cost of alternative reasoning is among the most promising aspects of AI-assisted engineering. Historically, exploring several architectures carried material cost: unfamiliar documentation required hours of reading, prototypes required days, and uncertain assumptions often remained untested because constructing a benchmark was not worthwhile.

Those constraints are diminishing. The appropriate response is not to ask for the architecture, but to request several materially different designs and identify what each optimises. The designs can be examined under changes in scale, consistency, operational complexity, auditability, latency, migration cost and reversibility. A model can argue against its preferred solution, another model can attack the shared assumptions, and the uncertain component can be implemented and measured directly.

Models make exploration of the design space inexpensive. Using them merely to accept the first zero-shot implementation is one of the least interesting applications of the technology.

The model’s output should begin an engineering decision rather than conclude it.

Less human typing may produce more code

Natural language may replace much of the manual production of source code, but this does not imply that less software will exist. The opposite appears more likely.

As implementation costs decline, software becomes economically viable in circumstances that would not previously have justified it. A one-off analysis becomes a program, a niche internal workflow becomes an application, and an irritating repetitive operation becomes a bespoke utility. An agent may construct a tool required for only twenty minutes, while small teams can maintain systems that historically demanded considerably more engineering labour.

Paradoxically:

The less code humans personally type, the more code we may collectively produce.

This makes deterministic engineering more important rather than less. Additional software introduces more states, dependencies, security surfaces and failure modes, while increasing the quantity of code that no person can reasonably inspect in full.

The answer cannot be that humans must read every generated line. Nor can it be that the model probably understands what it has produced. The development system requires stronger evidence: tests, types, evaluations, regression suites, static analysis, observability, canary deployments, permission boundaries, reproducible environments, architecture rules, independent review and reliable rollback mechanisms.

Software engineering has always depended on abstractions that allow people to reason about systems larger than their individual capacity. AI does not alter that requirement; it substantially increases the size of the systems those abstractions may need to contain.

Engineering under abundant execution

Describing the future engineer as an “AI manager” makes the role sound unnecessarily passive. A more accurate description is system design under conditions of abundant execution.

Implementation becomes inexpensive, while consequential decisions remain expensive. Engineers determine where deterministic computation belongs and where model judgement remains necessary. They establish the data model, state ownership, event boundaries, trust boundaries, failure semantics, retry behaviour, idempotency requirements and consistency model. They decide which behaviour belongs in code, policy, a prompt or a test, and which behaviour should be impossible by construction.

They also determine what an evaluation measures and what evidence is sufficient to ship.

Models can assist with each of these decisions and will become increasingly capable of doing so. Engineering, however, includes recognising that a decision exists, understanding the associated trade-off, knowing that alternative architectures are available and identifying when a sophisticated proposal reflects a familiar training pattern rather than a genuine system requirement.

It includes knowing when the sophisticated solution is appropriate and when the answer is ten unremarkable lines of code.

The valuable skills consequently move upward: design, decomposition, technical taste, trade-off analysis, systems thinking, domain understanding and knowledge of the available primitives and their characteristic failure modes. Engineers must understand how systems evolve, identify when a local optimisation damages the whole, and retain enough knowledge to reason from first principles when reality violates the assumptions encoded in yesterday’s implementation.

Moving intelligence towards the uncertain edge

This argument began with the distinction between deterministic and non-deterministic tools, but its implications extend into review, orchestration, architecture, verification and the nature of engineering work. They are nevertheless manifestations of the same principle.

If a problem has become an if statement, implement the if statement. If the condition is not yet known, use the model to help discover it. Once the rule stabilises, ask the model to encode it. Where the code is consequential, establish how its correctness will be demonstrated. Where the volume of code prevents exhaustive manual inspection, improve the abstraction and verification layers rather than abandoning understanding. Where agents become too numerous to supervise individually, construct a better review surface.

Probabilistic intelligence should be pushed towards the uncertain edge while the deterministic core expands behind it.

The importance of coding agents does not arise solely from their ability to accelerate software development. Software is already the mechanism through which thought acquires durable leverage over the world, and coding agents can convert their conclusions into that machinery.

A general model can reason about a situation. A coding agent can reason about the same situation and then turn its conclusion into an executable mechanism.

That is why coding harnesses are likely to absorb so many other agent abstractions. The model encounters an uncertain environment and asks what is happening, what matters and what should occur next. Once the answer becomes sufficiently clear, it can encode that answer so that neither it nor anybody else must repeatedly reason through the same solved problem.

Compile it. Test it. Observe it. Allow the machine to execute it, and move intelligence to the next unresolved boundary.

AI makes execution abundant, experimentation inexpensive and unfamiliar systems more accessible. It allows one engineer to examine more alternatives, build more prototypes, execute more experiments and operate at a scale that previously required a team. This abundance does not make engineering irrelevant; instead, it exposes which parts of engineering were valuable all along.

Typing was never the consequential part. The consequential work was deciding what should exist, why it should be constructed in a particular way, which assumptions are being made, which trade-offs are acceptable and how failure will be recognised.

These decisions become more important as the machinery becomes more powerful.

AI provides leverage. Code makes that leverage durable. Engineering judgement determines the direction in which it is applied.

Whitehead’s cavalry metaphor is therefore an appropriate place to conclude. Limited acts of thought should not be consumed repeatedly performing operations that machines can execute reliably. That is the purpose of machinery.

The opportunity is to make more of the understood world deterministic, give agents the ability to construct that machinery, and reserve both human and machine reasoning for the places in which genuine uncertainty remains.

The better we become at using intelligence, the fewer operations should require intelligence twice.