There was a time when automation was seen as an existential threat to testers.
If you go back far enough, “real testing” meant hands-on exploration. It was about human judgment, curiosity, and the “tester’s mindset”. Critics dismissed early automation as a mountain of flaky, brittle code that offered no real value. They pointed to the constant maintenance and the sea of ‘false red’ bars as a reason to stick to manual testing, rather than seeing it as a tool that just needed to mature.
Then the industry changed.
It didn’t happen overnight, but it happened decisively. Today, a high-performing team without automated regression is like a car without tyres, you might be able to drive a bit, but you aren’t going anywhere fast.
What’s fascinating isn’t that automation “won.” It’s what happened to the people who refused to pick up the tool.
The Quiet Career Shift
The testers who didn’t embrace automation didn’t vanish. They just found their roles shifting out of the “engine room” of product delivery.
- Some moved into other roles, those focussed on coordination.
- Some stayed in manual-heavy environments where the pace of change is glacial.
- Many found that their career ceiling lowered significantly as “writing automation” became a baseline expectation.
It wasn’t that they were being replaced; they were just being outpaced by colleagues who had stopped trying to win the race on foot while everyone else was getting in a car.
The testers who learned to automate increased their impact. They stopped reporting bugs and started designing systems to prevent them. They scaled their influence.
Now it is happening again, but this time it’s coming for all engineers.
Defining Engineers
When I talk about engineers, I’m talking about anyone who uses code to build, move, or validate a product. Whether you are a Software Engineer, a Quality Engineer, or a DevOps specialist, if you are using a keyboard to express intent through code, this shift applies to you.
From Typing to Shaping
AI-assisted development feels exactly like those early days of automation. There is legitimate skepticism, a bit of “purist” pushback, uncertainty over what tools to learn, and a healthy dose of fear.
AI tools can draft functions, generate tests, and explain legacy code. They remove the mechanical “grunt work” of typing. But they don’t remove the need for judgment.
In fact, the shift is almost identical to the one we saw in Quality Engineering:
| From… | To… |
| Writing Boilerplate | Refining Intent |
| Constructing Line-by-Line | Reviewing & Validating |
| Remembering Syntax | Shaping Architecture |
Engineers who integrate AI effectively aren’t “letting it code for them.” They are using it to move through the boring stuff faster so they can spend more time thinking.
The Risk of the “Pure” Engineer
The testers who ignored automation weren’t wrong about its limits. Early automation was brittle. It did create false confidence. But refusing to engage with it didn’t protect their craftsmanship; it just limited their scope and their ability to shape the future.
You can absolutely continue writing software without AI. You can craft every line by hand, just like you can still test every edge case manually. But over time, teams that use AI will:
- Iterate faster.
- Explore more design alternatives, and so pick better solutions.
- Reduce the mechanical workload.
That advantage compounds. Career trajectories follow leverage, and AI is the biggest lever we’ve seen in decades.
The Speed Trap
AI doesn’t just reduce typing; it obliterates cycle time. But velocity is a double-edged sword. If you’re moving ten times faster toward a cliff, “efficiency” is the last thing you need.
In a world where code can be generated in seconds, our role shifts from being the engine to being the stability control system. To do this well, we have to move away from “accidental friction” (bad tools, slow sign-offs) and embrace Strategic Friction.
Strategic Friction
These are the intentional bottlenecks we design into our process specifically where risk lives:
- Architecture Guardrails: If AI can spin up a microservice in minutes, we need senior-led standards that ensure it doesn’t become a distributed nightmare.
- Deep-Dive Peer Reviews: Shifting the focus from “Does this look right?” to “How does this break the system?”
- Automated Risk Gates: Designing smarter CI/CD checks that trigger deeper scrutiny when AI-generated boilerplate touches critical paths like security or payments.
The Differentiator is Application
There’s a massive difference between blindly trusting a generated block of code and thoughtfully integrating AI into a workflow. Just like there was a difference between “record and playback” testing and designing a maintainable automation framework.
The tool isn’t the differentiator. The quality of its application is.
We need our best engineers, the ones with the battle scars and the deep systems thinking, engaged in the process of building these standards. If the most experienced heads in the room choose to ignore AI, they lose the ability to design the very “speed bumps” that keep high-velocity teams safe.
You don’t want your most senior people hand-crafting every line of boilerplate. You want them designing the environment where AI-assisted teams can run at full tilt without crashing the business.
The Modern Junior / Senior Relationship
There is a hidden risk here: if we automate the “grunt work,” we risk removing the training wheels for our junior engineers. We cannot let AI-assisted development turn our next generation of talent into “prompt-monkeys” who don’t understand the underlying code.
This is where the senior engineers have their most important job. Mentorship.
Mentoring hasn’t just become important; it has always been the soul of the senior engineer’s role. It’s how we scale the craft. The age of AI simply amplifies that value.
The shift in the relationship is a move from teaching the “how” to a greater focus on explaining the “why.” Because with AI-assisted development they can move through the syntax faster than ever before, juniors need to be ready for system-level thinking much sooner than we were. Our job is to pull them into the Strategic Friction where they can develop the engineering intuition that no LLM can replicate. We aren’t just checking their work; we’re inviting them to the table to help us build the future.
Gradually, Then All At Once
If you look at how Quality Engineering evolved, automation didn’t replace the best testers, it elevated them. It gave them broader influence and more strategic input.
AI-assisted development is doing the same for engineers. It’s not an invitation to think less; it’s an opportunity to think at a higher level of abstraction.
The risk isn’t that AI replaces engineers. The risk is that engineers who choose not to engage will find their roles narrowing while the rest of the industry scales.
It happens quietly at first. Then gradually. Then, all at once.
Further reading
If you enjoyed this post then be sure to check out my other posts on Engineering Leadership.
Join the flock
Subscribe to get the latest posts on the messy reality of software delivery sent directly to your mailbox. I regularly share new thoughts on leadership and strategy —zero spam, just value.
Leave a Reply