The Constraint Wasn't Technical. It Was Habitual.
How a five-minute conversation with a QA engineer changed the way we build.
There’s a version of this conversation happening in every organisation with an engineering team right now. Someone mentions they’re “AI-native,” and what they mean is: they’ve might be running Copilot auto-completing their functions, or Claude Code in their terminal. That might be enough for some to call them AI native. To really be native, you have to change not just how you work, it’s about how you think.
Swapping your tool-chain doesn’t make you AI-native any more than buying a stand-up desk and dare I say, an under-desk treadmill, makes you a productivity guru. The tools are incidental. The shift that actually matters happens in how you think, how you contemplate a problem, how you hold a technical decision, and how you approach the blank page before any human or agent writes a line of code.
To me the most eye opening part is when we instigated an AI enabled code review on our Pull Requests, it’s great, saves time, catches a lot of potential bugs before they hatch, and ultimately let’s us move a lot faster and safer than if humans were the only source of reviews. BUT, we put the review here because that’s where reviews were done, right? Code has always had a critical eye passed over when the PR is raised, it’s the logical and most sensible place for it.
That was until I was sat with our senior QA and he said it’s a bit of a pain to raise a PR and wait for the reviewer bot to give you feedback when you know it will almost always catch something you should implement. Then it struck us; it’s AI, we’re not raising something to wait for someone to be free to get around to.
“A new form of shift-left.”
It’s on demand. We can trigger a review whenever we like. No need for raising a PR, waiting for all the code tests, and security reviews to pass before the AI reviewer gets to work. We can call a review off of our local code and get feedback here and in the space we will action it.
The most popular promise of AI was automating the boring, tedious bits away. I’m sure there are engineers out there who are absolutely riveted by reviewing pull requests, but that’s not me, and I’m pretty sure it’s not my team. Instead with shifting peer reviews to be done as we need them, on demand and in a way we can action them immediately has given us more space to focus on building software, safe in the knowledge that what we produce is as safe as can be.
The shift isn’t dramatic. It doesn’t announce itself. It’s the moment your QA says “why are we waiting around all the time?” and you realise the constraint you were working around wasn’t technical - it was habitual. This change came from a five-minute conversation with a senior QA who was mildly annoyed. That’s it. No grand strategy session, no AI task force. Just someone asking why we were still doing something the old way. I’d be willing to bet every team has a version of that conversation waiting to happen. What’s yours?