De usar IA a trabajar con IA en el desarrollo de software: por qué la diferencia importa
Cuando la mayoría de los equipos técnicos hablan de usar inteligencia artificial en su trabajo, se refieren a algo concreto: escribir un prompt, obtener una respuesta, evaluar si sirve y continuar. Es una forma de interacción válida para tareas puntuales, pero que tiene un límite claro cuando se intenta aplicar a proyectos de software reales, con toda su complejidad, sus dependencias y sus requisitos de calidad.
En 3digits llevamos tiempo desarrollando software a medida para clientes de distintos sectores, y cuando empezamos a evaluar seriamente cómo incorporar la inteligencia artificial a nuestro proceso de desarrollo, rápidamente nos topamos con ese límite. Los modelos de lenguaje son capaces de producir resultados notables en tareas bien definidas, pero aplicarlos directamente a un proyecto real sin ninguna estructura alrededor produce lo que cualquier equipo técnico experimentado reconocería como un problema: contextos que se contaminan a medida que avanza la sesión, ejecuciones impredecibles, decisiones tomadas por el modelo sin criterio claro y ninguna trazabilidad sobre qué se ha hecho, por qué y con qué resultado.
La conclusión a la que llegamos, y que ha guiado toda nuestra aproximación desde entonces, es que el problema no está en los modelos. Está en la ausencia de estructura alrededor de ellos.
Lo que hemos adquirido y seguiremos refinando en distintos proyectos es lo que en la literatura técnica más reciente se denomina harnesses: una infraestructura operacional que rodea al modelo y transforma su capacidad autónoma en trabajo de ingeniería controlado y verificable. No se trata de pedirle a la IA que actúe como un experto, sino de rodearla de procesos, contratos y límites que hacen que su trabajo sea confiable independientemente del modelo concreto que se utilice.
La diferencia práctica es significativa. Sin esta estructura, un agente puede generar código que funciona en el vacío pero que no encaja con las convenciones del proyecto, tomar decisiones de diseño sin considerar el contexto acumulado de sesiones anteriores o avanzar en una dirección que el equipo técnico no ha validado. Con unos harnesses bien definidos, cada fase del proceso tiene entradas y salidas claras, el agente conoce el contexto tecnológico del proyecto antes de hacer cualquier cambio, y cada resultado puede auditarse porque existe un registro de qué decisiones se tomaron, en qué momento y con qué justificación.
Este enfoque ha cambiado fundamentalmente cómo abordamos el desarrollo en 3digits. No como un experimento puntual, sino como una metodología que hemos aplicado y seguimos aplicando en proyectos reales, ajustando y refinando a medida que acumulamos experiencia.
Este planteamiento define el marco conceptual: la IA necesita estructura para ser útil en proyectos reales.
El siguiente paso es entender cómo se materializa esa estructura y qué elementos la componen en la práctica.
Cómo estructuramos el desarrollo de software con agentes de IA
Uno de los problemas más comunes cuando se intenta incorporar inteligencia artificial a un proceso de desarrollo real es tratar al modelo como si fuera un colaborador con memoria, contexto y criterio propios. No lo es. Un modelo de lenguaje, por capaz que sea, no sabe en qué punto del proyecto está, qué decisiones se tomaron en sesiones anteriores ni qué convenciones técnicas sigue el equipo. Sin estructura alrededor, esa ausencia de contexto produce resultados inconsistentes que generan más trabajo de corrección que ahorro real.
La metodología en la que seguimos evolucionando, y que hemos aplicado en 3digits a lo largo de distintos proyectos, aborda este problema desde la raíz mediante lo que técnicamente se conoce como harnesses de agentes: una capa de infraestructura que proporciona al modelo dirección, memoria y límites operacionales antes de que empiece a trabajar.
Un aspecto clave de esta estructura es la separación entre orquestación y ejecución. En nuestro sistema existe un agente orquestador cuyo rol es equivalente al de un líder técnico: decide el flujo del trabajo, controla los puntos de decisión relevantes y sintetiza los resultados, pero no ejecuta directamente las tareas técnicas. La ejecución se delega a subagentes especializados, cada uno con un contexto y unas instrucciones adaptadas a su función específica. El agente que analiza requisitos trabaja con un contexto distinto al que genera pruebas, y el que revisa código opera con criterios diferentes al que produce documentación técnica.
Esta separación tiene una consecuencia práctica importante: cada subagente trabaja en un entorno acotado, sin el ruido acumulado del resto del proceso. El orquestador mantiene la visión global y decide cuándo una tarea puede resolverse de forma inmediata y cuándo requiere crear un subentorno aislado para preservar el foco y la precisión del resultado.
Otro componente fundamental es la calibración del proyecto antes de cualquier intervención. Antes de que un agente comience a trabajar, el sistema construye una comprensión del contexto tecnológico del proyecto: las convenciones de código, las herramientas disponibles, las decisiones de arquitectura ya tomadas y los criterios de calidad que aplican. Este paso, que podría parecer un overhead innecesario, es en la práctica lo que evita que el agente produzca soluciones genéricas que no encajan con el proyecto concreto.
También resulta esencial un ciclo de vida estructurado por fases. Cada tarea de cierta envergadura sigue un proceso de propuesta, diseño, implementación y verificación, donde cada fase produce artefactos que sirven de entrada para la siguiente. Esto elimina el impulso de saltar directamente al código, que es uno de los patrones más comunes y costosos en el uso no estructurado de IA en desarrollo. Una propuesta mal definida que el modelo ejecuta sin más produce código que hay que reescribir; en cambio, cuando pasa por diseño y verificación antes de implementarse, el resultado encaja con lo que realmente se necesita.
Por último, uno de los factores que más ha influido en los resultados observados es la memoria persistente entre sesiones. Los proyectos de software tienen una duración que va mucho más allá de una única sesión de trabajo. Sin un mecanismo de memoria, cada sesión empieza de cero: el agente no sabe qué se decidió antes, qué partes están completas ni qué problemas ya se han resuelto. Con un harness de memoria bien diseñado, el sistema recupera decisiones previas, aprendizajes y contexto histórico, lo que permite mantener la coherencia del proyecto a lo largo del tiempo y entre distintas personas del equipo que interactúan con el sistema.
La combinación de estos elementos es lo que convierte el trabajo con agentes de IA en algo que puede integrarse de forma sostenible en un proceso de desarrollo profesional. No como una herramienta que se usa cuando conviene, sino como una parte estructurada del flujo de trabajo con entradas, salidas y criterios de calidad definidos.
Con esta base, el uso de agentes deja de ser experimental y pasa a integrarse en el flujo de desarrollo.
La pregunta relevante entonces ya no es cómo funciona la metodología, sino qué resultados produce cuando se aplica en proyectos reales.
Rigor, verificación y resultados: qué ha cambiado en nuestros proyectos de desarrollo de software
Describir una metodología es útil. Pero lo que justifica adoptarla son los resultados que produce en proyectos reales, con sus plazos, sus requisitos y sus exigencias de calidad.
Uno de los cambios más relevantes tiene que ver con la forma en que se garantiza la calidad del resultado. En el trabajo con agentes sin estructura, la calidad descansa en la esperanza de que el modelo lo haya hecho bien. En nuestra metodología, descansa en la evidencia técnica. Cada fase del proceso tiene contratos de resultado definidos: el agente no puede considerar una tarea finalizada sin producir los artefactos que demuestran que el trabajo está completo, incluyendo pruebas, validaciones y un resumen con estados, decisiones tomadas y riesgos identificados.
También se ha producido una evolución clara en la capacidad crítica durante el desarrollo. Contar con un orquestador que controla el flujo y con subagentes especializados trabajando en entornos acotados permite al equipo técnico concentrarse en las decisiones que requieren criterio y experiencia, mientras el sistema gestiona el trabajo estructural. En la práctica, esto se traduce en que las partes más complejas de un proyecto se abordan con más información, más alternativas exploradas y mayor rigor en la validación de cada decisión.
Otro aspecto especialmente valorado por el equipo es la mejora en la documentación. En proyectos de cierta envergadura, la documentación técnica suele ser una de las primeras víctimas de los ajustes de plazo o alcance. Con esta metodología, la documentación se genera como parte del ciclo de vida de cada tarea, en lugar de concentrarse al final cuando el tiempo escasea. El resultado es una documentación más completa, alineada con el código real y generada sin añadir una carga significativa de trabajo al equipo.
Además, se ha modificado de forma notable la relación entre plazo, alcance y calidad. En proyectos de desarrollo a medida, es habitual que, a medida que avanza el trabajo, surjan tensiones entre lo que puede entregarse en el tiempo acordado y lo que el cliente esperaba recibir. Estas situaciones suelen resolverse recortando alcance o ampliando presupuesto. Con esta forma de trabajar, el equipo progresa con mayor velocidad y capacidad al mismo tiempo, lo que ha reducido de forma significativa la frecuencia e intensidad de este tipo de conflictos.
Dentro del propio diseño de la metodología incorpora también un elemento importante relacionado con la entrega hacia el equipo humano. El harness evalúa el riesgo y el volumen de los cambios generados y propone estrategias para que la revisión sea manejable. En lugar de presentar grandes bloques de cambios difíciles de procesar, el sistema fragmenta las entregas en partes que pueden revisarse con criterio, evitando que la densidad de la información comprometa la calidad del control final.
Este conjunto de mejoras no surgió de manera inmediata. Es el resultado de un proceso continuo de ajuste y refinamiento a lo largo de distintos proyectos, incorporando aprendizajes en cada iteración. Aun así, el balance acumulado es claro y justifica el esfuerzo de construir esta infraestructura: se trabaja con mayor velocidad, con mayor rigor técnico, con mejor documentación y con menos situaciones en las que hay que elegir entre calidad y plazo.
Una vez que la infraestructura está en funcionamiento y los resultados comienzan a ser medibles, emerge un nuevo nivel de decisión técnica.
El rendimiento del sistema no depende únicamente de la metodología, sino también de cómo se configuran los modelos que ejecutan cada tarea.
La configuración de modelos como decisión de ingeniería en el desarrollo de software
Uno de los aspectos de trabajar con agentes de IA que menos se discute en público, pero que tiene un impacto directo tanto en la calidad del resultado como en el coste del proceso, es la selección y configuración de los modelos que se utilizan en cada parte del trabajo. Es una decisión que en muchos equipos se toma una vez y no se vuelve a revisar, o que directamente no se toma: se usa el mismo modelo para todo. En nuestra experiencia, ese enfoque deja valor sobre la mesa y genera costes innecesarios.
La razón es que las tareas que forman parte del desarrollo de software son cualitativamente distintas entre sí. Analizar los requisitos de una funcionalidad compleja y evaluar las implicaciones de distintas decisiones de diseño es un trabajo que requiere un nivel de razonamiento elevado y una alta tolerancia a la ambigüedad. Generar la estructura base de un módulo bien definido, escribir pruebas unitarias para una función concreta o producir documentación a partir de código existente son tareas más acotadas, donde el nivel de razonamiento requerido es menor y donde la precisión puede mantenerse con configuraciones más ligeras.
Aplicar el mismo modelo, con la misma configuración, a todas estas tareas sin distinción tiene dos consecuencias. La primera es de coste: los modelos con mayor capacidad tienen un coste por token considerablemente superior, y usarlos para tareas que no los requieren es un gasto que no tiene retorno proporcional. La segunda es de eficiencia: en algunos casos, un modelo de menor capacidad aplicado a una tarea bien definida produce resultados más rápidos e igual de útiles que uno más avanzado, precisamente porque la tarea no requiere el nivel de razonamiento adicional que el modelo más potente aporta.
Lo que hemos aprendido, a lo largo de distintos proyectos y con distintos tipos de tareas, es a definir la configuración de modelos como una decisión de ingeniería explícita, no como un parámetro que se fija al principio y no se vuelve a tocar. Dentro del harness que rodea a los agentes, la selección del modelo para cada subagente se hace en función del tipo de tarea que ese agente va a ejecutar y del momento del proyecto en que se ejecuta.
Las fases de análisis, diseño técnico y revisión crítica de decisiones de arquitectura utilizan modelos con mayor capacidad de razonamiento. Las fases de generación estructural, documentación y pruebas sobre código bien definido pueden resolverse con configuraciones más eficientes. Y dentro de cada proyecto, esta distribución puede variar: una funcionalidad de alta complejidad puede requerir configuraciones más exigentes en fases donde otro tipo de funcionalidad no las necesitaría.
Dicho esto, también hemos aprendido que esta configuración no puede ser excesivamente granular ni revisarse en cada momento. Cambiar la configuración de modelos constantemente introduce su propio overhead y puede generar inconsistencias entre partes del proyecto que deberían ser coherentes entre sí. Lo que funciona en la práctica es definir un marco de configuración suficientemente amplio para cubrir la variedad de situaciones habituales en un proyecto, con ajustes selectivos cuando el tipo de tarea o la fase del proyecto lo justifica de forma clara.
Este nivel de control sobre la configuración de los agentes es posible precisamente porque existe un harness que estructura el trabajo. Sin esa infraestructura, la configuración de modelos es un parámetro global que se aplica a todo por igual. Con ella, es una variable que puede ajustarse de forma precisa en cada punto del proceso, con criterio técnico y con visibilidad sobre el impacto en coste y en calidad.
La conclusión que extraemos de este proceso es que trabajar bien con agentes de IA en proyectos reales no es principalmente una cuestión de qué modelos se usan. Es una cuestión de cómo se estructuran, controlan y configuran para que produzcan trabajo confiable, trazable y coherente con los estándares del proyecto. Esa infraestructura es la que marca la diferencia entre usar IA de forma oportunista y usarla como parte de una metodología de desarrollo profesional.
Preguntas frecuentes sobre IA en el desarrollo de software
El principal problema es la falta de control. Sin una estructura, los modelos generan resultados inconsistentes, toman decisiones sin contexto y dificultan la trazabilidad del trabajo dentro del proyecto.
Un harness es una infraestructura que rodea al modelo y define cómo debe trabajar: establece procesos, límites, contexto y criterios de calidad para convertir la IA en un sistema fiable.
El orquestador actúa como un líder técnico. Define el flujo de trabajo, controla las decisiones relevantes y coordina a los subagentes que ejecutan tareas específicas.
La calidad deja de depender de suposiciones. Cada tarea debe cumplir criterios definidos, generar validaciones y documentar decisiones, lo que permite verificar el resultado de forma objetiva.
No. En el desarrollo de software, las tareas tienen distintas necesidades. Ajustar el modelo según la complejidad permite optimizar costes y mejorar la eficiencia sin perder calidad.
Permite obtener resultados más consistentes, mejorar la calidad del código, reducir errores y escalar procesos de desarrollo de forma controlada. La IA deja de ser una herramienta puntual para convertirse en un sistema fiable dentro del ciclo de desarrollo.
Project Manager 