Cybercoding Codex history

Imagina dos castillos.

El primero luce glorioso desde la distancia — torretas que reflejan la luz, banderas ondeando, un puente levadizo que baja a la orden. Sin embargo, al acercarte, notas que los cimientos son de arena. Los muros son de contrachapado pintado. Es el decorado de una película, construido rápido, construido para ser visto, nunca construido para ser habitado.

El segundo castillo es menos fotogénico. Muros de piedra gruesos, un foso, una torre del homenaje que ha sobrevivido asedios. Tardó más en construirse, y no intenta impresionarte desde la distancia: intenta seguir en pie dentro de cien años.

Esa imagen — un castillo dividido por la mitad, frágil de un lado, fortificado del otro — es cómo presentamos la diferencia entre vibecoding y cybercoding en el escenario de AI Summit Barcelona. Es una imagen justa, y no cruel. El vibecoding no es un error; es un decorado de película, y los decorados de película tienen su lugar. El error es mudar a tu familia a uno.

Este libro cuenta la historia de cómo lo descubrimos por las malas, qué construimos en su lugar, y cómo puedes usar el mismo enfoque — ya seas un desarrollador independiente lanzando tu primer SaaS, un CTO intentando poner bajo control el código de una scale-up, o un CISO enfrentando un plazo de cumplimiento de NIS2 con una cartera de aplicaciones heredadas que nadie quiere tocar.

Todo empieza, como suele ocurrir con estas cosas, con alguien despierto hasta tarde un fin de semana.

Thomas, uno de nuestros desarrolladores, pasa un fin de semana probando una nueva herramienta llamada bolt.new — una de las primeras plataformas basadas en el navegador donde puedes describir una aplicación en lenguaje sencillo y ver a la IA generar código funcional delante de ti, en vivo, en el navegador.

No es la primera herramienta de codificación con IA que alguien haya visto. Pero es la primera que se siente como una demo hecha realidad — sin configuración local, sin código repetitivo, solo un prompt y una aplicación funcionando unos segundos después. El lunes, Thomas ya se lo ha enseñado a la mitad del equipo.

Ese fin de semana es, en la medida en que algo puede serlo, el nacimiento de lo que el sector llamaría más tarde vibecoding: describir lo que quieres en lenguaje natural y dejar que un modelo de IA escriba — y a menudo despliegue — el código, con el humano guiando más por instinto que por especificación.

Es embriagador. También es, como aprenderíamos durante el año siguiente, incompleto.

No implementamos la codificación con IA de forma gradual. La implementamos en todas partes, a propósito, lo más rápido posible. Cada herramienta interna, cada prototipo, cada elemento pendiente del tipo «teníamos pensado arreglar esto» se convierte en un caso de prueba. La instrucción para el equipo es sencilla: cualquier cosa que estés a punto de construir a mano, intenta construirla primero con IA.

Los resultados son desiguales, y esa desigualdad resulta ser el dato más valioso que pudimos haber recopilado. Las interfaces se ensamblan en horas. Cualquier cosa que implique lógica de negocio, modelado de datos o — de forma muy notable — seguridad, se ensambla de manera mucho más inestable, cuando llega a ensamblarse.

Para la primavera, un patrón resulta evidente: la codificación asistida por IA es extraordinaria en las partes del software que un usuario puede ver, y poco fiable en las partes que un usuario no puede ver. Esa brecha — brillantez en el front-end, fragilidad en el back-end — definiría el año siguiente de nuestro trabajo.

Obtenemos nuestra primera prueba real fuera del laboratorio: TopFlix Academy, una plataforma de aprendizaje en línea. La construcción existente había costado bastante más de 1 millón de euros mediante desarrollo tradicional. Nuestro encargo era reescribirla.

Dos personas. Un verano. Asistido por IA de principio a fin.

Entregan una plataforma funcional y desplegada — no una demo, un producto real que gestiona usuarios reales — por una fracción del coste y en una fracción del tiempo que habría necesitado una agencia tradicional. Es el primer proyecto en el que la «reescritura asistida por IA» deja de ser un experimento interno y empieza a parecer una alternativa genuina a la forma en que se construye el software.

Es también el proyecto que nos convence de que este enfoque tiene recorrido comercial — y la semilla directa de lo que más tarde se convertiría en la forja de WakaStart.

Pero TopFlix Academy es una construcción desde cero con un alcance pequeño y contenido. La verdadera prueba — la que expondría las grietas del castillo — todavía estaba por llegar.

Llegan Claude Code y Opus 4.5, y con ellos un verdadero salto cualitativo en lo que la codificación asistida por IA puede producir. Pero cuanto más ambiciosos se vuelven nuestros proyectos, más claramente se muestran los límites del vibecoding puro.

Se repiten algunos patrones, proyecto tras proyecto:

• Los front-ends brillan; los back-ends no. Los modelos de IA son extremadamente buenos produciendo interfaces que se ven bien. Son mucho menos fiables produciendo lógica de back-end, modelos de datos e integraciones que resisten el uso real.
• El diseño de la base de datos evoluciona de forma improvisada. Sin un esquema deliberado diseñado de antemano, las tablas se añaden y parchean de forma incremental, prompt a prompt — una receta para el tipo de deuda estructural que es invisible hasta que deja de serlo.
• Los back-ends preempaquetados se convierten en una muleta. Herramientas como Supabase hacen trivialmente fácil añadir autenticación y una base de datos. También traen límites reales de escalabilidad, coste y — de forma crítica — seguridad, una vez que superas la escala de prototipo.
• La IA toma decisiones de seguridad que nadie aprobó. Sin supervisión, un asistente de codificación elegirá un enfoque de autenticación, un modelo de permisos, una forma de manejar secretos — y puede que sea razonable para una demo. Rara vez es una que sobreviviría a una revisión de seguridad, y casi nunca es una que un humano haya elegido deliberadamente. Eso es precisamente lo que la hace explotable — incluso, cada vez más, por otros sistemas de IA diseñados para sondear exactamente este tipo de decisiones no revisadas.

Nada de esto hace que el vibecoding sea inútil. Para maquetas, demos y trabajo iterativo de front-end, sigue siendo genuinamente excelente — probablemente insuperable. Pero cuando se trata de construir algo destinado a gestionar un negocio, almacenar datos de clientes o sobrevivir a una auditoría de seguridad, el castillo frágil deja de ser encantador y empieza a ser un pasivo.

Necesitábamos un enfoque distinto. No «la IA escribe menos código», sino «la IA escribe código dentro de una estructura que un humano diseñó primero».

De esa constatación nace WakaStart: no un rechazo de la codificación asistida por IA, sino una inversión deliberada de la misma. Mientras que el vibecoding empieza por la interfaz y trabaja hacia dentro, WakaStart empieza por los cimientos y trabaja hacia fuera — las decisiones de infraestructura y seguridad se toman primero, deliberadamente, por humanos, y se documentan exhaustivamente, antes de escribir una sola línea de código de la aplicación.

Dos disciplinas se sitúan en el centro del enfoque:

La ingeniería inversa como primer paso. Para cualquier sistema existente — heredado o no — la forja empieza extrayendo todo: comportamiento funcional, estructuras de datos, casos límite, peculiaridades no documentadas. Nada se asume; todo se verifica contra el sistema real.

La especificación exhaustiva antes de la generación. En lugar de guiar a una IA de forma incremental y esperar que la arquitectura se mantenga coherente, WakaStart produce un Documento de Requisitos de Producto completo — a veces de cientos de páginas — que recoge cada pantalla, cada regla, cada requisito de seguridad, antes de que comience la fase de codificación. La IA no improvisa la arquitectura. Construye siguiendo un plano que un humano ya ha validado.

Esta es la semilla de lo que llegaríamos a llamar cybercoding: desarrollo nativo de IA, pero con la disciplina de la ingeniería de software tradicional — seguridad, arquitectura e infraestructura — aplicada antes de que la IA empiece a teclear, no parcheada después.

La primera prueba real del nuevo enfoque es WakaSign, una plataforma de firma electrónica conforme a eIDAS — el tipo de producto donde «confía en nosotros, es seguro» no basta; el cumplimiento tiene que ser real, auditable y estar incorporado desde el primer día.

Construida en un solo mes, WakaSign está diseñada para competir directamente con actores consolidados como Yousign y DocuSign, pero con seguridad desde el diseño impulsada por los requisitos de NIS2 desde el inicio, en lugar de adaptarse más tarde para una auditoría de cumplimiento.

Es un producto pequeño con una implicación enorme: si una empresa puede pasar de cero a una plataforma de firma electrónica conforme y de nivel de producción en treinta días — en un espacio donde la confianza es el producto — el enfoque claramente se generaliza más allá de una sola construcción desde cero. La pregunta dejó de ser «¿puede funcionar una vez?» y pasó a ser «¿hasta dónde puede llegar esto?».

No es un cumplido que nos hayamos dado a nosotros mismos — es una paráfrasis de lo que nos llamaban los primeros clientes, a principios de 2025, cuando les decíamos que una reescritura completa de aplicación llevaría un mes, y una certificación ISO 27001, cuatro semanas.

El escepticismo era la respuesta racional. Nadie cumple esos plazos — ni con desarrollo tradicional ni, francamente, con vibecoding tampoco, en cuanto entran en juego la seguridad y el cumplimiento. Así que dejamos que los resultados hablaran por nosotros.

Siguió una serie de proyectos que demostraron que los plazos no eran una casualidad: Biped, Vicamed, OTeam, y otros, cada uno reescrito o construido sobre la forja de WakaStart, cada uno entregado en semanas en lugar de trimestres, cada uno con seguridad desde el diseño incorporada desde el primer día, en lugar de como una idea tardía.

Para cuando el escepticismo se disipó, teníamos un historial — y un desafío mucho mayor esperando.

Todo enfoque acaba encontrando el proyecto que lo pone realmente a prueba. El nuestro fue Vinci Group.

Vinci operaba un conjunto de sistemas ERP heredados construidos sobre Windev — software propietario usado para gestionar filiales y sedes remotas en todo el grupo. La situación que los forzó a actuar fue contundente: el proveedor de Windev había sido adquirido por un grupo canadiense, que a continuación multiplicó sus precios aproximadamente 200 veces. Quedarse en la plataforma heredada dejó de ser una opción viable.

El problema: no había código fuente disponible. Solo quedaba documentación. Una reescritura en el sentido tradicional — leer el código, entenderlo, reimplementarlo — no era una opción. El único camino posible era reconstruir el comportamiento del sistema a partir únicamente de la documentación y del conocimiento del dominio.

El alcance: más de 600 pantallas y 200 formatos de informes imprimibles, reescritos desde cero en una única plataforma SaaS cibersegura y conforme a NIS2, desplegable al instante en todas las sedes de Vinci a nivel mundial.

Al cabo de un mes, el proyecto pasó a fase de pruebas y pre-despliegue, con la puesta en producción prevista antes de fin de año. Este es el proyecto con el que abrimos nuestra charla en AI Summit Barcelona — la evidencia más clara de que la forja, nacida de un experimento de fin de semana con bolt.new un año antes, podía ahora abordar de forma creíble la modernización de sistemas heredados a escala corporativa, sin código fuente del que partir.

Pero Vinci es un compromiso privado que se extiende durante meses. Para el público de Barcelona, queríamos algo que pudieran ver ocurrir en tiempo real, contra reloj, sin dónde esconderse. Ahí entra el Wakathon.

Para poner a prueba la forja bajo presión real de tiempo, y en público, organizamos un Wakathon — un concurso de desarrolladores donde nuestros Waka Masters usan la forja de WakaStart para reescribir por completo un software existente, esta vez contra reloj y en competencia directa entre ellos.

El objetivo: Kanboard, una plataforma de gestión de proyectos de código abierto muy conocida, basada en PHP, con licencia MIT y por tanto libre de forkear, estudiar y reescribir sin restricciones — una aplicación grande, con unas 150 pantallas en total.

Las reglas: tres Waka Masters recibieron el encargo a las 10 de la mañana del primer día — la aplicación heredada, su repositorio de GitHub y su documentación — y se les pidió entregar una versión totalmente reescrita y cibersegura de la aplicación al día siguiente.

• 10:00–12:00 — ingeniería inversa con la IA: en gran medida un proceso de preguntas y respuestas para fijar la arquitectura de seguridad final de la reescritura.
• 12:00–14:00 (pausa para comer) — generación de maquetas para las 150 pantallas de la aplicación existente, de modo que cada pantalla del sistema heredado tuviera un diseño objetivo correspondiente antes de escribir código alguno.
• 14:00–17:00 (aproximadamente, según cada Waka Master) — completar el estudio de ingeniería inversa, tomar las decisiones arquitectónicas para la reescritura, y ensamblar el PRD que se entregaría a la forja durante la noche.
• Después de las 17:00 — los tres PRD en competencia entran en la forja. Claude dispone de una ventana nocturna de cinco horas para codificar cada aplicación completa, sin supervisión, a partir únicamente de las especificaciones.

Segundo día, 9:00 de la mañana — los Waka Masters vuelven para ver qué construyó Claude durante la noche. Dos de los tres encuentran una aplicación prácticamente lista para producción de fábrica. El tercero tiene que ejecutar una segunda pasada: su especificación funcional no era lo bastante precisa, y como resultado faltaban algunas pantallas — un recordatorio útil de que la calidad de la especificación es lo que determina la calidad del resultado.

Menos de dos horas después, los tres Waka Masters tienen una reescritura de Kanboard totalmente funcional y cibersegura — un poco antes del mediodía del segundo día, aproximadamente 48 horas después de que se entregara el encargo.

Esa es la aplicación que abrimos en vivo sobre el escenario en Barcelona: la interfaz original en PHP, inconfundiblemente anticuada, junto a su contraparte reescrita — la misma funcionalidad, segura por diseño, construida casi por completo por la IA, a partir de una especificación que tres humanos tardaron una jornada laboral en producir.

La herramienta detrás de todo esto es WakaNalytics — el motor de análisis y especificación de WakaForge. Así es como un proyecto avanza realmente a través de ella, paso a paso.

1. Elegir el resultado. ¿Qué debe entregar la forja al final: una aplicación SaaS, una app para iOS, una app para Android, un ejecutable de escritorio para Windows, macOS o Linux — o alguna combinación de todos estos?
2. Elegir el tipo de proyecto. Una aplicación totalmente nueva construida a partir de una especificación; hacerse cargo de un código base heredado existente (nuestro ejemplo de Kanboard); reescribir una aplicación solo a partir de documentación funcional, algo habitual en sistemas heredados de tipo Windev (nuestro ejemplo de Vinci); o ampliar un proyecto WakaStart existente con nueva funcionalidad. Esta elección importa más de lo que parece — determina directamente qué prompts de ingeniería inversa, análisis y especificación se seleccionan a continuación, ya que dependen tanto del resultado objetivo como de la naturaleza del proyecto.
3. Cargar las fuentes. Los archivos fuente y la documentación disponible se cargan en WakaNalytics.
4. Establecer el contexto. Un primer prompt define el contexto global del proyecto — qué es, qué hace, para quién es.
5. Analizar. Prompts específicos calculan la complejidad del proyecto y, a partir de ahí, un presupuesto y un calendario aproximados — e, igual de importante, identifican los elementos de seguridad ausentes en la construcción original, de modo que las brechas se aborden por diseño en lugar de descubrirse más tarde.
6. Especificar y maquetar. WakaNalytics genera entre seis y dieciocho especificaciones técnicas, además de maquetas de pantalla para cada una de las pantallas de la aplicación. Cada pantalla — el 100% — es revisada y validada por el propietario del proyecto antes de avanzar.
7. Ensamblar el PRD final. Solo una vez completados todos los pasos anteriores, la forja ensambla el documento a partir del cual Claude construirá realmente — fundamentado en todo lo generado y discutido durante la fase de análisis, no improvisado sobre la marcha.

Y Claude no lo construye solo. En promedio, se despliegan 29 agentes especializados a lo largo de la construcción — que cubren back-end, front-end, diseño, UX, seguridad, y gestión de identidad y acceso — cada uno trabajando para garantizar que el resultado final se mantenga alineado con los requisitos capturados en el PRD y con la infraestructura segura en la que se desplegará.

El despliegue, por fin, es un solo clic. La automatización de CI/CD, el aprovisionamiento de entornos de desarrollo, staging y producción — todo ello ya está codificado en la capa de hosting de WakaStart. No queda nada por construir ahí. Es una pila completa y preintegrada — no un back-end estilo Supabase añadido a posteriori, que es el patrón que se suele ver en el vibecoding puro.

A estas alturas, el panorama debería ser lo bastante claro como para expresarlo directamente.

En la práctica, eso significa:

• Infraestructura decidida antes del código. Hosting, gestión de secretos, identidad y acceso — elegidos deliberadamente, no impuestos por lo que el front-end necesite en cada momento. WakaStart, por ejemplo, se ejecuta sobre infraestructura soberana de la UE, en Kubernetes, con Keycloak para la identidad.
• Alineación entre código e infraestructura. Las especificaciones se escriben teniendo ya en cuenta la infraestructura elegida, de modo que ambas nunca se distancian.
• Secure-by-Design y Zero Trust, aplicados en cada etapa — no como una auditoría única al final, sino entretejidos en cada fase:
  1. Análisis — se mapean los permisos, perfiles de usuario, sensibilidad de los datos e implicaciones del RGPD antes que ninguna otra cosa.
  2. Especificación funcional exhaustiva, con maquetas HTML previamente validadas contra un sistema de diseño — Claude Code sustituyendo eficazmente a herramientas de diseño tradicionales como Figma para este paso.
  3. Diseño de base de datos, hecho una sola vez, de forma holística — no parcheado incrementalmente prompt a prompt.
  4. Un único archivo de especificación exhaustivo, a menudo de cientos de páginas, entregado a la IA de codificación — de modo que el modelo construya siguiendo un plan, en lugar de inventar sus propias reglas a mitad de la construcción.
  5. CI/CD asegurado, con análisis de dependencias y CVE que bloquea cualquier build que contenga una vulnerabilidad conocida.
  6. Pruebas sistemáticas SAST/DAST y pruebas de penetración impulsadas por IA, en cada lanzamiento, no solo en el lanzamiento inicial.
  7. Alojamiento en infraestructura construida para esto desde el inicio — Kubernetes, Keycloak, una bóveda de secretos de código abierto — una pila de código abierto de nivel bancario y militar, no una capa de conveniencia.

El beneficio de alinear cada una de esas etapas de principio a fin — diseño, desarrollo, despliegue y hosting — es que el Sistema de Gestión de Seguridad de la Información resultante puede estar certificado ISO 27001 en todo el ciclo de vida, una sola vez, en lugar de recertificarse proyecto a proyecto. Cada aplicación construida de esta manera hereda de forma nativa la alineación con ISO 27001 y NIS2, en lugar de tener que demostrarlo desde cero cada vez.

Esa es toda la idea. No «IA, pero con cuidado». Un punto de partida completamente distinto.

Todo lo anterior suena abstracto hasta que lo sitúas frente a tu punto de partida real. En la práctica, vemos tres.

Puntos de partida distintos, puntos de dolor distintos. La misma forja, la misma velocidad, la misma seguridad desde el diseño, siempre.

Abrimos este libro con dos castillos — uno construido para verse bien desde la distancia, otro construido para durar. La historia intermedia es, en realidad, solo un relato de cómo aprendimos, proyecto a proyecto, cuál de los dos necesitaban realmente nuestros clientes, y construimos las herramientas para entregarlo a la velocidad que la IA hizo posible desde el principio.

Si algo de esto te ha resonado — ya sea que estés lanzando algo nuevo, intentando poner bajo control los fundamentos de una plataforma en crecimiento, o teniendo sistemas heredados que te gustaría modernizar sin apartar a tu equipo de todo lo demás — nos encantaría saber de ti.

Como agradecimiento a todos los que asistieron a AI Summit Barcelona 2026, y que leen este libro como resultado, extendemos cuatro ofertas, exclusivas para los asistentes de AI Summit Barcelona y válidas hasta el 30 de septiembre de 2026:

Escanea el código de abajo, o visita directamente wakastart.com y cybercoding.ai.

Gracias por leer. Ahora ve a construir algo que siga en pie dentro de cien años.

— Denis Schirra
CEO, WakaStart / Wakastellar

Vibecoding

Describir una aplicación en lenguaje natural y dejar que un modelo de IA genere (y a menudo despliegue) el código, guiado por instinto en lugar de por una especificación formal. Rápido y excelente para prototipos e interfaces; poco fiable para la lógica de back-end, la arquitectura de datos y la seguridad una vez que un proyecto supera la escala de prototipo.

CyberCoding

Desarrollo nativo de IA en el que las decisiones de infraestructura y seguridad las toman deliberadamente los humanos primero, con la IA generando código dentro de esa estructura en lugar de inventarla sobre la marcha. Ver el Capítulo 12 para la metodología completa.

WakaForge / WakaNalytics

La plataforma de WakaStart para hacer ingeniería inversa, especificar y generar aplicaciones ciberseguras. Ver el Capítulo 11 para un recorrido paso a paso.

Wakathon

Un concurso interno de desarrolladores usado para poner a prueba la forja: reescribir una aplicación existente desde cero, bajo presión de tiempo, en público. Ver el Capítulo 10.

NIS2

La directiva revisada de la UE sobre Seguridad de las Redes y de la Información, que eleva los requisitos mínimos de ciberseguridad para una amplia gama de empresas que operan en el mercado de la UE o que le prestan servicios. Cada vez más un requisito previo para los contratos de software B2B a partir de 2026.

ISO 27001

El estándar internacional para los sistemas de gestión de seguridad de la información. El SGSI de WakaStart está certificado a lo largo de todo el ciclo de vida de diseño-desarrollo-despliegue-hosting, extendiendo el cumplimiento nativo a cada aplicación construida sobre la forja.

• TopFlix Academy — la primera prueba de reescritura asistida por IA, verano de 2025 (Capítulo 4).
• WakaSign — plataforma de firma electrónica conforme a eIDAS, construida en un mes (Capítulo 7).
• Kanboard — la plataforma de gestión de proyectos de código abierto reescrita durante el Wakathon (Capítulo 10).

Descubre más, consigue las herramientas o reclama tu oferta de AI Summit Barcelona (válida hasta el 30 de septiembre de 2026): wakastart.com · cybercoding.ai