Why output count is the wrong metric
“Cyborg ne 347 tasks complete kiye” sounds impressive. Put that number in a board deck and people nod.
But if 180 of those tasks were “send daily standup summary” and 90 were “update spreadsheet cell”, you’ve measured volume, not value. You’ve created a metric that rewards your Cyborg for taking on many small tasks instead of fewer complex, high-value ones. And over time, that’s exactly what happens — tasks get smaller, count goes up, actual work displacement goes down.
The goal of measuring a Cyborg is to answer two honest questions: Is it doing real work? Is the quality improving over time? Task count answers neither.
Measure what you actually care about: real work displacement and quality. Everything else is noise.
The 5 metrics that actually matter
1. Review-pass rate (RPR)
Of all outputs the Cyborg produced this week, what percentage passed your review without major changes? A “pass” means: approved as-is, or with only minor edits. “Fail” means: rejected, major revision requested, or you rewrote it yourself.
Target: >80% by month 2. Below 60% in month 1 is expected and fine — Cyborg is still calibrating to your context.
A declining RPR after month 2 is a signal worth investigating. It usually means: the Cyborg has been asked to work in a new area without sufficient context, or the definition of “good” shifted without being communicated.
2. Autonomous completion rate (ACR)
Of all assigned tasks, what percentage did the Cyborg complete without escalating to a human mid-task? Escalation is sometimes correct — this metric measures whether the Cyborg is developing the context to handle its assigned scope confidently.
Target: >70% on T1 tasks by end of month 1. >50% across all tasks. Rising ACR = Cyborg is learning your context. Flat or falling ACR = something is wrong with context or task scoping.
3. Escalation quality rate
When the Cyborg escalated to a human, was the escalation appropriate, well-reasoned, and useful?
Bad escalation: “I don’t know how to do this.” — No context, no options, no reasoning. Just a hand-off of confusion.
Good escalation: “This touches the billing module which has a known edge case [link to incident]. I need your judgment on whether option A (safer, slower) or option B (faster, higher risk) is the right call here.”
Target: >90% of escalations are high-quality by month 2. If escalations are vague, review the Cyborg’s escalation thresholds and whether it has enough context about what it doesn’t know.
4. Human hours saved
Estimate: how many hours did you and your team NOT spend on work that the Cyborg handled?
Method: list the tasks the Cyborg completed this month. For each, estimate how long it would have taken a human. Sum it. That’s your hours saved number. Run this monthly.
Target: The number should grow month-over-month as the Cyborg handles more complex work. If it’s flat, investigate: is the Cyborg stuck on small tasks? Has task complexity plateaued?
Don’t over-engineer this. A back-of-envelope estimate is fine. The goal is directional signal, not accounting-grade precision.
5. First-week-of-hire ramp time equivalent
If you hired a human for this exact role today, how long would it take them to reach the quality bar your Cyborg is at right now?
Reference benchmarks: A new human engineer typically takes 3–6 months to be fully trusted to ship independently. A new support hire takes 4–8 weeks to handle T1 tickets without supervisor review. A new marketer takes 2–3 months to match brand voice consistently.
Target: A Cyborg should hit equivalent trust in 30–90 days. If you’re past day 90 and RPR is still below 70%, the context investment probably wasn’t sufficient at onboarding. Run a calibration session.
The 1 anti-metric: task count
Do not track raw task count.
Task count incentivizes the wrong behavior — in both the Cyborg and in your own reporting. It pushes toward many small tasks over fewer complex ones. It makes standup summaries look equivalent to shipped features. It makes “update a spreadsheet cell” count the same as “architect a new API endpoint.”
One well-architected feature reviewed and shipped is worth more than 50 standup summaries. Task count hides that. Remove it from your Cyborg’s scorecard entirely. Replace it with RPR + ACR, which tell you the same directional story without the distortion.
A simple weekly review checklist
Every Friday, answer these 5 questions about your Cyborg. They take 10 minutes. They tell you everything you need to know.
- Did the Cyborg send its EOD report every working day this week? If not, why not — was it blocked, or is there a configuration issue?
- Did any output need more than 2 rounds of revision before you approved it? If yes, what was missing — context, clarity of task spec, or something in the Cyborg’s understanding of our standards?
- When it escalated, was the escalation useful and well-reasoned? Or did it escalate with a vague “I’m not sure”?
- Did it proactively flag something it noticed in your codebase, data, or process that you hadn’t asked about? (This is a green flag — it means the Cyborg is engaging, not just executing.)
- Would you give it a more complex task next week? If yes, do it. If no, what specifically would have to change before you would?
When to tune vs when to worry
Tune (normal behaviour): RPR below 80% in the first 2 weeks. This is expected. Run a calibration session — share more context docs, correct the “what I understood” document, clarify the acceptance criteria format you prefer. This is part of onboarding, not a failure.
Worry: RPR declining after month 2, without a clear cause (new area of work, new domain). Investigate what changed. Did you ask the Cyborg to work in a new part of your codebase without briefing it? Did your quality standards shift without being communicated? Has the task complexity suddenly increased?
Hard stop: Cyborg taking actions it shouldn’t be taking without your approval. If this happens: use the kill switch immediately, log the incident, review the trust-level settings. Do not wait to see if it corrects itself. Trust levels exist for exactly this reason — a T3 action that runs without approval is a configuration failure, not a Cyborg failure.
Previous: Day-1 onboarding playbook ← | Back to: Academy →