Beyond Vibe Coding: Specification-Driven Development for MuleSoft Vibes

Vibe coding accelerates development, but without proper context it leads to repetition, refactoring, and architectural drift.

I’ve been using MuleSoft Vibes, Claude Code, GitHub Copilot, Codex, and other AI coding assistants for quite some time. I enjoy working with these models, especially when tackling repetitive tasks such as Writing documentation, Building sequence diagrams, updating configuration properties, creating tests, or implementing minor bug fixes.

After using it extensively, Couple things became very obvious:

• The quality of code depended heavily on the quantity of the context you provide.
• When AI lacks the context, it starts to make assumptions. And that’s where the problems begins!

In this article, lets look into the challenges we face with Vibe Coding? How do Spec-Driven Development gives AI Context persistence, and finally, implement a Mule application.

Here is the GitHub Repo for your reference: https://github.com/AskNerella/Mule-Spec-Driven-Development

Challenges with Vibe Coding

Don’t get me wrong, Vibe Coding is awesome! It accelerates how we build things. But, depending on the scale of the project, prompt complexity, and Agent context constraints, most the sessions will stumble into the following common pitfalls:

1. Repeated Prompts:
   Every time you start a new session, Agent needs to rebuild the context of your project. Without this information, the developers repeatedly provide the same architecture, business rules, and coding standards, increasing both Effort and Token Consumption.
2. Refactoring Loops:
   Most of the times, Developers leave the Agent in “Act mode”, forcing the Agent to be in Code-First Approach. Without the complete picture, AI fixes 1 bug, often breaking other functionalities. Leading the developers into a loop of subsequent prompts and fixtures.
3. Architecture Drift:
   Without context, every prompt becomes a it’s own decision. Over time, AI will introduce new patterns that are NOT relevant to your application like Pub-Sub in Request Response application, or implementing different error handling strategies for each endpoint and so on.

The following table summarizes the most common issues and their impact on enterprise software development.

Challenges with Vibe Coding

Notice how each of the challenges have the same root cause: lack of Context.

In other words, if we were to provide an ability to save context of every decision, business rules, coding standards, features, and implementation guidelines in a place and share it with the Agent, then the problem is solved.

And that’s exactly what Specification Driven Development is.

The Solution: Specification Driven Development (SDD)

The idea behind SDD is instead of prompting one task at a time with less context, we provide a comprehensive markdown files (.md) that contains everything a typical developer would need, like Business requirements, Functional and non-functional requirements, API Contracts / Credentials, Acceptance criteria and others.

With that specification in place, AI agents have enough context to plan an implementation, generate code, iterate and refine the solution much like an experienced developer would.

Also, the major advantage we get with SDD is persistent and version-controlled context. Instead of re-explaining architecture, standards, API conventions, going through code, and business rules in every conversation, the AI reads the same specification every time. The specification becomes the project’s long-term memory.

So, How do we implement it?

Note: I’ve provided TL;DR and Full walkthrough. Feel free to skip to sections as it seems fit.

TL;DR Walkthrough

Writing a complete specification from scratch would be tedious. Fortunately, tools such as OpenSpec and GitHub SpecKit automate most of the process. In this article, I’ll use GitHub SpecKit, but the overall workflow is applicable regardless of the tooling.

Using the following commands, I’ve generated the specification and MuleSoft Code.

Scaffold the Spec:

uvx --from git+https://github.com/github/spec-kit.git specify init PROJECT_NAME

MuleSoft Vibes Prompts:

# Define MuleSoft Development Rules
/speckit-constitution.md - Create best practices focused on code quality, testing standards, and performance requirements for MuleSoft application. Include the best practices for RAML API Specification and Implementation standards.

# Define the Goal
/speckit-specify.md - Create an API that exposes Salesforce Account, Opportunity and Case information. Consumers should be able to filter and sort records by Name and Created Date details.

# Provide Agent Clarifications
/speckit-clarify.md

# Plan Implementation
/speckit-plan.md - Use the latest connectors, Mule runtime version, and use Salesforce MCP Server to fetch available objects and fields.

# Implement Changes
/speckit-implement.md

That’s all.

Detailed Step-by-Step Implementation

Step 1 — Scaffold the Specification

Instead of writing a massive specification manually, let’s make our beloved AI take up the task. The trick is to generate a specification that both developers and AI agents can understand and implement consistently.

For this, we’ll use GitHub’s Spec Kit! It’s an open-source toolkit to initialize your project documentation, capture business requirements, and define acceptance criteria.

To get started, run the following command:

uvx --from git+https://github.com/github/spec-kit.git specify init PROJECT_NAME

Select your preferred toolkit and scripting language. Since MuleSoft Vibes uses the Cline toolset, I chose Cline and Python for scripting.

SpecKit Initialize

Once the initialization is complete, SpecKit creates two folders:

• .clinerules — Contains the rules and configurations used by our Cline Agent.
• .specify — Contains specification templates, prompts, and supporting files used for writing your specifications.

Since MuleSoft Vibes looks for rules in the .a4drules directory, rename .clinerules to .a4drules. This allows MuleSoft Vibes to discover and use the Spec Kit workflows.

You should now see the SpecKit slash commands available.

Step 2 — Defining Rules & Standards

Before we let our MuleSoft Vibes generate single piece of code, we have to establish the rules and how code must be written. In order to generate these rules, let’s navigate to our MuleSoft Vibes and prompt the following:

/speckit-constitution.md — Create best practices focused on code quality, testing standards, and performance requirements for MuleSoft application. Include the best practices for RAML API Specification and Implementation standards.

On completion, you should see the .specify/memory/constitution.md is updated with MuleSoft rules as constitution.

MuleSoft Vibes — SpecKit’s Constitution

Based on the generated principles, you may add or remove principles that works for your organization standards.

Generated Constitution

Step 3 — The Goal

Now, we describe the feature we are trying to build. Inside the MuleSoft Vibes, prompt the following:

/speckit-specify.md — Create an API that exposes Salesforce Account, Opportunity and Case information. Consumers should be able to filter and sort records by Name and Created Date details.

SpecKit converts takes this simple request and generates a detailed specification containing:

• Business requirements
• API endpoints
• Functional & Non-functional requirements
• Acceptance criteria

Generated Feature

Step 4 — Clarifications

Just like an architect or developer, after a functionality is defined, we’ve questions and some assumptions. To resolve this, we will run clarify command to let Agent ask us questions, remove any ambiguity to get better clarity on each feature it’s planning on building.

Get Sravan Nerella’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Prompt as following:

/speckit-clarify.md

Based on the Agent’s understanding so far, MuleSoft Vibes starts asking questions like Data Volume, Rate Limiting, Availability and SLAs, PII Handling and Compliance, and so on.

MuleSoft Vibes — SpecKit Clarify

This is where we remove the assumptions before the implementation begins. Repeat this process, till the Agent has all the details.

Step 5 — Plan the Implementation

Now that we’ve identified the required features, it’s time to define how the agent should implement them. In this step, we establish the technical implementation approach and requirements to include the Integration patterns to follow, the libraries and connectors to use, the source and target systems, and any other architectural or technical constraints.

Inside the MuleSoft Vibes, prompt the following:

/speckit-plan.md — Use the latest connectors, Mule runtime version, and use Salesforce MCP Server to fetch available objects and fields.

On completion, MuleSoft Vibes researches the relevant technical options and track its findings in the spec folder.

• research.md — Documents the technical research and implementation decisions.
• data-model.md — Defines the application’s domain entities, and relationships.
• quickstart.md — Provides instructions for building, running, and validating the project.
• plan.md — Captures the implementation strategy, architecture, milestones, and execution plan.

This research helps the agent make informed implementation decisions before generating code, such as selecting appropriate connectors, confirming compatible runtime versions, identifying integration patterns, and documenting important technical trade-offs.

MuleSoft Vibes — Plan

Step 6 — Creating Tasks / Todos

With the feature specification and implementation plan complete, the next step is to break the work down into manageable development tasks. Rather than asking the AI agent to build the entire application in a single prompt, we generate a task list that can be implemented incrementally.

Prompt the following:

/speckit-tasks.md

MuleSoft Vibes — SpecKit Tasks

On completion, MuleSoft Vibes generates a comprehensive task list inside the tasks.md file.

Generated — Tasks

Step 7 — Implementation

Now that you have all the details captured, now open MuleSoft Vibes and prompt /speckit-implement to start the implementation.

MuleSoft Vibes — Speckit Implement

Notice your implementation looks more correct than the Vibe coded Mule application.

Note: I’ve given few rules for the time being, Imagine adding everything.

Mule Application

Cool right?

Vibe Coding vs Spec Driven Development (SDD)

Vibe Coding vs Spec Driven Development

Final Thoughts

When it comes to Enterprise organization, more than the productivity, we are focused on Consistency, maintainability, governance and correct implementation. As we Architects and Developers, we can do better job only when we have the right context. That’s no different for Agents.

Before we jump directly into the code, it’s always a good idea to gather as much context as possible and make a plan to get predictable outcomes. That’s exactly what our Spec Driven Development delivers.

References:

• https://github.com/AskNerella/Mule-Spec-Driven-Development
• How I code With AI Agents By Owain Lewis
• Spec-driven Development: How AI Changed Everything (And Nothing) by Simon Martinelli
• GitHub’s SpecKit
• The Only guide you’ll need for GitHub Spec Kit By Den Delimarsky