Vengo del código.

Fui DevOps, aunque entonces no se llamaba necesariamente así. Fui desarrollador. Fui arquitecto de software. Y después, poco a poco, me fui alejando de esos oficios para pasarme a la gestión de equipos de desarrollo, al proyecto, a la agilidad, al product management.

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

Hasta ahora todo estaba muy acotado. Un script de Python, una función. Una tarea concreta. Una especie de delegación limpia: en vez de pedirle al LLM que ordenara él mismo los archivos dentro de su contexto, le hacíamos escribir un script. Ejecutaba una operación, comprobábamos, seguíamos.

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

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

Este texto no es una conclusión sobre el vibe coding. No tengo suficiente perspectiva para eso. Cuatro días son muy poco para fabricar una doctrina. Puede incluso que ese sea el punto más importante: sigo dentro. Estoy documentando una travesía.

La luna de miel

Lo primero que impresiona es la velocidad.

En cuatro días he sacado algo que, en la época en que yo desarrollaba, me habría llevado probablemente un mes. Puede que dos. Y no lo digo por quedar bien. Partí de cero. He hecho más de 180 commits. He construido, roto, corregido, reorganizado, probado, añadido comportamientos, presentado el producto, recibido peticiones de evolución, seguido adelante.

Es embriagador.

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

Y eso cambia muchas cosas.

Con una maqueta ya puedes iterar. Ves una pantalla, un recorrido, una intención. Y piensas: pues no, el botón no está en el sitio adecuado, 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. Lo usas de verdad. Lo ves de verdad. Notas los roces.

En mi caso, el cambio llegó de forma bastante natural. Al principio aquello parecía una maqueta. Luego la maqueta empezó a funcionar. Luego la presenté. Luego me pidieron mejoras. Luego me preguntaron cuándo se iba a poder usar.

Ahí suele empezar el peligro: cuando lo desechable se vuelve útil.

El jarro de agua fría

Lo segundo que impresiona es que Claude Code, si lo dejas solo, puede hacer absolutamente cualquier cosa.

Cualquier cosa no en el sentido de que nada funcione. Es casi al revés. Muchas veces funciona. La pantalla se muestra. Los datos aparecen. El botón hace algo. La demo sale bien. Y precisamente por eso es peligroso.

Claude tiene una tendencia natural a lanzarse. Programa. Añade. Engorda. Empieza con un archivo razonable, y ese archivo se hincha, se hincha, se hincha, hasta convertirse en un bloque que hace un poco de todo. Cuando hay que modificarlo, se pierde tiempo. Cuando hay que entender la intención, cuesta más. Cuando aparece un bug, ya no sabes exactamente dónde mirar.

Un desarrollador con experiencia piensa bastante pronto en la separación de responsabilidades. Se pregunta dónde colocar 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 quede acoplado con todo. Claude puede hacerlo, pero no lo hace de forma espontánea y constante. Hay que guiarlo.

Lo mismo con la volumetría.

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

Pero si no le dices nada, Claude puede perfectamente cargarlo todo, pasárselo entero a la página web, filtrarlo todo en el front y dar el problema por resuelto. En pruebas, con pocos datos, puede dar la impresión de que funciona. En uso real, revienta. O peor: no se rompe del todo, simplemente se vuelve lento, se queda colgado, se hace incomprensible.

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

Dirigir a un desarrollador junior muy rápido

La relación con Claude Code me ha recordado mucho a dirigir a un desarrollador junior extremadamente rápido.

Puede producir enormemente. También puede tomarse libertades absurdas. Le das una captura de pantalla de un componente y no hace exactamente lo que se le pide. Interpreta. Simplifica. Se va por su lado. A veces hay que volver a explicarle cosas básicas: por qué ese archivo no debe contenerlo todo, por qué esa capa no debe conocer a esa otra capa, por qué no se carga todo el dato, por qué hay que escribir los tests, por qué hay que volver a ejecutar los tests.

Y a veces no lo pilla a la primera.

No es grave en sí. Los desarrolladores humanos también se equivocan. Cosas desarrolladas por desarrolladores llegan 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 muchísimo código mediocre en muy poco tiempo. Si el marco no es bueno, la deuda llega rápido. Muy rápido.

En mi caso, mi pasado técnico me ayuda. Entiendo las líneas generales de la arquitectura. Veo cuándo un archivo empieza a hacerse demasiado grande. Veo cuándo las capas se mezclan. Intuyo cuándo algo va a dar un problema de volumetría o de mantenibilidad.

Pero no lo domino todo. Hay partes del código que no sería capaz de explicar de inmediato. Si me tomo el tiempo, puedo entenderlas. Pero no puedo sostener que tengo el mismo dominio que si hubiera escrito cada línea yo mismo.

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

Y ese matiz es esencial.

El tema de fondo: competencia multiplicada por riesgo

Se podría plantear la pregunta así: ¿pueden ya todos los PM desarrollar software con la IA?

Mi respuesta espontánea sería: no.

O más bien: depende.

Pero ese "depende" no es una escapatoria. 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 igual que con un desarrollador junior. ¿Le abrimos de entrada a un junior el repositorio más complejo, más crítico, el que más peso tiene en el negocio? No necesariamente. ¿Le damos acceso a todos los repositorios, a todos los datos, a todos los permisos? Tampoco.

Con un PM que hace vibe coding, lo mismo.

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 carné de conducir. No se conduce cualquier vehículo sin carné, porque puedes volverte peligroso. E incluso con carné, no se conduce todo. Quizá un PM oxidado pueda llevar una 125. Eso no significa que deba subirse a una gran cilindrada y salir a la autopista bajo la lluvia.

Cuando hablo de "código de PM", no es un insulto. No estoy diciendo que el código de un PM sea necesariamente malo. Estoy diciendo que es código producido por alguien que no domina bien, o que ya no domina bien, el código. Hay que aceptar, por tanto, unas limitaciones. Y sobre todo, hay que aceptar definirlas.

Verde, ámbar, rojo

No creo en una tabla universal.

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

Una herramienta interna pequeña, personal, de vida corta, con un impacto limitado, probablemente pueda vivir con poco formalismo. Si se rompe, no pasa nada. La tiras, la arreglas, pasas a otra cosa.

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 tocas producción crítica, datos sensibles de clientes, permisos, escrituras irreversibles, flujos con fuerte impacto en el cliente o en el negocio, cambias otra vez de categoría.

La seguridad, por ejemplo, me parece innegociable. Se puede discutir el nivel de tests necesario para una herramienta pequeña y 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 día.

Por suerte, los desarrolladores ya tienen muchas herramientas para eso: integración continua, escáneres, reglas, prácticas, competencias, a veces incluso prompts o skills internos. Así que el tema no es reinventarlo todo para los PM. Es conectar a los PM aumentados con las herramientas que ya existen.

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

Se podría responder: basta con que todo lo revisen los desarrolladores.

Desconfío bastante de esa respuesta.

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

Si un PM se fabrica una herramienta personal, desechable, de bajo riesgo, ¿hace falta de verdad movilizar a un desarrollador para revisarla? Quizá no. Si no, recreamos exactamente la dependencia que intentábamos reducir.

En cambio, la revisión sí puede tener un papel al principio, para ayudar a los PM a coger buenas prácticas. También puede ser necesaria según lo que esté en juego. Otra vez: no es sí o no. Es una cuestión de riesgo.

En algún momento hay que aceptar también la responsabilidad. Si decido fabricarme una herramienta, tengo que aceptar comer de mi propio plato. Si da errores, también me toca a 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 están bien". Sino porque son uno de los pocos modos de mantener el control sobre un código que no has escrito entero tú.

Claude no escribe espontáneamente los tests adecuados si no se los pides. Puede olvidarse. Puede escribir los tests después. Puede escribir tests que validan su implementación en lugar de la intención de negocio. Puede dar la impresión de que el producto está protegido porque hay tests, cuando lo que falta es una verdadera estrategia de test.

Un PM no conoce necesariamente el TDD. No conoce necesariamente la diferencia entre un test unitario, un test de integración y 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, quizá sea 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 ejecuta los tests muy a menudo. Cuando algo se rompe, los tests dan un punto de apoyo. Permiten entender dónde ha dejado de respetarse el comportamiento esperado.

No digo que todo deba probarse con el mismo nivel de exigencia. Una herramienta interna muy simple, de bajo riesgo, no requiere necesariamente una estrategia de test completa. Una vez más, es una cuestión de envergadura.

Pero en cuanto el producto se pone serio, los tests dejan de ser un extra. Pasan a formar parte del volante.

Los raíles aceleran tanto como protegen

Cuando hablo de raíles, no hablo solo de barreras que impiden a los PM hacer tonterías.

Los raíles sirven también para ir más rápido.

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

En cambio, si los desarrolladores ponen raíles, el PM y la IA saben por dónde ir.

Esos raíles pueden tomar varias formas: un catálogo de las API internas utilizables, una documentación funcional generada a partir del código, una correspondencia 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 de Claude, prompts, skills.

Se puede imaginar, por ejemplo, un entorno en el que un PM pueda crear pantallas internas, herramientas de consulta, listados, gráficos o escenarios de negocio apoyándose en API documentadas y validadas. Toda la capa operacional la construyen los desarrolladores. El PM no parte de una página en blanco. Compone dentro de un marco.

Es lo que ya hacen desde hace tiempo algunas herramientas con lenguajes de consulta, cuadros de mando o plataformas internas. La IA simplemente vuelve esa lógica más potente.

El punto importante está ahí: los raíles no solo frenan. Aceleran, porque evitan que la IA se equivoque de camino.

De la herramienta interna pequeña al product builder

Puede que haya un escalón más.

Hasta aquí se podría pensar que hablo solo de herramientas internas pequeñas: una pantalla de consulta, una exportación, un cuadro de mando, una herramienta de consultas, una interfaz temporal para echar una mano al equipo de producto. Ese caso existe y ya resulta interesante. Puede aliviar a los desarrolladores, acelerar el día a día, permitir que un equipo de producto atienda por sí mismo ciertas necesidades.

Pero no es necesariamente el único horizonte.

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

No en un desarrollador autónomo sobre cualquier tema. No en alguien a quien se le confían sin límite las zonas críticas del producto. Pero sí en 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 herramienta interna pequeña, el PM construye a menudo al lado del producto. Consume API, agrega información, saca una interfaz útil para él o para su equipo.

En el caso del product builder, construye más bien como prolongación del producto. Usa los bloques existentes, el lenguaje de negocio del código, los componentes de la empresa, los raíles puestos por los desarrolladores. No parte de una página en blanco. Compone con un material ya estructurado.

Y ahí es precisamente donde la calidad de la codebase se vuelve decisiva. Una codebase mal estructurada encierra al PM y a la IA en el apaño. Una codebase legible, documentada, orientada al negocio y bien dotada de herramientas puede, al contrario, abrir un espacio de contribución mucho más amplio.

El vibe coding no convierte, por tanto, automáticamente a un PM en product builder. No basta con darle Claude Code y un repositorio Git. Hace falta un terreno transitable.

Si ese terreno existe, el tema se vuelve mucho más interesante que "¿pueden los PM montarse sus herramientitas?". La pregunta de verdad pasa a ser: ¿hasta dónde puede una organización permitir que perfiles de producto construyan directamente ciertas partes del producto, sin perder el control técnico, la coherencia y la seguridad?

¿Y las especificaciones en todo esto?

Esta experiencia también me ha hecho replantearme una pregunta casi provocadora: ¿sigue siendo necesario escribir especificaciones?

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

Pero para ciertas herramientas internas, me pregunto si la especificación no estará cambiando de estatus.

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

¿Para qué hacer una maqueta si puedo construir directamente una primera versión utilizable? ¿Para qué escribir una especificación descriptiva si puedo hacer emerger el comportamiento en el producto y generar después la documentación funcional a partir del código?

Hace poco escribí 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 una parte de la documentación puede regenerarse a partir de él. La especificación no desaparece necesariamente, pero ya no puede sostener que es, de forma duradera, la verdad del producto.

Para ciertos perímetros, casi se podría decir: ya no escribimos la especificación antes. Construimos, validamos y luego generamos la documentación funcional a partir de lo que está funcionando.

Estoy cargando un poco las tintas, claro. Pero tampoco tanto.

El riesgo organizativo

Hay también un riesgo menos técnico, más organizativo.

Si todo el mundo empieza a fabricarse sus herramientitas por su cuenta, esto se puede desmadrar rápido. Herramientas internas sin mantenimiento pueden volverse importantes. Scripts desechables pueden acabar usándose todas las semanas. Una pantalla apañada para un equipo puede convertirse en 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 esto con los archivos de Excel, las macros, los scripts, las herramientas no-code, los cuadros de mando montados en una esquina. El vibe coding no crea el problema. Lo acelera, porque hace más fácil producir herramientas.

Una vez más, la respuesta no es prohibir. Es definir las zonas, los permisos, las responsabilidades, los límites, los raíles.

Lo que esto cambia para los desarrolladores

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

En cambio, sí creo que ciertas herramientas internas pequeñas que antes se pedían a los desarrolladores podrán producirse directamente por los equipos de producto, soporte, ops o negocio, a condición de estar bien acotadas. Y eso puede aliviar a los desarrolladores.

¿Cuántas veces se le pide a un equipo de desarrollo que salga del corazón del producto para hacer una herramienta interna pequeña, una exportación, una pantalla de consulta, un cuadro de mando, una interfaz temporal? Si una parte de esas peticiones puede absorberse en otro sitio, no es necesariamente una mala noticia.

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

No es menos técnico. Puede incluso que sea más arquitectónico.

El cansancio

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

Cansa.

Hacer más de 180 commits en cuatro días, incluso con una IA, no es neutro. No tecleas todo el código, pero diriges, relees, pruebas, corriges, decides, retomas, vigilas, vuelves a explicar. Avanzas muy rápido, pero hay que seguir el ritmo.

El vibe coding da una sensación de potencia, pero no es una potencia gratis. El PM se convierte en una especie de piloto, de arquitecto de cercanía, de tester, de revisor, de portador de la intención, de barrera de protección. Y si no tiene suficiente cultura técnica, puede acabar pilotando algo que en realidad no entiende.

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

Ya vivimos algo así con el no-code. Había quien pensaba que ya no necesitaba desarrolladores, y descubría tres días más tarde que un sitio sin seguridad, sin protección contra los ataques de fuerza bruta, sin circuit breaker, podía volverse un problema muy rápido. No era que la herramienta fuese mala. Era que daba acceso a una potencia sin transmitir automáticamente la cultura de seguridad y de arquitectura que la acompaña.

El vibe coding plantea el mismo tipo de pregunta.

Documento una travesía

No tengo una conclusión definitiva.

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

Sigo haciendo vibe coding. Sigo aprendiendo. Sigo viendo lo que funciona, lo que se rompe, lo que se me escapa, lo que los tests recogen a tiempo, lo que los raíles aceleran, lo que mi antiguo bagaje técnico todavía me permite intuir.

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

Por ahora, lo que veo es una capacidad nueva, muy potente, que no elimina las viejas preguntas del software. A veces las hace 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 vas, ni saber qué te arriesgas a romper.

Así que sigo.

Documento una travesía.