The more I read about AI and software delivery, the more I think the bigger shift is not just speed, but volume.
If software becomes easier and cheaper to produce, we are likely to get a lot more of it. More code, features, products, updates, and that changes what matters.
The advantage is not just in being able to build, but in being able to build things that people trust, teams can safely use, and systems can absorb.
This week’s links got me thinking about what happens when software becomes more abundant, and why quality, trust, and better delivery systems may matter even more because of it.
Latest post from the QE Newsletter
Test automation never replaced testers because it only automated part of the role. Scripted checking could be automated, but exploratory testing, investigating risk, understanding what had and had not been covered, improving testability, and helping teams think more clearly about quality still needed to happen.
AI is currently being used in a similar way. It is automating specific tasks, not replacing whole roles. Role displacement is more likely to happen when software delivery itself is reorganised around AI, not just sped up at the edges.
If AI helps organisations produce more software, then the differentiator shifts. It is not just who can generate more output, but who can build systems, teams, and products that keep working well as that output grows.
Staff engineers sound like quality engineers
They learn why the system is the way it is. They understand the business pressures shaping technical decisions. They identify which constraints are real and which ones can be challenged.
This stood out to me because it sounds very close to how I think about quality engineering.
Good QEs take the time to understand how quality is created, maintained, and lost within complex systems. They work with teams to create more of the conditions that lead to the outcomes we want, and less of the ones that do not. Via A Staff Engineer isn’t an “extra strong Senior.” It’s a fundamentally different job. | Abhishek Singh | X.com
The code tsunami
A really good post from Vernon on how teams might deal with the wave of code coming now we have poured rocket fuel on the coding part of software delivery.
The part I especially liked was the breakdown of in-production testing into three distinct stages: deployment, release, and post-release. None of this is brand new, but naming those stages separately helps teams think more clearly about how they manage risk in production.
Rather than treating shipping as one big lump, it helps to think about rolling it out gradually, monitoring what happens, and limiting the blast radius if something goes wrong. That is not a replacement for pre-production testing. It is an additional part of how teams build confidence when the amount of software being shipped keeps increasing. Via The Code Tsunami | Vernon | Yeah But Does It Work?
Each layer of review makes you 10x slower
Code a simple bug fix
30 minutesGet it code reviewed by the peer next to you
300 minutes → 5 hours → half a dayGet a design doc approved by your architects team first
50 hours → about a weekGet it on some other team’s calendar to do all that
500 hours → 12 weeks → one fiscal quarter
While I think 10x is probably exaggerated, I do agree with the broader point. Layers of review and approval often slow things down, less because of the work itself and more because of the waiting that builds up between steps.
It also made me think about internal teams building modules or platforms that other teams depend on. In that scenario, consuming teams need to be able to trust that what they are being given is of a high enough standard that they do not need to retest everything from scratch.
If they cannot trust it, everything slows down. Teams become more reluctant to adopt updates, integration gets heavier, and the cost of coordination rises. If software gets cheaper to produce, trust becomes even more important, because without it the whole system gets buried under verification, waiting, and rework. Via Every layer of review makes you 10x slower | apenwarr
Types of consulting roles a QE could operate in
I found this grid from Training and Development Journal (Feb 1990) via Neil Vass’s coaching notes, which are well worth a read.
As QEs, our role is to help teams build quality in, not to do it for them. How that looks varies, but I tend to see QEs working mostly across columns 1 and 2 of the grid.
I am usually in column 1 (counsellor, facilitator, reflective observer) when running workshops or helping teams reflect more clearly on how they work. I move more into column 2 (coach, teacher, technical adviser) when helping teams with specific problems, offering guidance, teaching, or technical advice.
The interesting tension is that the work in column 3 (partner, modeller, hands‑on expert) often has the most visible impact. It is hands-on, easy to see, and easy to attribute. Work in columns 1 and 2 can have a much broader impact, but it is often less obvious because it is more about helping the system work better through people, habits, and relationships.
If software becomes easier to produce, I think this kind of work becomes even more valuable. Not because hands-on work stops mattering, but because helping teams build stronger habits, better judgment, and healthier systems becomes a bigger part of coping with the volume.
Another common issue is misaligned expectations. Teams may want you to operate in column 3 while you are intentionally trying to work more in columns 1 and 2. If that is not discussed early, it can create friction, especially when different QEs around them work in different ways. Via Coaching: Understanding the options | Neil Vass
In the age of AI, quality may matter even more
In markets shaped by scale and replication, small differences in perceived quality, visibility, or reputation can generate very large differences in reward.
This is a fascinating post about how streaming changed where scarcity sits in music. Once anyone could listen to almost anything, anywhere, at any time, scarcity shifted away from access to music itself and towards attention and live experiences.
That creates a world where small differences in quality, reputation, and visibility can make an outsized difference.
I think AI has the potential to push software in a similar direction. As it becomes easier to build more products and features faster, quality may matter even more, not less. When people have more choice, the products that feel more reliable, useful, and trustworthy can pull further ahead.
The people who stand to gain the most are often those already commanding the most attention, and those who can move quickly with very small teams. It is the middle that may feel the squeeze most. Via Rockonomics: The Logic of Relative Scarcity
What is your system teaching you
Every organization is running an educational program whether it intends to or not. The question isn’t whether your system teaches, it’s what it’s teaching. If your system teaches people that quality is someone else’s job, that shipping fast matters more than shipping well, or that raising a concern creates more trouble than ignoring it, you will get exactly the quality that curriculum produces. No amount of testing will change that.
This gets right to the heart of quality engineering for me.
If all we do is test, all we get is a faster signal about the level of quality currently coming out of the system. That can be useful, but it is not enough. If we want better outcomes, we have to shape the conditions that produce them.
That means nudging the system towards producing more of the behaviours, habits, and interactions that lead to quality, and less of the ones that undermine it. Via Quality Isn’t a Testing Problem | Alan Page
Close
The thread running through these links is that if software becomes easier to produce, then quality may matter even more, not less.
More code does not automatically mean more value. It can just as easily mean more noise, rework, coordination overhead, and risk. The teams that benefit most will not just be the ones who can generate more software. They will be the ones who can build trust in what they produce, shape systems that sustain quality, and help others move without needing to double-check everything from scratch.
That feels like a useful way to think about quality engineering in the age of AI. Not as the thing that slows delivery down, but as the thing that helps teams cope with a world where much more software is being produced.
