The harder problem is making sure that developers, architects, stakeholders, and AI assistants are all building the same thing in the same way.

As AI increases the speed at which individual developers can produce software, teams need better mechanisms for maintaining architectural decisions, business intent, requirements, and implementation conventions. Bossle’s proposal is to treat specifications not as static documentation, but as a shared, structured source of truth that guides both humans and AI.

Why does vibe coding become harder at team scale?

Vibe coding works particularly well when a developer is prototyping or exploring a solution. An assistant can generate code, compile it, revise it, and quickly move an idea toward a working implementation.

At team level, however, that speed introduces a coordination problem.

Different developers may give their coding assistants different prompts. Important context can remain in chat histories or in developers’ heads rather than in the codebase. The same problem can therefore result in different implementation patterns, while architectural decisions gradually drift in different directions.

The result is additional rework and coordination overhead.

Faster code generation does not automatically create a more aligned development team.

What information needs to be aligned before generating code?

Bossle describes alignment as more than agreeing on code style. Teams need a shared understanding of several layers of software design.

That includes:

• functional requirements
• non-functional requirements
• architectural structure
• important architectural decisions
• domain boundaries
• implementation-level design
• constraints and standards

Architectural decisions are especially important because architecture is not only a description of how components relate to one another. It also records decisions that can become expensive to reverse later.

The specification therefore needs to preserve both what should be built and the important reasoning and constraints that determine how it should be built.

Why isn’t a large Markdown specification enough?

One obvious response to the alignment problem is to write everything down.

Bossle’s team tried that approach.

In one real example from their codebase, a specification had grown to roughly 2,100 lines. Although the document remained technically human-readable, it had become closer to a reference document than something a developer would realistically consume during onboarding or everyday development.

Large text specifications introduce several problems.

Humans struggle to retain their contents. Requirements accumulate exceptions and additions. Contradictions can appear. And the same problem exists for AI assistants: adding more specification text consumes more context without necessarily increasing precision.

More context is therefore not automatically better context.

If specifications are going to guide both developers and AI systems, they need to remain structured, focused, and usable.

What should specification-driven development look like for AI-assisted teams?

Bossle proposes a different playbook: make the specification a collaborative artifact that actively drives development.

Instead of one person writing a large document and handing it to the rest of the team, specifications can be refined together. Developers, architects, product roles, and other stakeholders can participate in establishing the design intent.

Visual representations can also complement text.

An architectural diagram, for example, allows people with different technical backgrounds to discuss the same system without forcing everyone to interpret a long specification document first.

The underlying information can then be stored as a lightweight structured model rather than as an unstructured collection of text files.

The goal is not more documentation.

The goal is shared design intent that remains usable throughout implementation.

Why does shared terminology matter when working with AI?

One of Bossle’s requirements for an AI-assisted specification workflow is that the assistant must understand the terminology used by the team.

A team might talk about domains, entities, data entities, containers, aggregates, commands, or other concepts specific to its architecture and development practices.

The model should adapt to that language rather than forcing teams into an externally defined vocabulary.

This becomes an important part of alignment: humans and AI assistants need to reason about the system using the same concepts.

A lightweight model can therefore be more useful than a highly formal modeling language when its purpose is to communicate intent rather than deterministically generate source code.

How can visual models connect business intent to software architecture?

During the session, Bossle demonstrated the approach using a fictional webshop modernization project.

At the architectural level, the system was visualized using concepts from the C4 model, including systems and containers. That made it possible to start with a high-level view that both technical and non-technical stakeholders could discuss.

The demo then moved from business intent toward implementation.

A gift-card feature had been decomposed using a user story map. One story allowed a customer to check the remaining balance of a gift card.

The design assistant was asked to identify which C4 containers would be affected by that story. It proposed changes including the frontend, the backend-for-frontend, and a balance-related service.

This creates a traceable path from:

business requirement → architecture → implementation design → code

Instead of asking a coding assistant to infer the entire path from a single prompt, each stage provides structured context for the next.

How detailed can the specification become?

The model demonstrated in the session did not stop at high-level architecture.

At implementation level, the example used domain-driven design concepts for a gift-card service. The model contained an aggregate, an entity with properties and transactions, and commands describing behaviors such as activation, redemption, and refunds.

Individual commands could include details such as preconditions, processing logic, and postconditions.

That information was then represented in structured files inside the project repository. Bossle showed a YAML-based representation intended primarily for AI consumption rather than for humans to read directly.

Project-specific skills could instruct the coding assistant how those modeled concepts should map to implementation patterns.

According to Bossle, carefully defined skills can make the resulting generation near-deterministic: not guaranteed to produce identical code every time, but constrained enough to produce consistently similar implementations.

Why should specifications live in Git?

A central part of the approach is treating specifications similarly to source code.

The specification should live with the project in Git and act as a single source of truth.

This allows the development workflow to use mechanisms teams already understand for managing changes. More importantly, it prevents architecture, requirements, implementation specifications, and generated code from being distributed across numerous disconnected tools.

Once the model is available inside the development environment, a coding assistant can consume small, focused pieces of specification instead of repeatedly receiving the entire project context through prompts.

That can make subsequent changes easier to target.

If a specification changes, the assistant can be asked to apply that particular change to the implementation rather than regenerate the entire system from scratch.

Can specification-driven development reduce repeated prompting?

Bossle argues that investing more precision at the beginning can reduce repeated prompting later.

In the demo, he reported that generating the complete example service took approximately nine to ten minutes and cost roughly two US dollars in model usage.

The more important point, however, was not the absolute generation time or cost. It was the ability to rerun the process after changing the specification.

Teams can also look for divergence between the specification and code when implementation evolves faster than the model. Some of the current implementation state can then be reverse-engineered back into the specification.

That process cannot automatically recover all of the original design intent, but it can help bring the model back in line with the implementation.

Does writing specifications first mean returning to waterfall development?

This question came up directly during the VibeKode session.

Bossle acknowledged that specification-first development can initially sound like waterfall. His distinction is the size and speed of the specification cycle.

Instead of spending months specifying an entire system before implementation begins, teams can refine smaller problems and start implementing once each individual piece is sufficiently clear.

That shifts more effort toward the beginning of each development slice without requiring one enormous upfront design phase.

In other words, AI-assisted development may create a stronger shift left toward specification and design, because generating the code itself is becoming comparatively inexpensive.

The bottleneck moves from typing the implementation to deciding precisely what should be implemented.

What role will AI agents play in this workflow?

At the time of the session, agents could already contribute through the Git repository.

If an agent knows how to create the structured YAML representation used by the model, its changes can be picked up and visualized by the specification environment.

Direct interaction between agents and the design assistant was described as a future capability on the product roadmap.

Bossle also outlined a possible next step: a design change could be committed, an agent could detect it, and the agent could automatically trigger the corresponding implementation update.

That would move AI-assisted development from isolated code generation toward a workflow in which specification changes can drive increasingly automated implementation processes.

The real bottleneck in AI-assisted software development

The central argument of “Vibe Coding Is Fast. Alignment Isn’t.” is not that developers should slow down AI-assisted coding.

It is that teams need to become better at specifying intent.

When code generation becomes faster, ambiguity becomes more expensive. Unclear requirements, inconsistent architectural decisions, hidden context, and different interpretations can propagate through a codebase just as quickly as correct decisions.

A useful specification therefore needs to serve two audiences simultaneously.

It must give humans a shared representation they can discuss, review, and refine. And it must provide AI assistants with structured, precise context they can reliably turn into implementation.

For Bossle, specifications work best when they are created collaboratively, expressed using the team’s own terminology, supported by visual models, stored alongside the code, and refined continuously rather than written once and forgotten.

Vibe coding can accelerate implementation.

The next challenge is making sure everyone — including the AI — is accelerating in the same direction.