La IA no es predecible... pero tu proceso de desarrollo puede serlo

by Juan Renato Noh

Al trabajar en sistemas críticos del sector financiero y en especial en aquellos que se encuentran en producción es necesario contar con un control riguroso y un plan de mitigación de riesgos. Sin embargo, en esta era de la inteligencia artificial, debemos considerar que tanto las soluciones que diseñamos como las herramientas de IA que adoptamos para el desarrollo tienen la característica de no ser deterministas.

Este planteamiento me lleva a las siguientes preguntas :

• ¿Hay forma de mitigar el comportamiento probabilístico de los modelos de IA?
• ¿Es viable en los flujos de desarrollo?
• ¿Cómo líder técnico o arquitecto, qué estrategia puedo aplicar para mis procesos de desarrollo asistidos por IA?

¿Hay forma de mitigar el comportamiento probabilístico de los modelos de IA?

De forma corta SI , ahora es importante dejar en claro que la naturaleza del modelo seguirá siendo probabilística pero podemos construir un sistema determinista alrededor de él que nos dará un resultado más cercano al esperado .

The best practices for prompt engineering 2026 de anthropic nos sugiere :

• Ser explícitos y claros
• Dar contexto , explicar el propósito permite al modelo razonar y tomar mejores decisiones
• Ser específico , en límites y tareas .
• Usar ejemplos del resultado esperado .
• Permitirle al modelo recibir feedback si hay duda .
• Para tareas complejas utilizar “Prompt Chaining” . Es decir no resolver todo el trabajo en un paso sino dividirlo y utilizar la salida de un prompt para la entrada de otro .

Al revisar las prácticas de prompting preferí priorizar las prácticas core y la característica de “Prompt Chaining” . Desde mi punto de vista Prompt chaining aporta valor para emplearla en flujos de desarrollo .

¿Es viable en los flujos de desarrollo?

Al desarrollar con Inteligencia Artificial, el proceso suele comenzar con una instrucción o prompt dentro de la ventana de contexto de la herramienta. Sin embargo, depender únicamente de instrucciones puntuales puede generar resultados inconsistentes. Para tomar el control del flujo de desarrollo surge Spec-Driven Development (SDD). SDD es una metodología guiada por especificaciones donde se establece como fuente de verdad las especificaciones . El principio fundamental es que el código es el detalle de la implementación y no al revés .

Al usar especificaciones no todos los enfoques son iguales , estos niveles de rigor dependen de las necesidades , limitaciones y herramientas con las que cuenta el equipo.

A estos niveles de rigor se le conoce como “specification spectrum”.

Cada nivel significa :

• Spec First : La especificación se escribe y sirve únicamente para guiar el desarrollo . Cuando el código existe y el software evoluciona puede dejar de ser mantenida.

• Spec Anchored : La especificación y el código se tratan como socios de igual a igual y evolucionan en sincronía . Existen mecanismos como las pruebas automatizadas o CI / CD que garantizan el informar cuando no se encuentran sincronizadas . Un ejemplo claro es cucumber [3] herramienta que trabaja con la ideología de trabajar con escenarios escritos en su especificación y el concepto de una especificación viva en todo el proceso.

• Spec as Source : El código es generado totalmente desde la especificación por herramientas automatizadas de inteligencia artificial. Por lo general el humano no modifica el código lo que garantiza la sincronización entre especificación y código.

Ahora que sabemos cómo el desarrollo dirigido por especificaciones (SDD) nos ayuda a orientar nuestros flujos de trabajo, la pregunta es: ¿cómo lo aplicamos?

En el mercado existen herramientas como Github-Spec-Kit o Kiro, las cuales son buena opción para equipos en búsqueda de una herramienta madura y con documentación.

Sin embargo, si lo que se requiere es una adopción progresiva o desarrollar un expertise profundo en el equipo , vale la pena comprender el SDD Workflow [2] propuesto por el AI Scientis Deepak Babu.

SDD Workflow propone las siguientes etapas

• Especificar : En esta etapa se escribe ¿Qué debemos hacer? . Es necesario definir reglas de negocio , casos de uso . Se sugiere utilizar formatos estructurados como Given / When / Then , o ejemplos concretos de entrada y salida . En este punto se debe evitar el lenguaje técnico.

• Planear : Se define el cómo lo vamos a hacer . Es decir arquitectura , componentes , esquemas de bd , contratos de datos , requerimientos no funcionales. En resumen definir la solución .

• Implementar : El plan se convierte en tareas más pequeñas las cuales se van convirtiendo en pequeños incrementos validados por los Agentes de IA .

• Verificar : Se validan los escenarios de la especificación , pruebas unitarias en conjunto con el criterio humano para validar se cumplan los requisitos.

¿Cómo líder técnico o arquitecto, qué estrategia puedo aplicar para mis procesos de desarrollo asistidos por IA?

Considero que el decidir si aplica o no una metodología principalmente debe depender del valor que va a aportar y no por moda. Para evaluar si este enfoque encaja en tu contexto, cito de nuevo Deepak como una guía de referencia [2] quien nos comparte un diagrama de decisión de acuerdo a la naturaleza del proyecto.

De igual forma nos propone una regla de oro para la toma de decisiones.

<La regla de oro>

Aplica el nivel mínimo de rigor en la especificación necesaria para eliminar la ambigüedad en tu contexto. Prioriza la especificación para el desarrollo inicial asistido por IA; utiliza especificaciones como ancla para sistemas de producción de larga vida útil; y emplea la especificación como fuente única solo cuando las herramientas de generación sean maduras y fiables

Conclusión

En conclusión, existen formas efectivas de trabajar con inteligencia artificial de manera controlada. Sin embargo, como lo ha demostrado la historia del software, este paradigma traslada el peso principal hacia las especificaciones, pudiendo generar un cuello de botella en esta etapa. Por ello, resulta indispensable contar con profesionales experimentados que dominen estos nuevos esquemas y sepan determinar el nivel exacto de especificación que requiere cada proyecto.

Referencias

[1] Anthropic, «Best practices for prompt engineering for 2026», Claude Blog, 10-nov-2025. [En línea]. Disponible en: https://claude.com/blog/best-practices-for-prompt-engineering. [Accedido: 26-ago-2026].

[2] D. B. Piskala, «Spec-Driven Development: From Code to Contract in the Age of AI Coding Assistants», Technical Report, arXiv:2602.00180v1 [cs.SE], 30-ene-2026. [En línea]. Disponible en: https://arxiv.org/abs/2602.00180v1. [Accedido: 26-ago-2026].

[3] Cucumber, «Cucumber Documentation». [En línea]. Disponible en: https://cucumber.io/docs/. [Accedido: 26-ago-2026].

[4] GitHub, «spec-kit: Toolkit to help you get started with Spec-Driven Development», GitHub repository. [En línea]. Disponible en: https://github.com/github/spec-kit. [Accedido: 26-ago-2026].