Scott Fryxell, writing on his blog, has built his workday around a harness: a shared setup for instructions, tools, files, and scripts that he can use from Cursor, Claude, or the Pi coding agent. The durable workflow matters more than whichever AI tool happens to be attached to it.

Single developer projects can build to the caliber and consistency of large development teams. You can and should build bespoke applications and you don’t have to sweat onboarding experienced engineers; if they know their stack backwards and forwards they’ll quickly know how to contribute to yours. But most of all, I have learned that the harness is the thing; the fulcrum from which my expectations meet the LLM’s capabilities.

At the moment my rig is supported by two subscriptions (Cursor, Claude) that I can augment with Pi as needed. All three share my skills and AGENTS.md. Though I am using three TUIs, I have a unified experience. This has commodified the models for me; there is no magic sauce or special experience in Claude or Cursor that I need in order to be productive. I have zero anxiety about the transition from Cursor to Codex at the end of this month.

Fryxell also assigns different kinds of work to different models. He uses frontier models for planning, the first task, and parts of review, while cheaper models handle routine work. Here, “frontier” means the most capable models available:

I can run Deepseek on most maintenance and simple tasks. It’s when I am exploring a serious feature or large refactor with lots of moving parts that I reach for the frontier. Recently I learned about prewalk2, Can Bölük’s technique that uses frontier for the planning phase and first task, then hands off once the pattern is set. I paired it with the planner/worker/critic split from Building an Advanced Agentic Harness3 - a single prompt that plans, executes, and critiques itself confuses its own objectives, so each role gets isolated instead. I built both into a skill, with a supporting Pi extension that can take over at any stage of work.

Exploration leads to a plan formalized into an explicit DAG (directed acyclic graph) task list. Then a worker takes over, focusing on implementing the DAG one node at a time. Once complete, I bring in the critic to simplify and question what was implemented. Often this phase will push back enough that the worker phase is revisited. But once satisfied, the critic gives way to a promoter, which is my reminder that a job is not complete until you’ve properly communicated it to others.

The task plan is only one part of the harness. It also keeps the plans, files, scripts, and notes in one place where Fryxell can inspect and reuse them. He calls the command-line apps TUIs, short for text-based user interfaces. Those apps can change while the work stays put:

The harness is self-contained to support more than a home directory (sandboxing, a web interface, File System Access API, Docker, Deno executable, etc).

These concepts are still forming in my mind so I’ve been referencing npm start, cursor-agent, claude as TUIs to keep the concept of a harness clear. All TUIs share the harness.

Remaining auditable is important enough that the TUIs are instructed to keep things inside the artifacts/ directory. Cursor uses .gitignore to ignore files, which I think is smart, so a git-less root is required. I have a skill that syncs the harness with the repo in the work directory. Skills, extensions, and AGENTS.md are first-class citizens at the root, waiting to be modified and built upon. TUIs have to toe the line.