Politiques/opinions
|
October 1, 2026

You can see the interview on YouTube HERE.
Diederik van Liere leads engineering at Wealthsimple, Canada’s largest fintech innovator, which serves more than four million customers across managed investing, self-directed and crypto trading, derivatives, a growing suite of banking products and more. Over the past three years, his roughly 600-person engineering organization has gone through two distinct waves of AI adoption: an early period of experimentation that produced modest productivity gains, followed by a much larger jump once the underlying models became capable of autonomous work. In this conversation, Diederik walks through that journey, how Wealthsimple has rebuilt code review and verification to handle a doubling of merged pull requests, how AI is spreading well beyond the engineering org through internal tools like MCP Locker, Compass, and Magic, and what he believes the role of the software engineer looks like as AI becomes embedded in every layer of the company. For senior technology and business leaders watching how a systemically important, regulated fintech is operationalizing AI at scale, his answers offer a concrete look at what is working, what still needs to be solved, and where he thinks the puck is going.
Here are our key takeaways from the interview:
Let’s dive in.
Could you introduce what Wealthsimple does and share, at a high level, how you’ve been leveraging AI?
Diederik: Wealthsimple is Canada’s largest fintech innovator, serving more than four million clients. We started as a managed investing provider, what people used to call a robo-advisor, and have since expanded into self-directed trading, crypto, increasingly advanced derivatives, options and futures, and more recently a full set of banking features including chequing accounts and credit cards. The way we think about our products is that we want to empower people to make the right financial decisions for themselves and reach their own version of financial independence, through low fees and products that give people confidence they’re doing the right thing at the right moment. We’re twelve years old now, and the trust our four million customers place in us is something we take seriously as we keep growing.
On the AI side, I’ll focus specifically on the software development lifecycle, since I lead the engineering group. That journey started almost three years ago, right around when ChatGPT launched. We were quick to see this as a transformational technology rather than just a new tool, and we encouraged our people to experiment, learn, and prototype for the first year and a half or so. Then, around November of last year, the frontier models crossed an effectiveness threshold. Before that, you could see the potential of large language models, but you needed constant handholding to get useful output. After that point, you could hand the models a task and trust them to complete it with real autonomy, which changed everything about how we approached the work.
You mentioned Claude Code. Is that the only tool your engineers have access to, or is it a mixed stack that includes other IDEs and open-source options?
Diederik: Our thinking here has evolved quickly, and honestly nine months already feels like a long time given how fast things move. In January we standardized on Claude Code and gave all 600 engineers access through a one-day installation event, and that was the default for a few months. Since then, we’ve moved to a portfolio approach where people can choose between the Anthropic models, OpenAI’s models, or the best open-source options, since preferences shift and different models lead at different times. We’re also becoming more deliberate about routing prompts to the right model rather than defaulting to the most powerful one every time, since token cost and efficiency matter more as usage scales.
On the harness side, Claude Code and an open-source-based harness called Pi make up the large majority of usage. We intentionally limit the number of harnesses in use, mainly because it gives us better observability into what people are doing and lets us collect consistent telemetry on token usage. The more harnesses you support, the harder it becomes to standardize good engineering practices or make sense of the data.
Wealthsimple reportedly saw an initial productivity gain that plateaued before jumping. What caused the plateau, and what changed to produce that second jump?
Diederik: That arc played out over 2025. About a year and a half ago we rolled out Cursor company-wide, which got us a productivity boost, and we were pleased with that at the time. But the models and the harness at that stage weren’t capable of fully autonomous work, which is why progress plateaued. The next unlock came when we switched to Claude Code and the Anthropic models about ten months later. We’d done an installation event for Cursor in March of last year, then made a complete shift to Claude Code, which has been our default ever since. I’d attribute the breakthrough directly to the leap in frontier model capability during that window.
You mentioned merged PRs doubled from around 11,000 to 22,000. How do you manage that volume, especially since code review tends to become the bottleneck once generation gets easier?
Diederik: That’s exactly the right question, and it requires a real strategy rather than just asking people to review faster. If you double PR volume, people simply cannot keep up doing code review the way they always have, so we adopted more formal verification methods to make sure generated code is actually correct. We did two specific things. First, we introduced an AI review agent, typically a different model than the one that generated the code, that reviews every PR before a human ever sees it, catching both minor and serious issues early. Second, we broadened and deepened our verification layer. We already had continuous integration and strong test coverage, but we’ve since added many more deterministic checks, somewhere between fifteen and forty per repository on average, excluding full end-to-end test suites, that a PR has to pass before it even reaches AI review.
Those two changes have helped, but I think we still have more work to do. My belief is that we’ll need new ways to understand what a piece of code is doing without necessarily reading it line by line, since reading gives you solid understanding but makes it hard to relate any single PR back to the overall architecture and its edge cases. One example is an internal tool we built called WS Flow, which visually shows every user journey through the app and highlights what changes between the current production version and a new PR. I could see us extending that toward automatically generated screen-capture sessions that show how a user flow changes with a given PR, since as volume keeps growing, we’ll need better ways to see what’s changing that don’t depend entirely on reading code.
Do you see a future where low-risk PRs merge without human review while more complex or sensitive ones stay with people? How soon might that happen?
Diederik: We’re actively experimenting with that, and my sense is it could happen sooner than people expect. Right now we’re working on ways to assess how complex and risky a given PR is, since treating every PR with equal weight made sense when volume was lower but doesn’t scale in this new environment. The goal is a system that can distinguish technically trivial PRs from complex ones, so that changes passing the full verification layer and CI/CD checks can be treated with a higher degree of automated confidence.
For us, the added challenge is doing this in a way that stays compliant with regulatory requirements like SOC 2. I see real opportunity to innovate here, building approaches that maintain a strong audit trail of who or what initiated a given change and why, paired with deterministic controls that help ensure the code is secure, correct, and doesn’t introduce unintended consequences. I’d expect to see this happen at some scale within Wealthsimple this year, and I think it could become increasingly important across the industry next year, since a company that keeps a human in every loop risks hitting a hard ceiling on throughput that AI-native competitors won’t face.
Wealthsimple has been growing quickly, recently crossing $150 billion in assets under administration. What do you think about AI’s role in sustaining that trajectory relative to engineering headcount?
Diederik: It’s a question on a lot of people’s minds, and I’ll be honest that the jury is still somewhat out. Marc Andreessen wrote years ago that software is eating the world, and I think you could write a version of that essay today about AI eating the world. If that holds, engineers might end up eating the organization in a sense, because the core skill of a software engineer, taking a business problem and solving it with code, becomes applicable to far more problems than before. My own group might stay roughly stable in size, but other functions across the company may end up hiring more engineers as the skillset becomes more broadly useful, so at a societal level I wouldn’t assume the total number of engineers goes down. When the cost of generating code falls this much, the amount of code running in the world is likely to keep growing, and you still need people who understand it well enough to troubleshoot and fix it.
That said, the role itself is shifting. I expect engineers to move toward something closer to civil engineers, providing strong guarantees that code works as intended, the same way a civil engineer signs off on a building because the cost of failure is high. I think this points to a renewed focus within computer science on formal validation, and it may open the door for people with different backgrounds, mathematicians and people with strong machine learning training, to become especially valuable in a world built around AI agents, since we’ll continue to need people who can verify systems are doing what they’re supposed to do.
Beyond the engineering side, could you share how AI is showing up in the product itself?
Diederik: One project we’re excited about, though it’s still early, is what we call our AI foundation model. We took our customer behavioral data and used it to fine-tune an open-source model, so that you can now ask questions about a specific customer and get advice tailored to that person. It’s early days, but I believe the software we build going forward is going to be more personal and more customized, and AI makes that far more achievable. For a lot of people, financial decisions are difficult or even intimidating, since it’s their own hard-earned money and they don’t always feel confident making the right call. If we can give people more tailored, higher-quality advice based on who they are and what they’re trying to achieve, that would be a meaningful unlock, and that foundation model is the base layer we’re building toward that kind of client-facing feature.
Are functions beyond engineering and product also adopting AI tools at Wealthsimple?
Diederik: Absolutely, and we’re seeing this show up in a few concrete ways. We’ve given everyone at Wealthsimple access to Claude Desktop, and we’ve built something called MCP Locker, which is a gateway to many MCP servers that any employee can connect to with their company account, with us managing the security lifecycle centrally. With that many servers connected, an employee’s question can reach almost any context across the company, and I think of it as building the queryable company. People spend a lot of time just figuring out where information lives or whether it’s current, and I’d like to see essentially every vendor and every place we store data exposed through an MCP server so an agent can search across all of it based on someone’s own permissions. The third example is Compass, our Slack-based agent that we launched a few months ago. We have a public Slack channel called Building in Public where anyone can interact with Compass, whether that’s submitting small bug fixes, asking questions of the data warehouse about business performance, or asking how a particular system works. We encourage people to do this in public so others can learn by watching, which also makes the whole thing feel less intimidating.
As non-engineers start experimenting with these tools, some will inevitably build their own small applications that might duplicate existing software or eventually need engineering support. How do you think about managing that?
Diederik: We approach this a bit differently through a fourth tool we call Magic, which lets people using AI build simple, often interactive websites for their own use cases. I think we’re heading toward a new category of software that is highly personal but also disposable, an extension of the collapsing cost of AI-generated code. When writing a tool or a simple website for a specific task becomes this cheap, it might only need to exist for a few weeks before you delete it. These mini tools can also connect into MCP Locker to get the data they need, so people are building their own dashboards without needing to know SQL or wait on a data analyst.
Because MCP is effectively the gateway to the data, I’m not particularly worried about duplication across these small tools as long as the underlying data itself isn’t being duplicated. We auto-delete anything unused after 60 days, so the system cleans itself up. I’d compare it to fast fashion: you build the software, use it for a while, and then let it go, and I expect we’ll see more of that pattern going forward.
When you look at engineers who are running fastest with AI versus those who are more hesitant, do you notice patterns in what separates them?
Diederik: I wouldn’t claim to see deep psychological patterns, but in general, the people thriving in this environment tend to be high agency, curious, and genuinely enjoy learning and experimenting. Those are the three traits I’ve consistently seen among the people who’ve become dramatically more productive in this AI-driven environment. My view is that AI is here to stay as an incredibly powerful, even transformational technology, so we try to give our people access to best-in-class frontier models and actively encourage them to learn and experiment with them. In effect, we’re giving people a way to future-proof themselves: working with the best available tools, retraining and reskilling along the way, and preparing for whatever comes next, since this technology isn’t going away. The real question is how you choose to relate to it and make effective use of it, and we’re trying to create the right conditions and encouragement to help everyone get through that learning curve.
For students today who are uncertain whether to major in software or computer science given how fast things are changing, what advice would you give them?
Diederik: It’s a fair question. If software, and now AI, is eating the world the way I described earlier, there’s only going to be more code in the world, so I don’t think the need for people with a deep understanding of computer science goes away. What I do think changes is that formal verification, the ability to prove code is working as intended, becomes more important, which could mean more emphasis on lower-level computer science, compilers, and system design and architecture. That’s one plausible path, though I don’t have a crystal ball here. Beyond that, businesses will always need people who are exceptional problem solvers, since that’s fundamentally what a business does: solving problems for people in a form they’re willing to pay for. Becoming a genuine subject matter expert in nearly any domain is likely to remain valuable.
One concern I do have, and it applies regardless of what someone studies, is a kind of cognitive surrender, where people lose real understanding of how something works because they only glance at a model’s output, decide it looks fine, and sign off on it. If that becomes a habit during your studies, you risk losing fundamental knowledge. My advice would be to resist that pattern and make sure you’re still genuinely learning, to the point where you could do the work yourself without the model if you had to. If you can only do something with the model’s help, that may be a sign you don’t fully understand what you’re actually trying to do.
As always, we had some time for the rapid-fire round!
Closed source or open source?
Diederik: Open source
Terrestrial data centers or data centers in space?
Diederik: Terrestrial data centers
Verstappen or Hamilton?
Diederik: Verstappen! (hands down)
Dutch directness or Canadian politeness, for building a technology team?
Diederik: Dutch directness