Agentic Coding Needs Harness Engineering, Not Just Better Prompts

I use AI coding tools a lot, but I do not think the future is only about writing better prompts. Prompts matter, but they are not the full system.

A coding agent is useful because of the harness around the model: the files it can read, the commands it can run, the tests it understands, the permissions it has, and how it reports uncertainty.

The model is the brain. The harness is the body.

A coding agent needs a loop

The loop is simple to describe:

1. Understand the task
2. Read the codebase
3. Make a plan
4. Edit files
5. Run checks
6. Fix failures
7. Explain the result

The hard part is doing this without losing context or making random changes.

That is why harness engineering matters. The tool must guide the model toward real software behavior, not just good-looking answers.

Context is not “send everything”

More context is not always better. A large codebase has too much noise. The agent needs the right context.

Good context includes:

• The files near the change
• Existing tests
• Existing patterns
• Package scripts
• Error logs
• Design constraints
• User instructions

Bad context includes random files that only make the model confident about the wrong thing.

When I work with agents, I try to make the repo easier to navigate. Clear names, small modules, and focused tests help the model as much as they help humans.

Tests are the agent’s steering wheel

Without tests, the model can only guess if the change worked.

With tests, the loop becomes grounded:

edit -> test -> read failure -> fix -> test again

This is why I like TDD even more with agents. A failing test tells the agent what behavior matters. It also stops the agent from solving the wrong problem with a nice explanation.

Permissions should be explicit

Coding agents can do real damage if the tool gives them too much freedom without structure. They can delete files, rewrite unrelated code, run commands, or leak secrets if the environment is careless.

The answer is not to make agents useless. The answer is to make permissions visible and scoped.

For example:

• Reading project files is normal
• Editing task files is normal
• Running tests is normal
• Deleting unrelated files should be suspicious
• Touching secrets should be blocked
• Deploying production should require a clear decision

This is normal engineering discipline. AI just makes it more urgent.

The agent should admit uncertainty

One thing I value a lot is when an agent says, “I am not sure yet, I need to inspect this file” or “the test failed for this reason.”

That is much better than false confidence.

In coding, confidence should come from evidence:

• The code compiles
• The test passes
• The build passes
• The route renders
• The behavior was inspected

If there is no evidence, the agent should say that.

My practical setup

For serious agentic coding, I want this:

• A clean task description
• A local task checklist
• A feature branch
• Tests before risky changes
• Small commits or small logical edits
• Fast local checks
• A way to inspect UI visually when needed
• Clear final notes with what changed and what did not run

This sounds like normal software work because it is. Agents do not remove engineering discipline. They make good discipline more valuable.

Final thought

Better models will help. Longer context will help. Faster tools will help.

But the biggest gains come when the whole loop is designed well. The agent should read like an engineer, edit like an engineer, test like an engineer, and report like an engineer.

That is harness engineering. Without it, agentic coding becomes a fancy autocomplete. With it, it starts becoming real software work.