Dennis Porter

When a paid user cancels, our instinct as builders is to immediately jump into our roadmap and build whatever feature they asked for. But after reading through dozens of exit surveys, we realized a hard truth: lack of features almost never drives people away.

They churn because we made onboarding too complex and didn't help them build a daily habit around our tool. They didn't lose interest in the problem; they just gave up on our setup process.

Do users leave because your app lacks power, or because you made it too hard for them to get their first quick win?

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.