Frontend Harness — turning my frontend standards into checks the AI must pass

// Context

Frontend Harness is my personal open-source project. It started as the example for my Harness Engineering course; then I put it into my own projects, new and existing, and kept improving it every day.

I built it alone, with Claude Code, in October and November 2026, as a Claude Code plugin for React (Vite) and Next.js projects in TypeScript. It now runs my movie app, my personal finance analytics, my personal site and a few more side projects.

Claude Code Harness EngineeringMy course on making AI agents check their own work

// Problem

AI was supposed to make me faster, but every feature turned into a long conversation. The agent misunderstood the task and built the wrong thing, said "done" without tests, never opened the page to see whether it worked, copied code instead of reusing it, left code nobody used and put files where the project didn't keep them. So I sat through every step, repeated the same instructions in every chat and asked for the same fixes again and again.

The cost was not only hours. Keeping all of this in my head took a lot of mental energy, so I finished a feature more tired than if I had written it myself. Every new side project also needed the same checks set up by hand, which slowed down each idea before it started.

// Objectives

I wanted to step in only twice per feature: at the start, to agree the plan, and at the end, to get a working feature with nothing to fix. In between, the agent should know the steps and their order, decide the small things itself, write code to the project's standards, check in the browser that the feature works and finish only when every check is green.

Setting this up should take one command in a new or an existing project, and it should get better with use instead of breaking in the same places.

// Research

To see where my time went, I looked at my own corrections during a feature. Most of them were things a machine could check: missing tests, lint and type errors, copied or unused code, files in the wrong place. The rest were about the order of work: plan first, then tests, then code, then a look at the page.

I had also tried writing the workflow and the rules down for the agent, and that didn't stop the mistakes. Rules the agent had to remember got skipped, however clearly they were written. It followed only what stopped it.

// Options

That left three ways to work with the agent:

The first two depend on me catching what the agent missed; only the third makes the agent catch it.

// Design

I chose the harness, because the agent follows what blocks it, not what it is told. Every rule I could turn into a check, I did, and I set the checks in the order a feature goes, so each one runs at the moment it matters.

// Before the code

At the start of a session, the agent gets short instructions and the state of the project, so it doesn't lose them in a long chat. A workflow, built on the open-source Superpowers, sets the steps: clarify, plan, tests, code, a check in the browser, end-to-end tests. That is where I agree the plan. While writing, the agent follows the community's React and Next.js best practices, reads the current docs of the libraries through Context7 instead of guessing from memory, and follows the project's rules on structure. It writes the unit tests before the code.

// While and after the code

The same linter and formatter teams already run for themselves, ESLint or oxlint and Prettier, now run for the agent too: on every edit. At the end of every turn, TypeScript checks the types, jscpd and knip look for copied and unused code and Vitest runs the unit tests; a red one sends the agent back to fix it. When the feature is ready, it opens the browser with Playwright, checks the page with screenshots and writes end-to-end tests for the main scenarios. Before a commit, the harness scans for secrets; before a push, the end-to-end tests run; and the agent can never force a push or skip these checks.

// Teaching it after every feature

An agent doesn't learn between chats: ready instructions help, but when something goes wrong, you have to explain how to handle it next time, or it breaks in the same place again. So time spent on feedback pays off. At the end of every feature, the agent reads the chat for broken checks, ignored rules and my corrections, and turns them into fixes to the harness after I approve them. Each feature makes the next one easier.

// One plugin for any project

I packed all of this into one plugin with modules to pick from. In a new project it is set up in about five minutes. In an existing one it looks at what is already set up, settles the conflicts itself and asks me when it can't, and an audit finds the old code that breaks the rules. Everything lives in the project's own files, so it works for everyone who clones it, and an update keeps the project's own edits.

// Results

A new project with the harness is set up in about five minutes. I say what the feature is, describe what it should do and answer the main questions while it is planned, and the agent writes the code in the right structure, tests it, checks the page in the browser and fixes its own errors.

At the end, I only check that the feature fully works, and it usually does. What slips through is small details we missed while clarifying, and the ones that could come back become fixes to the harness. By my estimate, a feature takes about half an hour instead of three to four hours.

// Looking back

It was worth building the harness instead of writing better prompts. The agent doesn't need someone watching every step; it needs limits, a clear order of work and someone who teaches it after every mistake.

The course got it started; daily use on my own projects, and the feedback from every feature, made it good.

// What people say