Defining the Work: Requirement Prompting for AI Development

I recently discussed how core parts of our jobs are more or less the same, regardless the advances in languages and tools. In software engineering, our jobs are to take requirements and turn them into desired outcomes using some kind of machine code. Whether you're writing low-level assembly or using plain English, the outcome is software that (more or less) does what you want it to.

Moving to AI-generated code requires us to use some old tools in new ways.

Preface: When it comes to models, YMMV. Some models are are more or less capable than others, which will affect how well this works. Frontier coding agents will generally do fine, but you might take pause with local models on modest hardware. Adjust for your use case. With that out of the way, I'll assume you're using models capable of extended context and reasoning.

Start With Requirements: PRDs

PRDs - the Product Requirement Document. This is the high-level roadmap for work to be done.

Go ahead, let out a sigh of exasperation: ugh - I just want to get started already. Do I need to write this all out first? I get it - as engineers we often like to start writing with a vague idea and figure it out as we go. You know - the vibes.

Let's talk about it. I know you're a good engineer, and you've had your fair share of issues and mishaps between one person's vision and another's execution. What goes wrong?

Communication.

Short of mind reading, the best way to communicate details to a language model is through the prompt and adding necessary information into its context window. The clearer we are, the better chance it will understand our intent, system requirements, constraints, and desired outcomes.

So what do we do? Because models need explicit instructions, we document it in prompt documents, giving the model the information it needs to complete the task. Some call these "PRPs" - Product Requirement Prompts - which are essentially PRDs, but written for LLMs as prompts. Like the system prompts file that some tools use, these become the documents your AI coding agent will use.

Process

I won't go over specific frameworks or methodologies, as these evolve rapidly, but I can share more about the process and the frameworks we can use to build and train our own mental models around this subject.

Give the agent the project overview, ground rules, and important guidance for operating within your project. Think of this like the README.md, but for the agent. Do you want to focus on modularity, TDD, and KISS? Tell it.
Plan first - add a prompt that describes how it should plan out a feature based on your inputs. ideally, the agent is using this as a guide to creat the actual PRP. You'll want to add relevant links to documentation and other context, code samples, strategies, references to the ground rules, and the PRP format you want to see. Run it - the agent does the heavy lifting.
With a generated PRP document: This is where you come in - review it. Put your product and engineering hats on and look through the generated plan. Make edits as you see fit.
Let it rip, using the generated PRP as the document the coding agent uses to complete tasks. Review, Run, and iterate as needed.

The beauty in this approach is that it can be as complex or simple as you want it, though it takes some practice and refining to find the sweet spot. I mean, isn't that true for anything we do in our work? Also, don't stop at coding - this type of approach can have much broader applications to other tasks in work and daily life.

Take this as an opportunity to grow and expand your skills using tools in new ways. You may find that with the right capable models and agents, it works better for you than chat-style development, and I'm sure, better than just going with the vibes.