luismori.

Vibe Coding Practice

Vibe Coding Cursor Claude Code

Vibe coding avanzado: un flujo de trabajo agéntico moderno para principiantes

Una guía práctica del ciclo completo de vibe coding: explora con Ask mode y OpenSpec, instala skills, genera código con Plan mode o herramientas basadas en especificaciones, revisa con Bugbot y /simplify, verifica en el navegador con Playwright MCP, despliega con MCP y convierte lo aprendido en skills personalizadas.

21 min de lectura

TL;DR

  • El vibe coding deja de ser accesible para principiantes cuando te saltas fases. Un ciclo de trabajo práctico no consiste en «un chat, un prompt y listo». Consiste en: explorar → equipar → construir → revisar → verificar → desplegar → recordar.
  • Empieza sin modificar archivos. Usa Ask mode de Cursor o /opsx:explore de OpenSpec mientras todavía estás definiendo qué construir. Ambos son modos de exploración de solo lectura: responden preguntas y exploran sin editar archivos.
  • Instala skills con criterio. Los directorios públicos como skills.sh permiten instalar flujos de trabajo SKILL.md con un solo comando, pero trata las skills de la comunidad como dependencias de código abierto e inspecciónalas primero.
  • Elige tu capa de planificación. Para tareas rápidas, el Plan mode integrado es suficiente. Para trabajo que deba sobrevivir a los reinicios del chat y pasar por una revisión de equipo, prefiere OpenSpec o GitHub Spec Kit.
  • Revisa con agentes, no por intuición. Bugbot de Cursor en los PR y /simplify de Claude Code son útiles para una pasada de limpieza, pero no reemplazan las pruebas ni el criterio humano.
  • Verifica en el navegador antes del merge. Playwright MCP permite que tu agente haga pruebas de humo interactivas de los flujos críticos de la UI; ejecutar playwright test en CI a partir de pruebas guardadas en el repositorio aporta repetibilidad.
  • Usa MCP para despliegues interactivos cuando tenga sentido. Railway ofrece un MCP remoto listo para usar en mcp.railway.com. La documentación de Cloudflare se centra en alojar tus propios servidores MCP; el despliegue de apps a Pages/Workers todavía suele hacerse con wrangler, builds conectados a git o CI.
  • Convierte las lecciones recurrentes en skills. Un patrón que he visto dar muy buenos resultados es plasmar en un SKILL.md reutilizable aquello que has corregido tres veces, en lugar de buscar un prompt ingenioso de un solo uso.

Qué aprenderás aquí

  • El flujo completo de vibe coding moderno, fase por fase
  • Qué modos y comandos integrados usar en Cursor y Claude Code
  • Cuándo Ask mode es mejor que Agent mode y cuándo OpenSpec es mejor que Plan mode
  • Cómo descubrir e instalar skills de forma segura desde registros públicos
  • Cómo encajan las herramientas basadas en especificaciones en el mismo ciclo sin demasiada ceremonia
  • Cómo integrar agentes de revisión automatizada como Bugbot y /simplify antes del merge
  • Cómo usar Playwright MCP y las pruebas de Playwright en CI como capa de verificación en el navegador
  • Cómo funciona el despliegue con MCP en Railway y Cloudflare, y dónde sigue siendo importante CI
  • Cómo pueden usar el mismo flujo de trabajo ingenieros junior y personas sin formación en ingeniería, con distintos niveles de profundidad

Este artículo es para ingenieros junior, personas que están cambiando de carrera y personas sin formación en ingeniería que ya conocen lo básico del vibe coding —describir una app, dejar que un agente escriba código y desplegar algo— y quieren ir un paso más allá: menos decisiones equivocadas, menos diffs intimidantes y un flujo de trabajo que sirva para algo más que un proyecto de fin de semana.

Si primero necesitas conocer el stack para principiantes, empieza por Cómo crear tu app con vibe coding. Para incorporar controles de calidad durante la generación, consulta Cómo mejorar la calidad del código durante el vibe coding.

El July 6, 2026, revisé la documentación de Cursor sobre Ask, Plan, Agent, Debug, Bugbot y subagentes; la documentación de Anthropic y Claude Code sobre Plan Mode y comandos con barra; la documentación de OpenSpec y las skills de OpenSpec del repositorio; la documentación de GitHub Spec Kit; la documentación de Railway MCP; la documentación de MCP remoto de Cloudflare; la documentación de Playwright MCP; y el repositorio de la CLI skills de Vercel que está detrás de skills.sh. El comportamiento de los productos que describo a continuación está respaldado por fuentes donde se indican. Las recomendaciones de flujo de trabajo son mi síntesis editorial para principiantes que buscan un modelo operativo práctico, no un ensayo comparativo de herramientas.

El flujo de trabajo de un vistazo

Piensa en el vibe coding avanzado como un sistema operativo con seis fases:

┌──────────────┐   ┌──────────────┐   ┌──────────────┐
│  1. EXPLORE  │──▶│  2. EQUIP    │──▶│  3. BUILD    │
│ Ask / explore│   │ skills.sh    │   │ Plan / spec  │
└──────────────┘   └──────────────┘   └──────────────┘
        │                                      │
        │                                      ▼
┌──────────────┐   ┌──────────────┐   ┌──────────────┐
│ 6. REMEMBER  │◀──│ 5. DEPLOY    │◀──│ 4. REVIEW    │
│ custom skills│   │ MCP + CI     │   │ + VERIFY     │
└──────────────┘   └──────────────┘   │ Bugbot/MCP   │
                                      └──────────────┘

No necesitas todas las fases en cada tarea. Un ajuste de CSS de una línea puede quedarse en Agent mode. Una funcionalidad nueva que afecta autenticación, base de datos, UI y despliegue debería recorrer el ciclo, incluida la verificación en el navegador cuando los usuarios interactúan con el cambio.

Fase 1: Explora antes de generar

El error más común de los principiantes es abrir Agent mode y decir «créame un SaaS». El agente generará encantado un diff enorme antes de que hayas definido el alcance.

Usa Ask mode cuando quieras respuestas, no cambios

La documentación de Cursor describe Ask mode como un modo de solo lectura: el agente puede buscar y explicar tu base de código, pero no editará archivos. Abre el panel Agent (Cmd+I / Ctrl+I), presiona Shift+Tab para cambiar entre modos y elige Ask.

Buenos prompts para Ask mode dirigidos a personas sin formación en ingeniería:

  • «Explícame este repositorio como si fuera un PM. ¿Cuáles son las partes principales?»
  • «¿Qué dejaría de funcionar si agregara cuentas de usuario?»
  • «Muéstrame tres formas de agregar un formulario de contacto, desde la más sencilla hasta la más escalable».

Cursor también documenta Debug mode para bugs complejos que necesitan evidencia en tiempo de ejecución. No lo necesitas desde el primer día, pero conviene saber que existe antes de pasar una hora discutiendo con Agent mode sobre una condición de carrera.

Usa OpenSpec explore cuando la idea todavía no esté clara

Si tu repositorio ya tiene OpenSpec instalado, /opsx:explore es la versión integrada al flujo de especificaciones de «piensa primero». La guía de exploración de OpenSpec indica que este modo es para cuando tienes un problema, pero todavía no un plan. Es deliberadamente abierto: no impone una conclusión ni modifica código automáticamente.

Esto combina bien con Ask mode:

Ask mode in Cursor
  -> understand the current codebase in plain language

/opsx:explore in chat
  -> turn understanding into options, trade-offs, and open questions

/opsx:propose
  -> only when you are ready to commit to a change folder in git

Para una comparación más profunda entre Plan mode y OpenSpec, consulta Reemplaza Plan Mode con OpenSpec en Cursor y Claude Code.

Regla para principiantes: si no puedes explicar la funcionalidad en un párrafo, todavía estás en la Fase 1.

Fase 2: Equipa al agente con skills

Una skill es una carpeta pequeña, normalmente centrada en SKILL.md, que le enseña a un agente un procedimiento repetible: revisar una API, escribir un changelog, seguir una lista de verificación de despliegue, auditar las fuentes de un artículo, etcétera.

Descubre skills en skills.sh

skills.sh es un directorio público de skills para agentes. El ecosistema funciona con la CLI skills de Vercel, que es de código abierto. El comando de instalación habitual es:

npx skills add owner/repo

Flags útiles de la documentación de la CLI:

# Install globally (available across projects)
npx skills add owner/repo -g

# Target a specific agent
npx skills add owner/repo --agent cursor

# Search the ecosystem
npx skills find "deploy cloudflare"

Las skills se pueden instalar en carpetas del proyecto, lo que facilita compartirlas con el equipo, o en carpetas globales del agente, lo que resulta útil para flujos de trabajo personales.

Trata las skills públicas como dependencias

Esta es la parte avanzada que los principiantes suelen omitir.

Un análisis de Snyk de February 2026 sobre 3,984 skills de ClawHub y skills.sh reportó que el 36.82% tenía al menos un problema de seguridad señalado y el 13.4% tenía al menos un hallazgo de nivel crítico según el modelo de severidad de Snyk; en algunos casos se detectaron inyecciones de prompts, secretos expuestos y payloads maliciosos. Los directorios públicos son prácticos, pero no tienen el mismo proceso de selección que una tienda de aplicaciones.

Antes de instalar una skill de la comunidad:

  1. Lee el SKILL.md y todos los scripts incluidos.
  2. Prefiere skills de autores o repositorios que conozcas.
  3. Cuando pruebes algo nuevo, empieza con alcance de proyecto, no global.
  4. Elimina las skills que ya no uses.

Para aplicar la misma idea a escala de una empresa, consulta Cómo crear un registro de skills para agentes de IA en tu empresa.

Consejo para personas sin formación en ingeniería: no necesitas escribir skills desde el primer día. Instala una skill revisada que atienda un problema recurrente —despliegues, preparación de PR, revisión de contenido— y observa cuándo el agente empieza a hacer lo correcto sin que tengas que volver a pegar las instrucciones.

Fase 3: Construye con un plan, no por intuición

Una vez que el alcance esté claro, elige una capa de planificación.

Opción A: Plan mode integrado (la más rápida)

El Plan mode de Cursor investiga la base de código, hace preguntas para aclarar dudas, crea un plan que puedes revisar y espera tu aprobación antes de editar. La documentación de Claude Code describe el mismo patrón mediante el modo de permisos de planificación.

Usa Plan mode cuando:

  • el cambio sea pequeño o mediano
  • solo tú necesites el plan
  • no necesites conservar especificaciones en git

Opción B: OpenSpec (ideal cuando las especificaciones deben vivir en git)

El ciclo predeterminado de OpenSpec es:

/opsx:explore   -> optional thinking
/opsx:propose   -> proposal + specs + design + tasks
/opsx:apply     -> implementation
/opsx:archive   -> merge decisions into openspec/specs/

Usa OpenSpec cuando:

  • los PM o tus compañeros de equipo necesiten revisar la intención antes del código
  • la funcionalidad requiera más de una sesión del agente
  • quieras que la respuesta a «¿por qué elegimos esto?» quede en git, no en el historial del chat

Consulta Cómo empezar con OpenSpec para configurarlo.

Opción C: GitHub Spec Kit (ideal cuando los equipos quieren plantillas formales de requisitos)

GitHub Spec Kit es otra capa basada en especificaciones. Su flujo principal es:

/speckit.specify -> requirements
/speckit.plan    -> technical plan
/speckit.tasks   -> task breakdown
/speckit.implement -> execution

Spec Kit incluye plantillas completas, controles de calidad como /speckit.clarify y /speckit.analyze, y una amplia integración con agentes. Puede sentirse más pesado que el perfil principal predeterminado de OpenSpec, por eso lo recomiendo cuando tu equipo ya quiere documentos de requisitos y listas de verificación explícitos.

Guía práctica para principiantes:

SituaciónEmpieza aquí
«¿Qué hace este código?»Ask mode
«Corrige este bug»Agent o Debug mode
«Agrega una funcionalidad mediana sin ayuda»Plan mode
«Agrega una funcionalidad con un PM o revisor»OpenSpec propose/apply
«Producto nuevo con requisitos formales»Spec Kit

Mi recomendación general para la audiencia de este artículo: Ask → Plan para trabajo individual, Ask → OpenSpec para trabajo compartido. Spec Kit cuando tu equipo ya trabaja con requisitos y listas de verificación.

Fase 4: Revisa con agentes modernos integrados

La velocidad sin revisión es lo que convierte el vibe coding en «funcionó una vez en mi laptop».

Cursor Bugbot en pull requests

Bugbot de Cursor revisa los diffs de los PR y deja comentarios en línea sobre bugs, problemas de seguridad y problemas de calidad. La documentación de Cursor indica que puede ejecutarse automáticamente cuando se actualiza un PR, o manualmente cuando alguien comenta cursor review o bugbot run.

Algunas funciones adicionales útiles de la documentación y las páginas de producto de Cursor:

  • Bugbot Rules mediante .cursor/BUGBOT.md para estándares específicos del equipo
  • Bugbot Autofix, que puede iniciar agentes en la nube para proponer correcciones en el PR
  • Skills /review-bugbot o /review dentro de Cursor 3.7+ para ejecutar una revisión al estilo de Bugbot antes de hacer push

Cursor anunció un cambio de precios de Bugbot en May 2026, de facturación por usuario a facturación basada en el uso. Considera el costo como un dato sujeto a cambios y consulta la página de precios actual de Cursor antes de adoptarlo en todo el equipo.

Patrón de revisión entre modelos: genera código con un modelo y deja que Bugbot lo revise con otro. Esto puede ayudar a detectar problemas que un solo modelo pasa por alto; tómalo como una heurística, no como una garantía. Consulta Subagentes de Cursor y /simplify de Claude Code para ver un flujo de trabajo relacionado.

/simplify de Claude Code para pasadas de limpieza

El comando integrado /simplify de Claude Code (v2.1.154+) revisa el código modificado para mejorar su reutilización, simplificación y eficiencia, y aplica correcciones. A partir de esa versión solo hace una pasada de limpieza; usa /code-review cuando quieras buscar bugs. Es útil después de implementar, pero no sustituye las pruebas ni la revisión de seguridad.

Mi ciclo recomendado antes de crear un PR para principiantes:

1. Run unit tests and build locally
2. Playwright MCP: smoke critical UI paths (or run `npx playwright test`)
3. Ask the agent to explain what changed in plain language
4. Run /simplify or /review-bugbot
5. Fix only the findings you understand
6. Open the PR

Si un comentario de revisión no tiene sentido para ti, pídele al agente que lo explique en Ask mode antes de aceptar la corrección.

Fase 4b: Verifica en el navegador

La revisión estática y la limpieza del diff no demuestran que la UI siga funcionando. Para aplicaciones web, agrega una capa de verificación en el navegador entre la revisión y el despliegue.

Dos capas: MCP interactivo + pruebas en CI

CapaHerramientaCuándo
Prueba de humo interactivaPlaywright MCP en Cursor o Claude CodeAntes de abrir un PR; verificaciones con navegador visible en la UI modificada
Regresión persistentenpx playwright test en GitHub ActionsEn cada PR y merge a main

Playwright MCP es el servidor MCP oficial de Microsoft. Controla un navegador real mediante instantáneas de accesibilidad, sin necesidad de un modelo de visión. El agente navega, hace clic y puede invocar herramientas de verificación como browser_verify_element_visible y browser_verify_text_visible.

Configuración de Cursor (.cursor/mcp.json):

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["@playwright/mcp@latest"]
    }
  }
}

Claude Code:

claude mcp add playwright npx @playwright/mcp@latest

Un prompt práctico antes del merge:

Using Playwright MCP:
1. Start the dev server (or use the staging URL).
2. Verify /health returns 200.
3. Walk through login and the primary happy path.
4. Report broken flows with snapshots.
Do not claim the task is done until critical paths pass.

Para que las verificaciones sean repetibles, pídele al agente que convierta los flujos de prueba de humo recurrentes en pruebas guardadas en el repositorio:

# Local inspection (headed)
npx playwright test --headed

# CI gate (headless)
npx playwright test

Consulta Flujo de desarrollo con OpenSpec para saber cómo integrar Playwright en los controles de calidad de tasks.md, y Agentes de uso de computadora para QA para conocer el patrón híbrido: deja que el agente se encargue de la navegación menos estructurada y que Playwright verifique el estado final.

Límites que debes tener en cuenta:

  • Playwright MCP es excelente para pruebas de humo interactivas; no reemplaza una suite de pruebas guardada en el repositorio y ejecutada en CI.
  • browser_run_code_unsafe ejecuta código arbitrario de Playwright y equivale a permitir la ejecución remota de código; habilítalo solo para clientes de confianza.
  • Los agentes en la nube y CI sin interfaz gráfica pueden necesitar --headless o un servidor MCP independiente (npx @playwright/mcp@latest --port 8931).

Fase 5: Despliega con MCP y CI

Cuando describes un despliegue en el chat sin herramientas, los agentes suelen inventar flags y variables de entorno. MCP (Model Context Protocol) le da al agente herramientas estructuradas para que no tenga que adivinar.

MCP remoto de Railway

Railway documenta un servidor MCP remoto alojado en https://mcp.railway.com. Usa OAuth en el navegador, así que para la configuración básica no necesitas pegar tokens de larga duración en un archivo de configuración.

Ejemplo de Cursor de la documentación de Railway:

{
  "mcpServers": {
    "railway": {
      "url": "https://mcp.railway.com"
    }
  }
}

Ejemplo de Claude Code:

claude mcp add railway --transport http https://mcp.railway.com

Una vez conectado, puedes hacer solicitudes de despliegue en lenguaje natural: listar servicios, volver a desplegar, inspeccionar variables o delegar tareas complejas a la herramienta railway-agent de Railway.

Railway también documenta railway skills install para instalar skills seleccionadas de Railway en Claude Code, Cursor, Codex y OpenCode: una versión integrada a la plataforma del patrón de skills.sh.

Cloudflare: alojamiento de MCP y despliegue a Pages/Workers

La documentación oficial de MCP de Cloudflare se centra en crear y alojar servidores MCP remotos en Workers con transporte Streamable HTTP, OAuth y la clase McpAgent del Agents SDK. Esto es diferente del MCP remoto listo para usar de Railway, pero sigue siendo útil de dos maneras:

  1. Servidores MCP de la plataforma. Puedes desplegar tu propio servidor MCP en Workers y conectar Cursor o Claude Code para acceder a herramientas específicas de Cloudflare.
  2. Opciones de despliegue de apps. El despliegue de tu app a Cloudflare Pages o Workers todavía suele hacerse con wrangler, builds de Pages conectados a git o GitHub Actions; luego puedes mantener la configuración de MCP en .cursor/mcp.json para que futuras sesiones del agente administren el proyecto en producción de forma segura.

También existen servidores MCP de la comunidad para despliegues en Cloudflare, pero trátalos como cualquier otra skill de terceros: inspecciona el repositorio antes de conectarlo a tu editor.

Para ver un ejemplo de despliegue de una app en Cloudflare integrado al repositorio de este stack de devlog, consulta Cómo crear tu app con vibe coding.

GitHub Actions como red de seguridad

MCP es excelente para despliegues interactivos. GitHub Actions sigue siendo la capa de confiabilidad: ejecuta pruebas, construye el sitio y despliega al hacer merge. Un patrón sencillo para principiantes:

feature branch
  -> agent implements
  -> browser verify + Bugbot + human review
  -> merge to main
  -> GitHub Actions builds, tests, and deploys

Incluso las personas sin formación en ingeniería se benefician de un archivo de workflow que demuestre que «main siempre se puede desplegar». Deja que el agente redacte el workflow y luego pídele que explique cada paso en Ask mode antes de hacer merge.

Fase 6: Guarda la lección en una skill

La diferencia entre el vibe coding intermedio y el avanzado es la memoria.

Cada vez que:

  • pegas la misma instrucción tres veces
  • rechazas el mismo tipo de diff incorrecto
  • explicas la misma particularidad de un despliegue
  • vuelves a escribir la misma lista de verificación para una revisión

…has encontrado una posible skill.

Skill personalizada mínima viable

---
name: deploy-staging-checklist
description: Run the staging deploy checklist for this repo. Use before merging frontend changes or when asked to deploy to staging.
---

# Staging Deploy Checklist

1. Run `npm run build`
2. Confirm env vars in Railway service `web-staging`
3. Deploy with Railway MCP or `railway up`
4. Playwright MCP or `npx playwright test`: smoke-test `/health` and the login flow
5. Summarize what changed for the PR description

Guárdala como .cursor/skills/deploy-staging-checklist/SKILL.md o en la ruta equivalente para tu agente. Mantenla breve. Enlaza a scripts si el procedimiento es largo.

Para repositorios con mucha UI, una skill complementaria ayuda:

---
name: ui-smoke-verify
description: Run browser smoke verification before merge. Use Playwright MCP for login, checkout, and /health.
---

# UI Smoke Verify

1. `npm run dev` or confirm staging URL
2. Playwright MCP: verify /health, login, and primary happy path
3. If UI changed, update `tests/e2e/` and run `npx playwright test`
4. Summarize pass/fail in the PR description

Para un marco de auditoría más amplio —cuándo usar reglas, skills o subagentes— consulta Audita tu flujo de trabajo diario con agentes de IA.

Consejos avanzados para ingenieros junior y personas sin formación en ingeniería

1. Elige el modo según el riesgo

Low risk, small change      -> Agent
Understanding only          -> Ask
Multi-file feature          -> Plan or OpenSpec propose
Production bug              -> Debug
Shared feature with review  -> OpenSpec or Spec Kit
Before merge                -> Bugbot + browser verify + local tests
After implementation        -> /simplify

2. Mantén los diffs pequeños

Los diffs grandes generados por IA son difíciles de revisar, seas junior o no. Pide una parte a la vez:

  • primero el esquema
  • después la API
  • luego la UI
  • pruebas con cada parte

3. Haz que el agente muestre su trabajo

Estos prompts funcionan bien para personas sin formación en ingeniería:

  • «Antes de editar, enumera los archivos que vas a modificar y explica por qué».
  • «Explica las ventajas y desventajas en lenguaje sencillo antes de elegir un enfoque».
  • «Si no estás seguro, hazme una pregunta en lugar de adivinar».

4. Usa subagentes solo cuando el aislamiento ayude

Los subagentes de Cursor destacan cuando una tarea secundaria saturaría el hilo principal: explorar el historial de un repositorio, investigar en paralelo o procesar salidas extensas de terminal. Son complejidad opcional. No empieces por ahí.

5. Crea una lista personal para dar una tarea por terminada

Antes de dar una tarea por terminada:

  • Puedo explicar qué cambió sin leer el diff línea por línea
  • Las pruebas o la verificación de humo en el navegador pasaron
  • Se completó la revisión de un agente o de una persona
  • El proceso de despliegue es conocido y repetible
  • Las instrucciones recurrentes quedaron registradas como una skill o regla

Una semana de ejemplo para un equipo principiante

Monday
  Ask mode: map the repo and pick one feature slice
  /opsx:explore or Plan mode: agree on approach

Tuesday
  Install one public skill + one project rule
  /opsx:propose or Plan approval

Wednesday
  /opsx:apply or Agent mode implementation
  commit small chunks

Thursday
  Playwright MCP smoke on changed UI paths
  /simplify or /review-bugbot
  open PR, enable Bugbot

Friday
  merge after CI green (including headless Playwright if configured)
  deploy via Railway MCP, `wrangler`/Pages, or your CI pipeline
  write one custom skill from the week's corrections

Ese ritmo es deliberadamente aburrido. Lo aburrido es lo que permite que el vibe coding sobreviva al contacto con usuarios reales.

Lo que este flujo de trabajo no reemplaza

Seamos honestos sobre los límites:

  • Las skills y MCP no eliminan la necesidad de una revisión de seguridad. Las skills públicas pueden ser maliciosas. Las herramientas MCP pueden realizar acciones destructivas si las apruebas sin revisarlas.
  • Bugbot y /simplify no reemplazan las pruebas. Detectan problemas útiles, pero no demuestran que todo sea correcto. Las pruebas de humo de Playwright MCP ayudan, pero CI debe seguir ejecutando archivos playwright test guardados en el repositorio para proteger contra regresiones.
  • Las herramientas basadas en especificaciones no reemplazan el criterio de producto. Hacen visibles los desacuerdos antes, lo cual solo ayuda si alguien lee los artefactos.
  • Un flujo de trabajo avanzado no significa usar más herramientas. Si Plan mode por sí solo funciona para tu tarea, úsalo.

Fuentes

Fuentes primarias y oficiales consultadas el July 6, 2026:

Artículos relacionados en este devlog: