Last week, I blogged about being a builder and getting your computer setup. But before you go off to the races and start agentic coding, we need to be sure you have a collaboration model setup with your team. Your chat history is stored locally and cannot be viewed by your peers to “keep up.” At the same time, while development may be faster now, producing more features that don’t move the needle and are hard to maintain is an anti-goal; that is how you end up with a confusing product like Jira instead of a product grounded in strategy. It all ends up with the famous proverb:

If you want to run fast, run alone. If you want to run far, run together.

In other words, you still need to collaborate and be strategic in this new world. But what does that mean? Insert: spec-driven development.

What are specs?

Do you remember when local versions of Microsoft Word were replaced by Google docs? I argue this is like that. You can still leverage Google docs when appropriate, but with spec-driven development, your PRD-like artifact(s) live in version control (ie Git). This keeps context of the plan for agentic output in code for initial review and longer-term ownership; anyone can see the feature work added to the code base, when it was added, by who, what the goals were with the addition, and if there were gaps in the plan (specs) for the agentic agents to operate against.

This has the following benefits:

1. Keep context together (PRDs with code)
2. Enables collaboration at all points in the product development lifecycle (PDLC)
3. Eases code reviews, as if there is an issue, the prompt can be reviewed and addressed (vs just the agentic output). This enables a feedback loop to learn how to improve upfront prompts/specs/plans across the team.

Persisting Claude Code Plans

Working backwards from my latest strategy and roadmap doc(s) on my current project, I produced a Plan in Claude Code with the following prompt:

Assume I want to do the <pick a project> outlined in <detailed documentation reference>.

This will iclude <short list of prerequisties/requirements>

For more details, there is additional information in these locations as well: <list of additional resources like Slack channels, Zoom recordings, etc>

But Claude Code doesn’t store these plans in a consistent manner to be uploaded as part of the code base. After playing with how to store it, including formatting additions to ensure details where clear (who, when, etc), I explored alternative options and stumbled upon spec-driven development and frameworks to leverage.

The two I found:

1. OpenSpec (thanks to John Koehl), and
2. Get Shit Done (thanks to Brandon Clemons)

After exploring OpenSpec, I was quickly able to convert the output of the above prompt into an initial spec. This was far easier than I expected, and editing it was easy in my IDE such as Cursor or VSCode.

So, what’s the workflow?

Iterate on your proposal, and then submit that for review as part of source control. You can choose for this to be part of the package you will be working on or have it be a separate package (potentially requiring manual copying of files depending on your choice). Either way, there will likely be some administrative work custom to your company, be it getting permissions to submit code to an existing package or creating a new one.

1. Checkout the package you will be working against locally. Figuring out the package can be tricky at large companies! But if you’ve setup your IDE like I instructed last week, you can ask it (powered by a model of your choice) to find the package and check it out for me. I mentioned the project name and the lead engineer to help it find the package.

2. Navigate to this package.

cd <package location>

3. Create your own branch. Example:

git checkout -b <username>/<branch_description>

4. Initialize OpenSpec (or alternative). This assumes you have already downloaded it and added it to your PATH per the instructions last week. Run the following command in your terminal in the package:

openspec init

5. Create your Proposal. In your chat window, type:

/opsx:propose <what-you-want-to-build>

The overall OpenSpec workflow looks like this:

You: /opsx:propose add-dark-mode
AI:  Created openspec/changes/add-dark-mode/
     ✓ proposal.md — why we're doing this, what's changing
     ✓ specs/       — requirements and scenarios
     ✓ design.md    — technical approach
     ✓ tasks.md     — implementation checklist
     Ready for implementation!

Alternatively, if you need to explore first:

You: /opsx:explore

AI:  What would you like to explore?

You: I want to improve page load performance but I'm not sure
     where the bottlenecks are.

AI:  Let me help investigate...
     [Analyzes bundle sizes, identifies slow queries, reviews
     component render patterns]

     I found three main bottlenecks:
     1. Large unoptimized images
     2. Synchronous data fetching in ProductList
     3. Re-renders from context changes

     Which would you like to address first?

You: Let's tackle the data fetching issue.

You: /opsx:new optimize-product-list-fetching

AI:  Created change. Ready to create: proposal

You: /opsx:continue

AI:  Creating proposal based on our exploration...
     [Writes proposal incorporating investigation insights]

     Ready to create: specs, design
     Which would you like next?

You: /opsx:continue

AI:  Creating specs...

6. Review & modify the output. Iterate and add context in the proposal.md, which is what you will start with as your review.

7. Submit the proposal for review. This requires the following commands in your terminal:

a. List all new files:

git status

b. Add the proposal.md file to git:

git add <location of proposal.md>

c. Commit the new file to your branch:

git commit -m "<description>"

d. Make sure you are still working against the latest version:

git fetch origin
git rebase origin/main

e. Submit your change for review:

git push -u origin <branch name>

f. The output will tell you how to create a review by following a link to GitLab. The message will begin with:

“To create a merge request for <branch name>, visit:
remote: <GitLab URL>”

Follow this link and create your MR, adding your approvers as needed. Consider marking the review as DRAFT if you think it will be long-standing.

Then, go through the review process! Once finalized you now have a proposal that will be change managed with further reviews with changes.

What about the design.md, spec.md, and tasks.md files?

Once the proposal.md is aligned on, use OpenSpec to regenerate these files based on the updated proposal. Iteration should continue on these files, in order.

If you are working cross-functionally and want to know ownership boundaries between engineering and product, my initial guideline is that by tasks.md engineering should be leading with product in the reviewer role, leading to the following workflow:

proposal.md (product led, team reviewed) → design.md (collaborative) → spec.md (collaborative) → tasks.md (eng led, team reviewed)

If the collaborative approach requires a dedicated owner, the technical details are likely to require these to be eng-led.

What about visual designs?

I used Claude Design to produce a design for my new feature. Given this was a live package, it was able to see the existing code as well as leverage a Figma MCP to ensure future designs were keep into account. It output an html file that I also added to the OpenSpec project folder so it is auditable and reviewable with the proposal.

Claude Design is great compared to tools like Replit to keep the context in code with the spec/proposal and not try to code the solution with the upfront iteration on the spec.

What happens once the spec is agreed to?

Let the engineers fly. This is the fun part! This up front effort is all to enable the faster development that AI promises in a strategic way. The PM is still needed to set this direction, but instead of waiting weeks to understand if they were correct, it may now only take hours. The engineer(s) still own the implementation, as they are best suited to review the agentic output and ensure it fits in to the aligned on engineering design.

If the feature proves to be valuable, then the PM can shift to leading the go to market (GTM) strategy which is still needed. With this faster lifecycle, it’s OK to learn that some hypotheses are wrong, re-embracing agile methodology in the fastest cycle time in software development’s history.

Then, iterate and repeat across projects!

This is not the end of defining what it means to be an AI-driven builder, but I believe it is a solid stepping stone. It doesn’t mean engineering or PMs go away; rather, it means they work more closely than ever before, in code, with fast iterations. That’s not so scary, is it? 😅