<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/"><channel><title>Testing on A naive bidder</title><link>https://anaivebidder.com/tags/testing/</link><description>Recent content in Testing on A naive bidder</description><language>en-us</language><lastBuildDate>Mon, 26 Oct 2026 12:05:13 +0100</lastBuildDate><atom:link href="https://anaivebidder.com/tags/testing/index.xml" rel="self" type="application/rss+xml"/><item><title>How to Build your Own LLM Benchmark</title><link>https://anaivebidder.com/posts/build-your-own-llm-benchmark/</link><pubDate>Mon, 26 Oct 2026 12:05:13 +0100</pubDate><dc:creator>Ruben Afonso</dc:creator><guid>https://anaivebidder.com/posts/build-your-own-llm-benchmark/</guid><description>&lt;p&gt;Every LLM launch comes with the same slide: a wall of benchmark scores, each a point or two above last month&amp;rsquo;s. Those numbers matter, but they measure someone else&amp;rsquo;s problem, and they make you pay for capabilities you probably don&amp;rsquo;t need.&lt;/p&gt;
&lt;p&gt;You write your code, you own the unit tests. You leverage an LLM, you should own the benchmark too.&lt;/p&gt;
&lt;p&gt;Writing the first cases is easy. The hard part is structuring them so the benchmark keeps evolving as cases pile up, new models ship every month and someone asks why a model failed a case. This post covers building your own benchmark and the harness that runs it.&lt;/p&gt;</description></item></channel></rss>