Series · MoAI ADK and Harness Engineering
Episode 1 · MoAI ADK and Harness Engineering 1 - The AI Development Manual
MoAI ADK and Harness Engineering 1 - The AI Development Manual
I use a MoAI harness on projects that combine modern web applications, current Spring Boot services and Flutter apps. I first understood it as a collection of manuals for AI coding. Practice showed that this was only half the picture. Documentation is central, but a useful harness also decomposes work, constrains tools and uses test evidence to choose the next action.
The name needs one correction: in the official MoAI ADK repository, ADK means Agentic Development Kit, not AI Development Kit. It is a SPEC-first kit for organizing coding agents in a real repository, not a kit for training a new model.
One acronym, several different layers
| Product or category | Primary purpose | Relationship to project code |
|---|---|---|
| MoAI ADK | Development harness for specs, roles, workflows and verification | Governs repository-wide development |
| Google ADK | Build, evaluate and deploy user-facing agents | Embedded in an application runtime |
| OpenAI Agents SDK | Tool use, handoffs and traces | Embedded in Python or TypeScript apps |
| Microsoft Agent Framework and LangGraph | Stateful multi-agent workflows | Service execution frameworks |
| Claude Code, Codex and Gemini CLI | Coding agents that inspect and modify repositories | Engines that execute harness rules |
MoAI and Google ADK therefore should not be compared as direct substitutes. The latter helps build an agent inside a product. MoAI constructs the workshop around agents that build the product. Claude Code is the worker; MoAI is the procedure, blueprint and inspection station.
Four layers turn manuals into a harness
The practical structure has four layers:
- Knowledge: product goals, structure, stack, domain model, database and code maps.
- Contracts: SPECs, acceptance criteria, coding guidance, architecture boundaries and Git rules.
- Execution: plan, implementation, repair, review, E2E and synchronization commands invoking specialist agents and tools.
- Verification: builds, static analysis, unit, integration and E2E tests plus quality gates.
Documents alone can be acknowledged and then forgotten by a model. Tests alone can encourage an agent to chase green output without understanding the design. Declarative guidance and executable verification must work together.
Why SPEC-first is stronger than a prompt
A prompt disappears into a conversation. A SPEC stays in the repository. Breaking requirements into scenarios, domain rules, affected components, tests and acceptance evidence lets another session or model begin from the same contract.
Instead of “implement order cancellation,” a harness can define:
- state transitions and refund responsibility before and after settlement;
- dependency direction across Spring Boot application, domain and infrastructure layers;
- an API schema and errors shared by web and Flutter clients;
- migration, retry and idempotency requirements;
- completion criteria for unit, integration, contract and UI tests.
This does not eliminate agent freedom. It separates the area available for exploration from boundaries that must not break, addressing the structural weakness discussed in our vibe-coding analysis.
How MoAI relates to harness engineering
Harness engineering treats agent performance as more than a model score. Context delivery, tools, persistence, observability, verification and recovery form a runtime system. Research such as AI Harness Engineering and observability-driven harness evolution now treats that system as an engineering object.
MoAI applies the idea to a development repository: context maps locate evidence, session state survives longer work, and checklists plus self-verification expose failure. Language-aware tools and scaffolding-first workflows support the loop. Agent and skill counts change across releases; the stable point is the closed cycle of specification, implementation, verification and documentation synchronization.
How model-independent is it?
MoAI's strongest idea is investing in project memory rather than one model. Domain documents, SPECs, architecture decisions, tests and Git history survive a move between coding agents. This repository, for example, keeps Claude Code assets as the source of truth while a Codex adapter reads the same instructions.
“Completely independent” would still be an exaggeration. Command syntax, hooks, context capacity, team-agent features and permissions differ by runtime.
Precise assessment: knowledge, contracts and verification are model-independent; commands, hooks and tool invocation need adapters.
That division preserves team assets when model fashions change. It also explains why a repository contract should precede adoption of Claude Code or a GitHub Copilot agent workflow.
Part 2 examines how our team reached 100% AI-assisted development and zero manually typed production code, along with the analysis, review and testing that humans must still own.
No comments:
Post a Comment