Dirigir a la IA es como dirigir a un humano

Hay una frase que repito mucho: la IA puede construir cualquier cosa, pero dirigirla es como dirigir a un humano. La aprendí construyendo URG Technology↗, una tienda en línea completa que levanté solo, en unos cuatro meses, con Claude como herramienta. No la digo para sonar moderno. La digo porque describe exactamente dónde quedó el trabajo difícil.

Cualquiera puede pedirle algo a una IA. Lograr que construya un proyecto entero sin romperse es otra cosa. Esto es lo que me funciona, en el orden en que lo aplico.

El cuello de botella se mudó

Durante años, el límite para construir software fue programar. Con la IA ese límite se movió de lugar. Pasó a ser dirigir: explicar bien, revisar y decidir. Si la instrucción es vaga, el resultado es vago. Si nadie revisa, los errores pasan. Si nadie decide, el proyecto da vueltas.

Eso ya lo sabe cualquiera que haya liderado un equipo. Yo lo aprendí primero con personas: en cuatro veranos en Cedar Point, en Estados Unidos, pasé de comidas y bebidas a liderar equipos de hasta 80 personas, en jornadas largas y con miles de visitantes esperando. Las reglas de un buen líder no cambian tanto cuando el equipo es una IA.

1. Un documento que sirve de contrato

A un equipo nuevo no le dices "hazme una tienda" y te vas. Le explicas qué se construye, para quién y con qué reglas. Con la IA es igual. Antes de tocar código en URG pasé cerca de dos meses escribiendo un documento de unas 195 páginas: identidad y precios, cada pantalla, las tres fichas de producto, los pagos, el panel y veinticinco reglas de prevención de errores.

Ese documento era el contrato. Cuando un resultado no convencía, no discutía con mi memoria: volvía al documento y miraba qué se había pedido. Y cuando la realidad cambió el plan, lo escribí: por eso existe una segunda versión que cuenta el estado verificado, y no lo que habíamos soñado.

La diferencia entre "hazme una tienda" y un pedido con reglas es enorme. El segundo dice qué tiene que pasar, qué no puede pasar nunca y cómo se comprueba: nunca se puede vender dos veces el mismo equipo, el cliente tiene 8 minutos para subir el comprobante, si la búsqueda no encuentra nada, ofrece tres alternativas. Con eso, la IA construye lo que necesitas y no lo que suena parecido.

No todos los proyectos necesitan 195 páginas. El catálogo de La Roca↗ se construyó en 4 o 5 días. El tamaño del plan depende del tamaño del riesgo, pero el plan siempre existe, aunque quepa en una página.

2. Tareas pequeñas, que se puedan revisar

URG no se construyó de un tirón. Se construyó en 293 tareas registradas, cada una con un pedido concreto: que el encabezado móvil robe menos pantalla, que la tira de logos de pago deje de moverse, que el sello de vendido quede centrado. Una tarea pequeña se explica en pocas líneas, se prueba rápido y, si sale mal, se repite con más precisión sin tumbar el resto.

En Atlantic Center↗ el ritmo fue distinto y la idea, la misma. El cliente pedía "junta todo", así que cada versión reunía muchos cambios, se probaba en bloque (con scripts para la lógica delicada y con la aplicación real para la interfaz) y se publicaba de una sola vez por actualización automática.

3. Verificar en el código, no en la promesa

Esta es la regla que más problemas me ha evitado: nada se da por hecho hasta verificarlo en el código. Una IA puede decir "listo" con total seguridad. Un humano también. En los dos casos, el trabajo de quien dirige es comprobarlo.

En La Roca↗ aprendí la versión más fina de esa regla. Una versión temprana del panel de analítica dejaba entrar con cualquier clave: el código trataba como éxito cualquier respuesta del servidor que no fuera "no autorizado". De ahí salió un principio que hoy aplico a todo: la ausencia de un error no es una confirmación de éxito. Verificar no es revisar lo que el código cree, es medir lo que el usuario ve.

Cuando hay plata de por medio, subo el nivel. En Atlantic Center, antes de tocar la nómina de profesores en la versión que el cliente ya estaba usando, escribí pruebas automáticas del renombrado y de la nómina. No porque desconfiara de la IA: porque un error ahí se paga con la plata de otra persona.

4. Distinguir lo que se pide de lo que se necesita

Dirigir no es obedecer. En Atlantic Center el cliente quiso crear la misma transportadora tres veces, una por cada precio. El sistema ya permitía cambiar el valor en cada viaje, así que no hacía falta. En profesores, en cambio, eso no existía y hubo que construirlo. Varias veces el pedido literal escondía otra necesidad, y cuando había dinero en juego pregunté antes de actuar.

Con la IA el riesgo es parecido: si lo que pides no es lo que necesitas, puede construir muy bien la cosa equivocada. El criterio tiene que venir de quien dirige, y eso incluye decirle al cliente cuando cree estar más protegido de lo que está.

5. Dejarlo todo escrito

Un proyecto sin documentación depende de la memoria de una persona, y la memoria se va. Por eso URG tiene dos documentos: el primero con la visión y la V2.0, del 19 de junio de 2026, con 98 páginas que solo cuentan lo verificado en el código, pensada para que otro equipo, o una IA, pueda reconstruir la tienda casi idéntica.

Este mismo sitio se construyó igual: con un documento maestro, decisiones claras y verificación de cada entrega. Si algún día quieres cambiar de proveedor, lo escrito es lo que te deja libre.

Lo que la IA no reemplaza

Después de URG, Atlantic Center y La Roca tengo claro el reparto. La IA construye rápido y no se cansa. Yo pongo la pregunta correcta, el plan, la revisión, la decisión de qué no se construye y la responsabilidad por el resultado. Con la IA se puede construir casi cualquier cosa, pero hay que saber dirigirla.

1. 1Escribe el plan antes de construir.
2. 2Divide el trabajo en tareas que se puedan revisar.
3. 3Verifica en el código, no en la promesa.
4. 4Pregunta qué se necesita, no solo qué se pide.
5. 5Deja escrito lo que cambió y por qué.