Ask
29
@dbt_and_dust ·

How do I A/B two coding models on the same task without fooling myself?

Models are shipping faster than I can form an opinion about them, and every switch decision I have made this year was a vibe that I reversed two weeks later. I want a protocol small enough that a solo dev will actually run it.

What I think I need answers to:

  • what to hold constant, beyond "same prompt"
  • how many tasks before a difference means anything, honestly
  • how to grade without my own expectation deciding the result
  • what to record so the comparison is still useful when the next version ships

I do not need a research-grade eval. I need something I can run in an afternoon that stops me switching tools on the strength of one good session.

7 answers Share
Report

Answering anonymously — a moderator will review it first.

  • @petra_lindqvist · 2h ago · 2 replies

    Hold constant: same repo commit, same starting context, same prompt file read from disk rather than retyped, same tools available, same reasoning setting. Vary exactly one thing.

    Run each task twice per model. Run-to-run variance on the same model is bigger than most people expect, and if you do not measure it you will attribute your own noise to the model.

    Record per run: wall-clock, total tokens, number of tool calls, and one binary outcome, "did the diff pass the tests that existed before the run". The binary is what makes the whole thing comparable later. Everything else is diagnostic colour.

    18
    Share
    Reply

    Answering anonymously — a moderator will review it first.

    Report
    • @desmond_ruiz · 2h ago

      And write the assertion before you run anything. If you decide what counts as success after reading the output, you are grading fluency, not correctness. Models are extremely good at sounding like they finished.

      7
      Share
      Reply

      Answering anonymously — a moderator will review it first.

      Report
  • @proof_pilar · 2h ago

    Grade blind, and grade the next day. Strip model names from the transcripts and diffs, give the files neutral IDs, shuffle them, then score.

    My hit rate for guessing which model produced which diff, on models I was sure I could tell apart, was barely better than a coin flip once the names were gone. That result alone changed how much I trust my own impressions from a normal working day.

    12
    Share
    Reply

    Answering anonymously — a moderator will review it first.

    Report
  • @hot_heap_hana · 2h ago · 2 replies

    Be honest about what five tasks can tell you: it can catch a disaster, it cannot separate two close models. If model A goes 5/5 and B goes 4/5, you have learned essentially nothing.

    So use the small set as a smoke test, "is this thing unusable on my stack", and get the fine-grained signal from a running log of real work: date, model, task, outcome, one line of why it failed. After a month that log answers the question your afternoon experiment cannot.

    10
    Share
    Reply

    Answering anonymously — a moderator will review it first.

    Report
    • @dark_room_dev · yesterday

      Keep a regression file alongside it: every task any model failed, saved with its starting context. When a new version ships, that file is the first thing you run. It is the cheapest eval you will ever own because it is made entirely of cases that already broke something.

      5
      Share
      Reply

      Answering anonymously — a moderator will review it first.

      Report
  • @yield_on_cost · 2h ago

    Measure cost per completed task, never cost per token. A model that is three times cheaper per token and needs four attempts is the expensive one, and it also cost you the attention of four review cycles.

    Two things that quietly break this calculation: fast or priority variants of the same model name carry a different rate entirely, and retries after a failed run are usually not counted by whoever is telling you their per-token figure.

    9
    Share
    Reply

    Answering anonymously — a moderator will review it first.

    Report
  • @annualfee_amy · yesterday

    Do not run the eval on your nicest repo. Run it on the one with the 900 line file, the two competing conventions and the tests that were commented out in 2023. That is where the differences between models are visible, and it is also where you actually work.

    4
    Share
    Reply

    Answering anonymously — a moderator will review it first.

    Report