The Scarcity Inversion — Why Your Keyboard is Becoming Obsolete
Code generation is now infinite and free. The bottleneck has moved from writing code to architectural oversight — and that changes everything.
In the traditional software development lifecycle, we operated under a simple assumption: human logic was the bottleneck. We hired for "years of experience" because we needed developers who could hold complex state in their heads and manually type out the syntax to realize it. Quality was a direct byproduct of human attention. If a developer got tired, the code suffered. If a developer was fast, the features shipped. In that world, the keyboard was the primary tool of creation.
But as we cross into 2026, we have hit the Scarcity Inversion.
From Author to Architect
Code generation is now effectively infinite and essentially free. We can generate a thousand boilerplate CRUD endpoints in the time it takes to run a single npm install. Consequently, the "value" of writing code has plummeted.
The new goal isn't the ability to produce logic; it's the ability to provide architectural oversight and build the harnesses that ensure that infinite code doesn't become infinite technical debt.
When I say "Architect," I'm not talking about the ivory-tower Software Architect of 2010 who drew UML diagrams and disappeared. I'm talking about a System Governor. We are shifting from being Authors (manually crafting every line) to Harness Designers — engineering the automated environments where agents can work with production-grade reliability without babysitting.
The Metaphor: The Horse and the Harness
To understand "Harness Engineering," think of the AI agent as a powerful, high-speed horse. It has immense strength and speed, but left to its own devices, it has no sense of direction or safety. It will run until it hits a fence or falls off a cliff.
The Harness is the infrastructure you build around that power:
- The Reins — The specific intent and constraints (Spec-driven development).
- The Fences — The CI/CD pipelines, linters, and unit tests that define the "safe zone."
- The Path — The rigid architectural layers (Types, Services, Repos) that dictate exactly where the agent is allowed to "step."
Without a harness, you aren't engineering; you're just hoping the horse knows the way home. After 13 years in this game, I've seen enough "hope-based development" to know it doesn't scale.
Vibe Coding vs. Harness Engineering
Lately, the industry has been enamored with "Vibe Coding" — the process of ad-hoc iteration where a developer prompts an LLM, sees if it "feels" right, and keeps poking it until it works. This is fine for a weekend project or a hackathon script, but it is a disaster for SOC 2-style rigor and long-term maintainability.
I am designing my workflows to move past the "vibe" and toward Harness Engineering.
"Without a harness, you aren't engineering; you're just hoping the horse knows the way home."
| Feature | Vibe Coding | Harness Engineering |
|---|---|---|
| Primary Input | Natural language prompts | Intent-first specs & mechanical invariants |
| Validation | "It looks like it works" | Automated test suites & type-safety checks |
| State Management | Long, messy chat histories | Versioned markdown artifacts (PLAN.md) |
| Architecture | Emergent (and often inconsistent) | Rigid, multi-layer domain models |
| Scaling | Fails as context grows | Scales via modularity and "Context Resets" |
The Goal: Mechanical Invariants
The goal of this new era is to build repos that are Agent-Native. We aren't just using AI to help us code; we are building systems where the AI is the primary worker, and our job is to define the "mechanical invariants" — the rules that cannot be broken.
When you stop focusing on the syntax and start focusing on the harness, you realize that the keyboard was never the point. The intent was. My keyboard isn't just a peripheral anymore; it's a legacy device for when the harness fails.