iTranslated by AI
Specification-Driven Development in Organizations: Phase-Specific AI Agent Development Strategies
Introduction: Differences Between Solo Development and Organizational Development
In discussions about AI coding, stories are often told about personal experiences of how quickly one could create a working prototype (MVP) by leveraging AI. However, development within an organization is different from projects completed individually.
I use AI daily as a software engineer at a major Japanese company. In organizational development, "what to consult on and what to get approved" determines the success or failure of a project.
Even if you make a technically correct decision, the project will not move forward without approval from managers or relevant departments. Conversely, if appropriate consensus is built in the early stages, you can significantly accelerate during the subsequent implementation phase.
In this article, I will organize how to practice specification-driven development in an organization, along with the strategies for Phase 0/1/2 and the criteria for switching workflows. In my previous article, "Specification-Driven Development for Retaining Decisions," I discussed the value of specifications in the AI era, but this article focuses on practice.
Prerequisite Knowledge
- Specification-Driven Development: A method where requirements definition, task decomposition, and design decisions are externalized as specifications to proceed with development in collaboration with AI.
Phase Strategy: Stages of Externalization and Consensus Building
In this article, AI coding development workflows are broadly classified into two categories: Specification-Driven Development and plan→implement. Please refer to the previous article for details.
There is no need to make these two development cycles mutually exclusive or limit yourself to just one. What is important is to identify which phase the project is currently in to advance it within the organization and to use the appropriate development workflow accordingly.
These phases are classified not so much chronologically, but rather based on the necessity of externalizing decision records and the stage of consensus building within the organization.
This diagram visualizes the flow of specification formulation in the AI era based on the design thinking process. The key to smooth consensus building and sustainable development is not to leave the insights gained through collaboration with AI during "Exploration (Divergence)" as they are, but to refine them during the "Refinement (Convergence)" phase.
Prerequisite Knowledge
- plan→implement: An iterative workflow where a minimal plan is made, implemented, and the results are reflected in the next plan.
Phase 0 (Exploration): Gathering Information and Forming the Skeleton of Specifications
Purpose of Phase 0
Create the skeleton while externalizing thoughts through specification-driven development.
In this phase, decisions occur frequently regarding what to build and how to build it. We organize requirements, select the tech stack, and design data models. By externalizing these decisions as specifications, the rationale becomes clear when looking back later.
Specifically, we leave requirement definitions, reasons for technology selection, architectural overviews, and the design of major data models as specifications.
Practicing Phase 0 in an Organization
It becomes crucial for engineers to "properly understand the project." This involves gathering constraints, policies, and implicit assumptions from stakeholders—such as product managers, sales, designers, legal, and security personnel—and consolidating them into information that can be input into an AI.
Since AI accepts multimodal data, it is not always necessary to consolidate information in text format. You can prepare materials containing important prerequisite information in any format, such as PowerPoint or Excel.
Information like "This feature cannot be implemented due to regulations" or "There is a history of failure in a similar project in the past" is difficult for current AI to infer. The quality of information gathering in this phase significantly affects the amount of rework in later stages.
Information to Gather in Phase 0
- Business Constraints: Budget, deadlines, regulations, compliance requirements
- Technical Constraints: Available tools, integration with existing systems, security policies
- Organizational Constraints: Team skill sets, past failure cases, internal political considerations
- Implicit Assumptions: Information that is "taken for granted" but not documented
In a stage where the overall picture of the project is not yet clear, you should first spend time understanding the project.
Phase 1 (Refinement): Organizing Specifications for Consensus Building
Purpose of Phase 1
Structure the insights gained from exploration and format them so they can be shared with the team. Specifications written during the exploration phase tend to be redundant because they include the process of trial and error. In this phase, we organize the information that truly needs to be kept and reconstruct it into a readable format.
Specifically, we clarify decision points, briefly summarize the reasons for rejected proposals, and organize key points to be referenced in future development.
Practicing Phase 1 in an Organization
Consensus building becomes the top priority. Multiple technical options and architectural proposals explored in Phase 0 are compiled into a specification document or a minimum viable product (MVP) and presented to managers and relevant departments along with a pro/con analysis.
If stakeholder approval is not obtained at this stage, there is a high risk of being forced to change direction later even after moving to Phase 2 implementation. How quickly you can cycle through Phase 0→1 determines the success of subsequent rapid prototyping.
Since judgment criteria are not fully assembled at the end of Phase 0, it is difficult to gain approval; however, by organizing everything in Phase 1, organizational decision-making becomes possible for the first time.
Materials to Prepare in Phase 1
- Comparison table of technical options: Pro/con analysis for each option
- (Optional) MVP or working prototype: A minimal implementation that functions as a proof of concept
- Risk analysis: Anticipated risks and countermeasures
- Schedule and effort estimation: Development effort for each option
Presenting the information necessary for consensus building without excess or deficiency is what determines the success or failure of Phase 1. While preparing the above materials in addition to specifications might feel like a chore, it can be done rapidly by brainstorming with an AI agent.
Phase 2 (Building Up): Rapid Development and "When in Doubt, Implement Both"
Purpose of Phase 2
Perform high-speed feature additions using plan→implement.
Maintain specifications as a reference and update them only when significant decisions are made. For daily feature additions, there is no need to update the specifications. However, if a major decision affecting the architecture occurs, record it by updating the specifications.
Practicing Phase 2 in an Organization
In this stage, you can maximize the benefits of rapid development using AI. Since the direction was finalized and approved in Phases 0→1, engineers are freed from considering "how to build" and can focus on "what to build." This is the stage to accumulate features by running quick iterations with short prompts.
New Strategy in the AI Coding Era: "When in Doubt, Implement Both"
A particularly effective approach at this stage is the "implementing both when in doubt" approach.
In traditional development, much time was spent debating which UI pattern (A or B) was better or which algorithm (X or Y) to adopt. However, in AI coding, the implementation speed is so fast that I have realized it is more rational to just implement both if you have time to argue about it.
In marketing terms, the environment for easy A/B testing is now in place. Implement, compare, and then decide based on data or actual usability. This "build and choose" cycle becomes a realistic option in Phase 2.
Precautions for Phase 2
However, if the foundation from Phases 0→1 is insufficient, this rapid development can backfire. Piling up features without a settled direction risks rework where you realize later that "the fundamental direction was wrong," potentially wasting all implemented features.
You can accelerate in Phase 2 precisely because you appropriately slowed down and solidified the direction in Phases 0→1.
Summary: The Ability to Discern the Phase
In this article, I have organized the phase strategies for practicing specification-driven development in an organization.
- Phase 0 (Exploration): Gather constraints and assumptions, and understand the project.
- Phase 1 (Refinement): Organize specifications and strive for organizational consensus.
- Phase 2 (Building Up): Accumulate features through rapid development.
What is important is to discern "which phase requires what to be externalized" in the current project. By appropriately slowing down in Phases 0→1 to solidify the direction, you can significantly accelerate in Phase 2.
In the AI coding era, new options like "implementing both when in doubt" are emerging. Leveraging the improvement in implementation speed, a culture of comparing through implementation while looking at working products—rather than just debating on blueprints—will likely spread.
Being able to use both specification-driven development and plan→implement according to the situation is a skill required for developers in the AI era. I am still in the trial-and-error stage myself, but I am confident that being conscious of and switching between these frameworks will allow us to better draw out the effects of AI coding.
Discussion