I spent this week building a working project-management tool, and I didn't write the code for it. I want to be careful about what that sentence means, because "I used AI to build an app" has been said so many times it doesn't tell you anything anymore.
I didn't type a wish into a chatbot and ship whatever came back. I built this the way I'd run any project: I decided what it should do, wrote down the rules the work wasn't allowed to break, and checked the output at every stage. The only real difference is that the team doing the building was an AI agent instead of a room of engineers. I directed; it built.
Why a RAID register
The tool is deliberately ordinary. It's a RAID register, the log every project manager keeps to track Risks, Assumptions, Issues and Dependencies. Most teams run this in a spreadsheet that turns into a mess: no record of who changed what, ownership goes fuzzy, and every status update for leadership means rebuilding the thing by hand.
I picked something ordinary on purpose. The point of this wasn't a clever app. It was to prove a way of working. And a RAID log has a quality I wanted to show off: it only matters if you can trust its history.
How I built it, step by step
1. I wrote the rules before anything else. The first document wasn't code or even a feature list. It was a one-page "constitution" of non-negotiables: every change must be logged to a record that can't be erased, tests get written before the code they check, and keep the whole thing as simple as it can be. These are the rules the AI had to follow, no matter what I asked for later.
2. I wrote a plain-English spec. Next, a description of what the tool does and why, written so a non-technical colleague could read it and say "yes, that's right." No mention of databases or frameworks. Just the what and the why.
3. I turned that into a plan, then a task list. The plan is the "how" the spec deliberately left out: the approach, how the data is shaped, what screens exist. Then I broke that plan into a checklist of small, ordered steps, with the foundation and the locked history first because everything else sits on top of them.
4. I let the agent build, and reviewed at every gate. This is the part people get wrong. I didn't sit and watch it type. I let the AI agent work through the task list, and my job was to review at each handoff and push back when it strayed from the spec or tried to over-complicate something. Directing the work, not doing the typing.
5. The result is a working, auditable tool. You can add a risk, edit it, see its full history, filter the list, and print a status report for leadership. Every feature traces back to a numbered requirement, and the change history can't be altered. I even wrote a test that tries to tamper with the history and confirms it gets blocked.
The part that actually matters
Here's the thing I keep coming back to. Getting an AI to produce something is easy now. What's rare is being able to prove the something was built to an agreed spec, governed by rules you set up front, and traceable from a requirement all the way to the test that proves it works.
That traceability isn't busywork. In regulated worlds like finance, supply chain, and government, it's the difference between a tool you can put into production and a tool nobody will trust. It's also, frankly, the difference between a person who uses AI and a person who can be handed a delivery and trusted to govern it.
Want to build one yourself?
I wrote a full step-by-step guide that walks through doing this on your own machine, including where to slow down and review. If you want it, head to my LinkedIn post about this project and comment "RAID" — I'll send it over. Or just reach out through this site.
This is one piece of a longer build I'm doing in public. More to come.