why developers stopped trusting it
The first version drafted with the same confidence whether it was right or wrong. So developers stopped trusting the agent even when it was right.
how does an agent earn the right to act on someone's behalf, and know when to step back?
i evaluated it on its own production record
I ran four methods on the agent's complete production record: every pull request, issue and release it had made across five open-source repositories, met by their maintainers. I was the operator as well as the analyst, so this tells me where the pipeline breaks.
Expert inspection against an explicit rulebook. Rule by rule: does each claim trace to its source, does the tone fit the register, is the structure complete, is the terminology consistent.
The agent's complete production record, each failure coded into a class and pinned to the artifact where it happened. For a niche product, this is the entire population of its output.
Findings fed the AI agent back. The engineer's baseline prompt design came first; what I added and tuned were the style guide and the QA gates, and the loop reran on fresh output. An instrument different from user testing.
Recorded sessions with first-time users recruited from outside my own circle, working the live agent in GitHub. This is the one instrument here that puts the agent in front of someone who has never met it, and it is what rewrote first contact.
six ways it broke
Every failure in the corpus was coded into a class. Drag through them.
Many small PRs, global context lost
Source of truth split across two trackers
Dead links after deleted releases
A stalled PR that nobody decides on
Fragile links across repos and forks
A refusal born of domain misreading
failures became rules
Three of the six classes had no rule in the style guide. Now they do. Open each to see the rule it earned.
the ruleA master issue acts as the table of contents; work ships in linked batches.
the ruleReleases never get deleted. They get marked deprecated, so links keep resolving.
the ruleEvery stall gets a named next step and a decision deadline.
let it decide when to act, and when to step back
The agent carries : a sense of how sure it is. One behaviour, three postures. Scroll to watch it change what it prepares with its own confidence.
it speaks plainly, and shows the plan
When the change is unambiguous, the agent states the plan outright and asks you to approve it. No hedging. It never modifies anything without your approval.
it proposes, and names the one blocker
When it is not certain, it proposes and waits, naming the single thing that would settle it. One blocker up front, the rest one click away.
it stops, and says what it could not settle
When the call is beyond it, it makes no plan at all: it lays out what it found and asks. The decision is yours at every level; what changes is how much the agent prepares.
I read your new dev script. The plan: update the setup guide to match. Approve, and I push to this branch.
what I addressed, and what I did not
One graduated behaviour, not a rule per error.
I resisted writing a rule for every failure in the record. One graduated behaviour handles the whole class, so the fix scales past the cases that prompted it.
One blocker up front, not every doubt at once.
Raising every doubt at once was honest and paralysing. One blocker up front, the rest one click away.
Left out on purpose: a rule per failure, and an A/B on tone.
Without the traffic to power it, a number would only look like evidence.
every question hides a second intent, or a mood
The code says what the system is. What the reader wants, the agent has to read from the question. Read each one, then reveal what it means.
"Folks will want to track their training runs with the tracker we already integrate. We should document how to configure it."
The explicit ask is a page. The implicit one is that the feature already ships and nobody can find it. The doc answers both.
"Hmm, I'm probably not going to add this, sorry. I don't want to encourage people to use the old trainer."
The softeners are register; the decision is firm. The intent worth acting on is the redirect: document the maintained path and link it.
Intent fit is its own QA gate: a "how do I" answered with an explanation fails it.
the recorded baseline, then the redesign
The before is real: a v1 run recorded on a live repository, none of my documents in the loop. The after is the same first-contact turn, rewritten from what first-time users told me in recorded think-aloud sessions. Three of their four findings were the same thing said three ways: they could not tell when the agent was active, what turned it on, or that the conversation happens in comments. Drag the slider to rewrite it.
what the trust layer changed
Two moderated sessions followed the redesign. Time from trigger to publish fell about 30 percent, and the text participants rewrote by hand fell about 25 percent, which is my proxy for technical accuracy. Both numbers are small-n and directional. The result I am proudest of is softer.
Participants approved from the single blocker. That is the moment an agent earns delegated trust, and it was the whole goal.
what I took from it, and what's next
An agent earns delegated trust the moment it is allowed to under-claim. The voice can never promise more certainty than the system actually has.
Instrumenting at scale the numbers this evaluation could only point at. The A/B on tone waits for traffic, because a number without power behind it only looks like evidence.
If you are hiring for work like this, I am at write@elizamarin.com.