Scoring Developers When Everyone Uses AI

Token counts, lines of code and "it shipped" can each point the wrong way once every developer works with AI. This is the per-person scorecard we propose for small startups, built on ratios, shown only on invented numbers, with its weak points listed. It is the first of three articles on running a small team that works with AI; the second is the leave model, the third covers pay.

The two developers

Take two developers who each finished a service this week. One used a very large number of tokens to get there. The other used a small fraction of that for a comparable service. A manager has to decide who did better.

Every easy measure can point the wrong way.

Token counts are not comparable across model tiers. A big total might be a fleet of cheap agents doing real work. A small total might be a couple of very expensive sessions. Counted alone, the number says little about either person.

Lines of code fail for a different reason: they ignore what the lines are. A few hundred thousand lines for a couple of web pages is not the same thing as that count inside a full SaaS. Our concern is that AI can complicate structure and add lines. The one study we found (Huang and colleagues, discussed below) shows that size can match while quality differs. Simple, readable code is worth more than a large pile of it.

"It shipped" fails too. A service that took two months and one that took one month look the same on a checklist. So do a clean service and a fragile one, and a cheap run and an expensive one.

Our position is that the deliverable alone is no longer enough. Cost, time, quality at handoff and simplicity have to count as well.

We are writing this for small startups: one or two teams of five to six developers who build real software, not MVPs or vibe-coded proofs of concept, and where every developer now uses AI. At that size a team-level measure is not usable. The measure has to be per person. We consider this the most important point in the article, and the scorecard below is built around it.

The next two sections say why the deliverable and the activity counts fail. The sections after them build the measure from ratios instead of counts, work through an example with invented numbers, and show where it can go wrong.

Why the deliverable alone is not enough

A shipped service can look fine and still carry a bill that arrives later. The deliverable shows that something exists and runs. It does not show what it cost, or how much of it will still be standing in three months.

So we look at what survives, not what ships. Three sources point the same way. None is conclusive, and we will say what each one is.

Faros AI, a vendor, published a post on 23 April 2026, updated 29 May. The page shows no methodology, and we read the findings as correlational. It reports throughput going up while bugs per developer rose 54 percent and code churn rose 861 percent. We do not read that as proof that AI causes the bugs. We read it as a warning that a throughput chart can improve while cleanup cost grows underneath it.

Huang and colleagues published "More Code, Less Reuse" on arXiv on 29 January 2026, and it appeared at MSR '26. They compared pull requests written by autonomous agents with human ones. Line counts and complexity were similar, and redundancy in the agent pull requests was about 1.87 times higher. The limits matter. The redundancy analysis ran on one Python repository, crewAI, and it covers autonomous agent pull requests, not a developer steering an AI tool. The paper has internal inconsistencies, and no control for pull request size is described.

Rob Bowley wrote on his blog on 1 October 2025 about the DORA 2025 AI report. His reading is that speed gains were largely cancelled by a higher change failure rate for most teams. This rests on his summary, not on the full report. The extrapolated figures he adds are his own, so we leave them out.

None of the three measures an individual developer. They describe teams, repositories and agents, so they are a reason to look past the deliverable, not proof that any one score works. In a small startup this kind of failure can show up late: a service passes QA and ships, and defects, duplicated code and rework appear in the following weeks. Some of the usual late failures are listed in seven ways AI-built MVPs fail. That is why the formula below counts defects from QA and from the first 30 days after release, and prices every deliverable in real dollars.

Why activity counts fail

Token counts and lines of code share one trait. Both are easy to collect: a usage dashboard gives you the first in minutes, and git gives you the second for free. Both measure activity. Neither tells you what the company got.

Token counts

Gergely Orosz wrote in The Pragmatic Engineer on 23 April 2026 that token counts are gameable in the same way lines of code are. Reward the number and people produce the number. He also reported that Meta removed its internal leaderboard after backlash. His sources are mostly anonymous, so the details need care.

The Decoder reported on 8 September 2026 that a Meta memo drops AI usage from engineer reviews and names quality, speed and complexity instead. That is one memo, seen secondhand, with no definitions. LeadDev framed the same pattern as Goodhart's law on 17 August 2026: a measure that becomes a target stops being a good measure.

Shopify is the counter-case in Orosz's piece. It renamed its usage dashboard and asks whose tokens cost the most. That is a better use of the number, but the success is self-reported.

Luck is a second problem. Bai et al. found on arXiv in April 2026 that token use for the same task varies up to 30 times between runs, and that more tokens do not reliably buy accuracy. That is a maximum, from single-agent SWE-bench Verified runs, with no comparison across model tiers. What it supports is narrow: one task's cost is noisy and cannot be read as one person's skill. A weekly total sums many runs, which may reduce that noise but does not remove it, and Bai et al. did not test that, so the total still mixes skill with luck.

Model tier is a third. 50M tokens on an Opus-class model, the expensive tier, is not 20M on Haiku or Sonnet, the cheaper tiers. Whether a fleet of cheap agents beats a few expensive sessions is contested, and we take it up in the counter-arguments below.

Lines of code

Simon Willison wrote on 19 August 2026 that lines of code count only when quality is held constant. Spencer wrote on Substack on 20 June 2026 that they work as a diagnostic, never a target. Both are opinion pieces, and both keep a role for the number. Look at it, but do not aim at it.

We will not claim that AI inflates line counts, because we have no measurement of that. In the Huang study described above, addition lines averaged 23.01 for human pull requests and 23.78 for agent ones, so duplication separated the two groups while size did not. The same count also means different things in a simple site and in a full SaaS, which is why scope, not lines, is the unit in the scorecard below.

Both kinds of count measure activity. The fix is ratios, which relate activity to quality, cost and time.

A scorecard built on ratios

The scorecard has five ingredients. The scope of the work, set by the tech lead before anyone starts. A quality gate. The real cost in dollars, every loop included. The time to reach QA-ready. The simplicity of the code. Each is a ratio against a plan or a baseline, never a raw count. Each developer gets their own score.

Perf = SUM over deliverables [ V x Q x (0.4*E + 0.3*T + 0.3*S) ] / Cap

Quality multiplies everything, so a cheap, fast deliverable full of defects still scores low. A deliverable that is on plan, at baseline cost, at baseline simplicity, passes the handoff first time and has no defects earns its full V toward Cap, so a developer who fills Cap with such work scores 1.0. It is not a ceiling: because cost and time can each reach 1.2, a deliverable with a minor defect or two can score above 1.0, as the passage on starving the model under "How this can go wrong" shows.

The score is read over the two most recent quarters, with at least three deliverables whose 30-day defect window has closed.

How to measure each input. These are starting values, not research-backed settings.

• Excess: run the static-analysis tool on the files the deliverable changed and take two ratios against the codebase median, duplicated-line percentage and median cognitive complexity per function. For each ratio, excess is the ratio minus 1, clamped to 0 to 1 (0 at baseline, 1 at double the baseline). Average the two.
• Defect points: 1 for minor, 3 for major, 8 for critical. d_max of 2 per scope unit, as in the example below. QA or the lead, never the developer, sets each defect's severity and assigns it at triage to the deliverable whose code caused it, regardless of who found it or which service it surfaced in. The lead, not the developer, decides how work is cut into deliverables, and each assignment is written down so the developer can challenge it.
• H: administered by QA or the lead, never by the developer.
• Baseline dollars per unit: the median dollars per scope unit across all the team's deliverables that closed in the previous quarter, fixed when V is written down and not revised when the quarter changes. B is V times that figure. In the first quarter there is no baseline, so set E to 1 for every deliverable, record C, and start the cost term in quarter two.
• C: attributed to a deliverable through tagged API keys or a per-task usage export from the provider. C closes with the 30-day defect window, so defect fixes are in the bill. The lead reviews the export and moves spend to the deliverable it served, including spend tagged to a deliverable that has already hit the 0.1 floor and spend tagged to nothing.

Where the formula cannot run. It cannot be run on flat-rate seats, subscriptions, IDE tools or shared keys, because the bill cannot be tied to a deliverable. We offer no proxy for that case.

Why dollars

Dollars sidestep the model-tier problem, because a bill already prices each model. Even price per token misleads. Databricks reported on 8 July 2026, from one company codebase and scoring pass or fail only, that per-token price is a poor predictor of per-task cost. Sonnet 5 was about 1.7 times cheaper per token than the model Databricks compared it with, yet cost $2.09 per task against that model's $1.94. Databricks is a vendor, this is a single benchmark, the task count is not stated, and the gap is 7.7 percent. We read that as a reason to use the bill instead of a token count, not as proof of anything wider.

Dollars do not fix the luck problem. E inherits the run-to-run noise that Bai et al. describe, because a bill varies the way token use does. The mitigations are the three-deliverable minimum, the two-quarter window and the clamps on E, which cap how far one bad run can move the score. C counts what it cost to build the deliverable. What the finished service costs to run each month is a separate bill, covered in the hidden monthly bill of AI-built products.

Who sets scope

V is the lead's estimate, and the whole score is only as good as that estimate. It overlaps with T, so Perf comes close to planned days delivered over capacity, adjusted by quality, cost, time and simplicity. The ratios on quality, cost and simplicity keep it from being a plain throughput count. Three rules:

• The lead writes V and Cap down before work starts. The developer can challenge either, and a disagreement is settled before work begins. This is the same habit as writing the spec before the prompt.
• If scope changes before the midpoint of the planned time, V and the plan are recalculated together. After the midpoint, V stays and the change is logged.
• Each quarter, compare V with actual days across finished services, so the lead's estimates are scored too.

What is not solid

The weights, clamps and defaults are starting values. They are not research-backed. Do not tune them until the scores match what you saw, because that only encodes your impressions. Run a sensitivity check instead. Vary each weight by 25 percent up and down and see whether the ordering of developers changes. Treat any ordering that flips as noise. Tune only against outcomes you know independently, such as defects found later.

Prior art

The nearest published pieces all work at team level. Critical Path (12 May 2026, an opinion newsletter) and Unblocked (12 June 2026, a vendor) propose cost per merged pull request. DX, a vendor, includes an agent hourly rate in its measurement hub. Sonar (29 September 2026, also a vendor) covers escaped defects. We looked for a published scorecard that combines these for individuals and did not find one.

Four developers, one service

Every number in this section (bills, days, defect points, scores) is invented, to show how the formula behaves. This article reports no results from running it on real people.

Common inputs: the service is 10 scope units (V = 10), the baseline is $60 per unit so B = $600, the plan is 10 days, d_max is 2 and Cap is 10, so the window in this example holds just this one service. Blend is 0.4E + 0.3T + 0.3S.

Quality multiplies everything. D is the cheapest and the fastest, and its blend is above 1.1. It scores 0.24 because Q is 0.22: it needed three handoff attempts and left nine defect points. In this example, starving the model to look efficient loses, though those defects are inputs we chose, not a result.

A pays $1,500, the same as C, arrives two days late and still ships defects, so it scores 0.33. C is expensive but clean: on schedule, no defects, but 2.5 times the baseline cost, so its cost term is 0.40 and it scores 0.76. That is acceptable, not best.

B wins at 1.07. The bill is $420, the service reaches QA-ready in 8 days, and one defect point gets through. B is built on the workflow we use: cheap models build and an expensive model reviews, described under "Our loop" in the counter-arguments section. B hits the 1.2 clamp on both cost and time, so saving more or going faster earns nothing extra.

In our experience that loop closes lots of features fast and stable, but we have no measured numbers, so B illustrates the formula and proves nothing. Its lead over C comes mainly from cost: B beats C by 0.31, and the cost term accounts for about 0.32 of the 0.37 gap in their blends. The review rounds are why we gave B a quality of 0.95.

The cost floor is 0.1, not 0.5. With a 0.5 floor, any bill above twice the baseline would score the same, so a $1,500 bill and a $15,000 bill would cost the same. At 0.1, extra spend keeps costing score until the bill reaches ten times baseline, $6,000 here.

The human gate: ready for QA is not ready for production

Our bar for a developer is ready for QA. We do not aim for ready for production, because that decision has to stay human.

The gate has two steps. AI runs test rounds against the written requirements. Then a person does a happy-path click-through, walking the product the way a user would when everything goes right. On a small SaaS the whole gate should take no more than one day.

We write it as a checklist so it can be scored:

• Each written requirement has a result from the AI test rounds.
• A human completed the happy path from start to finish.
• Every failure found in either step is fixed and rerun.

The result is the H term in the scorecard table above.

Between two positions

Addy Osmani wrote on 15 Jun 2026 that a human owns the merge and AI review is a sensor. He works at Anthropic on Claude Code, so he is a practitioner close to a vendor.

Martin Monperrus argued in an arXiv paper on 11 Jun 2026 that mandatory human review should go for routine changes, with people kept for high-risk, novel or regulated ones. It is a position paper with no new data. Blake Crosley replied on 24 Jun 2026 that review relocates to intent and accountability and does not disappear.

Our gate sits between them. It does not ask a human to read every diff. It also does not hand the production decision to the agents. What a senior reviewer checks without reading every line is covered in what senior oversight means when AI writes the code. We looked for a pre-QA handoff gate used to score an individual developer and did not find one. The nearest is team-level: the Sonar escaped-defect tracking mentioned above.

A developer could hand work to the gate before it is ready, to look fast. Defects found later, in QA or in the first 30 days after release, count back against the developer through D, which lowers Q, and Q multiplies everything else. A rushed handoff should therefore tend to cost more than it saves.

How this can go wrong

Goodhart applies to this scorecard too. Any number that touches a review will be pushed on. We would rather list the weak points than pretend they are not there.

Starving the model. If cost is rewarded, people will spend less than the task needs. Three things limit this, and none removes it. First, the clamps: cost is clamped between 0.1 and 1.2, time between 0.5 and 1.2, and simplicity tops out at 1, so the blend cannot exceed 1.14, which is 14 percent over plan.

Second, quality multiplies the blend. D scores 0.24 on its inputs, but most of that comes from H = 0.4 and 9 of 20 defect points, which we picked. With a clean first handoff (H = 1), D keeps 0.61, still well below B. The example assumes that cheap runs produce defects; it does not show it.

Third, the lead writes scope units down before work starts, so a developer cannot shrink the scope afterwards to look efficient. That moves the risk to the lead: scope can still be negotiated up before work starts, which raises the numerator, and Cap can be negotiated down. The rules under "Who sets scope" limit that and do not remove it.

The clamps still allow a trade. With cost and time at 1.2 and simplicity at 1, a deliverable with H = 1 and two of the example's 20 defect points (Q = 0.9) scores 1.03. That is above a flawless, on-plan, baseline-cost deliverable at 1.0. Quality can fall by about 12 percent before the speed and cost bonus is gone. A stricter version would pay the cost and time bonus only when D is below a threshold.

Privacy. The inputs are the bill, the QA and defect records, the schedule, and code-quality measures. Never the prompts, because reading prompts turns a scorecard into surveillance. Usage mandates have backfired in some reports. Fortune reported on 13 April 2026 that Duolingo's CEO backed off evaluating employees on AI usage, and The Register carried an anecdote on 19 November 2025 about a director checking usage. Both are single cases.

Why per person, and the case for teams. Most measurement sources recommend team level. LeadDev (Chantal Kapani, 17 August 2026), quoting Ankit Jain, says to measure systems and not individuals. DX says never to track individuals, Critical Path argues for team level, and Faros warns against per-engineer leaderboards. The worry is real: individual numbers turn into leaderboards.

Our answer has four parts. These sources write for organizations with many engineers, where an individual number travels up a chain and becomes a ranking. At five to six people everyone already knows who does what. A team number averages across very different roles and hides who needs help. So the score stays between the developer and the lead, is shown with its inputs, is read as a trend, and is used as a conversation tool, not a ranking and not the sole basis for pay. The risk that remains is that someone treats it as a leaderboard anyway.

Small samples. This is the real risk at this size, and the arithmetic is tight. A 90-day window would hold about 65 working days. At roughly 10 planned days per service that is at most about 6 deliverables per developer, so a three-deliverable minimum would be half of capacity. Six months holds about 130 working days, so up to roughly 13 services, and three is a workable floor. D needs 30 days of post-release defects, so deliverables from the last month are not fully scored, and the score always lags. With fewer than three closed deliverables there is no score. Even then, three points make a noisy trend. A team number would pool more deliverables and be steadier, but it would hide who needs help, so we accept the noise and read each score as a trend and a prompt for a conversation.

Shared work. The formula assumes one owner per service. For shared work, split V and Cap between the owners in writing before work starts, and score each owner's share as its own deliverable: its own tagged key for C, its own defects under the triage rule for D, its own changed files for S, with H and T taken from the one shared gate. Review and maintenance time stay outside the score, so a developer who spends a quarter on them will look under-delivered, which is one more reason to use the score as a conversation.

Pay. The score should not be the sole basis for pay. Fortune, also on 13 April 2026, mentioned Omnisend tying raises of 2 to 4 percent to outcome-based AI use. That is one report, and we have not seen how Omnisend measures outcomes. If money is attached at all, keep the amount small and keep a human making the decision. The third article in this series, on pay, does let the score set a default position in a pay band. It does so inside a per-review cap, a budget and a written human sign-off, and it lists the tension with this caution as a limitation.

The counter-arguments, and our loop

We expect pushback on three points. Some of it is fair.

Tokens and cost

Rushabh Doshi argued on 12 February 2026, in "Stop counting tokens", that budgets should not constrain engineers. It is opinion with no data. A Hacker News commenter, tabbott, made a sharper version in an April 2026 thread on tokenizer costs: engineer time dwarfs token cost.

We take the objection as fair, and the formula answers it only in part. Cost is one term of three in the blend, clamped between 0.1 and 1.2, and quality multiplies everything. But cost carries the largest weight, 0.4, and on our invented numbers it drives B's lead, as the example shows. We will not use those numbers as evidence against Doshi or tabbott.

The 0.4 is a starting value and a design choice, not research-backed. The cost term is the one that puts model spend into the score. A team that agrees with tabbott should give time the largest weight instead. Human hours sit outside C altogether, so the formula does not capture the cost he stresses. They enter only through T.

Does AI help at all

We hold that every developer should now use AI. The evidence for a blanket gain is mixed. METR published a study on 10 July 2025: 16 experienced developers, 246 issues, 19 percent slower with AI while believing they were 20 percent faster. METR now flags that page as out of date. Rob Bowley's reading of the DORA 2025 report, described above, points the same way. Both are reasons to measure the effect rather than assume it, which is what the scorecard is for.

Fleets versus a few expensive sessions

We think a developer who manages a fleet of cheap agents is worth more than one running a couple of very expensive sessions. We looked for a source comparing the two on real software and did not find one, so this is our judgment, not a result. Two sources found the opposite for cohesive work.

Akita wrote on 25 April 2026 that on one simple Rails app, solo Opus scored 97 out of 100 in 18 minutes and no planner-executor mix beat it on quality, cost and time together. His cost figures are inconsistent, and independent batch tasks may differ. Cognition, a vendor that published no methodology, wrote on 22 April 2026 that its own test with a cheap primary model failed, and called parallel writer swarms "mostly a distraction".

Neither source is a test of our loop. Our view is most plausible for the case Akita says may differ: work that splits into independent pieces.

Arize, a vendor, cited an Anthropic result in August 2026: a Fable 5 orchestrator with Sonnet 5 workers kept 96 percent of the score at 46 percent of the cost. That was a web-research benchmark, the number is vendor-reported, and it is a different pattern again: an expensive orchestrator with cheap workers.

Our loop

This is the workflow we use. Haiku and Sonnet build the service. Opus reviews and writes a gap plan. Sonnet fills the gaps. Opus reviews again, and the loop repeats. A cheap model may drop needed changes, so it needs several review rounds, and we use the loop when time allows.

In our experience it closes lots of features fast and stable. That is experience, not a measured result. The scorecard is how it can be tested: the review passes land in the real bill, so the loop has to pay for itself in cost, days and defects. If it does not, the scorecard will show that.

What the company owes its developers

Measuring the person is only fair if the company has done its part first.

Provide the tools. If every developer is expected to use AI, the company supplies approved tools. Otherwise people bring their own.

Set guardrails from the start. The Cloud Security Alliance argued in a research note on 3 April 2026 for approved tool lists, least privilege and audit logging around AI coding assistants. The note is threat-focused and says nothing about training.

Ban and block shadow AI. You cannot monitor, track or protect what you cannot see. The Register reported on 27 May 2026 on an Okta survey finding that 52 percent of knowledge workers use unapproved AI tools. Okta is a vendor and commissioned the survey, so we read the number as a sign that unapproved use may be common, not as a measure. Okta's Peri also warned that bans push use underground, which is a vendor claim too. That is why the ban comes with approved tools good enough to use, and why the block matters: it is what gives you visibility.

Train everyone, briefly. Guardrails matter more than training. The evidence on training is mixed. Cybersecurity Dive reviewed studies on 20 October 2025 and found that awareness training barely changes phishing behavior. The Konrad-Adenauer-Stiftung (KAS) argued in a short commentary on 20 February 2026, with no data behind it, that technical safeguards beat one-off courses. We looked for studies of AI-security training for developers and found one, Kharma et al. on 20 April 2026: 12 developers, one Java stack, one model, so a hint and not evidence.

So guardrails come first, and a short, practical course tied to the tool rules comes second. The risk has not gone away, so we would not drop training yet, even on that evidence.

The EU AI Act deserves a brief mention. KI-Campus wrote on 28 July 2026 that the revised Article 4, which covers AI literacy and not security training specifically, asks for measures and not guaranteed competence. It is the only source we found on its current status, and it gives no date for when the change enters into force.

That is the company's side. Once it is in place, write scope and capacity down before the next service starts, run the gate, and score each developer on what survives, not on what ships.

What to do tomorrow

1. Write scope and capacity down before the next piece of work starts. The lead sets scope in planned days and each developer's capacity for the quarter, and any disagreement is settled before anyone prompts a model.
2. Tie the model bill to a deliverable. Tag API keys or pull the provider's per-task usage export, review passes included. If the team is on flat-rate seats, the formula cannot run yet, and knowing that now is the point.
3. Write the handoff gate as a checklist. AI test rounds against the written requirements, then a human happy-path click-through run by QA or the lead, never by the developer.

Sources

• Faros AI, Tokenmaxxing: Why AI token consumption isn't engineering productivity (23 Apr 2026, updated 29 May 2026)
• Huang et al., More Code, Less Reuse (arXiv 2601.21276 / MSR '26, 29 Jan 2026)
• Rob Bowley, DORA 2025 AI assisted dev report: Some Benefit, Most Don't (1 Oct 2025)
• Gergely Orosz, The Pragmatic Engineer, 23 Apr 2026
• The Decoder, 8 Sep 2026
• LeadDev, 17 Aug 2026
• Bai et al., arXiv 2604.22750v2, Apr 2026 (v2 cited; a later version dated 2 Oct 2026 exists)
• Akita, 25 Apr 2026
• Cognition, 22 Apr 2026
• Simon Willison, 19 Aug 2026
• Spencer, Substack, 20 Jun 2026
• Databricks, Benchmarking Coding Agents on Databricks' Multi-Million Line Codebase, 8 Jul 2026
• Critical Path, Tokenmaxxing is the new lines-of-code. Track cost-per-decision instead, 12 May 2026
• Unblocked, Cost per Merged PR: The Unit Economics of AI Coding, 12 Jun 2026
• DX, How to measure AI's impact on developer productivity (measurement hub)
• Sonar, The Acceptance Gap, 29 Sep 2026
• Addy Osmani, Agentic Code Review, 15 Jun 2026
• Martin Monperrus, The End of Code Review, arXiv 2606.13175, 11 Jun 2026
• Blake Crosley, Agents Supersede the Reviewer, Not the Review, 24 Jun 2026
• Fortune, 13 April 2026 (Duolingo CEO backs off evaluating employees on AI usage; Omnisend raises)
• The Register, 19 November 2025 (Devs gripe about having AI shoved down their throats)
• Rushabh Doshi, Stop counting tokens, 12 Feb 2026
• Hacker News thread, Measuring Claude 4.7's tokenizer costs (tabbott), Apr 2026
• METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, 10 Jul 2025
• Arize (Laurie Voss), How cheap models changed multi-agent economics, Aug 2026
• Cloud Security Alliance, AI Coding Assistants as Attack Surface (3 Apr 2026)
• The Register, Bosses blinded by confidence about shadow AI use by workers (27 May 2026)
• Cybersecurity Dive, Why security awareness training doesn't work (20 Oct 2025)
• Konrad-Adenauer-Stiftung, AI literacy requirements should be reformed to be more practical (20 Feb 2026)
• Kharma et al., arXiv 2604.17763 (20 Apr 2026)
• KI-Campus, EU AI Act: AI Omnibus recalibrates Article 4 (28 Jul 2026)

Frequently Asked Questions

How do you measure developer productivity when everyone uses AI? Not with token counts or lines of code, because both measure activity and both can be gamed. The scorecard in this article uses ratios instead: quality at handoff, the model bill in dollars against a baseline, time against the plan and code simplicity against the codebase. Each developer gets their own score, read as a trend over the two most recent quarters with at least three closed deliverables.

Are token counts a good measure of developer performance? No. Token counts are not comparable across model tiers, token use for the same task can vary up to 30 times between runs, and rewarding the number produces the number. The scorecard uses the model bill in dollars instead, because a bill already prices each model, and it clamps the cost term so one bad run cannot swing the score.

Should developer performance be measured per person or per team? Most published guidance says team level, and the worry behind it is real: individual numbers turn into leaderboards. For a team of five or six, a team number averages across very different roles and hides who needs help. This article argues for a per-person score kept between the developer and the lead, shown with its inputs, read as a trend, used as a conversation tool and never the sole basis for pay.

What does ready for QA mean for a developer working with AI? AI runs test rounds against the written requirements, then a person does a happy-path click-through of the product. On a small SaaS the whole gate should take no more than one day. Passing it first time scores 1.0 on the handoff factor, and the production decision stays with a human.

---

If you want a second pair of eyes on scope, baselines and the handoff gate before you score anyone, Fractional CTO & Technical Advisory is built for exactly that, and a diagnostic call is the place to start.