From Frontend to Harness Engineering: The Three-Year Direction I Set for Myself
Let me admit something first
I have a reasonably honest read on myself: my ability to build outpaces my ability to design systems. Give me clear boundaries and I’ll ship something usable fast. Ask me to design a high-complexity, governance-heavy platform from scratch, and I’ll struggle.
That bit of self-awareness matters—it directly determines where I should go and where I shouldn’t. I’m not suited to taking on big platform architecture right out of the gate. I’m a much better fit for small tools and automation workflows with clean boundaries, shoring up my system-design weaknesses as I go.
Vue is my main stack, but I don’t want to stop at “building UIs”
My main stack is Vue 3 / TypeScript, extending into Next.js / NestJS for full-stack work. These skills can pay the bills, but there’s a problem: their ceiling is being pushed down by AI.
More and more people can build CRUD interfaces, and with AI assistance the bar for implementing small-to-medium full-stack systems is dropping fast. If my entire moat is “I can write pages in Vue,” that moat gets narrower every year.
So the question isn’t “what can I do?”—it’s “what will still be scarce three years from now?”
The bet: Harness Engineering
My answer is Harness Engineering—designing the “frame” an AI agent runs inside:
- Which tools it can call and what it must never touch (capability boundaries);
- How it remembers things across sessions and across machines (memory);
- How multiple agents collaborate without stepping on each other (collaboration protocols);
- How you verify it actually did the right thing, rather than just looking like it did (verifiability).
Why bet on this?
- It’s scarce. The big labs are grinding away at the models themselves, but “how do you wrap a model in a reliable, auditable, collaboration-capable shell”—that problem is nowhere near solved, and the engineering content is enormous.
- It rewards engineering, not genius. That happens to be my strength zone: take a fuzzy collaboration problem, break it into small modules with clean boundaries, then verify and evolve them one at a time.
- It compounds. Every layer of harness you build makes the next agent task easier. That’s a completely different game from “implement one feature, one time.”
What I’m already doing
This direction isn’t wishful thinking—it has concrete handholds. Over the past few months I’ve landed it on two specific projects:
- nestwork: using Git to sync a growing “brain” across multiple machines and multiple agents—this is the “memory” and “collaboration protocol” layers.
- cheat-on-content: a self-calibrating content operations workflow, built around “blind prediction + rubric iteration”—this is “verifiability” applied to the content domain.
One leans toward tooling and the other toward content, but at their core they’re the same thing: taking an agent you can’t fully control and wrapping it in a frame that’s reliable, evolvable, and auditable.
Three concrete pieces of advice for anyone in the same transition
If you’re also a “strong builder, weak designer” engineer who wants to move toward AI agents, here are the three rules I’m actually using:
- Don’t chase big platforms—start with small tools that have clean boundaries. Practice system design inside small tools, where the cost is low and the feedback is fast.
- For every project, mark out its “verifiability” and its “automation leverage.” Not so you can ship it once, but so it can be reused, verified, and grow compounding returns.
- Write your direction down, and regularly prove yourself wrong. I wrote my “three-year direction” as a document and revisit it periodically: which judgments turned out wrong? That matters far more than just keeping my head down and grinding.
This isn’t a conclusion—it’s one person’s direction marker, written while still on the road. Looking back three years from now, some of these judgments will almost certainly be proven wrong. But being wrong with a direction beats being busy without one, by a wide margin.