What Is Harness Engineering? A Three-Layer AI Development System
What you’ll learn
- Why conversation alone does not stabilize quality in continuous AI work
- How harness engineering integrates rules, work procedures, and verification
- How to adapt this site’s three-layer structure to place support systems in another project
Harness Engineering Integrates Rules, Procedures, and Verification
Harness engineering designs the rules, work procedures, and verification methods surrounding AI in an ongoing project. On this site, repeated conversational context evolved into role-based management of shared rules, Skills, and automated checks. Separating official product capabilities from the site’s three-layer pattern helps determine which supporting systems another project actually needs.
By the end of this article, you will have practical criteria for answering “What does harness engineering design, and how is it separated from product features?” in your own context.
Design a Harness in Three Layers: Rules, Procedures, and Verification
Using AI to answer one-off questions is quite different from integrating it into an ongoing project. The challenges that surface are different too.
When I started using AI continuously in a project, the same situations kept repeating. When I asked AI in a new conversation to do something it had handled the previous week, it implemented the same task in a different way. When I told it to follow certain rules once, it did not follow them in the next conversation.
The base model does not automatically and permanently retain the contents of a separate session. If product history, Memory, project settings, or external files are unavailable, earlier rules and decisions are not automatically carried into the next session. Claude Code officially documents a way to pass project context through memory files such as CLAUDE.md.[1]
In AI agent work, the broader idea of designing instructions, tools, permissions, environment, validation, and feedback together is sometimes described as an agent harness (a project system of rules, procedures, and validation) or Harness Engineering. In this article, I describe the specific three-layer structure I use for AI Learning Playground.
On this site, I use “Harness Engineering” to mean the combined system of rules, settings, validation, handoff notes, and review practices that help AI work at a consistent quality level. This is my practical term for organizing my workflow, not the official name of a specific vendor feature.
The Harness Name Reflects Its Role in Constraining, Connecting, and Verifying AI Work
A harness is the equipment used to guide and control a horse, directing its energy toward the intended purpose. I use the same word here because the idea is similar: rather than treating AI as a simple question-and-answer tool, I design a system of settings, rules, and procedures that keeps AI moving in the right direction for the project.
The goal is not to change AI itself. It is to arrange what AI refers to so that its behavior stays consistent with the project’s intent across all sessions.
Separating Official Features from This Site’s Design
In this article, the official-feature side means Claude Code using CLAUDE.md as project memory, settings files managing permission and environment behavior, and Claude Code features such as Hooks (automatic actions that run at defined timings, such as before or after a command) and Skills (task-specific instruction and reference packages) being available.[1][2][3][4] Those are vendor-documented Claude Code capabilities.
By contrast, the term “Harness Engineering,” the decision to keep shared rules under shared/, and the three-layer structure that combines CLAUDE.md, shared/, and a lessons log are my way of explaining how this site is operated. They use official features, but Claude Code does not define this three-layer structure as an official pattern.
| Viewpoint | Status |
|---|---|
Using CLAUDE.md for project context | Based on Claude Code official documentation |
| Combining settings, permissions, Hooks, and Skills | Based on Claude Code official features |
Making shared/ the source of truth for common rules | AI Learning Playground-specific design |
| The term “Harness Engineering” | My practical term for this site’s workflow |
| Organizing the setup as three layers | This site’s operating pattern |
This Site Separates Rules, Skills, and Verification into Distinct Layers
On this site, I combine those official features with my own project design and implement the harness in three layers.
1. Project Configuration (CLAUDE.md)
This is the file AI reads first when starting work on the project. It contains the fundamental policies: what AI must not do, what the directory structure looks like, and which commands are permitted. Think of it as the orientation document handed to a new team member.
2. Rules and Skills (shared/ directory)
This is a collection of files covering procedures and constraints for specific types of work. Examples include how to write content, how to deploy, and how to conduct a review. Think of it as the operations manual. AI refers to the relevant file for each task.
3. Lessons Log (lessons.md)
This file records problems that occurred during AI sessions and how they were resolved. When product history or Memory cannot be relied on, the same problem can recur. By having AI read the lessons log at the start of a session, I provide context about past problems so they are less likely to repeat.
Harness Design Can Start from Business Rules and Review Steps
Every component of a harness is a plain Markdown text file. Programming knowledge is not required to design one. If you can describe the rules you want AI to follow, the things it must not do, and the steps you want it to take, you can design a harness.
Without this design in place, each new conversation requires re-explaining the same rules, and AI’s decisions vary from one session to the next.
Summary: Separate Official Capabilities from the Three-Layer Pattern and Add Only What You Need
In this article, Harness Engineering means designing the surrounding system so AI can participate more consistently in an ongoing project, not only answer one-off questions. CLAUDE.md, settings, Hooks, and Skills are based on official product capabilities, while the shared/ source-of-truth design and three-layer structure are AI Learning Playground-specific patterns. Keeping that boundary visible makes it easier to decide what readers can expect from the product itself and what they need to design for their own project. Related examples are covered in Writing CLAUDE.md and What It Changes, Choosing Between AI Agent Skills and Instruction Files, and Designing a shared/ Directory.
Start with one premise you currently repeat to AI and decide whether it belongs in a rule, work procedure, or verification check. The three-layer structure is an AI Learning Playground pattern, not an official architecture shared by every product or project.
References
- Anthropic, How Claude remembers your project, Claude Code Docs
- Anthropic, Claude Code settings, Claude Code Docs
- Anthropic, Hooks reference, Claude Code Docs
- Anthropic, Extend Claude with skills, Claude Code Docs
For the latest releases and updates, check the official website and official documentation.