There’s a version of the CTO role that’s purely strategic — roadmaps, vendor evaluations, board decks. I’ve never been that person. I’ve always believed that technical leaders need to stay close to the work. And right now, “the work” is being fundamentally reshaped by AI.

Over the past year, I’ve been building with AI tools daily. Not evaluating them from a distance, not reading analyst reports — actually using them to write code, design systems, and ship features. The experience has changed how I think about engineering leadership.

The productivity question is the wrong question

Every conversation about AI in engineering eventually lands on “how much more productive are your developers?” It’s the wrong framing. Productivity implies doing the same things faster. What’s actually happening is more interesting: the boundaries of what a single engineer can accomplish are expanding.

A senior engineer with strong AI tooling can now prototype a feature that previously required a frontend developer, a backend developer, and a designer to even get started. That doesn’t mean you need fewer people. It means the same team can take on problems they would have punted to “next quarter” indefinitely.

What changes for engineering leaders

If you lead an engineering organization, three things shift:

Hiring for judgment over output. When AI can generate code at scale, the differentiator becomes knowing what to build and recognizing when the generated output is wrong. I’m hiring for people who can evaluate, critique, and direct — not just produce.

Architecture matters more than ever. AI-generated code tends toward the obvious solution. That’s fine for CRUD endpoints and glue code. But system design, data modeling, and failure mode analysis still require deep human expertise. If anything, the gap between “works in a demo” and “works in production” has widened.

Learning velocity is the new moat. The teams that win aren’t the ones with the best AI tools. They’re the ones that learn fastest how to use those tools effectively within their specific domain. In fintech, that means understanding which problems AI accelerates (document processing, anomaly detection, developer tooling) and which ones it doesn’t (regulatory compliance, trust, customer relationships).

Staying technical as a leader

The biggest risk for engineering leaders right now is abstraction distance. If you’re managing AI adoption through slide decks and vendor calls, you’re going to make bad decisions. The tools are evolving too fast and the gap between marketing claims and actual capability is too wide.

My advice: pick a real project and build it with AI tools. Not a toy. Something with actual constraints — production data, real users, compliance requirements. You’ll learn more in a week of building than a month of evaluating.

That’s what this blog is about. Building things, learning from the process, and sharing what I find along the way.