For most of software's history, the bottleneck was implementation. Writing the code was the hard, slow, expensive part. Every engineering practice we built code review, pair programming, careful hiring, sprint planning exists because writing correct code was scarce and valuable.
That assumption is breaking. When an agent can produce working implementation faster than you can review it, code stops being the scarce resource. And when the scarce resource changes, everything built around the old scarcity has to be rebuilt.
This is what I've come to call harness engineering the discipline of building the system that lets agents do the implementation while humans do the steering. It's a different job than software engineering, and most of the instincts that made you good at the old job actively work against you in the new one.
Here's how I think about it.
The core shift: humans steer, agents execute
The mental model that unlocks everything else: you are no longer the one writing the code. You are the one deciding what gets written, why, and to what standard.
Three premises follow from this, and they sound uncomfortable until you sit with them:
Code is an abundant resource
If implementation is cheap to generate, then code itself is no longer the thing you protect. You can regenerate it. You can throw it away. The value moves up the stack to the specification, the architecture, the validation.
The token billionaire mindset
If you treat tokens as precious and hoard them, you'll under-use the system. The engineers getting the most from agents spend tokens freely running multiple attempts, generating throwaway exploration, letting agents iterate. Tokens are the cheap resource. Spend them to save the expensive ones.
Implementation is no longer scarce
This is the premise everything else rests on. If you don't accept it, you'll keep optimizing for the wrong thing guarding implementation when you should be guarding the architecture that makes implementation safe to regenerate.
What's actually scarce now
Three resources are genuinely constrained, and harness engineering is the practice of conserving all three:
The engineer's job is now staff-level by default
If you're not writing the implementation, what are you doing? The same things a staff engineer does — but now it's the whole job, not the part you grew into.
Systems thinking and design - the architecture is yours; the implementation is delegated
Delegation and orchestration - breaking work into agent-sized units with clear contracts
Specifying non-functional requirements - performance, reliability, security; the things agents won't infer
Staff engineer mentality - thinking about the system, not the line of code
The junior-engineer skill of writing a clean function is now table stakes the agent handles. The senior skill of deciding what should be built and how it should be structured is the entire job.
Building the harness
The harness is the infrastructure that makes agents productive and safe. Three components do most of the work.
A skills framework
Centralize the high-leverage capabilities agents need and hide the infrastructure complexity behind them. An agent shouldn't reason about how to run your test suite or deploy a preview it should invoke a local dev tool that handles it.
The skill is the interface; the complexity lives behind it. This is the same abstraction discipline that makes any large codebase maintainable, applied to agent capabilities.
Context management
This is where most harnesses succeed or fail. Three techniques that work: auto-compaction (models like GPT-5.4/Codex compress context as runs grow long), just-in-time instructions (load relevant guidance when the task needs it, not all upfront), and refreshing context via reviewers (a reviewer agent re-grounds the working agent when its context drifts).
The context window is the scarcest resource in a long run. Managing it isn't a nice-to-have it's the difference between an agent that stays coherent over 20 milestones and one that loses the plot by milestone 5.
Prompt injection points
The harness should inject guidance at the moments the agent is most receptive to it not in one giant system prompt at the start. Four high-value injection points: rules files and breadcrumbs left in the codebase, lint error messages (a lint failure is a teaching moment), test failure remediations (tell the agent how to fix, not just that it failed), and reviewer agent comments. Each one is context delivered exactly when it's actionable.
Operationalizing the team
Individual agent productivity is one thing. Running a team this way requires deliberate operational choices some of which feel radical until you see why they work.
Ban manual code editing
This sounds extreme, The reasoning: if humans edit code directly, the agent's model of the codebase drifts from reality, and the regeneration safety net breaks. If everything goes through the agent, the codebase stays agent-native. The discipline is what makes the abundance usable.
Garbage collection day
Agents produce slop dead code, redundant abstractions, inconsistent patterns. Schedule dedicated time to clean it up, the same way a GC pass reclaims memory. Treating cleanup as a first-class scheduled activity rather than an afterthought keeps the codebase healthy.
Persona-oriented documentation.
Write documentation for the agent personas that will read it: a front-end architect persona, a reliability/scalability expert persona, a QA specialist persona. Each persona gets docs tuned to the decisions it makes. Generic docs serve no one; persona docs make each agent sharper at its specific job.
Remove synchronous human blocks
Anywhere the workflow stops to wait for a human is a bottleneck on the scarcest resource. Restructure so human input is asynchronous — the agent proceeds with sensible defaults and surfaces decisions for review without blocking.
Agent-native codebase architecture
A codebase optimized for human readability is not the same as one optimized for agents. The structural choices change:
The 750+ packages number looks absurd by human standards — nobody wants to navigate that many packages by hand. But an agent doesn't navigate; it loads exactly the package it needs. Extreme modularization is a feature when your reader is a model with a finite context window.
Where this is heading
Four ideas that follow if you take the premises seriously:
The LLM as a fuzzy compiler.
A traditional compiler turns precise source into machine code deterministically. An LLM turns fuzzy intent into implementation probabilistically. If you accept that framing, your job is writing the source for the fuzzy compiler the specification not the output.
Token budget-driven development.
If tokens are the cost of building, then development gets planned around token budgets the way we used to plan around engineer-hours. The question becomes 'what can we build for this token budget' rather than 'how many engineers do we need.'
Code as a disposable build artifact.
This is the logical endpoint of code being abundant. If you can regenerate implementation from specification, the implementation is a build artifact like a compiled binary. You don't carefully preserve every binary; you preserve the source that generates it. The 'source' is now the spec and the architecture.
Autonomous product advancement.
The further endpoint: systems that advance the product with decreasing human involvement at the implementation layer, while humans concentrate entirely on direction, validation, and judgment.
What I'd actually take from this
I don't think every premise here is settled. 'Code as disposable artifact' is a strong claim, and the regeneration has to be reliable enough to trust before you throw the implementation away which, given the statistical validity gaps I see in my own benchmarks, isn't fully there yet.
But the core shift is real and already happening: the scarce resource is moving from implementation to attention. The engineers adapting fastest are the ones who stopped guarding their code and started guarding their architecture and their specifications.
Harness engineering is the name for that adaptation. Whether or not you buy the full vision, the practical core manage context ruthlessly, specify clearly, keep the codebase agent-native, spend tokens freely to save attention is worth adopting now.
Which premise do you push back on hardest that code is abundant, that implementation is no longer scarce, or that code is a disposable build artifact?
Top comments (0)