← BLOG
André SpineliAndré Spineli
July 12, 2026

Harness engineering and homogeneous architecture

harness engineeringplatform engineeringlldai

DevStation is TypeScript running on Deno. harness is Go. Both follow the same low-level design: hexagonal architecture, isolated bounded contexts, commands separated from queries, ports defined by the consumer. And in both, most of the code was written by agents. What caught my attention was not an agent writing code, it was the second project costing a fraction of the first to reach the same structural quality. This article is about what made that difference, and about where I think this kind of solution should live inside a company.

In theory, documenting the pattern and following it would be enough. In practice, everyone who has ever maintained an architecture guide knows how that ends: the document ages, each team reads it its own way, and six months later there are four dialects of the same pattern. The problem was never deciding the architecture, it was keeping it equal to itself, change after change, person after person.

Artifacts: rules, skills and agents

In the harness engineering I have been practicing, patterns stop being documents and become versioned artifacts that agents load: rules for what always applies, skills for on-demand knowledge, agents for specific roles. The difference from a traditional guide is practical: the artifact enters the agent’s context at the moment it works, and we can enforce the result at build time with architecture tests. The classic guide depends on someone remembering to read it. The artifact gets loaded whether the reader feels like it or not.

It is also what I have been applying with development teams: ADRs and technical guidelines that already existed become the raw material for rules, skills and guardrails. The architectural decision remains the important record, what changes is that it takes a shape an agent can obey.

Abstract skills, concrete capabilities

The piece that made the second project cheap was the separation between concept and implementation. The low-level design skill I use defines stack-agnostic contracts: what a bounded context is, where invariants live, how commands and queries separate, what a port is and who defines it. A capability per stack implements those contracts, and the library currently holds lld-typescript, lld-go and lld-php. lld-go, for example, translates the same concepts into idiomatic Go, with packages by feature instead of directories by layer and consumer-defined interfaces, while lld-typescript keeps the shapes DevStation uses.

Translation, not transliteration: the concept survives as a role, the form follows the language of the stack. When I started harness in Go, none of the theory had to be re-decided. I loaded the abstract skill, loaded the Go capability, and the agent produced the same shapes in another dialect. The theory ended up reasonably packaged: an artifact that reproduces across different projects with different stacks, without depending on me re-explaining the design at every project start.

The tool

For this to work across more than one project, the artifacts need to live outside of them. harness is an open source CLI that manages these artifacts across projects: it merges a personal library with each project’s local artifacts, lets you pick what each project needs in a TUI (an interface that runs in the terminal itself), composes stack-agnostic skills with per-stack implementations and generates the AGENTS.md that tells the agent what to always load and what to load on demand. Artifact libraries can live in git repositories added as sources, so a pattern fixed in the library propagates, instead of silently diverging in every copy.

Some honesty about scope is due: today it is a pilot, focused on sharing between my own projects. The thesis of this article is bigger than the tool, and the tool is the part of the thesis I can test on my own.

Agents follow rules better than I do

Here is the part that changed my expectations about all of this: LLMs are probably better than humans at following explicit rules. Not at judgment, at obedience. An experienced engineer questions the rule, forgets the rule, decides that today the rule is not needed. An agent with the rule loaded applies it the thousandth time with the same disposition as the first, not least because disposition is not a problem it has. The bottleneck moves: it stops being making sure the rule is followed and becomes writing rules worth following.

Homogeneous architecture in distributed environments

So far, personal projects. My bet is that the same design is worth more in distributed corporate environments, where the cost of variation is multiplied. When N teams share the same artifacts, people move between teams without relearning the local dialect, code review crosses team boundaries, and the company stops paying several times for the same engineering solution. It is not uniformity for its own sake: it is reducing variation where variation produces no value, which leaves energy exactly for the problems where a team needs to diverge.

I also have an observation, still without rigorous measurement: productivity gains with AI show up more in teams with well-defined responsibilities and contexts separated by product. It makes sense for the same reason bounded contexts do, a clear boundary reduces what the agent needs to load in order to act. But I record it as the observation of someone applying this, not as a measured result.

Where this should live: platform teams

In my view, this kind of solution should emerge from platform teams, in the Team Topologies sense: teams that solve common problems and build internal products for the product-aligned engineering teams. It is the same movement developer experience has been making for years with internal CLIs, golden paths for deploys and bootstrapping new applications, and developer portals with a service catalog, which is what tools like Backstage do. With harness it is no different: the library of rules and skills is one more internal product, with usage measured, feedback collected and evolution prioritized by the teams’ own demand.

And like every platform product, it does not have to be a monopoly. A product team can evolve the platform when the need is exclusively its own priority, as long as the platform team agrees and reviews the change. It is the internal contribution model that already works for the rest of the tooling, applied to harness artifacts.

The same logic, other problems

Agent artifacts are just the first product on that shelf. The same platform logic extends to curated knowledge, RAG over internal documentation, ADRs and business-rule catalogs, where the hard problem is not the search, it is keeping the base alive, and that is product work with an owner. It extends to internal MCPs exposing deploys, feature flags, observability and the service catalog as tools: the usual golden path, with the difference that the consumer is now an agent. And it extends to agents as internal products beyond engineering, querying metrics in natural language, supporting incidents with runbooks, summarizing postmortems, with guardrails proportional to readers who trust what they read.

There is also the workflow layer, breaking down deliverables, prioritization, estimates. Here I move with more caution: as a supporting draft it works, but an AI-generated estimate presented as a number becomes a commitment too fast, and estimating was already a hard problem before AI. Each of these topics would deserve an article of its own, and some still will.

What I can say so far

Back to the two projects from the opening. What I can say today is that, across my own projects, packaging the theory into abstract skills and per-stack capabilities made the second implementation cost a fraction of the first, with the same structure verified by architecture tests in both. That this scales to an entire organization is the bet, not the fact: it depends on a library with an owner, honest usage measurement and platform teams treating agent artifacts as a product, not as a wiki. Which is exactly the kind of bet a platform team exists to test.

References