Why I Want to Work on Harness Engineering

Let me say it plainly

The direction I most want to invest in long term is Harness Engineering.

Here, harness is not a decorative new term. It means the engineering frame around an AI agent when it actually runs: what tools it may call, what it must not touch, how it keeps memory across sessions, how multiple agents collaborate, and how the system knows whether the agent really did the job instead of merely looking convincing.

Models will keep getting stronger. Writing code, searching material and generating plans will keep getting cheaper. The more that happens, the less sense it makes to anchor my value in “I can make the model output a little more.” The thing worth betting on is different: can I put the model inside a reliable working system?

That is what I mean by Harness Engineering.

My starting point is engineering, not research

My core stack is Vue 3 / TypeScript, and I am extending into Next.js / NestJS full stack work. For a long time, my value showed up mainly in implementation: breaking down requirements, building the interface, wiring the API, making the system run.

After AI-assisted coding, that ceiling is getting lower. Frontend is not becoming unimportant, but “being able to write it” is becoming less scarce. Agents can write a lot of code for me, and even work on multiple branches in parallel. That change forced me to ask again: three years from now, what will actually separate me from others?

My answer is not to chase a grander platform story, and not to dive straight into model training. Neither is the best hand I currently hold.

I am better suited to start from engineering systems: take a fuzzy agent-collaboration problem and break it into boundaries, protocols, memory, verification and tool contracts, then validate each layer through real projects.

Four real projects, four layers

The posts on this blog are not a random pile of takes. They map to experiments I am doing or have done.

Nestwork validates memory and collaboration protocols.
I use Git to synchronize one set of rules, strategy and memory across multiple machines and agents. Each agent has its own directory, humans maintain the read-only governance layer, and shared memory is produced through distillation. This is not for showing off. It solves a concrete problem: an agent cannot live only inside one conversation. It needs a cross-machine, cross-session source of truth.

A2A mesh validates the real-time data plane.
Git mailbox is good for slow handoff, but not for second-level calls. So I connected agents across machines through A2A and worker-pull. The real difficulty was not the protocol itself, but NAT, persistence, security and result writeback. After getting it to work, I became more convinced that connectivity is only the entry ticket; the next layer has to be verification.

cheat-on-content validates calibration loops.
Content creation looks unrelated to agents, but the underlying problem is the same: when facing a black-box system, you cannot rely on hindsight explanations to comfort yourself. You need to predict up front, lock the prediction, collect real data, review the gap and iterate the rubric. It is verifiability applied to content work.

Duovid validates small-tool product discipline.
It is not a grand AI platform. It is one concrete problem: shoot once, output both landscape and vertical. This project reminds me that indie development should not keep getting pulled into platform temptation. A small, verifiable tool is often a better way to test real demand.

The real thread: boundaries and pain for agents

Put these projects together and the thread becomes clear:

• Nestwork answers how agents remember and hand work off;
• A2A mesh answers how agents call each other across machines in real time;
• cheat-on-content answers how an uncertain system gets calibrated;
• Duovid answers how a tool-shaped product validates value with restraint.

They look scattered, but they serve the same goal: moving from “I can use agents” toward “I can design agent systems.”

The most important layer is verification.

An agent system without verification is dangerous. It can run for a long time, produce a lot, look busy, and still be wrong without knowing it. When a human is watching, there is still a fallback. Once agent count rises and runtime stretches, the human becomes the bottleneck. The system needs a sense of pain: every task should carry a machine-checkable acceptance contract, results should be reviewable, and wrong results should trigger correction.

That is the shortfall I most want to close next.

How to read this blog

If you want the direction judgment, read this post first, then read “From Frontend to Harness Engineering.”

If you want the concrete projects, read Nestwork, A2A mesh, cheat-on-content and Duovid.

If you want my view on developer capability in the AI era, read the capability ladder, CS fundamentals and the net advantages humans still have over AI.

This is not a finished answer set. It is closer to a public engineering log: I write down a judgment, test it through projects, and wait for reality to prove me wrong. Being wrong is not the problem. Having no record, no calibration and no next move is the problem.

Harness Engineering is not a title to me. It is a practice route: less vague AI commentary, more systems that run, can be verified and can be reviewed.