DEV Community: Rocio Jacob

Vibe coding got me 80% there. Spec-Driven Development got me the other 20%.

Rocio Jacob — Fri, 04 Sep 2026 19:46:35 +0000

I like vibe coding. I'm not here to shame anyone out of it. Some of the best things I've shipped started as a half-formed idea typed into a chat box at 11pm.

But if you've done this for more than a weekend, you know the shape of the problem. The first prompt is magic. The fifth one is negotiation. By the fifteenth you're re-explaining a decision you already made twice, the agent has quietly renamed your data model, and you're one "fix the header" away from deleting the folder and starting over.

The bottleneck was never the code. The agent writes code faster than I ever will. The bottleneck is clarity — and clarity is the one thing I kept keeping in my head instead of in the repo.

That's the gap Spec-Driven Development fills, and Spec Kit is the toolkit that makes it practical.

What is Spec-Driven Development?

SDD is a simple inversion: the specification is the artifact you maintain, and the code is what gets generated from it.

Not "write a PRD, then throw it away once real work starts." The spec lives in the repo, next to the code, in version control, and it's the thing you edit when you want the software to change.

A real spec answers three things:

What the system does — entities, flows, screens, rules
How it must behave under constraints — auth, performance, compatibility, accessibility
Why the key decisions were made

And it deliberately does not answer "which framework." That comes later, on purpose.

The reason this matters more now than it did in 2015: your agent doesn't have your context. It has whatever you gave it in the last 4,000 tokens. A spec is context that survives a new chat window, a new model, and a colleague who joins on Tuesday.

So what is Spec Kit?

Spec Kit is GitHub's open-source toolkit for doing this. It launched in September 2025 as an experiment and it did not stay an experiment: 130K+ stars, 270+ contributors, 38 agent integrations, and a whole ecosystem of community extensions and presets.

Install and scaffold:

uv tool install specify-cli
specify init my-project --integration copilot

That drops a .specify/ folder plus slash commands into your agent (Copilot, Claude Code, Codex, Gemini, Cursor, Kiro, Zed — most of them). Then the workflow runs in chat:

/speckit.constitution → /speckit.specify → /speckit.clarify → /speckit.checklist
→ /speckit.plan → /speckit.tasks → /speckit.analyze → /speckit.implement

Every step produces a Markdown file that feeds the next one. Nothing is a black box. No proprietary editor. You can open any of it and type over it with your own hands, which you absolutely should.

Two pieces deserve special attention:

The constitution (.specify/memory/constitution.md) holds your non-negotiables. "Static-first delivery." "No new dependencies without justification." "Every migration ships with a rollback." Every later phase is checked against it. This is the single highest-leverage file in the whole setup, and most people leave it as boilerplate.

The gates — /speckit.clarify, /speckit.checklist, /speckit.analyze — are what separate this from prettier prompting. clarify hunts for ambiguity before you plan. checklist grades the requirements themselves. analyze cross-checks spec vs. plan vs. tasks before a single file gets written. For a quick prototype you can skip them. For anything you'll have to maintain, don't.

Why would I use it?

Four honest reasons.

1. It moves the argument earlier. Fixing a misunderstanding in a Markdown file costs a minute. Fixing it after 40 generated files costs an afternoon and your patience.

2. It makes the work reviewable by people who don't read code. This is the one that changed things for me. A spec is something you can send to a stakeholder, a PM, or a boss, and get real feedback on. Try doing that with a chat transcript.

3. Model churn stops being a threat. If the agent produced something mediocre, you don't lose the thinking. Delete the source, switch models, re-run /speckit.implement. Your spec is the durable asset; the implementation is disposable. That's a much better position to be in every time a new model drops.

4. It scales past one person. Chat context doesn't merge. Markdown in a git branch does.

How will my projects actually improve?

Concretely, from the pattern I keep seeing:

Fewer "start over from scratch" cycles. The rework loop shrinks because the misunderstanding gets caught upstream.
Edge cases you wouldn't have thought of. The spec templates force sections for acceptance scenarios and edge cases. The agent fills them, you correct them. Free QA thinking.
Onboarding stops being a conversation. "How does this work?" → read specs/001-*/spec.md.
Better decisions, because you had to write them down. Half the value shows up before you run anything. Writing the spec is where you notice that you never decided how episodes are ordered, or what happens when the list is empty.
Structured additive change. New feature = new spec folder = new branch. Your third feature doesn't quietly rewrite your first.

The honest trade: it's slower on day one. For a landing page you'll ship this afternoon, this is ceremony. For anything with more than one screen, more than one contributor, or a lifespan longer than a demo, it pays for itself fast.

Are there real-world examples?

Yes, and I want to give you both halves of the picture.

The supportive side: GitHub dogfoods Spec Kit on Spec Kit itself for substantial features. AWS built the same philosophy directly into Kiro and publishes customer cases where multi-day features shipped in a fraction of the human time when authored spec-first. There's a growing academic literature framing specs as the version-controlled contract between humans and agents, and community walkthroughs now cover brownfield adoption in .NET, Java, and Go/React codebases.

The skeptical side, which you should read too: Thoughtworks put SDD in the Assess ring of their Technology Radar, not Adopt, and they push back hard on the idea that specs replace code as the source of truth. There's a fair critique circulating that SDD is contract-design and waterfall with better branding — and the sharpest version of that critique is also the best argument for it: the value is the thinking you do while writing the spec, not the tooling around it. Vendor-reported multipliers should be treated as directional, not proven.

My read: the durable, less-disputable finding is that the human's time moves from typing implementation to specifying and reviewing. Whether that's a 3x or a 1.2x depends entirely on you.

How do I apply it to a Product Engineering pipeline?

This is where it gets interesting, because the workflow maps almost one-to-one onto roles you already have.

Phase	Command	Who owns it
Guardrails	`/speckit.constitution`	Tech lead + product, once per repo
What & why	`/speckit.specify`	Product / PM
Kill ambiguity	`/speckit.clarify` + `/speckit.checklist`	Product + eng together
How	`/speckit.plan`	Engineering
Breakdown	`/speckit.tasks`	Engineering
Consistency audit	`/speckit.analyze`	Whoever reviews the PR
Build	`/speckit.implement`	The agent, supervised

A few things that make this work in a real org rather than a demo:

The spec review is the new design review. Put it in the PR. That's your approval gate, and it's a much better artifact to argue over than a diff.
One feature, one branch, one spec folder. Spec Kit picks up the active feature from your git branch, so this falls out naturally.
Brownfield is supported and it's the normal case. Don't try to retro-spec your whole system. Initialize in place with specify init --here --force --integration <key> on a clean review branch, write a constitution from rules that are already true in your repo, then pick one bounded change — a CSV export, one endpoint — and run the loop on that.
Decide up front how specs age. Frozen historical snapshot per feature, or living contract you regenerate from? Both are valid. Choosing neither is how you end up with docs that lie.
Wire the constitution into CI eventually. Community extensions already do architecture and compliance gates. That's where this stops being a personal workflow and starts being governance.

Tips to actually get value out of it

Write the constitution yourself. Let the agent draft it, then delete two-thirds. Short and true beats long and aspirational. Unrealistic rules become noise the agent learns to ignore.
Use different models for different phases. Reasoning-heavy models are good at scaffolding specs and plans; I switch for implementation. Experiment — it's the only way to find out what works for your stack.
Never skip /speckit.clarify on real work. Unresolved [NEEDS CLARIFICATION] markers are the agent telling you where it's about to guess.
Edit the Markdown with your hands. People freeze up because "the LLM wrote it." It's a text file. If you want the logo centered, add a functional requirement and move on.
Don't over-specify. If your spec has become pseudocode, you've written the program twice. Specify behavior and constraints, not implementation.
Implement in phases. Core flow first, validate, then the rest. Dumping 60 tasks into one run saturates context and quality falls off a cliff.
Keep the spec free of tech choices. It feels unnatural. Do it anyway — it's what lets you regenerate the same product on a different stack later.
Feed it real design context. Hook up MCP servers (Figma, your issue tracker) so the plan references your actual design system instead of inventing one.
Treat a bad output as a spec bug first. Before you re-prompt, go read what the spec actually said. Nine times out of ten it's ambiguous there.

What should I research before starting?

Set aside an afternoon, not a week:

Your toolchain: uv / uvx for the CLI, and which integration key matches the agent you already use.
The core concept pages in the Spec Kit docs — "What is SDD?" and "Spec Persistence Models." Those two decide how you'll work six months in.
EARS notation for writing requirements that are unambiguous by construction. Cheap to learn, big payoff on spec quality.
The critiques. Read the Thoughtworks position and the "same patterns, new hype" argument before you adopt this. You'll use the tool better if you know where it's weak.
Your own repo's actual conventions — README, ADRs, CI config, contribution guide. That's the raw material for a constitution that's true instead of invented.
The alternatives, so you're choosing rather than defaulting: Kiro, cc-sdd, BMAD, and the Spec Kit preset ecosystem if you want a different process shape entirely.

The one-line version

Vibe coding optimizes for the first version. Spec-Driven Development optimizes for every version after that.

Implementation is cheap now. Clarity isn't. Spec Kit is a way of putting your clarity somewhere it won't evaporate when you close the tab.

Start small: pick one feature you were going to vibe out this week, run it through the loop instead, and compare how it feels on the third change request.

Sources & further reading

Spec Kit repo and docs — https://github.com/github/spec-kit · https://github.github.com/spec-kit/
Adopting Spec Kit in an existing project — https://github.github.com/spec-kit/guides/existing-projects.html
Thoughtworks on spec-driven development — https://www.thoughtworks.com/insights/blog/agile-engineering-practices/spec-driven-development-unpacking-2025-new-engineering-practices
"Spec-Driven Development in 2026: What It Is, the Tooling, and How Teams Actually Use It" (DEV) — https://dev.to/krlz/spec-driven-development-in-2026-what-it-is-the-tooling-and-how-teams-actually-use-it-2fk2
"Spec-Driven Development for Agentic Software Engineering" (arXiv) — https://arxiv.org/html/2609.00252v1

Getting Started with AWS Elastic Beanstalk: A Step-by-Step Guide

Rocio Jacob — Fri, 19 May 2023 09:49:09 +0000

In today's rapidly evolving world of web development, deploying and managing applications in the cloud has become a crucial aspect of every project. AWS Elastic Beanstalk simplifies the process by providing a platform-as-a-service (PaaS) solution that streamlines the deployment and management of your applications. In this tutorial, we will walk you through the step-by-step process of setting up a project in AWS Elastic Beanstalk.

Step 1: Sign in to the AWS Management Console

To begin, log in to the AWS Management Console using your AWS account credentials. If you don't have an AWS account, you can sign up for one easily on the AWS website.

Step 2: Navigate to Elastic Beanstalk

Once you're logged in, navigate to the Elastic Beanstalk service. You can find it by searching for "Elastic Beanstalk" in the AWS Management Console search bar.

Step 3: Create a New Application

Click on the "Create Application" button to start creating your new application. Provide a meaningful name for your application and optionally enter a description to help identify its purpose.

Step 4: Create an Environment

After creating your application, the next step is to set up an environment where your application will run. Click on the "Create environment" button.

Step 5: Configure the Environment

Choose the environment type that suits your project, such as a Web Server Environment or a Worker Environment. Provide a unique name for your environment and specify the URL that users will access your application from.

Step 6: Select the Platform

Choose the platform that matches your project's technology stack. Elastic Beanstalk supports a wide range of platforms, including Java, Node.js, Python, Ruby, PHP, and more. Select the platform that best suits your application.

Step 7: Customize Additional Settings

Take advantage of the additional settings to fine-tune your environment. Customize the platform version, database configuration, security settings, and environment variables as needed to meet your application's specific requirements.

Step 8: Review and Create the Environment

Review all the configuration details you have provided and ensure everything is correct. Once you are satisfied, click on the "Create environment" button to start the deployment process.

Step 9: Configure Application Code Deployment

Now that your environment is set up, you can configure the deployment of your application code. Choose the desired method: uploading a ZIP file or connecting to a code repository.

Step 10: Deploy Your Application

With your environment and code deployment configured, you are ready to deploy your application. Elastic Beanstalk will create the necessary resources and deploy your application code.

Step 11: Access Your Application

Once the deployment is complete, you can access your application by visiting the URL provided in the Elastic Beanstalk environment dashboard. Congratulations! Your application is up and running in Elastic Beanstalk.

AWS Elastic Beanstalk simplifies the process of deploying and managing applications in the cloud. By following the steps outlined in this tutorial, you have learned how to create an application, set up an environment, configure instance and capacity settings, customize additional configurations, and deploy your application code. Elastic Beanstalk handles the underlying infrastructure, allowing you to focus on your application development. Embrace the power of Elastic Beanstalk and enjoy the seamless experience of deploying your applications in the cloud.

Building and distributing Vite.js projects with Amplify

Rocio Jacob — Tue, 04 Oct 2022 14:20:09 +0000

On our last project we decided to use vite.js. We can now claim we LOVED IT! We loved vite's speed regarding serving our file and found it extremely intuitive and right for the project.

Yet development with vite implied quite a problem regarding our hosting on the web app. The fact vite is module based and has css code splitting, made the hosting of the project tough.

When we first started hosting it on amplify, we had the issue that the enviroment was completely blank, and none of the page contents were fetched by the service.

We fixed the initial problem by using the redirect AWS suggests for SPA's:
</^[^.]+$|\.(?!(css|gif|ico|jpg|js|png|txt|svg|woff|ttf|map|json)$)([^.]+$)/>

Beware with this redirect link as it's position on teh rewrites and redirects can affect the performance of the page.

So our rewrites and redirects page ended up looking like this:

Then we had to adapt the build settings so that the dist folder vite creates can be found by amplify:

Our build file ended up looking like this:

version: 1
frontend:
  phases:
    preBuild:
      commands:
        - npm ci
    build:
      commands:
        - npm run build --prod
  artifacts:
    # IMPORTANT - Please verify your build output directory
    baseDirectory: dist
    files:
      - '**/*'
  cache:
    paths:
      - node_modules/**/*

After following this steps, we could host the webpage correctly, yet amplify still had arbitrary issues on fetching some webpages. For example redirects were not working and took us to a blank page that claimed Amplify CloudFrontURL couldn't find the page.

Apparently some fractions of the code weren't being found. This is the problem that held us days, and to which we struggled to find the solution. The thing was, we had to change some things in vite.config.js that were making the base of the project untraceable to amplify.

Our vite.config.js ended up looking like this. Adding base: './index.html' was what managed to fix the mistake of arbitrary 404 we had:

import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'
import mkcert from 'vite-plugin-mkcert'

export default defineConfig({
  server: { https: true },
  plugins: [react(), mkcert()],
  base: './index.html',
  build: {
    input: {
      app: './index.html', // default
    },
  },
  resolve: {
    alias: {
      './runtimeConfig': './runtimeConfig.browser',
    }
  }
})

We hope this solution helps someone struggling with the same problem.

Building a React Native Filter - Part 1

Rocio Jacob — Thu, 17 Feb 2022 18:08:39 +0000

A couple of weeks ago a client asked us to create an application that displayed all of it's stores. The app had to be built in React Native in order to speed up development time and ensure compatibility among Android and IOS and had to include a full list of our client's stores. This list was fetched from a MongoDB collection, and came as an array of objects containing information for each store (such as location, phone number, email, coordinates). Obviously, a plain list of objects doesn't satisfy a customer, as scrolling through a 189 store list to find a specific one might be extremely painful. So with React Native (our choice to build fast compatible apps) we decided to create a filter. The filter we built included features such as searching, categorizing and ordering according to proximity.

In this article, we will show you how the filter was built by using a mock API to build a filter with search and categorization (in the future we will write another article to show how to handle location based objects, order them and filter them). The tutorial will not cover a step by step of the whole code, but will go through the most important parts when building it. You can find the whole code in this Expo Snack.

You will see this is a front-end built filter, and doesn't use backend filtering. Although backend filtering is a good option (particularly to handle long lists), it works smoothly with the data we have. Bear in mind if you have millions of elements mapping through them will impact negatively on the app's performance.

So, to start we will be using Fruityvice's API that will bring a response with an array of objects containing different information about fruits. An example for the response we get is:

[{
    "genus": "Malus",
    "name": "Apple",
    "id": 6,
    "family": "Rosaceae",
    "order": "Rosales",
    "nutritions": {
        "carbohydrates": 11.4,
        "protein": 0.3,
        "fat": 0.4,
        "calories": 52,
        "sugar": 10.3
    }
}, ...]

Project Structure

Let's get hands on it to the real code. The structure our project will take is:

A main App.js file where most of the work will happen, here we will set the main states and fetch our data.
Components folder.
Assets folder.
Data folder in order to save the initial state some variables will have.

Fetching the API

The first thing we should do, is fetch the API. We fetch it through a simple fetch function built in a useEffect, meaning each time the component mounts, the API is fetched and the fruits "refresh". The response is saved as a json and we can now work with it.

  useEffect(() => {
    fetch('https://www.fruityvice.com/api/fruit/all')
      .then((response) => response.json())
      .then((json) => setFruits(json))
      .catch((error) => console.error(error))
      .finally(() => setLoading(false));
  }, []);

Our App.js Component

We create a <SafeAreaView /> for our App.js (so that the content we build is contained within a visible space). Inside the SafeAreaView we will have three components, the AppBar (that will hold the modal and a logo for our app), the modal itself, and the Wrapper (called <FruitsWrapper />) where we will render the "card-styled" list of fruits with their information.

On the App.js we'll also do two things that will help us handle the Filtering correctly.

First we'll set a couple of states:

  const [fruits, setFruits] = useState([]);
  const [filter, setFilter] = useState(initialFilter);
  const [intermediateFilter, setIntermediateFilter] = useState(initialFilter)
   const [modalVisible, setModalVisible] = useState(false);

fruits holds the array of objects we fetch from the API
filter filter is the real filter that will be applied when the user decides to APPLY the filter within the modal
intermediateFilter is a filter that is setted while the user interacts with the modal, once the apply button is pressed, the intermediateFilter becomes the actual filter
modalVisible will handle modal visibility

Why the intermediateFilter? the intermediate filter ensures the fields the user clicks while in the modal will be applied correctly. We need to save the user choices as he/she advances through the modal.

Both the intermediateFilter and the filter take up an initialFilter. What is this? The initialFilter is a js written in our data folder. initialFilter is an object that hold's the initial state of the fields we are going to filter.

export const initialFilter = {
  query: '',
  genus: '',
  carbohydrates: '', 
}

The AppBar

The App bar is extremely simple. We have a logo, and a button that when pressed will change the state of the modalVisible variable to true and show us the modal.

Displaying the info

Before we filter we want to display multiple cards containing information about the fruits so we can then sort them according to the user's choices. For this we have two components <FruitsWrapper /> and <InfoCard/>

<FruitsWrapper /> is the wrapper where we map through the fruits and display them. In this Wrapper we will also have the filtering instance. So as long as there no filters it will display the complete object we receive from the fetch. If there filters, we will push fruits to a new variable that will be empty.
<InfoCard/> is the UI of the card that will hold the object's info. We build only one object, and then map the fetch response and render each fruit (with it's information in the cards).

The `<FruitsWrapper />`

This component is SUPER important. As the logic applied here makes the magic to display the filtered content.

You can see that at the beginning of the component I declared two boolean variables: filterFruits and empty (empty will not be used yet, but will serve us to display that no fruits were fetched). I then set up an empty filterArray where the fruits I filter with my modal will be pushed. After doing this I set filterFruits equal to allFruits, the later one being the whole fruit array we brought on the first place. The following logic is key to filtering:

if (filterFruits != undefined && && typeof filterFruits === 'object'){
    filterFruits.map((fruit) => {
    // I have two things, the filter and the fruits genus (in the array) so if I filter I only want to show the ones that match the genus
    if (filter.genus != '' && !fruit.genus.includes(filter.genus)) {
      return
    }

    filterArray.push(fruit)

  })
        if (filterArray.length > 0) {
        filterFruits = filterArray;
      }
} else {
  filterFruits = false
  empty= true
}

The filtering happens if filterFruits (before known as allFruits) is not undefined (meaning it has some content) and the type of this is an object. What we do is map through each fruit, if it doesn't match the parameters we want it to, we return, else we push it to the filterArray. If the filter array is bigger than 0 (meaning fruits were pushed) filterArray (the one where we pushed) becomes filterFruits.

The Modal

The modal is the most important part of this tutorial. For this we will use React Native's built in modal.

In the application we built for the client we had two modal instances, the filtering modal (that used the native modal) and an alert modal (where we used UI Kitten's modal). We like the native modal because it offers us the possibility of deciding how it transitions and it's easier to set it up fullscreen.

As we mentioned previously we chose to use an intermediate filter within the modal so that the state management can be smooth, and we can access the different states (Remember that the initalFilter was an object?). Yet, after the user click's the apply button, we want the intermediateFilter to become the actual filter

A key thing we also have in this modal is the list of all the genus. Instead of mapping all the fruits and displaying the genus, in the App.js we created an array with all the unique genus (so that we don't get them repeated). The following code creates an array of all the fruit.genus unique values:

const genusResult = allFruits.map(item => item.genus)
  .filter((value, index, self) => self.indexOf(value) === index)

We loop through this array that we built to create the radio buttons, as you will see in the RadioButton.js file. This file holds custom built Radio Buttons. The good thing about this is that they are fully customizable, and give us more control over the user selection.

The thing is, the user can only select one genus, and when the user selects the genus selected is saved in the intermediate filter. Once the user decides which genus he/she wants to see, he applies the filter and because of the logic applied in the <FruitsWrapper /> only the fruits that have that genus will be shown.

Closing Remarks

This was a quick tutorial over how to build the filter. We hope it was easy to follow and in the second part we will talk about querying filtering.

Remember the full code is in our Expo Snack