← Blog

16 June 2026

I'm Not a Developer. I Shipped Anyway.

Two weeks ago, I didn't know what a terminal was. By the end of the evening, I had a live website — no code, no developer, no waiting. This is what actually made it work.

Two weeks before any of this, I was back home in Pengkalan Balak for the holidays. My brother — also a doctor — was on the sofa across from me, half-asleep, doing some of his own work on his laptop. Out of nowhere he asked if I used Claude.

I told him I'd just finished a Google AI certification and that it had genuinely opened my eyes. He laughed. Then he told me that what I'd just learned was, by his estimate, fairly basic compared to what Claude could do in something called a terminal.

I had never heard the word terminal in my life. I have spent years managing technical teams, sitting in technical reviews, signing off on technical decisions — and somehow never once needed to know what a terminal was. Apparently that was about to change.

He sent me a YouTube video — something about AI as a "second brain," a talk by a man named Andrej Karpathy whose name I mangled for weeks. He handed me my first CLAUDE.md file. He got me a seven-day Pro trial. That was the entire onboarding. A brother, half-asleep on a sofa, mildly amused that I didn't know what a terminal was.

I did not expect that conversation to end with me building a website. But two weeks later, on the evening of 7 June 2026, that is exactly what happened — and for the first two hours of it, I had nothing to show for it.

I'd opened a blank screen with no code, no developer, and no template I'd paid for. I typed something in. It came back wrong. I tried again. Still wrong — not broken, just not what I meant, which is somehow worse, because it means the problem isn't the tool. It's that I haven't said what I actually want clearly enough for anyone, human or otherwise, to act on it.

By around nine that evening I had a live website. A working database, an admin panel, and a page laying out a framework I'd been turning over in my head for almost a decade, finally written down somewhere other than my own thoughts. I have never written a single line of code in my life.

But that's not really the story. The story is the two hours before it, where I was getting it wrong for a reason I didn't see until much later.


Here is what those two hours actually looked like, because I think the failure is more useful than the win.

I opened Claude and started typing the way most people probably do the first time: short instructions, half-formed, assuming it would fill in the gaps the way a competent person might. Build me a website. Make it look professional. It produced something. It was wrong — not in an obvious way, just generically wrong, the way anything is wrong when you haven't actually told anyone what you want.

I know what a database is. I know what an API does. I have sat through enough technical reviews and vendor meetings to follow along. None of that was the problem. The problem was that I was treating this like a vending machine — put in a request, get out a result — instead of treating it like the one thing I have actually been trained to do for ten years.

So I stopped. I went back to scope. What does this site need to do? What pages? What does someone see when they land on it? I wrote it out in plain language, the way I'd write a brief for a sponsor who needs to understand intent before they'll approve a budget.


Once I had that written down, the rest moved fast. Not vague prompts anymore — full written briefs. Context, constraint, what I needed, how I'd know it was done. Typed out the same way I'd type a brief for a new team member on their first day.

And it built. Not perfectly the first time. But the same way a good engineer responds to a clear brief — producing something real, asking when it needed to, correcting when I told it to. By the end of the night I had a live site, a connected database, an admin panel I could run without touching code, and the first version of an idea I'd been carrying around for nearly ten years finally sitting in public, in writing, instead of just in my head. I pushed it live and went to bed slightly stunned.


I've spent the weeks since trying to work out why it worked, because "AI is powerful" is true and also useless. A bulldozer is powerful. Hand one to someone who has never operated heavy machinery and you do not get a building.

What actually happened is that the skill I'd spent a decade building turned out to be exactly the skill AI needs to perform.

AI doesn't struggle with execution. It struggles with ambiguity. Vague instruction, vague result. Structured brief — context, outcome, constraint — and it gives you something you can use.

I'd been writing briefs like that since long before AI existed. I just never noticed it was the same skill, the same way I never noticed, sitting in an Additional Mathematics class in Melaka, that differentiation and progressions would mean anything to me again. They went quiet for years. Then I was twenty-six, on a manufacturing floor, looking at a defect rate nobody could explain, and someone handed me Minitab — and all of it was still there, waiting. You don't always see the use of a thing while you're learning it. You only see it when the moment that needs it finally shows up.

This evening was that, again. The moment showed up. The brief was already in me.

This, in hindsight, is the entire premise of what I've been building under KaizenPMAI. PM gives you the structure to define what you want clearly enough that someone else — human or AI — can execute it. Lean Six Sigma gives you the discipline to strip the waste out of that process. AI compresses the distance between brief and output from weeks to hours.

I did not ship a website that evening because AI is magic. I shipped it because I knew how to write a brief.


I want to be honest about something, because the triumphant version of this story does a disservice to anyone who tries to repeat it and finds it harder than it sounds.

It was not one evening of smooth sailing. There were moments the output was wrong and I didn't immediately know why. There were decisions about how the database should be structured that required me to understand the problem well enough to explain it — and sometimes I didn't yet, and had to stop and think before I could write the next instruction.

AI did not remove the thinking. It removed the waiting.

That's the whole distinction. The hard part of building something was never the building. It was the clarity — knowing what you want well enough to describe it to someone who will take you exactly at your word. AI takes you at your word more literally than any junior hire I've ever managed.

The executives nodding along in AI briefings are still waiting for someone to tell them what to do with it. The people who'll benefit most are not the ones who know the most about AI. They're the ones who already know how to write the brief. They just haven't been asked to write one for a machine yet.


Here is the part I have not said out loud until now. The framework that ended up on that site had been sitting in my head for almost a decade — half-formed, never written down anywhere I'd have to stand behind it. Having a place to finally put it in public, not borrowed, not filtered through someone else's platform, just mine, is something I had wanted for a long time. I just never had a way to build it that didn't involve waiting on someone else's calendar, or money I didn't want to spend testing an idea I wasn't sure was worth testing.

Two weeks before that evening, I did not know what a terminal was. Two weeks later, the thing I had wanted for years was live, and I had built it myself.

That is the part I actually want people to sit with. Not the website. The speed. If you are willing to take action, the gap between "I have an idea" and "it exists" is no longer measured in months or budgets. It is measured in how clearly you can say what you want.

I keep doing the same small calculation in my head, the way you'd extrapolate a trend line from two data points because it's the only honest thing to do with two data points. Two weeks ago, terminal meant nothing to me. Two weeks later, a website existed that hadn't existed before. I don't know what the next stretch looks like. I'm not going to pretend I do. But I know what the slope looks like so far, and I'm curious enough to keep going and find out.


I almost left this next part out, because it felt like a separate idea rather than the point of the post. It isn't. It's the whole reason I'm telling you this story at all.

I went back through what I'd actually written that evening and pulled it apart, the way you'd reverse-engineer a process map after the fact. Scope. Context. Constraint. Definition of done. Five fields, more or less — the same five that show up in nearly every brief I've written for a sponsor, a vendor, or a developer across a decade of doing this for a living.

So I built a tool that asks for those five fields and turns them into a structured prompt you hand to Copilot or ChatGPT — the same shape of brief that got me a live website in one evening, minus the part where you have to invent it from scratch with no one to ask.

It's free. It's live now at kaizenpmai.my/brief.

If you've spent more than three years in project management or process improvement, you already have this skill. You've been writing briefs for people your whole career. Try writing one for a machine, and see what comes back.


— Haqeem Zulkiflee PfMP | PgMP | PMP | LSSMBB Built a career that had no template. Still building.