Cuatro días de vibe coding en la piel de un PM oxidado

Vengo del código.

Fui DevOps, aunque en aquella época no siempre lo llamábamos así. Fui desarrollador. Fui arquitecto de software. Luego, progresivamente, me alejé de esos oficios para pasarme a la gestión de equipos de desarrollo, a los proyectos, a la agilidad, al product management.

No dejé de programar de un día para otro. Al principio, todavía escribía yo mismo algunos scripts Python para automatizar una tarea, ordenar archivos, transformar un formato, hacer una pequeña herramienta. Luego empecé a delegar parte de ese desarrollo a ChatGPT, en modo chat. Después pasé progresivamente a Claude Code. Pero en todos los casos, seguía siendo pequeños trozos de código para hacer herramientas, no desarrollo de producto en el sentido pleno.

Hasta ahora, todo estaba muy acotado. Un script Python, una función. Una tarea precisa. Una especie de delegación limpia: en lugar de pedirle al LLM que ordenara él mismo los archivos en su contexto, se le hacía escribir un script. Ejecutaba una operación, verificabas, avanzabas.

Pero desde hace unos días, eso ya no es así.

Desde hace cuatro días, he vuelto a desarrollar. O más bien: hago que Claude Code desarrolle. Y esta vez, no hablo de un script utilitario. Hablo de un producto real, partido de cero, con pantallas, API internas, comportamientos avanzados, modificaciones de datos, decisiones de arquitectura, tests, documentación generada desde el código.

Este texto no es una conclusión sobre el vibe coding. No tengo suficiente perspectiva para eso. Cuatro días es demasiado poco para fabricar una doctrina. Eso es incluso quizás el punto más importante: todavía estoy dentro. Estoy documentando una travesía.

La luna de miel

Lo primero que impacta es la velocidad.

En cuatro días, he producido algo que, en la época en que yo desarrollaba, me habría llevado probablemente un mes. Quizás dos. Y no lo digo para quedar bien. Partí de cero. Hice más de 180 commits. Construí, rompí, corregí, reorganicé, probé, añadí comportamientos, presenté el producto, recibí peticiones de evolución, continué.

Es embriagador.

Hay un momento en que uno piensa: es increíble. Puedo tener una idea, formularla, pedirle a Claude que la implemente, probar, ajustar, volver a empezar. Ya no estoy escribiendo una spec imaginando cómo quedará el producto más tarde. Ya estoy dentro.

Y eso cambia muchas cosas.

Con un prototipo, ya se puede iterar. Ves una pantalla, un recorrido, una intención. Te dices: al final, el botón no está en el lugar correcto, este caso de uso no está claro, falta una información. Pero con un producto que funciona, aunque sea imperfecto, la iteración se vuelve todavía más directa. Se usa de verdad. Se ve de verdad. Se sienten los roces.

En mi caso, el cambio llegó bastante naturalmente. Al principio, parecía un prototipo. Luego el prototipo empezó a funcionar. Luego lo presenté. Luego me pidieron evoluciones. Luego me preguntaron cuándo podrían usarlo.

Ahí es a menudo donde empieza el peligro: cuando lo desechable se vuelve útil.

La ducha fría

Lo segundo que impacta es que Claude Code, si se le deja solo, puede hacer absolutamente cualquier cosa.

Cualquier cosa no en el sentido de que nada funcione. Es casi lo contrario. A menudo, funciona. La pantalla se muestra. Los datos aparecen. El botón hace algo. La demo pasa. Y es precisamente por eso que es peligroso.

Claude tiene una tendencia natural a lanzarse. Programa. Añade. Crece. Empieza con un archivo razonable, y ese archivo se infla, se infla, se infla, hasta convertirse en un bloque que hace un poco de todo. Cuando hay que modificarlo, pierde tiempo. Cuando hay que entender la intención, es más difícil. Cuando aparece un bug, ya no se sabe muy bien dónde mirar.

Un desarrollador experimentado piensa bastante rápido en la separación de responsabilidades. Se pregunta dónde poner la lógica de negocio, dónde aislar el transporte, dónde poner el renderizado, cómo nombrar los conceptos, cómo evitar que todo esté acoplado con todo. Claude puede hacerlo, pero no lo hace espontáneamente con constancia. Hay que guiarlo.

Lo mismo con la volumetría.

En mi proyecto, ciertas API pueden devolver unos pocos cientos de elementos. Otras pueden devolver decenas de miles. No es el mismo mundo en absoluto. Cargar 200 elementos para mostrarlos en una página no es cargar 20.000 o 30.000 elementos y esperar que el navegador, el usuario y el backend sigan de buen humor.

Pero si no se le dice nada, Claude puede perfectamente cargar todo, pasarlo todo a la página web, filtrar todo en el front, y considerar que el problema está resuelto. En pruebas, con pocos datos, puede dar la impresión de que funciona. En uso real, explota. O peor: no falla de forma clara, se vuelve lento, bloqueado, incomprensible.

Un bug no siempre es un error rojo en la consola. A veces es simplemente un producto que ya no responde porque se han cargado 5.000 elementos de forma silenciosa, sin log, sin paginación, sin estrategia clara. Y ahí, un PM sin perfil técnico puede no entender qué está pasando.

Pilotar a un desarrollador junior muy rápido

La relación con Claude Code me ha hecho pensar mucho en el management de un desarrollador junior extremadamente rápido.

Puede producir muchísimo. También puede tomarse libertades absurdas. Le das una captura de pantalla de un componente, y no hace exactamente lo que se pide. Interpreta. Simplifica. Se va en una dirección. A veces hay que explicarle cosas básicas de nuevo: por qué este archivo no debe contenerlo todo, por qué esta capa no debe conocer a esta otra capa, por qué no se carga toda la información, por qué hay que escribir los tests, por qué hay que volver a lanzar los tests.

Y a veces no lo entiende de inmediato.

No es grave en sí mismo. Los desarrolladores humanos también cometen errores. Cosas desarrolladas por desarrolladores pasan a veces a producción y no aguantan la carga. La deuda técnica no nació con los PM que hacen vibe coding.

Pero la IA añade una velocidad que cambia el problema. Permite producir muy rápido mucho código mediocre. Si el marco no es bueno, la deuda llega rápido. Muy rápido.

Por mi parte, mi pasado técnico me ayuda. Entiendo las grandes líneas de la arquitectura. Veo cuándo un archivo empieza a volverse demasiado grande. Veo cuándo las capas se mezclan. Noto cuándo algo va a plantear un problema de volumetría o de mantenibilidad.

Pero no controlo todo. Hay partes del código que no sabría explicar de inmediato. Si me tomo el tiempo, puedo entenderlas. Pero no puedo pretender tener el mismo dominio que si hubiera escrito cada línea yo mismo.

En este producto concreto, lo acepto. En otros productos, no lo aceptaría.

Y ese matiz es esencial.

El verdadero tema: competencia multiplicada por riesgo

Podría plantearse la pregunta así: ¿pueden ahora todos los PM desarrollar software con IA?

Mi respuesta espontánea sería: no.

O más bien: depende.

Pero el "depende" no es una pirueta. No es solo una cuestión de competencia individual. Es una relación entre el nivel de competencia y el nivel de riesgo del producto.

Es exactamente como con un desarrollador junior. ¿Se le abre de inmediato al junior el repositorio más complejo, más crítico, más impactante para el negocio? No necesariamente. ¿Se le da acceso a todos los repositorios, a todos los datos, a todos los permisos? Tampoco.

Para un PM que hace vibe coding, es igual.

No se trata de decir: los PM tienen derecho o no tienen derecho. Se trata de definir qué pueden hacer, en qué perímetro, con qué límites, según su nivel y según el riesgo.

Me gusta la analogía del carnet de conducir. No se conduce cualquier vehículo sin carnet, porque uno puede volverse peligroso. Y aunque tengas carnet, no conduces todo. Quizás un PM oxidado puede conducir una 125 cc. Eso no significa que deba subirse a una moto grande y salir a autopista bajo la lluvia.

El "código de PM", en mi boca, no es un insulto. No es decir que el código de un PM sea necesariamente malo. Es decir que es código producido por alguien que no domina muy bien, o ya no domina bien, el código. Hay que aceptar por tanto limitaciones. Y sobre todo, hay que aceptar definirlas.

Verde, naranja, rojo

No creo en una grilla universal.

Cada empresa tendrá que definir su política. Pero el principio me parece bastante claro: cuanto más toca el producto a datos sensibles, a escrituras, a workflows críticos, a seguridad, a facturación, a permisos, más deben subir las exigencias.

Una pequeña herramienta interna, personal, de vida corta, con impacto limitado, puede probablemente vivir con poco formalismo. Si falla, no pasa nada grave. Se tira, se corrige, se sigue adelante.

Una herramienta interna compartida, con comportamientos avanzados, escrituras limitadas, dependencias de negocio, ya es otra cosa. Ahí hay que hacerse más preguntas.

Y en cuanto se toca producción crítica, datos de clientes sensibles, permisos, escrituras irreversibles, workflows con impacto fuerte para el cliente o el negocio, se cambia de categoría de nuevo.

La seguridad, por ejemplo, me parece no negociable. Se puede discutir el nivel de tests necesario para una pequeña herramienta desechable. Se puede discutir la revisión. Se puede discutir el nivel de documentación. Pero la seguridad no debería depender del humor del momento.

Afortunadamente, los desarrolladores ya tienen mucho instrumental para eso: integración continua, escáneres, reglas, prácticas, competencias, a veces incluso prompts o skills internos. El tema no es, pues, reinventar todo para los PM. Es conectar a los PM aumentados al instrumental ya existente.

No, no creo en la revisión sistemática

Podría responderse: basta con que todo sea releído por desarrolladores.

Soy bastante escéptico con esa respuesta.

La revisión sistemática se ha convertido en un reflejo, pero merece ser discutida. Viene en particular del mundo open source, por razones múltiples: calidad, seguridad, transmisión, gobernanza, confianza entre contribuidores. Pero en una empresa, para todos los tipos de código, en todos los contextos, no estoy convencido de que haya que revisarlo todo sistemáticamente.

Si un PM se fabrica una herramienta personal, desechable, de bajo riesgo, ¿hace falta realmente movilizar a un desarrollador para que lo revise? Quizás no. De lo contrario se recrea exactamente la dependencia que se intentaba reducir.

En cambio, la revisión puede tener un papel al principio, para ayudar a los PM a adquirir buenas prácticas. También puede ser necesaria según el alcance. Una vez más, no es sí o no. Es una cuestión de riesgo.

En un momento dado, también hay que aceptar la responsabilidad. Si decido fabricarme una herramienta, hay que aceptar comer mi propia comida. Si falla, también depende de mí apañármelas. Y ahí es donde puede doler, porque muchos PM no saben necesariamente resolver los bugs que acaban de crear con la IA.

Los tests como palanca de control

En esta experiencia, los tests se han vuelto centrales.

No solo porque "los tests son buenos". Sino porque son uno de los pocos medios de mantener el control sobre un código que uno no ha escrito enteramente.

Claude no escribe espontáneamente los tests correctos si no se le pide. Puede olvidarlos. Puede escribir los tests a posteriori. Puede escribir tests que validen su implementación en lugar de la intención de negocio. Puede dar la impresión de que el producto está asegurado porque hay tests, cuando falta una verdadera estrategia de tests.

Un PM no conoce necesariamente el TDD. No conoce necesariamente la diferencia entre un test unitario, un test de integración, un test end-to-end. No conoce necesariamente la pirámide de tests. No siempre sabe cuándo hay que probar un comportamiento antes de programarlo, ni cómo expresar una regla de negocio en forma de test.

Y sin embargo, en un proyecto de vibe coding, es quizás uno de los puntos más importantes.

En mi proyecto, hay más de 500 tests. Es mucho para un proyecto de este tamaño. La mayor parte del tiempo, no se rompe nada, precisamente porque Claude vuelve a lanzar los tests muy a menudo. Cuando se rompe algo, los tests dan un punto de apoyo. Permiten entender dónde el comportamiento esperado ya no se respeta.

No digo que todo deba ser probado con el mismo nivel de exigencia. Una pequeña herramienta interna muy simple, de bajo riesgo, no necesita necesariamente una estrategia de tests completa. Aquí también, es una cuestión de alcance.

Pero en cuanto el producto se vuelve más serio, los tests no son un extra. Se convierten en parte del volante.

Las barandillas aceleran tanto como protegen

Cuando hablo de barandillas, no hablo solo de barreras que impiden a los PM cometer errores.

Las barandillas también sirven para ir más rápido.

Si se deja a un PM y a Claude Code solos frente al código fuente, la IA puede perfectamente no utilizar las API internas correctas. Puede usar el punto de entrada equivocado. Puede reconstruir algo que ya existe. Puede producir una herramienta que funciona mal, o que no funciona en absoluto, o que pierde un tiempo enorme contorneando la arquitectura existente.

En cambio, si los desarrolladores proporcionan barandillas, el PM y la IA saben adónde ir.

Esas barandillas pueden tomar varias formas: un catálogo de las API internas utilizables, una documentación funcional generada desde el código, un mapeo entre los conceptos de negocio y los puntos de entrada técnicos, ejemplos de peticiones, componentes de interfaz reutilizables, convenciones, accesos acotados, CI de seguridad, archivos Claude, prompts, skills.

Se puede imaginar, por ejemplo, un entorno donde un PM pueda crear pantallas internas, visores, listas, gráficos o escenarios de negocio, apoyándose en API documentadas y validadas. Toda la capa operacional está construida por los devs. El PM no parte de una hoja en blanco. Compone dentro de un marco.

Eso es ya lo que hacen ciertas herramientas desde hace mucho tiempo con lenguajes de consulta, dashboards o plataformas internas. La IA simplemente hace esta lógica más potente.

El punto importante es ese: las barandillas no solo ralentizan. Aceleran, porque evitan que la IA tome el camino equivocado.

De la pequeña herramienta interna al product builder

Quizás hay un escalón adicional.

Hasta ahora, podría creerse que hablo solo de pequeñas herramientas internas: una pantalla de consulta, un export, un dashboard, un visor, una interfaz temporal para ayudar al producto. Ese caso existe, y ya es interesante. Puede aliviar a los desarrolladores, acelerar el día a día, permitir a un equipo de producto responder él mismo a ciertas necesidades.

Pero no es necesariamente el único horizonte.

Si la codebase de la empresa está bien encuadrada, si las API internas están documentadas, si los conceptos de negocio son legibles, si los componentes y las convenciones son estables, entonces el PM puede quizás ir más allá de la simple herramienta interna. Puede convertirse en una especie de product builder.

No un desarrollador autónomo en cualquier tema. No alguien a quien se confíen sin límite las zonas críticas del producto. Sino alguien capaz de crear un módulo, una pantalla, un recorrido o una variación funcional apoyándose en la codebase existente.

La diferencia es importante.

En el caso de la pequeña herramienta interna, el PM construye a menudo al margen del producto. Consume API, agrega información, produce una interfaz útil para él o para su equipo.

En el caso del product builder, construye más en prolongación del producto. Usa los bloques existentes, el lenguaje de negocio del código, los componentes de la empresa, las barandillas puestas por los desarrolladores. No parte de una hoja en blanco. Compone con una materia ya estructurada.

Y es precisamente ahí donde la calidad de la codebase se vuelve decisiva. Una codebase mal encuadrada encierra al PM y a la IA en el bricolaje. Una codebase legible, documentada, orientada al negocio y con buen instrumental puede al contrario abrir un espacio de contribución más amplio.

El vibe coding no transforma pues automáticamente a un PM en product builder. No basta con darle Claude Code y un repositorio Git. Hace falta un terreno practicable.

Si ese terreno existe, entonces el tema se vuelve mucho más interesante que "¿pueden los PM hacerse sus pequeñas herramientas?" La verdadera pregunta se convierte en: ¿hasta dónde puede una organización permitir a perfiles de producto construir directamente ciertas partes del producto, sin perder el control técnico, la coherencia y la seguridad?

¿Y las specs en todo esto?

Esta experiencia también me ha llevado a replantearme una pregunta casi provocadora: ¿hay que seguir escribiendo specs?

No digo que las specs vayan a desaparecer en todas partes. Para muchos productos, contextos, temas regulatorios, decisiones estructurantes, siempre habrá que escribir, enmarcar, discutir, documentar el porqué.

Pero para ciertas herramientas internas, me pregunto si la spec no está cambiando de estatus.

En mi caso, no escribí ninguna spec. Me lancé. Construí. Mostré. Me dijeron: falta esto, haría falta aquello, por tal y tal razón. Añadí. Iteré.

¿Por qué hacer un prototipo si puedo construir directamente una primera versión usable? ¿Por qué escribir una spec descriptiva si puedo hacer emerger el comportamiento en el producto, y luego generar después la documentación funcional desde el código?

Había escrito recientemente que la pregunta de producto debía partir del código fuente. Esta experiencia va en el mismo sentido, pero desde el otro lado. Si el código se convierte en la verdad del comportamiento, entonces parte de la documentación puede regenerarse desde él. La spec no desaparece necesariamente, pero ya no puede pretender ser duraderamente la verdad del producto.

Para ciertos perímetros, casi podría decirse: ya no se escribe la spec antes. Se construye, se valida, y luego se genera el negocio desde lo que funciona.

Fuerzo un poco el trazo, evidentemente. Pero no tanto.

El riesgo organizacional

También hay un riesgo menos técnico, más organizacional.

Si todo el mundo empieza a fabricar sus pequeñas herramientas en su rincón, puede irse todo rápidamente en todas direcciones. Herramientas internas no mantenidas pueden volverse importantes. Scripts desechables pueden acabar usándose todas las semanas. Una pantalla improvisada para un equipo puede convertirse en un paso obligado. Una herramienta sin gobernanza puede volverse crítica sin que nadie lo haya decidido.

Pero ese riesgo no es exclusivo del vibe coding. Las empresas ya conocen eso con los archivos Excel, las macros, los scripts, las herramientas no-code, los dashboards construidos en un rincón. El vibe coding no crea el problema. Lo acelera, porque hace la producción de herramientas más fácil.

Aquí también, la respuesta no es prohibir. Es definir las zonas, los permisos, las responsabilidades, los límites, las barandillas.

Lo que eso cambia para los desarrolladores

No creo que los PM vayan a reemplazar a los desarrolladores.

En cambio, pienso que ciertas pequeñas herramientas internas que se pedían a los desarrolladores podrán ser producidas directamente por los equipos de producto, soporte, ops o negocio, siempre que estén bien encuadradas. Y eso puede aliviar a los desarrolladores.

¿Cuántas veces se le pide a un equipo de desarrollo que abandone el núcleo del producto para hacer una pequeña herramienta interna, un export, una pantalla de consulta, un dashboard, una interfaz temporal? Si una parte de esas peticiones puede absorberse en otro lugar, no es necesariamente una mala noticia.

Pero eso no hace desaparecer el papel de los devs. Al contrario, puede desplazarlo. Pasan a ser también quienes construyen las barandillas, las plataformas, las API limpias, las convenciones, los entornos seguros en los que otros pueden producir sin romperlo todo.

Eso no es menos técnico. Quizás es incluso más arquitectónico.

El cansancio

No quiero vender esta experiencia como un momento únicamente eufórico.

Es agotador.

Hacer más de 180 commits en cuatro días, aunque sea con una IA, no es trivial. No se teclea todo el código, pero se pilota, se relee, se prueba, se corrige, se decide, se retoma, se vigila, se reexplica. Se avanza muy rápido, pero hay que seguir la velocidad.

El vibe coding da una sensación de poder, pero no es un poder gratuito. El PM se convierte en una especie de piloto, de arquitecto de proximidad, de probador, de revisor, de dador de intención, de barrera de seguridad. Y si no tiene suficiente cultura técnica, puede encontrarse pilotando algo que no entiende realmente.

Ahí es donde la ilusión de competencia es peligrosa.

Ya conocemos eso con el no-code. Personas pensaban que ya no necesitarían desarrolladores, y luego descubrían tres días después que un sitio sin seguridad, sin protección contra ataques por fuerza bruta, sin circuit breaker, podía convertirse rápidamente en un problema. No era que la herramienta fuera mala. Es que daba acceso a un poder sin transmitir automáticamente la cultura de seguridad y arquitectura que va con él.

El vibe coding plantea el mismo tipo de pregunta.

Estoy documentando una travesía

No tengo una conclusión definitiva.

Y quizás esa es la única conclusión seria posible después de cuatro días.

Todavía estoy haciendo vibe coding. Sigo aprendiendo. Sigo viendo qué funciona, qué se rompe, qué se me escapa, qué recuperan los tests, qué aceleran las barandillas, qué me permite todavía sentir mi antiguo bagaje técnico.

No quiero fabricarme una opinión desde la tribuna. Quiero construírmela por la práctica.

Por ahora, lo que veo es una capacidad nueva, muy potente, pero que no suprime las viejas preguntas del software. Las hace a veces más visibles. Las acelera. Las desplaza.

El vibe coding permite ir muy rápido. Pero ir rápido no es lo mismo que saber adónde se va, ni saber qué se puede romper.

Así que sigo.

Estoy documentando una travesía.

Para saber más

La pregunta de producto debe partir del código fuente En 8 días comprendí que el rol de Product Manager iba a cambiar por completo La IA no debería servir solo para producir diez veces más. También debería obligarnos a entender diez veces mejor lo que producimos Code centric