12.1 Introducción
En el tema anterior identificamos situaciones favorables para utilizar Vibe Coding. Ahora estudiaremos el límite opuesto: tareas en las que la asistencia de una IA puede aumentar la incertidumbre, exponer información o producir un costo de revisión mayor que el beneficio obtenido.
Decir que una tarea no conviene no significa que la IA sea incapaz de generar una respuesta. Puede producir una propuesta extensa y convincente incluso cuando carece del contexto, las herramientas o el conocimiento especializado necesarios.
La decisión correcta puede ser trabajar sin IA, limitarla a una función secundaria o incorporarla únicamente bajo supervisión experta y controles adicionales.
12.2 Cuando no podemos verificar el resultado
La generación rápida solo es útil si existe una forma razonable de evaluar lo producido. Sin conocimientos, pruebas, documentación o acceso al entorno, una respuesta correcta y una incorrecta pueden parecer iguales.
Esta situación aparece cuando:
- No comprendemos el lenguaje ni podemos leer el código.
- No sabemos cuál debería ser el resultado.
- No contamos con un entorno donde ejecutar la propuesta.
- No existe una persona capaz de revisar el dominio.
- La aplicación falla solo bajo condiciones que no podemos reproducir.
- Aceptamos una explicación como sustituto de una prueba.
Podemos utilizar la IA para aprender o construir un ejemplo aislado, pero no deberíamos incorporar directamente el resultado a un sistema real.
12.3 Sistemas con consecuencias críticas
En algunos entornos, un error puede afectar salud, seguridad física, derechos, patrimonio o servicios esenciales. El problema no es solo la probabilidad de equivocarse, sino la gravedad del daño.
Entre los ejemplos se encuentran:
- Software médico o de asistencia clínica.
- Control industrial, transporte o infraestructura.
- Operaciones financieras y sistemas de pago.
- Decisiones automatizadas sobre empleo, crédito o acceso a servicios.
- Gestión de identidades y permisos privilegiados.
- Sistemas de emergencia o comunicaciones críticas.
La IA puede colaborar en tareas auxiliares, documentación o generación de casos de prueba. La implementación principal necesita procesos formales, especialistas, trazabilidad y validaciones acordes con el dominio.
12.4 Requisitos confusos o contradictorios
Cuando ni siquiera las personas involucradas saben qué debe hacer el producto, generar código puede ocultar el problema detrás de una interfaz funcional.
La solicitud contiene objetivos abiertos y potencialmente contradictorios. “Cualquier negocio” amplía el alcance, “simple” intenta reducirlo y “todas las validaciones” no define reglas.
Antes de programar conviene realizar entrevistas, describir usuarios, modelar procesos y acordar ejemplos. La IA puede ayudar a ordenar preguntas, pero generar una aplicación completa en esta etapa cristaliza supuestos que todavía deberían discutirse.
12.5 Datos confidenciales o regulados
Una herramienta necesita recibir información para ayudar. Si esa información contiene secretos comerciales, código restringido, credenciales o datos personales, puede existir una prohibición contractual, legal o interna.
| Información | Riesgo | Alternativa |
|---|---|---|
| Contraseñas y claves | Acceso no autorizado a sistemas. | Usar valores ficticios y un gestor de secretos. |
| Datos personales reales | Exposición de identidad y privacidad. | Anonimizar o generar datos sintéticos. |
| Código confidencial | Incumplimiento de acuerdos o políticas. | Utilizar una solución aprobada o un ejemplo mínimo. |
| Registros de producción | Pueden contener sesiones, correos y detalles internos. | Eliminar campos sensibles y compartir solo el fragmento necesario. |
| Información regulada | Incumplimiento normativo y pérdida de control. | Consultar responsables legales y de seguridad. |
Si no sabemos cómo procesa, conserva o utiliza los datos el servicio, debemos detenernos y revisar sus condiciones antes de compartirlos.
12.6 Operaciones destructivas o difíciles de revertir
Eliminar archivos, modificar datos en producción, reemplazar configuraciones o ejecutar migraciones puede producir pérdidas que una corrección posterior no recupera.
No conviene autorizar una operación amplia cuando:
- El destino exacto no fue confirmado.
- No existe una copia de seguridad comprobada.
- No hay una vista previa de los cambios.
- El comando utiliza rutas, variables o patrones ambiguos.
- No conocemos el mecanismo de reversión.
- La misma operación se aplicará directamente sobre producción.
La IA puede preparar un plan, una consulta de lectura o una migración para revisar. La ejecución debe separarse de la propuesta e incluir respaldo, prueba en un entorno controlado y autorización humana.
12.7 Proyectos grandes que la herramienta no puede observar
Una modificación local puede afectar contratos, integraciones o procesos que se encuentran fuera del contexto disponible. En sistemas antiguos o distribuidos, parte del conocimiento puede vivir en documentación, configuraciones externas o experiencia del equipo.
Las señales de contexto insuficiente incluyen:
- No existe documentación de arquitectura.
- Los usos de una interfaz se reparten entre varios repositorios.
- Hay procesos manuales dependientes del sistema.
- El entorno local no reproduce las integraciones reales.
- Las pruebas son escasas o no se pueden ejecutar.
- La modificación atraviesa muchos módulos al mismo tiempo.
En estos casos conviene investigar y reducir el alcance antes de pedir cambios. Un resumen generado no reemplaza el conocimiento de las dependencias reales.
12.8 Tecnologías poco documentadas o muy específicas
Los modelos responden mejor cuando existen patrones y ejemplos suficientes. Una tecnología interna, reciente, poco difundida o modificada por la organización puede no estar representada adecuadamente.
La IA podría mezclar conceptos de versiones distintas, aplicar convenciones de otra herramienta o inventar funciones plausibles. Si tampoco existe documentación confiable, resulta difícil detectar el error.
El uso puede limitarse a tareas que no dependan de conocimiento específico:
- Ordenar información que nosotros proporcionamos.
- Preparar preguntas para una persona experta.
- Explicar código incluido completamente en el contexto.
- Generar pruebas a partir de un contrato definido.
No conviene pedir que complete detalles inexistentes y luego tratar la respuesta como documentación oficial.
12.9 Decisiones de arquitectura sin contexto suficiente
Elegir base de datos, estrategia de autenticación, división de servicios o modelo de despliegue tiene consecuencias duraderas. La opción más popular no es necesariamente la adecuada.
Una decisión de arquitectura requiere conocer:
- Volumen y patrones de uso.
- Requisitos de disponibilidad y recuperación.
- Experiencia del equipo.
- Infraestructura y presupuesto.
- Restricciones legales y de seguridad.
- Integraciones existentes y evolución esperada.
La IA sirve para enumerar alternativas y preguntas. No conviene delegarle la elección final mediante una solicitud breve, especialmente si luego generará una gran cantidad de código alrededor de esa decisión.
12.10 Requisitos estrictos de rendimiento o tiempo real
El rendimiento depende de datos, carga, hardware, red y comportamiento completo del sistema. Una optimización generada sin medición puede complicar el código sin resolver el cuello de botella verdadero.
En sistemas de baja latencia, tiempo real o recursos limitados no conviene aceptar propuestas basadas únicamente en afirmaciones como “esta versión es más rápida”. Se necesitan perfiles de ejecución, pruebas de carga y métricas comparables.
| Antes de optimizar | Después de optimizar |
|---|---|
| Definir la métrica importante. | Repetir la medición en las mismas condiciones. |
| Construir una carga representativa. | Comprobar que no empeoren otros recursos. |
| Localizar el cuello de botella. | Verificar que el comportamiento siga siendo correcto. |
| Registrar el valor inicial. | Documentar el resultado y sus condiciones. |
12.11 Cumplimiento, licencias y responsabilidad legal
Un proyecto puede estar sujeto a licencias de software, contratos, normas sectoriales y obligaciones sobre datos. La generación de código no elimina esas responsabilidades.
No conviene avanzar solo con la interpretación de una IA cuando debemos determinar:
- Si una dependencia puede utilizarse comercialmente.
- Qué consentimiento se necesita para procesar datos.
- Cuánto tiempo debe conservarse determinada información.
- Qué auditorías exige una regulación.
- Quién asume responsabilidad por una decisión automatizada.
La IA puede ayudar a identificar temas para investigar, pero las decisiones requieren fuentes oficiales y profesionales responsables del área legal o de cumplimiento.
12.12 Cuando reemplaza el aprendizaje necesario
En una etapa inicial, obtener siempre la solución completa puede impedir el desarrollo de habilidades necesarias para verificarla. La velocidad inmediata se transforma entonces en dependencia.
No conviene delegar completamente una práctica cuyo objetivo es aprender:
- Resolver un ejercicio diseñado para comprender una estructura de control.
- Implementar una función para practicar algoritmos.
- Leer un error para aprender a depurar.
- Diseñar datos para comprender sus relaciones.
- Escribir pruebas para aprender a identificar casos límite.
Podemos pedir pistas, preguntas, explicaciones o revisión posterior. La asistencia debe conservar el esfuerzo cognitivo que la actividad busca desarrollar.
12.13 Tareas autónomas demasiado amplias
Solicitudes como “reescribí toda la aplicación”, “modernizá el sistema” o “corregí todos los problemas” combinan demasiadas decisiones y formas posibles de éxito.
Durante una tarea extensa, los errores iniciales se propagan. Además, revisar cientos de modificaciones mezcladas dificulta distinguir qué era necesario, qué cambió por preferencia y qué introdujo una regresión.
Antes de usar Vibe Coding conviene transformar el objetivo amplio en una secuencia:
- Inventariar el estado actual.
- Definir el problema prioritario.
- Elegir un módulo representativo.
- Establecer pruebas y métricas.
- Realizar una modificación acotada.
- Evaluar el resultado antes de repetir el patrón.
12.14 Señales para detenerse
Algunas señales indican que debemos pausar, reducir el alcance o cambiar de enfoque.
| Señal | Problema | Respuesta |
|---|---|---|
| No podemos explicar el código. | La revisión depende de la apariencia. | Reducir el ejemplo y estudiar sus partes. |
| Cada corrección produce nuevos errores. | La causa no fue comprendida. | Volver al caso mínimo reproducible. |
| La IA modifica archivos no relacionados. | El alcance está descontrolado. | Revertir la propuesta y delimitar archivos. |
| No existen pruebas ni copia recuperable. | Un error puede pasar inadvertido o ser irreversible. | Crear primero mecanismos de seguridad. |
| Se necesita compartir información prohibida. | Riesgo de privacidad o incumplimiento. | Usar datos sintéticos o una herramienta aprobada. |
| La decisión excede nuestros conocimientos. | No podemos evaluar consecuencias. | Incorporar una persona especialista. |
12.15 Alternativas a delegar la implementación
Decidir que no conviene generar el cambio completo no obliga a abandonar toda asistencia. Podemos reducir el rol de la IA y conservar tareas de menor riesgo.
- Pedir una lista de preguntas para aclarar requisitos.
- Solicitar alternativas sin ejecutar ninguna.
- Resumir documentación que ya proporcionamos.
- Construir un ejemplo aislado con datos ficticios.
- Generar casos de prueba para revisión humana.
- Explicar un error sin modificar archivos.
- Preparar un plan que incluya controles y reversión.
También podemos utilizar herramientas deterministas: formateadores, analizadores estáticos, generadores definidos por plantillas y scripts revisados. Para tareas repetibles, una automatización explícita puede ser más predecible que una generación nueva en cada ejecución.
12.16 Actividad de comprensión
Una organización desea pedir a un agente de IA: “conectate a la base de datos de producción, eliminá clientes duplicados y corregí automáticamente cualquier inconsistencia que encuentres”.
- Identificá los términos ambiguos de la solicitud.
- Enumerá los daños posibles y qué datos podrían ser sensibles.
- Explicá por qué una copia de seguridad es necesaria pero no suficiente.
- Separá las tareas de lectura, propuesta, prueba y ejecución.
- Diseñá un proceso con criterios de duplicación, entorno de ensayo, vista previa y aprobación.
- Indicá en qué pasos podría colaborar la IA y cuáles requieren responsabilidad humana directa.
Finalmente, elegí una tarea propia que inicialmente parezca adecuada para Vibe Coding. Buscá una condición que la vuelva inconveniente y describí qué cambio de alcance o control permitiría retomarla de forma segura.