Vibe Coding Is a Drunk Carpenter With a Hammer

Agentic engineering does not need to be terrible for product outcomes or the carpenters' livers.

We know the problems with vibe coding are many. Stateless sessions lead to the loss of structural decision-making, and inconsistent design patterns develop. It becomes a spaghetti time bomb. Silent gaps arise because the LLM pays little attention to things like input sanitation, race conditions, and telemetry. Team coordination is effectively impossible when vibe coding puts each engineer into solo sessions with no clearly defined rules and coordinated objectives. PRs tend to become nightmarish, with thousands of lines of code to review while trying to understand the AI's intent.

Engineers end up feeling disconnected from the engineering process and more like AI babysitters at the end of the day.

But there is a two-part alternative that I fell in love with that solves those issues, and so can you. They are spec-driven agentic orchestration and vertical story slicing.

Spec-Driven Development (SDD) puts engineers back in the driver's seat with the agent riding shotgun. SDD helps you engineer solutions with forethought, collaborate as a team, research, and plan before the agent writes a single line of code.

Hair of the dog.

While there are several spec-driven workflows out there, I am going to address OpenSpec in this article as this is the workflow that I prefer due to its lightweight and versatility. The nice thing about the OpenSpec workflow is that it works great with both greenfield and brownfield products and you can introduce it into your workflow (and repo) at any point in the product lifecycle.

The OpenSpec Structure.

Before I discuss the individual artifacts of the OpenSpec workflow, let’s take a look at the directory organization of OpenSpec in a repo.

├── .openspec/
│   ├── config.yaml          # Framework rules, schema configurations, and linter settings
│   └── agent.md             # System prompt instructing the AI assistant how to use OpenSpec
├── project.md               # The Project Constitution: Global context (Tech stack, architecture rules)
├── specs/                   # 1. THE SOURCE OF TRUTH (Durable specifications)
│   ├── auth/
│   └── orders/
└── changes/                 # 2. THE DELTA CHANGES (Transactional task folders)
    └── change-042-add-filter/
        ├── proposal.md      # High-level business intent ("The What")
        ├── specs/           # Granular acceptance requirements
        ├── design.md        # Technical architecture blueprints ("The How")
        └── task.md          # Atomic checklist for the AI agent execution layer

The specs directory is the source of truth right at this time in your repo. It contains the system’s baseline logic for each completed and archived feature or domain. The agent regularly references the specs directory to maintain context across the system for new features or spec deltas and is shared across engineering because it is located right in the repo. When you are completed with a feature and archive it, the agent safely merges the spec deltas into the spec directory, and they become part of the source of truth.

The changes directory contains the artifacts for the feature or bug you are currently working on. Each change includes its own proposal.md, design.md, tasks.md, and a spec directory that contains one or more spec.md delta files. Each change should typically reflect a vertical slice of the feature which segues us nicely into…

Vertical Slicing.

Before starting the SDD workflow, the product owner should break the feature down into stories and stories into slices — structural verticals based on business value and domain components. From an Agile perspective, stories may contain multiple vertical slices. Stories that cross domains and/or cannot be completed in a single sprint should be broken into smaller manageable verticals, and each vertical should become a spec delta in the SDD workflow. Slice-based product management isn’t part of the OpenSpec framework, but it does make SDD much more manageable from a team and QA perspective.

Slicing is a verbose topic, and there are plenty of articles already written about it, so I won’t go into depth about it here. I linked a good primer about vertical slicing from the Monday blog at the end of this post if you want to learn more.

The reason that I mention it in this article is primarily that it is a great way to break stories into changes in the SDD workflow.

Let’s return to discussing the OpenSpec artifacts, starting with…

The Proposal.

First, the engineer works with product to capture the high-level plain-language goals, business constraints, and outcomes. Advanced teams use agent skills like grill-me here, forcing the AI agent to interrogate the engineer with edge-case questions before the document can finalize. Reviewing the Figma file during this session and even providing it to the agent via MCP is very helpful to make sure there is a clear understanding of the UI and experience between business, engineering, and the agent.

I found that doing a co-working session between the engineer and the PO with the agent works best for generating the proposal (proposal.md), and because the proposal is a plain English document it is easy to coordinate the conversation as you are both speaking the same language in the co-working session. Here you will work together to make sure that business and engineering are aligned, an area that teams often struggle with outside of this framework.

The Spec Deltas.

When talking about spec deltas, what we really mean are the feature or bugfix specifications that will ultimately update the existing “source of truth” once the feature or bugfix is completed and archived in the Spec Driven Development framework.

The specs are the highly precise operational requirements, frequently utilizing behavior-driven (Given-When-Then) syntax fenced blocks to establish requirement boundaries. The specs are controlled by the Product Owner and are driven by the proposal. Any deltas must be PO-approved. Specs should always be individually QA testable, and QA should build test cases that target the specs.

You might discover while drafting the design that an important constraint was overlooked that should be a spec because it is QA testable behavior. This might be a case for a valid spec addition, and you should address it with the PO to determine if it should be added. Since specs should be QA testable, any changes should also be brought to the attention of QA in case they have already written test cases and need to add more to address the spec addition or modification.

Specs should originate in your project management software and be tied to each associated slice in the story and be pulled into the repo as a spec delta. With an MCP for your project management suite, you can ask the LLM to generate the spec.md artifacts in the repo for you.

It should be noted that the source of truth is always the specs in the repo. NOT the stories in your project management software. QA, Product, and Engineering should always be aligned to the specs in the repo. Since the specs are plain English in Markdown and can be accessed by anyone in the company with a link to the file in your company's Git account, they can easily be viewed and referenced, even by non-engineering staff who lack access to a code editor.

The Design.

The design is the strict technical architecture blueprint and is owned by the engineer. This lays down the technical constraints — specifying patterns, models, contracts, fences, interfaces, etc. The design (design.md) ensures that these constraints are maintained across each slice and each engineer on the team. The design should ensure each spec is covered from an architectural perspective. I found using the grill-me skill is also useful here to make sure that you close any gaps that the agent would have to guess at during the execution.

The Tasks.

Turns the verified plan (from all of the artifacts) into an atomic checklist of minimal, independent execution steps that an AI agent can build without needing further guidance. As the LLM works through the execution, it will check off each item in tasks.md for you. Tell the agent to generate the tasks, and it will parse all of the artifacts and generate them for you.

The Execution.

This is where you finally set the agent loose to write the code, and you go hands off as the engineer. Simply tell the agent to start the execution, and it will be off and running, generating the code, following all of the specs, constraints, and design patterns that are defined in the artifacts, including those defined in the artifacts from archived slices to keep the solution cohesive.

After the build is complete, it is your opportunity to review the code that was generated. Before you open a PR, you should make sure that you do your own review to understand what was written as well as conduct dev testing to make sure the results fully align with the specs.

Sober Up.

SDD puts the team in control of the agent and ensures cohesive outcomes. Each slice's artifacts are archived and shared across slices (and engineers) through the repo. The agent has each slice's artifacts to reference in each subsequent slice, ensuring patterns are maintained, hallucinations are reduced, bugs are minimized, structural chaos is eliminated, and each slice is manageable in PR and in QA.

And the best part for engineers is it lets you actually engineer again instead of fighting with the agent all day.

You don’t have to feel like the drunk carpenter with a hammer anymore when using agentic AI to increase the efficiency of the development cycle.

Hold my beer.

I have experienced about a 20% time savings for feature delivery when using agentic SDD over a traditional software engineering workflow, but that’s not all. SDD forces the teams and departments to work together, to solve problems together, and think through more edge cases. This leads to far less bugs and a stronger, more cohesive product by coupling the specs to the repository and defining a single source of truth for the code base.

Learn more about the OpenSpec workflow at https://openspec.dev

Monday has a good primer on vertical slicing: https://monday.com/blog/rnd/vertical-slice/