Harness Engineering

High-level concept

Harness Engineering is an experiment in making my development process explicit enough that it can be followed, checked, and improved without depending on memory or tribal knowledge. The goal is not to remove judgment. It is to move the repeatable parts of the work into written rules, automated checks, and clear boundaries.

The project is inspired by OpenAI’s article on harness engineering, but the local question is practical: what parts of my own workflow can be encoded so agentic development becomes safer and less ad hoc?

A central hypothesis is that breaking behavioral changes cause most bugs. If I can define compatibility rules, keep test coverage strong at the boundaries, and prefer non-breaking changes by default, then I may be able to move faster without constantly risking regressions.

The notes that shape this project are Minimal process, Planning and implementation, Architecture for small tools, and Defining success. Together they keep the structure small, make the rules explicit, and measure whether the system actually helps.

Detailed steps

• Document my current workflow step by step.
• Identify the implicit rules I currently keep in my head.
• Decide which rules should become documentation, templates, or automated checks.
• Define the boundary tests and compatibility checks that catch behavioral regressions.
• Separate safe non-breaking changes from changes that need extra scrutiny.
• Apply the harness to one real project and observe what helps and what slows things down.
• Revise the harness based on evidence rather than preference.

Step 1: Map the current workflow

Write down how I actually work today: what I check before coding, what I verify while implementing, and what I inspect before merging or shipping. The goal is to surface the hidden process that already exists.

Step 2: Encode the rules

Turn repeated decisions into explicit artifacts:

• project templates
• checklists
• test fixtures
• lint or validation rules
• repository conventions
• prompts or agent instructions

The target is to make the default path obvious and the exception path visible.

Step 3: Guard the boundaries

Focus test coverage where behavior crosses a boundary: inputs, outputs, integrations, contracts, and state transitions. The idea is to make non-breaking change the easiest path and make accidental breakage hard to miss.

Step 4: Measure the effect

Track whether the harness reduces ambiguity, lowers review effort, and makes agentic work more reliable. Keep the parts that improve the system and cut the parts that only add ceremony.