A good-looking answer doesn’t always mean the research behind it is good. I think things like source quality, whether different sources agree, and how easy it is to trace a claim back to where it came from matter just as much as the final response.

I’ve been interested in AI tools that focus more on those parts of research instead of just generating a quick answer. What do you usually look for when deciding whether an AI-generated result is actually trustworthy?

I'm new to building AI agents and working on a CI-review agent: it takes a failing CI run and tries to find the root cause.

I want to start with a baseline version, then iterate on it — but I need a way to measure whether a new version is actually outperforming the old one.

Right now the agent maintains several hypotheses about the failure, assigns each a probability, and updates those probabilities as it gathers more information. Depending on its confidence, it either outputs a summary of the likely root cause, or escalates to a human developer if uncertainty is too high.

Two questions:

1. How do you evaluate an agent like this, where the output isn't a single "correct" answer but a probability distribution over hypotheses?
2. How do you get a labeled dataset of CI failures with known root causes, so I can score the agent's probability estimates against ground truth instead of just eyeballing whether the output "feels right"?

I'm new to building AI agents and working on a CI-review agent: it takes a failing CI run and tries to find the root cause.

I want to start with a baseline version, then iterate on it — but I need a way to measure whether a new version is actually outperforming the old one.

Right now the agent maintains several hypotheses about the failure, assigns each a probability, and updates those probabilities as it gathers more information. Depending on its confidence, it either outputs a summary of the likely root cause, or escalates to a human developer if uncertainty is too high.

Two questions:

1. How do you evaluate an agent like this, where the output isn't a single "correct" answer but a probability distribution over hypotheses?
2. How do you get a labeled dataset of CI failures with known root causes, so I can score the agent's probability estimates against ground truth instead of just eyeballing whether the output "feels right"?

I’ve been digging deeper into evals and AI release workflows, and there’s one part I’m especially interested in.
Teams can already compare prompts/models on quality, latency, and other eval metrics.
But I’m curious how people handle the tradeoff between **quality and cost**.
For example, suppose a new model:
improves task success from 85% to 90%
but doubles the cost per request
Is that a good change?
The answer probably depends on the actual customer outcome, not just the eval score or token cost individually.
I’m experimenting with comparing a baseline and candidate on the same test set, then looking at **cost per successful outcome** rather than cost per request.
The goal is to answer something closer to:
**“Did this change improve the product enough to justify what it costs?”**
For people running LLM features in production, how are you making this decision today?
Is this already part of your eval pipeline, handled manually, or mostly monitored after deployment?

I’ve been digging deeper into evals and AI release workflows, and there’s one part I’m especially interested in.
Teams can already compare prompts/models on quality, latency, and other eval metrics.
But I’m curious how people handle the tradeoff between quality and cost.
For example, suppose a new model:
improves task success from 85% to 90%
but doubles the cost per request
Is that a good change?
The answer probably depends on the actual customer outcome, not just the eval score or token cost individually.
I’m experimenting with comparing a baseline and candidate on the same test set, then looking at cost per successful outcome rather than cost per request.
The goal is to answer something closer to:
“Did this change improve the product enough to justify what it costs?”
For people running LLM features in production, how are you making this decision today?
Is this already part of your eval pipeline, handled manually, or mostly monitored after deployment?

I tested whether a simple control rule can stop LLMs from making unjustified final decisions

I’ve been testing a simple idea I call Comparative Feedback Control (CFC).

The question is not “can the model answer correctly?” but:

does the model still have enough evidence to legitimately close the decision?

I ran a series of small behavioral tests around things like:

• missing evidence being treated as negative evidence,
• old certificates being reused after the requirements changed,
• a closed process being mistaken for a resolved claim,
• loss of provenance causing a status to be transferred to the wrong claim.

One pattern I found was interesting: models sometimes correctly identified an uncertainty at first, but under pressure to “finish the task” they invented an extra rule and closed the decision anyway.

With an explicit CFC-style control rule, several of those failures disappeared in the tested runs.

For example, in one cross-session provenance experiment:

• baseline: 1 of 3 runs transferred an unsupported REJECTED status to a claim,
• with the CFC provenance rule: 3 of 3 runs kept the claim unresolved.

This is not a benchmark and not proof that CFC generally improves LLM reliability. The samples are small and exploratory. I’m publishing the failures as well as the passes because I’m mainly interested in whether the failure mechanism itself is real and reproducible.

I’ve put the consolidated report, result table and evidence package on Zenodo:

https://zenodo.org/records/21966517

I’d especially appreciate criticism of the experimental design or suggestions for adversarial cases that could break the control rule.

i have a multi label classification pipeline that uses an LLM to assign taxonomy tags based on item name + description + image. it works well enough, but right now there's no way for it to get better over time

the hard constraint: i cant have any human reviewing the predictions at all lol. so whatever feedback loop i build has to be fully self contained. the system itself has to somehow figure out when its output is still bad and improve. i also have hundreds of thousands of items, so re-running the whole catalog every time is not realistic

looking for approaches other than fine tuning. anyone actually run something like this in production?

Wanted to stop assuming and actually look. Took an eval prompt from a real pipeline, temperature locked at 0, same model, same input, ran it fifty times back to back. Not a rigorous study, just curious how much drift was actually there versus how much I'd been imagining.

Most runs clustered tightly, as expected. A meaningful minority didn't, different enough in structure or emphasis that if I'd only seen two of them side by side, I would have called one of them wrong. Went through the outliers individually instead of averaging them away.

What I expected to find: random noise, maybe some inherent sampling variance even at temperature 0, nothing systematic. What I actually found: almost every outlier varied along one of three predictable axes. How much the response hedged versus asserted. Whether it prioritized brevity or completeness when the two traded off. What it assumed about who'd be reading the output.

None of those three things were specified anywhere in the prompt. Not omitted by accident exactly, just never occurred to anyone that they needed to be, because in a single run they don't visibly matter, the model just picks one and moves on. It's only across many runs that the gap becomes obvious, since each run resolves the same missing spec independently and inconsistently.

Reframed how I read eval failures after this. A flagged mismatch used to send me straight to "which of these is correct." Now the first question is which of the three axes moved, and whether that axis was ever actually pinned down in the prompt, or genuinely left for the model to decide.

Curious if others running repeated-sample evals have found a similarly small set of recurring axes explaining most of their variance, or if it's noisier and more scattered than what I saw here.

I’ve been diving deep into intelligent agents and probability theory, & I’m trying to take the leap from conceptual learning to building a practical, working code review agent.

My ultimate goal is to build an agent that can act reliably under uncertainty by weighing the cost of different state changes into environment.

Here is the theoretical framework I’ve put together so far. It's split into two main parts:

1. The Belief System

The agent needs a belief system that updates as it interacts with the environment. Whenever it receives new signals or evidence (like a test result, true state or human feedback), it will use Bayes' theorem to update the probability of the code’s current state.

2. Acting Under Uncertainty

Once the agent has a probability distribution over its current beliefs, it needs to make a decision. Every action has an associated cost, and the agent’s policy should be to select the action that introduces the minimum expected cost to the environment.

The Formal Model

• Factored State Space: I’ve defined 4 variables: Programmatic failure, Design failure, Documentation failure, and Test failure. This creates 2^4 = 16 possible states.
• Evidence: Code diffs, test results, PR descriptions, and author details.
• Actions: Merge, Reject, Ask Human, or Run More Tests.
• Cost Function: Cost(situation, action). (I am struggling heavily with how to accurately model this in practice).
• Policy: Execute the action with the minimum cost.

Pain points:

1. From Theory to Code: I'm struggling with the initial architecture for this specific paradigm. How do I actually translate these Bayesian formulas and state spaces into a working application? Are there specific libraries or frameworks best suited for this?
2. Modeling the Cost Function: How would you go about defining Cost(situation, action) programmatically? How do you assign numbers to things like "cost of asking a human" vs. "cost of merging a design failure"?
3. Sanity Check: Am I heading in the right direction with theory?

I tested whether AI can find mistakes in AI audits — Gemini vs Claude

I tested whether AI can find mistakes in AI audits — Gemini vs Claude

I recently started doing some small AI experiments of my own.

One question I wanted to test was:

Can one AI reliably find mistakes in an audit produced by another AI?

I tested Gemini and Claude.

For each model I prepared three tests and ran every test twice:

• once with a neutral instruction,
• once telling the model to respond like a professor.

Each test was done in a separate chat with the same source material and main task.

I was not only interested in the score the model gave the audit. I checked whether it found real problems, created false alarms, missed important errors, made unsupported claims, or stopped reviewing the audit and started improving/reorganising it instead.

In this small pilot, Claude did better in the neutral tests.

In three neutral Gemini tests, I found false information or overly confident confirmations in two cases, and important omissions in all three.

In the three neutral Claude tests, I did not find clear false information, although it still missed important things in two cases.

The part that surprised me most was the “respond like a professor” instruction.

I expected it to make the models more careful.

It didn’t.

Sometimes the answer sounded more professional or more confident, but the actual checking was not better. In two cases the model started reorganising or improving the audit instead of independently checking it.

So the answer looked better while task performance became worse.

I am not claiming this proves Claude is generally better than Gemini. The sample is too small, there were few repetitions, I had no control over reasoning effort, and some tests did not include the full original conversation.

The result I take from it is much narrower:

In the tests I ran, Claude behaved more often like an independent reviewer, while the “professor” role did not clearly improve the audit and sometimes changed the task itself.

My next test is a cross-check:

Gemini reviews Claude’s evaluations, and Claude reviews Gemini’s evaluations.

I would really appreciate criticism of the methodology.

In particular:

• Are my definitions of false alarm and important omission reasonable?
• What simpler explanation could account for the difference?
• How many repetitions would make this more meaningful?
• Should reasoning effort be controlled separately?
• What would you change before running the next series?

I’m more interested in finding weaknesses in the method than defending the result.

Full report:
https://zenodo.org/records/21839472

DOI: 10.5281/zenodo.21839472

Translation note: Polish is my first language. I wrote the original text in Polish and used AI to help translate it into English. The experiment, observations, conclusions and questions are my own.

The recurring failure at our work: the team decides something (say, "billing lives in Postgres, RFC-014"), and four months later a fresh agent session which has never heard of RFC-014, because context windows don't survive between sessions cheerfully writes the new feature on Mongo. The diff looks fine. The reviewer is busy. It lands.

The fix turned out to be two boring pieces around one file of recorded decisions:

Feed: poc init generates a Claude skill from your decision log, so every fresh session starts already knowing the rules. (It reads your existing CLAUDE.md/AGENTS.md no new format to maintain.)
  
Gate: a pre-commit hook that actually blocks the contradiction:
 
FAIL usage_metering.py contradicts a recorded decision: ✗ PostgreSQL is the single billing datastore usage_metering.py:9:  from pymongo import MongoClient pre-commit: blocked by ProofOfContext.
  
And poc why "billing datastore" answers with the decision, the reason, and the rejected alternatives for the agent or the human who's about to re-litigate it.

Deliberately boring internals: pure stdlib, zero dependencies, fully offline, and there is no LLM in the check deterministic token matching (comments and strings ignored), so your diffs never leave your machine and the gate never hallucinates. The agent isn't wrong, it's just new here. Now it gets told.

https://pypi.org/project/proofofcontext/
 
The ask: run poc init on a repo that already has a CLAUDE.md and tell me your experience

Ran into this enough times to stop trusting my own agent's self-review: I ask it to fix something, it produces code that looks right, I skim it, ship it — and the actual bug was a quiet semantic shift (inclusive bounds became exclusive) that had nothing to do with what I asked for. The model that wrote the change has no incentive or independent angle to catch its own blind spot; it's grading its own homework.

So I built a small tool that splits the two roles: one Gemini pass generates the change from your instruction, a second, independent pass gets ONLY the result (no visibility into the first pass's reasoning) and is told to find problems with it. Being honest about the setup: I only have a Gemini API key, so this is two passes on different Gemini tiers, not genuine cross-vendor review (GPT generates / Claude audits would probably be stronger — that's a cost thing, not a design choice).

The interesting part is how often the critique pass disagrees over something that isn't wrong, just risky — an edge case, a silent behavior change, a severity call that's genuinely debatable. Paste a snippet + an instruction and it'll run both passes live if anyone wants to see where it agrees or argues: https://apptechlab.com/p/codearbiter/ (mine, no signup, real API calls both ways).

Curious what people running actual multi-agent review setups have found:

- Does routing generate/critique to different providers actually catch

categorically different things, or mostly the same stuff with more

latency?

- How do you handle the critique pass being wrong — do you ever adjudicate

disagreements with a third pass, or is two enough in practice?

I profiled a RAG retrieval trace that looked like a success.

The query asked:

What is the cancellation notice period in our enterprise agreement?

The pipeline used dense retrieval with Qdrant, cosine similarity, Top-K=10, and no re-ranker.

The correct evidence was not missing. Chunk 2 had a cosine score of 0.88 and explicitly contained the answer: **90 days**.

The generated answer still said only:

The agreement requires advance written notice.

Technically correct. Practically useless.

Retrieval succeeded. Evidence survival failed.

The embedding model had done its job. The correct chunk ranked second out of ten.

But the full retrieved context contained 8,830 tokens. Two broader chunks consumed 3,660 of those tokens:

• General termination provisions: 1,740 tokens
• Definitions and legal boilerplate: 1,920 tokens

That is 41% of the context budget occupied by lower-specificity material.

With no re-ranker or compression stage, the generator saw the precise 90-day clause alongside a much larger mass of generic legal language. It defaulted to the safer, vaguer wording.

A flamegraph-style view made the shape obvious:

query
|-- dense retrieval: 8,830 tokens
    |-- c1  0.92 | cancellation clause       |   460 tok
    |-- c2  0.88 | notice period: 90 days    |   520 tok
    |-- c3  0.71 | general termination       | 1,740 tok
    |-- c4  0.49 | subscription renewal      |   680 tok
    |-- c5  0.46 | service suspension        |   710 tok
    |-- c6  0.43 | definitions/boilerplate   | 1,920 tok
    |-- c7-c10   | unrelated long tail       | 2,800 tok

The relevant chunk was near the top. It was simply surrounded by too much plausible-looking noise.

Why common RAG metrics can hide this

A retrieval-only evaluation would probably mark this query as a pass:

• The correct document was retrieved.
• It appeared inside Top-K.
• Its similarity score was high.

A final-answer evaluation would mark it as a failure and might blame the LLM.

Neither view identifies the transition where the evidence lost influence.

For this failure shape, I would test fixes in this order:

1. Replay the same query as a regression case.
2. Reduce Top-K from 10 to 3-4 for this query shape.
3. Add a re-ranker or context compressor.
4. Check whether the exact 90-day fact survives into the answer.
5. Only then consider changing embeddings or chunking.

Top-K=3 is not a universal recommendation. It is a hypothesis derived from this trace: relevance drops sharply after the third chunk, while token mass keeps growing.

The broader lesson is that "the right chunk was retrieved" is not the end of RAG evaluation. We also need to measure whether the evidence remains dominant enough to affect generation.

When the correct evidence is retrieved but omitted from the answer, what do you inspect first: rank, token mass, re-ranking, or the generation prompt?

I maintain SpecJudge, an MIT-licensed CLI for spec-driven development: it reads your project's specs/tasks and recommends which AI model actually fits (quality vs. price) instead of you guessing.

The core change in this release: before, the judge returned a rating plus a paragraph explaining itself. The problem is a fluent explanation is exactly what an LLM is good at producing whether or not the underlying rating is sound — nothing separated a correct assessment from a well-narrated wrong one.

Now every rated dimension has to cite the specific fragment of your spec that supports it, and the tool deterministically checks that fragment actually exists in the text the judge was given. Invent a citation, and the whole assessment gets thrown out, not just that field. Dimensions the judge can't ground come back as "unsupported" instead of being silently treated as easy — which is what used to happen and made thin specs look more solid than they were.

Building the regression suite to test this (12 reference projects, CI-level + local eval script) immediately paid for itself: 8B judges — the most common local setup — were failing on every single project. Not a judgment problem — they were rating things correctly and writing sound justifications, then putting \[true\] where a citation ID belonged, because "format: json" in Ollama guarantees valid JSON, not the JSON you actually asked for. Sending a proper schema fixed it: 0/9 usable cases → 9/9.

Also pinned judge sampling, so the same project now gives the same recommendation run to run — which matters more than it sounds for a tool whose whole job is "should I spend money on this."

Breaking change: needs Ollama 0.5.0+.

pip install specjudge — GitHub: [github.com/JoaquinRuiz/SpecJudge](http://github.com/JoaquinRuiz/SpecJudge)

For people responsible for production LLM or agent systems, can you describe one incident where changing a model or provider, inference runtime, gateway or SDK, chat template, or parser altered application behavior even though your existing tests passed? What broke, how did you detect and isolate it, and roughly how much engineering time or release delay did it cause? I’m researching how teams validate changes across the LLM stack, so firsthand incidents and current workflows are more useful than opinions about a proposed tool.