DEV Community: Miguel Lopez

Spec-Driven Development con Superpowers: Como evoluciono mi vibecoding

Miguel Lopez — Fri, 29 May 2026 20:29:24 +0000

El problema con el vibecoding común

Todos hemos estado ahí. Abres Claude Code, escribes "hazme una app de tareas con autenticación y base de datos", y la IA se lanza a escribir código durante 10 minutos. El resultado: una mezcla de archivos que a veces funciona, a veces no, y que nadie, ni tú ni la IA, entiende del todo bien.

Eso es vibecoding, darle un prompt vago a la IA y esperar que interprete correctamente lo que tienes en la cabeza. Funciona para prototipos de 20 minutos. No funciona para software real.

El problema no es la IA. El problema es que le estás pidiendo que haga arquitectura, diseño, implementación y revisión al mismo tiempo, sin ningún proceso.

Qué es Superpowers

https://github.com/obra/superpowers es un plugin para Claude Code (y otros agentes de IA como Cursor, Gemini CLI, OpenAI Codex) que le inyecta skills (habilidades especializadas o comportamientos) al modelo. En lugar de que Claude improvise cómo abordar una tarea compleja, sigue un proceso probado.

Se instala en segundos:

Claude Code

/plugin install superpowers@claude-plugins-official

Una vez instalado, Claude tiene acceso a skills como brainstorming, writing-plans, subagent-driven-development, requesting-code-review, y muchas más. Cada skill es una guía de comportamiento que el modelo sigue disciplinadamente.

Mi flujo. Spec-Driven Development en 8 pasos

Lo que aprendí trabajando con IA es que la calidad del software que produce es directamente proporcional a la claridad del proceso que le das.

Este flujo de 8 pasos convierte el caos del vibecoding en algo reproducible y predecible.

Paso 1: Brainstorming

Antes de escribir una sola línea de código, exploro el problema con la skill superpowers:brainstorming.

/skill superpowers:brainstorming
"Quiero construir un sistema de notificaciones para la app"

La diferencia con simplemente preguntarle a Claude es que esta skill hace preguntas que yo no pensé hacer: ¿quién consume las notificaciones?, ¿qué pasa si el usuario está offline?, ¿necesitamos tiempo real o eventual consistency basta?, ¿cómo
afecta esto a la arquitectura existente?

El brainstorming no es generar ideas al azar —es descubrir los requisitos ocultos antes de que se conviertan en bugs.

Paso 2: Verificar el diseño

El brainstorming produce ideas. La verificación las filtra. Aquí reviso con la IA si el diseño propuesto tiene sentido técnico:

¿Hay decisiones de arquitectura que se contradicen?
¿Hay over-engineering? (YAGNI)
¿Hay suposiciones no validadas?

Este paso me ha salvado de construir cosas que no necesitaba. La IA es muy buena proponiendo soluciones elaboradas. Ser disciplinado aquí evita semanas de trabajo innecesario.

Paso 3: Escribir el spec

Con el diseño validado, la skill superpowers:writing-plans genera un documento de especificación estructurado. Un spec no es código —es la descripción precisa de lo que el software debe hacer.

Un buen spec tiene:

Comportamiento esperado por caso de uso
Casos borde explícitos
Lo que está fuera de scope (tan importante como lo que está dentro)
Criterios de aceptación verificables

Sin spec, cada desarrollador (o agente de IA) interpreta los requisitos a su manera. Con spec, todos trabajan hacia el mismo objetivo.

Paso 4: Revisar el spec

Aquí la IA actúa como revisor crítico del spec que acaba de escribir. La skill lanza un subagente específico para revisar documentos con esta lógica:

| Categoría | Qué buscar |
|---------------|--------------------------------------------------|
| Completitud | TODOs, secciones incompletas, "por definir" |
| Consistencia | Requisitos que se contradicen |
| Cobertura | Casos de error no manejados, edge cases |
| YAGNI | Features no solicitadas, over-engineering |

Si el revisor encuentra problemas, volvemos al paso 3. Si aprueba, seguimos.

Este ciclo de spec → revisión parece lento. En realidad es lo más rápido: un problema detectado en el spec tarda 5 minutos en corregirse. El mismo problema detectado en producción tarda días.

Paso 5: Escribir el plan de implementación

El spec dice qué. El plan dice cómo y en qué orden.

La skill genera un plan con tareas atómicas e independientes. Cada tarea tiene esta estructura:

### Tarea N: [Nombre del componente]

Archivos:

Crear: ruta/exacta/al/archivo.ts
Modificar: ruta/existente/archivo.ts:123-145
Test: tests/ruta/test.ts
[ ] Paso 1: Escribir el test que falla
[ ] Paso 2: Verificar que falla
[ ] Paso 3: Implementar el mínimo código
[ ] Paso 4: Verificar que pasa
[ ] Paso 5: Commit

git add tests/ruta/test.ts src/ruta/archivo.ts
git commit -m "feat: agregar feature específica"

La granularidad importa: tareas demasiado grandes generan conflictos entre subagentes. Tareas demasiado pequeñas generan overhead. El punto justo es una tarea por componente o responsabilidad clara.

Paso 6: Revisar el plan

Igual que con el spec, el plan pasa por un revisor antes de ejecutarse. El revisor verifica:

¿El plan refleja fielmente el spec?
¿Las tareas son verdaderamente independientes entre sí?
¿Las rutas de archivos son correctas?
¿El orden de implementación tiene sentido?

Si una tarea depende de otra, no pueden ejecutarse en paralelo. El revisor detecta estas dependencias ocultas antes de que rompan la ejecución.

Paso 7: Lanzar el plan con subagentes

Aquí está la magia del sistema. Con superpowers:subagent-driven-development, cada tarea del plan se ejecuta en un subagente independiente en paralelo o secuencialmente según las dependencias.

El flujo real se ve así:

[Extraer las 5 tareas del plan]
[Crear TodoWrite con todas las tareas]

Tarea 1: Sistema de colas
[Despachar subagente implementador con contexto completo de la tarea]

Implementador: "¿La cola debe ser persistente o en memoria?"
Tú: "Persistente con Redis"

Implementador: "Implementando..."
- Cola implementada con BullMQ
- 8/8 tests pasando
- Self-review: agregué manejo de reintentos, estaba en el spec
- Commit realizado

[Despachar revisor de spec]
Revisor: ✅ Cumple spec — todos los requisitos implementados

[Despachar revisor de código]
Revisor: Fortalezas: buena cobertura, arquitectura limpia
Issues: ninguno
Resultado: ✅ Aprobado

[Marcar Tarea 1 como completada]
[Continuar con Tarea 2...]

Cada tarea pasa por tres capas de validación:

El implementador hace self-review antes de entregar
El revisor de spec verifica que se implementó lo que se especificó (ni más, ni menos)
El revisor de código verifica calidad técnica

Si el revisor de spec encuentra que se implementó algo no pedido o faltó algo del spec, el implementador lo corrige antes de seguir con la siguiente tarea.

Paso 8: Commit de los cambios

Cada tarea hace su propio commit atómico siguiendo el formato convencional:

git add tests/ruta/test.ts src/ruta/archivo.ts
git commit -m "feat: agregar sistema de colas con reintentos"

Al final del plan, cada feature está en su propio commit trazable, con tests pasando, alineado con el spec original.

Por qué esto es una evolución y no solo "más pasos"

El vibecoding común trata a la IA como un oráculo: le haces una pregunta y recibes código. El problema es que un oráculo no tiene memoria del proceso, no tiene criterio de corrección, y no puede verificar su propio trabajo.

Spec-Driven Development trata a la IA como un equipo de ingeniería.

  ┌──────────────────────────────────────┬───────────────────────────────────────────┐
  │              Vibecoding              │          Spec-Driven Development          │
  ├──────────────────────────────────────┼───────────────────────────────────────────┤
  │ Un prompt → todo el código           │ Proceso estructurado en fases             │
  ├──────────────────────────────────────┼───────────────────────────────────────────┤
  │ Errores descubiertos en ejecución    │ Errores detectados en spec/plan           │
  ├──────────────────────────────────────┼───────────────────────────────────────────┤
  │ La IA interpreta los requisitos      │ Los requisitos están escritos y validados │
  ├──────────────────────────────────────┼───────────────────────────────────────────┤
  │ Código monolítico difícil de revisar │ Commits atómicos por responsabilidad      │
  ├──────────────────────────────────────┼───────────────────────────────────────────┤
  │ Resultado impredecible               │ Resultado alineado con el diseño original │
  ├──────────────────────────────────────┼───────────────────────────────────────────┤
  │ No escala con complejidad            │ Escala con subagentes paralelos           │
  └──────────────────────────────────────┴───────────────────────────────────────────┘

La clave no es que la IA sea más inteligente con este flujo. Es que el proceso elimina la ambigüedad que hace que la IA tome decisiones equivocadas.

Cuando la IA tiene un spec claro, un plan preciso y un revisor que verifica cada paso, produce software de la misma calidad que un equipo de ingenieros disciplinado. Sin ese proceso, produce el mismo vibecoding que todos hemos sufrido.

El resultado

Con este flujo, dejé de pasar horas corrigiendo código que la IA generó mal porque yo no fui claro. Ahora los problemas se detectan en el paso 3 o el paso 6 —cuando corregirlos cuesta minutos, no días.

El vibecoding es divertido para explorar ideas. El Spec-Driven Development es lo que uso cuando el código importa. Se puede decir que es ingeniería pura y dura.

Angular 19: Reactividad Simple

Miguel Lopez — Fri, 25 Apr 2025 18:43:05 +0000

Hola de nuevo 👋. En artículos como Tu Chatbot Open Source en VS Code o Mixins en SASS, siempre busco herramientas que hagan el código más limpio. ¡Hoy les traigo los nuevos Signals, Models y el control flow con @if, @for, @else y @empty!

1. Signals: Reactividad Sin Esfuerzo

Los Signals son variables "inteligentes" que actualizan la UI automáticamente.

// Ejemplo: Contador reactivo  
import { signal, computed } from '@angular/core';  

class ContadorComponent {  
  count = signal(0);  
  double = computed(() => this.count() * 2);  

  incrementar() {  
    this.count.update(v => v + 1);  
  }  
}

¿Por qué me gustan?

No más subscribe() o async pipe.
Integración perfecta con los nuevos @if y @for 😉.

2. Control Flow: Olvida los ngIf y ngFor

Angular 19 introduce una sintaxis más limpia para condicionales y bucles.

@if y @else

<!-- Ejemplo: Mensaje de usuario -->  
@if (usuario()) {  
  <p>Bienvenido, {{ usuario().nombre }}</p>  
} @else {  
  <p>Inicia sesión 🔑</p>  
}

Ventaja: Más intuitivo que *ngIf y else, sin .

@for y @empty

<!-- Ejemplo: Lista de tareas -->  
@for (tarea of tareas(); track tarea.id) {  
  <div>{{ tarea.titulo }}</div>  
} @empty {  
  <p>¡No hay tareas! 🎉</p>  
}

track: Mejora el rendimiento (¡adiós a trackBy!).
@empty: Muestra contenido si la lista está vacía.

3. Models y Inputs: Validación Integrada

Con Models, podras validar Inputs automaticamente:

import { model } from '@angular/core';  

class FormularioComponent {  
  // Modelo con validación automática  
  email = model<string>('', {  
    validate: (valor) => valor.includes('@') ? null : 'Email inválido ❌'  
  });  
}

4. Inject y Effect: Código Más Limpio

Inyectar servicios sin constructor

import { inject } from '@angular/core';  

class PerfilComponent {  
  servicioAuth = inject(AuthService); // ¡Magic!  
}

Effect para sincronizar datos (ejemplo: guardar en localStorage):

effect(() => {  
  localStorage.setItem('tema', tema());  
});

Ejemplo Completo: Lista de Tareas Reactiva

import { signal, effect } from '@angular/core';  

class TareasComponent {  
  tareas = signal<Tarea[]>([]);  

  constructor() {  
    effect(() => {  
      console.log('Tareas actualizadas:', this.tareas());  
    });  
  }  

  agregarTarea(titulo: string) {  
    this.tareas.update(t => [...t, { id: Date.now(), titulo }]);  
  }  
}

HTML

<!-- Template con @for y @if -->  
@if (tareas().length > 0) {  
  <div class="lista">  
    @for (tarea of tareas(); track tarea.id) {  
      <div>{{ tarea.titulo }}</div>  
    }  
  </div>  
} @else {  
  <p>¡Añade tu primera tarea! 📝</p>  
}

Angular 19 me encanta por su sencillez. Los Signals, el nuevo control flow (@if, @for, @empty) y Models eliminan código repetitivo y hacen todo más intuitivo.

Para los que vienen de versiones antiguas:

El nuevo control flow es opcional, pero recomiendo usarlo (¡es el futuro!).

Signals integran mejor con Reactividad que los Observables en componentes simples.

Tu Chatbot Open Source en VS Code

Miguel Lopez — Wed, 13 Nov 2024 14:53:37 +0000

El día de hoy vamos a hablar sobre un tema que a muchos les interesa, como configurar nuestro propio chatbot open source en VS Code y que funcione sin internet (Pd: para la instalación si requerimos internet).

Para el día de hoy utilizaremos 2 herramientas.

LM Studio, un software para uso de LLM open source como chatbots en nuestro sistema operativo. .
Continue, una extensión para VS Code que nos permitirá consumir nuestro modelo desde LM Studio. .

El primer paso es descargar LM Studio e instalarlo en nuestro sistema operativo:

Al tener LM Studio instalado, lo abrimos y a nuestra izquierda tenemos 4 iconos:

Chat: Funciona muy parecido a Chatgpt, Gemini o Perplexity.

Developer: Una sección para lanzar el LM Studio como API de terceros en local.

My models: Donde podrás ver todos los modelos disponibles en tu LM Studio.

Discover: La sección donde se pueden descargar los distintos modelos.

Ahora que ya entendemos un poco mejor la estructura del LM Studio, podemos comenzar por ir a la sección Discover y descargar los modelos que queramos, al tener esto listo ya podemos ir al chat y comenzar a usar el LM Studio como si de ChatGPT se tratara (Claro que no con tanta potencia, recordemos que esto es open source).

Nos vamos a la pestaña de Chat y en medio de la pantalla hay una barra donde nos permite elegir entre todos los modelos que hemos descargado para iniciar el chat.

Ahora podemos comenzar a hablar con nuestro chatbot sin ningun problema, y segun el modelo que utilicemos podemos darle archivos como imagenes, docx, xlsx, pdf, entre otros.

Bueno podemos decir que ya tenemos un chatbot pero eso no es todo lo que queremos, queremos usar este chatbot dentro de VS Code para trabajar con el sin tener que estar moviéndonos entre pestañas y poder contextualizar rápidamente al modelo con el que estamos trabajando.

Nos dirigimos a la pestaña Developer del LM Studio y presionamos el boton Start Server.

Esto lanzará el LM Studio como una API, luego vamos a descargar la extensión Continue (He dejado el link al principio).

Habiendo descargado la extensión en nuestro VS Code veremos algo muy parecido a esto:

Procedemos a configurarlo presionando en "Select Model" y luego "Add chat model"

Esto abrira un modal que nos solicitará algunos datos y lo configuraremos de la siguiente manera:

Y ahora nuestro VS Code tiene su propio chatbot con modelos LLM open source.

E incluso nos permitira contextualizar o hacer algunas acciones directamente desde el código sin usar el chatbot.

Esto es todo por hoy, espero que les haya gustado este curso, pronto vendré con mas para ayudarlos con tips, cursos y herramientas para desarrolladores.

Mixins en SASS

Miguel Lopez — Wed, 13 Nov 2024 14:24:11 +0000

Los mixins son herramientas que proveen los preprocesadores CSS, aunque no son funciones se pueden percibir como tal, y su principal utilidad es reutilizar código.

En mas de una ocasión hemos tenido la necesidad de crear múltiples clases que hacen lo mismo pero cambian en un solo valor, ejemplo múltiples clases para el font-size.

.fs-10 {
  font-size: 10px;
}
.fs-20 {
  font-size: 20px;
}
.fs-30 {
  font-size: 30px;
}

Si nos fijamos, lo único que cambia en este escenario es el numero tanto para nombrar la clase como para setear el valor del font-size, usado un mixin podemos crear una función que cree este código para nosotros de forma automatica.

Ejemplo:

// Esto es un mapa, lo que conocemos como un objeto en javascript
$sizes: (
  "10": "10px",
  "20": "20px",
  "30": "30px"
) 

// El mixin que crea las clases
@mixin generate-font-sizes($sizes) {
  // Recorremos cada uno de los elementos del mapa
  @each $key, $value in $sizes{
    // Creamos la clase e interpolamos los valores
    .fs-#{$key} {
      font-size: #{$value};
    }
  }
}

// Invocamos al mixin para que se ejecute
@include generate-font-sizes($sizes);

Al compilar nuestro código tendremos el mismo resultado que la primera vez, pero ahora pueden estar pensando que nuestro código es mas largo que el resultado, y tal vez es cierto pero si quiero por ejemplo hacer un recorrido del 1 al 100 y crear clases del fs-1 al fs-100 tambien puedo hacerlo con un mixin

@mixin generate-font-sizes() {
  @for $size from 1 through 100 {
    .fs-#{$size} {
      font-size: #{$size}px;
    }
  }
}
@include generate-font-sizes();

Con esto tendremos el resultado esperado, y esto no solo sirve para el font-size sino para cualquier cosa que se nos ocurra, podemos construir grandes cantidades de código con pequeños bloques de código en un mixin.

Esto es todo por ahora, aprendimos a usar los mixing

Mixins en SASS

Miguel Lopez — Fri, 08 Nov 2024 16:57:57 +0000

Los mixins son herramientas que proveen los preprocesadores CSS, aunque no son funciones se pueden percibir como tal, y su principal utilidad es reutilizar código.

En mas de una ocasión hemos tenido la necesidad de crear múltiples clases que hacen lo mismo pero cambian en un solo valor, ejemplo múltiples clases para el font-size.

.fs-10 {
  font-size: 10px;
}
.fs-20 {
  font-size: 20px;
}
.fs-30 {
  font-size: 30px;
}

Ejemplo:

// Esto es un mapa, lo que conocemos como un objeto en JavaScript
$sizes: (
  "10": "10px",
  "20": "20px",
  "30": "30px"
) 

// El mixin que crea las clases
@mixin generate-font-sizes($sizes) {
  // Recorremos cada uno de los elementos del mapa
  @each $key, $value in $sizes{
    // Creamos la clase e interpolamos los valores
    .fs-#{$key} {
      font-size: #{$value};
    }
  }
}

// Invocamos al mixin para que se ejecute
@include generate-font-sizes($sizes);

// El mixin que crea las clases
@mixin generate-font-sizes() {
  // El loop que hace el recorrido de 1 a 100
  @for $size from 1 through 100 {
    // Creamos la clase e interpolamos los valores
    .fs-#{$size} {
      font-size: #{$size}px;
    }
  }
}

// Invocamos al mixin para que se ejecute
@include generate-font-sizes();

Esto es todo por ahora, aprendimos a usar los mixin y a reutilizar código CSS en los preprocesadores.

El uso de los modelos de IA open source en el desarrollo

Miguel Lopez — Wed, 06 Nov 2024 14:08:11 +0000

Durante el ultimo año han aparecido un gran numero de herramientas con inteligencia artificial para hacer mas sencilla la vida de los usuarios, ya sea generación de imágenes o chatbots, incluso escalando a herramientas que ejecutan procesos gigantescos y profesionales.

He estado investigando, aprendiendo y probando muchas de estas herramientas desde chatgpt, gemini hasta dall-e o midjourney, todas funcionan muy bien pero cuando yo quiero escalar mis aplicaciones con estas herramientas me encuentro con que no tienen una alternativa gratuita u open source.

Esto me ha hecho llevar mi investigación a un paso mas allá y me he encontrado con stable diffusion ui (Generación de imágenes, https://github.com/AUTOMATIC1111/stable-diffusion-webui) y con *ollama *(Chatbot, https://ollama.com/), ambas son herramientas open source que te permiten ejecutar un servicio como API para consumirlo desde cualquiera de nuestras aplicaciones, con esto he llegado un paso mas allá con alternativas open source, pero para que esto funcione debo mantener estas herramientas ejecutándose para ser consumidas por nuestras aplicaciones.

Para entender como llevar esto a nuestras aplicaciones es importante entender como funcionan estas herramientas, y básicamente lo que hacen es utilizar archivos con la extensión "safetensors" que son LLM o modelos de lenguaje de gran tamaño, siendo estos modelos entrenados para realizar diferentes funciones según las necesidades de quien lo entrene (Ejemplo: Generación de imágenes, traducción, desarrollo de código, chatbot, entre otros).

Al entender un poco los modelos LLM y los archivos "safetensors" nos llega la siguiente pregunta como usar estos archivos en mis aplicaciones, y aquí es donde entra HugginFace, una web/base de datos de modelos de inteligencia artificial open source, y han creado su librería propia para python con 2 componentes extremadamente útiles para lo que queremos "Transformers" y "Diffusers".

*Transformers *(https://huggingface.co/docs/transformers/index) es el componente que nos permite consumir cualquier modelo especializado en texto, ejemplo convertir audio a texto o viceversa, modelos de chatbox como llama de Meta, entre otros.

import transformers

import torch

model_id = "meta-llama/Llama-3.1-8B"

pipeline = transformers.pipeline(
    "text-generation", model=model_id, model_kwargs={"torch_dtype": torch.bfloat16}, device_map="auto"
)

pipeline("Hey how are you doing today?")

Diffusers (https://huggingface.co/docs/diffusers/index) es el componente que nos permite consumir cualquier modelo especializado en generación de imágenes, ejemplo stable diffusion.

from diffusers import AutoPipelineForText2Image
import torch

pipe = AutoPipelineForText2Image.from_pretrained("stabilityai/sdxl-turbo", torch_dtype=torch.float16, variant="fp16")
pipe.to("cuda")

prompt = "A cinematic shot of a baby racoon wearing an intricate italian priest robe."

image = pipe(prompt=prompt, num_inference_steps=1, guidance_scale=0.0).images[0]

A este proceso se le conoce como Inferencia de modelos LLM, y a partir de aquí basado en esta información puedes comenzar a aplicar inteligencia artificial en tus diferentes aplicaciones con Python.

Cabe destacar que también he intentado usar la inferencia de modelos con otro lenguaje como nodejs y la verdad es que no funciona tan bien como con python, pero es importante mencionar que se necesita un hardware potente para la inferencia de modelos LLM por lo que lo que puedes ahorrar el uso de las API de ChatGPT o Gemini lo puedes gastar en comprar un hardware adecuado.

Hasta aquí llega este mi primer articulo, espero que mi camino para el uso de modelos LLM en el desarrollo de software te ayude a saltar pasos en este camino.