Chapter 6 · Capstone: Build Your Harness · Lesson 6.4

Adapt, Don't Copy

This course is a set of principles, not a template. Keep the universal parts; tune the rest to your stack, your team, and your model.

Chapter 0 · Sprint Zero
Chapter 1 · The ratchet & the practice loop
Chapter 2 · Spec-driven development in depth
Chapter 3 · Scaling & trusting the harness
Chapter 4 · Measuring & evolving the harness
Chapter 5 · Multi-agent & team harnesses
6.1 · Your starter harness
6.2 · One feature, end to end
6.3 · The first-week ratchet plan
6.4 · Adapt, don't copy
6.5 · Staying current & your capstone

The trap: copy someone else's harness

You will be tempted to grab a harness that impressed you online - their 200-line rules file, their agent swarm, their exact set of hooks - and drop it into your project whole. That usually hurts. A harness encodes assumptions about a specific model, a specific stack, and a specific team (recap Lesson 0.2: every component compensates for a weakness that setup had). Their assumptions are not yours.

"A harness is a local artifact, not a universal template." after Addy Osmani, Agent Harness Engineering

Keep the universal, adapt the local

So how do you tell what to take? Split it in two. Some things are laws of the practice and hold everywhere. Everything else is a choice that depends on your situation.

Keep vs adapt

KEEP - these are universal:

The ratchet - fix the harness after a real failure, not just the prompt.
Earn every line - each rule traces to a specific thing that went wrong.
Enforce, don't instruct - what must happen every time belongs in a hook, not a sentence.
Measure before you keep a change - a change earns its place only if it helps.
Independent review - a second lens catches what the author's does not.

ADAPT - these depend on YOU:

Which hooks you actually wire up - your language, your CI, your danger zones.
How many tools you expose - a lean menu for a small repo, more for a sprawling one.
Greenfield vs brownfield spec-driven workflow (Lesson 0.3) - a fresh repo and a legacy one want different specs.
How much team governance you need (Lesson 5.5) - a solo dev needs far less than a ten-person team.
Whether you even need multi-agent (Lesson 5.1) - most work is a single agent in a loop.

What not to copy blindly

Three imports look like shortcuts and are really someone else's baggage:

A huge borrowed rules file. Every line is their earned failures, not yours. Pasted in, most of it is noise that competes for the model's attention and invites harness drift - the slow bloat of unearned rules and stale scaffolding.
A swarm of agents "because it looked cool". Multi-agent adds real coordination cost (Lesson 5.1). Reach for it only when a single agent genuinely can't do the job.
Scaffolding a newer model has already outgrown. Much of a 2023 harness is dead code by 2026 - the disposability point from Lessons 0.2 and 3.5. Copying it re-installs weight the model no longer needs.

The bitter-lesson frame

Here is the frame that ties it together. Your harness is a 2026 artifact. Build for the model you have today, and design so scaffolding is easy to rip out as models improve - not something you defend forever. That is why harness engineering is a judgement practice, not a checklist to clone. The principles transfer; the specific build is disposable by design.

"Design for disposability - build for the model you have, and rip scaffolding out as the model improves." after Addy Osmani, Agent Harness Engineering

Check yourself

Copying a whole harness wholesale usually -

A harness encodes assumptions about a specific model, stack, and team. Lift it whole and you inherit assumptions that may not hold for you - which is why it's a local artifact, not a template.

Which of these transfers everywhere -

Universal: the ratchet, earn-every-line, enforce-don't-instruct, measure-before-you-keep, and independent review. The specific hooks, the rules file, and the swarm are context you adapt or skip.

Your 2026 harness should be built -

It's a 2026 artifact. Design for disposability: add structure where today's model is weak, then pull it out as models improve. A harness you defend forever is one you copied instead of engineered.

Do this now (5 min)

Name one thing from this whole course you will deliberately NOT adopt - because it doesn't fit your stack, your team, or the model you use. Write one sentence on why. (For example: "No multi-agent swarm - I work solo on a small repo and a single agent covers it.") Knowing what to skip is the skill. That judgement is harness engineering.

I'm your teacher - ask freely. Not sure whether a piece you like is universal or just context? Paste it and tell me your stack, team size, and model - I'll help you sort keep from adapt.

Go deeper

Primary source (read this): Addy Osmani - Agent Harness Engineering. The case for the harness as a deliberately tightened, disposable artifact.

Secondary: My Experiments With AI - "Why the harness", on why the wrapper, not the model, decides your results.

Wisdom (test it on people): r/ChatGPTCoding - a good place to watch borrowed setups collide with real, different stacks.

← 6.3 The first-week ratchet plan Course map Glossary Next: 6.5 Staying current & your capstone →