AI writes the code faster, but bugs and incidents are rising faster still
AI Can Write the Code. Who Verifies It?
A 2026 Faros study of telemetry from 22,000 developers found that high AI adoption brings 54% more bugs per developer, roughly five times longer median PR review time, and over three times as many incidents per PR. Since small teams can't meaningfully review huge AI-generated diffs, the author argues for automated verification: layered CI/CD checks spanning linters, tests, security scans, agentic review, infrastructure and database validation, and human accountability on risky changes.
Two agents can agree on the same wrong answer, overlook the same requirement, or confidently flag a bug that doesn't exist.
- pianopatrick
One idea I am thinking through is that I might want to use a linter to restrict the AI to only use a subset of various languages which would not need as much review.
For instance, if I wrote a web front end that only allowed certain HTML tags and certain CSS properties and no Javascript, I could avoid certain classes of errors entirely.
Or for instance, in C, if you disallow dynamic memory allocation you also avoid entire classes of errors.
These are checks I think I can configure with linters and would give me more confidence that AI generated code did not have certain errors.
- alcomatt
Perhaps the question here should be, "Who takes the blame when it all goes south?"
- salawat
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...
- thisisthenewme
AI:
- writes the code
- reviews the code
- designs it
- productizes it
- advertises it
- consumes it
- simianwords
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 erro […]