A few weeks ago, I asked one of my team leads for the agent instructions behind a particular pipeline we’d built. My intent was straightforward, I wanted to understand the architecture from the inside. When you want to really understand how an agent thinks, reading its prompt is the most direct path.

The prompt ran to several pages. Complex enough that I didn’t want to read it line by line myself, so I handed it to Claude and asked for an analysis.

What came back stopped me.

Contradictions between instructions in different sections. The same concept explained multiple times, inconsistently. Conditions added in one place that undermined rules established somewhere else. The prompt didn’t read like a coherent set of instructions. It read like a document that had been edited by several people who hadn’t read each other’s work.

Which, it turned out, is exactly what had happened.

When I asked the team lead whether this prompt had gone through peer review, the answer was no.

Not a rushed review. Not a partial review. No review at all.

I’ll be honest, I was surprised. This team follows good engineering practices. Code goes through automated quality checks. Pull requests get reviewed. There are standards. But somehow the prompt files, the instructions that define how the agent thinks and what it does, had been excluded from all of it.

What had happened was this: the agent had been adapted over time for different but related use cases. Each time, a developer made targeted edits, adding specificity here, inserting a condition there. Each edit made local sense. But nobody was reading the whole prompt before checking in. Nobody was asking: does this new instruction contradict something we wrote three sprints ago? Does this tip I’m adding conflict with a rule that already exists?

The prompt had deteriorated. Gradually. Silently. Without anyone noticing because the output was still acceptable.

This is the insidious thing about prompting: LLMs are forgiving. Give a model a contradictory or redundant prompt and it will still produce something reasonable. It will reconcile the contradictions in its own way, pick the interpretation that seems most contextually relevant, and generate an output that looks fine.

There is no compiler error. No syntax exception. No red line under the offending instruction. The code equivalent of a contradictory prompt would throw an error immediately. The prompt equivalent of a bug just silently shapes the output in ways you may not trace back to the instruction for weeks.

And that is exactly the problem.

The practical fix I landed on came from an obvious place once I saw it: if prompts are written in English, and LLMs can parse English as well as any human can — better, in many ways, at scale, then LLMs are actually well-suited to review prompt files.

I asked Claude to analyse the prompt not just for what it said, but for internal consistency, contradictions, redundancies, ambiguous or conflicting conditions, instructions that pulled in different directions. The output was a structured review with specific citations: here is where instruction A conflicts with instruction B, here is where the same concept is explained three times with slight variations, here is a condition in section four that is undermined by a rule in section seven.

We fixed the prompt based on that review, ran it through our validation metrics, and saw two things: a material improvement in agent output quality, and a measurable reduction in tokens consumed. A cleaner prompt is a more efficient prompt. The model doesn’t have to work as hard to resolve ambiguity that shouldn’t have been there in the first place.

The peer review that followed also surfaced something else worth noting: several of the logical steps the prompt was asking the LLM to reason through could actually be handled algorithmically in code. Moving deterministic logic out of the prompt and into the application layer made the whole pipeline more predictable and more efficient. Sometimes the right fix for a prompt problem is to make it a code problem instead.

What started as an ad hoc review has now become something we are building into our development template as a standing copilot instruction. Every prompt file check-in will trigger an automated consistency review, the copilot itself scanning the instruction for contradictions, redundancies, and gaps before the change is accepted.

This matters more at scale than it might seem. Some of the agent pipelines we build have fifteen or more prompt files covering different aspects of the same workflow. Consistency within a single file is one problem. Consistency across fifteen files, ensuring that the instruction for one agent doesn’t silently conflict with the assumption built into another is a harder problem, and one that a human reviewer is poorly equipped to catch without tooling.

Prompt engineering is being treated as an informal skill because it looks informal. You write in plain English. You iterate quickly. The feedback comes fast. It doesn’t feel like writing code.

But prompt files are load-bearing. They define agent behaviour, constrain agent scope, and shape every output the agent produces. When they deteriorate, everything downstream deteriorates with it slowly, in ways that are hard to trace, in ways that look like agent limitations rather than instruction failures.

The disciplines we already apply to code peer review, quality gates, version control rigour, automated linting apply to prompts too. We just haven’t built the muscle memory yet, because the tooling didn’t exist and the consequences weren’t obvious enough, fast enough, to force the issue.

They are now.

If you are a CTO managing teams settling into AI-assisted SDLC, here is the question worth asking this week: when did someone last read your most critical prompt files end to end? Not the developer who last edited them. Someone who wasn’t the author.

If the answer is uncertain, that’s the signal.