I Haven't Written Code in 30 Years. Last Week I Built a Software Tool. Here's What That Tells Us About Program Management.

There's a moment in every program manager's career where you realize the job has quietly changed around you. I had one of those moments recently — and it came with an unexpected twist.

I built a working software tool. Not a spreadsheet. Not a PowerPoint. A real, functioning application. And I did it without writing a single meaningful line of code myself. Let me explain what I built, why it took me this long, and why it matters beyond my own small experiment.

A Little Context

I have spent the last 25 years managing projects and programs across some of the world's largest and most successful technology companies. Agentic AI. Internet Security. Data center infrastructure. Enterprise software. Multi-country deployments. Multi-million dollar programs for some of the biggest names in global IT outsourcing. I have sat in rooms with executives, navigated political complexity across cultures and time zones, and built delivery systems for organizations that had no idea how broken their processes were until someone mapped them out.

What I had never done — not seriously, not since the early 1990s — was write code.

That wasn't an accident. I'll be honest about something that I suspect many program managers will recognize: coding intimidated me. Despite being a deeply structured, systems designer and program manager, I always found the act of writing code mentally exhausting and frustrating in a way that very little else in my career has. I could design the system. I could specify it precisely. But the moment it became about syntax and debuggers and environments, I disengaged. I told myself it wasn't my job. And for 30 years, that was a reasonable position to hold.

It isn't anymore.

The Problem I Was Trying to Solve

I work in a product organization that has seen impressive growth over recent years. That success creates its own kind of operational complexity. In high-growth environments, teams often self-organize autonomously — but that autonomy can quietly produce inconsistency when the organization needs to scale. Over time, different teams develop different expectations of what a Program Manager is there to do, which makes consistent governance genuinely difficult.

One consequence of that showed up clearly in our quarterly planning cycle. Product managers were submitting four times as many feature requests per quarter than the organization was historically delivering. Engineering, quietly aware that the math didn't work, was understandably giving many of those requests little to no attention. Product managers felt ignored. Engineering felt overwhelmed before the quarter even started. Program Managers felt stuck in the middle. Nobody was wrong. The system just lacked a clear, visible signal of the mismatch between demand and velocity.

What I wanted was simple: a traffic light status report — Red, Amber, Green — that compared incoming demand against historical delivery velocity and surfaced that ratio in plain language before the frustration started. Not a blame tool. A transparency tool.

Where Cursor Came In

I had used AI writing tools before. I had not used an AI coding tool. I opened Cursor — an AI-assisted development environment — with a clear specification of what I needed, and I started describing the problem in plain language. The feature lifecycle states. The quarterly cadence. The ratio logic. The three status conditions and the firm but non-confrontation language I wanted attached to each one.

What came back was working code. Not perfect on the first pass — there was iteration, clarification, and a few moments where I had to re-explain what I meant more precisely. But the direction of travel was unmistakable: the more clearly I described the system, the better the output. The AI didn't need me to know how to code. It needed me to know what I was building and why.

Within a few hours, I had a functioning status report tool. The thing I had been putting off — partly because of genuine technical inertia, partly because some part of me still associated "building software" with the frustrating, syntax-heavy experience of three decades ago — turned out to be mostly a specification problem. One that I was, it turns out, well equipped to solve.

What This Actually Demonstrates

It would be easy to read this as a story about how AI lowers the barrier to coding. That is true, but it's the less interesting insight.

The more important observation is about what made it work. It wasn't the AI tool itself. It was the specification. I knew the problem intimately. I had already worked through the mathematical logic — demand load ratio, threshold definitions, the right language for each status level and the risk they represented if not addressed. I understood the audience, the political sensitivity of the framing, and what outcome I needed the tool to produce. I came to the AI with a complete mental model of the system.

That is program management. That is exactly what we do.

The AI didn't replace the thinking. It replaced the part of the process that I previously couldn't execute alone — the translation of a clear specification into working software.

The Reassuring Part

If you're a program manager reading this and wondering whether AI is going to make your role obsolete, I'd suggest the opposite framing. What this experience demonstrated is that the core of what experienced program managers do — systems thinking, precise problem definition, stakeholder-aware communication, lifecycle design, conceptualizing future outcomes — is exactly what AI-assisted development needs more of, not less.

The developers I work with are already using these tools. The question is whether program management shows up with enough clarity and structural thinking to make those tools more effective, or whether we stay on the sideline watching.

I chose to stop watching. And the thing that finally got me there was realizing that the part of software development that always defeated me — the syntax, the environments, the endless debugging — was no longer the bottleneck. The bottleneck is now what it has always been in every project I've ever run: knowing precisely what outcome you're trying to achieve, and why.

A Reframe Worth Considering

We have spent years defining program management as the discipline that coordinates work across complex systems. I think that definition is due for an update. In an AI-assisted organization, the program manager's role is increasingly about owning the clarity of the system itself — the definitions, the thresholds, the lifecycle states, the signals that tell an organization whether it is on track or not. Whether that system is executed by humans, by AI tools, or by some combination of both is becoming a secondary question.

The primary question is whether the system is designed intelligently enough to be executed at all.

That turns out to be a question program manager are very well positioned to answer. We just have to decide to step into it.