How a tangled situation showed me i was using AI wrong

Here's how Prompt Driven Development started for me. It wasn't in some meeting room talking about AI, or born from a perfectly diagrammed whiteboard.

I got assigned on a new project at work, and although it wasn't technically complex, it turned out it would be near impossible to keep track of everything going on there. We had our own Jira boards, the client was split into multiple teams, and each of them had their own Jira board to keep track of everything.

Trying to get a unified view of bugs, dependencies or see the big picture across the whole project? Had to forget about it.

You couldn't assign someone to oversee all boards as there were too many, and it would be a nightmare to keep track of it. Plus, you'd waste someone's full schedule just for this task.

You can't give everyone access everywhere for obvious reasons like security, time, distractions, and pure confusion. We had all the data, all the tools, everything, it was just that none of it was actually... "talking."

So I had an idea, what if you can get all these Jira boards to communicate with one another, in an app that's separated from everything yet everyone can get access to. No security risks, no clutter, just the key information available at all times for everyone.

That's how I started building my first project. It's not a bloated Kanban board, it's no Jira either. Something simple, fast, lightweight. And it works!

Building it however... was not fast, lightweight nor simple.

Fired up GPT o1, debated the idea and concluded it can be done so I installed Cursor. At first it was just like the YouTube hype you see everywhere. Instant code, incredible momentum, and the best part? I was just prompting in english and witnessed Cursor create the right files with the right code for me.

Then the "vibe" wore off.

The further I got with developing my idea, the more I realised how far from the truth and brittle my app is. The AI's output became flaky, inconsistent, and the architecture I had in my mind when I started the development was becoming something alien with each new prompt.

So I started to learn more about prompt engineering. I thought that if I'd learn to talk to the AI better, I'll have its output improved. I created a new project, used much better prompts, and got further with the development than in my previous attempt.

In the end, it didn't quite work. Everything was still built on a house of cards, and it was clear that I wasn't engineering a system. I was stitching together code fragments spat out by reactive prompting. The tool had the functionality I intended it to have, but it was still nowhere near something to be proud of. I couldn't scale the app, I couldn't integrate anything properly, and it definitely couldn't be trusted in the long run.

This made me realise that maybe the AI wasn't the problem, or my prompts. My process though, or lack of it, was the real bottleneck.

What i desperately needed was a way to control and guide the incredible AI speed without throwing all engineering discipline out the window. I could still move fast, but I lacked structure.

That's how Prompt Driven Development (PDD) started to take shape. It was transforming from the vague "let's prompt and see what happens" loop to a structured, documentation-first methodology that turns AI into a powerful yet reliable assistant, not a chaotic liability.

• Don’t just prompt to build. Prompt to plan.

• Don’t just ask for a feature. Define it meticulously in documentation first.

• Don’t try to build Rome in a day from the top down. Build from the bottom up – one solid, isolated piece at a time.

I started debating the architecture with the AI before a single line of new code was written. I documented everything to the smallest detail:

• What each feature was supposed to do.

• What the actual user flows looked like (not just what I hoped they were).

• What the backend routes needed to be, precisely.

• What the frontend needed to show, and why.

• How those cards were actually going to sync with Jira without blowing up.

Then, I split that documentation into distinct layers:

• One markdown file for the data models.

• One for the API logic. Clear inputs, clear outputs.

• One for UI components. What they do, how they look, libraries and layouts.

• One for permissions. Who gets to touch what. (RBAC is the most fun to work on in my opinion)

• One for the third-party integrations. How the communication should take place with my app.

The markdown files weren't just some notes or thoughts scribbled on a whiteboard. They became the absolute source of truth for both me and the AI that was going to use them.

Once I had everything ready, i stopped reactive prompting, didn't need to find the right wording to explain what I wanted the AI to build. I could just give the AI real, actionable instructions:

"Begin development for the Cards feature. Focus on the Database model first. You must use and strictly follow the specifications in @cards-model.md and align everything with the project structure defined in @overview.md. Use and follow best practices for our tech stack..."

Everything changed afterwards. It wasn't perfect from the start, I still needed to improve my methods and documentation, which I did again and again once I was hitting bottlenecks.

But the output? It was so much better. It was finally following my instructions, developing the features exactly as I wanted and needed them to be developed.

My whole mess wasn't just about fixing one tool or workflow. I was stumbling in a new way of thinking - how to actually engineer software when you work with an AI that can write code faster than you can think or type.

AI is the rocket fuel, and Prompt-Driven Development is the guidance system. In the articles to come, I’m going to lay out the following:

• How to make AI part of your planning phase, not just a code monkey.

• How to break down any system into clear, documentable layers that AI can actually understand.

• How to craft prompts with surgical precision, so the AI builds what you need, not what it guesses.

• Why building bottom-up is your secret weapon against fragile, monolithic AI code.

• How to test, review, and actually trust the code your AI partner generates.

• How to apply this whether you're building an MVP, scaling a startup, or trying to bring sanity to team workflows.

This isn’t theory I read in a blog post or from YouTube videos. It's the theory I now use every single day to build fast – and build right.