By NHI Mgmt Group Editorial TeamBased on Arize: “CLAUDE.md Best Practices for Claude Code” (November 20, 2025)

TL;DR: Prompt learning improved Claude Code by 5.19% on a by-repo split and 10.87% in-repo, using only system-prompt optimisation, LLM evals, and iterative feedback rather than model retraining or tool changes, according to Arize. The result matters because prompt governance is becoming a real control surface for AI coding agents, not just an implementation detail.


At a glance

What this is: Arize shows that Claude Code can be improved through prompt learning alone, with gains of 5.19% by repo and 10.87% within a repo.

Why it matters: This matters because the prompt layer is becoming part of the governance surface for AI coding agents, which changes how teams think about access, instructions, and operational control.

By the numbers:

  • Arize reports a 5.19% boost in Claude Code’s test accuracy on the by-repo split.
  • Arize reports a 10.87% improvement in Claude Code’s in-repo test accuracy.

Context

Claude Code prompt learning is a good example of a wider governance shift in AI coding workflows. The control point is no longer only the model or the toolchain; it is also the system prompt, the repository-specific instructions, and the feedback loop used to refine behaviour.

For identity and security teams, that matters because prompt content can shape how an AI agent interprets repository context, commands, and boundaries. When an agent is allowed to act through a prompt, governance has to cover instruction quality, change control, and the scope of delegated behaviour, not just authentication to the tool.


Key questions

Q: How should security teams govern prompt changes in AI agent systems?

A: Treat prompt updates as production changes that can alter access, not just behaviour. Put them through approval, logging, testing, and rollback controls, especially when prompts influence retrieval, tool use, or data exposure. The right question is whether the change can expand what the agent can do with existing identities, tokens, or secrets.

Q: Why do repository-specific instructions change AI agent behaviour?

A: Repository-specific instructions give the agent local context about file structure, coding conventions, testing habits, and accepted workflows. That context can improve output quality, but it also means the agent’s behaviour becomes tied to local rules that must be maintained. If those instructions drift, the agent may produce patches that fit the benchmark but not the live codebase.

Q: What are the signs that prompt optimisation is failing for a coding agent?

A: Common signs include patches that pass isolated tests but break repository conventions, repeated mistakes on the same API patterns, and output that improves in one codebase while degrading in another. Those patterns usually mean the prompt is too narrow, the feedback loop is too weak, or the instructions are encoding brittle assumptions instead of durable rules.

Q: Should organisations prioritise prompt governance before model fine-tuning for coding agents?

A: Yes, when the issue is repository fit, instruction quality, or policy adherence. Prompt governance is cheaper, faster, and easier to audit than model retraining, and it often delivers measurable gains before any tuning work starts. Model changes make sense later, but only after teams have exhausted instruction-level controls and evaluation discipline.


Technical breakdown

How prompt learning optimises coding agent behaviour

Prompt learning is a feedback-driven way to improve agent output by changing the instructions rather than the model weights. In Arize’s workflow, Claude Code generated patches, unit tests scored those patches, and an LLM evaluator explained why results succeeded or failed. The meta-prompt then used that richer feedback to revise the system prompt. This is materially different from fine-tuning because the behaviour change lives in instructions, not training parameters. For coding agents, that means repository conventions, command preferences, and error handling can all be encoded as governance artifacts.

Practical implication: Treat prompt files and system-prompt append rules as controlled configuration, not informal notes.

Why repo-specific instructions change coding outcomes

The split between by-repo and in-repo testing shows two different optimisation goals. A by-repo split tests whether a prompt can generalise across repositories, while an in-repo split tests whether the agent can internalise one codebase’s patterns, conventions, and pitfalls. That makes repository context part of the operating model for the agent. In practice, the prompt becomes a compact policy layer that tells the agent how to reason about local files, testing habits, and accepted coding norms. The tighter the repo context, the more the agent’s output reflects that local governance model.

Practical implication: Manage repository-specific prompt rules with the same discipline you apply to source control and build configuration.

Why LLM evals matter more than scalar rewards

Scalar test scores tell you whether a patch passed or failed, but not why. Arize’s approach uses LLM feedback to explain the failure mode, such as misunderstanding APIs, missing edge cases, or making the wrong assumption about repository structure. That gives the optimiser a much better signal for prompt revision than a raw pass-fail count. For governance, this is important because the control surface is not only the agent output, but also the reasoning trail used to tune the agent. Better feedback loops reduce blind prompt churn and make changes more auditable.

Practical implication: Keep evaluation rationales alongside test results so prompt changes can be reviewed and justified.


Threat narrative

Attacker objective: The objective is to influence an AI coding agent’s behaviour through prompt-level control so it produces unsafe or incorrect output at scale.

  1. Entry occurs when a coding agent receives repository context and a mutable system prompt that can shape how it interprets instructions and acts on code.
  2. Credential or control abuse is not the main issue here; the risk is governance abuse through overbroad prompt influence, where instructions steer the agent beyond intended repository norms.
  3. Impact appears when poor prompt governance leads to wrong patches, missed edge cases, or behaviour that diverges from the codebase’s expected patterns.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

Prompt governance is becoming a first-class control surface for AI coding agents. This article shows that meaningful performance changes can come from system-prompt optimisation alone, without retraining or tool changes. For security teams, that means prompt content, prompt versioning, and prompt approval now belong in the same governance conversation as API permissions and repository access. The practitioner conclusion is simple: treat prompts as policy.

Repository-specific prompt tuning creates a new form of operational dependence. The in-repo result is not just a benchmark curiosity; it shows that a coding agent can be specialised to a codebase’s conventions, which is useful but also fragile. That makes prompt drift, stale instructions, and undocumented local rules governance risks. The practitioner conclusion is to control where specialisation is allowed and who can change it.

LLM evals are the difference between blind optimisation and governed improvement. A raw score tells you whether a patch passed, but not whether the prompt encouraged unsafe assumptions, brittle code, or repository misuse. Rich evaluator feedback can surface the failure mode behind the score, which makes the optimisation process auditable. The practitioner conclusion is to require explanation, not just outcome, before prompt changes are promoted.

For AI agents, instruction boundaries matter as much as identity boundaries. A coding agent that can be given repository rules through CLAUDE.md or a system prompt is operating through delegated authority, even if it is not fully autonomous. That is why agent governance has to cover instruction scope, change control, and reviewability alongside access control. The practitioner conclusion is to govern the agent’s instructions as carefully as its credentials.

Prompt-level gains should sharpen, not weaken, security expectations. If a small instruction change can move benchmark outcomes by several points, then the same mechanism can also change error patterns, unsafe output, and policy adherence. That makes prompt engineering a security-sensitive activity, not just a productivity trick. The practitioner conclusion is to classify prompt edits by risk and review them accordingly.

From our research library:

What this signals

Prompt governance debt: when prompt files accumulate local exceptions, agent behaviour becomes difficult to explain, reproduce, or secure across repositories. Security teams should expect prompt review to move closer to code review, especially where coding agents can write or modify production-adjacent logic.

A mature programme will distinguish between baseline instructions, repository overlays, and one-off experimental prompts. That separation matters because the prompt layer is now capable of changing agent output without changing the model, which means change control has to reach into the instruction plane as well as the build plane.


For practitioners

  • Establish prompt change control for coding agents Version system prompts, CLAUDE.md files, and any append-system-prompt rules in source control with reviewer approval before deployment.
  • Separate general and repository-specific instructions Maintain a baseline instruction set for all repositories and a tightly scoped repo-specific layer so local conventions do not leak across projects.
  • Require evaluator rationales for prompt updates Store LLM feedback explaining why outputs passed or failed, not just the final score, so prompt changes can be audited and rolled back.
  • Limit who can modify agent instructions Restrict write access to prompt files and agent configuration to the same roles that can approve production code or pipeline changes.
  • Test prompt changes against held-out repositories Use separate train and test splits to check whether prompt edits improve general coding behaviour rather than only overfitting to one codebase.

Key takeaways

  • Prompt learning can improve coding-agent output without touching model weights, which makes the instruction layer a real governance control.
  • Repository-specific tuning is useful for codebase fit, but it also increases the need for versioning, review, and rollback discipline.
  • LLM-based evaluator feedback gives teams better insight into why an agent failed, which makes prompt optimisation more auditable than score-only tuning.

Key terms

  • Prompt Learning: Prompt Learning is the practice of improving an agent by iteratively refining the instructions it receives rather than changing model weights. It uses evaluation feedback to adjust prompt wording, structure, and constraints so the agent behaves better in a specific task or environment.
  • System Prompt: The system prompt is the core instruction set that defines an LLM’s behaviour, boundaries, and response style during a session. When attackers influence or override it, they are not merely changing text. They are trying to change the model’s governing authority.
  • LLM Evaluation: LLM evaluation is the process of scoring model outputs against defined criteria so teams can judge quality before or after release. It typically uses test datasets, scorers, and review workflows to measure correctness, safety, relevance, and task success in a repeatable way.
  • Repository-Specific Specialisation: The practice of tuning an agent to the conventions and patterns of a single codebase. It can improve local performance, but it also creates dependency on accurate, maintained instructions that reflect the repository’s current state.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, and secrets management for practitioners who need to govern delegated machine behaviour. It helps security and IAM teams build the control thinking needed for AI-driven workflows.
NHIMG Editorial Note
Published by the NHIMG editorial team on August 21, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org