Spec-Driven Development & Agentic AI Software Engineering Guide

In this article, we'll walk through a complete AI-powered software development workflow—from an AI-generated prototype and functional specification to implementation planning, GitHub issue generation, and orchestrated execution by specialized AI agents. You'll see how AI software engineering, driven by spec-driven development, creates a structured AI software development lifecycle that transforms business intent into enterprise-ready software while keeping architecture, quality, and implementation under control.  

In the first demo session of our From Prototype to Production with Agentic AI series, Martin Kaiser, our Digital Product Designer, built a prototype by following the same process you would use when working with a customer: understanding the business intent and building the solution live.  

Starting from that prototype, we then had the second session, where Michael, PRODYNA's AI Software Engineer, established the AI foundation for everything that follows in this blog. He showed how to build custom agents, the AI infrastructure, and the framework that we'll now use to build the application.  

Building on that foundation, we'll now use these AI primitives and custom agents to transform the prototype into enterprise-grade software.

The process of transforming the prototype into enterprise-grade software consists of four steps.

The first step is the prototype, which captures the business intent behind the application.

Then, from that, we derive the specifications. What do we actually want to develop? We use AI to find these specifications and get a clear picture of what needs to be built.

In the following step, we plan our implementation. We feed in the technical details of the technology stack we want to use for building the application, along with the architectural decisions and boundaries.

We combine the business intent and the specifications with all these technical constraints to create an implementation plan and break this plan into smaller pieces of work that we can later delegate to our AI agents. This is where AI software engineering becomes a structured, repeatable process.

Spec Driven Development

Phase 0: AI Infrastructure

Phase zero is the governance layer. Michael showed that we use Copilot custom instructions, custom agents, hooks, and skills to encode the way we do software development and make this knowledge accessible to the AI. That's the governance layer.

Phase 1: Specification

We will show the AI our prototype and the user stories that Martin created during his prototyping workshop, and ask the AI to condense the business intent.

The prototype contains a lot of technical details. It's not structured very well from a coding perspective because it's a prototype—it was built rapidly. But we can use AI to understand what we're actually trying to build and extract the functional specification from it.

The better your specification, the stronger your AI software development lifecycle becomes.

This reflects the principles of Spec-Driven Development, where a well-defined specification guides implementation and serves as a shared reference for both engineers and AI agents.

In AI software engineering, precision—not prompting—is what helps separate a successful AI software development lifecycle from unnecessary technical debt. Clear specifications make implementation more predictable, maintainable, and scalable.

Phase 2: Planning and Task Breakdown

In this second phase, we feed in all the technical details and use them to come up with a plan for how to build what the business requires.  

We then break this down into smaller pieces of work and figure out which custom agent we built last week should be used for each task.  

Previously, Michael built custom agents for frontend development, backend development, and writing API specifications. These agents are very focused and skilled at performing specific tasks.

Now, in the planning phase, we identify and map the individual tasks to the appropriate agents. That way, when we execute the tasks, they're not executed by a general AI agent, but by an expert. That's what happens in this step.  

We have our task list. We know which custom agent should execute each task. This leads us to the last phase.

Phase 3: Implementing the Product

This leads us to the last phase, where we have an orchestration agent capable of reading all the tasks that need to be done, ordering them into a logical sequence, and delegating them to the appropriate implementation agents. It basically holds everything together, orchestrates all the sub-agents, and makes sure they execute the tasks correctly.

We start on the left side with the Product Finder prototype that we built. We feed this into the Spec Agent. The Spec Agent produces a Markdown file based on a predefined structure that defines what we want in such a specification, and it extracts the business intent.

Next, we have an agent that has proven to be very, very helpful: the review agent. Its sole purpose is to go through the functional specification we just created, check it for consistency, identify gaps and logic errors, ask questions for clarification, suggest optimizations, and refine the specification. It gives us a second pair of eyes on the specification, helping us refine it even further.

With this specification, we then hand it over to our planning agent. As you'll see, I've built the planning agent so that it looks at the specification, understands all the constraints and the technologies we want to use, then breaks the work down into tasks and creates GitHub issues for each of them.

After the planning agent is done, we have a long list of GitHub issues that we need to implement to fulfill the business requirements defined in the specification.

Finally, we hand everything over to our execution engine—our orchestration agent. We tell it to pick up all the issues for this specific feature, put them in the correct order, and start implementing them by creating sub-agents that do the actual work. These sub-agents are experts in implementing their specific tasks.

This has several advantages. First, you can parallelize the work. If you have independent tasks, it's not a problem to spawn all the agents in parallel and speed up the process.

Another very important aspect is that these specialized sub-agents have their own context. They don't know everything that needs to be done. They're only focused on a specific task with very clear instructions. Their context window is very, very focused on the actual task, and this helps steer the implementation.

What is a very important aspect: having a focused context for each of the sub-agents.  

To see how this works in practice, we switch to Visual Studio Code.

The Demo Application: AI Software Engineering in Action

To demonstrate the workflow, I start with a basic application that we can iterate on. The application is already running and displays a list of products.

We have a fictitious company called KLEB with around 700 to 800 different adhesive products. They have different properties, different types of materials, and different applications.

The goal is to build an expert application that can quickly filter, search, and compare all of these products. That's the use case.

At this stage, only the landing page has been implemented. Features such as Compare and the product detail pages are still pending implementation.

It's already a three-tier application. We have our frontend, which is a single-page application. We have our backend with a REST API written in Java, and we have a persistence layer.

For local development, the application uses SQLite. In production, it uses an ORM mapper with a PostgreSQL database. This is a very standard technology stack.

Looking at the project, we can already see the generated code.

We already have our OpenAPI specification. This was generated using the same process we'll apply to the remaining features. Here, the specification isn't just documentation—it directly drives the implementation, which is the core idea behind Spec-Driven Development. The backend implementation in Java is cleanly separated into domains and follows all the architectural rules defined in the specialized agents.

Specialized AI Agents

To recap, we have a backend development agent specialized in building Java backends with Spring Boot.

It has a clearly defined tech stack that it has to follow. We also have a number of architectural rules that need to be followed when implementing the backend, the application structure, and everything related to it. It's very detailed information. This is usually your developer guide. In this case, we've put it into a Markdown document that the agent always has available.  

That's one of the advantages of using AI agents. They always read the documentation. They're very good at reading it and remembering it.

Basically, every morning when a developer starts working, the AI agent reads the entire developer documentation anew.  So that's agent number one.

Next, we have a dedicated frontend agent. It's structured more or less the same way, but it contains all the rules that apply to frontend development.

We also have a specialist for writing OpenAPI specifications, which allows us to decouple the backend and the frontend by using a common OpenAPI specification.

Creating the Functional Specification: The Spec Writer Agent

Functional specification (in this context) = a structured document that describes what the system must do (scope, actors, preconditions, functional requirements, API interactions, and acceptance criteria) without mixing in speculative technical implementation decisions.

I use my spec writer agent. It knows exactly what to do. It's not supposed to write any code, tests, or anything else. It's only meant for writing specifications. It also knows where to read the information from because I told it where our prototype repository is.

If I open a new session, I can select our spec writer agent and tell it which specification it should write.

In the prototype, we have five user stories. We'll use them as the starting point for generating the specifications. I've already done that for three of them. The first one covers the overall application and layout. The second one focuses on more sophisticated filtering. We have the product details page, and the fourth one is the comparison feature.

I'll quickly open the spec agent and write a prompt: "Write the spec for 04-compare-feature.md."

Now the agent checks the prototype repository and loads the content using GitHub MCP. I don't have the prototype checked out locally or anything like that. It's really going through the tooling, the MCP server, contacting GitHub, looking into the repository, and loading all the required information.

This is a very common pattern. What we often see at customer projects is that user stories, specifications, and related documentation are usually stored in different systems.

In our case, the information comes from the prototype repository, which we can access directly through GitHub MCP. But we could just as easily point the agent to Confluence or Jira, depending on where the required information is stored. We only need to tell the spec writer agent where to discover the business intent and where to find it.

From that, we can see that it found the compare feature we defined in the first session, and it's now starting to write the specification. We should soon have the functional specification for the compare feature.  

The agent shouldn't have to guess. It should know exactly where to look.

One note is that I explicitly instructed the agent not to take any technical information from the user stories. With Figma Make, the user stories contain a lot of React- and Tailwind-specific information, so they contain a mix of technical and functional specifications. That's why I explicitly told the agent not to make any technical assumptions and to keep the specification purely functional.  

We have the user story, what's in scope and what's out of scope, the actors, the preconditions, and a comprehensive list of functional requirements, each with its own ID.

This structure is something I provided to the spec writer agent. The agent knows how we at PRODYNA write specifications, so it always follows the same structure and works in a consistent way.

We have some more UI-specific information. We also have the API requirements, the interaction flows, and the acceptance criteria. So, we can even test against all this information.  

And here we go. We now have a functional specification for our compare feature.

Reviewing the Specification: The Review Agent

Once the functional specification is complete, the next step is to review it before moving on to implementation planning.

I run the review agent using the prompt: "Review FS-04."

The review agent analyzes the specification, identifies inconsistencies, missing information, and assumptions, and suggests improvements before implementation begins.  

During the first review iteration, the agent reports several findings. I respond with the prompt: "Please fix the first findings and then show me the rest." The agent goes through the findings, takes the feedback into account, and reworks the specification to make it clearer. After completing the review, it reports a total of 10 findings: 1 blocker, 5 major, and 4 minor.

Once these findings are addressed, the specification is ready for implementation planning.

We see the message: "The specification is ready for implementation planning, with one action item to track." I'll accept the suggestion, and we're done here. The review process for FS-04 is complete.

Implementation Planning: The Spec Planner Agent

The next step is implementation planning. I use the spec planner. I already did that for feature number two, and now I'll do it for the product details page. I'll give the spec planner this prompt: "Plan FS-03."

The planner analyzes the product details page and comes up with an implementation plan. Maybe we need to implement new frontend components. Maybe we need new backend endpoints to load all the details. It will break all of this down into GitHub issues.  

Implementation plan (agentic workflow) = a sequenced breakdown of work into testable units, each assigned to specialized agents, with explicit acceptance criteria and dependencies.

The planner has already come up with a number of different tasks.  

Previously, I defined a couple of implementation phases for the planner agent:

This is the general implementation process.

The planner will now go through the specification, define the implementation tasks, and organize them into different phases.

The first phase starts with the API work. Then we move on to the backend implementation. Once the implementation is complete, we have review tasks to go through everything we've built. Here, we also specify which agent should be used for each task.  

The planner creates the GitHub issues, resulting in a complete set of implementation tasks.

We now have 21 tasks across eight phases, all synchronized with GitHub.

The planner reports: "21 tasks across 8 phases, all synced to GitHub issues. The plan is ready for execution via the Spec Executor agent (FS-03)."

Executing the Implementation: The Spec Executor Agent

The implementation isn't improvising. It's executing a predefined plan.

I start a new session with the spec executor and give it the prompt: "Implement FS-02."

The agent fetches all GitHub issues related to this specification.

The spec executor first evaluates the order in which the tasks should be executed. In this case, it determines that the frontend foundation work must be completed before the remaining implementation tasks can begin.

Next, I switch to the FS-02 implementation request and begin implementing the feature.

Specialized AI Agents in Action  

I told the orchestration agent, "Once you've loaded all the issues, start a sub-agent for each task." That's exactly what happened. Each task has now been spawned as its own sub-agent.

The sub-agents can use whichever model I assign to them.

This is really helpful because you can tailor a specific agent and link it to a model that's particularly good at a specific task.

Instead of trying to solve everything at once, every agent solves one clearly defined problem.

For example, GPT-5 Codex models are very good at straightforward implementation. They're good at staying focused on the target and working toward a clearly defined goal.

Opus models, especially Opus 4.6, are more creative. That's why they're particularly well suited for writing specifications. So I can select different models depending on the agent.  

Each specialized agent focuses on its own task, while the orchestration agent coordinates the overall implementation. This allows the entire implementation process to remain structured, consistent, and scalable.

Depending on the complexity of the implementation, this process can take some time—even several hours. By the end of the day, you'll have a running product.

Scaling Systems with Agentic Software Development

We started with an AI-generated prototype, moving from sticky notes and wireframes to a running prototype.  

Then we established the AI infrastructure—our AI operating system—with custom agents, governance, and reusable AI primitives.  

From there, we transformed the business intent into functional specifications, reviewed and refined them, planned the implementation, generated GitHub issues, and orchestrated the execution through specialized AI agents.

This end-to-end process demonstrates how Spec-Driven Development provides the foundation for a structured AI Software Development Lifecycle, enabling teams to build enterprise-grade software in a consistent, scalable, and maintainable way.

If you implement this structured process, you typically achieve:

• clearer requirements traceability (specs with scope + acceptance criteria)
• fewer mid-implementation surprises (review catches issues early)
• consistent architecture adherence (specialized agents enforce rules)
• faster iteration through delegation and parallel execution
• improved reliability through orchestration and quality gates

Most importantly, you build a repeatable pathway from prototype to enterprise-grade product—rather than rebuilding logic manually every time a prototype proves valuable.

AI accelerates software creation, but enterprise readiness requires discipline: requirements must be extracted, validated, planned, and executed through well-defined interfaces. The agentic lifecycle described here—prototype → functional spec → review → plan → orchestrated execution—turns AI from a tool into a process.

If you take one takeaway, make it this: successful AI software engineering is orchestration, not improvisation. When business intent is structured into AI-readable specs and implementation is delegated to specialized, context-focused agents, you’re no longer gambling on model output—you’re engineering a system that can deliver.

Ultimately, agentic software development is about giving every agent a well-defined responsibility within a structured engineering process, so software can be built predictably, consistently, and at enterprise scale.