11.1 Introducción
Después de conocer las ventajas y limitaciones de los modelos, podemos formular una pregunta práctica: ¿en qué situaciones la asistencia de una IA mejora realmente el proceso de desarrollo?
La respuesta no depende solamente del tipo de aplicación. Una misma tarea puede ser adecuada durante un prototipo y requerir controles mucho más estrictos cuando forma parte de un producto utilizado por miles de personas.
Conviene utilizar Vibe Coding cuando la velocidad de generación supera el esfuerzo necesario para explicar, revisar, probar y corregir el resultado. Si validar cuesta más que realizar el trabajo directamente, la ventaja disminuye.
11.2 Evaluar tarea, contexto y riesgo
No alcanza con preguntar si la IA “puede” generar el código. Debemos evaluar si resulta conveniente delegar una parte del trabajo en las condiciones actuales.
| Dimensión | Pregunta | Condición favorable |
|---|---|---|
| Objetivo | ¿Podemos describir qué resultado esperamos? | Existen ejemplos o criterios observables. |
| Alcance | ¿Sabemos qué archivos o funciones deberían cambiar? | El trabajo puede mantenerse pequeño y localizado. |
| Contexto | ¿La herramienta puede acceder a la información necesaria? | Los requisitos y convenciones están disponibles. |
| Verificación | ¿Podemos detectar si la propuesta es incorrecta? | Hay pruebas, tipos, ejemplos o revisión competente. |
| Impacto | ¿Qué ocurre si el cambio falla? | El efecto es limitado y puede revertirse. |
| Datos | ¿La tarea necesita información sensible? | Puede realizarse con datos permitidos o ficticios. |
Cuantas más condiciones favorables existan, más probable es que la IA reduzca el tiempo total hasta un resultado validado.
11.3 Prototipos y pruebas de concepto
El prototipado es uno de los escenarios más apropiados. Su objetivo es aprender: comprobar si una idea se entiende, observar un flujo o comparar alternativas antes de construir una solución definitiva.
La IA puede generar rápidamente:
- Pantallas con datos simulados.
- Formularios y navegación básica.
- Pequeñas demostraciones de una interacción.
- Variantes visuales para comparar.
- Integraciones mínimas con un servicio.
- Pruebas técnicas para confirmar compatibilidad.
Antes de comenzar conviene definir qué pregunta responderá el prototipo. “Determinar si las personas comprenden el proceso de reserva” es más útil que “crear una aplicación de reservas completa”.
11.4 Estructuras iniciales y código repetitivo
Las tareas con patrones conocidos permiten que la IA prepare una primera versión que luego adaptamos a las reglas del proyecto.
Algunos ejemplos son:
- Crear la estructura básica de un componente.
- Preparar operaciones de alta, consulta, modificación y eliminación.
- Generar campos semejantes en un formulario.
- Convertir datos entre dos formatos definidos.
- Agregar casos de prueba que siguen un patrón existente.
- Construir archivos de configuración a partir de un ejemplo.
La tarea resulta especialmente adecuada cuando existe un modelo dentro del repositorio. Pedir “creá el módulo de categorías siguiendo la estructura del módulo de productos” aporta una referencia concreta y facilita comparar ambos resultados.
11.5 Cambios pequeños y localizados
Una modificación acotada reduce la cantidad de contexto necesario y permite revisar con precisión qué cambió. Por ejemplo:
- Agregar una validación a un campo.
- Incluir una columna en una tabla existente.
- Mostrar un mensaje cuando no hay resultados.
- Ordenar una lista mediante un criterio definido.
- Corregir una condición que puede reproducirse.
- Renombrar un concepto en un conjunto identificado de archivos.
“Pequeño” no significa necesariamente pocas líneas. Significa que el comportamiento, las dependencias y la evidencia de corrección pueden comprenderse sin recorrer una parte extensa del sistema.
Es recomendable guardar o revisar el estado previo para distinguir las modificaciones de la IA de otros cambios que ya existían.
11.6 Exploración de alternativas
Antes de implementar podemos utilizar la IA para ampliar el espacio de opciones. Esto resulta útil cuando conocemos el problema, pero todavía no elegimos una estrategia.
| Decisión | Alternativas para explorar | Criterio de comparación |
|---|---|---|
| Presentar resultados | Tabla, tarjetas o lista compacta. | Cantidad de datos, pantalla y tarea principal. |
| Validar un formulario | Al escribir, al salir del campo o al enviar. | Claridad, accesibilidad y costo de validación. |
| Organizar una función | Solución directa o funciones pequeñas. | Complejidad, reutilización y facilidad de prueba. |
| Guardar un prototipo | Memoria, almacenamiento local o archivo. | Duración de los datos y entorno de uso. |
La IA puede describir ventajas y preparar ejemplos. La elección sigue dependiendo de requisitos, restricciones y experiencia del equipo.
11.7 Aprender con ejemplos situados
El Vibe Coding puede acompañar el aprendizaje cuando la persona participa activamente. En lugar de limitarse a copiar una solución, puede pedir explicaciones y modificar el ejemplo para observar consecuencias.
Un ciclo de aprendizaje útil sería:
- Describir el concepto que queremos practicar.
- Pedir un ejemplo mínimo y ejecutable.
- Anticipar el resultado antes de probarlo.
- Modificar una condición y volver a ejecutar.
- Explicar con palabras propias qué ocurrió.
- Comparar la explicación con documentación confiable.
Resulta conveniente cuando el ejemplo puede comprobarse y la IA actúa como guía. Deja de ser aprendizaje si reemplaza de forma permanente el esfuerzo de leer, razonar y practicar.
11.8 Comprender código existente
En un proyecto desconocido, la IA puede ayudar a construir un mapa inicial. Puede localizar puntos de entrada, resumir responsabilidades y seguir referencias entre archivos.
Preguntas apropiadas incluyen:
- ¿Qué archivos participan en este flujo?
- ¿Dónde se valida este dato?
- ¿Qué componentes llaman a esta función?
- ¿Qué pruebas muestran el comportamiento esperado?
- ¿Dónde se transforma la respuesta antes de mostrarla?
- ¿Qué configuración activa esta característica?
La respuesta debe apoyarse en archivos inspeccionados. Es útil solicitar rutas y referencias concretas para poder recorrer el proyecto personalmente.
11.9 Depuración con un problema reproducible
La IA aporta valor durante la depuración cuando recibe evidencia suficiente: mensaje completo, pasos, entrada utilizada, resultado esperado y resultado observado.
guardarProducto y la prueba adjunta lo reproduce. Identificá la causa antes de proponer un cambio.
Esta solicitud delimita el comportamiento y permite confirmar la corrección con la misma prueba. En cambio, “la aplicación no funciona” obliga al modelo a imaginar demasiadas causas posibles.
Conviene pedir primero diagnóstico y evidencia. Modificar varias partes al mismo tiempo puede ocultar la causa original o introducir errores adicionales.
11.10 Generación de pruebas y datos ficticios
Cuando el comportamiento está definido, la IA puede convertir requisitos en casos de prueba y datos representativos.
Puede ayudar a preparar:
- Casos normales, límites y entradas inválidas.
- Tablas de entradas y resultados esperados.
- Datos ficticios para interfaces y demostraciones.
- Pruebas semejantes a las existentes.
- Escenarios de regresión para un error corregido.
- Configuraciones mínimas para aislar una integración.
La persona debe revisar que las expectativas provengan del requisito y no de la implementación generada. Si la IA escribe función y prueba basándose en el mismo supuesto incorrecto, ambas pueden coincidir sin resolver la necesidad real.
11.11 Documentación y comunicación técnica
La documentación es una buena candidata cuando el código y el público destinatario están disponibles para contrastar el resultado.
El Vibe Coding puede colaborar en:
- Instrucciones de instalación y ejecución.
- Ejemplos de uso de una función.
- Descripción de parámetros y respuestas.
- Resumen de una modificación.
- Comentarios sobre decisiones poco evidentes.
- Explicaciones adaptadas a distintos niveles técnicos.
La documentación generada conviene ejecutarla como si fuéramos una persona nueva en el proyecto. Un comando bien presentado puede estar incompleto o depender de un paso que la IA no observó.
11.12 Herramientas personales e internas de bajo riesgo
Pequeñas automatizaciones para uso personal o interno suelen ofrecer una relación favorable entre beneficio y riesgo. Por ejemplo:
- Renombrar archivos según una regla.
- Transformar un archivo CSV conocido.
- Generar un informe a partir de datos no sensibles.
- Preparar una interfaz para una demostración interna.
- Automatizar una verificación repetitiva.
- Crear una calculadora específica para una tarea.
Aun en estos casos debemos conservar copias, probar con una muestra y evitar ejecutar operaciones destructivas sobre datos únicos. “Interno” no significa “sin consecuencias”.
Si la herramienta comienza a manejar credenciales, datos personales, decisiones financieras o procesos críticos, deja de ser un experimento de bajo riesgo y necesita controles adicionales.
11.13 Tecnologías nuevas con resultados verificables
La IA puede acelerar una primera aproximación a una tecnología que todavía no dominamos: explicar conceptos, preparar un ejemplo mínimo y relacionarlos con conocimientos previos.
El escenario es favorable cuando:
- Existe documentación oficial accesible.
- Podemos ejecutar el ejemplo en un entorno aislado.
- El objetivo inicial es aprender o evaluar, no publicar inmediatamente.
- La versión de la tecnología está definida.
- Contamos con pruebas o resultados esperados.
La IA reduce el tiempo de orientación, pero no convierte automáticamente a la persona en especialista. Para decisiones profundas siguen siendo necesarios estudio, práctica y revisión experimentada.
11.14 Señales de una tarea adecuada
Podemos reconocer una tarea favorable mediante un conjunto de señales. No es necesario que todas estén presentes, pero su combinación mejora la posibilidad de obtener valor.
| Señal | Por qué ayuda |
|---|---|
| El resultado puede mostrarse con un ejemplo. | Reduce interpretaciones diferentes. |
| Existe una implementación semejante. | Aporta convenciones y estructura verificables. |
| El cambio es reversible. | Limita el costo de una propuesta equivocada. |
| Hay pruebas automáticas. | Ofrecen retroalimentación rápida. |
| La persona comprende el dominio. | Puede reconocer supuestos incorrectos. |
| Los datos son ficticios o permitidos. | Reduce riesgos de privacidad. |
| La tarea admite iteraciones pequeñas. | Evita acumular errores durante demasiado tiempo. |
11.15 Proceso para decidir y trabajar
Antes de comenzar una tarea con Vibe Coding podemos aplicar el siguiente proceso:
- Definir el resultado y su valor.
- Estimar el impacto de un error.
- Comprobar que la información puede compartirse.
- Identificar archivos, versiones y convenciones relevantes.
- Dividir el trabajo hasta obtener una primera entrega revisable.
- Definir cómo se comprobará antes de generar código.
- Solicitar, inspeccionar y ejecutar la propuesta.
- Continuar solo cuando la evidencia coincide con el objetivo.
Este proceso evita elegir la herramienta únicamente por entusiasmo o costumbre. La decisión se apoya en el costo total y en la capacidad de conservar control sobre el resultado.
11.16 Actividad de comprensión
Evaluá las siguientes tareas:
- Crear dos variantes visuales para un prototipo de catálogo.
- Corregir un error reproducido por una prueba automática.
- Migrar sin interrupción todos los pagos de una empresa.
- Generar datos ficticios para una demostración.
- Aprender cómo funciona una API mediante un ejemplo mínimo.
- Modificar permisos de acceso en un sistema médico.
Para cada caso, respondé:
- ¿Qué parte podría realizar la IA?
- ¿Qué contexto necesitaría?
- ¿Cómo verificarías el resultado?
- ¿Qué impacto tendría un error?
- ¿Conviene usar Vibe Coding, usarlo con controles adicionales o elegir otro enfoque?
Finalmente, elegí una tarea real de un proyecto propio y redactá una primera entrega pequeña. Incluí resultado esperado, archivos relevantes, restricciones y evidencia de finalización.