Depends. Back in the day, I worked on development tools for a commericial avionics flight management computer. The headcount for embedded hardware/software verification was greater than for development.
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.
I work at a hyperscalar and we just send it, if something breaks the model can just open a ticket and fix it automatically and write a new test. This is much cheaper than spending a bunch of money and stalling things with human CI/CD
Whatever happened to the principle that finding a bug during design is best, finding it during development is a little worse, finding it during QA is even worse, and finding it in prod is the least acceptable?
"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?
Everybody is trying to copy the companies who have either already-established dominant market position or such compelling products that a bunch of paper-cut bugs don't really matter as long as they aren't catastrophically fucking people over.
you dont just get to ci/cd your way to nirvana. your ci/cd are only as good as your tests. your tests are only as good as the understanding of the tests. left to AI nobody knows what the code or the tests are doing they could just be hardcoding passes for all you know.
I was talking to some friends about how CI/CD should be used in $current_year if you have fully committed to agents.
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".
This is all good stuff to verify of course, but why would you not continually add the useful agent-created tests and verifications into a deterministic suite to ensure consistency of coverage?
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.
I agree. IN addition I think many businesses/industries are still not aware of the full capability of AI yet, that is why they still do things the old way. I have several friends who work as QA. When they describe the things they do daily, I tell myself quietly that AI agents can do all of them now.
I just don't understand the premise. If we're fully committed to agents, what does it mean to talk about a test being hard to maintain or requiring hardcore plumbing? "Hey Claude, can you please mock out Component X and write a test suite capturing behaviors A, B, C of component Y. Thanks!" When in the process of typing this would I go "ughh", and why would I prefer to receive a SCENARIOS.md as output rather than a test suite?
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.
There's a reason verification and code review shouldn't be done by the person who wrote the code, and those reasons don't magically go away because a code generation tool did it instead.
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.
This LLM as compiler analogy comes up here and there and it’s not hard to poke a hole in it.
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?
Yea, maybe one day in the future, "the LLM prompts" will be considered the source code. But a lot has to happen first, namely the same prompt needs to deterministically create the same intermediate code. I wouldn't check in source code that compiles a different binary every time, and we should not treat prompts as source code while they produce different code.
Traditionally, that'd be a joint effort between a dedicated QA team, partially supported by the engineering team, that no one wants to pay for...
Depends. Back in the day, I worked on development tools for a commericial avionics flight management computer. The headcount for embedded hardware/software verification was greater than for development.
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.
Isn't that why there's such investment into code verification agents in the cicd pipeline?
If the future is agentic, human review will be core bottleneck that needs to be streamlined.
I work at a hyperscalar and we just send it, if something breaks the model can just open a ticket and fix it automatically and write a new test. This is much cheaper than spending a bunch of money and stalling things with human CI/CD
Whatever happened to the principle that finding a bug during design is best, finding it during development is a little worse, finding it during QA is even worse, and finding it in prod is the least acceptable?
"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?
Everybody is trying to copy the companies who have either already-established dominant market position or such compelling products that a bunch of paper-cut bugs don't really matter as long as they aren't catastrophically fucking people over.
Most people don't have that luxury, though.
How does the AI know something is broken?
you dont just get to ci/cd your way to nirvana. your ci/cd are only as good as your tests. your tests are only as good as the understanding of the tests. left to AI nobody knows what the code or the tests are doing they could just be hardcoding passes for all you know.
Then you can get a verification agent to validate the quality and coverage of those tests.
And when your users complain because you've left yourself with a pile of broken, unmaintainable slop?
You are working on the incorrect assumption that AI generated code are automatically broken.
Often the maintenance of the code is also left to AI, human readability is a bonus.
We’ve already stopped bothering with human reviews where I’m at.
AI:
- writes the code
- reviews the code
- designs it
- productizes it
- advertises it
- consumes it
I was talking to some friends about how CI/CD should be used in $current_year if you have fully committed to agents.
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".
This is all good stuff to verify of course, but why would you not continually add the useful agent-created tests and verifications into a deterministic suite to ensure consistency of coverage?
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.
I agree. IN addition I think many businesses/industries are still not aware of the full capability of AI yet, that is why they still do things the old way. I have several friends who work as QA. When they describe the things they do daily, I tell myself quietly that AI agents can do all of them now.
I just don't understand the premise. If we're fully committed to agents, what does it mean to talk about a test being hard to maintain or requiring hardcore plumbing? "Hey Claude, can you please mock out Component X and write a test suite capturing behaviors A, B, C of component Y. Thanks!" When in the process of typing this would I go "ughh", and why would I prefer to receive a SCENARIOS.md as output rather than a test suite?
How stable is the boundary of Component X?
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.
If you build guardrails on what is generated, verification is done at the same time as generation.
There's a reason verification and code review shouldn't be done by the person who wrote the code, and those reasons don't magically go away because a code generation tool did it instead.
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.
It’s amazing how much developers want to automate themselves out of a career.
A lot of the risk is insider risk. A hacked credential, an annoyed engineer going to a competitor, etc.
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.
This is mathematically challenging as your system gets more complicated.
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.
what are the guardrails?
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?
it's bull-crap
Guard-rails are totally ineffective
What "guardrails" specifically ensure that? I assume you have a more interesting idea than simply suggesting more tests.
“Make no mistake.”
The same people that verify what a compiler spits out?
This LLM as compiler analogy comes up here and there and it’s not hard to poke a hole in it.
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?
Yea, maybe one day in the future, "the LLM prompts" will be considered the source code. But a lot has to happen first, namely the same prompt needs to deterministically create the same intermediate code. I wouldn't check in source code that compiles a different binary every time, and we should not treat prompts as source code while they produce different code.
That would be compiler writers, which seems unlikely.
Anyone can look at compiler output and verify its correctness.
The question wasn’t who can, but who does.
That's a big assumption. We don't even have formal specifications for many popular high level languages so there's nothing to verify against.
kek