Why Your CTO Should Be Building With AI, Not Just Talking About It

The Conference Circuit Problem

I’ve been in a lot of leadership meetings lately where someone asks “What’s our AI strategy?” and the room goes quiet. Then someone mentions they saw a great talk at a conference. Someone else brings up a whitepaper. The CTO nods thoughtfully and says they’re “exploring the space.”

Here’s what I’m noticing: a lot of technical leaders are treating AI like it’s still 2018. Like it’s a research topic, not a production tool. Like the right move is to watch, wait, and strategize before doing anything.

Meanwhile, the gap between companies that are building with AI and companies that are talking about AI is getting wider every week.

What Building Actually Looks Like

When I say “building with AI,” I don’t mean deploying a chatbot on your website or adding a “AI-powered” label to your marketing site. I mean integrating AI into your actual operations in ways that create leverage.

At Jetpack Labs, we run automated standups. Claude processes our daily updates, identifies blockers, and surfaces what needs attention. Our sales pipeline has AI-generated follow-ups that get reviewed and sent by humans. Meeting notes get processed into action items and documentation automatically. Our SR&ED claims write themselves from commit histories and Slack conversations.

None of this is bleeding edge. It’s not research. It’s production systems that have been running for months, saving hours every week, and getting better as we refine the prompts and workflows.

The difference between this and “having an AI strategy” is that one creates value today and the other creates PowerPoint decks.

Why CTOs Aren’t Building

There are a few patterns I see when technical leaders avoid getting hands-on with AI.

They’re waiting for it to stabilize. The tools are changing fast, so the thinking goes, why build something today that might be obsolete in six months? This makes sense for infrastructure decisions. It makes no sense for AI workflows. You learn by building. Waiting means you’re falling behind people who are learning right now.

They’re delegating it. They assign AI experimentation to a junior developer or a product manager and ask for a report back. But AI integration isn’t a side project. It’s a leadership decision about how your team operates. If you’re not in the code, you’re not learning fast enough to make good calls.

They don’t see it as their job. They’re thinking about architecture, hiring, and roadmaps. AI feels like a distraction from “real” technical leadership. But AI is a leverage multiplier. If you’re not thinking about how to use it to make your team 2x more effective, you’re leaving massive value on the table.

They’re overthinking it. They want the perfect architecture, the right vendor, the complete strategy before they start. But AI workflows are iterative. You build a rough version, see where it breaks, fix it, and improve it. You can’t design this stuff in a vacuum.

The Hands-On Advantage

Here’s what changes when you’re actually building with AI instead of just thinking about it.

You learn what works and what doesn’t. AI is weirdly specific about what it’s good at. It’s incredible at pattern matching, summarization, and generating structured output from unstructured input. It’s terrible at math, dates, and anything requiring perfect recall. You only learn this by using it.

You understand the cost model. Running Claude API calls for automated workflows costs real money, but way less than you’d think for most use cases. You only know if something is economically viable by shipping it and watching the bill.

You see the cultural shift. Your team watches what you’re building and starts experimenting themselves. AI adoption isn’t a top-down mandate. It’s a culture thing. If the technical leader is building with it, everyone else will follow.

You spot the high-leverage opportunities. When you’re hands-on, you see the repetitive work that’s eating your team’s time. You notice where information is getting lost between tools. You identify the workflows that could run themselves with the right prompts. You can’t see this from a conference talk.

You get faster at integrating new capabilities. AI tools are evolving every month. If you’re already building production systems, you can fold in new capabilities as they ship. If you’re still planning, you’re always six months behind.

What This Actually Costs

Let’s be direct about the investment.

Building AI workflows takes time. Not huge blocks of time, but consistent experimentation. I spend maybe 3-5 hours a week refining our AI systems, testing new prompts, and automating something new. That’s time I used to spend on status updates, documentation, and manual process management.

It takes technical comfort. You don’t need to be a machine learning expert. You need to be comfortable writing scripts, calling APIs, and debugging when things don’t work. If you’re a CTO who hasn’t written code in years, this is going to feel uncomfortable. Do it anyway.

It takes willingness to look stupid. Your first AI workflows will be rough. They’ll have edge cases you didn’t think about. They’ll generate output that’s 80% great and 20% weird. You’ll iterate. That’s fine. Better to ship something imperfect and learn than to plan something perfect that never ships.

The Risk of Not Building

Here’s what happens if you’re a technical leader who keeps treating AI as a future concern instead of a present tool.

Your team moves slower than competitors who are leveraging AI. Not 10% slower. Meaningfully slower. The gap compounds over months.

You lose credibility with your team. Developers are experimenting with AI whether you are or not. If you’re not fluent in how these tools work, you’re going to make bad calls about what’s realistic and what’s not.

You miss the architectural implications. AI changes what you should build and what you should buy. If you’re not using it, you won’t see where it slots into your product or where it replaces infrastructure you were about to build.

You get stuck in advisory mode. Technical leadership isn’t about giving advice from a distance. It’s about making calls based on hands-on context. If you’re not building, you’re guessing.

Where to Start

If you’re reading this and thinking “yeah, I should probably be doing more with AI,” here’s where I’d start.

Pick one repetitive workflow in your team and automate it with AI. Standup summaries. Meeting notes. Code review prep. Sprint planning research. Don’t overthink it. Just build the first version this week.

Use it yourself before rolling it out. See where it breaks. Fix it. Get it to the point where you’d trust it without checking every output.

Then ship it to your team and watch how they use it. You’ll learn more from observing real usage than from any planning session.

Repeat. Find the next workflow. Build it. Ship it. Iterate.

After three or four of these, you’ll have enough hands-on context to make real strategic calls about AI. You’ll know what’s realistic, what’s expensive, and where the leverage is.

The New Normal

Five years ago, a good CTO needed to understand cloud infrastructure, API design, and how to scale a database. Those skills are still important, but they’re table stakes now.

The new differentiator is understanding how to use AI to create operational leverage. Not in theory. In practice.

The CTOs who are building with AI right now are learning faster than the ones who are still strategizing. They’re shipping more with smaller teams. They’re solving problems that used to require expensive integrations or manual labor.

And they’re not waiting for permission or perfect information. They’re just building, learning, and iterating.

If you’re a technical leader and you’re not doing this yet, the gap is going to get uncomfortable fast.

Start this week.