Your Coding Harness is a Liar!

Claude Desktop, Codex, Cursor, and other desktop coding agents all share the same engine, same file system, same three things you can’t skip.

Your coding harness is lying to you.
Not maliciously. More like a bulldozer wearing a Slack costume, smiling politely while idling on your hard drive.

The interface is clean. A text box waits patiently for your thoughts. There may be a tasteful little sparkle near the submit button, suggesting intelligence, helpfulness, and the complete absence of heavy machinery.

So you use it like the chatbot it appears to be.

You paste in some context, ask a question, copy the answer, and move on. Two years of chatbot interfaces have trained this motion into your hands until it feels less like a workflow and more like blinking.

But when you opened one of those fancy desktop harnesses now wandering into Product Manager workflow space, you did not open another chat window.

You opened a language model attached to a file system, a collection of tools, and a command line capable of doing actual work inside an environment that will still be there tomorrow.

A chatbot speaks from inside the window.
A harness reaches through it.

That difference is small enough to hide behind a blinking cursor and large enough to turn your working life into either a well-run shop or a lumberyard after a tornado.

The model is not the whole machine anymore.
It is the motor.

The files are the memory. The command line is the reach. The structure around them determines whether the machine produces leverage or shrapnel.

The Smiley Face on the Bulldozer

Watch the status messages while one of these tools works and the disguise briefly slips.

You will see words like:

grep
sed
awk
find

Old Unix commands flickering beneath a polished interface, some of them older than the Product Managers now confidently prompting them to “clean things up.”

Those commands are not conversational.

They search directories. They inspect files. They transform text. They count, sort, rename, copy, compare, and execute. Depending on the permissions you granted, the harness may be able to create or alter persistent state without asking you to paste anything into the conversation first.

That does not make it sinister. A table saw is not sinister either. It simply has fewer opinions about your fingers than you might prefer.

The interface says: “Ask me anything.”
The machinery says: “I can walk the property.”

And that is why the first useful thing you should do with a coding harness is not ask it to build an app, rewrite your strategy, or unleash a small parliament of agents on the quarterly planning process.

Give it somewhere harmless to walk.

Motion 1: Let It Inspect the Junk Drawer

Your Downloads folder is ideal to learn this hands-on.

It is already the computer equivalent of that kitchen drawer where batteries, expired coupons, three mysterious keys, and a screwdriver nobody remembers buying have been waiting years for a tribunal.

Do not begin with production code. Do not begin with your shared customer-research repository. Do not point it toward the directory containing tax returns, legal documents, medical records, or anything else you would prefer not to turn into an impromptu AI fluency exercise.

Use a sandbox or read-only permission mode when the harness provides one.

Then paste this:

Treat my disaster of a Downloads folder as read-only.
Do not move, rename, create, edit, or delete anything.Inspect the folder and report:- total number and size of files
- breakdown by file type
- oldest and newest files
- ten largest files
- likely duplicate or versioned files
- obvious clusters such as installers, screenshots, PDFs, archives, and temporary exportsEnd with one honest sentence about the state of the place.

No multi-agent swarm. No grand theory of knowledge management. No governance retreat where twelve adults debate whether screenshots belong under “Evidence” or “Media Assets” while the coffee dies in the urn.

Just:

1. Look around.

2. Touch nothing.

3. Tell me what is here.

The point is not the report. The report will probably confirm what you already suspected, namely that your Downloads folder resembles a digital yard sale conducted during a hurricane.

The point is the proof.

The harness did not answer from training data. It did not wait for you to paste the files into a conversation. It walked a real environment, used deterministic tools to gather facts, and returned with a map.

You have now felt the difference between a chatbot and a harness.
That difference will become more important tomorrow.

Persistence Cures Amnesia

Browser chatbots suffer from a familiar form of memory loss.

The conversation grows. Earlier details drift out of reach. Yesterday’s insight disappears into another thread, so you paste the research again, explain the product again, redefine the audience again, and perform the little ritual sacrifice of context required before the machine can become useful.

Coding harnesses offer something better.
The files persist.
The instructions persist.

The output from yesterday can still be sitting in the same directory tomorrow morning, patiently waiting for the agent to pick up where it left off.

That is not a gimmick.
It is the beginning of a radically more useful working model.

It is also where the trouble starts.
Because the system does not merely remember.
It remembers indiscriminately.

The abandoned strategy remains. The current strategy remains. The synthetic customer interview remains. The real customer interview remains. The brainstorming document where someone proposed blockchain loyalty points for municipal water meters remains, because nobody had the courage to delete it and apparently history must suffer.

All of it sits on disk with the serene equality of files.
The harness has memory, it does not have judgment about that memory.

The Miracle Becomes a Crime Scene

Monday goes beautifully.

You ask the harness to review customer research, produce a summary, and create a few supporting documents. It does the work fast enough to make you briefly resent every workshop where someone once spent an afternoon moving sticky notes around a wall.

Tuesday, you ask it to continue.
It cannot find yesterday’s output.

You point it toward the files. It apologizes with the smooth confidence of a waiter who has dropped your entrée but intends to restore the evening through excellent eye contact.

Wednesday, it finds the files.
Then it finds the wrong files.

It cites an obsolete positioning statement as current strategy. It retrieves a synthetic persona as if she were a paying customer. It blends a rejected executive brainstorm with actual product evidence, then presents the resulting casserole in crisp markdown with six bold recommendations and a reassuring conclusion.

Nobody lied.
Everything was there.
That was the problem.

A file system cures amnesia. It does not cure bad filing.

And because the interface still looks like a chat window, we carry Chat Window Muscle Memory into an environment where nothing is truly disposable anymore.

Paste. Ask. Copy. Close.

In a chatbot, that habit produces temporary clutter.
In a harness, it creates persistent organizational memory without provenance, authority, or a clearly labeled place for the embarrassing ideas.

More Context Can Make the Machine Dumber

Once people discover that the agent can read files, they respond with the restraint and discernment of a Labrador retriever released into a butcher shop.

Everything goes in.

Every transcript. Every presentation. Every abandoned roadmap. Every competitive screenshot. Every workshop note. Every synthetic persona. Every analyst report from three reorganizations ago. Every executive thought bubble that briefly existed between airport Wi-Fi and the hotel bar.

Then someone points proudly at the swollen workspace and says:
“It has all the context.”

No.

It has all the artifacts.
Those are not the same thing.

Focused context illuminates the work. Context sludge forces the system to solve a larger retrieval problem before it can begin solving yours.

This is Context Hoarding Disorder, the belief that intelligence emerges naturally when enough documents are stacked in the same digital room.

It does not.

More material creates more possible matches, more contradictions, more stale assumptions, and more opportunities for a confident model to retrieve something plausible, adjacent, and completely wrong.

You did not give the agent a richer understanding.

You packed for a weekend trip by loading your entire house into a moving truck, then wondered why nobody could find the toothbrush.

Give the Machine a Map, a Contract, and a Constitution

A lumberjack does not map the entire forest before cutting one tree.

They inspect the lean, the wind, the ground, the escape route, and what might happen if the blade binds halfway through.
They gather enough truth for this cut.

That is what context engineering should do.
Not “upload everything.”
Not “make the context window enormous.”

Give the system enough trusted understanding to perform the work in front of it without inviting every artifact in the organization to testify.

Claude Desktop, Codex, Cursor, and their growing litter of cousins look like friendly chat apps. Underneath, they are persistent execution environments with access to your files, your tools, and whatever judgment you remembered to bring

To solve for this problem that occurs on a naked initial `/init` command in a new project, I use three small files:

Context. Contract. Constitution.

The context file tells the agent where it is. It names the goal, the important definitions, the trusted evidence, the current decisions, and where deeper material can be found.

The contract defines what good looks like. It states the audience, the expected outcome, the form of the deliverable, the quality bar, and when the work should stop.

The constitution defines what cannot be sacrificed for speed. It names the sources that carry authority, the claims that require evidence, the things that must never be fabricated, and the actions that require human approval.

The filenames may be README.mdfor the context, CLAUDE.md/AGENTS.md for the contract, or something else entirely, like CONSTITUTION.md. The labels matter less than the responsibilities.

These do not need to become three majestic documents written by a cross-functional committee beneath fluorescent lighting while someone records “AI Governance Alignment” on a whiteboard.

A few pages of disciplined markdown can outperform a forty-page policy that nobody has opened since Legal celebrated publishing it.

A Spotlight Does Not Organize the Warehouse

While the 3Cs help the agent focus on the immediate work.
They do not organize everything that deserves to persist.

That lesson usually arrives on a Tuesday, when the agent repeatedly retrieves the wrong definition, cannot determine which strategy is current, or discovers that your beautifully accumulated context library is actually three generations of thinking stacked on top of each other like sedimentary rock.

This is where context engineering gives way to information architecture.

Context engineering asks:
“What does the agent need to understand now?”
Information architecture asks:
“Where should durable knowledge live so it can be found, challenged, updated, and reused later?”

One points the spotlight.
The other organizes the warehouse.

Without that structure, persistence becomes contamination. Drafts bleed into decisions. Synthetic examples acquire the patina of customer evidence. Rejected ideas sit one search result away from resurrection.

A pile remembers everything.
A structure retrieves deliberately.

Motion 2: Give the Mess an Address

Return to the Downloads inventory from Motion 1.

This time, ask the harness to propose a structure. It still does not get permission to move anything.

Using the Downloads inventory you created, propose a filing structure I could realistically maintain.Classify each file as:- Keep and file
- Archive
- Delete candidate
- Needs human reviewFor each item include:- current path
- proposed destination
- one-sentence reason
- confidence: high, medium, or lowWrite the proposal to:~/Downloads/_junk-drawer-plan.md 
Show me the plan.Do not move, rename, archive, or delete anything until I explicitly approve individual items or a named group.

This motion looks like folder cleanup.
It is actually your first governed operating model.

You then review the plan, challenge the categories, rescue the tax document it confidently classified as stale, and decide whether its proposed folder structure would survive contact with your actual habits.

Only then does execution become possible.

The distinction matters because “organize this” is not a harmless instruction when the agent can touch the source material.

Observation, recommendation, authorization, and execution are different responsibilities. Smearing them together is how humans wake up to discover that an efficient machine has tidied away something irreplaceable.

Permissions are architecture.
Promises are prose.

The Forty-Eight Hours Were Purchased in Advance

This is the missing lesson beneath the impressive demos.

When Claire Vo pointed Claude and Cursor at existing repositories and produced a working design system in roughly 48 hours, everybody saw the clock.

The load-bearing part was the repository.

The components already had names. The patterns had addresses. The dependencies existed. The examples sat where a competent agent could find them. Years of work had created an environment where the machine could navigate, infer, and reuse without first excavating the ruins of six abandoned filing systems.

The visible result took 48 hours.
The speed was purchased in advance.

This does not mean you need a cathedral of information architecture before doing anything useful. It means structure should emerge from real friction.

The agent keeps asking for the same customer definition, so you give that definition a durable home.

It repeatedly retrieves an outdated strategy, so you mark the current source of authority and move the old one into an archive.

Generated summaries keep masquerading as primary research, so you give generated material a separate address and visible status.

A glossary appears. A decision record forms. An index quietly grows.

Not because some framework ordered you to build a knowledge empire, but because the work revealed where retrieval kept failing.

• A project bucket gives the machine somewhere to remember.

• A library gives it somewhere to look.

• An index gives it directions.

• A receipt lets you verify where it went.

Without those things, you do not have organizational memory.
Without those things, you have Confident Nonsense with a storage plan.

Repetition Is a Tool Asking to Be Born

Once people realize the harness can manipulate files and run commands, they immediately start dreaming about total automation.

Everything becomes an agent.
Every workflow becomes autonomous.

Every repeated irritation gets wrapped in enough architecture to qualify for its own keynote.

This is how an innocent desire to save ten minutes becomes a small distributed system maintained by someone who only wanted help formatting interview notes.

Sometimes a prompt is enough.
Sometimes you need a backsaw, not a forestry operation.

But repeated friction deserves attention.

The same search every morning. The same set of files gathered before a meeting. The same transformation after every interview. The same correction whenever the agent produces a draft. The same irritating half hour of preparation that quietly taxes every meaningful piece of work.

That repetition is not simply a nuisance.
It is a tool asking to be born.

Teresa Torres’ /today routine is useful because it produces a daily plan.

But the plan is not the move to remember.
/today is the move is memorable move.

She recognized a repeated motion, defined what information mattered, and captured the routine in a reusable form so the machinery could perform it consistently.

That is a digital jig.

In a workshop, a jig holds the work in the right position and guides the tool through a repeatable cut. The craftsperson makes the difficult judgment once, captures it in the setup, and earns reliable leverage every time the jig is used again.

• A command can be a jig.

• A skill can be a jig.

• A template can be a jig.

• An evaluator is a gauge.

• A stop condition is a guard.

The tool does not replace judgment.
It preserves where judgment belongs.

Build Your Own Damn Tools

Becoming a toolmaker does not mean becoming a discount software engineer with a prompt addiction and a haunted side project.

It means recognizing a repeatable motion and defining the smallest useful system around it.

Perhaps it assembles the evidence required for a decision.
Perhaps it compares new research against established customer obstacles.

Perhaps it creates a first-pass synthesis while keeping primary sources linked and synthetic material clearly labeled.

Perhaps it checks a document against a contract and reports what is missing without rewriting the entire thing in the scented language of corporate oatmeal.

The model can help you build the tool. Ask it to inspect the environment, propose the smallest design, explain every file it creates, generate test cases, identify failure conditions, and show you where inspection turns into action.

The delightful recursion is that the harness can help shape the context, scaffold the library, and build the reusable tools it will later operate.

It can herd the artifact cats.
It cannot decide which cat owns the house.

Motion 3: Build the Jig

You have inspected the junk drawer.
You have designed an address space.

Now turn the repeated review into a reusable tool with memory, tests, and an explicit human checkpoint.

Turn the Downloads inventory and `_junk-drawer-plan.md` into a reusable command or skill called `junk-drawer-review`.

Before building, propose the smallest useful design and show me:

* what you would create
* where it would live
* what it may read and write

Wait for approval.

Then build a tool that:

* scans Downloads without changing anything
* saves a snapshot of file names, types, sizes, and dates
* compares each run with the previous one
* reports what is new, missing, stale, duplicated, or likely superseded
* recommends Keep, Archive, Delete candidate, or Human review, with a brief reason

Save all reports inside:

`~/Downloads/_junk-drawer-reports/`

Test it first on a safe sample folder. Show me the results and stop before scanning my real Downloads folder.

The third motion is more sophisticated, but not because the prompt is longer, the resulting script looks clever, or somebody used the word “agentic” near a diagram.

It is sophisticated because the responsibilities are deliberately separated.
A deterministic tool gathers the facts.

---

The tool catalogs. The harness recommends. You decide.

That is leverage without Delegation Delusion.

The machine can identify duplicate installers, stale exports, and suspicious version clusters faster than you can. It can recommend a cleanup plan. It can explain the recommendation and report its confidence.

It still does not get to decide what disappears.
The judgment remains human because the consequence remains human.

Sometimes the Backsaw Is Enough

Not every task deserves a reusable workflow.

Sometimes you need five headline options.
Sometimes you need a paragraph tightened.
Sometimes you need one PDF summarized before a meeting and will never look at it again.

Use the chat window. Ask the question. Take the answer. Go to lunch.

Building a persistent skill, synthetic test fixture, evaluation harness, and governance checkpoint to rewrite a calendar invitation is industrial-arts performance theater.

The backsaw is hanging right there.
Use the complexity the work deserves.

No more.

The Multiplier Has No Taste

Coding harnesses do not grant product sense, empathy, taste, courage, or accountability.

They amplify what you already possess.

A Product Manager with strong judgment can use these tools to inspect more evidence, explore more alternatives, test assumptions earlier, and reduce the distance between a fuzzy idea and an honest reaction.

A Product Manager with weak judgment can produce more documents, more prototypes, more requirements, more code, and more beautifully formatted confusion before anyone remembers to ask whether the customer problem matters.

Same motor.
Different shop.

The harness does not know whether the product should exist. It does not know whether the evidence deserves trust. It does not know whether the recommendation protects margin, reduces risk, improves the customer’s life, or simply gives everyone something impressive to point at during the next steering committee meeting.

It executes the system you built around it.
For better or worse.

AI is a multiplier. Give it craft, and it multiplies craft.
Give it a junk drawer, and it multiplies shrapnel.

The interface will keep smiling.
The cursor will keep blinking.

The bulldozer will continue idling politely inside the chat window, waiting for instructions.

Now you know where the blade is.
You also know what to do next.
Inspect the environment.
Give the memory an address.
Build the jig.

---

Dean Peters is a Principal Consultant and Trainer at Productside, where he teaches outcome-based product management, AI Product Management, discovery, and the AI workflows product teams actually use once the demo is over.