DEV Community: Kris Raven

LLM as a judge

Kris Raven — Thu, 16 Jul 2026 06:32:07 +0000

Gone are the hours of careful thought and planning that go into coding a new feature. Vibe coding is too risky though, so another Driven Development was created. I'm referring to SDD (Spec Driven Development) of course. The vibe coding approach is great for prototypes and throwaway code, but this way of working falls apart when teams realise that the code needs to be maintained. So the thing that helps fix this is SDD.

Create a spec once from clear technical specs and then generate some high quality code. Sounds great, right. Reminds me of IaC, where you use a templating language to create infrastructure. Software as Code maybe. SaC anyone? Unfortunately, in practice it's not that straightforward. Thoughtworks have placed SDD into an "Assess" category and warned that it could be an anti-pattern for releasing software.

Deterministic vs Probabilistic

This article isn't about SDD. I'm more interested in discussing the output of SDD and how that is tested. Code can now be generated fast these days. So what better to test AI-written code than with AI itself. There are a lot of concepts and technical terms for the Quality Assurance part of AI generated code. One of these is the LLM-as-a-Judge idea. This idea is used to score the output of an LLM based on some explicit criteria. Traditionally, the way to evaluate an LLM was to judge its output on the helpfulness or faithfulness (using something called "exact-match" metrics). Sometimes it was usually down to a human to do this. It also changes the way that Quality is Assured when dealing with AI-written code.

Traditional QA is built on deterministic checks; either something does or does not fail. Something like expect(x).toContainText(y);. A failing test means that something is wrong. Then the bug can be fixed in the code and the test will pass. However, the outputs of an LLM are probabilistic, so it breaks the traditional pass/fail model. This is where a judge comes in. Instead of pass/fail, it can assign a score based on how good the output is. This changes the focus of the team too, as now the focus becomes reliability and consistency and a continuous evaluation of the code.

There's Gold in those Data Sets

Before I go into a few use cases and examples, I'd like to cover the term Golden Data Set and what it is. LLMs don't really have a good idea of what good looks like until you show it. There are different approaches to this which is where the Golden Data Set comes in. It is just a fancy way to say a versioned set of input/output test cases. The data set includes passes and fails, known issues, edge cases, and some of the tests have the expected outcomes and some do not. This data set can be taken from a working system whose outputs have already been tested and are known to be correct. These assertions can then be used in the first-pass testing of the AI-generated output. Then after each new version of the AI-generated code, we can compare the data sets and use those for testing the next version of the AI-generated code. Think of it like a growing versioned regression test suite. Importantly, the Golden Data Set needs to be curated by a human and it is best to use quality test cases rather than increase the quantity of test cases.

Use case: Regression testing in CI/CD

In this scenario there are 2 LLMs; one that generates the code and one that acts as The Judge. Every PR that touches a prompt, model or config is gated by an LLM Judge. The Judge can then be given rules to run on the output, as well as use the Golden Data Set as a reference to compare the results with. Instead of giving a score like 39/50 test cases passed, it will give a rating of confidence based on whatever was defined previously. Examples could be the quality, detail or even accuracy of the response. Usually, The Judge LLM would run at a temperature of 0 (0 meaning that there would be no creativity in the responses of the Judge). A threshold can be set that blocks the merge. The table below shows an example of what a CICD flow could look like, step-by-step.


1	Trigger	A PR changes a prompt, model version or config
2	Testing	Tests run against a golden dataset
3	Output	Generator produces outputs
4	Scoring	The Judge does this
5	Checking	Scores are compared to a previous run, not evaluated in isolation.
6	Deploy	If a metric we care about regresses, the pipeline blocks merge/deploy
7	Logging	Store logs (timestamp, dataset version, judge model snapshot and judge prompt)

Use case: Evaluating BDD tests

There is a paper called "LLM-as-a-Judge for Scalable Test Coverage Evaluation: Accuracy, Operational Reliability, and Cost" which as the title suggests was a study into LLM-judge framework scoring and a discussion of the idea of "execution-based vs. judgment-based testing". I'll leave a link at the bottom of the page.

100 Jira tickets were selected to simulate a realistic software development life cycle. Then using an LLM, Given-When-Then style BDD tests were generated for each of them. These tests were then reviewed by 3 senior QA Engineers experienced with the product that the test cases targeted.

The Judges, a selection of LLMs with different weightings and reasoning efforts (for example GPT-4, GPT-4o Mini and GPT-5), were tasked with "understanding" the tests. Each Judge received the text of the Jira ticket, the BDD test cases and a few guidelines on what different technical details meant (such as HTTP-methods). They could then assess whether the executed BDD tests address the specified requirements and output a coverage percentage and a written rationale about their scoring.

Use case: Chatbot/agent functional testing

There is a team somewhere building an AI powered chatbot that offers a voice feature. The team are running single-turn eval tests, but customers are complaining the bot is going in circles and forgetting what the user has just said. The problem is that the team aren't using a good testing strategy. The single-turn eval tests are almost like individual unit tests. Just relying on unit tests to deliver quality software isn't a good approach. It's like grading a movie by looking at random frames instead of watching the film.

Below is a list of the important evaluation steps. As you can see, there's a lot of things to evaluate, so this is where the LLM-as-a-Judge can be used instead of manually checking.

Task Completion
- If the task didn't get done, nothing else matters.
Tool call accuracy
- Was the right tool called with the right arguments?
Workflow completion
- Did it follow the intended multi-step sequence with proper data flow between tool calls?
Grounding
- Were the tools called actually used in the response or was the response invented?
Stay in character
- Does it maintain its role the whole way through the conversation? For example a support agent staying empathetic, a sales bot not discussing competitors.
Autonomy
- Was workflow completed without needing the user to guide it?
Knowledge retention
- Does the bot remember what the user already told it?
Follow-up quality
- Did it ask for missing information before going ahead, rather than guessing?
Conversation relevancy
- Does each reply actually track the live thread of the conversation rather than drifting?

Security

Something that I haven't included in the list above is the testing of security in the response. This is because it should actually be a separate activity. There are 3 ways of testing evals:

correctness which includes the golden dataset and The Judge
adversarial/security which includes red teaming, Attack Success Rate tracking (a Red Team activity) and guardrail testing
operational which includes canary deployments and observability

The Judge is itself an LLM, so it inherits LLM vulnerabilities. Testing the adversarial-robustness of The Judge itself is also important through things like fake reasoning, prompt injection, adversarial phrasing and jailbreak-style manipulation. This is more down the path of Red Teaming activity which is getting off topic for this article.

As a QA I hate the sound of probabilistic testing

At this point, you may be thinking "So you're saying that instead of minimising bugs, we're moving to the idea that we're probably going to find a few? That doesn't sound like a good way to do QA". And yeah, good point. With AI now in the loop of generating code it means that QA roles will change. Just as scripting made coming up with test scenarios and creating test data easier, and automated tests made running a suite of tests easier and deployments faster, LLMs become part of a test design approach.

Teams need to use different strategies to test AI-generated code. The fast, deterministic checks where "pass" is unambiguous are always going to be valuable, so they should be kept. These should be layered with a continuous cycle of evaluation. This means that teams should create Golden Data Sets and maintain them, as these collections will drift. The dataset evolves quickly as failures are discovered. Every time a new failure is discovered it should get added as a new case. This is the same philosophy as the pre-AI-coding way of managing suites of tests. The LLM-as-a-Judge model of testing introduces a different way of thinking about testing too. Every time The Judge prompt itself changes, old scores against the dataset aren't directly comparable anymore. In fact, whenever something changes, like the model's settings or preferences or even the model itself, then we need to set a new base-line for The Judge and the data sets.

Something I haven't covered explicitly is that this process has a sometimes mandatory requirement for a human to be in the loop, especially if the code is for an application (like in sensitive, highly regulated environments). Any failures in scores or drops in confidence need a human to investigate further. And that's a general theme in QA that always comes up; if software is being built for humans then a human needs to be in the loop at some point.

References

LLM-Judge Scoring: https://arxiv.org/abs/2512.01232

AI is reducing quality

Kris Raven — Sun, 12 Jul 2026 11:35:30 +0000

Once upon a time in 2018 I posted a few of my written articles to Reddit and got some replies where I was accused of "posting low quality responses with low quality articles." A general theme in the comments was that the articles weren't thought out and my articles "lacked an ending".

Each to their own, I thought to myself. In hindsight though, I think they have had a point. A bit of my writing was sloppy and hastily written with typos. Plus the way I replied to posts with a link to my website saying "I recently wrote about this here..." is annoying. Imagine if someone did this in real life, and instead of answering a question would just answer with self-promotion instead. Anyway, all of this is to say that I'm experienced with bad writing.

Everything is slop

Before I begin, a quick refresher on what AI slop is. It's low-quality, low-effort mass-produced content generated by AI. There's no human curation or refinement. In software engineering, it is commonly used to describe the subpar code that LLMs produce. But it can also be images, text or video.

AI-generated slop writing is everywhere. Since AI-aided writing became a thing, there were trademark LLM-isms in the writing, such as the obvious em dash (—). This was annoying and made AI-aided writing obvious. But it wasn't everywhere. Then a friend introduced me to tropes.md, a markdown file that attempts to make AI writing more human-like. But instead of being a helpful resource, it ruined the Internet even more for me. The Internet's decline is progressing the same way a middle-aged man loses his hair. Little bits fall out and you think "there's no coming back from that. Soon I'll be bald". By the way, probably not a hot take but in my opinion the downfall of the Internet began around 2010.

The tropes.md document goes through the current LLM-isms. And now I can't read an article without spotting a "genuinely", em dash, "quietly", always adding , before an "and" (commonly called the Oxford Comma) or some over-dramatic rambling and phrasing, or repeating what was just said using different words split up into two short sentences. For example "The invention of the motorcar quietly changed the tapestry of the game for good. It's no longer about driving — it's about freedom. Now people drive. All the time. This wasn't just a motorcar, it was a lifestyle choice."

And now I either can't unsee it, or it has become way more prevalent. It's even obvious in some YouTube videos. The creator has quite obviously got AI to generate the script for them and then they read it out. I won't call them out by name about how nauseating their AI-created scripts are, but it's safe to say that I've noticed some popular creators doing it.

LinkedIn is one of the worst places for it, where people that should have known better will post AI-generated content. It's enough to make me physically wince. AI-generated images are everywhere too. The same colour schemes and similar layouts. Then these people have the gall to watermark the image with their username as if they have taken hours of effort and thinking to generate the post. If someone does have English as a second language then I could be more lenient on them. But then again, they could also be more thoughtful of other people and not post their AI slop. There are people that I have followed for a while and seen their pre-AI posts. I know that they can string perfectly good sentences together. However, now they are using AI to help them with their writing, as though AI-assistants are going to leave soon so they need to get as much use out of them as possible. This is also something that bothers me. Why did they even let AI help them write, when they were an even better writer before AI?

The implication of a collection of LLM-isms (i.e. all the trademark tells of AI slop) is that people will think that the writer couldn't be bothered creating the content. There was no love involved in creating the output. So why should anyone show any love for reading or hearing it.

Hollow praise and platitudes

On top of the AI-slop posts, there is a tendency for LLMs to come across as "sycophantic". You've probably noticed this in the responses when using an LLM. They are generally too friendly. For me, this became obvious when moving over from ChatGPT 3.5 to one of Anthropic's earlier models. I noticed that the Anthropic model was much more friendly and gave out praise when it wasn't needed. It was overly positive about everything. Great idea! or Excellent question or the way it would soften criticism, like using the Compliment Sandwich style of feedback. Models also have a tendency to make things up.

All of this is largely a byproduct of how models are trained. When there is human feedback in reinforcement learning (called RLHF), humans tend to give higher ratings to responses that affirm their beliefs, or responses that sound confident or validate their opinion. And then the reinforcement learning the model does will optimise for responses that are rated highly by humans. So the model learns that agreeable responses correlate with what a good response is. This leads to things like the response sounding confident even if it may not be the truth.

It should be noted here that not all models face this issue. It only seems to be ones trained with human feedback (commonly referred to as RLHF-trained models).

There have been some interesting studies on this too. In one case, it was found that as a model gets larger/is tuned more with RLHF, it will become more sycophantic since the model is better at detecting what response the user wants to hear.

Everything is slop

As I mentioned earlier, this way of using an LLM as a helper for writing is something that is starting to affect all writing. Anyone that has easy access to AI tools can enhance their writing and, as we're dealing with humans that usually just want to get their message out as fast as they can with minimal effort, they turn to AI to help them. As a writer and a connoisseur of quality, this is painful and embarrassing to watch.

AI Productivity and the Dark Side of Efficiency

Kris Raven — Sun, 12 Jul 2026 11:29:13 +0000

Go on, use AI, you'll have more time to focus on other things. AI tools were supposed to make our jobs less stressful. But somewhere between the endless prompts, the instant outputs, and the expectation that you can now do the work of five people, something has broken. In February 2026 an article was published in the Harvard Business Review about a paradox happening in AI. Something that every developer working with AI has experienced. Most of the time they push through with some moans and grumbles to their teammates. Before you roll your eyes and sigh "oh not another data centre/AI-companies-are-evil/save-the-environment/LLMS-are-just-really-fancy-autocorrect article"; the HBR article was called AI Doesn't Reduce Work - It Intensifies It.

The article discusses research findings from a study. Over 8 months the study followed the experiences of 200 workers in 1 tech company as they used Generative AI tools. Not gigantic numbers but don't let that stop you reading more.

The study identified ways in which the employees' work intensified.

1) Scope creep

Gen AI was so helpful that workers began taking on duties outside of their usual roles. PMs started coding, researchers handled development work. This had knock-on effects, such as engineers suddenly having an extra workload because everyone and their uncle thought they could vibe-code some Production-level software.

People that shouldn't be creating production-grade code can now do that. This issue isn't hard to fix. In fact, the study gave some recommendations. I'll go through them at the end of the article.

In my personal experience using Gen AI tools for coding; they can fix bugs, write documentation, follow a structure, write some crazy Automated Tests (playwright-cli, anyone), write and push commits. But I've never been able to let a Gen AI tool run amok in some code. There have always been things I've had to jump in and fix manually. Even a simple bash script can become bloated and tangled without a well structured prompt.

2) Work-Life Balance

Anyone who has used Generative AI tools for knowledge work knows how it can suck you in. The early part of the task is usually pretty effortless and so you make good progress. You tell people about how you're making good progress. You vibe-code a demo app which goes down well. It encourages you to squeeze more and more in and this eats into lunch breaks or after-hours work. Then a few more prototypes into the task you discover a huge list of potential blockers and there is the realisation that you've bitten off more than you can chew. And then your project gets fast-tracked with some tight deadlines. And then you have the other problem of needing to support a feature that no customer asked for but it's destined for Production anyway.

3) More Tasks, More Problems

Employees were given more tasks because the assumption from management was that "AI is helping, so of course you can do more things". The study found that employees ran several processes at once; they were manually coding, as well as using AI-generated solutions and keeping multiple tasks active in parallel. There was improved progress using Gen AI, yet for the person doing the work it meant more time switching focus and increasing their cognitive load.

Another study by the London School of Economics found that companies viewed using AI as a way to have a 7.5 hour "productivity gain", basically saving one work day per week. It was assumed that employees would work fewer hours, but what actually seems to be happening is that they are expected to do more with the time they saved.

4) Mental autopilot

At the start of a project, there are lots of little tasks that need to be done. These tasks are great for 2 reasons. One; you don't have to think too much about them. Two; it gives your subconscious brain time to analyse the tasks some more and think of other approaches and solutions. Using Gen AI tools straight away reduces this initial thinking period. People would jump straight into a task. In the study it made people feel more reliant on AI to deliver. It sped up the tasks, and increased expectations whilst also reducing their thinking power.

The "2 commits and a README" phenomenon

Some might say that this all sounds like "a you" problem. It sort of is and sort of isn't. With a lot of experience, coding using a Generative AI tool has a learning curve. For most software engineers that are not extremely experienced developers, it's an inverted curve. They hit a scalability wall. They want to do more. They know how to do more. But the "2 commits and a README" phenomenon is real. Github is a graveyard of abandoned side projects. Developers can just now create and abandon them at a quicker rate. They can do more, think less. Burnout quicker.

Software Engineering is full of tongue-in-cheek, catchy proverbs which seem like a joke but are also actually true

Anything that can be written in Javascript will eventually be written in Javascript,
the two hardest things in computer science are cache invalidation, naming things and off by one errors,
the Scream Test,
Rubber Duck Programming,
Works On My Machine,
and this awesome rule called the 90/90 Rule, still as relevant today as when it was first uttered back in 1985 by a Bell Labs employee Tom Cargill. The quote is below.

90/90 Rule: The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.

A solution

By eliminating creative blocks and making it easier to start tasks, these tools remove natural pauses in the workday. These tools also made people feel like they have a companion. But that seems to add a false sense of security. It could lead to a wave of "AI Burnout" and lower quality of work.

Gen AI tools make it easier to do more. People being people, they will usually choose to do something more if the barrier to entry is low. It's why people get baited by the seductive charms of AWS. It reminds me of this meme (image below) about gambling vs vibe coding. Most memes are rooted in truth, and are pithy takes on the real-world. Addictive, flashy, the "feeling" of progress but the confusion of "what did I do in the last 3 hours". No, not doom scrolling or playing slot machines. You were vibe coding.

Anyway, back to the solution. The AI Doesn't Reduce Work - It Intensifies It article ended with some pretty under-whelming, obvious solutions.

Organisations and managers need to understand that using Generative AI tools can lead to work informally expanding. Telling employees to take care of their mental health while using Generative AI for their work is not the solution. Instead of it reshaping an organisation, they need to actively shape how they use AI. They need to build in an intentional way that AI is used, in the article, this is called "AI Practice". Which is a fancy way of saying that there needs to be some standards set by the organisation on how they sustainably use Gen AI tools. This means things like adding intentional, structured pauses. Moments of downtime to prevent overload accumulation. They also recommend something called "sequencing" which aims to protect focus windows and reduce cognitive load.

My take on this is that many software development professionals will already recognise signs of burnout in themselves. They will realise that they are being pushed unsustainably to do more in less time. They will know they're working longer unproductive hours. They are smart enough to take action, somehow. But some of the less experienced software developers won't know that, they might not even realise that burnout is a thing. And that's concerning. This means that it's up to organisations and managers to set the guardrails for how these tools can be used in a healthy, sustainable way.

And I've not even mentioned "data centres/AI-companies-are-evil/save-the-environment/LLMS-are-just-really-fancy-autocorrect" yet.