DEV Community: Bezael Pérez

SDD en proyectos brownfield: pros, contras y la estrategia que realmente funciona

Bezael Pérez — Tue, 26 May 2026 15:51:42 +0000

SDD: pros, contras y la estrategia que realmente funciona

Hay un tipo de desarrollador que me resulta muy familiar.

Abre un tutorial de IA. Ve al tipo construir una app desde cero en 20 minutos. Se emociona. Abre su proyecto real. Y se da cuenta de que lo que tiene delante no tiene nada que ver con lo que acaba de ver.

Porque su proyecto no es un repo vacío con carpetas bien ordenadas.

Su proyecto es un monolito de cuatro años con lógica de negocio enterrada en helpers que nadie sabe quién escribió. Con una tabla de base de datos que tiene 47 columnas y ninguna tiene comentario. Con tres formas distintas de hacer la misma cosa según en qué parte del código estés. Con una carpeta llamada utils que tiene 3.000 líneas.

Eso es un proyecto brownfield.

Y la IA no te lo va a limpiar sola.

Pero hay algo que sí puedes hacer. Y funciona mejor de lo que parece.

Primero, el problema real

Cuando la gente descubre Spec-Driven Development, lo primero que piensa es: "genial, pero eso es para proyectos nuevos."

Es un razonamiento lógico. SDD habla de escribir la spec antes de empezar. En un brownfield ya empezaste hace años. El barco ya está en el agua. No puedes volver al puerto a hacer los planos.

Esa lógica tiene un fallo.

SDD no es un método para proyectos. Es un método para cambios.

Y tú, trabajes en el proyecto que trabajes, vas a hacer cambios. Hoy, mañana, la semana que viene. Cada vez que añades una feature, cada vez que corriges un bug, cada vez que tocas algo que otro construyó y que no entiendes del todo.

Ahí es exactamente donde entra SDD. No en el origen del proyecto. En cada cambio que haces a partir de ahora.

Lo que SDD sí resuelve en brownfield

El sistema deja de ser una caja negra.

Cuando escribes una spec sobre algo que ya existe, el primer paso es describir cómo funciona ahora. No cómo debería funcionar. Cómo funciona.

Ese ejercicio solo ya tiene un valor enorme.

Muchos equipos llevan años trabajando en sistemas que nadie sabe describir con precisión. Hay intuición. Hay memoria histórica. Hay "creo que funciona así pero no estoy seguro." La spec obliga a convertir esa niebla en texto.

Y el texto se queda. El texto se versiona. El texto lo puede leer el agente.

El agente tiene una frontera.

El problema clásico del brownfield con IA: le pides al agente que cambie una cosa y te cambia cinco. Porque el agente no sabe qué está permitido tocar y qué no.

Una spec con una sección "fuera de scope" resuelve eso de forma radical.

El agente no adivina. Ejecuta lo que le das. Si le das una spec que dice explícitamente qué no entra en este cambio, el agente no lo toca. No porque sea listo. Porque tiene instrucciones.

Las regresiones bajan.

No desaparecen. Bajan.

Si la spec describe el comportamiento que tiene que seguir siendo verdad cuando el cambio esté hecho, el agente tiene un criterio para verificar su propio trabajo. "¿Lo que he implementado cumple lo que dice la spec?" Es una pregunta que el agente puede responder.

Sin spec, el agente no tiene criterio. Tiene intuición. Y la intuición de un agente en código heredado que no entiende del todo es una fuente inagotable de bugs que aparecen tres semanas después.

El conocimiento se acumula.

Este es el punto que más se subestima.

Cada mini-spec que escribes es documentación que se queda en el repo. No en Notion. No en Confluence. No en la cabeza del desarrollador que lleva más tiempo en el equipo. En el repo, junto al código que describe.

Con suficientes cambios bien especificados, el sistema empieza a tener memoria. Los módulos más críticos tienen spec. Los flujos más usados están descritos. El onboarding de alguien nuevo mejora sin que nadie lo haya planificado.

Es un efecto secundario del método. Pero es uno de los más valiosos.

Lo que SDD no resuelve

Aquí hay que ser honesto.

El código mal estructurado sigue siendo malo.

Una spec no refactoriza nada. Si tienes un módulo de 800 líneas con efectos secundarios en tres capas distintas, la spec te ayuda a acotar el cambio. Pero el módulo sigue siendo un desastre.

SDD no es una excusa para no hacer el trabajo de limpieza cuando es necesario. Es una herramienta para hacer cambios seguros. No es la misma cosa.

Sin tests, la spec flota en el aire.

La spec describe el comportamiento esperado. Pero si no hay nada que verifique automáticamente que ese comportamiento es real, la spec es solo texto.

Los tests y la spec se complementan. La spec dice qué tiene que ser verdad. Los tests comprueban que lo es. Si tienes spec pero no tienes tests, tienes la mitad del sistema. La mitad útil para pensar. Pero no la mitad que te avisa cuando algo se rompe.

Documentar retroactivamente un sistema grande es trabajo.

No hay atajo aquí. Si tienes un monolito de cinco años y quieres tener spec de todo antes de tocar nada, vas a tardar meses. Y probablemente no lo vas a terminar nunca porque mientras escribes specs el negocio sigue pidiendo features.

La solución no es intentar especificarlo todo de golpe. La solución es no intentarlo.

La estrategia que realmente funciona

No especifiques el sistema. Especifica el cambio.

Es la diferencia entre un proyecto paralizado y uno que avanza.

El flujo es este:

1. Identifica exactamente qué vas a tocar

No el sistema. No el módulo entero si solo necesitas cambiar una parte de él. La unidad mínima de trabajo que tiene sentido hacer de forma independiente.

Cuanto más pequeño sea el alcance, más fácil es especificarlo. Y cuanto más fácil es especificarlo, más probable es que lo hagas.

2. Escribe el estado actual antes que el estado deseado

Este es el paso que más gente se salta. Y es el más importante en brownfield.

Antes de escribir lo que quieres que haga el sistema, escribe lo que hace ahora. Con precisión. No "valida los datos del formulario." Qué valida, cuándo, qué pasa cuando falla, qué no valida aunque debería.

Ese ejercicio tiene dos efectos. Primero, te obliga a entender de verdad lo que vas a tocar antes de tocarlo. Segundo, le da al agente el contexto que necesita para no romper lo que ya funciona.

## Estado actual
- El formulario valida formato de email solo en el cliente (regex básico)
- Si el campo está vacío y el usuario hace submit, no pasa nada visible
- El servidor acepta cualquier payload sin validar

## Estado deseado
- El servidor valida el email antes de persistir (formato + dominio real)
- El cliente muestra un mensaje de error específico por campo al hacer submit
- Los errores de servidor se mapean al campo correspondiente en el formulario

## Fuera de scope
- No se cambia el diseño visual del formulario
- No se añaden campos nuevos
- No se toca la lógica de envío de emails posterior al submit
- No se migran registros existentes con emails inválidos

La sección "fuera de scope" no es opcional. Es la que protege el trabajo que ya funciona.

3. Dale al agente contexto preciso, no contexto abundante

El error más común: pegar todo el repo en el contexto y esperar que el agente entienda qué es relevante.

El agente trabaja mejor con menos contexto bien elegido que con todo el contexto mal filtrado.

Dale los archivos que afectan directamente al cambio. El componente del formulario. El endpoint del servidor. El schema de validación si existe. Nada más.

4. Verifica contra la spec, no contra la intuición

Cuando el agente termine, la pregunta no es "¿parece bien?" La pregunta es "¿hace lo que dice la spec?"

Esa es la diferencia entre revisar con criterio y revisar con fe.

Si algo de lo que describe la spec no está implementado, vuelves al agente con esa diferencia concreta. No con "esto no está bien." Con "la spec dice X y el código hace Y."

5. La spec se queda en el repo

No la borres cuando el cambio esté hecho. No es documentación temporal. Es la memoria del sistema.

La persona que toque ese módulo dentro de seis meses — que probablemente seas tú — va a abrir ese archivo y va a entender en dos minutos lo que de otro modo le habría costado dos horas de arqueología de código.

El efecto acumulado

Aquí está la parte que más me gusta de este método en brownfield.

No necesitas un sprint de documentación. No necesitas parar todo para "pagar la deuda técnica." No necesitas convencer a nadie de que hay que refactorizar antes de avanzar.

Solo necesitas que cada cambio que hagas a partir de ahora sea un cambio con spec.

Eso es todo.

Con el tiempo, el sistema que era opaco empieza a tener zonas claras. Los módulos que más se tocan son los que más spec tienen. Que resulta ser exactamente el conocimiento más valioso: el de las partes que cambian, no el de las partes que llevan tres años sin tocarse.

El brownfield no desaparece. Pero deja de ser un problema sin solución.

Se convierte en un sistema que se va documentando solo, cambio a cambio, a medida que crece.

Una última cosa

El método que describo aquí — spec antes del cambio, estado actual antes del estado deseado, contexto preciso al agente, verificación contra spec — es el núcleo de lo que enseño en mi curso.

Lo construí trabajando con Claude Code en proyectos reales, no en demos. Y lo he aplicado exactamente en el tipo de proyecto del que hablo aquí: código heredado, sin documentación, con decisiones que nadie recuerda haber tomado.

Si quieres ver cómo se aplica esto en proyectos reales, tengo un curso donde lo cubro en detalle.

Bezael Pérez — DominiCode

El método para construir con agentes de IA

Bezael Pérez — Mon, 25 May 2026 08:31:15 +0000

Bezael Pérez

May 25

BMAD: el método para construir con agentes de IA como si tuvieras un equipo

#ai #programming #productivity #webdev

Comments

4 min read

BMAD: el método para construir con agentes de IA como si tuvieras un equipo

Bezael Pérez — Mon, 25 May 2026 08:30:42 +0000

La mayoría de devs usa la IA como un buscador muy listo.

Le hacen una pregunta. Obtienen una respuesta. Le hacen otra. Y así durante horas,
dando vueltas al mismo problema sin llegar a ningún lado.

Eso no es construir con IA. Es improvisar con IA.

Y hay una diferencia enorme.

Qué es BMAD

BMAD son las siglas de Breakthrough Method for Agile AI-Driven Development.

No es un framework más. Es una forma distinta de pensar cómo trabajar con agentes.

La premisa es simple: un solo agente que hace de todo es como contratar a alguien
y pedirle que sea product manager, arquitecto, desarrollador y QA al mismo tiempo.

Nadie rinde bien así. Los modelos tampoco.

BMAD divide el trabajo entre agentes especializados, igual que un equipo real.

Los cuatro roles

Rol	Responsabilidad
Business Analyst	Entiende el problema, captura requisitos, escribe historias de usuario
Product Manager	Define el producto, prioriza el backlog, toma decisiones de alcance
Architect	Diseña la arquitectura, elige el stack, define los contratos entre módulos
Developer	Implementa el código con todo el contexto ya resuelto

Cada agente tiene su propio system prompt, su propio foco, sus propias responsabilidades.

No improvisa. Sabe exactamente para qué existe.

Un ejemplo real, paso a paso

Supón que quieres construir una app de seguimiento de hábitos.

Sin ningún método: abres el chat y escribes "hazme una app de hábitos con React".
La IA genera algo genérico. No era lo que tenías en mente. Ajustas el prompt.
Otras dos horas. Mismo resultado.

Con BMAD, el flujo es completamente distinto.

Paso 1 — El Business Analyst entra primero

No genera código. Hace preguntas.

Eres un Business Analyst experto. Tu trabajo es entender el problema
antes de que se escriba una sola línea de código.

Pregunta al usuario:
- ¿Qué problema concreto resuelve esta app?
- ¿Quién la va a usar y en qué contexto?
- ¿Qué tiene que hacer sí o sí para ser útil desde el día uno?
- ¿Qué queda fuera del MVP?

No asumas nada. No propongas soluciones. Solo escucha y documenta.

El output es un documento de requisitos. Claro. Sin ambigüedad.

Paso 2 — El Product Manager toma ese documento

Define las features con criterios de aceptación concretos.

No "el usuario puede ver sus hábitos". Sino: "el usuario ve un listado de hábitos activos
ordenados por frecuencia, con indicador visual del streak actual".

Esa diferencia parece pequeña. En la implementación es enorme.

Paso 3 — El Architect diseña antes de que se escriba código

Eres un Architect de software. Recibes el PRD del Product Manager
y tu trabajo es definir:

- Estructura de carpetas y módulos
- Modelo de datos (entidades, relaciones, campos)
- Contratos entre capas (qué expone cada módulo, qué consume)
- Stack técnico justificado

No escribas implementación. Escribe decisiones.

El output es un documento de arquitectura. El Developer lo recibe como contexto fijo.

Paso 4 — El Developer implementa con todo claro

Eres un Developer. Tienes el PRD, la arquitectura y las historias de usuario.

Tu trabajo es implementar el módulo de autenticación siguiendo exactamente
las decisiones de arquitectura documentadas.

Si encuentras una ambigüedad, para y pregunta. No asumas.

Módulo a módulo. Con criterios de aceptación. Con arquitectura definida.

Al final tienes un producto que alguien pensó antes de construir.

Por qué funciona mejor que hablar con un solo agente

Los modelos rinden mejor con un rol delimitado.

Un agente que solo hace arquitectura toma mejores decisiones de diseño que uno al que
le pides arquitectura, código, documentación y tests en el mismo chat.

El contexto se contamina. El foco se pierde. La calidad baja.

La especialización no es solo para humanos.

La conexión con la especificación

Lo que BMAD hace de forma implícita — separar el qué del cómo antes de escribir
código — tiene un nombre en ingeniería de software: desarrollo orientado a especificación.

Si quieres llevar esta idea más lejos y aplicarla en tu flujo de trabajo con IA de forma
sistemática, hay una metodología que lo formaliza: Spec-Driven Development (SDD).

La idea es la misma: antes de que un agente genere una sola línea de código, existe un
documento de especificación claro que define el qué, el quién, los flujos y las decisiones
de arquitectura. El agente developer recibe eso como contexto cerrado, no como un chat abierto.

Tengo un libro corto sobre esto — SDD: Construye con control — si
quieres ver cómo estructura esa especificación en la práctica.

Cómo empezar con BMAD

BMAD es open source en GitHub: busca [bmad-method](https://github.com/bmad-code-org/bmad-method).

Puedes tomarlo tal cual, adaptarlo a tu stack o usarlo como referencia para construir
tu propio sistema de agentes. Funciona con Claude, con GPT, con Gemini.

El modelo importa menos que el sistema.

Los mejores builders que conozco no tienen mejores prompts.

Tienen mejor estructura.

Cómo integrar OpenSpec con Claude Code paso a paso

Bezael Pérez — Mon, 04 May 2026 12:05:26 +0000

Si usas Claude Code para programar ya sabes lo que pasa: abres una nueva sesión y el agente vuelve a improvisar. El contexto de la sesión anterior desapareció. Le describes la feature de nuevo, asume cosas distintas, y acabas corrigiendo código que nadie pidió.

OpenSpec resuelve exactamente eso.

Es un CLI open-source que inserta una capa de especificación versionada dentro de tu proyecto. Claude Code la lee en cualquier sesión, sabe qué se acordó construir, y trabaja contra esa spec — no contra tus prompts.

En este artículo te muestro la integración completa, paso a paso, con una demo real.

Qué es OpenSpec (en 2 párrafos)

OpenSpec es un toolkit de spec-driven development para agentes de IA. Antes de que el agente toque el código, tú y él acuerdan en un documento estructurado qué se va a construir, por qué y cómo. A partir de ahí el agente trabaja contra esa especificación.

Lo que lo diferencia de SpecKit (GitHub) o BMAD Method es que está diseñado para proyectos que ya existen y evolucionan — proyectos brownfield. Usa marcadores de cambio (ADDED, MODIFIED, REMOVED) para registrar exactamente qué cambia sobre el código existente. Es ligero (~250 líneas de spec vs ~800 de SpecKit) y se integra mediante slash commands directamente en Claude Code.

Requisitos

Node.js 20+
Claude Code instalado
Un proyecto existente (la demo usa una API en TypeScript)

Paso 1 — Instalación

npm install -g openspec

Verifica:

openspec --version
# openspec/1.3.x

Paso 2 — Inicializar en tu proyecto

Ve a la raíz de tu proyecto y ejecuta:

cd mi-proyecto
openspec init

Aparece un selector interactivo con todas las herramientas compatibles. Selecciona Claude Code.

? Select your AI coding tool:
  GitHub Copilot
  Cursor
❯ Claude Code
  Kilo Code
  Windsurf
  (more...)

Al confirmar, OpenSpec genera esta estructura:

openspec/
  project.md       ← contexto general del proyecto
  specs/           ← estado actual de las specs (se actualiza con cada archive)
  changes/         ← propuestas en curso
  archive/         ← historial de cambios completados
agents.md          ← instrucciones para Claude Code (NO modificar manualmente)

Paso 3 — Llenar project.md

Este paso es el más importante y el que más se saltea. Abre openspec/project.md y rellena el contexto real de tu proyecto:

# Mi API de Gestión de Tareas

## Stack técnico
- Runtime: Node.js 22 + TypeScript
- Framework: Fastify
- ORM: Prisma + PostgreSQL
- Testing: Vitest

## Convenciones
- Nombres de archivos: kebab-case
- Variables de entorno: siempre validar con zod al inicio
- Errores: usar clase AppError con statusCode y message
- No usar `any` — tipado estricto

## Estructura de carpetas
src/
  routes/          ← definición de endpoints
  services/        ← lógica de negocio
  middleware/       ← guards, validación
  lib/             ← utilidades compartidas

Por qué importa: Claude Code lee este archivo al inicio de cada sesión. Con buen contexto aquí, las propuestas que genera son precisas desde la primera iteración.

Paso 4 — Entender agents.md

OpenSpec generó un agents.md en la raíz. Claude Code lo lee automáticamente como instrucción de proyecto, igual que un CLAUDE.md. Dentro están definidos los tres slash commands que vas a usar:

Comando	Qué hace
`/openspec-proposal`	Activa modo planificación. Claude pregunta sobre la feature y genera los archivos de propuesta.
`/openspec-apply`	Implementa el cambio aprobado, tarea por tarea, referenciando la spec.
`/openspec-archive`	Cierra el cambio, actualiza las specs actuales y limpia `changes/`.

Si ya tienes un CLAUDE.md en tu proyecto, no hay conflicto — Claude Code lee ambos archivos. Déjalos en la raíz.

Paso 5 — Demo completa: añadir autenticación JWT

Vamos a añadir autenticación JWT a la API. Proyecto que ya existe, feature real.

5.1 — Crear la propuesta

En Claude Code, ejecuta:

/openspec-proposal

Claude Code entra en modo planificación y empieza a hacer preguntas:

OpenSpec Proposal Mode activated.

Tell me about the feature you want to build:
> Autenticación JWT — login, logout, refresh token, y proteger rutas existentes

What routes need protection?
> /tasks, /projects — todas las rutas excepto /auth/*

Token strategy?
> Access token (15min) + Refresh token (7 días) en httpOnly cookie

Algorithm preference?
> HS256

Al responder, genera tres archivos en openspec/changes/jwt-auth/:

proposal.md — descripción del cambio y decisiones de diseño:

# JWT Authentication

## Objetivo
Proteger las rutas /tasks y /projects con autenticación JWT.

## Decisiones
- Access token: HS256, 15 minutos, en Authorization header
- Refresh token: 7 días, httpOnly cookie
- Secret: JWT_SECRET en variables de entorno (validar con zod al init)
- Logout: blacklist en Redis (TTL = expiración del access token)

tasks.md — lista de tareas atómicas en orden de dependencia:

# Tasks: jwt-auth

- [ ] 1. Instalar dependencias: jsonwebtoken, @types/jsonwebtoken
- [ ] 2. Crear lib/jwt.ts con sign, verify, decode
- [ ] 3. Crear servicio auth.service.ts con login y refresh
- [ ] 4. Crear middleware/auth.guard.ts que valida el token
- [ ] 5. Añadir rutas POST /auth/login y POST /auth/refresh
- [ ] 6. Proteger rutas /tasks/* y /projects/* con el guard
- [ ] 7. Añadir JWT_SECRET a validación de env vars
- [ ] 8. Tests unitarios para lib/jwt.ts

spec.md — cambios sobre las specs actuales con marcadores delta:

# Spec delta: jwt-auth

[ADDED] lib/jwt.ts — utilidades de sign/verify
[ADDED] services/auth.service.ts
[ADDED] middleware/auth.guard.ts
[ADDED] routes/auth.route.ts
[MODIFIED] routes/tasks.route.ts — añadir preHandler: authGuard
[MODIFIED] routes/projects.route.ts — añadir preHandler: authGuard
[MODIFIED] lib/env.ts — añadir JWT_SECRET a schema zod

5.2 — Revisar y ajustar

Este paso es el valor real de OpenSpec. Revisa los archivos y corrige las asunciones del agente antes de que escriba código.

En la revisión encontramos que el agente asumió Redis para la blacklist pero no tenemos Redis en el proyecto. Editamos proposal.md:

## Decisiones
- ...
- Logout: no blacklist por ahora — invalidación por expiración de token
  (se añadirá Redis en una feature separada)

Valida que todo esté consistente:

openspec validate
# ✓ Spec is valid

5.3 — Implementar

/openspec-apply jwt-auth

Claude Code lee tasks.md y spec.md, y ejecuta cada tarea en orden:

[1/8] Installing dependencies...
[2/8] Creating lib/jwt.ts...
[3/8] Creating services/auth.service.ts...
[4/8] Creating middleware/auth.guard.ts...
...
[8/8] Writing tests for lib/jwt.ts...

✓ All tasks completed

El agente no improvisa nada fuera de la spec. Si necesita tomar una decisión que no estaba en el documento, te pregunta antes de proceder.

5.4 — Archivar

Revisa el código generado. Cuando estés conforme:

openspec archive jwt-auth --yes

✓ Specs updated
✓ Change moved to archive/jwt-auth/
✓ changes/ cleared

openspec/specs/ ahora refleja el estado actual con la autenticación incluida. changes/ está vacío y listo para la siguiente feature.

Tips para sacarle partido con Claude Code

1. Combina con CLAUDE.md para reglas globales

agents.md gestiona el workflow de OpenSpec. Tu CLAUDE.md puede tener reglas más generales del proyecto que aplican siempre, independientemente de OpenSpec. Se complementan bien.

2. Revisa siempre entre proposal y apply

La revisión humana es la clave. Un agente bien orientado con una spec correcta produce código predecible. Un agente con una spec con errores produce los mismos errores a escala.

3. Usa openspec validate antes de cada apply

Detecta referencias rotas o inconsistencias en los archivos de spec antes de lanzar la implementación.

4. Features pequeñas, ciclos cortos

OpenSpec funciona mejor con cambios atómicos (una feature bien delimitada) que con cambios masivos. Si la lista de tareas supera 12-15 items, divide la feature en dos propuestas.

5. Comitea openspec/ junto con el código

Los archivos en openspec/ son documentación ejecutable. Versionalos en git. El archive/ es especialmente valioso — es el historial de decisiones de diseño del proyecto.

Cuándo usarlo y cuándo no

Vale la pena si:

El proyecto tiene más de unas semanas de vida y sigue creciendo
Las features tienen 5+ tareas de implementación
El agente ha roto cosas antes por falta de contexto
Quieres un historial auditable de qué se construyó y por qué

Es overkill si:

Es un proyecto de demo o prueba de concepto
La tarea es una sola pieza pequeña (un componente, un endpoint sencillo)
Ya tienes un flujo que funciona bien con solo un CLAUDE.md detallado

Conclusión

OpenSpec + Claude Code resuelve el problema más frustrante del desarrollo con agentes: el contexto perdido entre sesiones. La inversión inicial (5-10 minutos de setup) se recupera en la primera feature donde el agente no improvisa nada que no estabas esperando.

El repo está en github.com/Fission-AI/OpenSpec y la documentación oficial en intent-driven.dev/knowledge/openspec.

Tutorial en video con demo completa en el canal de YouTube → dominicode.com

Spec-Driven Development: el método para construir con IA sin perder el control

Bezael Pérez — Thu, 09 Apr 2026 07:40:32 +0000

Tienes una idea. Le pides a Claude o Cursor que la construya. En 20 minutos tienes algo que funciona.

Dos semanas después, el proyecto es una bomba de tiempo. Cada feature nueva rompe algo. Nadie sabe por qué el código hace lo que hace. Y cada prompt al agente sale peor que el anterior porque el contexto se ha ido acumulando sin orden.

Eso no es un problema de la IA. Es un problema de proceso.

El vibe coding tiene un límite

El vibe coding es real. Funciona. Para prototipos, para explorar ideas, para hacer algo pequeño en un fin de semana.

Pero tiene un problema de escala.

Cuando el proyecto crece, el conocimiento sobre él vive en tu cabeza. En el historial de chats con el agente. En comentarios dispersos. Cuando quieres cambiar algo, tienes que reconstruir el contexto desde cero cada vez.

El agente ejecuta bien. El problema es que ejecuta lo que le dices. Y si lo que le dices es ambiguo, incompleto o contradictorio, el resultado también lo es.

Spec-Driven Development (SDD) resuelve exactamente eso.

Qué es SDD

Una frase lo resume:

La spec se convierte en el artefacto primario que dirige todo el trabajo posterior: implementación, tests, documentación, verificación.

En el desarrollo tradicional, el código es la fuente de verdad. La documentación sirve al código.

SDD invierte esa relación.

La spec no sirve al código. El código sirve a la spec.

Defines el comportamiento esperado antes de que empiece la implementación. Ese comportamiento está escrito en un documento que el agente puede leer, seguir y contra el que puede verificar su trabajo.

El agente ejecuta. Tú piensas. Cada uno en su sitio.

Lo que SDD no es

Antes de seguir, tres malentendidos comunes:

No es documentación que nadie lee. Una spec de SDD vive con el código, se versiona con el código, y cuando el proyecto cambia, la spec cambia. No es un PDF en Confluence que nadie ha abierto en dos años.

No es waterfall. SDD describe el destino, no el camino. El destino puede cambiar. Lo que no cambia es el principio: antes de que el agente ejecute, alguien tiene que haber pensado qué se quiere conseguir.

No mata la velocidad. La velocidad que te dio la IA se queda. Lo que cambia es que ahora va en la dirección correcta.

Las 7 fases del flujo

Matt Pocock publicó en 2025 un video sobre su flujo de trabajo con IA — más de 250k visualizaciones — donde describió siete momentos que ocurren en cualquier proyecto serio. Independientemente de la herramienta.

Aquí están.

Fase 1: Idea

Todo empieza aquí. La trampa es ir demasiado rápido a la siguiente fase.

Tienes la idea. La entiendes en tu cabeza. Quieres empezar.

El problema: "la entiendes en tu cabeza" no significa que esté suficientemente definida para que un agente la ejecute bien. En tu cabeza hay contexto implícito, restricciones que das por sentadas, decisiones que no has tomado conscientemente.

Una pregunta para salir de la fase 1: ¿puedo describir lo que quiero en dos frases que no sean ambiguas?

Si la respuesta es no, todavía estás aquí.

Fase 2: Research (opcional)

Si hay algo desconocido en el proyecto — una API nueva, una integración que nunca hiciste — necesitas entenderlo antes de especificar.

Formato: un archivo research.md. Temporal, vive mientras dura el sprint. No es documentación permanente. Es caché.

Fase 3: Prototipo (opcional)

El prototipo ocurre antes de la spec, no después.

Si le pides al agente que construya sin haber tocado el problema primero, el agente toma todas las decisiones de diseño, de UX, de arquitectura. El resultado puede ser perfectamente funcional y completamente distinto a lo que habrías elegido tú.

El prototipo es rápido y desechable. Una vez que lo tienes, lo commiteas. La spec puede referenciarlo. Entonces sí: a especificar.

Fase 4: PRD (La spec)

El Product Requirements Document. El artefacto central de todo el método.

El PRD describe el destino, no el viaje. Qué tiene que ser verdad cuando el trabajo esté hecho. Quién lo usa. Qué puede hacer. Qué no puede hacer. Qué asumes sobre el estado actual. Qué criterios vas a usar para verificar que está hecho.

No cómo implementarlo.

Un PRD bien escrito tiene menos de 500 palabras. Si es más largo, está describiendo implementación.

Ejemplo mínimo de estructura:

## Objetivo
[Qué problema resuelve esta feature en una frase]

## Usuarios
[Quién lo usa y en qué contexto]

## Comportamiento esperado
- [El usuario puede hacer X]
- [El sistema responde con Y]
- [Cuando Z ocurre, el resultado es W]

## Fuera de scope
- [Qué NO incluye esta versión]

## Assumptions
- [Qué das por sentado sobre el estado actual del sistema]

## Criterios de aceptación
- [ ] [Verificable, concreto, testeable]
- [ ] [...]

La sección de assumptions es la que más impacto tiene en la calidad del código generado. Es también la que más gente se salta.

Fase 5: Kanban

El PRD define el destino. El kanban define el camino.

El PRD se convierte en issues. Cada issue es una unidad de trabajo que el agente puede ejecutar de forma independiente.

Dos principios para dividirlo:

Vertical slices. Cada issue implementa algo de punta a punta: interfaz, lógica, base de datos. No issues por capa. No "issue de frontend" + "issue de backend". Eso genera dependencias artificiales y hace imposible verificar hasta que todos están hechos.

Tracer bullets. Los unknowns más arriesgados van primero. Si no sabes si algo es técnicamente posible de la forma en que lo imaginaste, ese es el primer issue.

Fase 6: Execution loop

Aquí el agente toma el control.

El loop es simple: el agente lee el issue, implementa, comenta y cierra. Pasa al siguiente.

Lo que nunca es opcional: leer el código que el agente produce. No para microgestionar. Para mantener el criterio sobre lo que se está construyendo. El agente ejecuta bien. Pero tú sigues siendo el responsable del resultado.

Fase 7: QA

El trabajo está hecho. Pero no está terminado.

QA significa verificar que el comportamiento real del sistema coincide con el comportamiento especificado en el PRD. El agente puede ayudar: dale el PRD y el código y pídele que genere un plan de QA. El plan lo genera él. Las pruebas las ejecutas tú.

Los bugs y las inconsistencias que encuentres se convierten en nuevos issues. Vuelven a la fase 6.

El flujo en una imagen

IDEA
  └─ ¿Está suficientemente definida?

RESEARCH (si aplica)
  └─ research.md — caché temporal de lo desconocido

PROTOTIPO (si aplica)
  └─ Exploración rápida, desechable — commitear como referencia

PRD
  └─ Destino, no viaje
  └─ Máx. ~500 palabras — criterios de aceptación testeables

KANBAN
  └─ Vertical slices — tracer bullets primero
  └─ Blocking relationships — dependencias explícitas

EXECUTION LOOP
  └─ Agente ejecuta issue por issue
  └─ Humano lee el código producido

QA
  └─ Agente genera el plan — humano ejecuta
  └─ Bugs → nuevos issues → vuelve al loop

Por qué ahora

Thoughtworks, en su radar tecnológico de 2025, describió SDD como "una de las prácticas más importantes que emergieron con la IA generativa."

GitHub SpecKit tiene más de 72.000 estrellas y soporte para más de veinte plataformas: Claude Code, GitHub Copilot, Amazon Q, Gemini CLI. No es un proyecto de nicho. Es infraestructura.

¿Por qué importa ahora y no antes?

Porque antes, las specs las leían desarrolladores humanos. Un desarrollador puede llenar huecos, hacer preguntas, pedir aclaraciones.

Un agente no puede. Un agente rellena los huecos con lo que le parece más probable.

Y lo que le parece más probable no siempre es lo que tú querías.

Cuando el ejecutor es una IA, la calidad de las instrucciones importa más que nunca. SDD es la respuesta a eso.

Para empezar hoy

Tengo una plantilla gratuita de PRD que puedes usar en tu próximo proyecto. Incluye la estructura completa, ejemplos de criterios de aceptación y la sección de assumptions que la mayoría se salta.

👉 dominicode.com/spec-driven-development

Bezael — DominiCode

Tu app de vibe coding funciona. Eso es exactamente el problema.

Bezael Pérez — Wed, 08 Apr 2026 16:20:17 +0000

Tu app funciona.

La abriste en el navegador. Hiciste clic en los botones. Todo responde.

Hiciste el deploy. Nadie se quejó.

Y ahí está el problema.

Porque "funciona" no significa lo mismo que "está bien". Y cuando le delegas el código a una IA sin revisarlo, la diferencia entre los dos puede ser un endpoint sin autenticación, un token JWT que no expira nunca, o una contraseña guardada en texto plano en tu base de datos.

No porque la IA sea mala. Sino porque la IA optimiza para "hacer que funcione el prompt". No para "hacer que sea seguro en producción".

Lo que la IA no te dice cuando genera tu código

La IA generó tu endpoint. Lo probaste con Postman. Devolvió 200.

Pero no te dijo que cualquier usuario autenticado puede acceder a los datos de cualquier otro usuario simplemente cambiando el ID en la URL.

La IA configuró tu autenticación con JWT. Los tokens se generan. Los usuarios entran.

Pero no te dijo que esos tokens no tienen fecha de expiración. Que si uno se filtra, es válido para siempre.

La IA puso CORS para que el frontend pudiera llamar al backend.

Pero no te dijo que lo configuró con origin: '*'. Que eso significa que cualquier dominio del mundo puede hacer peticiones a tu API.

Esto no es teoría. Es lo que aparece cuando auditas una app de vibe coding. Una tras otra.

`/vibe-audit` — 30 segundos para saber en qué lío estás

Construí AI Workflow Kit porque me cansé de revisar código generado por IA de manera manual y encontrar los mismos 20 problemas cada vez.

La instalación:

npx ai-workflow-kit

Y luego, en cualquier proyecto:

/vibe-audit

Eso es todo. La skill escanea el proyecto completo, lee los archivos más críticos, y genera un reporte con severidad, evidencia concreta y el fix sugerido.

No te dice "hay un problema de seguridad". Te dice exactamente dónde está, qué línea, qué puede pasar si no lo arreglas, y cómo arreglarlo.

Los problemas que encuentra. Siempre.

Después de auditar decenas de apps generadas con IA, hay 20 patrones que aparecen una y otra vez. Estos son los más comunes:

Los críticos — los que pueden costarte el proyecto:

Secretos hardcodeados. La IA pone API keys, contraseñas y URLs de base de datos directamente en el código porque "funciona más rápido en el prompt". Aparece en casi el 100% de los proyectos generados sin revisión.

// Lo que encuentras
OPENAI_API_KEY = "sk-..."
password: "admin123"
const SECRET = "abc123"

Sin validación de inputs. Los endpoints confían ciegamente en req.body. Cualquier usuario puede mandarte lo que quiera. Incluyendo role: "admin".

const { email, role } = req.body
await db.users.update({ role })  // el usuario se da a sí mismo rol de admin

IDOR — acceso a recursos de otros usuarios. El endpoint GET /api/orders/:id no verifica que ese pedido sea tuyo. Cambia el número en la URL. Accedes a los datos de cualquier otro usuario.

Contraseñas sin hashear. No siempre. Pero ocurre, especialmente cuando el prompt fue vago o rápido.

JWT sin expiración. jwt.sign(payload, secret) sin expiresIn. Token válido para siempre. Si se filtra — en logs, en localStorage, en cualquier sitio — el atacante tiene acceso permanente.

Stack traces expuestos al cliente. res.json({ error: err.stack }) en el manejador de errores. En producción esto le da al atacante rutas internas, versiones de librerías y lógica de la aplicación.

Los importantes — los que te explotan en producción:

Queries sin paginación. db.findMany() sin límite. En desarrollo con 10 registros, perfecto. En producción con 50.000, la base de datos se cae.

APIs de terceros sin rate limiting. La IA conecta tu app a OpenAI, Stripe, o cualquier API externa y llama directamente sin control. Un bot puede hacer miles de llamadas y arruinarte la factura o hacer que el proveedor banee tu cuenta.

Sin estados de loading o error en el frontend. La IA genera el happy path perfecto. Si la API tarda o falla, la app se queda en blanco o explota en silencio.

console.logs de desarrollo en producción. La IA logea todo para depurar. Esos logs exponen datos internos y contaminan los logs de producción.

El reporte que genera /vibe-audit tiene este formato:

# Vibe Audit — nombre-del-proyecto
Auditado: fecha

## Resumen
- 🔴 Críticos: N  (bloquear producción o son riesgos de seguridad)
- 🟡 Importantes: N (afectan estabilidad o mantenibilidad)
- 🔵 Mejoras: N   (deuda técnica, calidad)

## 🔴 Críticos

### Contraseñas sin hashear
**Dónde:** `src/auth/register.ts` línea 23
**Evidencia:**
[código problemático]
**Riesgo:** Si la base de datos se compromete, todas las contraseñas quedan expuestas en texto plano
**Fix sugerido:**
[código corregido]

No generalidades. Código concreto. Línea exacta. Fix aplicable.

El resto del kit

/vibe-audit es la razón de ser del kit. Pero no está solo.

Una vez que tu app está auditada y los problemas críticos resueltos, el workflow se mantiene limpio con el resto de las herramientas:

Skills:

/commit — lee el diff real y genera un commit semántico. Sin copy-paste, sin "fix stuff"
/pr — PR con descripción, plan de tests y checklist de revisión
/review @archivo — revisa bugs, seguridad y rendimiento con criterios de ingeniería real
/plan [tarea] — fuerza planificación antes de ejecutar. Para tareas complejas, un plan aprobado vale más que código rápido
/debug [problema] — diagnóstico con hipótesis antes de proponer fixes

Agentes especializados:

/frontend — componentes siguiendo el sistema de diseño del proyecto
/api — endpoints con validación, auth y manejo de errores
/test — tests por comportamiento, no por implementación
/refactor — mejora el código sin cambiar el comportamiento
/docs — JSDoc, README, ADR según el contexto

Hooks automáticos — sin activación, corren solos:

Bloquea comandos destructivos antes de que se ejecuten
Escanea archivos staged buscando API keys antes de cada commit
Formatea con Prettier o Biome después de cada edición
Corre ESLint y devuelve los errores a Claude para que los corrija
Notificación de escritorio cuando Claude termina (Mac/Linux/Windows)

Funciona con Claude Code, Cursor y GitHub Copilot.

La diferencia entre vibe coding y vibe coding bien hecho

El vibe coding no va a desaparecer. Ni debería.

La velocidad es real. La productividad es real. Poder construir en horas lo que antes tardaba días es real.

El problema no es la velocidad. El problema es confundir "rápido" con "hecho".

Tu app necesita los dos. Velocidad para llegar al mercado. Y un /vibe-audit para saber qué hay dentro antes de que alguien más lo descubra por ti.

Una línea:

npx ai-workflow-kit

GitHub: https://github.com/bezael/ai-workflow-kit

Your vibe coding app works. That's exactly the problem.

Bezael Pérez — Wed, 08 Apr 2026 16:20:02 +0000

Your app works.

You opened it in the browser. Clicked the buttons. Everything responds.

You deployed it. Nobody complained.

And that's exactly the problem.

Because "works" doesn't mean the same thing as "is correct". And when you delegate code to an AI without reviewing it, the gap between those two can be an endpoint with no authentication, a JWT token that never expires, or a password stored in plaintext in your database.

Not because the AI is bad. But because the AI optimizes for "make the prompt work". Not for "make it safe in production".

What the AI doesn't tell you when it generates your code

The AI generated your endpoint. You tested it with Postman. It returned 200.

But it didn't tell you that any authenticated user can access any other user's data just by changing the ID in the URL.

The AI set up your JWT authentication. Tokens are generated. Users log in.

But it didn't tell you those tokens have no expiration date. That if one leaks, it's valid forever.

The AI configured CORS so the frontend could call the backend.

But it didn't tell you it set origin: '*'. That means any domain in the world can make requests to your API.

This isn't theory. It's what shows up when you audit a vibe-coded app. Every single time.

`/vibe-audit` — 30 seconds to know what mess you're in

I built AI Workflow Kit because I got tired of manually reviewing AI-generated code and finding the same 20 problems every time.

Installation:

npx ai-workflow-kit

Then, in any project:

/vibe-audit

That's it. The skill scans the entire project, reads the most critical files, and generates a report with severity, concrete evidence, and the suggested fix.

It doesn't tell you "there's a security problem". It tells you exactly where it is, which line, what can happen if you don't fix it, and how to fix it.

The problems it finds. Every time.

After auditing dozens of AI-generated apps, there are 20 patterns that show up again and again. These are the most common:

The critical ones — the ones that can kill your project:

Hardcoded secrets. The AI puts API keys, passwords, and database URLs directly in the code because "it works faster in the prompt". Shows up in almost 100% of projects generated without review.

// What you find
OPENAI_API_KEY = "sk-..."
password: "admin123"
const SECRET = "abc123"

No input validation. Endpoints blindly trust req.body. Any user can send you whatever they want. Including role: "admin".

const { email, role } = req.body
await db.users.update({ role })  // user gives themselves admin role

IDOR — access to other users' resources. The GET /api/orders/:id endpoint doesn't verify that order belongs to you. Change the number in the URL. You access any other user's data.

Unhashed passwords. Not always. But it happens, especially when the prompt was vague or rushed.

JWT without expiration. jwt.sign(payload, secret) without expiresIn. Token valid forever. If it leaks — in logs, in localStorage, anywhere — the attacker has permanent access.

Stack traces exposed to the client. res.json({ error: err.stack }) in the error handler. In production this gives an attacker internal paths, library versions, and application logic.

The important ones — the ones that blow up in production:

Queries without pagination. db.findMany() without a limit. In development with 10 records, perfect. In production with 50,000, the database goes down.

Third-party APIs without rate limiting. The AI connects your app to OpenAI, Stripe, or any external API and calls directly with no control. A bot can fire thousands of requests and wreck your bill or get your account banned by the provider.

No loading or error states in the frontend. The AI generates the perfect happy path. If the API is slow or fails, the app goes blank or crashes silently.

Development console.logs in production. The AI logs everything for debugging. Those logs expose internal data and pollute your production logs.

The report /vibe-audit generates looks like this:

# Vibe Audit — project-name
Audited: date

## Summary
- 🔴 Critical: N  (block production or are security risks)
- 🟡 Important: N (affect stability or maintainability)
- 🔵 Improvements: N   (technical debt, quality)

## 🔴 Critical

### Unhashed passwords
**Where:** `src/auth/register.ts` line 23
**Evidence:**
[problematic code]
**Risk:** If the database is compromised, all passwords are exposed in plaintext
**Suggested fix:**
[corrected code]

No vague warnings. Concrete code. Exact line. Actionable fix.

The rest of the kit

/vibe-audit is the reason the kit exists. But it doesn't stand alone.

Once your app is audited and the critical issues resolved, the rest of the tools keep the workflow clean:

Skills:

/commit — reads the real diff and generates a semantic commit. No copy-paste, no "fix stuff"
/pr — PR with description, test plan, and reviewer checklist
/review @file — reviews bugs, security, and performance with real engineering criteria
/plan [task] — forces planning before execution. For complex tasks, an approved plan is worth more than fast code
/debug [problem] — diagnosis with hypotheses before proposing fixes

Specialized agents:

/frontend — components following the project's design system
/api — endpoints with validation, auth, and error handling
/test — behavior-driven tests, not implementation tests
/refactor — improves code without changing behavior
/docs — JSDoc, README, or ADR depending on context

Automatic hooks — no activation needed, they just run:

Blocks destructive commands before they execute
Scans staged files for API keys before every commit
Formats with Prettier or Biome after every edit
Runs ESLint and feeds errors back to Claude to fix
Desktop notification when Claude finishes (Mac/Linux/Windows)

Works with Claude Code, Cursor, and GitHub Copilot.

The difference between vibe coding and vibe coding done right

Vibe coding isn't going away. And it shouldn't.

The speed is real. The productivity is real. Being able to build in hours what used to take days is real.

The problem isn't the speed. The problem is mistaking "fast" for "done".

Your app needs both. Speed to reach the market. And a /vibe-audit to know what's inside before someone else finds out for you.

One line:

npx ai-workflow-kit

GitHub: https://github.com/bezael/ai-workflow-kit

De Senior Dev a Tech Lead: la transición donde más talento se pierde ¿Te ha pasado?

Bezael Pérez — Wed, 29 Oct 2025 18:08:40 +0000

Bezael Pérez

Oct 28 '25

Por qué los desarrolladores que pasan a tech lead fracasan…

#liderazgo #tecnologia #management

Comments

2 min read

Por qué los desarrolladores que pasan a tech lead fracasan…

Bezael Pérez — Tue, 28 Oct 2025 16:57:24 +0000

De Senior Dev a Tech Lead: la transición donde más talento se pierde

¿Te ha pasado?

Eras un desarrollador senior brillante… y un día te dicen:

“A partir de ahora, serás Tech Lead.”

Lo tomas como un ascenso.

Pero en realidad, es un cambio de profesión.

Y aquí es donde muchos (muchísimos) desarrolladores fracasan.

¿Por qué?

Porque siguen midiendo su valor con las métricas equivocadas.

El conflicto central

Tu valor ya no está en tu código.

Como Senior Dev, te valoran por tu output individual:

la calidad de tu código, lo rápido que resuelves problemas, lo bien que entregas.

Como Tech Lead, te valoran por el output de tu equipo:

rendimiento colectivo, claridad, bienestar, producto final y alineación con negocio.

El día que entiendes eso, todo cambia.

🚨 Los 5 errores más comunes (y cómo evitarlos)

1. El síndrome del héroe

“Es más rápido si lo hago yo.”

Falla: te conviertes en cuello de botella.

Solución: delega, confía y enseña. Tu trabajo ya no es escribir código, es que se escriba bien.

2. El micromanagement disfrazado de “calidad”

Code reviews de 50 comentarios, querer aprobarlo todo.

Falla: ahogas la autonomía del equipo.

Solución: define estándares, automatiza lo repetitivo y revisa lo que realmente importa.

3. Falla de comunicación

“Pero si técnicamente es obvio…”

Falla: olvidas que no todos hablan tu idioma.

Solución: traduce el lenguaje técnico al de negocio y viceversa. El contexto es poder.

4. Olvidar el factor humano

Tu equipo no son tickets en Jira.

Solución: haz 1:1, pregunta cómo están, protege su foco y reconoce sus logros.

5. Seguir queriendo ser el mejor programador

Solución: recalibra tu éxito.

Ya no eres el más rápido, eres quien hace que los demás lleguen más lejos.

💡 En resumen

Pasar a Tech Lead no es subir un peldaño, es cambiar de escalera.

Dejas de ser un doer para convertirte en un facilitador.

Un multiplicador de fuerza.

Si lo haces bien, tu impacto se multiplica.

Si no, acabarás quemado… y tu equipo también.

📘 Estoy preparando una guía completa sobre “Cómo no fracasar en la transición de Senior Dev a Tech Lead”, con ejemplos y prompts de IA para cada reto.

¿Te gustaría que la comparta en PDF gratis cuando esté lista?

Jest 30: Más Rápido, Inteligente y Listo para el Futuro. ¿Es Hora de Actualizar?

Bezael Pérez — Thu, 26 Jun 2025 05:51:57 +0000

Después de una espera que pareció una eternidad en el vertiginoso mundo del desarrollo de software, el equipo de Jest ha lanzado la versión 30. Y permíteme decirte, la espera ha valido la pena. Esto no es una simple actualización incremental; es una reinvención fundamental que aborda deudas técnicas de larga data, responde a las críticas de la comunidad y reafirma a Jest como un titán en el panorama de las pruebas de JavaScript.

Durante años, los desarrolladores hemos tenido una relación de amor-odio con Jest. Adoramos su simplicidad de "cero configuración" y su potente ecosistema, pero a menudo nos hemos enfrentado a tiempos de ejecución lentos y a un consumo de memoria descontrolado en proyectos grandes. Jest 30 no solo pule los bordes ásperos, sino que reconstruye los cimientos.

¿Por qué esta actualización es un punto de inflexión?

Adiós a la Lentitud

El problema más notorio de Jest siempre ha sido el rendimiento. La versión 30 ataca este problema en dos frentes con una eficacia brutal:

Módulos Ultrarrápidos:

El principal cuello de botella era la forma en que Jest encontraba los módulos. En proyectos grandes, especialmente monorepos, la búsqueda recursiva de archivos package.json consumía una cantidad desproporcionada de tiempo. Jest 30 reemplaza este sistema con unrs-resolver, un nuevo componente de alto rendimiento que aprovecha la velocidad de Rust.

Resultados: Los benchmarks oficiales muestran tiempos de ejecución hasta un 37% más rápidos en aplicaciones TypeScript de gran tamaño.
Control de Fugas de Memoria:

¿Quién no ha visto fallar su pipeline de CI por un misterioso error de "heap out of memory"? Jest 30 introduce una solución nativa con la opción globalsCleanup. Esta característica detecta y limpia automáticamente las variables globales que se "filtran" entre pruebas, una de las principales causas de las fugas de memoria.

En el mismo benchmark, esta opción redujo el uso máximo de memoria en un increíble 77% (de 7.8 GB a 1.8 GB).

Esto no es una optimización, es un cambio radical que puede estabilizar por completo tus pruebas.

Nuevas Herramientas para el Desarrollador

Más allá de la velocidad, Jest 30 enriquece nuestra caja de herramientas con funcionalidades que simplifican patrones de prueba comunes y mejoran la legibilidad del código.

expect.arrayOf(matcher): Una de las adiciones más solicitadas. Ahora puedes verificar que cada elemento de un array cumple con un matcher específico de forma declarativa, sin necesidad de bucles manuales.

  // Verifica que cada objeto en el array tiene un 'id' de tipo string.
  expect(users).toEqual(expect.arrayOf(
    expect.objectContaining({ id: expect.any(String) })
  ));

using spy para una Gestión de Mocks Impecable: Aprovechando la nueva sintaxis de "Explicit Resource Management" de JavaScript, ahora podemos crear espías que se restauran automáticamente al salir del ámbito. ¡Adiós a los olvidos de mockRestore() en los bloques afterEach!

  test('llama a console.warn', () => {
    // El espía se restaura automáticamente al final del test. ¡Magia!
    using consoleWarnSpy = jest.spyOn(console, 'warn').mockImplementation(() => {});

    console.warn('un aviso');
    expect(consoleWarnSpy).toHaveBeenCalled();
  });

Reintentos de Pruebas Configurables: Las pruebas inestables (flaky tests) son la pesadilla de la integración continua. jest.retryTimes() ahora permite configurar un retardo entre reintentos (waitBeforeRetry) o reintentar una prueba fallida de inmediato (retryImmediately), dándote un control mucho más fino.

La Migración: ¿Vale la Pena el Esfuerzo?

Seamos claros: Jest 30 introduce cambios rompedores. Requiere Node.js 18+ y TypeScript 5.4+, y elimina los alias de matchers obsoletos (como toBeCalled en lugar de toHaveBeenCalled).

Sin embargo, la migración es más sencilla de lo que parece. La mayoría de los cambios de alias se pueden solucionar automáticamente con eslint-plugin-jest. El esfuerzo de actualizar es una inversión directa en una base de código de pruebas más moderna, robusta y, sobre todo, más rápida.

El Futuro de las Pruebas y Cómo Dominarlo

Esta actualización demuestra que Jest no solo está vivo, sino que está evolucionando para liderar la próxima era de las pruebas en JavaScript. Escribir pruebas no es solo una formalidad; es un arte que, cuando se domina, garantiza la calidad y la mantenibilidad de nuestras aplicaciones.

Si estas mejoras en Jest 30 te inspiran a llevar tus pruebas al siguiente nivel, especialmente en el ecosistema de Angular, he volcado años de experiencia en mi libro: Unit testing con Jest y Testing Library en Angular.

Es la guía perfecta para dominar no solo las herramientas, sino las estrategias para escribir pruebas que realmente aporten valor y confianza a tu equipo.

Las pruebas unitarias son la base de una pirámide de software sólida. Para una inmersión profunda en patrones prácticos, ejemplos del mundo real y cómo aprovechar al máximo herramientas como Jest y Testing Library, puedes encontrar más información y adquirir el libro aquí

Conclusión: Un Nuevo Comienzo para Jest

Jest 30 es una declaración de intenciones. Es una respuesta contundente a las alternativas modernas y una promesa de un futuro con ciclos de lanzamiento más consistentes y un desarrollo más audaz. Las mejoras de rendimiento son reales y tangibles, las nuevas funcionalidades son ergonómicas y potentes, y la hoja de ruta es clara.

Si has estado luchando con la lentitud de Jest o te has sentido tentado por otras herramientas, esta es la actualización que estabas esperando. Es el momento de actualizar, explorar las nuevas funcionalidades y llevar tus pruebas a un nuevo nivel de eficiencia y fiabilidad.

El futuro de las pruebas con Jest es brillante.

De Jasmine a Jest: Migración sin dolor en 30 minutos

Bezael Pérez — Sun, 15 Jun 2025 19:36:36 +0000

¿Te imaginas recortar a la mitad el tiempo que tardan tus pruebas de Angular con un simple giro de tuercas que casi nadie está aplicando todavía?
Hoy vas a descubrir cómo hacerlo y por qué aplazarlo podría costarte horas de café frío y deploys retrasados.

La verdad incómoda sobre Karma

Karma ha sido el “motor” oficial durante años.
Pero en Angular 16 ya apareció en la lista de obsoletos y, desde la versión 17, vive con fecha de caducidad impresa.
Cada lanzamiento de navegador, cada reconexión y cada pestaña oculta que se abre en segundo plano es un ladrillo más en la pared que separa tu código de la luz verde del pipeline.

Por qué Jest está ganando terreno en silencio

Jest no necesita un navegador real para ejecutar tests: todo sucede en memoria, como quien hace cálculos sobre la servilleta del bar.
Los informes son legibles, coloreados y te señalan el error con una flecha casi insultante.
Además, el caché inteligente evita repetir trabajo y acelera aún más cada iteración.
La comunidad ya lo adoptó; el propio equipo de Angular lo reconoce como la opción a futuro. ¿Vas a quedarte fuera?

Tu plan exprés de 30 minutos

Actualiza dependencias
Añade el preset oficial de Angular para Jest y retira los paquetes de Karma. Con una sola orden de instalación limpias el terreno.
Prepara la configuración
Reemplaza el archivo de Karma por el de Jest. Solo necesitas declarar el preset, el directorio de cobertura y los mapeos de paths que ya usas.
Adapta los setup files
Si inicializabas zonas o polyfills especiales, muévelos al archivo de arranque de Jest. El formato cambia, pero el contenido es prácticamente el mismo.
Ajusta los test utilities
TestBed sigue funcionando; la diferencia es que las utilidades de Jest —spies, temporizadores falsos, snapshots— sustituyen a las de Jasmine sin dolor.
Corre la primera pasada
Ejecuta tus pruebas. Lo habitual es ver una ráfaga verde y un tiempo de ejecución que parece un error de imprenta: tan rápido que querrás presumir la captura.

Lo que nadie te cuenta (pero necesitas saber)

Cobertura instantánea: Jest muestra el porcentaje de líneas cubiertas sin plugins extra.
Migración incremental: puedes mantener algunos archivos en Jasmine mientras terminas la transición.
Integración continua simplificada: adiós a los launchers de navegador y a esa configuración críptica que nunca recuerdas.

¿Qué pasa si lo dejas para mañana?

Karma desaparecerá del CLI y tendrás que migrar deprisa, bajo presión y con todo el equipo mirando el reloj.
El coste no será solo técnico: cada minuto de espera en cada build se multiplicará por cada desarrollador y cada pull request.

Da el salto ahora mismo

Haz clic aquí y descarga el ebook “Unit testing con Jest y Testing Library en Angular”.
Y tendrás tu proyecto corriendo con Jest y disfrutarás de test suites que vuelan.

Recuerda el beneficio final

Migrar hoy significa ciclos de feedback rapidísimos, menos frustración y más tiempo para crear funcionalidades que importan.
No dejes que un runner obsoleto decida tu velocidad de desarrollo: adopta Jest y comprueba cómo tus pruebas dejan de ser un lastre para convertirse en tu mejor aliado.

Paso 1 – Instala lo esencial sin perder un minuto

Abre tu terminal favorita y ejecuta el gestor de paquetes para añadir Jest, jest-preset-angular y @types/jest como dependencias de desarrollo.
Con esta sola acción dejas listo el motor, el adaptador específico para Angular y las definiciones de tipos que evitarán errores de compilación más adelante.

Confirma al terminar que el archivo de bloqueos (ya sea package-lock.json o pnpm-lock.yaml) refleje las tres librerías; eso te garantiza entornos reproducibles en todo el equipo.

¿Listo? En menos de lo que tarda en hervir el café, ya tienes las bases instaladas y puedes pasar al siguiente ajuste de configuración.

npm install --save-dev jest jest-preset-angular @types/jest
# o si usas yarn
yarn add --dev jest jest-preset-angular @types/jest

2. Ajuste del `package.json`

Imagina que el corazón de tu proyecto late en el package.json.
El próximo latido –el que activará Jest– se cocina con un simple ajuste.

Abre ese archivo y localiza el bloque scripts.
Dentro verás la orden clásica que dispara Karma; bórrala sin piedad.

En su lugar, coloca una instrucción que invoque Jest de forma directa, sin corredores intermedios ni arranques de navegador.

Con esta única sustitución, cada vez que escribas npm run test (o el alias que uses) entrarás en la nueva era de tests turboalimentados.

Guarda el cambio, ejecuta la prueba… y comprueba cómo el cronómetro se hunde: tu suite ahora corre a la velocidad que siempre quisiste.

{
  "scripts": {
    "test": "npx jest"
  }
}

3. Configuración de `tsconfig.spec.json`

¿Todavía ves el fantasma de Jasmine acechando en tu tsconfig.spec.json?
Ese pequeño detalle frena a TypeScript y puede hacer que tus imports de Jest luzcan como errores.

Localiza la puerta de entrada
Abre tsconfig.spec.json y busca la propiedad types dentro de compilerOptions. Allí es donde “vive” la referencia a los tipos globales que entiende el compilador.
Expulsa al huésped equivocado
Si la lista contiene "jasmine", sustitúyelo por "jest". Puedes mantener otras entradas útiles (por ejemplo, "node") si ya estaban presentes: la regla es dejar solo el conjunto de tipos que realmente necesitas.
Guarda y respira
A partir de este cambio, TypeScript reconocerá todas las funciones globales de Jest (describe, it, expect, etc.) sin que necesites imports extra ni comentarios de bypass. Un simple npm run test confirmará que las advertencias desaparecieron y que tu nueva configuración late con normalidad.

Con esa edición mínima habrás desalojado por completo los viejos tipos de Jasmine y tu proyecto quedará afinado para el nuevo corredor de pruebas.

¿Listo para el siguiente ajuste o hay algo que quieras pulir antes de continuar?

{
  "extends": "./tsconfig.json",
  "compilerOptions": {
    "outDir": "./out-tsc/spec",
    "types": ["jest", "node"] // Cambia "jasmine" por "jest"
  },
  "include": ["src/**/*.spec.ts", "src/**/*.d.ts"]
}

4. Creación de `jest.config.ts`

¿Preparado para darle a Jest las llaves de tu proyecto?

Crea el archivo
En la raíz, añade un nuevo jest.config.ts. Piensa en él como la consola central desde la que controlarás cada test.
Importa el preset oficial
El primer paso dentro del archivo es “enchufar” jest-preset-angular. Con eso, Jest entenderá componentes, pipes y templates como si llevara años hablando Angular.
Define la configuración

preset: apunta a 'jest-preset-angular'.
testEnvironment: usa 'jsdom' para una simulación ligera de navegador.
setupFilesAfterEnv: referencia a un pequeño jest.setup.ts donde inicialices jest-preset-angular, fakeAsync zones o utilidades globales.
transform: indica a Jest que los archivos .ts y .html pasen por el transformador que trae el preset.
moduleNameMapper: replica aquí los alias de paths que ya tienes en tu tsconfig, de modo que los imports sigan funcionando.
coverageDirectory: elige la carpeta donde quieras el informe de cobertura; así mantienes los resultados fuera de la carpeta de artefactos principales.
transformIgnorePatterns: excluye el código de terceros (por ejemplo, node_modules/(?!(lodash-es|rxjs))) si necesitas transpilar alguna librería moderna.

Guarda y prueba Con solo ese puñado de líneas, Jest sabe exactamente cómo arrancar tus specs de Angular. Lanza npm run test y observa cómo se disparan los resultados: rápido, limpio y con un informe de cobertura listo para presumir.

Sin tocar una sola línea de tu código de producción, habrás levantado la nueva central de mando para tus pruebas unitarias. Tu stack ya funciona con Jest; lo siguiente es disfrutar de ciclos de feedback que casi no dan tiempo ni a parpadear.

import type { Config } from 'jest';

const config: Config = {
  preset: 'jest-preset-angular',
  setupFilesAfterEnv: ['<rootDir>/setup-jest.ts'],
  moduleDirectories: ['node_modules', '<rootDir>'],
  testMatch: ['**/+(*.)+(spec).+(ts)'],
};

export default config;

5. Creación de `setup-jest.ts`

¿Sabías que un único archivo puede convocar todo el poder de Jest y al mismo tiempo convencer a Angular de que nada ha cambiado? Ese archivo se llama setup-jest.ts, y su misión es dejar listo el escenario antes de que se ejecute la primera prueba.

Por qué importa

Jest necesita que le cuentes cómo funcionan las zonas de Angular, cómo compilar plantillas y en qué momento «pinchar» el TestBed. Sin esa preparación, tus components quedarían mudos y tus pipes perderían la voz.

Lo que debe ocurrir dentro

Encendido del preset
El archivo arranca cargando la utilería que traduce internamente los decoradores, las plantillas y las dependencias que Angular usa de forma nativa.
Parches y polyfills opcionales
Si tu app depende de APIs del navegador que JSDOM no expone por defecto—como matchMedia o ciertas animaciones—, aquí añades los parches mínimos para que Jest no tropiece.
Extensiones a las expectativas
Puedes incorporar ayudas de aserción adicionales—por ejemplo, comparadores de fechas o números aproximados—sin repetir imports en cada archivo de prueba.
Configuración global de tiempo
Ajustar un timeout genérico evita que las pruebas se queden colgadas por operaciones lentas, manteniendo el reporte limpio y controlado.

Con esa coreografía, cada spec encuentra un Angular completamente operativo en milésimas de segundo, sin demoras ni advertencias extrañas. Guarda el archivo junto al resto de tu código y lánzate a ejecutar npm run test: verás cómo todo fluye con la seguridad de saber que tu entorno está perfectamente preparado antes de que el cronómetro arranque.

import 'jest-preset-angular/setup-jest';
import '@angular/localize/init'; // Necesario para Angular >= 9
// Workaround para ReferenceError: TextEncoder is not defined en Jest
import { TextEncoder } from 'node:util';
Object.defineProperty(window, 'TextEncoder', {
  writable: true,
  value: TextEncoder,
});

6. Deja atrás el lastre de Karma y Jasmine

Ahora que tu suite vuela con Jest, mantener las viejas dependencias es como llevar un ancla colgada al tobillo. Deshazte de Karma, Jasmine y cualquier launcher o reporter relacionado: liberarás espacio, acelerarás las instalaciones de CI y evitarás conflictos de versiones en el futuro.

Depuración del package.json
Despídete de cada librería que empiece por karma- o jasmine-. Al retirarlas, tu árbol de dependencias se encoge y las descargas en cada pipeline se reducen a la mitad.
Limpieza de archivos de configuración
Borra karma.conf.js, test.ts (si lo tienes) y cualquier script de npm que invoque Karma. Si tu CI aún abre un navegador para los tests, elimínalo también: ese paso dejó de tener sentido.
Revisión de scripts y tasks
Comprueba que no queden comandos heredados en la carpeta de herramientas, ni pasos de build que referencien al viejo runner. Una búsqueda rápida por el repositorio te dará la certeza.
Actualización del cache de CI
Sin Karma ni Chrome Headless en la ecuación, tu contenedor construirá menos capas y completará los tests antes de que acabes el primer sorbo de café.
Confirmación final
Ejecuta la suite con Jest en local y en la pipeline. Verás cómo la lista de paquetes descargados se acorta y los tiempos de ejecución marcan nuevos mínimos históricos.

Con esta purga, tu proyecto queda más ligero, tu presupuesto de CI respira y tu equipo trabaja sobre un stack coherente y enfocado en el futuro. Sigue avanzando; cada archivo antiguo que eliminas es un segundo menos de espera en tu próximo deploy.

npm uninstall karma karma-chrome-launcher karma-jasmine karma-coverage karma-jasmine-html-reporter @types/jasmine @types/jasminewd2 jasmine-core jasmine-spec-reporter

Ejemplo mínimo: Conversión de una prueba tradicional a Jest con Testing Library

Veamos un ejemplo sencillo de cómo se vería una prueba antes y después de la migración.

Componente CounterComponent (ejemplo):

// counter.component.ts
import { Component, signal } from '@angular/core';

@Component({
  selector: 'app-counter',
  template: `
    <button (click)="decrement()">-</button>
    <span data-testid="count">{{ count() }}</span>
    <button (click)="increment()">+</button>
  `,
  standalone: true,
})
export class CounterComponent {
  count = signal(0);

  increment() {
    this.count.update((value) => value + 1);
  }

  decrement() {
    this.count.update((value) => value - 1);
  }
}

Prueba tradicional (Karma/Jasmine con TestBed):

// counter.component.spec.ts (Antes)
import { ComponentFixture, TestBed } from '@angular/core/testing';
import { CounterComponent } from './counter.component';

describe('CounterComponent', () => {
  let component: CounterComponent;
  let fixture: ComponentFixture<CounterComponent>;
  let compiled: HTMLElement;

  beforeEach(async () => {
    await TestBed.configureTestingModule({
      imports: [CounterComponent],
    }).compileComponents();

    fixture = TestBed.createComponent(CounterComponent);

    component = fixture.componentInstance;
    compiled = fixture.nativeElement;
    fixture.detectChanges();
  });

  it('Haves an initial count of 0', () => {
    expect(component.count()).toBe(0);
  });

  it('Renders the initial count of 0 in the span', () => {
    const countSpan = compiled.querySelector('[data-testid="count"]');
    expect(countSpan?.textContent).toBe('0');
  });

  it('Increment the count signal when increment() is called', () => {
    expect(component.count()).toBe(0);

    component.increment();
    expect(component.count()).toBe(1);
  });

  it('Decrement the count signal when decrement() is called', () => {
    expect(component.count()).toBe(0);

    component.decrement();

    expect(component.count()).toBe(-1);
  });

  it('Increment the count in the template when the "+" button is clicked', () => {
    const incrementButton = compiled.querySelectorAll('button')[1];
    const countSpan = compiled.querySelector('[data-testid="count"]');

    incrementButton.click();
    fixture.detectChanges();

    expect(component.count()).toBe(1);
    expect(countSpan?.textContent).toBe('1');
  });

  it('Decrement the count in the template when the "-" button is clicked', () => {
    const decrementButton = compiled.querySelector('button');
    const countSpan = compiled.querySelector('[data-testid="count"]');

    expect(countSpan?.textContent).toBe('0');

    decrementButton?.click();
    fixture.detectChanges();

    expect(component.count()).toBe(-1);
    expect(countSpan?.textContent).toBe('-1');
  });
});

Prueba migrada (Jest):

import { ComponentFixture, TestBed } from '@angular/core/testing';
import { CounterComponent } from './counter.component';

describe('CounterComponent (con Jest) - Versión Mejorada', () => {
  let component: CounterComponent;
  let fixture: ComponentFixture<CounterComponent>;
  let compiled: HTMLElement;

  const getElement = (selector: string): HTMLElement | null => compiled.querySelector(selector);
  const getButton = (text: string): HTMLButtonElement | null => {
    return Array.from(compiled.querySelectorAll('button')).find((btn) => btn.textContent === text) || null;
  };
  const getCountSpan = (): HTMLElement | null => getElement('[data-testid="count"]');

  beforeEach(async () => {
    await TestBed.configureTestingModule({
      imports: [CounterComponent],
    }).compileComponents();

    fixture = TestBed.createComponent(CounterComponent);
    component = fixture.componentInstance;
    compiled = fixture.nativeElement;
    fixture.detectChanges();
  });

  describe('Initial State and Rendering', () => {
    it('Initialize with a count of 0', () => {
      expect(component.count()).toBe(0);
    });

    it('Renders the initial count "0" inside the span', () => {
      const countSpan = getCountSpan();
      expect(countSpan).not.toBeNull();
      expect(countSpan?.textContent).toBe('0');
    });

    it('Renders an increment and a decrement button', () => {
      const incrementButton = getButton('+');
      const decrementButton = getButton('-');
      expect(incrementButton).not.toBeNull();
      expect(decrementButton).not.toBeNull();
    });
  });

  describe('Business Logic', () => {
    it('Update the count signal from 0 to 1', () => {
      component.increment();
      expect(component.count()).toBe(1);
    });

    it('Update the count signal from 0 to -1', () => {
      component.decrement();
      expect(component.count()).toBe(-1);
    });

    it('Handles multiple operations correctly (e.g., increment twice, decrement once)', () => {
      component.increment();
      component.increment();
      component.decrement();
      expect(component.count()).toBe(1);
    });
  });

  describe('User Interaction', () => {
    it('Update the displayed count to "1" when the "+" button is clicked', () => {
      const incrementButton = getButton('+');
      incrementButton?.click();
      fixture.detectChanges();

      const countSpan = getCountSpan();
      expect(component.count()).toBe(1);
      expect(countSpan?.textContent).toBe('1');
    });

    it('Update the displayed count to "-1" when the "-" button is clicked', () => {
      const decrementButton = getButton('-');
      decrementButton?.click();
      fixture.detectChanges();

      const countSpan = getCountSpan();
      expect(component.count()).toBe(-1);
      expect(countSpan?.textContent).toBe('-1');
    });

    it('Displays "0" after clicking "+" and then "-"', () => {
      const incrementButton = getButton('+');
      const decrementButton = getButton('-');

      incrementButton?.click();
      fixture.detectChanges();

      decrementButton?.click();
      fixture.detectChanges();

      const countSpan = getCountSpan();
      expect(component.count()).toBe(0);
      expect(countSpan?.textContent).toBe('0');
    });
  });
});

¿Lo mejor de todo? Ahora tu archivo de pruebas no solo “pasa”, sino que respira mantenimiento futuro.

Por qué tus ajustes son oro puro

Selectores resilientes
Buscar por texto (+ / −) anula la fragilidad del índice numérico. Mañana podrás insertar un botón “reset” en cualquier parte y el test ni se despeinará.
Describe anidados que cuentan una historia
Al separar Estado Inicial, Lógica y Interacción, cualquiera localiza la intención en segundos. Leer el archivo deja de ser un safari de it() sueltos y pasa a ser un mapa bien señalizado.
Helpers DRY
Centralizar la obtención de elementos reduce el “ruido” en cada spec y concentra el cambio en un único punto. Si algún día migras de data-testid a atributos ARIA, actualizarás solo esas funciones.
Cobertura real de flujos
Verificar la presencia de ambos botones y la secuencia + → − garantiza que tu contador no falla ante combinaciones encadenadas. Es un test de comportamiento, no una foto estática.

Cómo exprimir aún más tu nueva base

Añade tests de accesibilidad
Usa jest-axe para asegurarte de que los cambios visuales no rompen reglas WCAG. Mantendrás al equipo en verde respecto a inclusión sin esfuerzo manual.
Integra snapshots selectivos
Útiles para componentes con mucho markup. Hazlo solo en piezas poco volátiles; así evitarás falsas alarmas en cada refactor visual menor.
Mide la cobertura de ramas
Activa coverageReporters: ['text', 'lcov'] y revisa los puntos ciegos. Verás con claridad qué caminos lógicos no pisan todavía tus pruebas.
Optimiza los fake timers
Para lógica basada en setTimeout o debounce, los temporizadores controlados de Jest aceleran las specs y evitan esperas innecesarias.
Revisa tu pipeline de CI
Ahora que Karma salió de escena, ajusta el caché de dependencias y elimina pasos de navegador. Ganas minutos en cada ejecución automática.

Has sentado un cimiento robusto: pruebas legibles, resistentes y fáciles de ampliar. A partir de aquí, cualquier nueva funcionalidad se incorporará con confianza y sin temer al efecto dominó.

Bonus: Jest y Angular Testing Library

¿Listo para ver cómo el mismo test respira libertad sin fixture, sin detectChanges() y sin ese ruido que encoge la vista?

Observa esta versión con Angular Testing Library: minimalista, robusta y pensada para el futuro.

Prueba migrada (Jest y Angular Testing Library):

// counter.component.spec.ts (Después)
import { render, screen, fireEvent } from '@testing-library/angular';
import { CounterComponent } from './counter.component';
import '@testing-library/jest-dom'; // Para matchers extendidos como.toBeInTheDocument()

describe('CounterComponent (Jest/Testing Library)', () => {
  // Helper centralizado: un solo punto de cambio
  const setup = async () => {
    await render(CounterComponent); // crea componente + fixture por ti
    const getButton = (label: string) => screen.getByRole('button', { name: label });
    return {
      getCount: () => screen.getByTestId('count'),
      getButton,
    };
  };

  it('Create and display initial count of 0', async () => {
    const { getCount } = await setup();
    expect(getCount()).toHaveTextContent('0');
  });

  it('Increment count when + button is clicked', async () => {
    const { getButton, getCount } = await setup();
    fireEvent.click(getButton('+'));

    expect(getCount()).toHaveTextContent('1');
  });

  it('Decrement count when - button is clicked', async () => {
    const { getButton, getCount } = await setup();
    fireEvent.click(getButton('-'));
    expect(getCount()).toHaveTextContent('-1');
  });
});

Sin fixtures ni TestBed.compileComponents(). render() hace la magia tras bambalinas.
Selectores accesibles (getByRole): resistentes a cambios de orden o estilo.
Flujos síncronos por defecto: cuando algo sea realmente asíncrono, usa await waitFor(() => …) y listo.

¿Te gustó la sensación de limpieza? En mi libro sobre testing moderno en Angular, profundizo en querying accesible, patrones de state observers y prácticas de rendimiento que hacen que tus tests vuelen.

¿Prefieres aprender mirando? Aquí tienes tu atajo visual

Sé que la instalación de Angular Testing Library merece un tutorial aparte; lo verás detallado en el próximo artículo.

Mientras tanto, si eres de los que absorben conceptos viendo cada clic en tiempo real, he preparado un vídeo exprés donde compruebas, paso a paso, cómo escribir un unit test de un input required con Jest.

▶️ *Ver el vídeo en YouTube *

Beneficios medibles: Tiempo de ejecución y reporte de cobertura

En pocas líneas:

Velocidad a otro nivel
Jest ejecuta tests en paralelo y en JSDOM; suites que tardaban 15 min con Karma pueden bajar a 1-2 min.
Cobertura con un flag
jest --coverage genera informes detallados sin plugins extra, así ves al instante qué ramas faltan por probar.
Mocking integrado y simple
Con jest.fn() o jest.mock() aísla servicios y APIs globales sin configurar librerías adicionales.
Snapshot testing
Captura la salida del componente y detecta al momento cualquier cambio inesperado en la UI.

En conjunto, obtienes ciclos de feedback mucho más rápidos, builds de CI más baratas y una confianza mayor en cada refactor.

Conclusión

Dar el salto de Karma/Jasmine a Jest es pasar de un motor con años de servicio a uno pensado para la velocidad y la claridad de hoy. En minutos tendrás:

Pruebas que se ejecutan en paralelo y terminan antes de que apures el café.
Cobertura de código con un simple --coverage, sin plugins ni rodeos.
Mocks y snapshots listos para blindar cada refactor.

Cada segundo ganado en el test runner vuelve a tu desarrollo: menos espera, más funciones nuevas, mayor confianza.

¿Quieres ver cómo aplicar Jest a casos reales y tener ejemplos de producción listos para copiar y pegar? Descúbrelo en nuestro eBook y lleva tus pruebas al siguiente nivel. Haz clic aquí y conviértete en el desarrollador que rompe la barra de progreso antes de que empiece a cargar.

Cómo Crear un Framework de JavaScript desde Cero - La Historia de Brisa Build

Bezael Pérez — Mon, 28 Oct 2024 22:50:00 +0000

En el mundo de desarrollo web, los frameworks de JavaScript se han vuelto herramientas esenciales para la creación de aplicaciones modernas. Desde Angular y React hasta Vue y Svelte, cada uno ofrece un enfoque único para resolver problemas de arquitectura, rendimiento y experiencia de usuario. Sin embargo, muchos desarrolladores se han preguntado: ¿realmente necesitamos otro framework de JavaScript?

Hoy quiero compartir la historia de cómo y por qué se creó Brisa, un nuevo framework de JavaScript, de la mano de su propio creador, Aral Roca. Brisa no solo busca resolver problemas específicos de performance y modularidad en aplicaciones web, sino que también plantea una visión innovadora sobre cómo los desarrolladores pueden construir interfaces modernas sin perder de vista el funcionamiento interno de la web y el servidor.

¿Qué es Brisa?

Brisa es un framework que ha sido desarrollado desde cero con el propósito de mejorar la comunicación entre el cliente y el servidor, aprovechando al máximo la tecnología de web components y signals. Uno de los principales problemas que Aral identificó en muchos frameworks actuales era la complejidad de manejar acciones del servidor y del cliente de forma eficiente. Con Brisa, cualquier evento puede ejecutarse en el servidor, y el código que se necesita en el cliente es mínimo.

Un aspecto innovador de Brisa es que funciona sin necesidad de escribir código en el cliente para manejar eventos en el servidor. A través de un sistema llamado RPC (Remote Procedure Call) de solo 2 KB, Brisa permite que las interacciones se procesen directamente desde el servidor. Esto no solo facilita el desarrollo, sino que también reduce significativamente la cantidad de código necesario en el cliente, mejorando así el rendimiento general de la aplicación.

El Origen de Brisa

La idea de crear Brisa nació cuando Aral tuvo una conversación inspiradora con Misko Hevery, el creador de Quick.js, durante un evento en Barcelona. La visión de Misko y su enfoque para mejorar la performance en aplicaciones web dejaron una marca en Aral.
"Fue como si estuviera hablando de su propio hijo", dice Aral, recordando la conversación. Inspirado por este nivel de pasión y compromiso, Aral decidió que él también quería crear un framework, pero no uno más en el montón; quería algo que resolviera problemas que él mismo había enfrentado.

Así, comenzó a trabajar en Brisa, un proyecto que combina lo mejor de las interacciones en tiempo real entre cliente y servidor, y que es lo suficientemente ligero como para integrarse sin fricciones con otros componentes web. Brisa surgió como un experimento que luego se convirtió en un framework completo, diseñado para la eficiencia y la escalabilidad en la web moderna.

Principales Características de Brisa

Server Actions sin Us Client y Us Server: En Brisa, todo el código se ejecuta en el servidor por defecto. Solo en situaciones específicas se habilita la ejecución en el cliente, lo cual simplifica la gestión del código y evita complejidades innecesarias.

Components Web Integrados: Los web components de Brisa son completamente modulares y se pueden utilizar en otros frameworks. Esto significa que cualquier componente creado en Brisa se puede reutilizar en React, Angular, o Vue, brindando a los desarrolladores mayor flexibilidad.

Signals Avanzados: Brisa implementa un sistema de signals para la gestión de estados. Estos signals permiten que los componentes se actualicen automáticamente cuando cambian sus propiedades, sin necesidad de un render completo de la página. Esto optimiza el rendimiento y reduce la carga del cliente.

RPC de Solo 2 KB: Uno de los aspectos más innovadores de Brisa es su sistema de RPC de solo 2 KB, que permite a los desarrolladores manejar interacciones desde el servidor sin necesidad de escribir código en el cliente. Esto resulta en un código mucho más ligero y simplificado, mejorando la eficiencia general de las aplicaciones.

¿Realmente Necesitamos Otro Framework?

Es comprensible que algunos desarrolladores se pregunten si realmente necesitamos otro framework de JavaScript. La respuesta de Aral Roca es clara: "Con cada nuevo framework vienen nuevas oportunidades de mejorar y de aprender".

A lo largo de los años, hemos visto cómo cada framework ha aportado algo diferente y único. React nos enseñó sobre el virtual DOM, Angular sobre la modularidad en gran escala, y Vue sobre la simplicidad en el desarrollo de componentes. Brisa, por su parte, nos muestra cómo combinar la potencia de la plataforma web y las técnicas de renderizado desde el servidor para optimizar aplicaciones modernas.

Aplicaciones de Brisa en el Mundo Real

Las ventajas de Brisa son particularmente valiosas en aplicaciones de alto rendimiento, como aquellas que requieren de cargas rápidas y mínima latencia en el manejo de datos en tiempo real. Brisa permite que la comunicación entre el cliente y el servidor sea mucho más eficiente, lo cual resulta ideal para aplicaciones que manejan un gran volumen de interacciones de usuario.
Además, su integración con los web components facilita la creación de aplicaciones modulares que pueden integrarse con otras tecnologías sin problemas.

La Comunidad Detrás de Brisa

Aral también enfatiza la importancia de la comunidad en el desarrollo de Brisa. Para él, el apoyo y las contribuciones de otros desarrolladores han sido fundamentales. “La mejor parte de trabajar en Brisa ha sido la oportunidad de aprender de otros desarrolladores y ver cómo ellos aplican este framework en sus propios proyectos”, comenta Aral. Brisa es un framework abierto y siempre se anima a la comunidad a contribuir, ya sea con ideas, reporte de problemas, o nuevas funcionalidades.

¿Qué Sigue para Brisa?

Aral tiene grandes planes para el futuro de Brisa. Con la posibilidad de que los signals sean incluidos en la web platform oficial gracias a TC39, el comité encargado de la evolución de JavaScript, Brisa está en una excelente posición para volverse aún más eficiente y ligero. Si se incluye la funcionalidad de signals en el lenguaje base, las aplicaciones que usen Brisa podrían beneficiarse de un rendimiento aún mayor, con menos dependencia de bibliotecas externas.

¿Quieres Probar Brisa?

Si eres un desarrollador curioso o te interesa conocer más sobre la arquitectura de aplicaciones web avanzadas, te invito a darle una oportunidad a Brisa. No solo verás un enfoque innovador para resolver problemas de rendimiento y modularidad, sino que también podrás aprender sobre las últimas tendencias en el desarrollo de JavaScript.

¡Comparte tus pensamientos en los comentarios!
¿Te entusiasma la idea de un nuevo framework como Brisa?
¿Qué piensas sobre el futuro de los frameworks de JavaScript?

¡Espero tus opiniones!

DEV Community: Bezael Pérez

SDD en proyectos brownfield: pros, contras y la estrategia que realmente funciona

SDD: pros, contras y la estrategia que realmente funciona

Primero, el problema real

Lo que SDD sí resuelve en brownfield

Lo que SDD no resuelve

La estrategia que realmente funciona

El efecto acumulado

Una última cosa

El método para construir con agentes de IA

BMAD: el método para construir con agentes de IA como si tuvieras un equipo

BMAD: el método para construir con agentes de IA como si tuvieras un equipo

Qué es BMAD

Los cuatro roles

Un ejemplo real, paso a paso

Paso 1 — El Business Analyst entra primero

Paso 2 — El Product Manager toma ese documento

Paso 3 — El Architect diseña antes de que se escriba código

Paso 4 — El Developer implementa con todo claro

Por qué funciona mejor que hablar con un solo agente

La conexión con la especificación

Cómo empezar con BMAD

Cómo integrar OpenSpec con Claude Code paso a paso

Qué es OpenSpec (en 2 párrafos)

Requisitos

Paso 1 — Instalación

Paso 2 — Inicializar en tu proyecto

Paso 3 — Llenar project.md

Paso 4 — Entender agents.md

Paso 5 — Demo completa: añadir autenticación JWT

5.1 — Crear la propuesta

5.2 — Revisar y ajustar

5.3 — Implementar

5.4 — Archivar

Tips para sacarle partido con Claude Code

Cuándo usarlo y cuándo no

Conclusión

Spec-Driven Development: el método para construir con IA sin perder el control

El vibe coding tiene un límite

Qué es SDD

Lo que SDD no es

Las 7 fases del flujo

Fase 1: Idea

Fase 2: Research (opcional)

Fase 3: Prototipo (opcional)

Fase 4: PRD (La spec)

Fase 5: Kanban

Fase 6: Execution loop

Fase 7: QA

El flujo en una imagen

Por qué ahora

Para empezar hoy

Tu app de vibe coding funciona. Eso es exactamente el problema.

Lo que la IA no te dice cuando genera tu código

/vibe-audit — 30 segundos para saber en qué lío estás

Los problemas que encuentra. Siempre.

El resto del kit

La diferencia entre vibe coding y vibe coding bien hecho

Your vibe coding app works. That's exactly the problem.

What the AI doesn't tell you when it generates your code

/vibe-audit — 30 seconds to know what mess you're in

The problems it finds. Every time.

The rest of the kit

The difference between vibe coding and vibe coding done right

De Senior Dev a Tech Lead: la transición donde más talento se pierde ¿Te ha pasado?

Por qué los desarrolladores que pasan a tech lead fracasan…

Por qué los desarrolladores que pasan a tech lead fracasan…

De Senior Dev a Tech Lead: la transición donde más talento se pierde

El conflicto central

🚨 Los 5 errores más comunes (y cómo evitarlos)

1. El síndrome del héroe

2. El micromanagement disfrazado de “calidad”

3. Falla de comunicación

4. Olvidar el factor humano

5. Seguir queriendo ser el mejor programador

💡 En resumen

Jest 30: Más Rápido, Inteligente y Listo para el Futuro. ¿Es Hora de Actualizar?

¿Por qué esta actualización es un punto de inflexión?

Adiós a la Lentitud

Nuevas Herramientas para el Desarrollador

`/vibe-audit` — 30 segundos para saber en qué lío estás

`/vibe-audit` — 30 seconds to know what mess you're in

2. Ajuste del `package.json`

3. Configuración de `tsconfig.spec.json`

4. Creación de `jest.config.ts`

5. Creación de `setup-jest.ts`