Building a Systematic LLM Evaluation Framework from Scratch

coda · Tech · 2023 · source Agentic: no · promotional bias: low · source-backed · extracted with prompt 0.5.4 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Productivity software

Coda needed systematic GenAI evaluation after model upgrades changed behavior and broke prompt expectations across AI assistant, table, and RAG features.

Constraints:

Architecture

Coda evolved its evaluation stack in four phases: OpenAI Playground for early prompt iteration, Coda tables as an internal prompt playground, Vellum for collaborative prompt/dataset experiments, and application-integrated automated evaluations whose scores are uploaded to Braintrust for visualization, trend tracking, and benchmark drilldown.

Diagram confidence: explicit (topology described by the source).

flowchart LR
  ai-product-features[AI Product Features] --> application-code[Application Code]
  ai-product-features --> benchmark-dataset[Benchmark Dataset]
  benchmark-dataset --> openai-playground[OpenAI Playground]
  benchmark-dataset --> coda-prompt-playground[Coda Prompt Playground]
  benchmark-dataset --> vellum[Vellum]
  application-code --> automated-eval-runner[Automated Eval Runner]
  benchmark-dataset --> automated-eval-runner
  automated-eval-runner --> braintrust[Braintrust]
  braintrust --> human-reviewers[Human Reviewers]
  human-reviewers --> benchmark-dataset
Drag to pan · scroll or use +/− to zoom · reconstructed from the source's described component topology

Components

Component Role Interacts with
AI Product Features Coda assistant, table AI operations, and RAG-style doc question answering that require quality checks. Application Code, Benchmark Dataset
Application Code Production prompt assembly and manipulation layer that the final evals needed to test closely. AI Product Features, Automated Eval Runner
Benchmark Dataset Curated examples, edge cases, internal usage, and generated/seeded cases used to evaluate features. OpenAI Playground, Coda Prompt Playground, Vellum, Automated Eval Runner
OpenAI Playground Early manual prompt experiment environment. Benchmark Dataset
Coda Prompt Playground Internal Coda table that combined prompts and benchmark rows and supported manual evaluation. Benchmark Dataset
Vellum Vendor prompt playground for shared prompts, datasets, and manual pass/fail ratings. Benchmark Dataset
Automated Eval Runner Integration-test-like workflow that evaluates application behavior and produces scores. Application Code, Benchmark Dataset, Braintrust
Braintrust Visualization and analysis system for uploaded eval scores, timeline trends, aggregate runs, and benchmark drilldowns. Automated Eval Runner, Human Reviewers
Human Reviewers Engineers, PMs, designers, and teammates who inspect outputs, identify edge cases, and enrich datasets. Braintrust, Benchmark Dataset

Data flow

A feature's prompts and benchmark data first moved through manual playgrounds and Coda tables, then through Vellum for shared prompt/dataset runs, and eventually through integration-test-style automated evals close to application code. Completed eval runs upload scores to Braintrust, where engineers inspect aggregate trends and individual benchmark failures.

3 supporting quotes
“last year um we have a table uh here that contains uh each of the Benchmark that we have uh that's a roll and then if you look at the fourth column which is the rat Arrow that's where we um behind the scene what we do is we combine the system prompt that we have”transcript, stated
“we started integrating the an automated eval workflow as a part of our test integration test Suite where we basically run uh an eval similar to to how we run test”transcript, stated
“once we complete an evaluation run all we have to do is to push all the score upload the score to brain trest and they can visualize it for us”transcript, stated

Why this architecture

Coda moved from playgrounds to app-integrated evals because prompt-only and manual workflows did not reflect production behavior, did not scale, and consumed engineering time that the team wanted to spend improving AI quality.

3 supporting quotes
“all the prompts that we have written in the past no longer works the response are much more conversational rather than instructionals”transcript, stated
“our eval is actually decoupled from our application code um if you look at all the examples that we have what we're evaluating is actually the prompt but our application code not only takes the prompt but they also do additional”transcript, stated
“uh while it works we will watch B spend time on improving air quality rather than you know writing SQL which is where we met Brain Trust uh Brain Trust matters right where when we need them this is back in uh ma middle of”transcript, stated

Models used: DaVinci · GPT-3.5 Turbo · GPT-4 Turbo

Scale

Alternatives considered (roads not taken)

Manual OpenAI Playground testing

Rejected because: It was easy to start but required manual copy-paste, lacked grading, and did not track behavior over time.

“it requires a lot of manual copy and pasting for it to work to get the eval going and more over it lacks the ability to grade like an AI output”transcript, stated

Maintaining Coda's internal prompt playground as the main evaluation tool

Rejected because: Conversation-model changes increased maintenance work, and the lean team preferred to spend time on AI quality.

“Etc the work that we need to maintain the document that we have to do AI playground uh has increased by a lot we were still pretty lean at that time we only have less than five engineers and instead of spending time maintaining the tool which we spend a lot of time doing”transcript, stated
“instead of spending time maintaining the tool which we spend a lot of time doing at that time we were rather focusing on improving the AI quality”transcript, stated

Prompt-playground evaluation decoupled from production code

Rejected because: Actual application code assembled payloads differently, so playground passes did not guarantee production behavior.

“when we run eval everything works great but then when we run it actually in the application code when we run it to the release it to the alpha users the results that we get is dramatically different”transcript, stated

Snowflake and Mode reporting for eval results

Rejected because: The team started maintaining SQL and reports instead of improving AI quality.

“we get um at the end what we have is we started spending me time maintaining that SQL and that reporting capability uh while it works we will watch B spend time on improving air quality rather than you know writing SQL which is where we met Brain Trust uh Brain Trust matters right where”transcript, stated

Patterns

eval-driven-development (evaluation)

Coda ran systematic evals close to application code and used score trends and benchmark failures to guide prompt/model changes.

“having a systematic way to understand how changes impact AI quality is essential to a gen feature application”transcript, stated

canary-rollout (release)

The team compared model versions and prompt changes through evals before confidently moving to cheaper/faster models.

“we wanted to use it instead of the old D Vinci model and here comes the interesting thing when we're testing it”transcript, implied

human-in-the-loop-gate (evaluation)

Human review remained the final edge-case discovery layer even as many checks became automated.

“human can be kind of like the final gatekeeper to ensure that all the edge cases are covered”transcript, stated

synthetic-data-generation (data)

Coda used seed benchmarks and GenAI to multiply benchmark data over time.

“use the first set of a benchmark as like seed and you can use gen to kind of multiply your benchmark over time”transcript, stated

observability-tracing (operations)

Braintrust gave Coda timeline trends, aggregate scores, and drilldowns into individual failing benchmarks.

“you have the timeline where you can see kind of like observe how the the score goes”transcript, stated

Tradeoffs

Build versus buy for evaluation tooling

Chose Adopt Vellum and later Braintrust over Continue maintaining internal Coda-based playground/reporting tools.

Rationale: The lean team wanted to spend effort improving AI quality rather than maintaining tools and SQL reports.

“this is kind of like the the classic build versus buy problem um that we encountered which um with that led us to the first purchase of our AI vendor”transcript, stated

Evaluation location

Chose Automated evals close to application code over Prompt-only playground evals.

Rationale: App-integrated evals better reflect what users actually see after production code manipulates prompts and payloads.

“by keeping uh eval as close to our application as possible when eval runs you can know that you have confidence”transcript, stated

Human judgment in eval loops

Chose Humans as final edge-case gatekeepers over Fully automated scoring only.

Rationale: Humans catch failure modes no existing automated check anticipated, then turn observations into new checks.

“having uh human reviewing AI output can help you identify the ash cases they haven't thought of and you can turn those observations into automator checks”transcript, stated

Benchmark growth strategy

Chose Start small and expand with usage, feedback, and synthetic multiplication over Wait for a perfect comprehensive dataset before evaluating.

Rationale: Coda's dataset investment grew over time from a small baseline into thousands of data points.

“start early even if it's small n equals 10 is a great start and once you have established your Baseline you can iterate on your bench my data set as you go”transcript, stated

Gotchas (what bit them)

A provider model upgrade changed output behavior enough to break existing prompts.

Root cause: GPT-3.5 Turbo became more conversational than instructional, and model behavior changed outside Coda's control.

Resolution: Create systematic evals so model and prompt changes can be measured before release.

“all the prompts that we have written in the past no longer works the response are much more conversational rather than instructionals”transcript, stated
“as model upgrades the behavor can change outside of our control”transcript, stated

Prompt playground results diverged from production application behavior.

Root cause: The playground evaluated prompts in isolation while the actual app manipulated and combined prompts differently.

Resolution: Move evals closer to application code and run them like integration tests.

“we observe that oh actually what we evaluate the way we structure the prom is actually in the playground is actually very different from how our application code”transcript, stated
“keep your evoluation close to code”transcript, stated

Manual vibe checks consumed too much time as feature count grew.

Root cause: Vellum still required people to rate outputs by hand for many features and prompts.

Resolution: Automate checks where possible and use humans for novel edge cases.

“we have to actually go in and do Vibe checks uh by hand this is consuming it's as the number of feature grows it's doing consuming a lot of our time”transcript, stated

Eval datasets can miss real-world issues if they do not cover actual user cases.

Root cause: Automated checks and human review cannot compensate for poor benchmark coverage.

Resolution: Use PM/designer input, alpha/beta feedback, customer-facing teammates, and internal usage data to enrich benchmarks.

“if our Benchmark data set doesn't have a good cover on the actual realwork use cases it cannot help us to assess out issues for us”transcript, stated

Evaluation

Coda evaluates AI features with benchmark datasets, app-integrated automated evals, Braintrust timelines and drilldowns, human review for unexpected edge cases, and ongoing dataset curation from usage, product, customer, and synthetic sources.

Metrics: Binary score trends where 1 is good and 0 is failure · Aggregated evaluation-run scores · Individual benchmark pass/fail · Automated check count · Evaluation jobs per week · Benchmark dataset size

3 supporting quotes
“in case you don't know the one is like a good score zero is like a failure”transcript, stated
“when you run a job you can get a aggregated score at a high level to see how the job is doing”transcript, stated
“this Benchmark data actually contains zero Benchmark action items so this is a way for us to measure”transcript, stated

Outcomes

The talk describes roughly a year of evolution from one feature and manual checks to broad automated evaluation coverage.

3 supporting quotes
“we now have about 15 and more uh features supported we have five and more Engineers involved in AI in some Capac capacity”transcript, stated
“we have more than 50 automated checks so that the amount of mandate work that we do right now is uh relatively much less compared to before”transcript, stated
“when we first started we only have one feature with uh about 25 examples in a Koda data uh T table and now we have grown to more than 5,000 data points”transcript, stated