In this edition of the newsletter, we dive into the AI-driven technical evolution of KOHO, a Canadian fintech company dedicated to helping over 2 million users build wealth through smarter spending and saving tools. KOHO’s VP of Technology, David Kormushoff, and Technical Product Manager, Katrina Stevenson, share how the company is methodically scaling AI developer productivity without compromising engineering culture. Their reflections capture a transition from chasing short-term speed to building a “balanced scorecard” where AI adoption, code quality, and developer experience are measured in tandem. Towards the end of our interview, we had just enough time for a rapid fire round!

Complementing KOHO’s story, we are introducing the AI Corner, where we highlight recent breakthroughs shaping the next wave of agentic AI along with what we, at Sagard, are reading; from the viral rise of the “OpenClaw” agent and its companion social network, Moltbook, to Anthropic’s “Claude Cowork” and Axiom’s landmark AI reasoning performance on the hardest math competition in the world, the Putnam Competition.

Measuring AI Developer ROI Without Breaking the Culture

KOHO has been methodically experimenting with AI across its engineering organization, with an emphasis on long-term impact rather than short-term hype. In this conversation, Katrina Stevenson, Technical Product Manager, and David “DK” Kormushoff, VP of Technology, share how KOHO thinks about developer productivity in an AI-enabled world. They discuss why traditional metrics still matter, what surprised them about adoption across experience levels, and how they addressed concerns around trust, quality, and security. The discussion offers a grounded perspective on treating AI not as a shortcut, but as a new way of working that requires patience, guardrails, and cultural alignment.

Here are our key takeaways from the interview:

1. Productivity Follows Enablement, Not the Other Way Around: AI productivity gains typically appear after teams adjust their workflows and build comfort with new tools. Early dips are often part of the learning curve, making experimentation and enablement essential before optimizing for output.
2. Measurement Requires Balance, Not New Metrics: Effective AI measurement combines existing productivity metrics with quality signals, developer experience, and usage data. This balanced approach helps teams understand whether AI adoption is driving meaningful, sustainable impact.
3. Adoption Is About Mindset, Not Seniority: AI adoption varies more by how individuals define their value than by experience level. Engineers focused on customer outcomes tend to adopt faster than those who equate value primarily with writing code.
4. Guardrails Enable Trust and Scale: Strong engineering fundamentals, tool standardization, and clear guardrails help address concerns around quality and security. These controls make it possible to scale AI adoption without compromising reliability or trust.

Let’s dive in.

To start us off, what are your roles at KOHO?

Katrina: I’m a technical product manager at KOHO, and my role focuses on building AI tooling and driving AI adoption across the company. That includes developer productivity, but also exploring how AI can support how teams work across different departments. A big part of my work is making sure we’re learning from the data while also listening closely to how people feel about these tools.

David: I’m the VP of Technology, reporting to our COO. I oversee what we think of as KOHO’s AI-native organizational transformation. Developer experience and productivity are important pieces, but the broader mission is about change management, helping teams across functions and seniority levels adapt to AI as a new operating model, not just a new tool.

Should throughput and speed be the primary metrics for AI-driven developer productivity?

David: Throughput and speed are useful, but they can be misleading if they’re treated as the main success criteria early on. AI changes how people work, and there’s almost always an adjustment period. If you optimize for productivity too quickly, you risk misreading what’s actually happening, because people may initially slow down as they learn new workflows. The more meaningful gains tend to show up after that adaptation phase.

Katrina: From a measurement standpoint, we landed on using familiar metrics rather than inventing new AI-specific ones. The reason is simple, you need a clear baseline to understand impact. We built a scorecard that combines impact metrics, quality signals, developer experience feedback, and AI usage data. That lets us see not just whether output changes, but how usage correlates with quality and satisfaction over time.

Did KOHO build its productivity dashboards in-house or rely on vendors?

Katrina: It’s a combination. We use Sigma as our dashboarding layer and feed it data from several sources, including our developer productivity tools and internal surveys. There were also a few AI-specific metrics we wanted that didn’t exist out of the box, so we set up custom data pipelines to capture those and bring them into the same view.

KOHO reported a 150% year-over-year increase in code output with fewer developers. When code abundance becomes the norm, how does it affect the roles of junior and senior engineers?

David: One important clarification is that quality didn’t decline, it stayed steady or improved. As AI reduces code production as a bottleneck, teams can spend more time on testing, documentation, and trying ideas earlier. Over time, that can actually improve the overall health of the codebase.

For senior engineers, AI often removes repetitive work they’ve been doing for years and creates more room for architecture, exploration, and proactive thinking. For junior engineers, AI can act as a fast feedback mechanism, a way to explore options, ask questions, and build context before bringing things to a human mentor. That tends to make mentoring interactions deeper and more efficient.

To get David’s full take on this topic, watch the following video snippet:

Breaking the fourth wall; This is a critical observation; one that is aligned with Anthropic’s CEO, Dario Amodei’s comments at the World Economic Forum at Davos earlier this year. He predicts that the industry might be just six to twelve months away from AI handling most of software development [source]. Additionally, the creator of Anthropic’s Claude Code, Boris Cherny, tweeted how Claude Code wrote 100% of the lines he contributed to Claude Code in the month of December’25 [tweet].

Back to the interview.

Do you see differences in AI adoption based on seniority?

David: We didn’t see a strong senior-versus-junior divide. The more meaningful difference is how individuals define their value. Engineers who see their impact in terms of outcomes, shipping value to customers, tend to adopt AI more easily. Engineers who see their value primarily in the act of writing code can struggle more at first, because AI challenges that mental model.

Katrina: When we looked at the data, it supported that view. There wasn’t a meaningful adoption gap tied to seniority level alone.

What assumptions did you make about people adopting AI that you later had to revisit?

Katrina: We initially assumed that because we hire for agency, most people would naturally figure AI out once the tools were available. That turned out to be true for a small group, but many people needed more support. We also learned that early messaging around “10x productivity” wasn’t realistic, there’s usually a learning curve before gains appear.

Creating space for conversations, addressing concerns directly, and running peer-led AI jam sessions helped people build confidence. Over time, teams started coming in with their own ideas rather than waiting to be told how to use the tools.

For a deeper dive on this topic, watch this video snippet:

David: I also underestimated how important joy and curiosity are in adoption. We talked a lot about productivity early on, but what really moved the needle was helping people have an “aha” moment, building something they’d been curious about or experimenting without pressure. I also learned how individual this transformation is. Even with shared tools and guardrails, people engage with AI in very personal ways.

Up until this point, what’s the strongest argument you’ve heard against adopting AI, and why wasn’t it enough to stop you?

David: The most common concern is that AI will degrade quality or erode trust, whether through hallucinations, maintainability issues, or security risks. I take those concerns seriously, but the fundamentals of good engineering don’t change. Strong testing, CI/CD, observability, code review, and security practices mattered before AI and matter even more now because output accelerates.

From a security perspective, knowing where data comes from and where it goes is essential. With the right infrastructure choices and safeguards, these risks can be managed. Avoiding AI entirely would suggest those risks are unsolvable, and I don’t believe that’s true.

Katrina: I often hear, “What if it’s wrong?” My perspective is that adoption doesn’t mean handing full control to AI. There’s a spectrum between human oversight and AI agency, and different problems sit at different points on that spectrum. When you’re deliberate about where AI fits and put guardrails in place, the objections become design constraints rather than reasons not to engage.

We had the time for a few rapid fire questions.

OpenAI Codex or Claude Opus 4.5?

David: Claude Opus 4.5.

Katrina: Same.

Cursor or Replit?

David: Replit.

Katrina: If I’m being honest, neither! I vastly prefer Lovable..

What advice would you give to companies or individuals still not adopting AI?

David: Start by playing. Don’t begin with the hardest problem you already know well. Use AI to explore something you’ve always been curious about but never had time to pursue. Let experimentation and enjoyment guide your learning.

Katrina: Create dedicated time, like a hackathon, where teams can experiment without the pressure of day-to-day work. Giving people permission to focus and play makes it much easier for adoption to take hold.

To learn more about the experiments that KOHO conducted to track developer productivity, take a look at this blog post.