La capacidad de generar código con inteligencia artificial está avanzando más rápido que la capacidad de muchas organizaciones para definir qué necesitan construir. En Entelgy consideramos que esa distancia será uno de los grandes desafíos del desarrollo de software en los próximos años: proporcionar a los agentes el contexto, las reglas y los criterios necesarios para convertir una necesidad de negocio en una solución fiable.
Por Miguel Ángel Villacañas, Head of Digital Architecture & Devs de Entelgy
Durante años, buena parte de la conversación sobre productividad en el desarrollo de software ha girado alrededor de cómo acelerar la programación. La inteligencia artificial ha ampliado enormemente esas posibilidades, pero también nos obliga a revisar qué entendemos por productividad. Un desarrollador puede generar código más rápido sin que el equipo entregue antes una solución útil. Las dudas sobre los requisitos, los problemas de integración o las correcciones posteriores siguen consumiendo tiempo, aunque escribir el código resulte más sencillo.
Microsoft compartió en septiembre una experiencia que ilustra esta cuestión: la mejora de la productividad individual de sus desarrolladores con IA no se estaba trasladando a la productividad del equipo. Para abordar esa distancia, explicó su apuesta por el Spec-Driven Development (SDD), un enfoque que sitúa una especificación viva en el centro del desarrollo para conservar la intención de negocio y los criterios de aceptación. Me parece una señal relevante porque desplaza la atención hacia un problema que ninguna herramienta de generación de código resuelve por sí sola: mantener una comprensión compartida de lo que estamos construyendo.
La autonomía necesita contexto
Los agentes están ampliando su participación en el desarrollo. GitHub, por ejemplo, ha incorporado la posibilidad de trabajar con agentes de distintos proveedores dentro de GitHub y Visual Studio Code. Esta evolución permite delegar más tareas, pero también hace más necesario definir el alcance de cada encargo y revisar sus resultados.
Mi tesis es que cuanto más trabajo delegamos en la IA, más explícito debe ser el contexto que le proporcionamos. Un agente puede producir una implementación aparentemente correcta y, aun así, interpretar mal una regla de negocio, ignorar una dependencia o tomar una decisión incompatible con la arquitectura existente. La capacidad de generar una solución no garantiza que esa solución sea la adecuada.
Pensemos en una petición aparentemente sencilla: automatizar la aprobación de una solicitud. Para implementarla, necesitamos saber quién puede aprobarla, qué límites se aplican, qué excepciones requieren intervención humana, cómo se registra la decisión y qué sucede si falla un sistema del que depende el proceso. Si estas condiciones quedan implícitas, el agente tendrá que completar los huecos. Y una suposición técnicamente plausible puede convertirse en un error de negocio.
Especificar también es desarrollar
Aquí encuentro el principal valor del Spec-Driven Development: convertir la intención de negocio en una referencia estructurada que permita orientar la implementación, las pruebas y la revisión. La especificación recoge qué debe hacer el sistema, bajo qué restricciones y cómo comprobaremos que cumple lo esperado.
Para que resulte útil, debe evolucionar con el proyecto. Una especificación desactualizada pierde valor como referencia, y una especificación ambigua traslada esa ambigüedad al código. Por eso considero esencial mantener la conexión entre requisitos, decisiones arquitectónicas, implementación y pruebas. También hay que distinguir entre lo que sabemos, lo que estamos suponiendo y lo que todavía necesita una decisión.
Este enfoque exige criterio para ajustar el nivel de detalle. Una funcionalidad acotada y una aplicación crítica necesitan grados diferentes de definición y validación. La calidad de la especificación depende de su capacidad para resolver las incertidumbres relevantes antes de que se conviertan en errores costosos.
Medir el valor más allá del código
Desde una perspectiva empresarial, la pregunta es cuánto mejora el proceso completo. El tiempo hasta poner una funcionalidad en producción, el esfuerzo dedicado a rehacer trabajo, los defectos detectados y el coste de mantenimiento ofrecen una visión más útil que el volumen de código generado.
El ahorro debe evaluarse sobre el ciclo de vida del software. Una implementación rápida puede perder su ventaja si exige más revisiones, introduce problemas de integración o dificulta futuras modificaciones. Por eso defiendo que la adopción de IA debe acompañarse de criterios de calidad y métricas que permitan comprobar dónde aporta valor y dónde necesita mayor supervisión.
En Entelgy entendemos el desarrollo con IA como una transformación que conecta negocio, arquitectura e ingeniería. En esa transformación, el desarrollador conserva una responsabilidad decisiva: comprender el problema, definir las restricciones, evaluar las decisiones de los agentes y validar el resultado. Su conocimiento técnico sigue siendo imprescindible para juzgar un código que puede haberse generado en segundos.
La IA amplía nuestra capacidad para construir software. Aprovechar esa capacidad exige mejorar también nuestra manera de definirlo. La ventaja estará en saber qué merece la pena construir, explicar con precisión qué esperamos de ello y comprobar que el resultado responde a esa intención.
