Crear tu propio SaaS con IA y saber que está bien hecho

Abre el listado de suscripciones de tu banco. Ese cuadradito de enlaces, ese formulario, ese calendario de reservas: cada SaaS cuesta entre 5 y 50 euros al mes y muchos caben en un fin de semana de trabajo con un agente de IA delante.

La tentación, llegado ese punto, es escribir un prompt monolítico. Un texto enorme, muy bien pensado, que describe pantallas, modelo de datos, seguridad y casos límite, y que pegas de una sentada esperando una aplicación entera.

Este post va de lo contrario.

Y conviene que sepas dónde encaja. Si en cómo hacer bien vibe coding vimos cuándo improvisar y cuándo frenar, esto es el paso lógico siguiente: cómo se improvisa con criterio en un proyecto concreto. No hay metodología nueva ni nada que firmar. Es vibe coding hecho un poco mejor, apoyado en un mecanismo pequeño que lo sostiene todo: la línea “Terminado cuando”.

Aquí verás qué le pides primero al agente, dónde paras a discutir con él, cómo compruebas que lo entregado sirve de verdad y en qué momento abres una sesión nueva para que revise su propio trabajo. Una secuencia que sirve igual para un Calendly, para un acortador de URLs o para el lector de RSS que llevas años pagando.

Esto es lo que vas a encontrar:

• Por qué reconstruir un SaaS que ya usas enseña más que cualquier tutorial
• Cómo elegir el servicio correcto y localizar su pieza difícil antes del primer prompt
• La línea “Terminado cuando” y cómo se escribe una que no se pueda esquivar
• Un checklist de validación para pasarle al agente o ejecutar tú a mano
• La secuencia completa, el revisor que no se cree nada y el día dos

Vamos al lío.

¿Por qué reconstruir algo que ya existe enseña más que un tutorial? ¶

Porque cuando sigues un tutorial el problema ya está resuelto antes de que empieces. Alguien decidió el modelo de datos, alguien eligió las librerías, alguien escondió las decisiones incómodas debajo de la alfombra.

Cuando reconstruyes un servicio que usas pasa lo contrario: tú ya sabes cómo se comporta el producto final. Has visto qué ocurre cuando cambias de zona horaria. Has recibido el email de confirmación. Has intentado reservar un hueco que alguien acababa de coger tres segundos antes.

Eso te convierte en el mejor tester posible de tu propio proyecto. No necesitas que nadie te diga si está bien: lo comparas con el original y lo sabes.

Con un agente de IA delante, esa ventaja se multiplica. Tú pones el criterio de producto, el agente pone la velocidad de tecleo. Si todavía andas dando los primeros pasos, el método para empezar a programar con IA te da el marco general y las ideas para tu primer proyecto te dan el catálogo. Aquí voy a por la mecánica.

Una advertencia honesta antes de seguir: casi todos estos servicios tienen ya una alternativa open source excelente. Calendly tiene Cal.com, con licencia AGPLv3 y más de 30.000 estrellas en GitHub. Si lo que quieres es una herramienta lista para producción, instálala y sigue con tu vida.

Lo que estás leyendo es otra cosa. Es el gimnasio.

¿Qué agente hace falta y con qué disciplina? ¶

Te vale cualquier agente de terminal decente. Aquí los ejemplos salen de Claude Code, pero Codex, OpenCode o Gemini CLI sirven igual; tienes la comparativa de agentes de IA en terminal si aún no has elegido.

Sobre el stack, la regla es sencilla: elige el que ya conoces. El alcance importa mucho más que el framework.

Y sobre la disciplina, no hay nada que reinventar. El Nivel 2 del post de vibe coding ya trae la lista larga: contexto en el prompt, pasos pequeños, commits frecuentes y no aceptar cambios masivos que no entiendes. De esa lista, tres son las que este tipo de proyecto castiga más si te las saltas:

1. Un commit por prompt cumplido. Si el paso pasa su criterio de cierre, se guarda. Si no, git restore y reformulas. Sin punto medio.
2. Tú ejecutas la aplicación, no el agente. Abre el navegador y míralo. Que los tests pasen no significa que el producto sirva, y las buenas prácticas de TDD siguen aplicando cuando quien teclea es un modelo.
3. El que escribe no revisa. Ni en equipos humanos ni con agentes, y por eso conviene tener claro cuánto código generado por IA hay que revisar de verdad. Hay skills específicas para revisión de código y seguridad, pero el principio funciona sin instalar nada.

Ese “una cosa cada vez, y cerrada” tiene una versión formal, que es el Spec Driven Development y su ecosistema de frameworks. No vamos por ahí todavía, a propósito: quiero que veas la secuencia en crudo, con sus asperezas, y que el orden te haga falta antes de que te lo venda.

Guía interactiva gratis

Elegir agente y presupuesto antes de teclear el primer prompt

Una parada entera del curso-juego va de elegir agente (Claude Code, OpenCode, Codex) y otra del presupuesto real. 17 paradas y sales con una checklist a tu medida.

Entra en el curso gratis →

¿Cómo eliges el SaaS correcto? ¶

Aquí se decide si el proyecto llega al domingo por la noche o muere el sábado a mediodía. Tres criterios, y los tres tienen que cumplirse:

• Que lo pagues. Si no sale de tu bolsillo, la motivación se evapora al segundo obstáculo. El recibo es el combustible.
• Que lo uses. Si no eres usuario, no vas a saber cuándo tu versión está mal. Y entonces solo estás siguiendo otro tutorial con pasos más largos.
• Que quepa. El primero no puede ser el difícil. Un acortador de enlaces se termina; un clon de Notion te enseña sobre todo a abandonar proyectos.

Cuando miras estos servicios uno a uno, lo que separa a los que se terminan de los que se abandonan casi nunca es la tecnología: es el recorte. Un clon de Notion no fracasa por difícil, fracasa porque nadie decidió qué parte de Notion no iba a existir. Con un gestor de tareas de equipo pasa igual: la versión que sirve es la que borra el noventa por ciento del original. Y con una base de datos visual tipo Airtable, lo que necesitas construir es tu flujo de trabajo concreto, no el constructor genérico.

Traducido: tu primera decisión de arquitectura es qué NO vas a construir.

¿Dónde está la pieza difícil? ¶

Todo servicio tiene una pieza que, si sale bien, hace que el resto sea decoración. Y suele estar escondida detrás de una interfaz que parece trivial.

En Calendly la pieza difícil no es la página de reserva. Son dos cosas: la aritmética de intervalos que genera los huecos (disponibilidad menos ocupado menos buffers, troceado) y la carrera entre dos invitados que pinchan el mismo hueco a la vez. Todo lo demás es formulario. Ese caso lo tengo desarrollado entero, pieza a pieza y con el prompt de cada una, en crea tu propio Calendly con IA.

Localizarla antes de escribir el primer prompt cambia el proyecto entero, porque determina el orden de la secuencia. Algunos ejemplos, con el precio de referencia de sus planes públicos y una estimación honesta de arranque:

⚠️ La tentación es empezar por la pantalla bonita. Resiste. Una interfaz preciosa encima de un núcleo roto es un decorado, y el decorado se cae cuando alguien lo usa dos veces.

Si no sabes identificar la pieza difícil, hay un truco: pregúntale al agente qué es lo que más le preocupa de construir ese producto y que ordene los riesgos. No para que decida, sino para que te dé material con el que decidir tú.

El prompt cero: el contexto que evita el 80% de los desastres ¶

Antes del primer npm create, escribe un fichero de contexto. AGENTS.md o CLAUDE.md, según tu agente. Y escríbelo con el agente, sin generar código todavía.

Vamos a construir una versión pequeña de [SERVICIO].

Escribe un fichero AGENTS.md con estas secciones, sin generar
todavía nada de código:

1. Qué es el producto en tres frases, con su usuario principal.
2. Stack: el que ya uso a diario. Nada de librerías nuevas sin
   preguntarme antes.
3. Reglas del proyecto: las decisiones transversales que no se
   deducen leyendo el código.
4. Convenciones: nombres en inglés, comentarios en español, reglas
   de dominio en módulos que se puedan probar sin base de datos.
5. Qué NO vamos a construir: lista explícita de lo que queda fuera.

Pregúntame antes de asumir cualquier cosa que no esté en esta lista.

Terminado cuando: el fichero existe, cabe en una pantalla y no
contiene ninguna decisión que yo no te haya dado.

Esa penúltima línea vale su peso en oro. Y la de cierre evita el AGENTS.md de cuarenta apartados que nadie vuelve a leer jamás.

La sección de “qué NO vamos a construir” es la que más te va a ahorrar. Los agentes tienen un sesgo brutal hacia añadir. Escríbelo tú y te ahorras la mitad del trabajo de revisión. Si quieres afinar ese fichero, tengo aparte cómo se escribe un AGENTS.md mínimo que de verdad funciona.

La línea que convierte un prompt en un encargo ¶

El mecanismo que sostiene todo esto cabe en dos palabras: Terminado cuando.

No es una instrucción más. Es un criterio de aceptación: una frase comprobable que decide, sin discusión posible, si el paso está hecho o no.

Mira la diferencia. “Haz el motor de huecos” te devuelve algo. Esto otro te devuelve algo que puedes rechazar:

Terminado cuando: la misma disponibilidad produce huecos locales
correctos a los dos lados del cambio de hora de octubre, los buffers
impiden de forma demostrable dos reuniones pegadas, y ningún hueco
generado viola el aviso mínimo en el momento de generarse.

🔑 Un prompt sin criterio de aceptación no tiene forma de fallar. Y lo que no puede fallar tampoco puede estar terminado: solo puede estar entregado.

Esto no es manía de proceso. En el Stack Overflow Developer Survey, con más de 49.000 respuestas, la frustración número uno con la IA (citada por el 66% de los encuestados) son las soluciones que están “casi bien pero no del todo”, y un 45% dice que depurar código generado por IA le consume un tiempo significativo. El “casi” es el enemigo, y solo lo detectas si has escrito antes qué significaba “bien”.

Los tres filtros de un buen “Terminado cuando” ¶

Escribir criterios flojos es fácil y da una falsa sensación de rigor. Pásale estos tres filtros a cada uno:

1. ¿Se comprueba mirando o se comprueba opinando? “La interfaz es usable” es una opinión. “Puedo completar el flujo entero sin tocar el ratón” se comprueba en treinta segundos.
2. ¿Tiene un caso concreto dentro? Un número, una fecha rara, un límite, un nombre propio. “Gestiona bien las zonas horarias” no dice nada; “una regla de 9:30 sigue existiendo el día del cambio de hora en Europe/Madrid” sí.
3. ¿Podría fallar? Si no se te ocurre ningún resultado que incumpla el criterio, el criterio no sirve. Escribe uno que puedas suspender.

Compara cómo cambia la misma petición al pasarla por el filtro:

Hay una trampa que conviene nombrar: no le pidas al agente que escriba su propio criterio de aceptación. Lo escribirá a la medida de lo que piensa hacer. Puedes pedirle que te proponga tres y elegir tú, pero la frase final la firmas tú o no vale nada.

¿Cómo compruebas que lo que te ha entregado está bien? ¶

El criterio dice qué hay que comprobar. Falta el cómo, que es donde se cae la mayoría.

La respuesta corta: una parte la delegas y otra no. Y la que no se delega es más pequeña de lo que temes, pero es innegociable.

Estas cuatro las haces tú, a mano, con la aplicación abierta. No tardan ni diez minutos:

• El camino feliz completo, de principio a fin. Sin atajos, sin datos ya cargados. Como lo haría alguien que llega de fuera.
• Un caso raro que tú conoces del producto original. Aquí es donde te paga el haber elegido un servicio que usas: sabes qué pasa al cambiar de zona horaria o al reenviar un enlace viejo.
• Los estados feos. Vacío, cargando, error, y qué ve el usuario que pierde la carrera. Si un estado no lo has visto con tus ojos, no existe.
• Borrar y empezar de cero. Base de datos limpia, migraciones, datos de ejemplo, arrancar. Es la comprobación que más agujeros destapa y la que todo el mundo se salta.

El resto sí se delega, pero con una condición: pídele evidencia, no veredicto. Un agente al que preguntas “¿está bien?” contesta que sí. Este prompt le obliga a enseñar los cables:

Verifica el paso anterior contra su criterio de aceptación.

Para cada punto del criterio, dame en una tabla:
- el punto tal como lo escribí
- cumple / no cumple / no comprobable
- la EVIDENCIA concreta: comando ejecutado y su salida, fichero y
  línea, o el caso de prueba que lo demuestra
- qué has hecho para intentar romperlo

Reglas:
- Si no puedes aportar evidencia, es "no comprobable". No lo cuentes
  como cumplido.
- Enumera aparte lo que has tocado y yo no te pedí.
- No arregles nada en este turno.

Terminado cuando: cada punto tiene su evidencia o está marcado como
no comprobable, y no hay ni un cambio en el árbol de trabajo.

Ese “no comprobable” es la casilla más útil del prompt. Sin ella, todo acaba en verde.

El checklist de validación que puedes reutilizar ¶

Este sirve para cualquier servicio que reconstruyas y vale la pena dejarlo pegado en el propio proyecto. Úsalo tú antes de dar por bueno un paso, o pásaselo al agente pidiéndole evidencia punto por punto:

1. ¿Puedo completar el recorrido principal desde cero, con la base de datos vacía?
2. ¿He probado el caso raro que sé que existe en el producto original?
3. ¿He visto con mis ojos los estados de carga, vacío y error?
4. ¿Qué pasa si dos personas hacen lo mismo a la vez?
5. ¿Qué pasa si el servicio externo no responde o tarda diez segundos?
6. ¿Los tests fallan cuando rompo el código a propósito?
7. ¿Hay algún dato privado que se filtre en una respuesta pública?
8. ¿Puede alguien adivinar, enumerar o reutilizar un enlace que no es suyo?
9. ¿Sé qué ficheros ha tocado y por qué está cada dependencia nueva?
10. ¿Sabría explicar este paso a otra persona sin volver a leerlo?

Si respondes “no lo he mirado” a más de tres, todavía no has terminado el paso: lo has entregado.

El punto 6 merece una nota. Rompe el código a propósito, cambia un signo, y comprueba que algún test se pone rojo. Un agente que escribe implementación y tests en el mismo turno tiende a escribir tests que pasan con la implementación que acaba de escribir, aunque las dos estén mal. Por eso los tests se piden antes, y por eso el “fallan primero” es un criterio de aceptación en sí mismo.

La secuencia, prompt a prompt ¶

Sirve para casi cualquier SaaS con usuarios, datos y una página pública. Cada paso lleva su “Terminado cuando” y su commit.

1. Modelo de datos. Antes que ninguna pantalla. Pídele que te explique en prosa sus decisiones sobre índices, unicidad, transiciones de estado y borrado en cascada, y que no escriba código hasta que respondas.
2. El núcleo, como función pura. La pieza difícil que localizaste antes, aislada, sin acceso a base de datos y con el instante actual como parámetro de entrada. Una función que consulta el reloj por dentro no se puede probar; una que lo recibe, sí.
3. Concurrencia y estado. Qué pasa cuando dos personas hacen lo mismo a la vez. Aquí pide opciones antes que soluciones: que te proponga dos formas distintas con sus contras, y eliges tú.
4. La página pública. Con una restricción rara que da muy buen resultado: sin librerías para lo que es didáctico. Y que declare sus cinco estados (carga, vacío, éxito, error recuperable y el raro de tu dominio) antes de implementar.
5. La integración externa. Calendario, email, pagos, lo que toque. Con timeout, errores normalizados, un doble local para desarrollo y una pregunta obligatoria: qué pasa cuando el token expira o el usuario revoca el acceso.
6. Los enlaces sin cuenta. Tokens largos guardados con hash, con caducidad y revocación, donde token inválido, caducado y revocado devuelven la misma página para que nadie aprenda qué existe.
7. El revisor. Sesión nueva, contexto limpio, rol distinto. Tiene sección propia justo debajo, porque es el que casi nadie escribe.
8. Despliegue y README. Escrito como si volvieras dentro de seis meses habiendo olvidado el proyecto entero.

Los puntos 2 y 3 son el partido. El 1, el 4 y el 8 son mecánicos. El 5 y el 6 son donde se cuela la mayoría de agujeros de seguridad de los proyectos de fin de semana. Si quieres ver esos ocho pasos aterrizados en un servicio concreto, con la trampa que esconde cada uno, ahí tienes el Calendly propio y sus seis piezas difíciles.

Al prompt cero le toca el número cero por algo: se escribe antes que ninguno de estos ocho y no genera código.

¿Por qué el revisor tiene que empezar de cero? ¶

Porque un agente que acaba de escribir el código lleva en su contexto todas las razones por las que le pareció buena idea. No es un revisor: es el autor defendiendo su obra.

Eres un ingeniero de seguridad revisando este repositorio por primera
vez. No lo has escrito tú y no confías en quien lo hizo.

Busca, en este orden:
1. Endpoints que confíen en datos del cliente sin revalidar en el
   servidor.
2. Fugas de datos: qué revela una respuesta pública sobre los datos
   privados del propietario.
3. Tokens adivinables, sin caducidad o sin revocación.
4. Falta de límite de ritmo en las acciones públicas.
5. Secretos en el repositorio o en el cliente.

Para cada hallazgo: fichero, línea, impacto real y arreglo mínimo.
No arregles nada todavía. Solo el informe.

Terminado cuando: tengo una lista con fichero y línea por hallazgo,
ordenada por impacto, y ni un solo cambio en el árbol de trabajo.

🛡️ Contexto limpio, rol distinto, y le pasas el artefacto, no la conversación. Ese es todo el truco, y es el mismo que usamos entre humanos desde que existen los pull requests.

Los prompts de rescate para cuando algo se rompa ¶

Se va a romper. Estos cuatro sacan del atasco casi siempre y funcionan sea cual sea el servicio que estés construyendo.

Cuando la IA gira en círculos:

Para. Llevamos tres intentos con el mismo error.

No propongas otro arreglo. Escribe un fichero DEBUG.md con:
qué creías que hacía el código, qué hace en realidad, qué evidencia
tienes de cada afirmación y qué NO has comprobado todavía.

Cuando algo funcionaba y ha dejado de funcionar, pídele que use git para localizar el último commit donde el comportamiento era correcto y te enseñe el diff filtrado solo a los ficheros implicados, sin cambiar nada.

Cuando el código funciona pero no te fías, pídele que te explique el módulo como si tú fueras quien lo va a mantener cuando él no esté, incluyendo los tres casos límite que más le preocupan.

Y el que más va a doler:

Lista los cambios de las últimas dos horas agrupados por intención,
no por fichero. Marca cuáles te pedí de forma explícita y cuáles
añadiste por tu cuenta.

Ese último te va a sorprender. Y probablemente te explique por qué tu aplicación tiene tres dependencias que nadie pidió.

El método SDD paso a paso

Cuando los prompts se te quedan cortos, la spec es lo que aguanta

Vas a ver las cinco fases con un ejemplo guiado real, para convertir esos ocho prompts en artefactos que sobreviven a la sesión del terminal.

Abrir el método →

Incluye autodiagnóstico para saber si tu proyecto lo necesita

¿Y el día dos? Cuando la secuencia deja de bastar ¶

Han pasado tres semanas. Tu aplicación funciona. Y quieres añadir una funcionalidad nueva.

Abres el terminal, la pides y el agente arranca de cero.

No sabe ninguna de las diecisiete decisiones que tomaste entre el prompt 1 y el prompt 8. No sabe que las marcas de tiempo van en UTC con el nombre de la zona guardado aparte. No sabe que un fallo del proveedor de email no puede tumbar una operación confirmada.

Porque esas decisiones estaban en el prompt, y el prompt se gastó al pegarlo.

Fíjate en lo que has escrito durante todo el proceso sin darte cuenta: comportamiento esperado, casos límite, reglas que el agente no puede deducir, lista de lo que queda fuera de alcance y criterios de aceptación. Eso es, apartado por apartado, una spec. La escribiste entera. Lo que hiciste con ella fue tirarla al historial del terminal.

💡 La diferencia entre esta secuencia y el Spec Driven Development no es el contenido. Es dónde vive. Un prompt se gasta al pegarlo; una spec se queda en el repositorio, se enmienda y crece.

El arreglo es más pequeño de lo que parece: guarda cada uno de esos prompts como fichero en specs/ dentro del proyecto. Mismo texto, distinto sitio. A partir de ahí, la funcionalidad número nueve no arranca de cero: arranca leyendo las ocho anteriores.

Cuándo vale la pena dar ese salto ya lo desglosé en el post de vibe coding, con sus tres niveles y su checklist de diez preguntas. El resumen para este caso concreto: si el proyecto muere el lunes, quédate en la secuencia; si vas a volver a él, mueve los prompts a specs/ antes de cerrar el portátil.

Los errores que vas a cometer igualmente ¶

Los enumero para que los reconozcas antes, no para que los evites del todo. Algunos hay que sufrirlos.

1. Empezar por la pantalla. Ya lo dije arriba y lo repito porque lo vas a hacer.
2. Probar solo en tu entorno. Cambia la zona horaria del sistema, el idioma, el ancho de pantalla. Rompe tú lo que romperá otro.
3. No desplegar hasta que esté perfecto. Despliega en cuanto tengas la página pública, aunque esté feo. Un proyecto sin URL pública es un proyecto que no existe.

La regla que resume todo esto cabe en tres golpes: quédate con lo difícil, construye lo pequeño, cancela con gusto.

Con un matiz que cuesta varios proyectos aprender. Construir lo pequeño es la parte fácil. Que siga vivo el mes que viene es la otra mitad del trabajo, y esa no cabe en ningún prompt.

¿Cuál es el primero que te vas a quitar del recibo?

TL;DR ¶

• 🧩 No hay metodología nueva: es vibe coding hecho un poco mejor, un paso lógico por encima de improvisar.
• ✅ Cada paso cierra con un “Terminado cuando” que se comprueba mirando, contiene un caso concreto y puede suspender.
• 🔍 Al agente le pides evidencia, no veredicto: comando, salida, fichero y línea. Y una casilla de “no comprobable” para que no todo acabe en verde.
• ✋ Cuatro comprobaciones no se delegan: camino feliz completo, un caso raro que conoces del producto original, los estados feos y arrancar desde cero.
• 🎯 Elige un SaaS que pagues, que uses y que quepa. Localiza su pieza difícil antes del primer prompt y constrúyela antes que la interfaz.

Preguntas frecuentes ¶

¿Cuánto tarda de verdad reconstruir un servicio que pagas?

Depende de dónde esté su pieza difícil. Una página de enlaces o un acortador arrancan en menos de dos horas; un sistema de reservas con zonas horarias y sincronización de calendario pide un fin de semana largo. Igualar el producto comercial completo son meses, y ese tramo es justo el que conviene no construir.

¿Es mejor un prompt gigante o una secuencia de prompts?

Depende del objetivo. Un prompt monolítico llega antes a un prototipo desechable. Una secuencia de prompts pequeños, con revisión humana y criterio de aceptación en cada paso, produce código que puedes mantener y te deja entendiendo el sistema. Si el proyecto es para aprender, gana la secuencia.

¿Qué es un criterio de aceptación en un prompt?

Es la frase que define cuándo un paso está terminado en términos comprobables, no opinables. “El fichero se importa a la hora correcta en los tres clientes” es un criterio; “el calendario funciona” no lo es. Sin ese cierre, el agente decide por su cuenta que ha acabado.

¿Cómo elijo qué servicio reconstruir primero?

Con tres filtros simultáneos: que lo pagues de tu bolsillo, que lo uses a diario y que su versión básica quepa en unas horas. Un acortador de enlaces o una página de enlaces se terminan; un gestor de proyectos completo se abandona.

¿En qué se diferencia un prompt de una spec?

En dónde vive y cuánto dura. Un prompt es una instrucción de un solo uso que desaparece cuando cierras la sesión; una spec es un fichero que se queda en el repositorio, se enmienda y sirve de contexto para el siguiente cambio. El contenido puede ser casi idéntico: cambia la permanencia.

¿Cómo sé que lo que ha entregado la IA está bien de verdad?

Combinando dos cosas. Tú compruebas a mano el camino completo desde cero, un caso raro que conozcas del producto original, los estados de carga, vacío y error, y que la aplicación arranque con la base de datos limpia. Al agente le pides verificación con evidencia (comando y salida, fichero y línea) en lugar de un “sí, funciona”.

¿Puede la IA validar su propio trabajo?

En parte, y solo si le exiges pruebas. Un agente al que preguntas si su código está bien responde que sí. Si le pides una tabla con la evidencia de cada punto del criterio y le obligas a marcar como “no comprobable” lo que no puede demostrar, el informe empieza a servir. Aun así, la comprobación manual del recorrido principal no se sustituye.

¿Cómo compruebo que los tests sirven para algo?

Rompe el código a propósito y mira si alguno se pone rojo. Si no falla nada, los tests están escritos a la medida de la implementación. Por eso conviene pedirlos antes que el código y verificar que fallan primero.

¿Por qué hay que pedir el revisor en una sesión nueva?

Porque el agente que acaba de escribir el código conserva en su contexto las razones por las que le pareció correcto y tiende a defenderlas. Con contexto limpio y un rol distinto revisa el artefacto en lugar de justificar su propio trabajo.

¿No es mejor instalar la alternativa open source y ya está?

Para uso real, casi siempre sí. Cal.com, Umami o Chatwoot cubren estos casos con años de trabajo detrás. Reconstruirlo tú tiene sentido como aprendizaje o cuando necesitas un flujo muy concreto embebido en tu propio producto.

¿Qué hago si la IA se atasca con el mismo error?

Detén el ciclo de intentos. Pídele un documento con lo que cree que hace el código, lo que hace de verdad, la evidencia de cada afirmación y lo que no ha comprobado. Separar diagnóstico de arreglo rompe casi todos los bucles improductivos.

¿Cuánto código generado por IA hay que revisar de verdad?

Todo el que vayas a mantener. El Stack Overflow Developer Survey sitúa en el 66% a quienes señalan las soluciones “casi correctas” como su mayor frustración, y en el 45% a quienes pierden un tiempo significativo depurando código generado. Revisar en tandas de menos de 80 líneas es lo que hace ese porcentaje manejable.

Fuentes ¶

• Stack Overflow, “Developer Survey: AI”. Datos de adopción, confianza y frustraciones con herramientas de IA.
• Cal.com, repositorio oficial en GitHub. Licencia AGPLv3, stack y guía de self-hosting.

🧨 Última oprtunidad para recibir la dinamita que mereces sobre programación con IA el próximo domingo: Suscríbete gratis a Web Reactiva en https://webreactiva.com/newsletter