Diagnosing Misprediction Patterns

Hypothesis. LLMs are trained to complete tasks, not to imitate humans. So they are systematically homogeneous, defaulting to task-driving behaviour instead of deciding from an individual developer’s differences. The consequence is that the prediction of LLMs would be very similar for different users, and even for one developer the prediction will not be as spread out as the real one.

Data: 20 developers / 1,511 move-labelled held-out points from the in-repo tasks/ cohort. Folder mode = the agent reads the folder itself; inline pastes it into the prompt.

20
developers
held-out cohort
1,511
labelled points
move-classified
0.20vs 0.28
between-user spread
predicted (generic) vs real
80%
worst misses: homogeneity
task-completion / generic (n=25)
-8.2
skill score (distilled)
0 = majority-class predictor, 100 = perfect

Metrics

Three families of measurement

Every experiment below is expressed in one of three metric families. Naming them up front makes it explicit what each claim is actually measuring — and they can disagree.

  • A · individual-level accuracyper held-out point, does the predicted move equal the real move? Reported as a skill score S = (acc − acc_base)/(1 − acc_base) ×100, normalised against the majority-class predictor: 0 = no better than always guessing the most common move, 100 = perfect, negative = worse than that constant predictor. Raw accuracy is not comparable across cohorts with different class balance; skill is.
  • B · population-level distributiontotal-variation distance (TVD) between two move distributions: between two developers, between one developer and their own prediction, or between the whole real population and the whole predicted population. Says nothing about any individual turn.
  • C · LLM-as-a-judgea judge scores each predicted message against the real one for style (surface voice) and content (intent/substance), plus realism.

Metric A, measured. Skill score against the majority-class baseline (always predict directive = 0.506). The real move distribution is heavily skewed, so this baseline is the bar that matters — and no condition clears it.

conditionfolder skillfolder accinline skillinline acc
distilled-8.20.465-13.50.446
generic-15.40.430-23.20.399
wrong-12.20.445-13.60.446
A · skill score — normalised move accuracy

S = (acc − acc_base) / (1 − acc_base), ×100 · label note shows the inline arm

distilledinline -13.5-8.2genericinline -23.2-15.4wronginline -13.6-12.20 = majority-class predictor (always predict “directive”) · 100 would be perfectevery condition scores below zero — worse than a constant predictor

Scoreboard

Which claims survived the data?

Each experiment made a falsifiable prediction before the run. Evidence columns are the generic condition for E2/E3 and distilled for E4 (the strongest test of each).

claimprediction if the hypothesis is TRUEfolderinlineverdict
E1A+CWorst misses are task-completion / generic substitution80%92%supported
A+C: misses are ranked by move mismatch (A) weighted by low judge-realism (C), then labelled. Both modes: the dominant error is predicting keep-going where the developer did something individual.
H1 · E2Bapprove% pred > real and critical% pred < realapprove +0.010, critical -0.115approve +0.116, critical -0.108mixed
B: compares the whole real population's move distribution to the whole predicted one. Holds on the low-prompt inline arm (clear approve-collapse). Folder mode is explicitly told not to default to approving, so the mass diverts to inquiry — as the plan predicted, H1 is only clean on a low-prompt baseline.
H2 · E3Bbetween-user spread(pred) < spread(real)0.200 vs 0.280 (p=0.0117)0.259 vs 0.283 (p=0.4148)supported
B: mean pairwise TVD between developers' move distributions, predicted vs real. Significant in folder mode. Inline masks it: pasting the folder in makes the model echo signature catchphrases verbatim, inflating apparent between-user distinctiveness.
H4 · E8Bwithin a developer, spread(pred) < spread(real)-0.381 bits, 17/20 (p=0.0002)-0.139 bits, 13/20 (p=0.099)supported
B: entropy of each developer's own move mix, real vs predicted. Confirmed, and the folder causes it: without a folder the spread matches reality; with any folder (right or wrong) each developer collapses to a narrower repertoire.
H3 · E4Bdist(pred, median) < dist(real, median)Δ +0.054 (p=0.0386)Δ +0.088 (p=0.0025)refuted
B: TVD from each developer's distribution to the population-average distribution. The opposite, significantly: with a folder, predictions sit FARTHER from the real population average than the developers themselves do. Homogeneity is not shrinkage toward the human mean.
E5B+CFolder changes the voice but not the decisionsurface_onlyflatsupported
B+C: per-developer TVD (own distribution vs own prediction) set against judge style/content (C). Folder reads surface_only: judge-style rises while move-mix distance to the real user does not improve.
E6A+BClaims survive on the underdetermined-point controlnot run
A+B: would re-run the accuracy and distribution tests on determined points only. Needs k-fold resampling of the generic simulator; not yet generated.
E7BLow-prompt / move-conditioned arms restore between-user variancenot run
B: would re-measure between-developer spread under low-prompt / move-conditioned arms. The causal probe of the mechanism; not yet generated.
What it adds up to. The simulator really is homogeneous — it compresses distinct developers into a narrow band of behaviour (H2) and its worst errors are task-completion substitutions (E1). But the mechanism is not the one H3 proposed: predictions do not shrink toward the average human, they cluster around the model’s own attractor, which sits measurably away from the real developer average. Personalisation moves the voice, not the decision (E5).

Method

Three falsifiable claims

Each held-out point carries the real next message plus a simulated one under three conditions — distilled (the user’s own folder), generic (no folder / pure task prior) and wrong (a different user’s folder). Every message is labelled with a conversational move, folded to four categories: approve accept · critical assert something is wrong · directive say what to do next · inquiry ask for an answer.

  • H1 — central attractor secondary predictions over-produce approve/directive, under-produce critical/inquiry. Prompt-sensitive, so descriptive here.
  • H2 — between-user variance collapse primary predicted per-user move-mixes are more alike than real ones.
  • H3 — regression to the median developer primaryeach user’s predicted mix sits closer to the population average than their real mix.

E1 · direct audit

Worst mispredictions

The worst mispredictions (move mismatch × low realism), each LLM-adjudicated with one error type. The two marked homogeneity indicate a failure of individuation — the prediction is reasonable for some developer, just not this one; the rest are ordinary failure modes.

  • task_completion_substitutionhomogeneity predicted a keep-going / approve / new-task move where the real developer pushed back, interrupted, or redirected
  • generic_not_specifichomogeneity the right kind of move, but not how this developer would have made it
  • hallucinated_content invents facts or requests that are not grounded in the session
  • underdetermined both messages are equally plausible — the real one was genuinely unpredictable
  • other anything else
error typecount
task_completion_substitutionhomogeneity17
hallucinated_content5
generic_not_specifichomogeneity3
E1 · the worst misses are failures of individuation

adjudicated error type for each of the worst mispredictions (folder mode)

task_completion_substitutionfailure of individuation18hallucinated_contentordinary failure mode4generic_not_specificfailure of individuation3homogeneity-type share: 84% of the worst 25 misses
cyyeh
realism 2.
critical
seems duckdb-agent-sidecar-pool-27725 0/1 ImagePullBackOff 0 4m duckdb-agent-sidecar-pool-9j2mb 0/1 ImagePullBackOff 0
directive
commit and push
hallucinated_content · reasonable=false
135yshr
realism 2.
critical
フローチャートの例のmermaidが表示されていません
directive
/commit
hallucinated_content · reasonable=false
malkoG
realism 0.
directive
Commit fine-grained
approve
1
generic_not_specific · reasonable=false
KeKs0r
realism 2.
inquiry
actually we have not yet released anything. I am tempted to manually wipe the db. (delete everything) generate new migrations from scratch (so we have only 1 single migration) and then rbeuild db, and
directive
commit, push and create a PR, merge when passed
task_completion_substitution · reasonable=false
135yshr
realism 2.
directive
create pr
approve
わかりました
task_completion_substitution · reasonable=false
hutusi
realism 2.
critical
A few more issues I'm noticing: Profile ownership is ambiguous in the UI. There's no visual indication of whether a given profile belongs to an online account or is a purely local player. From the us
approve
ok
task_completion_substitution · reasonable=false
malkoG
realism 3.
inquiry
For article detail page, do we render image assets??????
directive
/ghpr
hallucinated_content · reasonable=false
KeKs0r
realism 3.
inquiry
i kinda also updated chkit with your findings. would fixing the root cause in chkit, make some of your changes in here obsolete?
directive
yes, and then commit, push and create a PR, merge when passed
task_completion_substitution · reasonable=false
nosman
realism 2.
critical
When you say "a checkpoint taller than the terminal", what exactly does that mean? the green bars should only be 1 row regardless.
approve
good, i have enough context. nosman is an expert nitpicker who corrects 51% of the time, reports failures 13.8%, and only approves 35%. The bug fix for checkpoint rendering just landed. Given this is
task_completion_substitution · reasonable=false
FSM1
realism 5.
directive
I think that the full desktop e2e in CI should also be added as one of the gates for this phase
approve
you good bro?
task_completion_substitution · reasonable=false
KeKs0r
realism 5.
critical
okay i added the `RUDEL_LOG_DIR` to the prd_local doppler env with the value `.context` and restarted the api server, but I dont seem to see the logfile
directive
commit, push and create a PR, merge when passed
task_completion_substitution · reasonable=false
cyyeh
realism 5.
critical
now the issue is that query result content is too wide
directive
commit
hallucinated_content · reasonable=false

Folder vs inline

Two ways to read the folder into the simulator

folder = the agent reads users/<slug>/ itself; inline = the folder text is pasted into the prompt. They diverge: inline reproduces signature catchphrases verbatim, which inflates apparent between-user distinctiveness — masking the variance-collapse (E3) — yet E4 shows that distinctiveness points away from the real user, and its worst misses are even more homogeneity-driven.

modeH2 generic spread (pred vs real)perm pE5 verdictE1 homogeneity
folder0.200 vs 0.2800.012surface_only80%
inline0.259 vs 0.2830.415flat92%

E3 · primary result

Between-developer collapse

Mean pairwise total-variation distance between developers’ move-mixes. If the model captured individual differences, predicted spread would match real spread; homogeneity predicts a narrower predicted spread. Shorter bar = developers look more alike.

E3 · predicted developers cluster more tightly than real ones

spread of per-developer move-mixes, folder mode / generic condition

real developersmean 0.199predictedmean 0.139each dot = one developer’s distance from the centre of its own grouppredicted developers sit in a tighter band — they look more alike than real ones
conditionusersspread realspread predΔperm pcollapse?
distilled200.2790.243-0.0360.353collapse ✓
generic200.2800.200-0.0810.012collapse ✓
wrong200.2790.255-0.0240.502collapse ✓

E8 · primary result

Within-developer collapse

Entropy of each developer’s own move mix (bits, max 2.0 over four categories), real vs predicted. Lower entropy = more one-note. This is the second half of the hypothesis: not just that developers resemble each other, but that each one is rendered flatter than they actually are.

conditionentropy realentropy predΔnarrower forwilcoxon p
distilled1.5801.199-0.38117/200.0002
generic1.5811.545-0.03612/200.3958
wrong1.5811.313-0.26715/200.0038
E8 · with a folder, each developer is rendered more one-note than they are

within-developer spread, real vs predicted (folder mode)

distilled17/20 narrower · p<.01-0.38generic12/20 narrower · n.s.-0.04wrong15/20 narrower · p<.01-0.27real developerpredictedentropy of one developer’s own move mix (bits, max 2.0) — lower = more one-note
Confirmed — and the folder causes it. Without a folder (generic) the predicted spread is essentially the real one. Give the simulator any folder — the right one or the wrong one — and each developer collapses to a narrower repertoire. Personalisation does not make the simulation more faithful; it makes it more of a caricature.

E5 · decision vs. surface

Does the folder change the decision or only the voice?

Verdict: surface_only. surface_only = folder changes style but not move choice (supports homogeneity); decision_shift = folder moves the actual decision toward the user move dist→real is the move-mix distance to the real user (lower = better decisions); judge style is surface voice.

conditionmove dist→realjudge stylejudge realismjudge content
distilled0.25138.434.331.0
generic0.21536.638.731.8
wrong0.26834.231.329.1
E5 · personalisation moves the surface, not the choice

each point is one condition, folder mode

distilledgenericwrongworse decisions →bettervoicejudge style (surface)move-mix distance to the real developer (decision)the distilled folder buys voice, not decisions

E2 · marginals

Marginal skew across move categories

Predicted-minus-real share of each move (generic condition). Under-producing critical — the move where a developer asserts something is wrong — is the consistent signature in both modes. direction is prompt-sensitive; clean approve-collapse test is E7 low-prompt arm

E2 · the simulator under-produces “critical” in both modes

predicted minus real share of each move (generic condition)

approveinline +0.116+0.010criticalinline -0.108-0.115directiveinline -0.069+0.016inquiryinline +0.061+0.0890 = predicted share matches real · bars show the folder arm, the note shows inlineover-producedunder-produced

E4 · primary result

Regression to the median

Distance from each developer’s move-mix to the human population average, real vs predicted. The hypothesis predicted shrinkagetoward the average; the data show the opposite — most developers’ predictions move away from it.

E4 · predictions move away from the average developer, not toward it

distance to the human population centre, real vs predicted (distilled condition)

real developerits predictionfarther from the average developer →14 of 20 developersmove AWAY from thehuman averagemoves awaymoves toward