Comment by kristianc

13 hours ago

I'm getting a lot of mileage out of basically acting like the AI's Product Manager, and insisting that it writes up short PRDs for every feature we propose to build. That gives it a reference over time of everything that has been built, but also makes it less liable to drift with each one. Each one gets its own conversation. For me this is a happy medium between stopping it going off the rails but also making sure it can reference past decisions when it needs to. The one thing I dislike about Pocock's method (not to use PRDs so much but to have an in depth discussion to get alignment) first is it wastes a lot of the best window on that initial back and forth.

6 comments

kristianc

Reply
nopurpose  13 hours ago

Is it adhoc or you use more structured approaches like openspec? I also tend to work on a plan first, but it stays as in-session todo, which is hard to reference later.

  • kristianc  13 hours ago

    It's ad hoc / my own framework, just found something which works for me. The exact structure is

    - Work Mode - HITL/AFK

    - Problem Statement

    - Who It Affects - Primary / Secondary User

    - User Stories

    - Business Case

    - Why Now

    - Success Critera

    - In Scope/Out of Scope [Out of Scope v. important)

    - Thinnest Slice (This I've found super valuable, means you max out the amount of 'product' for your buck and avoid diminishing marginal returns or overbuilding. Often I will build this)

    - Eigenfeature - What is the larger feature we _could_ (but probably won't) which would solve for this use case and other stuff I might not have thought of

    - Technical Notes

    - Deps

    - Schema Changes

    - Risks

    - Final Recommendation [go / no go, including on scope]

    There's a note in my Claude / Agents MD which says no net new feature gets introduced without this and I get it to move through a pipeline of folders (active, approved, shipped, proposed etc). All runs in a system of MD files and have even created a little MD Kanban from the metadata!

    • magicalhippo  12 hours ago

      I guess I've stumbled into something similar. Though I don't have a fixed format like yours. I first do a lot of back and forth to generate what I call a design document also includes rationales for various points or decisions. I use both Claude and Codex to iterate on this until I'm happy. The end result includes a lot of what you mention.

      I then start a fresh conversation, make it analyze the design document and code, and for larger changes, generate a high-level implementation document which includes concrete phases or steps. I review this plan and iterate if necessary.

      Then for each phase I make it generate a detailed plan for that phase and save it along side the other documents. Once the phase is over, I make it write a summary of what was done, decisions made and reasons for it. And typically a good point to compact the model's context.

      These documents gives additional context for when I make another model do code review, and help illuminate drift or gaps from the main design document.

      1 reply →