If I generate a piece of code with LLM, and verify it to be correct; can you trust the LLM output, with the same prompt, in a new session based on my verification of my code, with the same certainty that you’d trust LLVM output for the same source code in a similar environment, ran independently? If no, why?
- writes the code
- reviews the code
- designs it
- productizes it
- advertises it
- consumes it
The industry is surprisingly slow to adapt and I'm writing two capabilities I'd like standardised in the industry.
I'd like standardisation of Agentic tests (I know, it sounds terrible) but these are tests that are broader and capture fuzzy intent of the system. Unit tests, e2e tests are focused and hard to maintain. An Agentic test (or a behaviour test) is where the agent understands the underlying behaviour intent and creates scenarios on the fly and executes them.
For example, I'd imagine that Claude Code goes through multiple Agentic tests where Claude itself tries to use the software using desktop control. This would capture a much broader range of bugs and its much easier to maintain because you only need the test to have a description of the intent and not all the hardcore plumbing required in e2e tests and unit tests (like mocks ughh).
I'd like a framework where I could simply have something like SCENARIOS.md and the framework runs the scenarios by spinning up the common environment required for the test. The industry is severely lacking in this kind of capability.
The next thing missing is Agentic deployment verification.
So image that you are deploying your service and you'd need to verify multiple metrics are in shape before you promote it to all servers. Traditionally this was done either by manual checks by the developer (tiresome and prone to errors) or just having alerts on a few key metrics (not extensive).
Concretely, I'd like the agent complete access to all my metrics and logs and have it make the judgement to either promote it or not promote it or notify the developer.
You'd argue this is not required, but in my experience, having this capability gives me a lot of sanity. There are greybeards who love to gatekeep their responsibilities and would argue something like "just have good unit tests!!11!!" but that's silly.
Why these are not becoming standard or even required practices is beyond me. I'm guessing that there's a cohort of developers whose mindset is risk aversion and they are not great at intuiting what an LLM is good at and what they are bad at. Unfortunately, a lot of arguments are just silly like "but hallucination", "but just have deterministic tests", "don't overcomplicate things".
Think embezzlement. Think someone with a political agenda who changes the homepage on the way out the door.
Having a single point of control is asking for trouble.
if there are many of them (e.g. unit tests), who generates those guardrails and who verifies their correctness?
if they are a few, then how can they cover vast product capability surface?
Guard-rails are totally ineffective
If you give up on trying to reduce the number of permutations you need to test, you're gonna also (even if not intentionally) give up on testing them.
We knew this, of course. But everything old is new again.
At some point the agent rewrites Component X, or X+Y, and now many or all of your tests that hit it directly are invalid and need to be rewritten. That introduces bugs, you're changing the tests and code at the same time, so you don't know if the new ones cover the same stuff as the old one.
I won't be "fully committed to agents" re: test-writing until they reach the point where they demonstrate that they're taking contract and component boundary stability into account in placing their tests. Currently I still need to intervene.
And the tests I point it at doing instead of the ones it does by default are currently catching more would-be or latent bugs than ever before, because we're changing stuff so much faster.
Agents won't make you better, quality-wise, unless you were in a lower-percentile of code-writing ability. But they'll make you a lot faster at raw change count. How good or bad that is depends on (a) the situation the product is in and the tolerance for issues/regressions, (b) how much existing judgment and best practices you can wrangle into position on top of those changes to make the path of least resistance for the agent be smoother.
For instance:
>Traditionally this was done either by manual checks by the developer (tiresome and prone to errors) or just having alerts on a few key metrics (not extensive).
Ignores the places where it's always been important enough to have automated checks on many things.
Of course, since AI will be doing the writing and maintaining, there's really no reason for that any more. Let the AI do it all and wait for management to realize they're paying senior salaries to people that are little more than entering prompts, a job that really only requires someone to be able to read and write English.
salawat•1h ago
PradeetPatel•53m ago
If the future is agentic, human review will be core bottleneck that needs to be streamlined.
Jagerbizzle•52m ago
polalavik•51m ago
PradeetPatel•38m ago
egg1•26m ago
PradeetPatel•19m ago
Often the maintenance of the code is also left to AI, human readability is a bonus.
augment_me•49m ago
ryandrake•28m ago
"Let's break prod and fix it later" is a terrible attitude. It didn't start with LLMs but boy LLMs seem to be making it widespread. Would it kill developers to find problems before deployment?
majormajor•19m ago
Most people don't have that luxury, though.
treespace8•8m ago
aworks•4m ago
That was never true for software development in other domains I worked in i.e. Fortune 500 enterprise tools, compiler/design tools, networking, and semiconductor.