Spec-First Software Development: How Google Is Changing the Way Software Is Built with AI

Artificial intelligence is changing how software is built. AI assistants and agents can generate code at remarkable speed, but speed alone does not ensure that a solution matches business requirements, architecture, or real user needs. When instructions are unclear or context is lost during long sessions, the result can include defects, unnecessary features, or technical decisions that have not been properly examined.

Spec-First Software Development places planning before code generation. Instead of moving directly from a short request to implementation, the team first creates a technical specification describing the problem, objectives, constraints, architecture, and verification approach. This document becomes a shared reference for developers and the agents carrying out the work.

A concrete example is the Elephant-Goldfish Model (EGM), introduced on the Google Open Source Blog on October 22, 2026. Google released an open-source plugin to support this workflow and said it had originally been developed for its software engineers. The approach connects context-rich design with independent review before an AI agent begins writing code.

What is Spec-First Software Development?

In traditional projects, requirements may be communicated through documents, meetings, and discussions across teams. In a Spec-First process, those requirements are turned into a clear, reviewable specification before implementation begins. The document explains what the system should do, why it is needed, which constraints apply, and how the team will verify that the result works as intended.

A specification can include the problem statement, technical approach, alternatives considered, dependencies, files to be changed, data structures, and testing criteria. The clearer the document, the less room there is for different interpretations by AI agents and team members.

How does Google’s Elephant-Goldfish Model work?

The model assigns two different roles to AI. The “Elephant” is a long-running, context-rich session that retains project background, discusses requirements with the developer, and helps shape the design. No code is written at this stage; the focus is on intent, architectural decisions, and documenting them.

“Goldfish” refers to fresh sessions that do not have access to the earlier conversation. They receive the specification and review it independently. Because they were not part of the original discussion, they can identify ambiguity, hidden assumptions, missing dependencies, and unaddressed edge cases. If the document cannot be understood without additional explanations, it needs further work before implementation.

From an idea to a specification, then to code

The workflow described by Google moves through several phases. First, the developer and the Elephant session explore the idea, discuss alternatives, and challenge assumptions under a “No Code” rule during design. Next, they draft a Markdown design document that sets out the problem, technical plan, implementation steps, and the specific elements expected to change.

During review, Goldfish sessions check whether the specification can be understood accurately, look for logical weaknesses, and verify that the information needed for implementation is present. Only after the document is sufficiently clear and approved by a person should the agent move on to code generation. This shifts some quality control from fixing incorrect code to preventing design mistakes earlier.

Benefits and limitations for software teams

A reviewed specification can improve communication among developers, product leaders, and AI agents. It creates a traceable record of decisions, makes changes easier to review, and helps teams distinguish essential requirements from assumptions. Independent review can expose problems before they become code, potentially reducing rework and correction costs.

However, this approach does not guarantee bug-free software and does not replace testing, code review, security assessment, or engineering judgment. A specification can be wrong, AI reviewers can miss issues, and requirements can change during a project. Final decisions, architecture approval, and accountability for the outcome must therefore remain with people.

How can businesses adopt this approach?

Companies can begin with a limited project whose requirements, integrations, and expected outcomes can be described clearly. The team should define the specification format, who approves it, how reviews are conducted, and which criteria must be met before coding starts. A pilot can show whether the approach improves quality and reduces ambiguity.

It is also important to keep specifications alongside the code and update them when requirements or architecture change. Businesses should establish controls for privacy, security, data access, and the use of AI tools. The aim is not to create documentation for its own sake, but to provide enough reliable information for sound decisions and controlled implementation.

Conclusion: clarity first, code second

Spec-First Software Development reflects an important shift in AI-assisted engineering: value comes not only from generating code quickly, but also from defining precisely what needs to be built. Google’s Elephant-Goldfish Model puts this idea into practice by combining context-rich design with independent specification reviews.

For businesses, the approach can lead to clearer processes, better-documented decisions, and more controlled use of AI agents. Technology can accelerate implementation, but quality still depends on clear requirements, testing, and human judgment.

As Ermal Beqiri, founder of Soft & Solution Group, explains:

“In AI-assisted software development, the best result does not start with how quickly code is written, but with how clearly the problem is defined and the solution is validated before implementation.”