¿Qué es la metodología CRAFT?

Por qué importa CRAFT

La mayoría de los equipos operan en uno de dos modos de falla. O avanzan despacio porque cada decisión se vuelve a discutir, o avanzan rápido sin un entendimiento compartido y acumulan una deuda de retrabajo que crece mes tras mes. El primer modo desperdicia tiempo. El segundo desperdicia dinero.

En la era de la IA, el problema empeora. Cuando se tiene acceso a herramientas potentes de generación de código y de arquitectura, la velocidad a la que se puede producir un resultado equivocado no tiene precedentes. Un equipo sin claridad puede crear en un solo sprint decenas de funcionalidades asistidas por IA que se contradicen entre sí. Eso es caos acelerado.

Además, el riesgo deja de limitarse a la base de código. Cuando un sistema toma decisiones por su cuenta (enruta trabajo, redacta respuestas, ejecuta acciones en los sistemas del negocio), las preguntas cambian. ¿Qué se le permite tocar? ¿Quién puede anularlo? ¿Qué evidencia demuestra que sigue comportándose dentro de los límites que usted fijó? Esas preguntas no se cierran con un lanzamiento. Vuelven a surgir cada vez que cambian el modelo, el prompt, los datos o el negocio.

CRAFT existe porque construir y operar sistemas en la era de la IA exige un nuevo sistema operativo. Se necesita suficiente estructura para mantener la coherencia y lograr que las decisiones se sostengan. Pero esa estructura también debe habilitar la velocidad, no asfixiarla. CRAFT está diseñado para lograr ambas cosas.

Responde cuatro preguntas que toda organización que construye con IA debe responder:

¿Cómo mantenemos un entendimiento compartido mientras construimos más rápido? CRAFT guarda ese entendimiento en artefactos versionados que viven junto al código.

¿Cómo evitamos volver a discutir sin fin las decisiones, algo que acaba con la velocidad? CRAFT hace que las decisiones importantes sean visibles y estén razonadas. Cuando una pregunta surge por segunda vez, el razonamiento ya está ahí.

¿Cómo sabemos que el sistema sigue comportándose dentro de los límites que fijamos? CRAFT clasifica el riesgo, registra dónde reside la autoridad humana y condiciona los cambios a las evaluaciones, no a la confianza.

¿Cómo sabemos que realmente resolvimos el problema? CRAFT mide los resultados, no solo lo que se produce. El éxito exige evidencia, no reportes de estado.

Cómo funciona CRAFT: las cinco disciplinas

Context: construya primero una verdad compartida

Context es la comprensión estructurada y versionada del producto, el flujo de trabajo, sus usuarios, las restricciones del dominio y los objetivos de negocio que enmarcan todas las decisiones. Context no es documentación. Context es la fuente de verdad a la que vuelven los equipos cuando eligen qué oportunidad perseguir, toman decisiones, construyen funcionalidades o evalúan ventajas y desventajas.

Context empieza antes de lo que la mayoría espera. Antes de una decisión de producto hay una decisión de estrategia: qué oportunidad vale la pena, cuál es la línea base actual y qué está realmente dispuesto a cambiar el negocio en su forma de trabajar. Elegir la oportunidad es un problema de Context. Los equipos que se saltan este paso construyen sistemas bien gobernados que nadie necesitaba.

Un Context Graph puede describir qué problema resuelve el producto o el flujo de trabajo, cómo es el mundo del usuario, qué restricciones no son negociables, qué significa el éxito en términos medibles y qué riesgos técnicos, operativos o de negocio importan. Se versiona. Evoluciona a medida que se aprende. Pero, sobre todo, es explícito y compartido.

El principio de CRAFT es simple: si no está en Context, no es verdad compartida. Si Context es vago, todo lo que viene después es una suposición disfrazada de certeza.

Rationale: documente las decisiones antes de que la velocidad las entierre

Toda decisión importante necesita un registro: qué se decidió, por qué, qué alternativas se consideraron, qué riesgos se aceptaron y cómo sabremos si fue la decisión correcta.

Los Decision Records evitan la causa más común de pérdida de velocidad: volver a discutir lo que ya se decidió. A los seis meses, un ingeniero nuevo cuestiona una decisión de diseño. Sin un registro, el equipo vuelve a debatirla. Con un registro, usted lee el razonamiento y lo acepta, o bien anula formalmente la decisión con una justificación documentada.

Se registran dos decisiones que los equipos suelen dejar implícitas. La primera es la clasificación de riesgos: qué tan graves pueden ser las consecuencias de esta parte del sistema y, por lo tanto, qué nivel de escrutinio merece. La segunda es la autoridad humana: qué acciones puede tomar el sistema por su cuenta, cuáles requieren la aprobación de una persona y quién es esa persona. Dejar por escrito esas dos decisiones es lo que hace que un sistema con IA sea gobernable, y no solo funcional.

Esto parece una carga adicional. En la práctica, es lo contrario. Los equipos que se saltan este paso pasan mucho más tiempo en discusiones por Slack e idas y vueltas asíncronas tratando de recordar por qué algo se construyó de esa manera. Los Decision Records concentran ese tiempo en un costo único.

Automate: deje el andamiaje a la IA y el criterio a las personas

Con un contexto claro y un fundamento explícito, la IA y las herramientas pueden ejecutar el trabajo mecánico. Los ingenieros diseñan el sistema. La IA se encarga de los primeros borradores, el andamiaje y los patrones de implementación repetitivos. El criterio humano queda reservado para las decisiones de arquitectura, la aceptación de riesgos y el juicio sobre la calidad.

Automate abarca dos cosas fáciles de confundir: la IA que nos ayuda a construir y la IA dentro del sistema que estamos construyendo, que sigue actuando mucho después del lanzamiento. Ambas se acotan de la misma manera: la automatización es proporcional al riesgo y la autoridad humana es explícita. Generar una función auxiliar amerita una revisión ligera; permitir que un agente escriba en un sistema de registro amerita una evaluación rigurosa. Nuestros profesionales con certificación Anthropic diseñan esos límites, no solo los prompts.

Esta disciplina no se trata de reemplazar a los desarrolladores. Se trata de dirigir su esfuerzo hacia el trabajo que crea valor real. Si un ingeniero escribe a mano código repetitivo porque no existe una herramienta para hacerlo, eso es una falla del sistema, no un costo inevitable.

Fortify: diseñe la seguridad desde adentro, no la agregue después

Fortify significa que nada se lanza sin controles de calidad definidos. La seguridad, la capacidad de reversión y la confiabilidad se diseñan desde el principio; no se añaden al final.

Esto abarca la estrategia de pruebas, la observabilidad, los patrones de reversión y los entornos de preproducción. Significa entender el alcance del impacto de una funcionalidad antes de que llegue a los usuarios. Significa tener una ruta de reversión probada antes de lanzar cualquier cosa.

Para el comportamiento basado en IA, Fortify añade un segundo control: las evaluaciones. Un conjunto de evaluaciones es una serie de casos con respuestas correctas conocidas que se ejecuta con cada cambio en un modelo, un prompt, una herramienta o un permiso. Así se entera de que un cambio empeoró el sistema antes de que lo noten sus usuarios.

Fortify también define qué significa "funcionar" mientras el sistema está en producción. Los objetivos de servicio fijan la confiabilidad, la latencia y el costo que el negocio tiene derecho a esperar, además de la ruta de escalamiento cuando el sistema no los cumple. Esos objetivos se escriben antes del lanzamiento, no se negocian durante un incidente.

El principio operativo es este: "parece listo" no es un criterio aceptable para lanzar. Se requiere evidencia.

Telemetry: mida los resultados previstos

El éxito se mide con evidencia, no con reportes de estado. ¿La funcionalidad resolvió el problema? ¿La adopción coincidió con la hipótesis? ¿Movió la métrica que dijimos que movería? ¿Hay efectos secundarios inesperados?

Telemetry es el mecanismo de retroalimentación que cierra el ciclo. Las métricas y la evidencia de un ciclo alimentan el contexto del siguiente. Sin telemetría, se lanza a ciegas.

En producción, la telemetría sigue generando evidencia: la adopción, los patrones de excepciones, las anulaciones humanas, el costo, la latencia, la postura de seguridad y la métrica de negocio que el sistema está hecho para mover. Esa evidencia se revisa según un calendario, no por corazonadas. Cada revisión trimestral de valor identifica qué cambió en la evidencia de operación, qué acción sigue y cómo se verificará la siguiente mejora. En CRAFT, la mejora continua es una actividad gobernada, no una buena intención.

Los cuatro artefactos de CRAFT

Los artefactos de CRAFT no son documentación para cumplir el trámite. Cada uno es un mecanismo de control que resuelve un problema específico del sistema.

Intent Contract. Un Intent Contract es una declaración breve y aprobada del resultado, el alcance, las métricas de éxito, las restricciones, los límites de la autoridad humana y los criterios de aceptación. No es un acuerdo legal; las condiciones comerciales se establecen en el contrato del proyecto. Se acuerda antes de comenzar el trabajo y responde: ¿qué estamos construyendo? ¿Qué cuenta como terminado? ¿Cómo lo vamos a medir? ¿Qué queda fuera del alcance? ¿Quién decide qué puede hacer el sistema? Es el norte que guía todas las decisiones posteriores.

Decision Record documenta las decisiones técnicas y operativas importantes: la opción elegida, por qué se eligió, qué alternativas se consideraron, qué riesgos se aceptaron y cómo sabremos si fue la correcta. Evita volver a discutir lo que ya se decidió y crea memoria organizacional.

Context Graph es la fuente de verdad versionada. Recoge el panorama del producto y de los flujos de trabajo, el conocimiento del dominio, las restricciones técnicas, el contexto de negocio y los supuestos que dan forma al sistema. Evoluciona a medida que se aprende, pero se mantiene explícito y estructurado, y el equipo de operación lo sigue manteniendo después del lanzamiento.

Telemetry Ledger (registro de telemetría) da seguimiento a las métricas de resultado y a las señales operativas. Responde la pregunta: ¿logramos lo que nos propusimos? Lleva el aprendizaje de vuelta al siguiente ciclo y es la base de evidencia con la que trabaja la revisión trimestral de valor.

Estos artefactos viven junto al código. No son un silo de documentación aparte. Forman parte de cómo trabaja el equipo, y son lo que usted conserva. Cuando un proyecto cambia de forma, los artefactos son la razón por la que el siguiente ciclo empieza con contexto y no con arqueología.

Qué mide CRAFT

La métrica principal de entrega es el tiempo hasta el valor verificado: el tiempo desde un Intent Contract aprobado hasta que un resultado acordado se verifica en producción. No son puntos de historia. No son funcionalidades entregadas. No son tokens generados.

Esa elección es deliberada. La métrica solo puede reportarse si funcionó todo el ciclo: la intención fue lo bastante clara para aprobarse, las decisiones quedaron registradas, el sistema se fortaleció lo suficiente para lanzarse con seguridad y la telemetría pudo demostrar que el resultado realmente se movió. No se puede manipular simplemente lanzando más.

Dos métricas complementarias cubren el resto del ciclo de vida. El trabajo de evaluación se mide con el tiempo hasta una decisión ejecutable, desde el inicio de la evaluación hasta un Intent Contract aprobado. Una vez que el sistema funciona en producción, la métrica de operación es el tiempo hasta la siguiente mejora verificada: qué tan rápido la evidencia del sistema en producción se convierte en una mejora verificada del resultado de negocio. Debajo de las tres hay métricas de apoyo: calidad y confiabilidad, adopción, anulaciones humanas, costo y latencia, y seguridad y gobernanza.

Cómo se manifiesta CRAFT a lo largo del ciclo de vida

Considere un ciclo completo con CRAFT en marcha.

Empieza antes de la decisión de producto. Una evaluación establece la línea base, mapea el flujo de trabajo tal como funciona en realidad, clasifica el riesgo y produce un mapa de oportunidades. Lo que se obtiene es una decisión sobre qué vale la pena construir, no una presentación.

El Intent Contract surge de esa evaluación y normalmente toma días, no semanas. El Product Delivery Lead lo redacta con el responsable designado por el cliente. Un Product Delivery Lead es responsable del resultado: gestiona la intención, los hitos y el ritmo de entrega durante todo el proyecto. El Intent Contract establece el resultado, el alcance, las métricas de éxito, las restricciones (latencia, costo, cumplimiento normativo, compatibilidad con versiones anteriores), los límites de la autoridad humana y los criterios de aceptación.

El diseño abarca a la vez el sistema humano y el técnico. Si el propósito del trabajo es que las personas hagan algo de otra manera, el rediseño del flujo de trabajo forma parte del diseño; no es un agregado de última hora de gestión del cambio.

El líder de ingeniería usa el Context Graph para entender el panorama actual de sistemas, los patrones existentes y la deuda técnica que podría afectar este trabajo. Un ingeniero senior documenta la decisión clave en un Decision Record: por qué este enfoque y no las alternativas, y qué riesgos acepta. Con esa intención y ese fundamento definidos, las herramientas asistidas por IA generan el andamiaje y los primeros borradores, y los ingenieros revisan, modifican y construyen sobre ellos. La estructura es lo bastante clara para que la revisión y la anulación sean rápidas.

Las pruebas, los patrones de reversión, los conjuntos de evaluaciones y los objetivos de servicio se definen desde el inicio como parte de Fortify. El equipo sabe cómo validará el sistema antes de que llegue a los usuarios y cómo revertirlo si algo falla. Una vez lanzado, el Telemetry Ledger registra si el trabajo logró el resultado buscado, y el tiempo hasta el valor verificado se reporta frente a la métrica acordada.

Luego comienza la operación. El lanzamiento no marca el fin de nuestra responsabilidad; marca el momento en que empezamos a operar el sistema. El sistema opera frente a sus objetivos de servicio, la IA opera frente a sus evaluaciones y la evidencia de producción regresa al Context Graph. La revisión trimestral de valor convierte esa evidencia en la siguiente decisión, medida por el tiempo hasta la siguiente mejora verificada. Esa evidencia se convierte en el Context del siguiente ciclo. El ciclo no termina con el lanzamiento. Cambia la pregunta que se hace.

Ideas clave

CRAFT es un enfoque sistemático para gobernar el software y la IA en la era de la IA. No es un proceso rígido en cascada. Es un ciclo de control continuo en el que la claridad, el razonamiento, la automatización acotada, la seguridad y la evidencia guían cada iteración, desde la primera conversación sobre una oportunidad hasta la mejora que se pone en producción dos años después del lanzamiento.

Los principios centrales son reversibles: Context puede actualizarse a medida que se aprende. Las decisiones pueden revisarse formalmente. La arquitectura puede refactorizarse cuando cambian las restricciones. Los límites de autoridad pueden ampliarse o reducirse a medida que se acumula evidencia. Pero todos los cambios siguen siendo visibles y razonados.

CRAFT escala. En un solo equipo, reduce el desperdicio dentro de su trabajo. Aplicado a varios equipos y a las operaciones, le da a una organización algo más valioso: la capacidad de compartir contexto, aprender de las decisiones entre proyectos y acumular aprendizaje con el tiempo en lugar de reiniciarlo en cada traspaso.

Requiere disciplina. Documentar la intención toma tiempo. Escribir Decision Records resulta incómodo al principio. Pero el tiempo que se ahorra al no volver a discutir decisiones ni rehacer trabajo se multiplica rápidamente.

El resultado es una entrega más rápida con menos retrabajo, decisiones que se sostienen, un comportamiento de la IA que se mantiene dentro de los límites que una persona fijó a propósito y resultados medibles en lugar de suposiciones.