My Coding Agent Shouldn't Have a Boss

I was working on our cybersecurity models when Claude Code stopped me.

Nothing in the repository had failed.

I had not reached a technical limit.

The harness decided it would not continue with the work.

Then it happened again.

Sometimes it was a refusal. Sometimes it was throttling. Sometimes a workflow that had worked the week before behaved differently after the harness changed.

The exact reason mattered less each time.

Claude Code had become part of how I ran the company. I was using it for hours every day, delegating real work to it, and increasingly depending on it to keep multiple technical programs moving.

But the layer deciding whether I was allowed to work was not mine.

Claude Code is excellent. I still use it.

This is not a post about Anthropic building a bad product.

It is a post about me building a bad dependency.

I was renting permission to work

When a coding agent is an occasional convenience, a refusal is annoying.

When it becomes your development environment, its rules become infrastructure.

The harness decides which files the model sees. It decides which tools it can call, when a shell command can run, what context gets retained, which requests are refused, and when the agent is allowed to declare the task complete.

The model matters. The harness gives the model hands.

The better Claude Code became, the more I put inside it. The more I put inside it, the more obvious the dependency became.

Its owner can change its behaviour, policy, capacity, price, or account limits. They are allowed to do that. It is their service.

My mistake would be treating rented permission as owned infrastructure.

I found myself thinking: my coding agent has a boss, and it is not me.

That is not an architecture I want to depend on for the next decade.

Owning the model is not enough

I have spent much of this year talking about "AI you can own."

I meant open weights. A model you can download. A version you can keep. Something that cannot be changed, deprecated, or taken away after you have it.

That was incomplete.

An open model inside a closed harness can still leave you renting the most consequential part of the system.

You may own the brain. Someone else still controls its hands, memory, tools, permissions, and stop button.

For a chat app, that distinction is easy to miss.

For an agent that edits files and runs commands, it is the whole thing.

Owning your AI has to extend beyond the model. It has to reach the harness.

What an open harness actually changes

An open-source harness does not make every problem disappear.

The provider you choose can still rate-limit you. Its model can still refuse a request. Open code can still contain serious security defects.

The difference is that none of those things has to own your entire workflow.

You can inspect the layer deciding what leaves your machine. You can see how credentials are stored. You can examine the guards instead of guessing how they work.

That is the guard, not a diagram of the guard. Asked to delete a directory with rm -rf, it names what it thinks the command is, prints it, and defaults to refusing. You can read that code and disagree with it.

Here is the whole loop, on my own provider key:

You can keep the version that works for you. You can change providers without replacing the rest of your development environment.

Or you can use Vinci's managed service when convenience matters more than configuration.

The valuable property is not that nobody can ever restrict you.

It is that you have an exit.

The ability to leave is what turns dependence into a choice.

We did not build the engine

Vinci Code is built on Pi, the open-source agent harness created by Mario Zechner.

I want that near the top because launch posts have a habit of hiding the foundation underneath the impressive part.

We did not build the core agent engine.

Pi already had the multi-provider model layer, the agent runtime, the tool loop, and the terminal interface. Without that work, Vinci Code either would not exist or would be a much worse product.

What we built is the Vinci distribution layer on top.

We tried to make the agent easier to understand, particularly for someone who cannot or does not want to interpret raw tool logs.

It narrates what it is doing in plain language. It reports what actually happened: how many files it inspected, how many lines it read, whether a command succeeded, and whether a change was actually made.

It adds command guards, secret masking, sandboxing, checkpoints, undo, review, and task receipts.

The goal is not to hide the technical work. It is to translate the technical work without lying about it.

That matters to me because the next group of people using coding agents will not all identify as programmers. They will still need to know what the agent changed.

"Done" is a claim, not a feeling

Coding agents like to declare victory. Mine does too.

A model makes a change, runs something that looks test-like, and confidently says the task is complete.

Sometimes it is right. Sometimes it is performing the shape of completion.

We added a verification layer because I do not want the agent that performed the work to hold unilateral authority over whether the work succeeded.

Today, Vinci Code records one of four outcomes: DONE, DONE-UNVERIFIED, WAITING, BLOCKED.

If changed code warranted a direct check and that evidence is not current, the result is not DONE.

Have we solved verification?

No.

A model reviewing another model is not mathematical proof. A test suite can encode the wrong requirement. A reviewer can miss the bug. A verifier can be gamed. The agent can still produce a convincing receipt for work that later turns out to be wrong.

The meaningful improvement is more modest.

Verified and unverified completion no longer have to share the same word.

That distinction sounds small until you watch an organization build decisions on top of AI-generated work.

"Done" cannot remain a tone of voice. It has to become an evidence claim.

Why we are opening it now

We could keep Vinci Code closed and sell access to it. That would be easier in the short term. It would also contradict the thesis.

The entire CLI repository is now under the MIT License.

There is no enterprise folder containing the useful parts under a different licence. There is no "source available" qualification hiding in the footer.

The optional Vinci inference service remains hosted. People who want one account and no provider configuration can use it and pay for the compute they consume.

But the harness does not require that relationship. Use your own provider and you do not need a Vinci account.

That is a healthier business relationship. We can charge for convenience, compute, and services people deliberately choose. We do not need to charge rent on their ability to keep using the tool.

Open source is not a moat by itself

I want to be careful here, because founders have learned a new kind of launch theatre.

Make the repository public. Add an MIT badge. Call the community a moat. Wait for stars.

That is not how it works.

Open source does not create a community. Maintenance does. Answering issues does. Accepting criticism does. Sending general improvements back upstream does. Keeping the documentation honest when the code changes does. Making security fixes when nobody is applauding does.

A public repository is a starting condition, not an outcome.

It also makes us more exposed. People can inspect the guardrails and find holes. They can point out where the verification claim is too strong. They can fork the project, remove our branding, and build something better.

Good.

A coding agent with access to people's files, credentials, and shell should be inspected by people we did not hire.

Beta means I expect parts of this to be wrong

Vinci Code is in beta. The interfaces will change. Some ideas that feel important today will be deleted.

There will be providers that behave badly, guards that are too aggressive, and verification cases we have not anticipated.

It also does not run local models today. That is the thing I most want to change, and I would rather say it plainly than let the word "open" imply it.

I am not calling it mainstream today. I hope it eventually becomes the open equivalent of the coding CLIs people now treat as default infrastructure. That is an ambition, not a present-tense fact.

The more defensible statement is that I already use it every day.

I moved more of my work onto it because I needed the ability to understand and control the thing sitting between me and my repositories.

Now we are opening it because that ability should not belong only to us.

My coding agent should not have a boss I cannot see.

It should have source code I can read, rules I can inspect, and an exit I can exercise.

AI you own needs hands you own too.

Vinci Code on GitHub