Deterministic and Probabilistic Development Workflows

Componer mecanismos con propiedades distintas

Deterministic and Probabilistic Development Workflows es la práctica de organizar trabajo de desarrollo combinando mecanismos de resultado definido por reglas con decisiones o generación AI que pueden variar, además de juicio humano y feedback del entorno. La pregunta es dónde conviene permitir exploración, qué debe quedar acotado y qué evidencia permite aceptar el resultado. Es una práctica transversal de composición, no una metodología universal ni una clasificación binaria de proyectos.

Un modelo puede proponer un cambio; el compilador comprobar compatibilidad de tipos; una suite ejecutar ejemplos del contrato; una persona decidir si el comportamiento corresponde a la necesidad. Cada intervención aporta algo diferente. No todo el proceso se vuelve probabilístico por incluir un modelo, ni los controles programados eliminan toda incertidumbre del resultado conjunto.

La composición puede existir en una tarea breve, un pipeline fijo o una ejecución delegada. Un script que entrega un diff a un modelo y conserva su revisión utiliza AI sin necesitar un agente autónomo. Un agente que elige comandos incorpora decisiones variables aunque algunas herramientas tengan reglas precisas. Interesa identificar esas fronteras para diseñar el trabajo y comprender los límites de lo que se observa.

Determinismo bajo entradas y estado pertinentes

Un mecanismo determinista, dadas entradas y estado relevantes equivalentes, se espera que produzca el mismo resultado definido por sus reglas. La calificación depende de qué se considera entrada: versiones, configuración, archivos, variables de entorno y otros estados pueden ser pertinentes. Compilación, validación de schemas, scripts exactos, formateo o determinadas pruebas pueden aportar comportamientos predecibles cuando esas condiciones están controladas.

Esto no autoriza a llamar perfectamente determinista a todo software tradicional. Concurrencia, temporización, servicios externos, estado distribuido, algoritmos estocásticos y dependencias del entorno pueden introducir variación observable. Un build que descarga contenido mutable no se explica solamente por su archivo de configuración. Un test que consulta la hora o comparte datos con otra ejecución puede variar aunque no utilice AI.

La documentación oficial de pytest sobre flaky tests, consultada el 2026-10-28, señala estado insuficientemente controlado y dependencias de orden entre las posibles causas. Es un ejemplo concreto de límites del entorno, no una afirmación de que toda prueba sea inestable ni una recomendación de incorporar esa herramienta al proyecto.

Usar «determinista» aquí requiere señalar mecanismo y condiciones pertinentes. Si cambió el compilador o el servicio remoto, observar un resultado distinto no demuestra que la regla fuera probabilística. Puede mostrar que no se repitieron las mismas condiciones. Si esas condiciones no pueden reconstruirse, conviene limitar la afirmación de reproducibilidad en vez de prometer una propiedad que no se verificó.

Comportamiento probabilístico y resultados variables

Un modelo probabilístico puede participar en interpretación, generación, planificación, clasificación, ranking o síntesis. En desarrollo puede proponer otra secuencia, elegir otra herramienta, editar una implementación diferente o priorizar otra hipótesis con entradas similares. Esa variación no implica azar sin estructura ni convierte automáticamente el trabajo en incorrecto o poco fiable.

Tampoco probabilístico y no determinista son sinónimos completos. El primero describe un componente o mecanismo basado en un modelo probabilístico; la variación observable de ejecución también puede provenir de otras causas. Una configuración puede reducir variación sin demostrar determinismo integral. Obtener la misma respuesta dos veces no prueba que todas las futuras ejecuciones produzcan esa respuesta.

Coding-Agent Failure Modes and Recovery conserva el tratamiento situado de Non-Deterministic Outcomes. Dos patches distintos pueden satisfacer el mismo contrato; dos respuestas idénticas pueden repetir el mismo error. El criterio de corrección se refiere a requisitos y evidencia. La variabilidad importa cuando perjudica propiedades buscadas, como compatibilidad, trazabilidad o comportamiento aceptado, no simplemente porque exista una diferencia textual.

probabilistic-vs-deterministic-software caracteriza mecanismos del software y non-determinism desarrolla variación y reproducibilidad. Esta página utiliza la distinción para organizar trabajo: decidir dónde es admisible producir alternativas y dónde hace falta comprobar condiciones invariantes. Tampoco supone que AI sea preferible para cualquier tarea ambigua. Una regla conocida puede resolverse mejor con software convencional, y una ambigüedad comercial puede necesitar una decisión humana.

Tres niveles de composición

En el nivel de mecanismo interesa qué transforma una entrada y bajo qué reglas: un modelo, un validador o un script. En el nivel de paso interesa además quién selecciona entradas, configura la herramienta e interpreta su respuesta. En el nivel de workflow interesa cómo se eligen y conectan pasos, cómo se repiten y qué permite terminar. Las propiedades de un nivel no se trasladan automáticamente a los otros.

Una herramienta determinista llamada por un agente probabilístico no hace determinista el workflow. El agente puede elegir otro archivo, otro argumento u otro momento de ejecución. Incluso con la misma herramienta, esas decisiones pueden cambiar el trabajo realizado. La herramienta conserva su contrato local; el sistema completo incluye también selección, estado y continuación.

A la inversa, un modelo dentro de un pipeline controlado no vuelve probabilístico cada paso. Una comprobación de schema puede rechazar consistentemente una estructura inválida aunque la estructura se haya generado de forma variable. La siguiente decisión puede permanecer programada. La composición mantiene propiedades parciales útiles sin prometer que el proceso entero posee una sola naturaleza.

Workflows vs Agents distingue dónde se decide la continuación. Agentic Workflow Patterns compara familias de orquestación como secuencias, rutas y feedback. La composición determinista/probabilística atraviesa esas familias y también procesos sin agentes. No es otro patrón equivalente, ni exige adoptar una estructura específica para desarrollar software.

Ejemplos de combinaciones y sus límites

Combinación posible	Aporte de cada parte	Límite relevante
Un modelo propone; el compilador comprueba.	Generación de alternativas y compatibilidad expresada por el lenguaje.	Compilar no demuestra satisfacer la regla de negocio.
AI edita; una suite ejecuta casos.	Producción de un cambio y observación de comportamientos seleccionados.	Los casos y sus resultados esperados pueden ser insuficientes.
Un agente planifica; un script ejecuta una transformación.	Organización adaptativa y operación acotada.	Elegir la transformación o sus entradas puede ser incorrecto.
Un modelo clasifica; una política programada decide.	Interpretación de una entrada y aplicación de una regla.	La política opera sobre una clasificación que puede estar equivocada.
Un agente prepara un patch; un analizador lo inspecciona.	Cambio candidato y detección de ciertas propiedades.	La ausencia de hallazgos no prueba ausencia de defectos.
AI revisa; una persona acepta o rechaza.	Observaciones y decisión según contexto y autoridad.	La decisión humana también puede heredar supuestos erróneos.

Son ejemplos componibles, no una pipeline obligatoria. Una corrección documental puede necesitar comprobar enlaces y exactitud sin compilar una aplicación. Un cambio de persistencia puede requerir una integración que una prueba unitaria no observa. La selección de mecanismos depende de la afirmación que se necesita respaldar y de los límites reales del entorno.

Controles programados y verificación semántica

Schemas, tipos, linting, permisos, reglas de política, builds y tests pueden acotar o examinar partes del trabajo. Conviene distinguir control preventivo y comprobación posterior: negar una operación limita qué se ejecuta; ejecutar un test observa un comportamiento bajo ciertas condiciones. Ambos pueden aportar confianza, con contratos y dependencias diferentes.

Un schema válido demuestra conformidad con la estructura y restricciones expresadas por ese schema, no que el contenido sea verdadero, pertinente o seguro. Un tipo compatible no establece que el importe calculado corresponda al acuerdo comercial. Una regla perfectamente repetible puede aplicar consistentemente una expectativa equivocada. Determinismo y corrección semántica responden a preguntas distintas.

Tests verdes tampoco constituyen una prueba determinista de cumplimiento integral. Puede haber un oráculo incorrecto, cobertura insuficiente o una integración no ejecutada. Generated Code Verification relaciona evidencia con aceptación, self-verification e independencia. La composición debería aprovechar esos controles sin convertir sus éxitos parciales en una certificación universal del cambio.

Los límites se vuelven útiles cuando se comunican explícitamente: qué revisión se comprobó, qué casos se observaron y qué condición quedó fuera. Una excepción conocida necesita interpretación en el proceso vigente, no ocultación para obtener un resultado favorable. La aceptación del equipo conserva su autoridad; no se deduce de que una herramienta haya devuelto cero.

Reproducibilidad y procedencia

Reproducibilidad pregunta si puede repetirse una observación bajo condiciones descritas y con qué grado de equivalencia. Determinismo describe la relación de un mecanismo con sus entradas y estado pertinentes. Registrar una ejecución puede facilitar reproducción y diagnóstico sin volver determinista un componente que no lo era. Tampoco un mecanismo determinista asegura reproducibilidad práctica si sus entradas se perdieron.

Para investigar variación pueden importar modelo y versión, prompts, instrucciones, contexto seleccionado, configuración de muestreo cuando esté expuesta, herramientas, SHA del repositorio, datos, entorno y servicios externos. No basta conservar el último mensaje si una herramienta leyó otra revisión. El nivel de registro debe responder al riesgo y al propósito; capturarlo todo puede ser costoso o exponer información innecesaria.

Los Development Context and Execution Records conservan evidencia situada. Context Engineering for Software Development distingue contexto activo y actualidad. Agent Tracing ayuda a relacionar eventos observados. Sus aportes pueden explicar una ejecución sin revelar razonamiento privado ni garantizar replay exacto de servicios o decisiones no controlados.

Una seed, un prompt fijado o una versión identificada son controles parciales, según lo que ofrezca la implementación. No se promete reproducibilidad perfecta de un servicio AI ni identidad byte a byte entre ejecuciones completas. Cuando la observación solo puede contrastarse funcionalmente, conviene declarar esa equivalencia y sus límites en lugar de simular una reproducción exacta.

Fiabilidad, límites estables y costo de control

Alrededor de componentes variables pueden establecerse entradas estructuradas, contratos de herramientas, permisos, criterios de detención y evidencia de salida. Tool Calling separa invocación estructurada de validez semántica o autorización. Estas fronteras facilitan detectar resultados inadecuados; no hacen falta nuevos conceptos de Guardrails o Structured Generation para explicar aquí su utilidad básica.

La recuperación puede combinar reintentos acotados ante una causa transitoria, alternativas autorizadas, aislamiento del workspace y Agent Checkpoints and Recovery. Un retry no corrige por sí solo un requisito mal interpretado; un checkpoint tampoco revierte necesariamente efectos externos. La fiabilidad del coding agent conserva su hogar existente, sin duplicar mecanismos generales con nombres AI.

Agregar reglas y gates puede reducir flexibilidad, incrementar complejidad o bloquear exploración útil. Una regla frágil sobre la redacción exacta puede rechazar soluciones válidas. Menos restricciones también puede trasladar costo a evaluación, revisión, latencia o intentos fallidos. No hay una preferencia universal por maximizar determinismo o libertad; interesa control apropiado para la consecuencia y la incertidumbre.

Human-Agent Collaboration delimita quién interpreta, decide, escala y acepta en esa composición. Ni más gates ni más autonomía sustituyen esa relación. La economía de AI mantiene su alcance futuro: aquí basta reconocer que controles, variación y revisión consumen recursos, sin inventar precios, métricas o una metodología económica.

Ejemplo: actualización de una dependencia

Un agente propone cambios para una actualización compatible. El lockfile fija resoluciones, el compilador detecta una incompatibilidad y los tests ejercen usos conocidos. El modelo puede elegir entre patches equivalentes, pero el contrato de compatibilidad y el alcance autorizado siguen vigentes. Que el build pase no demuestra que una API externa conserve su comportamiento.

Si aparece un fallo intermitente, conviene contrastar estado y entorno antes de atribuirlo al carácter probabilístico del agente. Si el patch introduce una dependencia adicional no autorizada, repetir la suite no resuelve la desviación de alcance. El resultado combina inspección del diff, evidencia técnica y decisiones pertinentes, sin exigir el mismo recorrido a toda actualización.

AI-Native Software Development como encuadre editorial

En V0.5, AI-Native Software Development es un encuadre VOLATILE: procesos de desarrollo diseñados alrededor de una participación AI significativa, en vez de limitarse a agregar AI a un flujo sin revisar su organización. Es una interpretación editorial en evolución, dependiente de comunidad o proveedor. No constituye un estándar, metodología, nivel de madurez ni arquitectura obligatoria.

AI-Assisted expresa contribución de AI al desarrollo; AI-Native puede enfatizar el rediseño deliberado del proceso alrededor de esa participación. No existe aquí una frontera universal, un umbral cuantitativo o una certificación que separe ambas etiquetas. Un equipo puede incorporar AI extensamente sin adoptar ese nombre. La etiqueta tampoco demuestra calidad, productividad o corrección.

AI-Native no exige autonomía, múltiples agentes, MCP ni un producto particular. Un proceso con propuestas de modelos, herramientas programadas y decisiones humanas puede responder a ese encuadre. Specification-Assisted Development aporta expectativas explícitas cuando corresponde, pero no es una metodología universal AI-Native ni obliga a seguir Spec → Plan → Implement para toda tarea.

La utilidad del término depende de si permite discutir cambios concretos en tareas, evidencia y responsabilidad. Si solo renombra automatización sin aclarar decisiones, aporta poco. Por su volatilidad permanece como subtema, sin canonical separado ni una taxonomía nueva de estilos de desarrollo.

Fuentes y alcance editorial

La definición, los niveles de composición, las tablas y los ejemplos son síntesis del Atlas. La fuente primaria nueva es pytest: Flaky tests, usada para ilustrar variación por estado y entorno, no para fundamentar afirmaciones sobre modelos concretos. Las relaciones internas conservan las definiciones generales de agentes, verificación, permisos y fiabilidad; aquí se estudia su composición durante el desarrollo.