BlogLa IA como herramienta de desarrollo, no como palabra de moda
La mayoría de las discusiones sobre IA (Inteligencia Artificial) en el desarrollo de software caen en uno de dos campos: entusiasmo desenfrenado o temor existencial. Este artículo no es ninguno de los dos. Trabajo como desarrollador freelance en PHP, Laravel, aplicaciones móviles (Flutter/Dart), frameworks frontend, programas en C y más. Durante el último año he integrado agentes de IA en mi flujo de trabajo diario, y quiero describir concretamente cómo es eso — qué funciona, qué no funciona y por qué.
La restricción más importante que da forma a este flujo de trabajo es una que rara vez se menciona en el bombo publicitario: los agentes de IA tienen ventanas de contexto limitadas. No pueden mantener una base de código completa en su memoria de trabajo a la vez. Esto impone una disciplina que resulta ser una buena práctica de ingeniería independientemente de la IA: dividir las funcionalidades en fragmentos más pequeños y bien definidos; planificar antes de ejecutar; y revisar de forma iterativa en lugar de en una sola pasada grande.
Lo que sigue cubre el flujo de trabajo específico que uso, la infraestructura sobre la que se ejecuta, las lecciones que he aprendido al aplicarlo en múltiples stacks tecnológicos y los modos de fallo que debes conocer.
Claude Code y Codex
Mi agente principal de planificación e implementación es Claude Code de Anthropic. Diseña arquitectura, escribe planes de ejecución, genera código y trabaja las tareas de forma sistemática. Se encarga de la parte constructiva: dado un enunciado claro del problema y contexto relevante, produce un plan y luego lo implementa.
Mi agente de revisión es Codex de OpenAI. Su rol es adversarial en el sentido productivo: recibe el plan que Claude produjo y busca lagunas, suposiciones incorrectas, casos límite no contemplados y mejores enfoques. Los dos modelos provienen de organizaciones diferentes, entrenados con datos diferentes, con tendencias diferentes y puntos ciegos diferentes. Esa diferencia es el punto — uno detecta lo que el otro pasa por alto.
Revisar manualmente cada línea de código generado por IA anularía la mayor parte de la ganancia en eficiencia. Así que la propia revisión se delega a un agente. Mi rol es intervenir cuando los agentes se atascan, cuando la salida se desvía del requisito real o cuando se necesita conocimiento del dominio que ninguno de los dos modelos tiene. La decisión final sobre lo que se publica es siempre mía.
Planificar, revisar, iterar, ejecutar
El flujo de trabajo concreto para cualquier funcionalidad o tarea es el siguiente. Primero, le doy a Claude Code una descripción clara de la tarea junto con el contexto relevante: qué archivos están involucrados, qué patrones sigue la base de código existente, cuál debería ser el resultado esperado. Claude produce un plan de ejecución que cubre la arquitectura, los cambios específicos en archivos y el enfoque que pretende seguir.
Ese plan va a Codex para revisión. Codex identifica problemas: manejo de errores faltante, suposiciones incorrectas sobre el código existente, abstracciones demasiado complejas, descuidos de seguridad o casos que el plan no contempla. Los comentarios de Codex vuelven a Claude, que revisa el plan. Este ciclo normalmente se ejecuta dos o tres veces antes de que ambos agentes converjan en algo sólido. Si el plan contiene fases o sub-tareas distintas, cada fase pasa por el mismo ciclo de revisión antes de que comience la siguiente.
Solo después de que el plan es estable comienza la implementación. Después de la implementación, los commits también se revisan — dependiendo del tamaño y la complejidad del cambio, otra pasada del agente detecta problemas que se escaparon durante la fase de planificación. La idea clave es que iterar sobre un plan es mucho más barato que iterar sobre código escrito. La mayoría de los problemas salen a la superficie antes de que se implemente una sola línea.
Docker, VMs y NFS
Los agentes de IA no solo generan texto — ejecutan código, instalan dependencias, ejecutan pruebas e interactúan con el sistema de archivos. Ejecutar eso dentro de tu máquina host es un error que cometes una vez. Mi configuración usa contenedores Docker ejecutándose dentro de una máquina virtual. Los archivos del proyecto se exponen a los contenedores mediante un montaje NFS. Los agentes trabajan en la base de código real sin tener acceso directo al host.
Este aislamiento por capas importa en la práctica. Si un agente instala un paquete inesperado, ejecuta un comando con efectos secundarios o produce código que falla ruidosamente en tiempo de ejecución, el radio de explosión queda contenido dentro del contenedor. El límite de la VM es una segunda capa de contención. Los contenedores se pueden reconstruir limpiamente entre sesiones, por lo que no hay estado acumulado de una tarea contaminando la siguiente.
Usando múltiples sesiones SSH en la VM, es sencillo ejecutar varios agentes en paralelo — diferentes agentes en diferentes tareas, o diferentes agentes en diferentes proyectos simultáneamente. La configuración NFS significa que cada contenedor ve los mismos archivos sin duplicación ni sobrecarga de sincronización.
Un flujo de trabajo, muchos stacks
La variedad de proyectos a los que aplico este flujo de trabajo es más amplia de lo que podrías esperar: sitios web, aplicaciones móviles Flutter/Dart, programas en C, backends Laravel, frontends React y Vue, preparación de material de estudio para trabajar eficientemente con grandes volúmenes de contenido y redacción de textos. Los stacks son diferentes en casi todos los aspectos relevantes — lenguaje, runtime, herramientas de compilación, enfoque de testing.
El flujo de trabajo de planificar-revisar-iterar es agnóstico del stack. La disciplina está en el proceso, no en las herramientas. Lo que importa es dar al agente un contexto claro sobre lo que ya existe, lo que requiere la tarea y qué restricciones aplican. Los agentes de IA manejan el cambio de contexto entre stacks mejor de lo que esperaba inicialmente, siempre que el contexto se proporcione explícitamente en lugar de asumirse.
La misma infraestructura Docker-en-VM-sobre-NFS acomoda todos estos stacks con una reconfiguración mínima. La imagen del contenedor cambia; el flujo de trabajo no.
Por qué dos modelos superan a uno
La efectividad de la revisión con dos agentes se reduce al hecho de que cada modelo tiene datos de entrenamiento diferentes, elecciones arquitectónicas diferentes y tendencias diferentes en cómo aborda los problemas. Claude tiende hacia la exhaustividad y a veces sobreingeniería las soluciones. Codex suele ser más directo y señala cuando Claude ha añadido complejidad que el problema no requiere. Lo inverso también ocurre: Codex puede pasar por alto casos límite que Claude detecta cuando las posiciones se invierten.
La dinámica adversarial — un agente construyendo, otro buscando activamente problemas — refleja lo que sucede en un proceso funcional de revisión de código humano. En términos concretos, el ciclo de revisión detecta regularmente: manejo de errores faltante para entradas poco comunes pero válidas, configuraciones demasiado permisivas, suposiciones incorrectas sobre cómo se comporta el código existente, abstracciones que son técnicamente correctas pero más difíciles de mantener que una alternativa más simple, y problemas de seguridad que son fáciles de pasar por alto cuando te enfocas en la funcionalidad.
Esto no es una afirmación de que un modelo sea superior al otro. El valor está en la combinación. Dos agentes con puntos ciegos diferentes, en una relación explícita de revisión, producen un resultado más sólido que el que cualquiera produce por separado.
Una pregunta obvia es si añadir un tercer agente mejoraría las cosas aún más. En la práctica, los rendimientos disminuyen drásticamente. Un tercer agente revisando el mismo plan estaría de acuerdo con uno de los dos existentes — sin añadir información nueva — o introduciría una tercera opinión que requiere un desempate, ralentizando la convergencia en lugar de ayudarla. Dos agentes ya cubren los roles constructivo y adversarial a lo largo de múltiples rondas de revisión. La única excepción es la revisión de commits post-implementación, que opera con un contexto diferente (código real en lugar de un plan) y genuinamente se beneficia de una mirada fresca. Más allá de eso, apilar más agentes en la misma tarea aumenta los costos de tokens y la latencia sin una ganancia proporcional en calidad.
El desarrollador permanece en el ciclo
Delegar la planificación, implementación y revisión a agentes de IA no significa que el desarrollador desaparezca. Sigo siendo quien toma la decisión final sobre cada resultado. Los agentes producen propuestas; yo decido lo que se confirma. Esa distinción importa.
En la práctica, intervengo en varios puntos: cuando los agentes se quedan en un bucle con el mismo desacuerdo sin converger, cuando el plan se ha desviado de lo que realmente se solicitó, cuando una decisión requiere conocimiento del dominio o contexto empresarial que los agentes no tienen, y cuando la salida simplemente no se ve bien aunque no pueda articular inmediatamente por qué. Esto último vale la pena tomárselo en serio — el instinto del desarrollador desarrollado a lo largo de años trabajando en una base de código no es algo que tenga un agente.
El rol cambia de escribir cada línea a dirigir, validar y corregir el rumbo. Es más parecido a ser un tech lead con desarrolladores junior muy rápidos que a ser reemplazado por la automatización. La eficiencia proviene de la supervisión estructurada, no de eliminar la supervisión.
Calidad de entrada, calidad de salida
La calidad de lo que produce un agente de IA es una función directa de la calidad de lo que le das. Descripciones de tareas vagas producen resultados vagos. Una instrucción como “mejorar el flujo de autenticación” producirá algo — pero si es algo útil depende enteramente del contexto que proporciones sobre el flujo existente, qué específicamente necesita mejorar y qué restricciones aplican.
Un buen contexto incluye: una descripción precisa de lo que hay que hacer, las rutas de archivos relevantes, los patrones ya en uso en la base de código, cualquier restricción (rendimiento, compatibilidad hacia atrás, estándares de codificación) y cómo se ve un resultado exitoso. Escribir ese contexto lleva tiempo, pero es tiempo bien invertido. Los agentes que tienen contexto claro producen planes que requieren menos ciclos de revisión.
Aprender a escribir contexto efectivo es una habilidad que mejora con la práctica. Los primeros intentos tienden a estar sub-especificados, y se itera más. Los intentos posteriores son más ajustados, y el ciclo planificar-revisar converge más rápido. Estructurar el contexto para un agente de IA es estrechamente análogo a escribir un buen ticket para un desarrollador humano: si no puedes explicar claramente lo que quieres, el problema no es la herramienta.
Cuando la IA se equivoca
Los agentes de IA no son infalibles, y tratarlos como tales es donde los proyectos salen mal. Alucinan — describiendo con confianza APIs o bibliotecas que no existen. Se quedan atascados en bucles, aplicando la misma corrección repetidamente cuando no funciona. Producen código que parece plausible pero es incorrecto, y a veces defenderán enfoques incorrectos con aparente convicción.
Patrones de fallo comunes que he encontrado: un agente intenta repetidamente una corrección que no aborda la causa raíz; un agente inventa una función o método que no existe en la biblioteca con la que está trabajando; un agente malinterpreta la base de código existente a pesar de tener contexto relevante, porque el contexto era incompleto o engañoso. Reconocer estos patrones temprano importa. Cuando la salida deja de hacer progreso o empieza a ir en círculos, seguir alimentando el bucle es contraproducente.
Cuando esto sucede, la respuesta correcta es intervenir: reiniciar el contexto, reformular el problema, dividir la tarea en un fragmento más pequeño que sea más fácil de razonar, o a veces simplemente hacer esa parte manualmente. Si la salida es simplemente mala, deséchala y empieza de nuevo. El pensamiento de costo hundido no aplica al código generado — no hay artesanía invertida en él que valga la pena preservar.
El flujo de trabajo de planificación primero reduce estos fallos porque la mayoría de los problemas salen a la superficie durante la fase de revisión del plan, antes de que haya ocurrido cualquier implementación. Un mal plan es mucho más barato de descartar que código malo.
Ejecutar agentes de IA de forma segura
Los agentes de IA que ejecutan código, instalan paquetes y escriben en el sistema de archivos necesitan ejecutarse en un entorno aislado. Esto no es opcional. La configuración Docker-en-VM que uso proporciona contención por capas: el comportamiento inesperado de un agente afecta al contenedor, no al host. El límite de la VM proporciona una segunda capa. Incluso si algo sale muy mal dentro de un contenedor, la máquina host y otros proyectos no se ven afectados.
El código generado por IA puede introducir vulnerabilidades de seguridad: inyección SQL a través de consultas con parámetros incorrectos, configuraciones predeterminadas inseguras, acceso a archivos o red demasiado permisivo, validación de entrada faltante. El ciclo de revisión ayuda a detectar estos, pero no los elimina. La conciencia y una revisión final consciente de la seguridad siguen siendo necesarias.
Una práctica que vale la pena ser explícito al respecto: no alimentes credenciales sensibles, claves de API o datos de producción en los contextos de agentes de IA a menos que el entorno esté debidamente asegurado y entiendas a dónde van esos datos. La comodidad de dar a un agente contexto completo es real, pero también lo es el riesgo de hacerlo descuidadamente.
Una herramienta práctica, no un reemplazo
Los agentes de IA son un multiplicador de fuerza para desarrolladores que aplican estructura y disciplina al proceso. La ventana de contexto limitada — a menudo citada como una limitación — resulta imponer una disciplina que vale la pena tener independientemente: planificar cuidadosamente, trabajar en fragmentos bien delimitados, revisar antes de ejecutar. Estas son buenas prácticas de ingeniería con o sin participación de la IA.
El flujo de trabajo descrito en este artículo no es teórico. Ha sido aplicado en sitios web, aplicaciones móviles Flutter, programas en C, backends Laravel, frontends React y Vue, preparación de material de estudio y redacción de textos. El proceso se adapta al stack; el stack no dicta el proceso.
El desarrollador que entiende el problema, dirige el proceso y valida la salida sigue siendo quien entrega el resultado. Los agentes de IA hacen eso más rápido. No lo hacen innecesario.
