I've adopted a brainstorm -> plan -> implement approach with my team. The entire goal for the approach is to put people first in the process with using these tools and use the tools to promote team collaboration and understanding and to prevent slop from entering the codebase. My thesis on this approach is that communication is the real problem we can try to improve on with the benefit of these tools, not just raw code output which seems to be the myopic focus of a lot of engineers using LLMs.

• Brainstorming involves creating a markdown spec that defines the user stories, experience mapping, business case, acceptance criteria, and a mockup. Once those are ready the team reviews it together to tweak the UX and decide if we are building the right thing. This is the one place I allow vibe coding, and the branch is clearly named "prototype/" so the vibe coded mockup is never merged in. This phase is built around centering the team on the "why" of the feature.

• Planning takes the feature doc built in the previous step and moves it into a new branch where the actual technical design happens. I landed on spec-driven design with the team, so the expectation here is to create markdown specs that show how we are going to build it, including Mermaid sequence and class diagrams, data structures and data flow, and requirements around accessibility, auditibility, scaleability, maintainability, security/threat modeling, test strategy, etc. Additionally, plans are developed that detail exactly what will be done by the agent in the codebase to implement the plan incrementally. Once these artifacts are built, a technical review is done collaboratively with some subset of the team to get consensus on the technical approach and determine whether the work is appropriately phased to facilitate good review and incremental feedback.

• Implementation is the execution of the plans from the last step where we actually build things that will enter the codebase. It's highly iterative, having the LLM move one step at a time and validating and tweaking the output as we go. Often things don't go as planned exactly though, which is where the engineering expertise in particular comes in to make sure the LLM isn't sailing us way off course or creating slop (things that LLMs are very apt to do, even with all this descriptive context). Once a plan is complete, if an engineer built it alone they submit a PR for review. If the engineer pair programmed with another engineer while executing the plan, I consider the review already done and the PR can be approved immediately between the two engineers. One way or another, collaboration and review are mandatory.

As far as all the markdown generated is concerned, I built Claude skills, agents, and hooks for the team to help structure this process and create the docs. Docs around features are considered evolutionary and while they are stored in source control with the project they are otherwise ignored after the feature is delivered. At the end of implementation we do reflect and add to more stable "charter", "system design", and "component" docs that can be brought into context for future feature work. They serve as higher level descriptions of the product and architecture. Most importantly, the docs are all written with LLM assist, but they're designed to be read by people to promote communication and understanding. It's a happy coincidence they also can be used for LLM context, and I treat that as a secondary benefit.

Regardless of your approach, put people first in it. LLMs are tools and nothing more, so if we're going to use them, let's use them to build people up and build team understanding of why and how we are building things. No matter which new tools come our way, the underlying concepts of engineering and team dynamics haven't changed.