Skip to content

chore(templates): make the starter eval readable - #3426

Merged
kwakayama merged 1 commit into
mainfrom
chore/simplify-starter-eval
Aug 6, 2026
Merged

chore(templates): make the starter eval readable#3426
kwakayama merged 1 commit into
mainfrom
chore/simplify-starter-eval

Conversation

@kwakayama

@kwakayama kwakayama commented Aug 6, 2026

Copy link
Copy Markdown
Contributor

What

The ai-agent starter eval is the first eval most Veryfront users ever read. It opened with four hand-rolled lookaround regexes:

metrics.answer.regex({
  pattern: String.raw`(?<![-\d.\\])\\?\$33\.23(?!\d|\.\d)`,
}).gate(),

This replaces them with the rubric judge that was already in the file.

Why the regexes existed

They are exact, and exact for reasons earned the hard way:

  • Make starter money checks exact #3162 replaced contains({ text: "33.23" }) because it passed on 33.2366.
  • A follow-up commit added the \\? and the backslash in the lookbehind because Markdown-escaped output (\$15.21) let the engine restart at the dollar token and skip a preceding minus.

Both were real bugs. Neither is in dispute.

Why they still go

A starter file teaches by example. This one taught that asserting an agent said "$33.23" takes a negative lookbehind. A reader does not learn what the eval checks — they learn to copy a regex they cannot modify. That is the wrong first lesson.

The exactness requirement moves into the rubric, in prose:

"Every amount must be exact to the cent: $33.2366 and $133.23 are wrong."

Same constraint, stated so a reader can check it and change it.

The trade — please read before approving

#3162 carried an explicit directive: "Keep deterministic currency gates alongside the rubric judge; do not replace them with substring checks." This branch knowingly departs from it. Monetary correctness is now graded by a model, which means it costs an LLM call and can vary between runs.

What holds the line instead:

  • The gate threshold stays at 0.8.
  • calledTool("calculator") and noFailedTools() stay deterministic, so a run that skips the calculator or errors a tool still fails without involving the judge.
  • The rubric names the near-misses ($33.2366, $133.23) explicitly rather than leaving "exact" to interpretation.

This was a deliberate call by the requester after being shown the regression risk. If reviewers would rather keep deterministic money gates, the alternative I'd recommend is a first-class metrics.answer.containsAmount({ amount: "$33.23" }) in veryfront/eval — the boundary logic tested once in the SDK instead of copy-pasted into every user's project. Happy to switch to that.

Test changes

accepts sentence punctuation without accepting longer monetary values tested the four regex metrics directly and goes with them. In its place, grades the starter's money answer with a rubric a reader can follow guards both halves of the change:

  • The eval carries no metrics.answer.regex and no String.raw — the readability property.
  • The rubric still names all four amounts, still says "exact", and still shows the near-misses — because nothing else enforces exactness now.

The existing metrics.answer.contains( assertion stays, so the #3162 substring bug cannot come back either.

Verification

  • deno task fmt:check — pass
  • deno task lint — pass
  • deno task typecheck — pass
  • deno task generate:manifests:check — pass (manifest.json regenerated)
  • Template + eval suites: 23 files, 217 steps, 0 failed
  • Mutation-checked the new guard: dropping the exactness sentence from the rubric makes the test fail

Not tested: no live eval run against a real model. The judge's ability to actually reject $33.2366 is asserted in prose, not measured. That is the main thing a reviewer should push back on if they are uncomfortable.

Summary by CodeRabbit

  • Enhancements

    • Improved assistant evaluation guidance with clearer descriptions and run instructions.
    • Added explicit expected tip, total, and per-person split amounts.
    • Updated answer validation to assess exact monetary values and require a brief explanation.
    • Continued validating calculator usage and handling of tool errors.
  • Tests

    • Expanded coverage to verify rubric-based evaluation and reject incomplete or near-miss answers.

The ai-agent starter eval is the first eval most people ever read. It opened
with four hand-rolled lookaround regexes:

    metrics.answer.regex({
      pattern: String.raw`(?<![-\d.\\])\\?\$33\.23(?!\d|\.\d)`,
    }).gate(),

Those are exact, and they are exact for good reasons earned the hard way:
#3162 replaced `contains({ text: "33.23" })` because it passed on 33.2366, and
a follow-up commit added the `\\?` and the backslash in the lookbehind because
Markdown-escaped output let the engine restart at the dollar token and skip a
preceding minus.

But a starter file teaches by example, and this one taught that asserting an
agent said "$33.23" takes a negative lookbehind. Nobody reading it learns what
the eval checks; they learn to copy a regex they cannot modify.

The exactness requirement moves into the rubric judge, in prose:

    "Every amount must be exact to the cent: $33.2366 and $133.23 are wrong."

That is the same constraint, stated so a reader can check it and change it.

This is a deliberate trade. #3162's directive was to keep deterministic
currency gates alongside the rubric judge, and this branch does not: monetary
correctness is now graded by a model, so it costs an LLM call and can vary run
to run. The gate threshold stays at 0.8 and the tool gates
(`calledTool("calculator")`, `noFailedTools()`) stay deterministic, so a run
that skips the calculator or errors a tool still fails without the judge.

The regression worth guarding is the file drifting back toward unreadable, so
the template test asserts the eval carries no `metrics.answer.regex` and no
`String.raw`, and -- because nothing else enforces exactness now -- that the
rubric still names all four amounts, still says "exact", and still shows the
near-misses it has to reject.

Tested: template + eval suites (23 files, 217 steps); fmt; lint; typecheck;
manifest check. Mutation-checked the new guard by dropping the exactness
sentence from the rubric and confirming the test fails.

Not-tested: no live eval run against a model; the rubric judge's ability to
reject $33.2366 in practice is asserted in prose, not measured.
@kwakayama
kwakayama requested a review from kojiwakayama as a code owner August 6, 2026 11:16
@chatgpt-codex-connector

Copy link
Copy Markdown

Codex usage limits have been reached for code reviews. Please check with the admins of this repo to increase the limits by adding credits.
Repo admins can enable using credits for code reviews in their settings.

@coderabbitai

coderabbitai Bot commented Aug 6, 2026

Copy link
Copy Markdown

Review Change Stack

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: fe0e5c92-8f25-4a64-bdd3-e88ec43cc92d

📥 Commits

Reviewing files that changed from the base of the PR and between 0385c19 and 811a70e.

📒 Files selected for processing (3)
  • cli/templates/files/ai-agent/evals/assistant.eval.ts
  • cli/templates/index.test.ts
  • cli/templates/manifest.json

📝 Walkthrough

Walkthrough

The assistant eval now uses a rubric judge for exact tip, total, and per-person split values. Documentation and the manifest describe the expected results. Template tests verify rubric configuration and reject regex-based validation.

Changes

Assistant eval rubric migration

Layer / File(s) Summary
Rubric configuration
cli/templates/files/ai-agent/evals/assistant.eval.ts, cli/templates/manifest.json
The eval documents its question and expected monetary values. Four regex gates are replaced by one rubric judge. Calculator-use and failed-tool checks remain.
Template validation
cli/templates/index.test.ts
The test verifies rubric metrics, exact expected amounts, rejected near-miss values, and the absence of hand-written regex assertions.

Estimated code review effort: 3 (Moderate) | ~20 minutes

Possibly related PRs

Suggested reviewers: kojiwakayama

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title clearly describes the main change: improving readability of the starter eval template.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
✨ Finishing Touches
📝 Generate docstrings
  • Create stacked PR
  • Commit on current branch
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch chore/simplify-starter-eval

Comment @coderabbitai help to get the list of available commands.

@kwakayama
kwakayama added this pull request to the merge queue Aug 6, 2026
Merged via the queue into main with commit 0a6057c Aug 6, 2026
31 checks passed
@kwakayama
kwakayama deleted the chore/simplify-starter-eval branch August 6, 2026 12:35
@kwakayama kwakayama mentioned this pull request Aug 7, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant