A few weeks ago, I wrote a post called SoftwareCraftsmanship — When AI Writes the Code. The basic idea was pretty simple: AI hasn’t made software craftsmanship disappear. It has moved the craft from writing every line ourselves to making sure we understand the problem and own the outcome. That part is not really new.
For most of my career, we crafted code by taking
requirements, breaking them down into logic, and turning that logic into
instructions a computer could execute. AI is changing that because it can
generate code fast enough that writing code is no longer the hard part,
regardless of the size or complexity of the ask.
On the surface, that sounds like pure upside: higher productivity, more output, shorter cycle times. But software delivery has never been just about producing code. It is about delivering value to customers through software they can trust. The hard part was rarely just writing the code. It was understanding the problem, deciding what success looked like, and proving that the software solved the right problem.
AI can make code generation faster, but it does not remove the work on either side of it. The more it helps us generate software, the more we have to prove that the software works as intended. That sounds obvious. I’m not sure we’ve started acting like it yet.
I was reading Leah Brown's article How to Work with AI
Coding Tools Without Losing Your Engineering Judgment, and this line jumped
out at me:
"They do not produce correct answers—they produce
statistically likely answers, which is a different thing."
That is an important distinction. Because generative AI
systems are probabilistic rather than deterministic, they are incredibly good
at producing answers that look right. Sometimes they are right. Sometimes
they're not. The tricky part is that both correct and incorrect answers are
often presented by an AI with the same level of confidence.
Later in the article, Brown asks a question that I think
every engineer should get comfortable asking:
"What observable evidence would confirm that this
suggestion is actually correct, and have I gathered it?"
I think that's the question that as engineers we need to get
better at asking.
Not "Does this code look reasonable?"
Not "Would I have written it this way?"
Instead, the better question is: what evidence do I have
that this is actually correct?
That is not just my concern. The industry is starting to see
the same issue.
Google's DORA team talks about a "verification
tax" that organizations pay as they adopt AI-assisted development. As code
generation gets faster, teams spend more effort reviewing, validating, and
proving that generated code actually does what it is supposed to do.
That same pattern shows up in the 2025 DORA research, which
summarizes it this way: "Without robust control systems, like strong
automated testing, mature version control practices, and fast feedback loops,
an increase in change volume leads to instability." That is the risk AI
exposes if our delivery pipelines cannot handle the volume of change in an
AI-native world.
The Octopus Deploy AI Pulse Report describes something
similar. Teams are seeing real productivity gains from AI, but they're also
discovering that testing, reviews, deployment processes, and delivery systems
don't automatically speed up just because code generation does.
In other words, AI can help us produce code faster. It does
not automatically help us prove that the software works. That proof still has
to come from engineering discipline, automated validation, and the delivery
systems around the code.
That lines up with the way IT Revolution described the
downstream problem: "The current constraint in the delivery cycle is
usually somewhere downstream of the coding effort: code review, integration,
system test, or some other verification or validation step." If that is
true, then writing more code faster does not help much unless the validation
system gets stronger and more automated too.
This is not a new idea. Integration and system tests in the
deployment pipeline have always mattered. What AI changes is how little room we
have left to pretend they are optional. If AI helps us generate code faster, automated
validation cannot stay a "we'll add that later" item. For new
systems, that means building it in from the start. For existing systems, it
means moving automated validation into the delivery path now, before manual QA
becomes the bottleneck.
As AI makes writing code cheaper, unit tests are not enough.
Unit tests can tell us whether a function behaves the way we expect. They do
not tell us the system works. Automated integration and system tests in the
deployment pipeline are the safety net for delivering applications in the
AI-native era.
Those tests need to run before production. And if they fail,
that should pull the Andon Cord: make the problem visible, stop the pipeline,
and get the right people swarming on it immediately. Not warn us politely. Not
create a ticket for somebody to look at someday. Stop the pipeline until the
safety net is green again.
This also changes what we need to pay attention to in code
review. It has been easy to treat test code as a second-class citizen in the
code base because it is not the actual product code. We review the product code
carefully, then give the tests a lighter pass as long as they exist and seem
reasonable.
Tests are code. They do not stay useful because we wrote
them once. Every new feature, every meaningful change, and every bug fix should
leave the pipeline with better coverage than it had before. If the product
keeps changing and the tests do not, the safety net slowly stops protecting the
system we are shipping.
That does not work anymore. If tests are what we are relying on to validate AI-assisted changes, then tests need to get at least the same scrutiny as the product code, if not more. First, we need to know the system works on the happy path. If we do not have that, the risk is not that we missed an edge case. The risk is that the system fails and nothing in the pipeline catches it. Even when the pipeline is green and all the checks pass, the safety net can still have holes in it.
That is the part that gets more important in an AI-assisted
world. Testing is not becoming more important because AI writes bad code. Testing
is becoming more important because AI writes a lot of code, and it makes an old
problem harder to ignore. We have always been able to write code faster than we
can prove it works.
That proof cannot depend on manual QA catching up after the
fact. It has to be built into the delivery system. The pipeline needs to keep
asking the same blunt question before we ship: does the product still work the
way we think it does?
None of this makes unit tests less useful. It makes them
less sufficient. Unit tests still matter because they are fast, close to the
code, and good at helping us understand small pieces of behavior. They can
catch regressions while the change is still small enough to understand, and they
can make debugging easier without forcing us to reason through the whole system
every time.
But unit tests are not a substitute for integration and
system tests. They can give us fast feedback that small pieces behave correctly
in isolation. They cannot show that the product works when those pieces are
wired together, deployed, configured, authenticated, authorized, and used the
way customers use it. Unit tests are still worth writing. They help us move
faster safely only when they sit alongside integration and system tests that
prove the product still works.
AI is not making software engineering easier. It is making
some parts faster and other parts harder to ignore. Testing is one of those
parts.
If we are going to use AI to create more code, we need
delivery pipelines that can handle more change. That means automated
integration and system tests that run before production. It means failed tests
stop the pipeline. It means tests get reviewed like code because they are code.
It also means treating tests as part of every feature, every meaningful change, and every bug fix. Not someday. Not after the release. As part of the work. If the product changes and the tests do not, the pipeline gets less trustworthy over time.
As the 2025 DORA research puts it, AI's primary role is "as an amplifier, magnifying an organization's existing strengths and weaknesses." If the pipeline is slow, fragile, or mostly dependent on manual validation, AI will just move the bottleneck downstream faster. The teams that benefit most from AI will not be the ones that generate the most code. They will be the ones that can safely absorb more change because their pipelines give them fast, honest feedback about the current state of the product.
References
·
Leah Brown, How to Work with AI Coding Tools
Without Losing Your Engineering Judgment, IT Revolution:
https://itrevolution.com/articles/how-to-work-with-ai-coding-tools-without-losing-your-engineering-judgment/
·
Jonathan Snyder, Triangulating for
Truthiness: Effective Engagement with LLMs for Software Development and
Operations, IT Revolution:
https://itrevolution.com/product/triangulating-for-truthiness/
·
GeeksforGeeks, Deterministic vs Probabilistic
AI: Why Modern Models Lack Predictability:
https://www.geeksforgeeks.org/artificial-intelligence/ai-for-geeks-week2/
· Google Cloud DORA, ROI of AI-Assisted Software Development: https://cloud.google.com/resources/content/dora-roi-of-ai-assisted-software-development
· DORA, State of AI-assisted Software Development 2025: https://dora.dev/report/2025
· Octopus Deploy, 2026 AI Pulse Report:
https://octopus.com/publications/ai-pulse-report
·
DevLead.io, DevTips: Andon Cord:
https://devlead.io/DevTips/AndonCord
