Notes on building software with AI without going soft: how to delegate the work while keeping the thinking.

the frame

Harness engineering is the spine. Every philosophy is really a bet on one of its components:

  • Guides (feed-forward): pseudocode, spec-driven, SPDD, memory and rules
  • Sensors (feedback): tests and contracts, evals, formal proof
  • Loop (orchestration): human-on-the-loop, multi-agent
  • Vibe = no harness (eyeball the output). Formal spec = two at once (its spec is a guide, its verifier is a sensor).

Under all of it, one question keeps you honest: are you keeping the thinking (intent, algorithm, verification) and delegating only the work?

the map

Harness engineering as the spine, with each philosophy plugging into a component A top bar labeled harness engineering feeds three columns: guides (feed-forward), sensors (feedback), and loop (orchestration). Guides holds pseudocode, light spec, SPDD, spec-driven, memory and rules. Sensors holds tests and contracts, evals, formal proof. Loop holds human-on-the-loop and multi-agent. Vibe is no harness; the hybrid uses guides plus sensors. Harness engineering the spine every philosophy plugs into Guides · feed-forward Sensors · feedback Loop · orchestration pseudocode light spec SPDD spec-driven memory / rules tests / contracts evals formal proof human-on-the-loop multi-agent Vibe coding = no harness: skip the guides and sensors, just eyeball the output. Hybrid = pseudocode + light spec (guides) + tests (sensors): the smallest balanced harness. Formal spec plugs into two slots at once: its spec is a guide, its verifier is a sensor.

start here

  1. Harness engineering - the spine. Why we need it, and what each component (guides, sensors, loop) is for. Start here.
  2. The ladder - the philosophies grouped by the component they plug into, the two scoring framings, and the hybrid. With interactive plots.
  3. Context & memory architecture - a deep dive on the guides / feed-forward component.

the through-line

The hybrid you land on (pseudocode + tests + light spec) is not separate from the harness. Its tests are the harness’s sensors and its spec is a guide. Choosing how you specify is partly building the environment that checks the work.

the larger question

All of this is linked to a much wider question one I keep circling: what makes a good system?