Originally published on LinkedIn – Read the original post
I built an iOS app. Me, a CIO with almost 36 years in IT, a full-time job running technology for one of the largest prosecutorial offices in the country, and a development background that hadn’t been seriously exercised in decades. I built a working, functional iOS app. And it changed how I think about the future of technology leadership.
It started simply enough. LA County has complex telework policies, tracking work modes, RDOs, PTO, and holidays, and I needed something to manage it that didn’t exist. So I decided to build it myself. What started as solving a personal problem became something more: a deliberate experiment in whether a non-developer could ship real software in the age of AI. Spoiler: you can.
The moment everything shifted
I came into this with some relevant history, though not recent history. Early in my career I wrote COBOL, batch and CICS, working with IMS databases and flat files. I programmed in Easel back when 4GLs were a genuinely new idea, and dabbled in dBase along the way. But that was a long time ago. The languages, frameworks, and tools that developers use today barely resemble what I grew up on. So while I understood the concepts, I was in no way a practicing developer walking into this project.
And yet I still didn’t expect what happened: I stopped caring about learning Swift almost entirely. Not because it was too hard, but because I didn’t need to. Somewhere along the way, the moment I saw the app actually running on my phone doing exactly what I’d envisioned, something clicked. After 36 years in IT, I finally didn’t need to know the implementation details. I needed to know what I wanted. That’s a fundamentally different relationship with technology than even experienced technologists are used to.
Claude is a junior-to-intermediate developer
Here’s the most useful mental model I’ve found: Claude is like a talented junior-to-intermediate programmer. Technically capable, fast, eager. But without strong direction, vision, and leadership, the output will drift. It will solve the wrong problem elegantly. It will make technically correct decisions that miss the point entirely.
What I brought to this project wasn’t code. It was everything else: deep domain knowledge of the problem, judgment about what users actually needed, the vision of what the app should feel and behave like, and the ability to recognize when Claude was wrong. That last one matters more than people realize. AI-generated code isn’t always right. Knowing when to push back, redirect, or scrap and restart requires exactly the kind of experience and judgment that technology leaders spend careers developing.
In other words: the skills that make a great CIO also make a great AI development partner.
The skill you didn’t know you already had
Here’s what surprised me most: working with Claude felt familiar. Not because I remembered my COBOL days, but because it’s exactly how I’ve operated as a CIO for years. I don’t know everything about security, or operations, or application development. Nobody does. There’s simply too much IT to know everything. What I do know is how to lead people who have that expertise. How to set a clear direction. How to ask the right questions, evaluate the answers, and make decisions with incomplete information.
That’s the job. And it turns out, it’s also exactly the skill set you need to be effective with AI-assisted development. If you’ve spent years learning to lead without knowing every detail, trusting your team while still holding them accountable to the vision, you’re already prepared for this. You just haven’t tried it yet.
What this means for your organization
Every technology leader should understand this shift from experience, not just from briefings. Because your developers are already using these tools. Your product teams will be soon. And the decisions that follow, how to structure teams, where to invest, what skills to hire for, are leadership decisions, not technical ones.
My honest take on what’s coming for development teams: developers who are open-minded and willing to adapt will be fine, more than fine. The role is evolving, not disappearing. But you need less of a pure coder and more of a developer who understands programming concepts well enough to direct AI effectively, evaluate its output critically, and bring genuine design thinking to the table.
Developers who want to keep their heads down and write code the same way they always have? They should be paying attention.
The bigger shift
The most profound change isn’t that AI can write code. It’s that domain expertise is now a development superpower. The person who understands a problem most deeply, who knows the edge cases, the user needs, the institutional context, is now the most valuable person in the room when building a solution.
That used to be the business analyst handing requirements to a developer. Now it can be the person who builds it.
I’m not suggesting every executive should ship an app. But I am suggesting that if you lead a technology organization and you haven’t experienced AI-assisted development firsthand, you’re making decisions about a world you haven’t seen yet.
Go build something. Even something small. The clarity it gives you is worth more than any briefing document I’ve ever read.
This article is Part 1 of a three-part series, Building with Claude. Read Part 2 and Part 3.