What Martin Fowler Told Us About Navigating the AI Shift
By Diederik van Liere, CTO at Wealthsimple
Last month, we hosted Martin Fowler at our Toronto office for a conversation about AI, software architecture, and what this moment means for engineering teams. If you are of a certain age (mine) then you will know Martin either by having read his articles or you have even implemented some of his software architecture patterns, perhaps not even realizing he’s responsible for them. Martin has spent decades observing how software development changes, and his ability to discover patterns across technology cycles is something I always find valuable.
Here's what I took away.
The change is real, and the discomfort is normal
Martin was direct: this is the biggest technology shift he's observed in decades of working in software. That's significant. And it signals something important - feeling unsettled right now is completely normal. The technology is moving fast enough that even the most experienced technical leaders don't have a clear roadmap yet.
That matters for how organizations should respond. Waiting for certainty before acting isn't a strategy. It's how you fall behind.
You can't afford to ignore it
AI cannot be uninvented, and organizations that try to ignore it are making a serious mistake. The question isn't whether to engage, it's how.
The more teams sit on the sidelines, the more they give control over where this technology goes. We'd rather help steer it.
At Wealthsimple, that's deliberately choosing not to bet on a single platform or approach. We've been running parallel experiments across teams - trying different tools, models, and workflows - and staying honest about what the results are actually telling us.
Experimentation is the strategy
The most useful advice Martin gave was also the most actionable: commit to a set of things, run experiments, and iterate. There's no definitive playbook right now, and waiting for one to emerge isn't an option. The rules are changing week to week.
What makes this moment different is cost. Running experiments is cheap and fast. You can test three different approaches to a problem in the time it used to take to scope one. The differentiating skill isn't having the right answer upfront. It's being able to judge the results quickly and adapt.
Our engineers are already building that muscle. Teams naturally started writing detailed specs before prompting models, not because anyone told them to, but because it’s the only way to get reliable results. Martin names that instinct Spec-Driven Development. We arrived at it because the technology demanded it.
We’re also experimenting with running two or three agents in parallel on different facets of the same problem, letting the outputs provide trade-offs that wouldn't have been obvious.
That maker-owner mentality of trying things, learning fast and adjusting is what compounds over time.
The new constraint is cognitive, not computational
One thing Martin raised that I think about a lot is - as velocity increases, where do new bottlenecks appear? His answer was cognitive capacity. We can generate code faster than teams can meaningfully understand or review it. He called this "cognitive debt" - systems that outgrow the team's ability to reason about them.
The counter to cognitive debt is the same thing we've been pushing on for years: simplification. Fewer services. Fewer moving parts. Less code to reason about in the first place. AI that helps us delete is worth more to us than AI that only helps us generate.
He also talked about "cognitive surrender", which is when engineers start accepting AI outputs without enough scrutiny because reviewing them is exhausting. The fix isn't to slow down. It's to use AI as a tutor, not just a tool. Ask it to explain its decisions. Focus scrutiny on the parts that matter most. The engineers who build that discipline now will be the ones who can operate effectively at scale.
We've been deliberate about this. Our clients trust us with their money. That bar doesn't move because the tooling got faster. Good guardrails aren't about limiting what AI can do, they're about making sure the humans in the loop are actually in the loop.
Building judgment without a map
Someone asked Martin how you develop professional judgment when there's no established precedent to follow. His answer was honest: you can't wait for someone who's been through this before, because nobody has at this speed.
His advice: follow the people being honest about both their successes and their failures, not just the ones making confident claims. Stay curious. Run cheap experiments and pay close attention to what they actually tell you. Curiosity matters more than confidence right now, because curiosity keeps you searching for real signals. Confidence, without evidence, just gets you stuck faster.
That maps directly to how we think about what we're building. We have guardrails in place, we're not experimenting recklessly. But we're not waiting for a clear winner to emerge before we move.
What comes next
We're at an inflection point. The models and tooling are maturing to the point where they're starting to actually deliver on what we hoped they would. Teams that have been building the right foundations - strong domain expertise in things like payments, ledgers, and financial systems, combined with a maker-owner mindset and genuine curiosity - are going to compound on that now.
We'll share more of what we're learning as we go.
Interested in working at Wealthsimple? Check out open roles on our team today.
