Harness Engineering
A coding agent is more than a model. It is a model plus its harness: the tools, hooks, checks, review loops and memory around it. Harness Engineering is the industry’s term for working on that. This page is our version of it, written down, including the rules we hold ourselves to.
Fast code still has to be good code.
AI made writing code cheap: minutes instead of days. That moved the bottleneck rather than removing it. The question is no longer whether the code can be produced; it is whether you can trust what was produced.
That is a systems problem rather than a prompt problem, and systems problems are exactly what software engineers are for. We happen to enjoy them, too.
LangChain moved its Deep Agents from outside the top thirty into the top five on Terminal-Bench 2.0 by changing only the harness. Same model, same weights. Their result, not ours. We cite it because it changed where we put our own engineering effort.
LangChain · Terminal-Bench 2.0From work item to pull request. An engineer decides.
This is how the SaaS Factory builds, for every product and every client. Agents do the routine work from work item to pull request: reading, sorting, writing the test, writing the code, running every suite. Our engineers keep the decisions, the review and the final say.
From ready to merged
On any doubt, failure, disagreement or exhausted budget the line stops and the item goes to a person. Never a retry loop, never a merge.
a person actsThe limits are enforced in the environment, not in a document, so they hold even when an agent ignores its instructions. Every run is capped and logged, and a person can stop any step with one switch.
The writer and the reviewer are two different agents.
Agents are good at writing code. It is just that everyone, human or agent, is too kind to their own work. So the rule is simple: the writer never reviews its own work.
Implements the spec. Has the context, the tools and the memory, but no authority to approve anything.
Reviews it critically against our definition of done and sends it back. The loop runs until the criteria are met.
The deterministic checks run throughout, on every commit. Together with the evaluator loop they decide when a change is ready to be looked at. Only then does a person review it, faster and with more signal, because the noise is already gone. The gate makes human review better; the person keeps the last word.
Code merges when the gate says so.
Every change goes through the same four checkpoints before it merges: two automated checks that run all the time, one AI agent and one person. No shortcuts, and no merging on gut feeling.
Here is an actual gate.
This is what a gate looks like on a real engagement: one page, agreed with the client before the first commit, with the same five checks every SaaS Factory release passes — build and tests, static analysis and security, a skeptical review, mutation on new tests, and scope. From then on it is the referee. Yours will differ in its thresholds, because it is written from your standards.
The gate as it stands in the repository, in English.
- AUTObuild & tests: the build succeeds, warnings treated as errors
- AUTObuild & tests: every test green, on a clean checkout
- AUTOstatic analysis & security: analysis clean, no new findings above the agreed threshold
- AUTOstatic analysis & security: dependency and secret scan clean, OWASP baseline passed
- AUTOmutation on new tests: every new test goes red when the code it tests is mutated
- AGENTsceptical review: a second agent, against the written definition of done
- HUMANscope: named engineer signs; product owner accepts the scope
- ONevery file write by an agent
- IFpath matches migrations/ or infra/
- THENblock, print the rule, require a human
- IFcommand contains a destructive delete
- THENblock. no override flag exists
- ELSEsilence
Success is silent, failure is verbose. The agent reads the rule it broke and fixes itself before a person needs to look.
Agentic technical debt is invisible.
AI-written code looks clean. It passes every check you happen to have, while the team gradually loses sight of what actually shipped.
Every mistake becomes a rule.
Quality is locked into a codebase one notch at a time. Every rule in our harness traces back to a real failure. When a better model makes a rule redundant, we delete it. A harness is engineered, and kept small.
Entry
The harness is half the story. The other half is that our agents inherit twenty years of architecture instead of reinventing it: building blocks, a blueprint and code generation for .NET and Angular, public under Apache-2.0 so you can read it first.
Twenty years, searchable
Architecture decisions, hard-won lessons and the reasoning behind twenty years of choices, captured and structured. The same knowledge feeds our agents’ context, so they build like people who have been here for years.
A team alongside yours, under your lead, behind your gate.
You have a product owner and a backlog, and what you need is capacity that ships behind a gate rather than a project with a start and an end. Our engineers work from Rotterdam, Belgrade and Novi Sad: one company, one set of employment contracts, no time difference, and the same ISO 27001 controls in all three offices.
A team with a lead of its own, working in your backlog under your product owner, with the harness and the gates on your pipeline from the first week. It is billed monthly and you can stop at any time. The gate and the code stay in your repository.
See it on your own code.
Five days and you have a fixed quote for a secure MVP; six weeks and it runs in European production. An app you already built with AI gets a Hardening Audit first.
The method is public. The judgement took twenty years.
The gate is on this page, the foundation is Apache-2.0, and the review loop fits in four paragraphs. What took twenty years is knowing which failures matter in your domain. That part we would rather do next to your team than write down.
Agents write · checks block · an engineer decides