Qué ha cambiado: Las señales están por todas partes —en conversaciones de Slack, tickets de soporte, notas de ventas e incidencias de Jira— y pierden contexto cuando los equipos saltan de una herramienta a otra. Por qué importa: Si no se entiende el «porqué» de una solicitud, se desperdician ciclos de desarrollo. A quién afecta: A responsables de producto, líderes de investigación y equipos de éxito del cliente, que deben decidir qué problemas resolver. Recomendación práctica: Configura conectores y permite que el agente de Descubrimiento incorpore transcripciones, documentos y tickets. Usa un panel de puntos de dolor basado en evidencias que mida la frecuencia y la gravedad, destaque citas representativas de clientes y señale las señales contradictorias. Riesgos y limitaciones: Las entradas ruidosas pueden distorsionar las puntuaciones; añade una etapa de validación humana para corregir sesgos de muestreo.

Qué ha cambiado: Ahora, al priorizar, hay que evaluar tanto la viabilidad agéntica como el impacto en el negocio. Por qué importa: La programación más rápida reduce el coste de construir; el cuello de botella pasa a ser elegir las apuestas adecuadas. A quién afecta: A responsables de producto, líderes de diseño y partes interesadas del negocio, que deben sopesar el valor, el riesgo y la viabilidad. Recomendación práctica: Usa una matriz de puntuación doble: una rúbrica de 0 a 10 para el encaje con LLM y herramientas y la preparación operativa, y otra para el impacto, el esfuerzo y los aspectos regulatorios. Pide al agente de Priorización que elabore una matriz de puntuación ordenada, con evidencias trazables y una justificación breve para cada puntuación. Riesgos y limitaciones: Las ponderaciones reflejan la estrategia; defínelas y documéntalas de antemano, y vuelve a puntuar cuando aparezcan nuevas evidencias.

Qué ha cambiado: El diseño ahora debe generar documentos que también sirvan de contrato para los agentes de programación. Por qué importa: Una especificación clara con criterios de aceptación reduce la ambigüedad y acelera la entrega de principio a fin. A quién afecta: A los equipos de UX, responsables de producto y líderes de ingeniería que reciben la especificación. Recomendación práctica: Usa el agente Working Backwards para generar un PR/FAQ y el Generador de especificaciones para convertirlo en flujos de usuario, perfiles, criterios de aceptación y un documento de traspaso de diseño. Asegúrate de que cada requisito remita al punto de dolor de origen y al contexto de priorización. Riesgos y limitaciones: Una especificación demasiado prescriptiva puede limitar la creatividad de ingeniería; incluye una sección de «restricciones frente a intención» para que quienes implementen puedan proponer alternativas equivalentes.

Qué ha cambiado: Los agentes de diseño pueden generar wireframes, mapas de experiencia y prototipos HTML interactivos en el mismo espacio de trabajo que utiliza el Orchestrator. Por qué importa: Los prototipos rápidos permiten que las partes interesadas y los clientes refuten supuestos antes de escribir código. A quién afecta: A investigadores, equipos de UX y partes interesadas que deben dar el visto bueno antes de que ingeniería se comprometa. Recomendación práctica: Usa Fast Track en ámbitos conocidos y Deep Discovery para problemas nuevos. Haz pruebas breves de usabilidad o de tipo concierge con el prototipo interactivo, registra métricas y citas, e incorpora los resultados al panel de puntos de dolor. Riesgos y limitaciones: Los prototipos pueden dar una falsa impresión de fidelidad; los experimentos de diseño deben centrarse en objetivos de aprendizaje y umbrales de aceptación.

Qué ha cambiado: Los agentes de programación, como Kiro o Claude Code, pueden procesar especificaciones estructuradas mediante Agent Client Protocol (ACP) y generar código funcional con rapidez, pero necesitan un contrato inequívoco. Por qué importa: Una especificación lista para desarrollar, con pruebas de aceptación, cierra la brecha entre la intención del producto y la implementación. A quién afecta: A responsables de ingeniería, SRE y revisores de seguridad. Recomendación práctica: Reúne los requisitos, los modelos de datos, los criterios de aceptación y los casos de prueba en un único archivo prototype_spec.md; usa adaptadores compatibles con ACP para el traspaso e incluye una revisión humana obligatoria para aceptar o rechazar la especificación. Riesgos y limitaciones: Las compilaciones automatizadas pueden acelerar resultados deficientes; mantén puntos de control explícitos para la privacidad, el cumplimiento y la coherencia arquitectónica.