Needlr for coding agents

Your coding agents ask Needlr whether what they ship works. They measure; you decide, and only people publish.

Coding agents like Claude Code or Cursor can now build features on their own. Needlr for coding agents lets them ask the question that matters: did the thing I built actually help?

Think of a new chef

A new chef cooks lots of new dishes, fast. To learn which ones people like, someone counts the plates that come back empty. The chef can ask for that count any time.

But the chef doesn't change the menu. The owner does. In Needlr, the agent is the chef, the empty plates are your KPI, and you are the owner.

What an agent can do

• Ask before it builds. Which KPIs the project has, how many visitors it gets, and how long a verdict would take. With few visitors only big changes can be measured, and the agent is told so.
• Ask after it ships. For a change that's already live, Needlr compares the KPI before and after the release date, often with an answer right away. For a new feature, it can measure adoption. Or it adds a split test in its own code, like a Split test (developer).
• Read its verdicts and record what it did next: keep, roll back, try again, give up, or fix the measuring.
• Look up what was tried before on your projects, so it doesn't test the same losing idea twice.
• Propose a KPI when none fits. A person creates it, or dismisses it.

What an agent can't do

• Publish to your site. Agents never touch Tag Manager. Publishing and shipping a winner stay with a person, with a code from their phone.
• Peek. Until the verdict, it sees progress and an expected date, never which way the result leans (why).
• Start split tests without your say. You choose for each agent: always ask, only with a pull request, or always (how).
• See other projects. It works only on the projects you picked for it.
• Create a KPI itself. It can only propose one.
• Ask for more than 50 new impact checks a day. Each agent has its own daily limit.

Safety rules built in

• Split tests started by agents are judged at 95% confidence, over at least 7 full days.
• At most 2 of an agent's split tests run at the same time on the same KPI.
• If an agent's split test clearly hurts your KPI, or one of the guardrail KPIs it watches, it stops by itself and everyone sees the current version again. It shows as Stopped · it hurt.
• Releases within 14 days of each other on the same KPI are measured together, and the result says the evidence is weak.
• A change that already didn't win isn't measured again, unless it's a follow-up to it.

Where you see it

Open Agents in the menu on the left. Owners and editors manage agents there; viewers can look.

• Waiting for you: split tests an agent asks to start (Review and start), KPIs it proposes (Create KPI or Dismiss), and verdicts nobody decided on for more than a week.
• Last 30 days: how many changes your agents asked about, how many got a verdict, proven and likely wins, and what hurt.
• Each agent's card: its projects, its impact checks, how many are measuring, and when it last called.

Everything an agent asks to measure is a normal impact check in its project, with Requested by and the agent's name on its check page. It shows on the Timeline like any other release.

Common mistakes

• Letting every split test start on its own on day one. Start with Always ask me, see what your agent asks for, then decide.
• Leaving verdicts undecided. An agent learns from what was decided. Check Waiting for you once a week.
• Asking about a tiny change on a quiet page. No one can measure it in time. Bigger bets get answers (why).