La línea difusa entre "vibe coding" y el desarrollo profesional con IA: por qué debería preocuparte

Antes creíamos que los asistentes de IA para código caían en dos mundos claros: prototipos rápidos o trabajo pro de verdad. Esa división se está borrando. Y trae dudas serias sobre quién responde por los errores, en qué confiamos y qué diablos significa "listo para producción" hoy.

El plan original: todo en su lugar

La idea era simple.

Vibe coding: el caos total. Gente sin experiencia pide a la IA que arme algo funcional. No importa si el código es un desastre. Sirve para jueguitos personales, scripts desechables o proyectos de fin de semana. Si falla, es tu problema. Sin víctimas.

Agentic engineering: lo serio. Desarrolladores expertos usan IA para potenciar su expertise. Seguridad al día, código mantenible, rendimiento óptimo. Tú mandas; la IA solo acelera.

Sonaba perfecto. En la realidad, todo se mezcla.

La cruda verdad

Los modelos son tan buenos que hasta los pros saltan la revisión.

Pides a Claude o tu agente favorito un endpoint JSON con consultas SQL, pruebas y docs. Sabes que lo clava. Así que no lees nada. Directo a merge.

¿Una vez? Pase. ¿Diez? Mala costumbre. ¿Cien? Ya estás en vibe coding, pero con un título que no te ganaste.

El dilema de la caja negra (y por qué no es tan raro)

Hay un contraargumento lógico: en empresas grandes, no revisas cada línea de tus compañeros. Confías en el servicio de redimensionado de imágenes sin husmear adentro. Usas librerías sin leer su código fuente. Delegas y sigues.

¿Por qué? Porque hay reputación en juego. Los ingenieros responden con su carrera. El sistema tiene frenos.

Con IA, no. Claude no pierde el puesto ni su reputación. Genera código de sus patrones de entrenamiento. Punto.

Pero... funciona una y otra vez. Confiar parece sensato.

El peligro real: normalización de la desviación

En ingeniería hay un concepto clave (de los análisis de desastres de la NASA): normalization of deviance. Rompes reglas unas veces sin drama y dejas de verlas como tales.

Cada componente de IA que subes sin chequear y sale perfecto te acerca al día que falla. Y lo ves en producción, cuando todo revienta.

No es que la IA falle mucho. Es que acierta lo suficiente para que bajemos la guardia.

Cómo no volverte loco (y ser responsable)

Si tu software impacta a otros —datos ajenos o experiencias reales—, arma un esquema:

1. Clasifica por riesgo. No todo merece el mismo escrutinio. Un archivo de config no es como lógica de auth. Y auth no es procesamiento de pagos.

2. Define qué es "revisar". No siempre es línea por línea. Para código IA de bajo riesgo: corre pruebas, verifica flujo lógico, chequea supuestos de seguridad y mide rendimiento.

3. Maneja la IA como un equipo interno. Confía en tareas rutinarias, pero lidera arquitectura y zonas sensibles. Tú eres el senior; ellos, juniors competentes.

4. Vigila tus sesgos. Si saltas una revisión por "suele salir bien", anótalo. Registra fallos (vendrán). Deja que los datos guíen tu confianza, no la pereza.

La verdad incómoda

Estamos en transición. Las herramientas impresionan. Ganas productividad real. Pero no sabemos usarla con cabeza. Y el sector casi no lo discute.

La comunidad ya resolvió algo así con open source: reputación, transparencia, accountability. La IA necesita su versión.

Mientras, tú respondes. Mantén los ojos abiertos. Sé honesto con lo que revisas. Recuerda: que funcione no significa que lo construiste tú.

¿Cómo llevas tu relación con herramientas de IA para código? ¿Te pillas en esa zona gris? Cuéntanos en comentarios. Esta charla la escribimos entre todos, y los pros debemos moldearla.