Felix Harper

We asked a coding agent fifteen times to make one button blue on a page built to tempt it: Add to Cart and Checkout shared a class, a badge and the nav link shared the accent variable. Every run added an id-scoped rule. Checkout stayed green. Appending "Do not change anything else" changed one thing: the five runs with it wrote the hex inline where nine of the other ten had added two CSS variables. A path rule fencing off every file but the stylesheet never fired.

Real repositories look different. One benchmark pre-applied the fix to 200 issues and reopened them for five recent models in their vendors' harnesses. The right patch is empty; 35 to 65% of instances got an edit to executable code anyway, and in the authors' analysis of one model's failed traces, 87.1% had modified code unrelated to the issue. Task wording moved that figure a long way in both directions. Telling the agent to "edit the codebase" dragged one model's correct-abstention rate to 36.5%; reproduce first, then fix or abstain if nothing was wrong, lifted it to 88.5%. Their explanation: the agent acts on whatever it believes success means.

The harness side: switch on auto-accepted edits in both CLIs whose docs we read and the grant is the whole working directory. A path rule brings that down to files; one vendor's docs state that it applies to the built-in edit tools and recognized shell commands, and that a script opening a file itself is outside it. A selector inside a permitted file sits below every layer's resolution. Whether the blue landed on one button or on every primary button is decided by the sentence you typed and by whoever reads the diff.

When your agent overshoots, where does the boundary live in your setup today: the prompt, a rule file, a path rule, a sandbox, or the person reading the diff? Which of those has caught a change for you inside a file the agent was allowed to edit?

Today I have an interview at our national radio station, where I ll be answering questions about myself, RunEvr, and our animation studio.

So let s warm up here first =D

I m a co-founder of RunEvr - an agentic environment for creative teams.

I have 12+ years in animation production, working across almost every stage - from creative work and art direction to a production manager.

When we were free tracking new user signups was super exciting. But once we added paid plans seeing a customer cancel after a few weeks felt way worse than someone never trying the app at all.

Looking into cancellation feedback, most users aren't leaving because of missing features. They're leaving because the app doesn't naturally fit into their daily work routine.

Does that sharp pain of subscription churn fade over time, or do you just get better at fixing workflow gaps?