The more important question - how would you actually get LLM agents to follow the instructions in your ever-growing CAPA reliably?

It’s all very well having a list of actions to avoid but that doesn’t help if your agents won’t reliably follow it.

▲

jaggederest 6 hours ago | parent | next [-]

You stop relying on the agents following instructions exactly.

You need two pieces:

a) prompts, that tell the agents what to do and how to do it (and ideally, the why, where, etc, the full picture) - that's the positive half, that drives behavior the way you want it.

b) deterministic tooling that prevents negative outcomes, like linters, compilers, static analysis, fuzzing, testing, the more the better. This side should either be firewalled off from the AI or very carefully watched so that it doesn't drift.

The part that you put in the deterministic side is the "never do x" stuff - I have lint for long comments (which AI hits every single time it commits), all my dev scripts are in typescript, precommit hooks, massive CI, and I lint even for things like redirecting error to standard out, tiny stuff, and also e.g. static migration analysis so the AI never ships an exclusive full table lock in a migration, for example.

▲

sarchertech 5 hours ago | parent | next [-]

You can’t deterministically keep them from making even a tiny fraction of all the possible errors they can and do make though.

You can’t keep humans from making those errors either but you also don’t let an error prone human crank out 20k LOC per day without forcing other humans to understand it.

	▲	CharlieDigital 5 hours ago \| parent \| next [-]
		This may be platform dependent. C# Roslyn Analyzers[0], for example, are quite powerful and can identify complex patterns in code. One approach to deterministic enforcement would be to ensure that the project is set up with an analyzers library and mistakes that can be deterministically flagged are [0] https://learn.microsoft.com/en-us/visualstudio/code-quality/...
	▲	jaggederest 5 hours ago \| parent \| prev [-]
		I don't know if that's necessarily true in practice the way it is in theory. If you knock down 95% of the issues they create over a certain period of time, in practice you'll have better code than a human would write, and it's all upside from there. I've been using languages with stronger type systems and that's also a huge boon.

▲

monknomo 5 hours ago | parent | prev [-]

yes, this is a very helpful approach. I take a similar approach, partly because I find bringing up negative directions seem to bring the undesired action/direction into the agent's view and makes it more likely that they will go there

▲

CraigJPerry 6 hours ago | parent | prev | next [-]

Why couldn't you express all those as test cases rather than instructions?

In test cases i can do anything, a test framework is just a way of discovering and then scheduling functions to run. I can emit useful instructions to the agent from the failed test case: "After walking the AST of all use of state machine X, a branch was found at Y which reused stale state. Ensure stale references are dropped..."

I can force the agent to pass the test suite before it considers itself done. I can reject edits of such test cases to partially mitigate reward hacking. etc etc

	▲	CharlieDigital 5 hours ago \| parent \| next [-]
		You can express them as tests, but you also need a feedback mechanism that creates the rule that when the LLM generates some net new code or performs some refactor, that there are these CAPAs that it needs to cover with test cases. The CAPA is a learning that sits outside of the mechanism of verification; it is a record of problem:root_cause:preventative_action. I see it as the instruction that would be required to generate the test case to prevent the next occurrence of a class of failures. In a real-world process, for example, there is usually a QA lead that is verifying that the process is followed by looking at the paperwork and evidence.
	▲	palmotea 5 hours ago \| parent \| prev [-]
		> Why couldn't you express all those as test cases rather than instructions? How would prevent removing the test case and the code that it tests? That's a legitimate thing to do when you're modifying a codebase. My intuition is "corrective and preventative actions (CAPA)" is a level or two up from test cases.

▲

CharlieDigital 5 hours ago | parent | prev | next [-]

This is a question of context management and I suppose some would classify this as "harness engineering" as the trend of the moment.

One approach, for example, might be to have the a standalone code reviewer agent that is solely responsible for interfacing with the CAPA system (e.g. via a tool, via MCP) and acts as a back stop. When it finds a new type of CAPA, it stores it (and the backend indexes it with enough metadata to support broad types of retrieval). When it reviews a piece of code, it finds past CAPAs. By file locality. By business domain in the application. By keywords.

Same tool and repository available to both building agents and review agents, but use the review agent as a dedicated back stop as part of the verification process.

▲

juancn 5 hours ago | parent | prev | next [-]

I think the only way for now it through distillation of your own models, which can get expensive fast.

▲

Ferret7446 5 hours ago | parent | prev [-]

The same way you do for humans, regular training and audits.