In the previous article, we described the framework and overall design of Harness: a robust software engineering design that constrains AI to work stably within engineering. Open-source repository: cow-harness

AI Harness Enterprise Implementation Practice (Part 1)

This article continues to explore how a team can grow into AI full-stack development, capable of simultaneously maintaining code across multiple platforms such as apps, backends, and web pages.

In the AI era, we believe that programmers should not be limited to a single technology. They should view the entire project with a top-level mindset, understanding the design and data flow of the whole system.
This not only improves an individual's breadth of knowledge but also enables them to independently and efficiently complete specific modules, thereby accelerating product iteration and enabling rapid idea validation.

1. Top-Level Design Thinking

To achieve AI full-stack development, you must first:

• Centrally manage our full-stack projects
• Let AI deeply understand the code style, framework layering, and design philosophy of each sub-project, and solidify this understanding

This leads to:

• Regardless of the model, it can quickly know which specific platform your requirement needs to touch
• The generated code matches the platform's style without low-level mistakes
• After writing, it can automatically start each platform and perform cross-platform end-to-end (e2e) full-process testing

2. Project Structure Based on Git Submodules

For full-stack collaboration scenarios, platforms like apps, backends, and web pages each have their own independent code repositories, with different iteration rhythms and branch management strategies.

Therefore, we first maintain a composite root repository, bringing business sub-projects together using Git submodules. A common structure looks like this:

fullstack-workspace/
├── cow-harness/                    # Full-stack entry point and common Harness
├── .ai-harness/
│   └── workspace-map.md            # Business module map
├── apps/mobile/                    # App code (git submodule)
├── services/backend/               # Backend code (git submodule)
└── apps/web/                       # Web code (git submodule)
│ 
└── .gitmodules     

.gitmodules

• Records the repository source and local path, and the root repository records the branch each sub-repository should be on at this moment. This way, anyone on the team who pulls the root repository gets the same set of front-end and back-end code versions.
• Submodules themselves do not affect the branching strategy of the sub-projects; branch conventions, commit habits, and code directories are still maintained by each sub-repository.

workspace-map.md

• Catalogs which domain each sub-project belongs to, whether it has been initialized, etc.
• A map that answers "where should this task go first?"

3. Letting AI Deeply Understand the Entire Project

"Understanding" does not mean having AI scan the entire repository and then write a professional-looking summary; it means very precisely knowing the design, style, specification constraints, security, and performance indicators of each project.

For this purpose, we specifically wrote a SKILL for this step: domain-init.

This SKILL has very complete project identification capabilities. It is not only integrated into cow-harness but also open-sourced independently. Get it here if needed: https://github.com/MinLeeV5/domain-init-skill/tree/main

1. Introduction

domain-init first performs domain identification: it looks for signals in build files, dependencies, entry points, testing tools, and directory structures to determine which platform the current project is (e.g., closer to a React frontend, Go backend, mobile, CLI...).

After determining the domain, it samples real code, identifies the architectural design, component conventions, interface layering, test fixtures, and verification commands already in use by the project, and then turns these facts into reviewable rule drafts.

Core point: Code is the source of truth; rules are merely a structured expression of the facts.

2. Four Principles

Principle	Problem It Solves
Signal Priority	First determine the domain based on dependencies, entry points, and build files in the project, avoiding the misapplication of a frontend specification to a backend or client.
Evidence First	Every convention must be traceable back to the project code, preventing the model from creating rules that are "theoretically correct but wrong for the project" based on memory.
Filter by Domain	The frontend focuses on design systems, state, and accessibility; the backend focuses on interfaces, data, and observability. Only relevant items enter the context.
Human in the Loop	There are confirmation points for domain judgment, scanning scope, rule drafts, and final writes. AI is responsible for induction; humans are responsible for judging what is a convention and what is just historical baggage.

3. Best Practices

If you only extract from an existing project, there is another risk: the original project might not be well-designed, and then the AI will write increasingly poor code following that specification.

Therefore, domain-init also provides some best-practice references.

Reference File	Design Role	Avoids
detection-signals.md	Defines the priority, fallback path, and human confirmation mechanism for domain identification.	Guessing the project type wrong.
domain-matrix.md and dimension-pool.md	Uses a domain matrix to filter the applicable dimensions for rules, Skills, and Agents.	Dumping all governance dimensions onto every project at once.
project-index.md	Specifies open-source quality benchmarks and key reference files for different problems.	Only applying vague "best practices."
output-formats.md	Specifies the structure, code examples, and evidence requirements for rules, skills, and agents.	Generating artifacts that are just slogans with no executability.

project-index.md: A critical quality index that references a large number of excellent practices. For different problems, we look for different benchmarks. For example:

• For coding conventions, refer to the language-specific rules of everything-claude-code
• For frontend performance and component architecture, refer to Vercel's agent skills
• For testing strategies and verification gates, look at get-shit-done
• For security reviews, there are the workflows of gstack and Trail of Bits

At the same time, when using these excellent practices, the point is not to copy the content from other people's repositories. The core is to let AI learn how they organize rules, express hard constraints, and write verification into the process; then return to the code facts of the current project and generate content suitable for itself.

Verification chain: Domain judgment has signals, rule conclusions have code evidence, artifact quality has benchmarks, and there is a human review before writing to disk.

4. Initialization Artifacts

After initialization is complete, each sub-project will have a set of assets that can be repeatedly read by subsequent tasks. These assets are not placed in the composite root repository but in their respective business sub-projects.

services/backend/
├── AGENTS.md                       # AI's entry point into the project
├── cow-harness/
│   └── skills/domain-init/          # Nested domain initialization skill
├── .ai-harness/
│   ├── project.profile.md           # Project profile
│   ├── context-map.md               # Modules, entry points, and boundaries
│   ├── verification.md              # Verification methods and commands
│   └── domain-init-report.md        # Detection basis, confirmed scope, and results
├── .agents/                         # Platform rules, skills, and agents selected for the current project
└── .ai-runtime-artifacts/           # Requirements, plans, verification, and decision records

project.profile.md: Answers "what is this project, and what are the key constraints?";

context-map.md: Answers "where should the code be changed, and where are the boundaries?";

verification.md: Answers "how to prove it works after the change."

Additionally, some model-layer entry points are produced:

domain-init-report.md: Preserves the basis for domain judgment, the user-confirmed scope, and the generated results, preventing these conclusions from becoming an unaccountable black box;

.agents/: The rules, skills, and agents that this project will actually load for AI;

.ai-runtime-artifacts/: Saves requirement analysis, plans, verification records, and architectural decisions.

5. How to Execute Tasks After Initialization

When a task enters from the full-stack composite root directory:

1. AI first reads workspace-map.md
2. If the task contains explicit project paths, module names, interface names, or screen names, these clues are used to locate the business sub-project
3. Combining multiple related projects, it begins to assess the task's scope and decides whether to decompose it into specs
4. Once a project is selected, the reading order is fixed: first enter the project through AGENTS.md, then load the common processes of cow-harness/core/, as well as the current project's project.profile.md, context-map.md, and verification.md
5. Then the AI follows the harness specification to use superpower and omx to start working

6. Quick Start

1. Maintain the full-stack composite repository and first pull all submodules to the version locked by the composite root repository:

git submodule update --init --recursive
git submodule status --recursive

1. Add cow-harness as a submodule to your project:

git submodule add [email protected]:WxqKb/cow-harness.git cow-harness
git submodule update --init --recursive

1. Next, let cow-harness start initializing sub-projects for you:

Please first read cow-harness/README.md, cow-harness/init/fullstack-bootstrap.prompt.md,
and cow-harness/skills/domain-init/SKILL.md.

This is a full-stack project composed of multiple business sub-projects. Please first run
git submodule status --recursive to distinguish business sub-projects, Harness, and third-party dependencies;
show the candidate business sub-projects and wait for my selection. Only initialize the sub-projects I confirm,
do not generate mixed domain rules in the composite root directory, and do not automatically rewrite unselected sub-projects.

7. Final Thoughts

In reality, with the efforts of major foundation models in coding, the impact of AI on the programmer profession is lethal, and the feeling is very obvious in large companies.

For example: a one-sentence requirement can let AI fully understand and break it down, quickly build A/B solutions, and publish them for angel user testing. This process verification might have taken a week in the past, but AI + Harness can get it done in 2 days. And this kind of efficiency improvement generates undeniable value for individuals and businesses, and it is no longer a pipe dream.

To put it bluntly, Harness full-stack will also displace a wave of people.

But what the author wants to say is that in this environment, we should try our best to grow. When coding skills are no longer a barrier, we should use AI more quickly, letting AI comprehensively broaden our knowledge and business boundaries. Solidify this into our core competitiveness, and I believe that when the environment improves, you will still be the hot commodity~