Vibe coding frente a robustez: cómo gestionar las tensiones entre Product Builders y los equipos de ingeniería

Amélie Gouthier, AI Product Builder en Converteo, lidera la propuesta de valor en torno a la IA conversacional dentro de la firma. Especialista en estrategia de producto para soluciones basadas en LLM, dirige el desarrollo de agentes de última generación y la optimización de los flujos automatizados para marcas de retail y direcciones digitales.

Puntos clave

• Definir el carácter temporal del prototipo: no permitas que el código generado por IA pase directamente a producción. Considera el resultado del vibe coding como una especificación funcional ejecutable, destinada a ser reestructurada o reescrita conforme a los estándares de la empresa.
• Incorporar explícitamente las reglas de ingeniería a las herramientas: no pidas a los desarrolladores que revisen manualmente cada línea de código generado. Integra las restricciones de arquitectura y seguridad directamente en las instrucciones de tus herramientas para permitir una autonomía controlada.
• Establecer un proceso formal de transferencia: no elimines el diálogo entre producto e ingeniería en nombre de la velocidad. Sustituye la redacción de extensos pliegos de requisitos por una demostración del prototipo funcional para alinear a los equipos en torno al valor de negocio antes de la industrialización.

El origen de las tensiones entre el prototipado rápido y la ingeniería

La aparición del vibe coding —la posibilidad de que perfiles de producto o de negocio generen código funcional mediante lenguaje natural gracias a la inteligencia artificial— ha transformado el ritmo del desarrollo de software. Esta capacidad de crear prototipos interactivos en cuestión de horas agiliza la fase de pruebas, pero pronto choca con la realidad de las restricciones de ingeniería.

En los equipos técnicos, las reacciones ante el código generado automáticamente pueden ser contundentes. Algunos desarrolladores califican el resultado de shit coding, una expresión que designa un código aparentemente funcional, pero cuya arquitectura interna resulta desastrosa, está mal estructurada y carece de pruebas automatizadas.

Esta tensión no surge de una oposición de principio a la innovación, sino del choque entre dos culturas profesionales con objetivos diferentes:

• La cultura de producto: centrada en la velocidad de aprendizaje, la validación rápida de una hipótesis de uso y la reducción del tiempo de salida al mercado (time-to-market).
• La cultura de ingeniería: centrada en la estabilidad a largo plazo, la seguridad de los datos, la mantenibilidad del sistema y el control de la deuda técnica.

Cuando estas dos lógicas entran en conflicto sin un marco explícito, el prototipo rápido se convierte en una fuente de incomprensión. El equipo de producto reprocha a ingeniería su lentitud, mientras que los desarrolladores acusan al equipo de producto de introducir código inestable en los sistemas de información de la empresa.

La trampa de la deuda técnica invisible

El principal peligro del vibe coding no reside en el prototipo en sí, sino en la tentación de desplegarlo directamente para todos los clientes sin revisarlo ni adaptarlo previamente. La inteligencia artificial destaca en la creación de componentes visuales y lógicas sencillas, pero suele pasar por alto las restricciones fundamentales.

Una aplicación creada mediante vibe coding presenta habitualmente importantes deficiencias de diseño:

1. La ausencia de gestión de casos límite: la IA genera el flujo principal, es decir, el escenario en el que todo funciona, pero olvida gestionar los errores de red, la indisponibilidad de las bases de datos o las entradas incorrectas de los usuarios.
2. Las vulnerabilidades de seguridad: la inclusión directa de credenciales de API en el código fuente, la ausencia de comprobaciones de permisos y la gestión deficiente de las sesiones exponen a la empresa a fugas de datos.
3. Los costes de infraestructura fuera de control: las solicitudes no optimizadas a modelos de lenguaje o las bases de datos con índices deficientes pueden provocar un consumo presupuestario masivo cuando se escala la solución.

Cuando un perfil que no es desarrollador produce código cuyas bases técnicas no domina, genera una deuda técnica de la que ni siquiera es consciente. Si ese código se despliega en producción, la carga de mantenimiento recae inevitablemente sobre los ingenieros, que deben corregir errores sobre una base de software inestable.

Explicitar las reglas de ingeniería: crear un entorno de trabajo controlado

Para reducir los conflictos y devolver el control a los equipos técnicos sin limitar la creatividad de los perfiles de producto, la empresa debe formalizar sus reglas de desarrollo. Del mismo modo que un sistema de diseño (design system) establece las normas gráficas que deben respetarse, un marco de ingeniería define los requisitos técnicos innegociables.

Este marco se basa en la creación de un entorno de pruebas aislado, conocido habitualmente como sandbox o entorno de staging. El departamento de sistemas de información (DSI) proporciona un espacio técnico seguro en el que los Product Builders pueden generar código, conectar datos ficticios y probar sus prototipos de forma autónoma, sin riesgo alguno de afectar al sistema en producción.

El siguiente paso consiste en integrar las reglas de ingeniería directamente en las herramientas de IA utilizadas por los perfiles de producto. En lugar de permitir que la herramienta genere código siguiendo estándares genéricos, el equipo técnico configura las instrucciones del sistema (system prompts) y las reglas del editor de código, por ejemplo, mediante los archivos de configuración de Cursor.

Gracias a esta configuración previa:

• La IA aplica automáticamente las convenciones de nomenclatura y la estructura de carpetas de la empresa.
• Las normas básicas de seguridad se incorporan durante la generación del código.
• Los desarrolladores recuperan la visibilidad y la tranquilidad respecto al código producido, ya que las medidas de protección están automatizadas.

El modelo de transferencia: del prototipo a la industrialización

Para consolidar la reconciliación entre el vibe coding y la ingeniería, la organización debe establecer un proceso formal de transferencia. El prototipo ya no debe considerarse el producto final, sino la especificación funcional más avanzada posible.

Este modelo de transferencia sustituye las antiguas prácticas de redacción de pliegos de requisitos textuales, que suelen requerir mucho tiempo y dar lugar a interpretaciones divergentes.

El proceso de transferencia se desarrolla en cuatro etapas estructuradas:

1. La demostración interactiva: el Product Builder presenta el prototipo en funcionamiento al equipo de ingeniería. Demuestra el valor de negocio validado con los usuarios y explica la lógica del recorrido.
2. La evaluación del valor: los equipos de producto e ingeniería confirman conjuntamente que la necesidad del usuario es real y que el impacto empresarial justifica la inversión necesaria para industrializar la solución.
3. La auditoría de arquitectura: los desarrolladores analizan el código del prototipo. Deciden qué elementos pueden conservarse —a menudo, la interfaz visual o la lógica de los prompts— y cuáles deben reescribirse, como el acceso a las bases de datos, la autenticación y la optimización de las consultas.
4. La planificación de la industrialización: el equipo técnico incorpora la adaptación del módulo a su lista de trabajo (backlog) y define los criterios de rendimiento, seguridad y mantenimiento necesarios para su despliegue real.

Este proceso garantiza que la velocidad del vibe coding sirva para reducir los riesgos de uso desde las primeras fases, mientras que el rigor de la ingeniería asegura la sostenibilidad del sistema a largo plazo.

FAQ