El criterio: la checklist honesta

Todo lo anterior converge aquí, en una herramienta deliberadamente modesta: una lista de preguntas. Un criterio no es un manifiesto a favor o en contra de las máquinas; es un procedimiento que da la misma respuesta sin importar de qué humor estés ni qué acabes de aprender. Y esa última cláusula es la difícil, porque el mayor enemigo de una buena decisión sobre máquinas no es la ignorancia, sino el entusiasmo reciente: quien ayer entendió los statecharts ve statecharts en todas partes. La checklist que sigue está diseñada para funcionar a pesar de ese sesgo, no gracias a tu objetividad. Respóndela con honestidad y el árbol de decisión al final se recorre casi solo.

Siete preguntas honestas

Ninguna pregunta decide por sí sola; es el peso conjunto lo que inclina la balanza. Respóndelas sobre el problema que tienes hoy, no sobre el que imaginas para dentro de un año.

Las tres restantes son sobre el contexto humano y temporal, tan decisivas como las anteriores. Cinco: ¿el diseño ya viene como diagrama? Si product o diseño te entregan el flujo dibujado como cajas y flechas, el problema ya se pensó como máquina y transcribirlo es fiel. Seis: ¿cuánta gente mantendrá esto? Una máquina explícita documenta el protocolo para el equipo; un flujo que solo tú tocas y que es simple no necesita esa documentación cara. Siete: ¿va a crecer? Un flujo hoy trivial que sabes que ganará estados y reglas cada trimestre justifica pagar la estructura antes; uno estable y pequeño, no.

Un matiz sobre el peso: las preguntas dos y cuatro valen doble. Puedes tener muchos modos excluyentes y aun así no necesitar una máquina si entre ellos no hay reglas de paso ni asincronía —eso es un enum—. Son las transiciones con reglas y la orquestación de efectos las que solo una máquina sirve bien; las demás preguntas modulan una decisión que esas dos ya casi han tomado.

Ese reparto desigual tiene una consecuencia práctica: puedes descartar muchas máquinas con solo las preguntas dos y cuatro. Si no hay reglas de transición ni asincronía con ciclo de vida, ninguna cantidad de modos ni de importancia del estado convierte el problema en una máquina; a lo sumo lo convierte en un enum bien tipado. Empieza siempre por esas dos: si ambas son no, has terminado sin gastar las otras cinco.

Las señales en contra

Un criterio honesto pesa también lo que empuja hacia el no. Estas cuatro señales, cuando aparecen, deberían frenar tu mano antes de escribir el primer createMachine, por muy atractiva que sea la herramienta.

La regla de oro con estas señales es que una sola de ellas con fuerza suele bastar para descartar la máquina, mientras que del lado a favor hacen falta varias juntas. La asimetría es deliberada: como el coste de la máquina es frontal y el beneficio incierto, el criterio debe estar sesgado hacia la herramienta más simple, y solo ceder ante evidencia acumulada. La duda, en este dominio, se resuelve bajando un peldaño, no subiéndolo.

Detrás de esa asimetría hay una razón económica que ya vimos: como el coste de la máquina es frontal y su beneficio incierto, equivocarse por defecto —un enum donde cabía una máquina— se paga con una refactorización barata el día que el dolor aparece, mientras que equivocarse por exceso —una máquina donde bastaba un booleano— se paga cada día en verbosidad, curva y ceremonia hasta que alguien se atreve a quitarla. Ante la duda, el error barato es quedarse corto.

Puntuar sin autoengaño: la ley del instrumento

Abraham Maslow lo dijo mejor que nadie: para quien solo tiene un martillo, todo problema parece un clavo. Aplicado aquí: para quien acaba de dominar XState, todo estado parece un statechart. Este sesgo es real, es fuerte, y es la causa número uno de sobreingeniería en este dominio. No se combate con buena voluntad —nadie cree estar sesgado— sino con procedimiento.

El antídoto tiene tres pasos. Primero, responde la checklist antes de haber decidido la herramienta, no después; si ya elegiste XState en tu cabeza, las siete respuestas se contaminan para justificar la elección. Segundo, busca activamente el sí que te contradice: si quieres usar una máquina, esfuérzate en argumentar por qué un enum bastaría, y solo descarta el enum si de verdad no aguanta. Tercero, pon fecha a la aspiración: cada vez que uses “podría crecer” como razón, exígete decir cuándo y cuánto; una aspiración sin fecha es entusiasmo disfrazado de previsión, y no cuenta como sí.

Hay un segundo sesgo, gemelo del primero y más difícil de ver: el del coste hundido aplicado al revés. Cuando acabas de dedicar una tarde a aprender statecharts, tu cerebro busca dónde amortizar esa inversión, y el primer flujo que se cruce parecerá el candidato perfecto aunque sea un formulario. El conocimiento recién adquirido pesa en la balanza más de lo que merece. El antídoto es un recordatorio austero: la herramienta que dominas no es un requisito del problema. Que sepas construir máquinas no es una razón para que este problema sea una.

Un truco social ayuda contra ambos sesgos: pídele a alguien que no haya aprendido XState hace poco que lea tu justificación. Si no consigue seguir por qué el problema necesita una máquina sin que apeles al futuro o a la elegancia, probablemente no la necesita. El criterio es más fiable cuando sobrevive a un lector escéptico que cuando solo te convence a ti.

El árbol de decisión

La checklist alimenta un árbol que integra las cuatro lecciones del nivel. Se recorre de arriba abajo y te deja en el peldaño más bajo que resuelve tu problema, que es siempre el correcto.

flowchart TD
A[cuantos modos excluyentes?] -->|cero o uno| B[useState o campo en store]
A -->|varios| C[hay reglas de transicion?]
C -->|no| D[enum de status en un store]
C -->|si| E[hay asincronia o crecimiento?]
E -->|poco| F[FSM a mano de 20 lineas]
E -->|mucho| G[hay jerarquia o actores?]
G -->|no| H[XState store o FSM a mano]
G -->|si| I[XState statechart completo]
style B fill:#a6e3a1,color:#11111b
style D fill:#89dceb,color:#11111b
style F fill:#89b4fa,color:#11111b
style I fill:#cba6f7,color:#11111b

Léelo así: cero o un modo excluyente es un booleano o un campo suelto en tu store. Varios modos sin reglas de paso son un enum de status —el peldaño de la lección 3—, que elimina los estados imposibles sin ceremonia. Varios modos con reglas pero poca asincronía y poco crecimiento son la FSM a mano de la lección 4. Solo cuando además hay orquestación async seria, jerarquía, regiones paralelas o el actor model entra el statechart completo de XState. Cada bifurcación hacia la derecha añade coste —el de la lección 2— y debe estar comprada por un sí concreto de la checklist, nunca por inercia ni por estética.

Ese árbol se puede escribir como código, y hacerlo es revelador: obliga a admitir que el criterio, una vez tienes las respuestas, no es más que contar señales y elegir el peldaño mínimo.

// El criterio, hecho explicito: contar senales y elegir el peldano minimo.
type Senales = {
  modosExcluyentes: boolean
  reglasDeTransicion: boolean
  asincroniaConReglas: boolean
  creceraEnEstados: boolean
}

function recomendar(s: Senales): 'useState' | 'enum' | 'fsm' | 'xstate' {
  if (!s.modosExcluyentes) return 'useState'
  if (!s.reglasDeTransicion) return 'enum'
  if (s.asincroniaConReglas || s.creceraEnEstados) return 'xstate'
  return 'fsm'
}

La función es honesta hasta cierto punto y deshonesta a partir de ahí. Honesta porque deja ver que la decisión es mecánica en cuanto tienes las respuestas; deshonesta porque cada booleano de Senales esconde un juicio —¿esto cuenta como regla de transición o no?— que ningún tipo puede tomar por ti. El criterio como código es una caricatura útil: muestra la forma de la decisión, pero las respuestas siguen exigiendo la honestidad que las secciones anteriores intentaron proteger.

Cada hoja tiene su herramienta idiomática en 2026. Un modo o dos sin reglas: useState, o un campo en Zustand o Jotai si el estado es global. Varios modos sin transiciones con reglas: un enum de status en el store, o directamente el que regala TanStack Query si el estado es de servidor. Varios modos con reglas pero sin jerarquía: la FSM a mano, o @xstate/store si quieres eventos tipados con menos ceremonia. Jerarquía, regiones paralelas o actores con invoke: XState v5 completo. Y un recordatorio transversal que ahorra la mitad de las máquinas mal puestas: el estado de servidor casi nunca es una máquina, es cache, así que resuélvelo con TanStack Query antes de preguntarte si necesitas un statechart para él.

Este árbol es local: decide entre formas de modelar un flujo. Al final del track lo reencontrarás absorbido en un árbol mayor —el de elegir arquitectura— que además distingue estado de servidor, de cliente y de UI, y sitúa las máquinas junto a signals, stores y arquitecturas unidireccionales como Elm o TCA. El criterio que acabas de aprender es una rama de aquel; dominarlo aquí, en pequeño, es lo que hará legible el mapa completo cuando llegues a él.