Quick context if you're new here: I'm Sandeep, a Technical Lead on backend systems, with hands-on AI work at integration and proof-of-concept level. This newsletter looks at what AI gets wrong in software architecture, and what good systems look like.

A word that covers several jobs lets a team skip deciding which job it needs done. "Eval" blurs a judge that agrees with itself and one that is right. "Guardrail" blurs detecting and deciding, and the five words in the third article get used as if they were one. The question I take from all three: which job does this piece of the system do? The first two add another: can the model influence the thing that checks it?

In this issue:

→ Your LLM Judge Agrees With Itself. That Is Not an Eval. (article)
→ Your Guardrail Can Detect an Attack. It Cannot Authorize a Refund. (article)
→ Agent vs. Skill vs. Prompt vs. Hook vs. MCP (article)
→ One idea from Atomic Habits (book)

An LLM judge can give the same verdict every run and still be wrong. In a June 2026 preprint (so the figures are provisional), Qwen 3 8B reproduced its own scores almost perfectly while showing a position bias of about 19 percentage points. Rerunning a judge is cheap, which is why consistency is the number teams see. Which judge you pick is the small decision. The larger one is where human labels enter the loop, and I group the published guidance into four entry points. When the judge is no stronger than the model it scores, one ICLR 2025 result caps how many human labels it can save; the breakdown has the cap and when a judge alone is enough.

Takeaway: Choose the judge last. First decide who defines the criteria, who labels the validation set, who pays for the correction sample, and what triggers a re-check when the model changes.

Read the full breakdown →

"Guardrail" covers two jobs. Detectors (Prompt Shields, Llama Guard, an LLM judge) estimate how likely something is to be bad, and they are wrong some of the time. Controls (an authorization check, a schema, a spending limit, an approval gate) decide whether an action is allowed, and the same input gets the same answer every time. The test that sorts any guardrail: can the model's output influence the decision? If it can, it is a detector.

Takeaway: Buy the detector, own the decision.

Read the full breakdown →

Five words that sound like synonyms and sit at five layers. A prompt is what you want right now, and an agent is who carries it out. MCP is how the work reaches outside. A Skill is what doing it well looks like, and a hook is what must happen whatever else does.

Takeaway: Name the gap before you build anything: is it reach (MCP) or judgment (a Skill)? Pick the wrong one and you get the wrong thing, built competently.

Read the full breakdown →

Clear's argument is that results follow from the system you run, not the goal you set.

It matches the guardrail article. That article's example is "never issue refunds over $100" written into a system prompt: a request, which a model can be talked out of. In Clear's terms it is a stated goal. A check in code the model cannot reach is the system that makes the goal hold. The way I would use this: when I write a rule, I ask where it is enforced. If the answer is "in the prompt", it is still a goal.

If one of these was useful, forward it to someone deciding where a rule should live. And if you have an answer to that question for your own stack, reply and tell me.