Desarrollo con IA v6.2 · 6 módulos · 30 lecciones de unos 15 minutos
Uno hace, el otro verifica
Claude y Codex juntos, desde el briefing hasta la aceptación: uno planifica o implementa, el otro critica el artefacto real, y las pruebas y tú deciden. Con el modelo y el esfuerzo elegidos por etapa y el costo medido.
Los términos técnicos del curso explicados con palabras sencillas. Cada término te lleva a las lecciones donde aparece.
AGENTS.md
Archivo de texto en la raíz del proyecto con las reglas y el orden de lectura. Codex lo lee automáticamente al empezar; otros asistentes lo leen cuando alguien se lo indica.
Programa de control de versiones: guarda cada cambio de los archivos de una carpeta, para que puedas ver qué cambió y volver atrás. El módulo 3 enseña lo necesario.
El programa de IA que lee tu pedido y escribe la respuesta, como Claude o GPT. Otro modelo = otra IA; una conversación nueva con el mismo asistente también sirve como segunda opinión.
Puedes mirar un resultado hecho con IA y distinguir lo que verificaste de lo que solo aceptaste.
La IA escribe código, texto y hojas de cálculo en minutos, y con mucha seguridad. El problema es que la seguridad no es una prueba. Quien entrega el trabajo responde por él, no la IA.
En 1 minuto
La IA dice "listo" con la misma seguridad cuando acierta y cuando se equivoca.
Verificar es mirar el resultado real, no el resumen que la IA hizo de él.
La decisión de entregar es tuya. La IA ayuda a verificar, pero no firma.
1La IA dice "listo" con la misma voz cuando se equivoca
Los asistentes de código como Claude Code y Codex trabajan rápido. Al final, escriben un resumen de lo que hicieron.
Ese resumen es la opinión de la IA sobre su propio trabajo. A veces tiene razón. A veces dice "probado" sin haber probado nada.
Rafael, desarrollador independiente, pidió un formulario de contacto para el sitio web de una clínica. La respuesta llegó en dos minutos, con "probado y funcionando".
Asistente de código
RafaelCrea el formulario de contacto de la página de la clínica. El envío va al correo electrónico de recepción.
IAListo. Creé el formulario con nombre, teléfono y mensaje, y el envío a recepción. Probado y funcionando.
Parece completo. Pero ¿qué se probó y cómo?
Rafael¿Cómo probaste exactamente el envío a recepción?
IAVerifiqué que la página se abre y que aparece el formulario. No envié ningún mensaje de verdad. Para probar el envío, manda un mensaje desde la página y revisa la bandeja de recepción.
Una pregunta mostró que "probado" solo significaba que la página se abría.
Toca o haz clic en los dos botones del cuadro: la misma tarea, antes y después de preguntar.
2Verificar es mirar el resultado real
Aceptar es confiar en el resumen. Verificar es abrir lo que se hizo y comprobar si hace lo que debía.
Rafael abrió la página, completó el formulario e hizo clic en enviar. La pantalla mostró "mensaje enviado", pero no llegó nada a la bandeja de recepción.
Aceptó
Lo que hizo: leyó "probado y funcionando" y envió el enlace a la clínica.
Resultado: recepción descubre el error días después, con pacientes sin respuesta.
Verificó
Lo que hizo: envió un mensaje de prueba y revisó la bandeja de recepción.
Resultado: encontró el error antes de entregar y pidió que lo corrigieran.
Balance: cinco minutos de verificación en lugar de una semana de mensajes perdidos.
3Tres formas de comprobar
No existe una sola comprobación. Este curso usa tres, siempre juntas.
La primera es un criterio de aceptación, escrito antes. La segunda es abrir y usar el resultado. La tercera es una segunda mirada: otro modelo, una conversación nueva u otra persona.
Carla, analista de operaciones, genera con IA el informe semanal de entregas. Comprueba el total de pedidos con la hoja de cálculo original antes de enviarlo a la dirección.
Comprobación del informe de Carla
1 Criterio: total de pedidos igual al de la hoja de cálculo
2 Abrir el informe y sumar la columna de pedidos
3 Pedirle a otra IA, o a una conversación nueva, los números sin fuente
1Escrito antes de pedir el informe.
2Hecho por ella, en el archivo real.
3Una mirada externa, que enseña el módulo 2.
Si te trabaste aquí, es normal¿Parece demasiado trabajo para cada pedido? No es para cada pedido. Empieza solo por lo que va a otra persona: cliente, jefe, equipo.
Ponte a prueba
La IA terminó la tarea y escribió "todas las pruebas pasaron". ¿Qué es esto?
4La IA ayuda a comprobar; quien decide eres tú
Un segundo modelo encuentra fallas que el primero no vio. Aun así, la decisión de entregar sigue siendo tuya.
Carla le pide a otro modelo que revise el informe. Señala dos ciudades intercambiadas. Quien decide si el informe se envía hoy es ella.
Lo que hace la IA
Produce, revisa y señala fallas con la evidencia.
Lo que te corresponde
Defines el criterio, miras el resultado real y decides si lo entregas.
Las dos tarjetas están bien: una corresponde a la IA y la otra a ti.
Practica ahora 0/3
¿Comprobado o solo aceptado?
Termina cuando hayas marcado cada elemento del caso como "comprobado" o "aceptado". Unos 8 minutos, en papel o en el bloc de notas.
Solo tienes que leer un caso. Si tienes dudas sobre un elemento, marca "aceptado": si hay dudas, no se comprobó.
El caso. Rafael le pidió a la IA una página de precios. Respondió: "Página creada, aparecen los tres planes, el botón lleva al pago y el texto fue revisado". Rafael abrió la página y vio los tres planes. No hizo clic en el botón. No leyó el texto. Le envió el enlace al cliente.
Ver respuestas
Tres planes: comprobado, los vio. Botón: aceptado, nadie hizo clic. Texto revisado: aceptado, nadie lo leyó. En un minuto: hacer clic en el botón y comprobar si abre el pago correcto, y leer el texto de la página para buscar un precio o nombre incorrecto.
Ya sabes separar lo que se comprobó de lo que solo se dijo.
Resumen de bolsillo
Comprobar
El resumen de la IAes una declaración, no una prueba.
Tres comprobacionescriterio escrito antes, resultado abierto, segunda mirada.
Decisiónentregar o no siempre depende de ti.
Tu próximo paso
Ya sabes separar lo que comprobaste de lo que solo aceptaste.
La próxima vez que compartas el resultado de una IA con otra persona, comprueba una afirmación abriendo el resultado real. Te tomará cinco minutos.
En la próxima lección: ¿y si otro modelo dice que todo está bien? Que dos IA estén de acuerdo todavía no es una prueba.
Lección 1 · Dev con IA v6.2 · INEMA.CLUB
Módulo 1 · Lección 2 de 5
Que dos IA estén de acuerdo no es una prueba
Puedes decir qué permite dar por terminada la revisión de un trabajo, además de la opinión de un segundo modelo.
Pedirle a otro modelo que revise es un buen paso. El riesgo es detenerte ahí: "el otro también lo aprobó, entonces está bien". Dos calculadoras con el mismo número incorrecto ingresado dan el mismo resultado incorrecto.
En 1 minuto
Un modelo diferente encuentra errores que el autor no ve.
Pero ambos pueden equivocarse juntos si leyeron lo mismo de forma incorrecta.
Lo que permite darlo por terminado: criterio de aceptación, prueba con el resultado real y tu decisión.
1Quien lo escribió tiende a aprobar lo que escribió
Cuando le pides al mismo modelo, en la misma conversación, que revise su propio trabajo, suele estar de acuerdo consigo mismo. Un modelo diferente, o una conversación nueva, lo mira con menos apego.
¿Solo tienes un asistente? Abre una conversación nueva con él: ya tendrás una mirada con menos apego. Otro modelo es aún mejor. El curso llama a esto revisión cruzada: uno lo hace, el otro lo comprueba.
Rafael le pidió a Claude el plan de un área de acceso con contraseña para el sitio web de la clínica. Después le pidió a Codex que leyera el mismo plan y señalara errores.
Revisión del plan
RafaelRevisa el plan que acabas de escribir.
ClaudeEl plan está completo y cubre los requisitos. No veo que sea necesario hacer ajustes.
Quien lo escribió, en la misma conversación, confirmó su propio plan.
RafaelLee el plan de abajo y señala errores, junto con el fragmento que muestra cada uno.
CodexError 1: el plan no dice qué pasa cuando la persona se equivoca de contraseña varias veces. Dónde: la parte "Entrada" del plan solo enumera correo electrónico, contraseña y el botón para entrar.
Una mirada externa encontró un caso que el autor no había previsto.
Toca o haz clic en los dos botones del recuadro y compara las dos revisiones.
2Ambos pueden equivocarse juntos
La revisión cruzada encuentra errores. No garantiza que no quede ninguno. Si ambos modelos leyeron mal el mismo dato, ambos estarán de acuerdo con el error.
Carla le pidió a un modelo la fórmula del tiempo promedio de transporte, desde la salida del almacén hasta la entrega. El segundo modelo la revisó y aprobó. Los dos contaron desde la fecha del pedido, y no desde la fecha de salida del almacén.
Dos lo aprobaron
Lo que Carla tenía: la fórmula y el «está correcta» de los dos modelos.
Lo que pasó: el tiempo de transporte resultó dos días mayor que el real.
Lo comprobó en la realidad
Lo que hizo Carla: calculó a mano tres pedidos y los comparó con la fórmula.
Lo que pasó: la diferencia apareció en el primer pedido.
Balance: tres cálculos a mano detectaron lo que dos revisiones dejaron pasar.
Si te trabaste aquí, es normalEntonces, ¿la revisión no sirve? Sí sirve, y mucho. Solo que no es la última palabra. Piensa en ella como otro par de ojos, no como el sello final.
3Lo que cierra la verificación
Tres cosas cierran el ciclo, y ninguna es la opinión de un modelo. El criterio de aceptación escrito de antemano. La prueba con el resultado real. Tu decisión.
En el área de acceso de la clínica, el criterio de Rafael era «después de cinco contraseñas incorrectas, aparece el aviso de esperar diez minutos». Lo probó escribiendo mal la contraseña cinco veces.
Lo que cierra el ciclo
1 Criterio de aceptación, escrito antes del trabajo
2 Prueba con el resultado real, hecha por alguien
3 Decisión humana: se acepta o no
1Dice qué comprobar.
2Muestra si pasó.
3Asume la responsabilidad.
Ponte a prueba
Claude escribió, Codex revisó y aprobó. ¿Qué falta antes de entregar?
4El revisor recibe el original, no un resumen
Para que la revisión sirva, el segundo modelo recibe el mismo briefing y el trabajo real: el archivo, el plan, la hoja de cálculo. Nunca un resumen de lo que el primero dijo que hizo.
Carla empezó a pegar el pedido original y adjuntar la hoja de cálculo con el clip del chat. Antes, pegaba solo la respuesta de la primera IA. En un asistente de código, basta con mencionar el archivo por su nombre.
Resumen
«El otro modelo dijo que la fórmula está bien. Compruébala».
Original
El pedido inicial, la hoja de cálculo y la fórmula, con: «señala los errores e indica el fragmento que muestra cada uno».
Con el resumen, el revisor comprueba una frase. Con el original, comprueba el trabajo.
Practica ahora 0/3
¿Qué falta todavía?
Listo cuando hayas respondido las tres preguntas del caso. Unos 8 minutos, en papel o en el bloc de notas.
Solo tienes que leer un caso. Si dos respuestas parecen correctas, elige la que incluye una prueba con el resultado real.
El caso. Carla le pidió a Claude una rutina que junta las hojas de cálculo de entregas de la semana. Pegó la respuesta en Codex y preguntó «¿está bien?». Codex respondió «sí, parece correcto». Carla envió el informe a la dirección.
Ver respuestas
1. Solo la respuesta de Claude, sin las hojas de cálculo y sin el pedido original: faltó el material para verificar. 2. Algo como «el total de pedidos del informe es igual a la suma de las hojas de cálculo de la semana». 3. Sumar la columna de pedidos de las hojas de cálculo y comparar con el total del informe.
Ya sabes qué falta cuando «los dos estuvieron de acuerdo».
Resumen de bolsillo
Revisión cruzada
Otra miradaun modelo diferente o una conversación nueva encuentra lo que el autor no ve.
No es una pruebados modelos pueden equivocarse juntos.
Quién cierrael criterio, la prueba en la realidad y tu decisión.
Tu próximo paso
Ya sabes usar un segundo modelo sin tratarlo como un sello final.
La próxima vez que pidas una revisión, envía el original y pide «fallas con el fragmento que muestra cada una». Te lleva dos minutos más.
En la próxima lección: si el criterio de aceptación cierra el ciclo, ¿cómo escribir uno que funcione?
Material complementario · De dónde viene esta lecciónProfundización del tema. No cuenta dentro del tiempo de la lección.
Qué dicen las fuentes
La síntesis de INEMA del 27 de septiembre de 2026 lo resume así: la revisión cruzada ayuda a revelar problemas, pero el acuerdo entre modelos no demuestra que el sistema funcione. Los criterios de aceptación, las pruebas y la verificación humana cierran el ciclo.
El kit Use Both, resumido en el área Codex + Claude de Eventos INEMA, dice lo mismo en el nivel 1: una IA escribe el plan, la otra critica el mismo archivo, solo leyendo, con hallazgos respaldados por evidencia y su gravedad, en un máximo de dos rondas. «Que dos IA estén de acuerdo no es una prueba independiente».
Por qué falla la autorrevisión
Según Mark Kashef, autor del video que acompaña el kit, el modelo que escribió el plan, más aún en la misma sesión, tiende a aprobarlo. Un modelo diferente o una sesión nueva da otro resultado. Es un relato del autor, sin medición publicada.
Puedes escribir tres criterios de aceptación que se comprueban con sí o no para una tarea real tuya.
Sin un criterio escrito de antemano, «listo» se convierte en lo que la IA considere que está listo. Entonces, la verificación depende de la memoria y del estado de ánimo. Con el criterio, cualquier persona lo verifica de la misma manera.
En 1 minuto
Un deseo es «bonito y funciona». Un criterio es «llega el mensaje de prueba».
Un buen criterio se responde con sí o no, por alguien que no hizo el trabajo.
El criterio va dentro del pedido, junto con lo que no puede cambiar.
1El deseo no se verifica; el criterio sí
El criterio de aceptación convierte un deseo en algo que se puede revisar. «Fácil de encontrar» se convierte en «el enlace Contacto aparece en el menú de todas las páginas».
Rafael reescribió el pedido del formulario de la clínica. Quitó «bonito» y «funcionando». Agregó tres frases que puede comprobar.
Deseo
«Un formulario de contacto bonito y funcionando».
Criterio
1. El mensaje de prueba llega a la bandeja de recepción. 2. El campo de teléfono no acepta letras. 3. En el celular, la página no se desplaza hacia los lados.
Balance: tres cosas que cualquiera puede comprobar en cinco minutos.
2La prueba de sí o no
Lee cada criterio y pregúntate: ¿alguien que no hizo el trabajo puede responder sí o no? Si la respuesta es «depende», el criterio todavía es un deseo.
Carla escribió «informe claro». No pasó la prueba. Lo cambió por «cada ciudad aparece una vez, con el total de pedidos de la semana».
Ficha de Carla · informe semanal
1 El total de pedidos es igual a la suma de las hojas de cálculo de la semana
2 Cada ciudad aparece una vez, con su total
3 Debajo de cada tabla, el nombre de la hoja de cálculo de donde provino
1Se comprueba con una suma.
2Se comprueba leyendo la lista de ciudades.
3Se comprueba leyendo la línea debajo de cada tabla.
Si te trabaste aquí, es normal¿No se te ocurre ningún criterio? Piensa en cómo puede salir mal el trabajo cuando lo usa el cliente. Cada posible error, convertido en lo contrario, es un criterio.
3El criterio va dentro del pedido
Escribir el criterio solo para ti ayuda. Ponerlo en el pedido ayuda más: la IA empieza a trabajar para cumplirlo. Y le pides que diga cómo va a comprobar cada uno.
Rafael pegó los tres criterios al final del pedido. La respuesta empezó a indicar cómo comprobar cada uno, en vez de solo decir «probado».
Asistente de código
RafaelCrea el formulario de contacto de la clínica.
Criterios de aceptación:
1. El mensaje de prueba llega a la bandeja de recepción.
2. El campo de teléfono no acepta letras.
3. En el celular, la página no se desplaza hacia los lados.
Al final, di cómo comprobar cada criterio.
IAFormulario creado. Para comprobarlo:
1. Envía un mensaje de prueba y revisa la bandeja de recepción.
2. Escribe letras en el teléfono: el envío debe bloquearse.
3. Abre la página en el celular e intenta desplazarte hacia los lados.
La IA devuelve una guía de comprobación, no un «funcionando».
CarlaJunta las hojas de cálculo de entregas de la semana en un informe nuevo.
Criterios de aceptación:
1. El total de pedidos es igual a la suma de las hojas de cálculo.
2. Cada ciudad aparece una vez, con su total.
3. Debajo de cada tabla, el nombre de la hoja de cálculo de donde provino.
Al final, di cómo comprobar cada criterio.
IAInforme creado. Para revisarlo:
1. Suma la columna de pedidos de las hojas de cálculo y compárala con el total del informe.
2. Lee la lista de ciudades y busca nombres repetidos.
3. Comprueba que cada tabla tenga debajo el nombre de la hoja de cálculo.
La misma forma de pedir sirve para un informe.
Toca o haz clic en los dos botones del cuadro. La guía es para que la ejecutes; no sustituye la revisión.
4Di también qué no se puede cambiar
Un buen pedido incluye la parte externa: lo que la IA no debe tocar. Sin eso, “mejora” cosas que nadie pidió y la revisión se hace más larga.
Carla agregó: “no cambies las hojas de cálculo originales; guarda el informe en un archivo nuevo”. Ya no necesita comprobar si cambiaron los datos de origen.
Dentro
Generar el informe semanal en un archivo nuevo, con los tres criterios.
Fuera
No cambiar las hojas de cálculo originales. No cambiar el formato del informe.
“Dentro” y “Fuera” van en el mismo pedido. “Fuera” reduce lo que tienes que revisar.
Practica ahora 0/3
Tres criterios para una tarea tuya
Listo cuando tengas tres criterios que pasen la prueba de sí o no y una línea sobre lo que queda fuera. Unos 10 minutos, en papel o en el bloc de notas.
Solo escribes; no se envía nada a nadie. Si no tienes una tarea de código, usa una de texto o de hoja de cálculo: el criterio funciona igual.
Tarea: <lo que le vas a pedir a la IA>
Criterios de aceptación:
1. <algo que se comprueba con sí o no>
2. <otro>
3. <otro>
Fuera: <lo que la IA no debe tocar>
Ejemplo de Carla:
Tarea: informe semanal de entregas
1. Total de pedidos igual a la suma de las hojas de cálculo de la semana
2. Cada ciudad aparece una vez, con su total
3. Debajo de cada tabla, el nombre de la hoja de cálculo de donde salió
Fuera: no cambiar las hojas de cálculo originales
Ya conviertes un deseo en criterios que otra persona puede comprobar.
Resumen de bolsillo
Criterio de aceptación
Antesescribe el criterio antes de pedir el trabajo.
Sí o noquien no hizo el trabajo debe poder responder.
En el pedidopega los criterios y lo que queda fuera.
Tu próximo paso
Ya escribes qué significa “listo” antes de empezar.
Usa los tres criterios de la práctica en tu próximo pedido real. Pégalos al final y pide la guía de revisión.
En la próxima lección: un criterio sin límite se convierte en trabajo sin fin. ¿Cómo poner un límite de verdad?
Lección 3 · Dev con IA v6.2 · INEMA.CLUB
Módulo 1 · Lección 4 de 5
“Detente en dos horas” es un pedido, no un límite
Puedes cambiar un límite vago por tres límites que se pueden comprobar: intentos, archivos y tiempo o gasto.
Una tarea larga con IA consume tiempo y uso de tu cuenta. Una frase como “detente en dos horas” parece un límite, pero la IA puede no cumplirla. El límite que te protege es el que alguien o algo comprueba.
En 1 minuto
Una frase en el pedido es un pedido. Un límite es lo que detiene el trabajo aunque la IA no quiera.
Tres límites comprobables: intentos, archivos y tiempo o gasto.
Cuando llega al límite, la IA se detiene y describe el bloqueo. No insiste.
1Una frase en el pedido no es un límite
La IA lee "detente en dos horas" como cualquier otra frase. Puede que no tenga un reloj a mano y piense que falta poco. La frase ayuda, pero no garantiza nada.
El riesgo aumenta en el modo automático, en el que el asistente aprueba sus propias acciones y sigue sin pedirte confirmación. Cada paso consume el uso de tu cuenta.
Rafael dejó al asistente en modo automático corrigiendo el formulario, "en un máximo de una hora". Volvió del almuerzo y el asistente iba por el décimo intento.
Pedido
"Corrige el envío del formulario. Detente en una hora."
Qué pasó: hizo diez intentos y el trabajo continuó después de la hora.
Límite y restricción
En el pedido: "como máximo dos intentos, solo el archivo del formulario". Fuera del pedido: se quedó cerca, con una alarma de 30 minutos.
Qué pasó: se detuvo en el segundo intento y describió lo que faltaba.
2Tres límites que puedes comprobar
Cada límite responde a una pregunta que puedes revisar después. ¿Cuántos intentos hizo? ¿Qué archivos cambió? ¿Cuánto tiempo o uso consumió? Un intento es cada vez que la IA dice que probará de otra manera.
Carla le pidió a la IA que trabajara en una carpeta de copias. Después abrió la carpeta de las hojas de cálculo originales en el modo Detalles (en Mac, Lista) y revisó la columna "Fecha de modificación": ninguna fecha de hoy.
Límites de la tarea
1 Intentos: como máximo 2
2 Archivos: solo los que indica el pedido
3 Tiempo o gasto: una restricción fuera de la IA
1Compruébalo contando en la conversación cuántas veces la IA dijo que probaría de otra manera.
2Compruébalo en la columna "Fecha de modificación" de la carpeta.
3Compruébalo en el reloj y en la página de uso de la cuenta.
3La restricción está fuera de la IA
El límite en el pedido lo compruebas después. La restricción detiene el trabajo en el momento. Para el tiempo, si estás cerca, basta con una alarma: cuando suene, haz clic en el botón para detener del asistente (un cuadrado, en la app y la extensión) o presiona Esc en el terminal.
Para el gasto, entra al sitio donde te suscribiste, abre la configuración de la cuenta y busca "Uso" (en inglés, "Usage"). Ahí puedes medirlo. Solo hay una restricción de gasto cuando la cuenta permite fijar un tope, algo común en las cuentas de pago por consumo.
Carla encontró la página de uso de su cuenta y anotó cuánto consumía una tarea de informe. Así supo cuántas podía hacer por semana.
Restricción de tiempo
Alarma de 30 minutos. Cuando suene: haz clic en el botón para detener y pide un informe de lo que se hizo.
Medición del gasto
Página de uso de la cuenta, abierta antes y después de la tarea. Tope de gasto, si la cuenta lo ofrece.
La alarma depende de que estés cerca. Para detener el trabajo sin que estés, solo sirve la restricción automática del recuadro siguiente.Restricción automática, para quienes usan el terminal
En el terminal de Linux, el comando timeout cierra otro programa cuando se acaba el tiempo. En Mac, viene con el paquete coreutils (brew install coreutils) y se llama gtimeout.
Terminal · Linux
$ timeout 30m claude -p "Corrija o envio do formulário. No máximo 2 tentativas. Altere só contato.html."
...$ echo $?
124
124 quiere decir que se acabó el tiempo y el programa se cerró. Otro número es la respuesta del propio programa: cero si terminó bien.
Con Codex, cambia claude -p por codex exec. Cerrar a mitad del proceso puede dejar un archivo incompleto: revisa qué cambió antes de seguir.
Si te trabaste aquí, es normal¿No encontraste la página de uso de tu cuenta? Empieza solo por la alarma. Después, busca la página de uso con calma, una sola vez.
4Llegaste al límite: detenerse y describir el bloqueo
El límite solo funciona si dices qué hacer cuando se alcanza. Pide: detente, describe qué intentaste, qué falló y qué necesitarías para seguir.
Carla recibió un aviso claro después de dos intentos: una hoja de cálculo tenía las columnas en otro orden. Arregló la hoja de cálculo en dos minutos.
Asistente de código
CarlaJunta las hojas de cálculo de la carpeta "entregas-copia". Como máximo 2 intentos. Si no se puede, detente y dime qué intentaste, qué falló y qué falta.
IAMe detuve después de 2 intentos. Intenté juntar las hojas de cálculo según el orden de las columnas. Falló: una de las hojas de cálculo tiene la columna "cidade" en otra posición. Falta: que me digas si puedo reordenar las columnas de esa hoja de cálculo en la copia.
Un bloqueo descrito vale más que un décimo intento.
La carpeta "entregas-copia" es una copia que Carla hizo antes: clic derecho en la carpeta original › Copiar y Pegar al lado.
Practica ahora 0/3
Pon tres límites en tu pedido
Listo cuando tu pedido tenga un límite de intentos, una lista de archivos, una instrucción para detenerse y la alarma acordada. Unos 10 minutos, en el bloc de notas.
Solo escribe el pedido; no hace falta que lo envíes ahora. ¿No hiciste la lección 3? Usa cualquier tarea que le pedirías a la IA esta semana.
<tu pedido, con los criterios de aceptación>
Límites:
- Como máximo 2 intentos.
- Cambia solo: <archivo o carpeta>.
- Si se alcanza un límite, detente y di qué intentaste, qué falló y qué falta.
Ya conviertes "no te demores" en límites que se pueden comprobar.
Resumen de bolsillo
Límites de verdad
Un pedido no es un bloqueola frase ayuda, pero no detiene nada.
Tres límitesintentos, archivos y tiempo o gasto.
Detenerseal llegar al límite, la IA describe el bloqueo.
Tu próximo paso
Ya sabes poner un bloqueo que funciona incluso si la IA no está de acuerdo.
Entra al sitio de tu asistente de IA, busca la página de uso de la cuenta y guarda el enlace en favoritos. Toma cinco minutos.
En la próxima lección: juntar tarea, criterio y límites en un solo archivo y ver el ciclo completo.
Material complementario · Objetivo con condición de paradaProfundización del tema. No cuenta para el tiempo de la lección.
De dónde viene esta lección
El kit Use Both, una guía abierta para usar Claude y Codex juntos, llama a esto "objetivo con condición de parada": un objetivo con éxito observable (qué pruebas, qué resultado) y límites de archivos, intentos y gasto. Pedir "detente en dos horas" es un pedido, no un límite garantizado.
En el video que acompaña el kit, el autor, Mark Kashef, cuenta que el modo de metas de Codex (en el que persigue un objetivo por su cuenta) tarda de 3 a 5 veces más y consume más tokens. Es un relato suyo, sin mediciones publicadas.
Qué recomienda la síntesis de INEMA
Define límites verificables para las tareas largas. Comprueba los precios, las cuotas y las herramientas disponibles en tu cuenta antes de usar recursos de pago. Los precios y los límites cambian; lo que vale es lo que muestra tu cuenta ese día.
El ciclo en cinco pasos y el briefing de tu piloto
Puedes preparar el briefing de tu piloto: objetivo, qué queda dentro y fuera, criterios de aceptación y límites, en un solo archivo.
En las lecciones anteriores viste las piezas por separado: comprobar, revisión cruzada, criterios y límites. Por separado, se pierden entre un pedido y otro. Juntas en un archivo, se convierten en el comienzo de un método que cualquier modelo sigue.
En 1 minuto
El ciclo: definir, planificar y criticar, construir y revisar, comprobar, registrar.
Todo empieza en un archivo: el briefing, que leen los dos modelos.
El piloto es una tarea pequeña, de una o dos horas, no el sistema completo.
1El ciclo completo en una ficha
Este curso sigue cinco pasos, uno por módulo. El primero ya lo practicaste: definir la tarea. Los demás vienen en los próximos módulos.
El último paso es el handoff: un registro para que la próxima conversación continúe sin que tengas que volver a explicarlo todo.
Rafael pegó los cinco pasos en la pared de la oficina. Toda tarea con IA para un cliente pasa por ellos.
El ciclo del curso
1 Definir: objetivo, dentro y fuera, criterios, límites
2 Planificar y criticar: uno escribe el plan, el otro lo cuestiona
3 Construir y revisar: uno lo hace, el otro lee lo que cambió
4 Comprobar: pruebas, resultado real, tu decisión
5 Registrar: handoff para la próxima conversación
1Módulo 1, este.
2Módulo 2.
3Módulo 3.
4Módulo 4.
5Módulo 5. El módulo 6 mide el costo de todo.
2Quién hace qué es una ruta inicial
Un punto de partida común: Claude escribe el plan y Codex lo critica. Después, uno construye y el otro revisa. Esa es una ruta para empezar, no una clasificación de qué modelo es mejor.
¿Solo tienes un asistente? Empieza con él haciendo el trabajo y, en una conversación nueva, pídele que lo critique. El método es el mismo.
Carla tiene Codex y un chat de IA. Usa Codex para hacer el trabajo y el chat, en una conversación nueva, para criticarlo.
Ruta inicial
Plan: Claude escribe, Codex critica. Construcción: uno hace el trabajo y el otro revisa lo que cambió.
Qué decide
La calidad de la entrega en tu tarea. Los modelos, el acceso y los cobros cambian de una cuenta a otra.
Empieza por la ruta inicial y quédate con la que dé mejores resultados en tu tarea.
3El briefing es el archivo que todos leen
El briefing reúne en un archivo de texto lo que escribiste en las lecciones 3 y 4. Los dos modelos reciben el mismo archivo. Así, nadie trabaja con un resumen.
La extensión .md quiere decir texto simple en formato Markdown: los # marcan los títulos. Los asistentes leen bien este formato.
Rafael guarda el briefing.md en la carpeta del proyecto del cliente. En Claude Code y Codex, escribe @ en el pedido y elige el archivo. En un chat, pega el texto.
briefing.md · formulario de la clínica
1 Objetivo: los pacientes envían mensajes por el sitio
2 Dentro: página de contacto · Fuera: página de inicio y colores
3 Aceptación: el mensaje llega a recepción; el teléfono rechaza letras; se abre en el celular
4 Límites: 2 intentos; solo contacto.html; alarma de 30 minutos cada vez que trabaja la IA
1Una frase: para qué sirve.
2Qué puede cambiar y qué no.
3Los criterios de la lección 3.
4Los límites de la lección 4.
4El piloto: una tarea pequeña y real
Todo el curso gira en torno a un piloto tuyo. Elige una tarea real y pequeña que puedas hacer en una o dos horas de tu trabajo. Si es demasiado grande, el ciclo se pierde. Si es ficticia, nadie la verifica de verdad.
Carla eligió la rutina que reúne las hojas de cálculo de entregas de la semana. Es pequeña, la hace todas las semanas y sabe decir cuándo está correcta.
Demasiado grande
"Automatizar todos los informes de la empresa."
Buen piloto
"Reunir las hojas de cálculo de entregas de la semana en un informe, verificado contra la suma."
Si te trabaste aquí, es normal¿Ninguna tarea te parece lo bastante pequeña? Toma una parte de una grande: solo una página, solo un informe, solo una fórmula.
Practica ahora 0/4
Escribe el briefing de tu piloto
Está listo cuando el archivo briefing.md tenga las cuatro partes completas. Unos 12 minutos, en la computadora.
Es un archivo de texto tuyo; no se envía nada. Si no sabes qué límite poner, escribe "por definir" y vuelve a la lección 4. ¿No tienes una computadora ahora? Escribe en la app de notas del celular y crea el archivo después.
# Instrucciones: <nombre del piloto>
## Objetivo
<una frase: para qué sirve>
## Dentro y fuera
Dentro: <qué puede cambiar>
Fuera: <qué no puede cambiar>
## Criterios de aceptación
1. <sí o no>
2. <sí o no>
3. <sí o no>
## Límites
- Intentos: <máximo 2>
- Archivos: <cuáles>
- Tiempo o gasto: <dónde está el límite>
Crear el archivo en Windows
1 Carpeta del piloto
2 Ver › Mostrar › Extensiones de nombre de archivo
3 Clic derecho › Nuevo › Documento de texto
4 briefing.md
1Abre la carpeta que creaste para el piloto.
2Activa las extensiones. En Windows 10: pestaña Ver, marca Extensiones de nombre de archivo.
3Haz clic derecho en un espacio vacío de la carpeta.
4Cámbiale el nombre a briefing.md y confirma. Para abrirlo: clic derecho › Abrir con › Bloc de notas.
En Mac: TextEdit › Formato › Convertir en texto sin formato, pega la plantilla y guárdala como briefing.md; si te pregunta, elige "Usar .md". ¿Tuviste problemas con la extensión? briefing.txt también sirve.
Ya tienes el briefing que los dos modelos leerán en el módulo 2.
Resumen de bolsillo
Ciclo y briefing
Cinco pasosdefinir, planificar y criticar, construir y revisar, comprobar, registrar.
Briefingun archivo con el objetivo, lo que está dentro y fuera del alcance, los criterios y los límites.
Pilotouna tarea real y pequeña que sabes cómo comprobar.
Tu próximo paso
Terminaste el módulo 1 con el briefing de tu piloto listo.
Vuelve a leer el briefing mañana, con la mente descansada. Corrige un criterio que todavía dependa de una opinión.
En el módulo 2: un modelo escribe el plan a partir de tu briefing y el otro intenta echarlo abajo.
Lección 5 · Dev con IA v6.2 · INEMA.CLUB
Módulo 2 · Lección 1 de 5
El plan vive en un archivo, no en la conversación
Puedes pedirle a la IA un plan-v1.md con el alcance, las suposiciones, los criterios de aceptación y los riesgos, sin que todavía cambie nada.
Cuando el plan queda en medio de la conversación, se mezcla con preguntas, correcciones y código. Nadie logra criticarlo completo. En un archivo, el plan se convierte en algo que otra IA y tú pueden leer de principio a fin.
En 1 minuto
Pide el plan en un archivo: plan-v1.md, en la carpeta del piloto.
Cuatro partes: alcance, suposiciones, criterios de aceptación y riesgos.
Escribe "no implementes nada todavía". Criticar un plan cuesta menos que deshacer código.
1El plan en la conversación se pierde; el plan en un archivo permanece
El plan es lo primero que escribe la IA. Si queda solo en la conversación, desaparece cuando desplazas la pantalla. En un archivo, queda en la carpeta, con nombre y versión.
Así el segundo modelo lee exactamente el mismo texto que tú leíste.
Rafael pidió el plan del formulario de la clínica. La primera vez, apareció en la conversación, mezclado con código. La segunda, pidió un archivo.
Asistente de código
RafaelPlanea el formulario de contacto de la clínica.
IAClaro. Primero voy a crear el formulario. Ya creé el archivo contato.html con los campos. Después…
El plan se convirtió en trabajo en medio de la respuesta. No quedó nada para criticar.
RafaelLee briefing.md. Escribe el plan en plan-v1.md, con alcance, suposiciones, criterios de aceptación y riesgos. Todavía no implementes nada.
IAGuardé plan-v1.md en la carpeta del piloto. No modifiqué ningún otro archivo.
Un archivo que cualquier persona, u otra IA, puede leer completo.
Toca o haz clic en los dos botones del cuadro y compara los dos pedidos.
2Las cuatro partes de un plan
Un plan que se puede criticar tiene cuatro partes. Alcance: lo que incluye y lo que queda fuera. Suposiciones: lo que la IA da por sentado. Criterios de aceptación: cómo comprobarlo. Riesgos: lo que puede salir mal.
Los criterios de aceptación vienen de tu briefing. El plan dice cómo se probará cada uno.
En plan-v1.md de Rafael, la parte de riesgos advirtió: el alojamiento de la clínica puede bloquear el envío de correo electrónico.
plan-v1.md · formulario de la clínica
1 Alcance: página de contacto con nombre, "campo de teléfono, texto libre" y mensaje; "enviar al correo electrónico de recepción". Fuera: página de inicio y colores
2 Suposiciones: recepción usa un solo correo electrónico
3 Criterios de aceptación: los 3 del briefing, cada uno con su prueba
4 Riesgos: el alojamiento puede bloquear el envío de correo electrónico
1Lo que incluye y lo que queda fuera.
2Lo que la IA dio por sentado.
3Cómo se comprobará cada criterio.
4Lo que puede salir mal.
3"Todavía no implementes nada"
A los asistentes de código les gusta empezar enseguida. Sin la frase "todavía no implementes nada", el plan se convierte en trabajo. Y deshacer un trabajo equivocado cuesta más que corregir un plan equivocado.
La frase es un pedido. En Claude Code hay un bloqueo real: el modo de planificación, que impide editar archivos. Presiona Shift+Tab hasta que aparezca; el plan vuelve a la conversación y tú mismo lo guardas en plan-v1.md.
Carla pidió el plan de la rutina de las hojas de cálculo y olvidó la frase. El asistente ya creó tres archivos nuevos en la carpeta. Tuvo que borrar todo y pedirlo de nuevo.
Sin la frase
Pedido: "Planifica la rutina de las hojas de cálculo."
Resultado: tres archivos creados antes de que alguien leyera el plan.
Con la frase
Pedido: "Escribe el plan en plan-v1.md. No implementes nada todavía."
Resultado: un solo archivo, para leer en cinco minutos.
4Una suposición escrita es un error que se puede encontrar
La parte de las suposiciones es la más valiosa. Los errores suelen esconderse en lo que nadie escribió. Cuando la IA escribe lo que dio por cierto, tú y quien revisa pueden discrepar.
En el plan-v1.md de Carla apareció: "todas las hojas de cálculo tienen las mismas columnas, en el mismo orden". Ella sabía que eso no era cierto para una ciudad. El error apareció antes de cualquier intento.
Suposición oculta
El plan indica "unir las hojas de cálculo según el orden de las columnas". Nadie se da cuenta de lo que eso supone.
Suposición escrita
"Supongo que todas las hojas de cálculo tienen las mismas columnas, en el mismo orden". Carla lo lee y lo corrige de inmediato.
Si te trabaste aquí, es normal¿El plan quedó demasiado largo? Pide: "resúmelo en una página, manteniendo las cuatro partes". Un plan corto es más fácil de criticar.
Practica ahora 0/3
Pide el plan-v1.md de tu piloto
Está listo cuando haya un plan-v1.md en la carpeta del piloto con las cuatro partes y ningún otro archivo nuevo. Unos 10 minutos, en la computadora.
El pedido dice que no implementes nada. Si el asistente crea otros archivos de todos modos, interrúmpelo (tecla Esc en Claude Code; botón para detener en la app) y borra solo lo que creó. ¿No hiciste la lección 5? Escribe tres líneas de briefing en el mismo pedido.
Lee briefing.md. Escribe el plan en plan-v1.md, en la misma carpeta.
Incluye cuatro partes: alcance (dentro y fuera), suposiciones,
criterios de aceptación (cada uno con la prueba que lo verificará) y riesgos.
No implementes nada todavía. No modifiques ningún otro archivo.
Ya tienes un plan en un archivo, listo para que otra IA lo critique.
Resumen de bolsillo
Plan en un archivo
plan-v1.mdel plan queda en la carpeta del piloto, no en la conversación.
Cuatro partesalcance, suposiciones, criterios de aceptación y riesgos.
Sin hacer el trabajo"no implementes nada todavía" va en el pedido.
Tu próximo paso
Ya puedes transformar "planifica esto" en un archivo que se pueda criticar.
Lee en voz baja tu plan-v1.md, solo la parte de suposiciones. Anota una pregunta que le harías a quien lo escribió.
En la próxima lección: quién va a leer este plan sin piedad y cómo pedir una crítica que sirva.
Material complementario · De dónde viene plan-v1.mdProfundización del tema. No cuenta dentro del tiempo de la lección.
El pedido del kit Use Both
El primer flujo del kit Use Both, "planificar y después desafiar", empieza así: crear plan-v1.md para la tarea, sin implementar nada, con alcance, suposiciones, criterios de aceptación (cada uno con su prueba) y riesgos. Después, el mismo archivo pasa al otro modelo para que lo critique en modo de solo lectura. El nombre con número de versión permite guardar el plan original cuando llegue la versión revisada.
Crítica en modo de solo lectura: hallazgo con evidencia
Puedes pedirle a otra IA una crítica de tu plan en la que cada hallazgo incluya la falla, la evidencia, el impacto y la corrección más sencilla.
"Parece bueno" y "podrías considerar más casos" no ayudan a nadie. Una crítica solo sirve cuando señala el fragmento, dice qué pasa si nadie lo corrige y propone el arreglo más sencillo.
En 1 minuto
El revisor solo lee. No modifica el plan ni ningún otro archivo.
Cada hallazgo tiene cuatro campos: falla, evidencia, impacto y corrección más sencilla.
El revisor recibe el briefing y el plan real, nunca un resumen.
1El revisor solo lee
En la crítica, quieres hallazgos, no que escriban un plan nuevo encima del tuyo. Por eso el pedido dice: lee, señala, no modifiques archivos. Esa frase sigue siendo un pedido; la protección real que impide modificar archivos viene en la lección 8.
El revisor puede ser otro modelo o una conversación nueva con el mismo asistente. Es la revisión cruzada de la lección 2 aplicada al plan.
Rafael le envió a Codex el plan plan-v1.md del formulario, con el pedido de una crítica en modo de solo lectura. Recibió tres hallazgos y no se modificó ningún archivo.
Revisor
RafaelLee briefing.md y plan-v1.md. Enumera los hallazgos del plan. Para cada hallazgo: falla, fragmento del plan, impacto y la corrección más sencilla. No modifiques archivos.
CodexHallazgo 1. Falla: el plan no dice qué pasa si falla el envío. Fragmento: "enviar al correo electrónico de recepción". Impacto: el paciente ve "enviado" y el mensaje se pierde. Corrección más sencilla: mostrar un aviso de error y registrar la falla.
Un hallazgo que Rafael puede revisar y corregir sin preguntar nada.
2Los cuatro campos de un hallazgo
Una falla es lo que está mal o falta. La evidencia es el fragmento que lo muestra. El impacto es lo que pasa si nadie lo corrige. La corrección mínima es el arreglo más sencillo que lo resuelve.
Pide también un nivel de gravedad: alta, media o baja. Así sabrás por dónde empezar.
Carla pidió una crítica del plan de las hojas de cálculo en el chat de IA, en una conversación nueva. Pidió que los hallazgos estuvieran ordenados por gravedad.
review.md · hallazgo 1 del plan de Carla
1 Falla: nada contempla hojas de cálculo con las columnas en otro orden
2 Evidencia: "unir las hojas de cálculo según el orden de las columnas"
3 Impacto: los totales de una ciudad se suman en la columna equivocada
4 Corrección mínima: unir por el nombre de la columna
1Qué está mal.
2Dónde está, con las palabras del plan.
3Por qué importa.
4El arreglo más sencillo.
3Un hallazgo vago no es un hallazgo
Sin los cuatro campos, la crítica se convierte en un consejo genérico. No sabes si estás de acuerdo porque no sabes de qué se trata.
La primera crítica que recibió Rafael, sin el molde, decía "considera validar mejor los campos". Con el molde, se convirtió en un hallazgo sobre el teléfono.
Vago
"Considera validar mejor los campos del formulario."
Hallazgo
Falla: el plan no contempla teléfonos con letras. Evidencia: "campo teléfono, texto libre". Impacto: incumple el criterio 2 del briefing. Corrección mínima: aceptar solo números.
El hallazgo cita el criterio del briefing que se incumpliría.
Si te trabaste aquí, es normal¿El revisor devolvió hallazgos que parecen incorrectos? ¡Genial! No tienes que aceptarlos todos. En la lección 9, aprenderás a responder a cada uno con "aceptado", "rechazado con evidencia" o "pendiente".
4El revisor recibe el briefing y el plan
Sin el briefing, el revisor juzga el plan según su propio criterio. Con el briefing, lo juzga según lo que pediste. Envía los dos archivos, de verdad.
Carla pegó en el chat el briefing, luego el plan y solo entonces el pedido de crítica. En el asistente de código, basta con mencionar los dos archivos por su nombre.
Solo el plan
El revisor sugiere cambiar la hoja de cálculo por una base de datos. Está fuera del alcance.
Briefing y plan
El revisor señala que el plan olvidó el criterio "cada ciudad aparece una vez".
Practica ahora 0/3
Pide una crítica de tu plan-v1.md
Termina cuando tengas un review.md con al menos dos hallazgos que incluyan los cuatro campos. Unos 10 minutos, en la computadora.
El pedido es solo de lectura: ningún archivo cambia. Usa otro asistente o una conversación nueva con el mismo. ¿No hiciste la lección 6? Pide una crítica de cualquier plan que tengas en texto.
Lee briefing.md y plan-v1.md. Critica el plan solo con una lectura.
Enumera los hallazgos. Para cada uno, escribe:
- Falla:
- Evidencia (el fragmento exacto del plan):
- Impacto (lo que pasa si nadie lo corrige):
- Corrección mínima:
- Gravedad (alta, media o baja):
Ordénalos por gravedad. No modifiques ningún archivo.
Ya recibes críticas que puedes verificar, no consejos genéricos.
Resumen de bolsillo
Crítica útil
Solo lecturael revisor señala; no reescribe ni modifica archivos.
Cuatro camposfalla, evidencia, impacto y corrección mínima.
Base comúnel briefing y el plan se envían juntos al revisor.
Tu próximo paso
Ya pides críticas con evidencia, no opiniones.
Guarda la plantilla de la práctica en un archivo pedido-critica.md en la carpeta del piloto. La volverás a usar en el módulo 3.
En la próxima lección: llamar al otro modelo sin copiar y pegar, con un solo comando.
Lección 7 · Dev con IA v6.2 · INEMA.CLUB
Módulo 2 · Lección 3 de 5
Conectar Claude y Codex: tres caminos y el manual
Puedes pedirle a otro asistente que critique el plan con un comando, o hacerlo por el camino manual, y abrir el review.md que recibes.
Copiar el plan de una ventana y pegarlo en la otra funciona, pero cansa y da lugar a errores: falta un fragmento, sobra otro. Hay caminos en los que un asistente llama al otro y la respuesta se guarda directamente en un archivo.
En 1 minuto
Tres caminos automáticos: el complemento oficial, un comando que llama al otro y la revisión de un cambio publicado. Y el manual.
Con el comando, el revisor queda limitado a solo lectura y la respuesta se guarda en un archivo.
¿Sin terminal? Copiar y pegar en una conversación nueva sigue siendo una opción.
1Tres formas de conectar los dos, más la manual
Claude Code y Codex pueden comunicarse de tres formas automáticas. La primera es un plugin oficial de Codex para Claude Code. La segunda es un comando que llama al otro asistente y guarda la respuesta en un archivo.
La tercera es la revisión de un cambio publicado, que aparece en el módulo 3. Todos los caminos, incluido el manual, siguen la regla del módulo: el revisor recibe el briefing y el archivo real.
Rafael usa el segundo camino: un solo comando, ejecutado en la carpeta del piloto.
Tres caminos y el manual
1 Plugin oficial: openai/codex-plugin-cc
2 Un comando llama al otro; respuesta en review.md
3 Revisión del cambio publicado (módulo 3)
4 Manual: copiar y pegar en una conversación nueva
1Se agrega como complemento en Claude Code.
2Se ejecuta en la terminal. Requiere la CLI del otro asistente, conectada a tu cuenta.
3Sirve cuando ya hay código modificado.
4Funciona con cualquier chat.
2Codex critica el plan de Claude con un comando
En la terminal, dentro de la carpeta del piloto, el comando codex exec hace un pedido y termina. Es la CLI de Codex.
La opción --sandbox read-only pone a Codex en una sandbox de solo lectura. La opción -o guarda la última respuesta en review.md.
La carpeta del piloto de Rafael todavía no usa Git. Por eso añade --skip-git-repo-check, que Codex pide fuera de él.
Terminal · carpeta del piloto
$ codex exec --skip-git-repo-check --sandbox read-only -c model_reasoning_effort=medium -o review.md 'Leia briefing.md e plan-v1.md. Liste os achados do plano, cada um com falha, evidência, impacto e a menor correção. Não altere arquivos.'
...$ ls
briefing.md plan-v1.md review.md
ls muestra que solo apareció review.md. El plan sigue igual.
-c model_reasoning_effort=medium elige el esfuerzo medio. El módulo 6 retoma este tema.
3El camino inverso: Claude critica
Si quien escribió el plan fue Codex, Claude puede ser el revisor. El comando claude -p hace un pedido, imprime la respuesta y termina. El signo > guarda esa respuesta en un archivo.
La protección está en la opción --permission-mode plan: es el modo de planificación, en el que Claude lee los archivos, pero no modifica ninguno. Sin esa opción, “no modifiques archivos” sería solo un pedido.
Rafael invirtió los papeles en un segundo proyecto: Codex hizo el plan y Claude lo revisó.
Terminal · carpeta del piloto
$ claude -p --permission-mode plan 'Leia briefing.md e plan-v1.md. Liste os achados do plano, cada um com falha, evidência, impacto e a menor correção. Não altere arquivos.' > review-claude.md
No aparece nada en la pantalla: toda la respuesta se guardó en review-claude.md.
Para elegir el modelo y el esfuerzo, agrega --model y --effort; los nombres dependen de tu cuenta. El módulo 6 retoma este tema.
Si te trabaste aquí, es normal¿Nunca usaste la terminal? Sigue el camino manual, el punto 4 del cuadro: abre una conversación nueva, pega el briefing, el plan y el pedido de crítica de la lección 7, y guarda la respuesta como review.md. El resultado es el mismo.
4Manual o con un comando: qué cambia
El contenido de la crítica no cambia. Cambian el trabajo manual y el riesgo de pegar algo equivocado. Con el comando, el revisor lee los archivos directamente desde la carpeta.
Carla usa Codex desde la aplicación y un chat de IA. Eligió el camino manual y guardó el pedido de crítica en un archivo para pegarlo siempre igual.
Manual
Conversación nueva, pega el briefing, el plan y el pedido. Guarda la respuesta como review.md. Funciona en cualquier chat.
Por comando
Un comando en la carpeta. El revisor lee los archivos y la respuesta queda en review.md. Menos copias, menos errores al pegar.
Las dos opciones son válidas. Elige según lo que ya usas.
Practica ahora 0/3
Recibe la crítica del plan en un archivo
Listo cuando exista un review.md junto a plan-v1.md y el plan siga igual que antes. Unos 12 minutos, en la computadora.
El revisor solo lee. Si el comando da error, comprueba que estés en la carpeta del piloto y que el asistente esté conectado a tu cuenta; si no se resuelve, usa la opción manual. Para abrir la terminal en la carpeta: en Windows 11, haz clic derecho en la carpeta › Abrir en Terminal; en Mac, escribe cd y un espacio, y arrastra la carpeta a la ventana. En Windows, usa PowerShell: las comillas simples no funcionan en el Símbolo del sistema. ¿No hiciste las lecciones 5 y 6? Usa cualquier plan en texto.
codex exec --skip-git-repo-check --sandbox read-only -o review.md 'Lee briefing.md y plan-v1.md. Enumera los hallazgos del plan, cada uno con falla, evidencia, impacto y la corrección más pequeña. No alteres archivos.'
¿Solo tienes Claude Code? Usa este:
claude -p --permission-mode plan 'Lee briefing.md y plan-v1.md. Enumera los hallazgos del plan, cada uno con falla, evidencia, impacto y la corrección más pequeña. No alteres archivos.' > review.md
Ya recibes la crítica de otro asistente sin modificar el plan.
Resumen de bolsillo
Conecta los dos
codex execcon --sandbox read-only y -o review.md.
claude -pcon --permission-mode plan y > review-claude.md.
Manualconversación nueva, pega todo, guarda la respuesta.
Tu próximo paso
Ya haces que un asistente revise al otro y guardas la respuesta en un archivo.
Lee el review.md y marca junto a cada hallazgo si estás de acuerdo. Toma diez minutos.
En la próxima lección: ¿y si los dos discrepan para siempre? Cuándo detener el debate.
Material complementario · Los comandos y el pluginProfundización del tema. No cuenta dentro del tiempo de la lección.
Lo que registran las fuentes
La sección Codex + Claude de Eventos INEMA enumera tres formas de conectar los dos: el plugin oficial de Codex para Claude Code (openai/codex-plugin-cc), una CLI que llama a la otra y guarda la respuesta en un .md, y un pull request (la revisión de un cambio publicado) que el otro modelo revisa. Los dos comandos de esta lección se comprobaron en el entorno de INEMA; las opciones cambian según las versiones, así que ejecuta codex exec --help y claude --help para ver las de tu equipo.
Por qué --skip-git-repo-check
De forma predeterminada, codex exec solo se ejecuta dentro de una carpeta con control de versiones. Fuera de ella, esta opción permite ejecutarlo. En el módulo 3, la carpeta del piloto tendrá ese control y la opción dejará de ser necesaria.
Puedes responder a cada hallazgo de la crítica, decidir cuándo terminar el debate y saber cuándo vale la pena automatizarlo.
El plan y la crítica pueden ir y venir para siempre. Cada ronda consume tiempo y uso de la cuenta, y a partir de cierto punto ambos solo están de acuerdo por cansancio. Quien decide qué queda pendiente son las pruebas, no otra ronda.
En 1 minuto
Cada hallazgo recibe una respuesta: aceptado, rechazado con evidencia o pendiente.
Como máximo, dos rondas de revisión. Estar de acuerdo no es una prueba.
Lo que queda pendiente se convierte en una prueba con nombre. Si el plan es grande: claudex lo automatiza.
1Cada hallazgo recibe una respuesta
Una ronda de revisión es un ida y vuelta: llega la crítica y cada hallazgo recibe una respuesta. Aceptado: se incluye en el plan. Rechazado con evidencia: muestras por qué no. Pendiente: todavía nadie lo sabe.
Carla respondió a los tres hallazgos del plan de las hojas de cálculo. Uno aceptado, uno rechazado y uno pendiente.
review.md · respuestas de Carla
1 Unir por el nombre de la columna → aceptado
2 Cambiar la hoja de cálculo por una base de datos → rechazado: fuera del briefing
3 Hoja de cálculo con la ciudad en blanco → pendiente
1Se incluye en el plan.
2No se incluye, y la evidencia está escrita.
3Se convierte en una prueba, en el paso 3 de esta lección.
2Por qué detenerse en dos rondas
La primera ronda encuentra la mayoría de los fallos. La segunda comprueba si las correcciones quedaron bien. Después de eso, cada ronda encuentra menos y cuesta lo mismo. Y los dos modelos empiezan a estar de acuerdo, lo que la lección 2 mostró que no es una prueba.
Rafael dejó que el debate del formulario llegara hasta la quinta ronda. En las tres últimas solo cambiaron palabras de lugar.
Cinco rondas
Rondas 3, 4 y 5: ajustes de redacción. Los dos asistentes terminan «de acuerdo». Ninguna prueba con nombre.
Dos rondas
La ronda 1 encuentra fallos. La ronda 2 comprueba las correcciones. Lo que queda se convierte en una prueba antes de construir.
Ponte a prueba
Después de la segunda ronda, los dos modelos están de acuerdo en que el plan está listo. ¿Qué garantiza eso?
3Lo que queda pendiente se convierte en una prueba con nombre
Un hallazgo pendiente no se resuelve discutiendo. Se convierte en una prueba escrita en el plan, para ejecutarla cuando haya algo que probar. Así el debate termina, pero la duda no desaparece.
El hallazgo de la ciudad en blanco se convirtió en una prueba. Ejecutarla con la hoja de cálculo de Juiz de Fora, que tiene la ciudad en blanco, y comprobar dónde aparece el pedido.
Asistente
CarlaEl hallazgo 3 sigue abierto: no sé qué hacer con la ciudad en blanco. Conviértelo en una prueba para el plan, sin decidir por mí.
IAPrueba propuesta: ejecutar la rutina con una hoja de cálculo que tenga una fila con la ciudad en blanco. Comprobar si el pedido aparece en el total general y dónde se muestra. Tú decides qué es lo correcto.
La prueba indica qué comprobar. Carla sigue definiendo la regla de negocio.
4Plan grande: claudex automatiza el debate
Para un plan pequeño, bastan dos rondas hechas a mano. Para un plan grande, existe claudex, un plugin de Claude Code. Con el comando /claudex:plan --rounds 2 <tema>, Claude escribe el PLAN.md y Codex lo critica, con un revisor diferente en cada ronda. El ciclo se repite hasta la aprobación o hasta alcanzar el número de rondas. El valor predeterminado es 3; fija 2 para seguir la regla de esta lección.
Rafael usa las dos rondas manuales en el formulario. Dejó claudex para el sistema de citas de la clínica, que es mucho más grande.
Tarea pequeña
Dos rondas a mano. Lees cada hallazgo y respondes.
Plan grande
/claudex:plan --rounds 2, con el número de rondas fijado. Al final, todavía lees el plan y nombras las pruebas.
Automatizar el debate no automatiza la decisión.
Si te trabaste aquí, es normal¿No usas Claude Code? Ignora claudex por ahora. Las dos rondas manuales funcionan con cualquier asistente, incluso con una conversación nueva con el mismo.
Practica ahora 0/3
Responde los hallazgos
Terminas cuando cada hallazgo del caso tenga una respuesta y el que estaba abierto se haya convertido en una prueba. Unos 8 minutos, en papel o en el bloc de notas.
Es un caso para practicar. Si un hallazgo parece tanto aceptado como rechazado, márcalo como abierto y escribe la prueba que permitiría decidir.
El caso. El briefing de Rafael pide un formulario de contacto para la clínica, solo en la página de contacto. La crítica presentó tres hallazgos. A: "el plan no limita el tamaño del mensaje". B: "cambiar los colores de la página de inicio para destacar el contacto". C: "no está claro si recepción quiere recibir una copia de los mensajes en el celular".
Ver respuestas
A: aceptado; el límite de tamaño se incluye en el plan. B: rechazado; el briefing pone la página de inicio y los colores en "Fuera". C: abierto; se convierte en la pregunta "¿recepción quiere recibir una copia en el celular?", para que la clínica responda antes de construirlo.
Ya puedes cerrar el debate cuando cada hallazgo tenga respuesta y la duda quede registrada en una prueba.
Resumen de bolsillo
Cerrar el debate
Tres respuestasaceptado, rechazado con evidencia, abierto.
Dos rondasdespués de eso, estar de acuerdo no aporta pruebas.
Sin resolver se convierte en una prueba con nombre; plan grande, claudex.
Tu próximo paso
Ya sabes cerrar una revisión sin entrar en un debate interminable.
Escribe al lado de cada hallazgo de tu review.md: aceptado, rechazado o sin resolver. Te lleva diez minutos.
En la próxima lección: reunir las respuestas en el plan-v2.md del piloto y ver por qué «Claude planea» es solo un comienzo.
Material complementario · Reconciliar y pararProfundización del tema. No cuenta en el tiempo de la lección.
Lo que pide el kit Use Both
En el flujo «planear y luego cuestionar», el kit pide reconciliar los hallazgos como aceptados, rechazados con evidencia o sin resolver (el kit dice «no resueltos»), guardar plan-v2.md y review.md, y limitarse a dos rondas de revisión. Y recuerda: estar de acuerdo no es una prueba; nombra las pruebas o la evidencia necesarias antes de implementar.
claudex × Use Both
Según el área Codex + Claude de Eventos INEMA, ambos son complementarios. claudex es un software que automatiza el debate de un plan grande. Use Both es un método para todo lo demás: revisar cambios, definir una meta con una condición de parada, cambiar de sesión.
Ruta inicial, no clasificación, y el plan-v2.md del piloto
Puedes cerrar el plan-v2.md de tu piloto, con una respuesta para cada hallazgo y una prueba vinculada a cada criterio de aceptación.
Recibir la crítica es la mitad del camino. La otra mitad es reunir lo que se aceptó en una nueva versión. Sin perder el plan original ni olvidar lo que quedó sin resolver. Y sin convertir la ruta del kit en una verdad absoluta.
En 1 minuto
«Claude planea, Codex critica» es una ruta para empezar, no una clasificación.
El plan-v2.md es un archivo nuevo; el plan-v1.md queda guardado a su lado.
Antes de construir, cada criterio de aceptación del brief debe tener una prueba en el plan.
1La tabla de rutas es un punto de partida
El kit Use Both incluye una tabla sobre quién hace qué. Para planear: Claude escribe y Codex cuestiona las premisas. El objetivo es un plan con alcance y criterios de aceptación, cada uno con su prueba. Son preferencias iniciales registradas por el autor, no una clasificación medida de modelos.
Rafael empezó con la ruta de la tabla. En el segundo proyecto, intercambió los roles para ver qué crítica encontraba más problemas reales en su tarea.
Quién hace qué · ruta inicial
1 Planear: Claude escribe · Codex cuestiona las premisas
2 Construir: Claude construye · Codex revisa lo que cambió
3 Revisar el documento: cualquiera escribe · el otro verifica
1Este módulo.
2Módulo 3.
3Aplica a textos, informes y planes.
Quédate con la ruta que produzca mejores evidencias para tu tarea.
2Lo que decide es la evidencia de tu tarea
Los modelos, el acceso y los cobros cambian de una cuenta a otra y de un mes a otro. Por eso, la pregunta útil no es "cuál es el mejor". Es "en esta tarea, ¿qué crítica encontró fallas reales con evidencia?".
Carla comparó dos críticas del mismo plan: una de Codex y otra de una conversación nueva del chat. Contó cuántos hallazgos tenían evidencia que ella verificó.
Por la fama
"Dicen que el modelo X es el mejor para planear". Carla usaría solo ese, sin verificarlo.
Por la evidencia
Crítica 1: 3 hallazgos, 2 verificados. Crítica 2: 5 hallazgos, 1 verificado. En esta tarea, la crítica 1 sirvió más.
3El plan-v2.md es un archivo nuevo
No escribas encima de plan-v1.md. La versión nueva es un archivo hermano: plan-v2.md. Así comparas ambos y sabes qué cambió a causa de la crítica.
El plan-v2.md incluye los hallazgos aceptados, una lista de los rechazados con la evidencia y los pendientes como pruebas.
La carpeta del piloto de Rafael quedó con cuatro archivos, cada uno con una función.
Carpeta del piloto · formulario de la clínica
1 piloto-formulario
briefing.md
2 plan-v1.md
3 review.md
4 plan-v2.md
1Una carpeta por piloto.
2El plan original, guardado.
3La crítica, con tus respuestas.
4La versión que se usará para construir.
4Verifica el plan-v2.md con el briefing
Antes de construir, verifica que cada criterio de aceptación del briefing tenga una prueba en el plan. Un criterio sin prueba es un criterio que nadie va a verificar.
Rafael pidió esta verificación a una conversación nueva. Un criterio se había quedado sin prueba.
Asistente
RafaelLee briefing.md y plan-v2.md. Enumera cada criterio de aceptación del briefing y la prueba del plan que lo verifica. Señala los criterios sin prueba. No modifiques archivos.
IACriterio 1, el mensaje llega a recepción: prueba de envío real. Criterio 2, el teléfono rechaza letras: prueba de escritura. Criterio 3, se abre en el celular: ninguna prueba en el plan.
La brecha apareció antes de la primera línea de código.
Si te trabaste aquí, es normal¿Tu review.md tiene demasiados hallazgos? Lleva al plan-v2.md solo los de gravedad alta y media. Los de gravedad baja reciben la respuesta "pendiente (baja)" y se quedan en el review.md; no se incluyen en el plan-v2.md.
Practica ahora 0/4
Completa el plan-v2.md de tu piloto
Listo cuando el plan-v2.md esté en la carpeta, junto al plan-v1.md, con cada criterio de aceptación vinculado a una prueba. Unos 12 minutos, en la computadora.
El plan-v1.md no cambia: creas un archivo nuevo. ¿No hiciste las lecciones 6 a 9? Usa la plantilla con cualquier plan y crítica que tengas por escrito.
Lee briefing.md, plan-v1.md y review.md (con mis respuestas:
aceptado, rechazado o pendiente). Escribe plan-v2.md, un archivo nuevo:
- incorpora los hallazgos aceptados;
- enumera los rechazados con la evidencia;
- convierte los pendientes en pruebas con nombre.
No modifiques plan-v1.md ni review.md. No implementes nada.
Cerraste el plan del piloto: recibió críticas, tiene respuestas y una prueba para cada criterio.
Resumen de bolsillo
Plan cerrado
Ruta inicialsirve para empezar; la evidencia de la tarea es la que decide.
Criterio con pruebaningún criterio del briefing queda sin una comprobación prevista.
Tu próximo paso
Cerraste el módulo 2 con el plan del piloto revisado y listo para convertirse en trabajo.
Vuelve a leer plan-v2.md mañana y subraya el primer paso de la construcción. Solo ese.
En el módulo 3: alguien construye a partir del plan y la otra persona lee cada línea que cambió.
Material complementario · La tarjeta de rutasProfundización del tema. No cuenta en el tiempo de la lección.
De dónde viene la tabla
La tarjeta de rutas del kit Use Both, resumida en el área Codex + Claude de Eventos INEMA, presenta preferencias iniciales registradas en el video de Mark Kashef y traducidas en tareas. El propio kit dice que son elecciones editoriales, no una clasificación medida: prueba y quédate con la ruta que produzca mejor evidencia. El video menciona Claude Opus 5.5 y GPT-6 Astra; los modelos, las herramientas, los límites y los cobros cambian según la cuenta, y el flujo de trabajo es más portátil que esos nombres.
Puedes crear una rama de prueba y leer un git diff línea por línea, indicando qué salió y qué entró.
En el módulo 2 alguien criticó el plan. Ahora la IA va a modificar archivos reales. Para revisar lo que hizo, necesitas ver exactamente qué cambió, no lo que dice que cambió.
En 1 minuto
Git guarda versiones de los archivos de una carpeta y muestra la diferencia entre ellas.
Una rama separa la prueba: haces cambios en ella sin estropear la versión que funciona.
En git diff, la línea con − salió y la línea con + entró.
1Git muestra qué cambió, no lo que se dijo
Git guarda versiones de los archivos de una carpeta. Con él, comparas la versión anterior con la actual, línea por línea.
Para revisar trabajo de IA, esto es lo que importa. El resumen dice "cambié el formulario". La diferencia muestra qué líneas cambiaron y en qué archivos.
Rafael pidió corregir el campo de teléfono del sitio de la clínica. El resumen mencionaba un archivo. La diferencia mostró dos: la IA también había modificado el pie de página.
Sin Git
Pregunta: "¿qué cambiaste?"
Respuesta: el resumen de la IA, con su memoria.
Con Git
Pregunta: "¿qué cambió?"
Respuesta: Git enumera los archivos que cambiaron, incluidos los nuevos, y muestra las líneas.
Balance: Rafael encontró el cambio en el pie de página, que nadie había pedido.
2Un branch es una línea de prueba
Antes de que la IA haga cambios, crea un branch. Si el cambio no sirve, la versión que funciona sigue intacta.
En el terminal, dentro de la carpeta del proyecto, un comando crea el branch y te cambia a él. git status confirma dónde estás.
Rafael creó el branch formulario-contato antes de pedirle nada a la IA. La versión publicada del sitio quedó en el branch principal.
Terminal · carpeta del sitio
$ git switch -c formulario-contato
Switched to a new branch 'formulario-contato'$ git status
On branch formulario-contato
nothing to commit, working tree clean
"Switched to a new branch" = branch creado y ya estás en él. "nothing to commit" = todavía no cambió nada.
Git responde en inglés. Lee solo el comienzo de cada línea.
3Lee el diff: − salió, + entró
Después de que la IA trabaje, ejecuta primero git status: enumera todos los archivos que cambiaron, incluidos los nuevos. Un archivo nuevo no aparece en git diff hasta que usas git add, que se muestra en la lección 13.
Luego, git diff muestra el diff. Cada archivo modificado aparece con su nombre. Una línea que empieza con − salió; una línea con + entró. Las demás son contexto, no cambiaron.
En el diff de Rafael, salió una línea del campo de teléfono y otra entró en su lugar. Leyó ambas y vio la nueva regla: solo números, espacios, paréntesis y guiones.
Las primeras cinco líneas indican qué archivo y en qué sección. Después, − la línea anterior y + la nueva. Un diff largo se abre página por página: Espacio avanza, q sale.
Lee primero los nombres de archivo: un archivo ajeno a lo pedido es la primera señal de un problema.
Ponte a prueba
En el diff, una línea empieza con −. ¿Qué significa?
4Sin terminal: pídele el diff al asistente
Si usas el asistente desde la app, no necesitas abrir el terminal. Pídele que muestre el diff completo de los cambios. El asistente ejecuta el comando y pega el resultado.
Carla usa Codex desde la app. Después de cada pedido, escribe: "muestra el git diff completo". Así ve las líneas y no solo la frase "cambié el juntar.py".
Una hoja de cálculo .xlsx es diferente: en el diff solo aparece como "Binary files differ", sin las celdas. Para una hoja de cálculo, pídele al asistente un resumen de las celdas que cambiaron, o trabaja con la copia en CSV, donde el diff muestra cada línea.
Asistente de código
CarlaSuma los pedidos por ciudad en el archivo juntar.py.
IAListo. Ajusté la suma por ciudad.
¿Qué ajustaste? ¿Cuántas líneas? No se puede saber.
CarlaMuestra el git diff completo de lo que cambiaste.
Toca o haz clic en los dos botones del cuadro y compara.
Si te trabaste aquí, es normal¿El diff parece una sopa de letras? Lee solo tres cosas: el nombre del archivo, las líneas con − y las líneas con +. El resto es dirección y contexto.
Practica ahora 0/4
Tu primer diff, en la carpeta del piloto
Listo cuando hayas leído un diff de tu briefing.md y anotado una línea que salió y una que entró. Unos 12 minutos, en la computadora.
Todo sucede en la carpeta del piloto, con el briefing de la lección 5; ¿no lo hiciste? Crea cualquier archivo de texto allí. Si aparece "git: command not found" (en Windows: "El término 'git' no se reconoce"), instala Git desde el sitio oficial, git-scm.com, y cierra y vuelve a abrir el terminal. Si el commit te pide nombre y correo electrónico, ejecuta los dos comandos git config que te muestre, cambiando el nombre y el correo electrónico de ejemplo por los tuyos. ¿Prefieres no usar el terminal? Pídele cada paso a tu asistente, en la carpeta del piloto.
Ya puedes leer, en el propio Git, qué cambió en un archivo.
Resumen de bolsillo
Git para revisar
git switch -ccrea un branch de prueba y entra en él.
git statuste dice dónde estás y enumera todo lo que cambió, incluso los archivos nuevos.
git diffmuestra las líneas: − salió, + entró.
Tu próximo paso
Ya puedes ver el cambio real, sin depender del resumen de la IA.
En tu próximo pedido a un asistente de código, al final pídele: "muestra el git diff completo". Te toma diez segundos.
En la próxima lección: si la IA hace todo de una vez, el diff se convierte en un libro. ¿Cómo pedirlo por etapas?
Lección 11 · Dev con IA v6.2 · INEMA.CLUB
Módulo 3 · Lección 2 de 5
Un paso a la vez, con el criterio a la vista
Puedes pedir solo la primera etapa de tu piloto, con los criterios del briefing incluidos y una pausa al final.
Pedir toda la tarea de una vez genera un cambio enorme. Nadie revisa bien trescientas líneas. Por etapas, cada cambio es pequeño, se verifica y se revisa antes del siguiente.
En 1 minuto
Divide el plan en etapas pequeñas, cada una con su criterio.
Pide una etapa, con los criterios incluidos y «detente al terminar».
¿Verificaste la etapa? Pasa a la revisión de la lección 13; el commit viene después.
1Hacer todo de una vez crea un diff que nadie lee
Cuando la IA hace todo en un solo pedido, el diff queda largo. Lo hojeas, te cansas y lo apruebas. Así es como se cuela el error.
Rafael pidió «el formulario completo, con envío y validación». Recibió cambios en siete archivos. La siguiente vez, pidió solo los campos: un archivo, pocas líneas.
Todo de una vez
Pedido: formulario completo.
Diff: siete archivos. Rafael aprobó sin leerlos todos.
Una etapa
Pedido: solo los campos del formulario.
Diff: un archivo, que leyó línea por línea.
Balance: un cambio pequeño es un cambio que de verdad verificas.
2Cada etapa con su criterio
Toma el plan del módulo 2 y divídelo en etapas que quepan en un pedido. Cada etapa toma del briefing el criterio de aceptación que debe cumplir.
Carla dividió la rutina de las hojas de cálculo en tres etapas. La primera solo lee las hojas de cálculo de la semana. Su criterio: el total de filas leídas coincide con la suma de las filas de las hojas de cálculo.
Etapas del piloto de Carla
1 Leer las hojas de cálculo · criterio: coincide el total de filas leídas
2 Sumar por ciudad · criterio: cada ciudad una sola vez
3 Guardar el informe · criterio: archivo nuevo, originales intactos
1Empieza por lo que necesitan las demás.
2Una cosa nueva por etapa.
3La última entrega el resultado.
3El pedido de la etapa: criterio incluido y pausa
El pedido tiene cuatro partes: dónde leer el contexto, qué etapa hacer, sus criterios y la orden de detenerse al final. Con la pausa, la IA no continúa con la siguiente etapa antes de que la verifiques.
Rafael menciona los archivos por su nombre, con @, y pide la etapa 1. La respuesta enumera qué cambió y cómo verificarlo.
Asistente de código
RafaelLee @briefing.md y @plan-v2.md. Haz solo la etapa 1: los campos del formulario.
Criterios de esta etapa:
1. El nombre, el teléfono y el mensaje aparecen en la página.
2. El campo de teléfono no acepta letras.
Modifica solo contato.html. Al final, detente, enumera los archivos modificados y di cómo comprobar cada criterio.
IAEtapa 1 lista. Archivo modificado: contato.html.
Para comprobarlo: 1. abre la página y mira los tres campos; 2. escribe letras en el teléfono e intenta enviar.
Me detuve aquí. La etapa 2 es el envío.
Un archivo, dos criterios y la IA se detuvo a esperarte.
Si te trabaste aquí, es normal¿No tienes el plan-v2.md del módulo 2? Usa solo el briefing de la lección 5 y escribe tú la etapa 1 en el pedido. El resto funciona igual.
4¿La etapa salió mal? Deshaz los cambios antes de guardar
La versión guardada en Git se llama commit. En este curso viene después de la revisión de la lección 13. Hasta entonces, el cambio está solo en los archivos y puedes deshacerlo.
Si la etapa no quedó bien, git restore . devuelve los archivos que Git ya sigue a la última versión guardada. Los archivos nuevos que creó la IA no desaparecen con eso: revísalos con git status y bórralos a mano.
A Carla no le gustó el primer intento de la etapa 1. Le pidió a Codex, desde la app: "deshaz los cambios de esta etapa con git restore y muestra git status". Todo volvió a como estaba antes.
Terminal · carpeta del piloto de Carla
$ git status
On branch etapas-relatorio
Changes not staged for commit:
modified: juntar.py$ git restore .
$ git status
On branch etapas-relatorio
nothing to commit, working tree clean
"modified" = archivo modificado y aún no guardado. Después de git restore ., "nothing to commit" = volvió a la última versión guardada.
Desde el terminal o pidiéndoselo al asistente. Si ya ejecutaste git add en la lección 13, usa git restore --staged --worktree . para deshacer también lo que preparaste.
Practica ahora 0/3
Pide la etapa 1 de tu piloto
Listo cuando el pedido de la etapa 1 tenga contexto, etapa, criterios y una indicación para detenerse, y hayas comprobado la respuesta. Unos 10 minutos, en la computadora.
La IA modifica solo el archivo que enumeres, dentro del branch de prueba de la lección 11 (¿no lo hiciste? Pídele al asistente: "crea un branch de prueba y cámbiate a él"). Si pasa de la etapa 1, presiona el botón para detener (Esc en el terminal) y pídele que informe lo que hizo. En un chat común, pega el texto del briefing en lugar de @.
Lee @briefing.md <y @plan-v2.md, si lo tienes>.
Haz solo la etapa 1: <en qué consiste la etapa 1>.
Criterios de esta etapa:
1. <sí o no>
2. <sí o no>
Modifica solo: <archivo>.
Al final, detente, enumera los archivos modificados y di cómo comprobar cada criterio.
Ejemplo de Carla:
Lee @briefing.md.
Haz solo la etapa 1: leer las hojas de cálculo de la semana.
Criterios de esta etapa:
1. El total de filas leídas es igual a la suma de las filas de las hojas de cálculo.
2. Las hojas de cálculo originales no cambian.
Modifica solo: juntar.py.
Al final, detente, enumera los archivos modificados y di cómo comprobar cada criterio.
Ya pides trabajo por etapas que puedes revisar una por una.
Resumen de bolsillo
Etapas
Pequeñauna etapa cabe en un diff que puedes leer completo.
Pedidocontexto, etapa, criterios y "detente al final".
Deshacergit restore . antes del commit, que viene después de la revisión.
Tu próximo paso
Ya conviertes un plan en pedidos pequeños y fáciles de revisar.
Escribe las etapas 2 y 3 de tu piloto, cada una con un criterio. Te toma cinco minutos.
En la próxima lección: la etapa está lista. ¿Quién la revisa y qué necesita recibir esa persona?
Lección 12 · Dev con IA v6.2 · INEMA.CLUB
Módulo 3 · Lección 3 de 5
Quien revisa recibe el diff, no el resumen
Puedes pedirle al otro modelo que revise una etapa con el paquete adecuado: briefing, diff y el resultado de tus verificaciones.
En la lección anterior, la IA entregó una etapa. Si quien revisa solo recibe "hice esto", revisa una frase. Con el paquete adecuado, revisa el trabajo y señala la línea exacta del problema.
En 1 minuto
El paquete para quien revisa tiene tres partes: briefing, diff y resultado de las verificaciones.
Pide hallazgos con ubicación, qué falla, impacto y la corrección más pequeña.
Quien revisa solo lee: señala, no modifica archivos.
1El paquete para quien revisa tiene tres partes
La revisión cruzada de una etapa necesita tres cosas. El briefing, para saber qué se pidió. El diff, para ver qué cambió. Y lo que verificaste, con el resultado.
Rafael anota las verificaciones de la etapa en un archivo conferencias.txt: "Aparecen 3 campos: sí. El teléfono rechaza letras: sí." Esa hoja se envía junto con el paquete para quien revisa.
Carpeta del piloto · paquete de revisión
1 briefing.md · qué se pidió
2 mudanca.diff · qué cambió, línea por línea
3 conferencias.txt · qué verificaste y cuál fue el resultado
1El mismo briefing que recibió quien hizo el trabajo.
2El cambio real, generado por Git.
3Evidencia, no opinión.
2Con el paquete, quien revisa encuentra lo que falta
Con el resumen, quien revisa tiende a estar de acuerdo. Con el paquete, compara el pedido con el cambio y con lo que se verificó. Así aparece el criterio que nadie probó.
Rafael le envió a Codex el paquete de la etapa 1. En la revisión se notó que conferencias.txt decía «sí» para el teléfono sin explicar cómo se comprobó.
Revisión de la etapa 1
RafaelClaude dijo que completó los campos del formulario. ¿Está bien?
CodexParece adecuado. Los campos de un formulario son un cambio sencillo.
El revisor aprobó una frase.
RafaelLee briefing.md, mudanca.diff y conferencias.txt. Enumera los hallazgos. Para cada uno: dónde, qué falla, impacto y la corrección mínima. No modifiques archivos.
CodexHallazgo 1. Dónde: conferencias.txt, línea «Teléfono rechaza letras: sí». Falla: no dice cómo se comprobó. Impacto: medio. Corrección mínima: escribir letras en el teléfono, intentar enviar y anotar lo que apareció.
El hallazgo señala el archivo, la línea y la corrección.
Toca o haz clic en los dos botones del recuadro y compara las dos revisiones.
3Armar y enviar el paquete
Antes del commit, la versión guardada, pídele a Git el diff en un archivo, desde el terminal. Después llama al otro modelo en modo de solo lectura, con la respuesta guardada en un archivo.
En la app, el proceso es el mismo, explicado con palabras. Pídele a quien hizo el trabajo: «ejecuta git add -A y guarda git diff --staged en mudanca.diff». Después abre una conversación nueva, con el otro asistente o con el mismo, y menciona los tres archivos. En la app, «no modifiques archivos» es un pedido, no un bloqueo: después, comprueba con git status que nada haya cambiado.
Carla hace todo desde la app. Codex hizo la etapa; el chat de IA, en una conversación nueva, recibe los tres archivos adjuntos con el ícono del clip. Si el chat rechaza el .diff, ella lo cambia de nombre a mudanca.txt.
Terminal · carpeta del piloto
$ git add -A
$ git diff --staged --output=mudanca.diff
$ codex exec --sandbox read-only -o review.md "Leia briefing.md, mudanca.diff e conferencias.txt. Liste os achados. Para cada achado: onde, o que falha, impacto e a menor correção. Não altere arquivos."
Las dos primeras líneas preparan todo, incluidos los archivos nuevos, y guardan el diff. La tercera llama a Codex solo para leer, y la respuesta queda en review.md. En Claude: claude -p --permission-mode plan "…mismo pedido…" > review-claude.md. En Windows, es mejor usar PowerShell 7 o la app para ese >, que en el PowerShell antiguo puede dañar los acentos.
«read-only» y «plan» son bloqueos: el revisor no puede cambiar ningún archivo.
Si te trabaste aquí, es normal¿El comando largo te asusta? Cópialo, cambia solo los nombres de archivo si son otros y pégalo. O sigue el proceso desde la app, que te lleva al mismo resultado.
4Un hallazgo útil tiene cuatro partes
"Puede mejorar" no ayuda a nadie. Pide que cada hallazgo indique dónde está, qué falla, el impacto y la corrección mínima. Así decides rápido qué corregir.
Carla recibió un hallazgo impreciso sobre el paso de la suma. Volvió a pedirlo en las cuatro partes y obtuvo el punto exacto: la línea de la suma, donde la ciudad con y sin tilde se convertía en dos.
Hallazgo impreciso
"La suma por ciudad puede tener inconsistencias."
Hallazgo útil
Dónde: juntar.py, línea de la suma. Falla: "São Paulo" y "Sao Paulo" se convierten en dos ciudades. Impacto: el total queda dividido. Corrección: quitar las tildes antes de sumar.
Practica ahora 0/3
Pide la revisión de tu etapa 1
Listo cuando tengas una revisión con al menos un hallazgo en las cuatro partes, o la frase "no se encontraron fallas" junto con lo que se leyó. Unos 10 minutos, en la computadora.
El revisor solo lee. ¿Solo tienes un asistente? Abre una conversación nueva con él para revisar. ¿No hiciste la etapa de la lección 12? Revisa el diff del briefing de la lección 11.
Lee briefing.md, mudanca.diff y conferencias.txt.
Revisa la etapa <número> según los criterios del briefing.
Para cada falla: dónde, qué falla, impacto (alto, medio, bajo) y la corrección mínima.
Si no encuentras fallas, di qué leíste para llegar a esa conclusión.
No modifiques archivos.
Ya pides una revisión del trabajo real, con evidencia en cada hallazgo.
Resumen de bolsillo
Revisión del diff
Paquetebriefing, mudanca.diff y conferencias.txt.
Solo lecturaread-only en Codex, plan en Claude; en la app, verifica en git status.
Cuatro partesdónde, falla, impacto, corrección mínima.
Tu próximo paso
Ya preparas el paquete que hace útil la revisión cruzada.
Crea el conferencias.txt en la carpeta del piloto y anota, en una línea por criterio, lo que verificaste hoy.
En la próxima lección: ¿y cuando el cambio es una imagen y no una línea de texto?
Material complementario · De dónde viene esta lecciónProfundización del tema. No cuenta dentro del tiempo de la lección.
Nivel 3 del kit Use Both
"Dividir construir y revisar": un asistente construye por separado de la versión que funciona; el otro revisa el diff con el briefing y el resultado de las pruebas. Las pruebas y tu aprobación deciden qué se incorpora. El revisor recibe el mismo briefing y el artefacto real, nunca un resumen impreciso de lo que hizo el primero.
Tres formas de conectar Claude y Codex
Según el video que acompaña el kit: el complemento oficial de Codex para Claude Code; una línea de comandos que llama a la otra, con la respuesta guardada en un archivo; o una solicitud de cambio en un sitio de código, que el otro modelo revisa.
Puedes revisar una imagen hecha con IA en cuatro puntos: herramienta y costo antes, archivo real, tamaño de uso y versión hermana.
Una imagen también es un cambio en el proyecto y también se equivoca con seguridad. Puede consumir créditos sin que te des cuenta, llegar solo como enlace o tener letras inventadas en los bordes.
En 1 minuto
Antes: ¿la sesión tiene una herramienta de imagen? ¿Cómo cobra?
Está lista cuando es un archivo guardado en el proyecto y abierto al tamaño en que se va a usar.
Nunca sobrescribas: guarda la versión nueva junto a la anterior y anota cuál usa el proyecto.
1Antes: ¿hay una herramienta y cuánto cuesta?
Tener un asistente de código no garantiza que genere imágenes. Cuando lo hace, cada imagen puede descontar créditos de la cuenta. Revisa ambas cosas antes de pedirla.
Por eso, escribe en el pedido: si no hay una herramienta, detente y avísame, sin usar otro servicio de pago. Sin esa instrucción, puede cambiar por su cuenta.
Rafael quería un banner para la página de contacto de la clínica. Antes, le preguntó al asistente si había una herramienta de imagen en la sesión y cómo cobraba.
Asistente de código
RafaelAntes de generar: ¿esta sesión tiene una herramienta de imagen? ¿Cómo se cobra? Si no hay, detente y dímelo; no uses otro servicio.
IANo encontré una herramienta de imagen en esta sesión. Me detuve aquí, sin generar nada. Puedo escribir la descripción del banner para que la generes donde tengas acceso.
Con la instrucción escrita en el pedido, se detuvo y avisó en vez de buscar otro servicio.
2Está listo cuando es un archivo en el proyecto
Una descripción de imagen no es una imagen. Un enlace temporal tampoco: desaparece. Solo cuenta el archivo guardado en la carpeta del proyecto, con un nombre claro.
Carla pidió una portada para el informe semanal. La primera respuesta solo trajo un enlace. Volvió a pedirla: "guarda el archivo en imágenes/capa-relatorio-v1.png".
No cuenta
Una descripción de la imagen o un enlace que vence.
Cuenta
El archivo imagens/capa-relatorio-v1.png, dentro de la carpeta del proyecto.
3Ábrela al tamaño en que se va a usar
En una miniatura, casi cualquier imagen parece buena. Ábrela al tamaño real de uso y revisa tres cosas: texto, marcas y recorte. Es común que aparezcan letras inventadas en los bordes.
En la pantalla pequeña, la portada de Carla se veía excelente. Impresa en una hoja completa, apareció una palabra sin sentido en una esquina y una persona con la cara cortada.
Revisión de la portada a tamaño real
1 Texto: ¿hay alguna letra o palabra inventada?
2 Marcas: ¿hay un logotipo de una empresa que no es tuya?
3 Recorte: ¿hay una cara u objeto cortado en el borde?
1Revisa con calma los cuatro bordes.
2No puedes entregar al cliente una marca ajena.
3Revísala en el formato final: página, celular o impreso.
Ponte a prueba
La imagen quedó excelente en la miniatura. ¿Qué haces antes de usarla?
4Versión hermana, nunca encima de la anterior
¿Necesitaste cambiar la imagen? Guarda la nueva al lado, con otro número, y conserva el original. Anota en el proyecto qué versión está en uso. Así puedes volver atrás y comparar.
Rafael generó el banner donde tenía acceso, en tres versiones. Guardó las tres y anotó en el briefing (briefing.md): "banner en uso: v2".
imágenes · sitio de la clínica
1 imágenes
banner-contato-v1.png
2 banner-contato-v2.png
banner-contato-v3.png
1Una carpeta para las imágenes del proyecto.
2La versión en uso, anotada en el briefing.
Si te trabaste aquí, es normal¿Tu asistente no genera imágenes? No pasa nada: las revisiones de los pasos 2 a 4 sirven para cualquier imagen, hecha con IA, por ti o por un diseñador.
Practica ahora 0/4
Revisa una imagen real
Listo cuando tengas una imagen del piloto revisada en los tres puntos y una versión hermana guardada al lado. Unos 10 minutos, en la computadora.
No se genera ni se cobra nada: usa una imagen que ya tengas, del proyecto o una foto tuya. Si el asistente dice que va a generar algo, detente antes.
Antes de generar cualquier imagen: ¿esta sesión tiene una herramienta de imagen?
¿Cómo se cobra? No generes nada ahora ni uses otro servicio.
Ya revisas una imagen de IA como revisas cualquier otro cambio.
Resumen de bolsillo
Imagen con IA
Antes¿existe la herramienta? ¿Cómo cobra? Indícale que se detenga si no hay una.
Archivoguardado en el proyecto y abierto al tamaño real.
Versionesv1, v2, v3 lado a lado; anota cuál está en uso.
Tu próximo paso
Ya sabes evitar que una imagen cueste sin aviso o desaparezca del proyecto.
Abre la carpeta de tu piloto y crea la carpeta imagens, aunque esté vacía. Te lleva un minuto.
En la próxima lección: reunir todo en un cambio del piloto, con la revisión registrada, e intercambiar los papeles.
Material complementario · Imagen con Codex en INEMAProfundización del tema. No cuenta dentro del tiempo de la lección.
Nivel 2 del kit Use Both
Solo si hay una herramienta de imagen disponible en la sesión; revisa el acceso y el cobro antes. El resultado esperado es el archivo real en el proyecto, abierto al tamaño en que se va a usar. Conserva el original y guarda las revisiones como archivos hermanos, registrando qué versión usa el proyecto.
Cómo lo hace INEMA hoy
Una guía automática solicita la imagen al generador de Codex y guarda el archivo en una carpeta. Cada generación consume crédito de la suscripción, por eso solo se ejecuta cuando está autorizada; sin autorización, se usa por defecto un generador local gratuito. Después de generar, se revisa la imagen: el texto de los bordes puede aparecer inventado.
Puedes entregar un cambio de tu piloto con la revisión cruzada registrada en un archivo: hallazgos, lo que corregiste y lo que rechazaste.
La revisión que queda solo en la conversación se pierde. Mañana nadie recuerda qué se encontró ni por qué se rechazó un punto. Y, si siempre tienes el mismo revisor, no descubres si la otra ruta funciona mejor para tu tarea.
En 1 minuto
Quien hace y quien revisa pueden intercambiar roles. Prueba la otra ruta en tu tarea.
Corrige el hallazgo que tiene evidencia; rechaza el resto, con el motivo.
Registra todo en revisao-etapa-N.md, junto al código.
1Quien hace y quien revisa pueden intercambiar roles
"Claude hace, Codex revisa" es una ruta para empezar, no un ranking. En una etapa, prueba lo contrario y compara con tu propio criterio: ¿qué ruta encontró más fallas reales?
¿Solo tienes un asistente? El intercambio se hace entre conversaciones: una hace, otra nueva revisa y, en la etapa siguiente, al contrario.
Rafael hizo la etapa 2 con Codex y pidió la revisión a Claude. Claude encontró una falla en el envío que la ruta anterior no había detectado en esta tarea.
Ruta A
Claude hace la etapa. Codex revisa el diff.
Ruta B
Codex hace la etapa. Claude revisa el diff.
Las dos rutas son válidas. Quédate con la que encuentre más fallas reales en tu tarea, no con la más famosa.
2Corrige lo que tiene evidencia; rechaza con un motivo
No todos los hallazgos merecen una corrección. Corrige lo que señala dónde está el problema, muestra la falla y coincide con un criterio del briefing. Rechaza lo que sea cuestión de gusto o esté fuera del alcance, y escribe por qué.
Carla recibió dos hallazgos. Uno señalaba ciudades repetidas por la tilde: lo corrigió. El otro sugería cambiar el formato del informe, que está en la sección "Fuera" del briefing: lo rechazó.
Corregido
"São Paulo" y "Sao Paulo" se contaban como dos ciudades. Criterio 2 del briefing.
Rechazado
"Cambiar el formato del informe." Motivo: está en la sección Fuera del briefing.
Si te trabaste aquí, es normal¿Dudas si corregir o rechazar? Pregúntate: ¿esto incumple algún criterio del briefing? Si sí, corrígelo. Si no, anótalo y sigue.
3El registro de la revisión
Un archivo breve por etapa guarda la revisión. Quién revisó, qué encontró, qué se corrigió, qué se rechazó y por qué. El archivo queda en la carpeta del piloto, junto al código.
El revisao-etapa-2.md de Rafael tiene seis líneas. En el módulo 5, otra conversación leerá ese archivo para continuar.
revisao-etapa-2.md · formulario de la clínica
1 Hizo: Codex · Revisó: Claude
2 Hallazgo 1: el envío no muestra un aviso cuando falla el mensaje · corregido
3 Hallazgo 2: cambiar los colores del botón · rechazado (Fuera del encargo)
4 Verificado después: el envío de prueba llegó a recepción
1Quién lo hizo y quién lo revisó.
2Hallazgo corregido, con lo que era.
3Hallazgo rechazado, con el motivo.
4La verificación después de la corrección.
4El laboratorio: un cambio completo
En Git, el módulo completo se convierte en una secuencia: branch, etapa, paquete, revisión, corrección, registro y commit. El commit va al final, después de la revisión. Es el primer cambio de tu piloto, realizado y verificado por dos personas.
Carla hizo la etapa 2 desde la app, en el orden de la ventana de abajo. Desde la etapa hasta el commit, tardó unos cuarenta minutos, y el revisao-etapa-2.md quedó en la carpeta.
Un cambio revisado
1 Branch de prueba (lección 11)
2 Etapa con criterio pegado y parada (lección 12)
3 Paquete y revisión de solo lectura (lección 13)
4 Corregir, registrar, git add -A y commit (esta lección)
1Separado de la versión que funciona.
2Cambio pequeño.
3Otra mirada al trabajo real.
4Registro y, solo entonces, el commit.
El branch y el commit se explican en las lecciones 11 y 12. Desde la app, pídele cada paso al asistente. El laboratorio completo, con los comandos, está en el material complementario.
Practica ahora 0/4
Un cambio del piloto, con la revisión registrada
Listo cuando la carpeta del piloto tenga el revisao-etapa-N.md completado a partir del review.md de la lección 13 y la etapa esté guardada en un commit. Unos 12 minutos, en la computadora.
Todo sucede en el branch de prueba; la versión que funciona no cambia. ¿No tienes el review.md de la lección 13? Practica con el ejemplo de Carla en la plantilla. Si la revisión pide algo grande, anota "queda para otra etapa" y sigue.
# Revisión de la etapa <N>
Lo hizo: <modelo o conversación> · Revisó: <otro>
Hallazgo 1: <qué es> · corregido | rechazado (motivo)
Hallazgo 2: <qué es> · corregido | rechazado (motivo)
Verificado después: <qué probaste y cuál fue el resultado>
Ejemplo de Carla:
# Revisión de la etapa 2
Lo hizo: Codex · Revisó: chat de IA, conversación nueva
Hallazgo 1: la ciudad con y sin tilde aparecía como dos · corregido
Hallazgo 2: cambiar el formato del informe · rechazado (Fuera del encargo)
Verificado después: cada ciudad aparece una vez; el total coincide con las hojas de cálculo
Cerraste el módulo 3 con un cambio realizado, revisado, corregido y registrado.
Resumen de bolsillo
Revisión registrada
Rutasintercambia quién hace y quién revisa; compáralo con tu tarea.
Decidircorrige con evidencia, rechaza con un motivo.
Archivorevisao-etapa-N.md junto al código.
Tu próximo paso
Ya entregas cambios con dos revisiones y un registro que otra persona entiende.
Vuelve a leer tu revisao-etapa-N.md mañana. Si no entiendes algo, escribe una línea más.
En el módulo 4: revisión hecha. Pero ¿el cambio funciona de verdad? Es hora de comprobarlo y decidir.
Material complementario · El laboratorio completo del móduloProfundización del tema. No cuenta en el tiempo de la lección.
Un cambio revisado, de principio a fin
Reserva de 30 a 45 minutos. En la siguiente etapa del piloto, invierte las rutas: quien revisaba hace, quien hacía revisa. ¿Solo tienes un asistente? Una conversación hace el trabajo y otra nueva lo revisa.
En el branch de prueba, pide la etapa con los criterios pegados y el punto de parada (lección 12).
Comprueba en git status y anota el resultado de cada criterio en conferencias.txt.
Genera el paquete y pide la revisión de solo lectura (lección 13).
Corrige o rechaza cada hallazgo y regístralo en revisao-etapa-N.md.
Vuelve a comprobar y haz el commit.
git add -A
git diff --staged --output=mudanca.diff
codex exec --sandbox read-only -o review.md "Leia briefing.md, mudanca.diff e conferencias.txt. Liste os achados. Para cada achado: onde, o que falha, impacto e a menor correção. Não altere arquivos."
git add -A
git commit -m "etapa 2 revisada"
En Claude, la revisión de solo lectura es claude -p --permission-mode plan "…" > review-claude.md.
Puedes escribir, junto a cada criterio de tu briefing, cómo se comprobará y quién lo comprobará.
En el módulo 1 escribiste los criterios. Un criterio sin una forma de comprobarlo se convierte en un adorno del briefing. Al entregar, cada criterio necesita una verificación acordada de antemano.
En 1 minuto
Cada criterio tiene una línea: cómo lo compruebo y quién lo comprueba.
Una regla que se repite se convierte en una prueba automática. La apariencia y el sentido se comprueban manualmente.
Una prueba que nunca ha fallado no demuestra nada. Pide ver cómo falla antes.
1Un criterio sin verificación es un adorno
Todo criterio de aceptación necesita una forma acordada de comprobarlo. Sin eso, cada persona lo comprueba a su manera o nadie lo comprueba.
Rafael tomó los tres criterios del formulario de la clínica y escribió, junto a cada uno, cómo iba a comprobarlo.
briefing.md · cómo compruebo
1 El mensaje llega a recepción → enviarlo desde la página y revisar la bandeja
2 El teléfono rechaza letras → prueba automática
3 No se desplaza hacia los lados en el celular → abrirlo en el celular
1Comprobación manual, hecha por Rafael.
2Una regla que se repite: la computadora comprueba.
3Apariencia: comprobación manual.
2Automático para reglas, comprobación manual para el sentido
Una prueba automática comprueba una regla de la misma manera, tantas veces como quieras. Es excelente para «rechaza letras» o «el total coincide». Es poco útil para «el texto tiene sentido» o «la página se ve bonita».
Carla puso una celda de comprobación en la hoja de cálculo: compara el total del informe con la suma de las hojas de cálculo y muestra «coincide» o «no coincide». En cambio, lee la lista de ciudades con sus propios ojos.
Prueba automática
Reglas que se repiten: suma, formato, campo obligatorio. Se ejecuta igual cada vez.
Comprobación manual
Sentido, apariencia, tono, el recorrido del usuario. Hace falta que alguien lo revise.
Un buen criterio indica cuál de las dos formas lo comprobará.Cómo hizo Carla la celda de comprobación
En una celda vacía de la hoja de cálculo del informe, escribió una fórmula que compara el total con la suma de las hojas de cálculo. Por ejemplo: =SE(B2=SOMA(C2:C8);"confere";"não confere"), donde B2 es el total del informe y de C2 a C8 están los totales de cada hoja de cálculo. Cambia las celdas por las tuyas. ¿No sabes cómo armarla? Pídele a la IA la fórmula e indica qué celdas debe comparar.
Si te trabaste aquí, es normal¿No sabes si un criterio se puede comprobar con una prueba automática? Pregúntate: ¿se puede escribir la regla como una operación o un formato (suma, solo números, campo completado)? Entonces es automática. ¿Depende de observar, leer o usar? Es una comprobación manual.
3No tienes que escribir la prueba
La IA escribe la prueba automática. Tu trabajo es pedir una prueba por criterio y revisar su resultado: el texto que muestra al ejecutarse. No aceptes solo «creé las pruebas, todas pasan».
Rafael pidió una prueba solo para el criterio del teléfono y su resultado, antes y después de la corrección.
Asistente de código
RafaelCrea pruebas para el formulario.
IACreé pruebas para el formulario. Todas pasan.
¿Qué pruebas? ¿Qué criterio se está comprobando? No se puede saber.
RafaelCrea una prueba para el criterio 2 de briefing.md: el teléfono rechaza letras. Prueba con el texto "abc". Ejecútala antes de corregir y muéstrame el resultado. Después corrige y ejecútala de nuevo.
IAAntes de la corrección: FALLÓ — el campo aceptó "abc".
Después de la corrección: PASÓ — el campo rechazó "abc".
Un criterio, una prueba y el resultado que se muestra las dos veces.
Toca o haz clic en los dos botones del cuadro y compara las dos respuestas.
4Una prueba que nunca falló no demuestra nada
Una prueba mal escrita puede pasar siempre, con el error o sin él. Por eso conviene ver que la prueba falle una vez, cuando el error todavía existe. Si nunca falló, no sabes si revisa lo correcto.
En una copia, Carla cambió a propósito un valor de la última hoja de cálculo, y la celda siguió diciendo "coincide". La fórmula sumaba de C2 a C7 y dejaba fuera la última hoja de cálculo.
Siempre pasó
"Coincide" con los valores correctos y también con un valor cambiado a propósito.
Lo que demuestra: nada.
Ya falló una vez
Con la fórmula sumando de C2 a C8: "no coincide" con el valor cambiado; "coincide" con los correctos.
Lo que demuestra: que detecta el error.
Ponte a prueba
La IA escribió una prueba para "el total coincide" y pasó a la primera. ¿Qué pides después?
Practica ahora 0/3
Cómo vas a verificar cada criterio
Está listo cuando cada criterio de tu briefing tenga una línea "cómo verifico" y "quién verifica". Unos 10 minutos, en la computadora.
Solo escribes en tu archivo; todavía no se ejecuta nada. ¿No tienes el briefing.md de la lección 5 (en la carpeta del piloto)? Usa tres criterios de cualquier tarea tuya.
## Cómo verifico
1. <criterio 1> → <cómo verifico> · <automático o manual> · quién: <nombre>
2. <criterio 2> → <cómo verifico> · <automático o manual> · quién: <nombre>
3. <criterio 3> → <cómo verifico> · <automático o manual> · quién: <nombre>
Ejemplo de Carla:
1. Total igual a la suma de las hojas de cálculo → celda de verificación · automático · quién: Carla
2. Cada ciudad una vez → leer la lista · manual · quién: Carla
3. Origen debajo de cada tabla → revisar cada tabla · manual · quién: colega de la dirección
Ya sabes cómo se va a verificar cada criterio de tu piloto.
Resumen de bolsillo
Criterio y verificación
Cómo verificouna línea junto a cada criterio.
Automático o manualregla que se repite × sentido y apariencia.
Ver que falleuna prueba solo sirve después de detectar el error una vez.
Tu próximo paso
Ya relacionas cada criterio con una verificación acordada.
Pídele a la IA la prueba del criterio que marcaste, con el resultado antes y después de la corrección.
En la próxima lección: la prueba pasó. ¿Eso quiere decir que el sistema funciona en manos de quien lo usa?
Lección 16 · Dev con IA v6.2 · INEMA.CLUB
Módulo 4 · Lección 2 de 5
La prueba pasó. Ahora úsalo de verdad.
Puedes verificar un cambio de tu piloto siguiendo el recorrido de quien lo va a usar, de principio a fin, con datos de prueba.
Una prueba verifica una regla. Quien usa el sistema pasa por varias reglas seguidas, en un celular y con prisa. Muchos errores solo aparecen al recorrer todo ese camino.
En 1 minuto
Que una prueba pase no significa que el sistema funcione para quien lo usa.
Recorre el camino de quien lo usa, de principio a fin, con datos de prueba.
Si la IA maneja la pantalla por ti, tú te encargas de las contraseñas, los pagos y los envíos.
1Que una prueba pase no significa que el sistema funcione
La prueba automática revisa una regla a la vez. No ve la pantalla pequeña del celular, el teclado que cubre el botón ni el mensaje que termina en la carpeta de spam.
En el formulario de la clínica, la prueba del teléfono pasó. En el celular de Rafael, el teclado cubría el botón de enviar y no se podía desplazar la pantalla hasta él.
Solo la prueba
Lo que vio Rafael: PASÓ — el campo rechazó "abc".
Lo que vio el paciente: un botón de enviar al que no podía llegar.
Todo el recorrido
Lo que hizo Rafael: abrió el formulario en el celular, lo llenó como paciente e intentó enviarlo.
Lo que encontró: el botón oculto, antes de que llegara a la clínica.
2Recorre el camino de quien lo usa
Piensa en quién lo va a usar y dónde. Haz el mismo recorrido, en el mismo tipo de dispositivo, desde el primer clic hasta el resultado final.
La dirección lee el informe de Carla en el celular, desde el correo electrónico. Ella empezó a enviarse el informe a sí misma y abrirlo en el celular antes de enviarlo.
Recorrido del paciente · formulario de la clínica
1 Abrir el sitio en el celular, desde el enlace que comparte la clínica
2 Llenar el nombre, el teléfono y el mensaje
3 Enviar
4 Revisar la bandeja de recepción, incluida la carpeta de spam
1El mismo dispositivo y la misma forma de acceso que usa el paciente.
2Escribiendo, no pegando.
3Hasta el final, sin saltarte ningún paso.
4El resultado en el destino, no la pantalla que dice "enviado".
3Usa datos de prueba, nunca datos reales
Verifica con datos inventados y deja claro que son de prueba. Así nadie confunde la prueba con un caso real y no circulan datos de personas reales.
Rafael envía el formulario como "Paciente Teste" y acuerda con recepción que pueden borrar los mensajes con ese nombre.
Carla verifica en una copia de las hojas de cálculo, nunca en las originales.
Dato real
El nombre y el teléfono de un paciente real en el formulario de prueba.
Dato de prueba
"Paciente Teste", un teléfono de ejemplo y recepción avisada.
Si te trabaste aquí, es normal¿No puedes hacer la prueba sin realizar una acción real, como enviar un correo electrónico? Primero envíatelo a ti. Después, envíalo una sola vez al destino real y avisa a quien lo recibe.
4Cuando la IA maneja la pantalla por ti
Opcional: si tu asistente no maneja el navegador, salta esta parte. Algunos asistentes pueden manejar el navegador o la computadora, como Claude Code con la extensión de Chrome. Esto solo funciona si la herramienta está disponible en tu cuenta: tener el asistente en la computadora no es suficiente.
Incluso con la herramienta, hay tres cosas que quedan en tus manos: la contraseña, el pago y el clic final para enviar. La IA prepara y se detiene. Si se niega a realizar una acción por seguridad, no cambies de modelo para evitarlo: hazlo tú por el camino habitual.
Asistente con uso del navegador
RafaelAbre la página de contacto de la clínica y completa: nombre "Paciente Teste", teléfono "11 90000-0000", mensaje "teste do formulário". Detente antes de enviar.
IACompleté el nombre "Paciente Teste", el teléfono "11 90000-0000" y el mensaje "teste do formulário". Me detuve antes de enviar. Revisa los campos y dime si puedo hacer clic en enviar.
La IA preparó todo; el envío espera tu confirmación.
Practica ahora 0/3
Todo el recorrido, una vez
Listo cuando hayas hecho el recorrido de quien lo usa, de principio a fin, y hayas anotado lo que viste. Unos 10 minutos, en el dispositivo que usa la persona.
Usa datos de prueba y una copia, nunca el original. Si tu piloto todavía no tiene nada funcionando, haz el recorrido con el resultado de cualquier tarea con IA de esta semana.
Ya revisas el sistema de la manera en que se va a usar.
Resumen de bolsillo
Recorrido del usuario
Más allá de la pruebael recorrido completo detecta lo que la regla suelta no ve.
Mismo dispositivoy datos de prueba, con un aviso a quien los recibe.
IA en pantallaella prepara; la contraseña, el pago y el envío son tuyos.
Tu próximo paso
Ya revisas el piloto tal como lo va a usar quien lo utilice.
Acuerda hoy con quien recibe los resultados de tu piloto un nombre de prueba, como "Paciente Teste".
En la próxima lección: encontraste un problema. ¿Qué le pides a la IA que cambie?
Material complementario · Uso supervisado de la computadoraAmpliación del tema. No cuenta en el tiempo de la lección.
Nivel 4 del kit Use Both
El kit lo llama "uso supervisado de la computadora": delegar una acción autorizada en una interfaz cuando no hay otro camino. Prefiere una cuenta de prueba y un registro inventado. Confirma que el asistente realmente tenga la herramienta de uso de la computadora. Escribe la contraseña y el código de verificación tú mismo, nunca en el pedido. Pídele que prepare todo y se detenga antes de enviar, comprar, publicar o borrar. Revisa los campos finales y verifica el resultado después.
El kit también dice: si una herramienta rechaza una acción sensible, no cambies a otro modelo para evitar el rechazo. Usa el camino habitual, realizado por una persona.
La corrección más pequeña, y una línea para no repetir el error
Puedes pedir la corrección más pequeña para una falla de tu piloto y registrarla en una línea del archivo FALHAS.md.
Cuando algo se rompe, dan ganas de pedir «hazlo de nuevo y bien». La IA rehace mucho más de lo necesario, y tienes que volver a revisarlo todo. Y sin un registro, el mismo error vuelve al mes siguiente.
En 1 minuto
Pide la corrección más pequeña que resuelva el problema, y di qué no debe cambiar.
Registra la falla en una línea: fecha, qué se rompió, la corrección, prompt o infra.
Después de unas diez líneas, el patrón de tus errores aparece por sí solo.
1Corrige lo que se rompió, no todo el sistema
La corrección más pequeña es el cambio más breve que hace que el criterio vuelva a cumplirse. Cuanto menor sea, menos cosas tendrás que volver a revisar y menos posibilidades habrá de que se rompa otra parte.
El botón de enviar desaparecía detrás del teclado del celular. Rafael casi pidió «rehaz el formulario». Solo pidió que el botón quedara visible con el teclado abierto.
Rehacer todo
Pedido: «El formulario se ve mal en el celular, reházlo».
Resultado: página nueva y tres criterios para volver a revisar.
Corrección más pequeña
Pedido: «Deja visible el botón de enviar con el teclado abierto. No cambies nada más».
Resultado: un cambio, un punto para revisar.
2El pedido de corrección tiene tres partes
Qué falló, con la evidencia. Qué corregir, y solo eso. Qué debe informar la IA al final: qué cambió y qué quedó igual.
La fórmula de Carla contaba el plazo desde la fecha equivocada. Pidió que corrigieran solo la fórmula, con la hoja de cálculo de ejemplo que mostraba el error.
Asistente de código
CarlaFalló: el plazo de transporte se cuenta desde la fecha del pedido. Evidencia: pedido 3 de la hoja de cálculo adjunta.
Corrige solo la fórmula del plazo para que se cuente desde la fecha de salida. No cambies las columnas ni el formato.
Al final, di qué cambió y qué quedó igual.
IACambié la fórmula del plazo para que se cuente desde la fecha de salida. Las columnas y el formato quedaron iguales. Para revisar: calcula a mano el pedido 3 y compáralo.
Falla con evidencia, corrección delimitada, informe de lo que cambió.
3Una línea en FALHAS.md
¿Lo corregiste? Antes de seguir, escribe una línea en un archivo llamado FALHAS.md, en la carpeta del piloto. Cuatro campos: fecha, qué se rompió, la corrección más pequeña y si fue el prompt (tu pedido) o la infra (algo ajeno al pedido). Sin una historia larga.
Rafael crea el FALHAS.md de la misma manera que creó el briefing.md en la lección 5. También puedes pedirle al asistente: «crea FALHAS.md en la carpeta del piloto con este encabezado». La línea más reciente va arriba.
FALHAS.md · carpeta del piloto
1 | fecha | qué se rompió | corrección más pequeña | prompt o infra |
2 | 28/09 | botón de enviar detrás del teclado del celular | botón visible con el teclado abierto | prompt |
3 | 25/09 | el envío no llegaba a recepción | cambiar la dirección de envío | infra |
1El encabezado, escrito una vez.
2La falla de hoy, arriba.
3Las antiguas bajan.
4Prompt o infra: de dónde vino el error
Prompt, aquí, es tu pedido: marca "prompt" cuando el pedido indujo el error o la IA entendió mal. Infra es cuando el problema está fuera del pedido: máquina, red, servicio fuera de línea, cuenta, dirección. Cuando sean ambas cosas, marca ambas.
Después de diez líneas, Carla vio que seis eran "prompt" y todas hablaban de columnas. Empezó a pegar el nombre de las columnas en cada pedido.
Prompt
"El pedido no decía desde qué fecha contar el plazo."
Infra
"La dirección de envío de la clínica estaba mal en el proveedor de correo electrónico."
La etiqueta muestra dónde está la solución: en la forma de pedir o fuera de ella.
Si te trabaste aquí, es normal¿No sabes si fue prompt o infra? Marca "?" y sigue. Con el tiempo, las líneas parecidas muestran la respuesta.
Ponte a prueba
La IA no pudo terminar porque su servicio quedó fuera de línea. ¿Qué etiqueta va en la línea?
Practica ahora 0/3
Tu primera línea en FALHAS.md
Listo cuando la carpeta del piloto tenga un FALHAS.md con el encabezado y una línea completada. Unos 8 minutos, en la computadora.
Es un archivo de texto tuyo. ¿Todavía no hubo fallas en el piloto? Registra la última vez que una IA se equivocó en un trabajo tuyo o usa la falla del botón de Rafael. Las barras y los guiones de la plantilla forman la tabla: cópiala tal como está.
| fecha | qué falló | corrección mínima | prompt o infra |
|---|---|---|---|
| <dd/mm> | <qué falló, en pocas palabras> | <el cambio mínimo que lo resolvió> | <prompt, infra o ambas> |
Ya tienes el registro que muestra, con el tiempo, dónde fallan tus pedidos.
Resumen de bolsillo
Corregir y registrar
Corrección mínimael cambio más corto que hace que el criterio vuelva a cumplirse.
Pedido en tres partesfalla con evidencia, solo lo que hay que corregir, relato de lo que cambió.
FALHAS.mdfecha, qué falló, corrección, prompt o infra.
Tu próximo paso
Ya corriges sin empezar una reforma y guardas lo que aprendiste.
La próxima vez que haya una falla con IA, cualquiera, escribe la línea antes de seguir con la siguiente tarea.
En la próxima lección: ¿y el error que no se va ni en uno ni en dos intentos?
Lección 18 · Dev con IA v6.2 · INEMA.CLUB
Módulo 4 · Lección 4 de 5
Un error difícil necesita una meta
Puedes escribir la meta de un error difícil: el éxito que se puede ver, los límites y el momento en que la IA debe detenerse e informar.
Hay errores que no se van ni en uno ni en dos intentos. La tentación es decir "resuelve esto, cueste lo que cueste". Entonces la IA trabaja mucho tiempo, gasta mucho y nadie sabe decir si lo logró.
En 1 minuto
Cambia «resuelve esto» por una meta con éxito observable: cuál es la entrada y cuál es el resultado.
Pon límites en el pedido: archivos e intentos. Y un momento para informar. El límite de tiempo o gasto queda fuera de la IA.
Si cumple el criterio, la IA se detiene. Sin adornos adicionales.
1«Resuelve esto» no tiene fin
Un pedido sin meta deja que la IA decida cuándo detenerse. Puede detenerse demasiado pronto o no detenerse nunca. Una meta indica cómo saber que llegó.
El informe de Carla daba un total diferente solo algunas semanas. Escribió la meta con una semana que fallaba y el resultado esperado.
Sin meta
«A veces el total no coincide. Resuelve esto.»
Meta
«Con las hojas de cálculo de la semana 38, el total del informe es igual a la suma de las hojas de cálculo. La celda de verificación muestra “coincide”.»
2Las tres partes de la meta
Éxito observable: la entrada, el resultado esperado y cómo verificarlo. Límites: qué archivos, cuántos intentos. Momento para informar: cuándo detenerse y contar lo que intentó. Y, fuera del pedido, el límite de tiempo o gasto, como en la lección 4.
Rafael usó el mismo modelo para un error que solo ocurría con un teléfono de otro estado.
meta.md · error del total
1 Éxito: semana 38 → total igual a la suma; la celda dice «coincide»
2 Límites: solo el archivo juntar.py; 3 intentos · límite: alarma de 30 min
3 Informe: al cumplir la meta o al alcanzar el límite
1Lo verificas sin preguntarle nada a la IA.
2Límites en el pedido; el límite queda fuera de la IA, como en la lección 4.
3Qué intentó, qué falló, qué falta.
3Si llegó: se detiene. Si no llegó: informa.
Indica las dos opciones en el pedido. Si cumple el criterio, la IA se detiene, sin agregar funciones que nadie pidió. Si alcanza el límite, se detiene y describe el bloqueo.
Al tercer intento, la IA de Carla se detuvo y mostró dónde estaba la diferencia.
Asistente de código
CarlaMeta: con las hojas de cálculo de la semana 38, el total del informe es igual a la suma de las hojas de cálculo. Cómo verificarlo: la celda de verificación muestra «coincide». Solo el archivo juntar.py. Máximo 3 intentos. Si cumple la meta, detente. Si no, detente y di qué intentaste, qué falló y qué falta.
IAMe detuve después de 3 intentos; la meta todavía no se cumple. Probé tres formas de sumar la semana 38. Falló: una hoja de cálculo de la semana 38 tiene pedidos repetidos en dos filas. Falta: que indiques si un pedido repetido cuenta una vez.
Sin llegar a la meta, la IA entregó un bloqueo claro, con la pregunta que solo Carla puede responder.
Si te trabaste aquí, es normal¿No sabes cuál es el resultado esperado? Entonces todavía no entiendes el error. Primero pídele a la IA que solo encuentre un caso que falla, sin corregir nada.
4Modo de meta: más tiempo no significa más calidad
Algunos asistentes tienen un modo de meta, en el que persiguen el objetivo por su cuenta. Según el autor del video que acompaña al kit Use Both, Codex tiene un modo de meta (/goal), que consume de 3 a 5 veces más tiempo y tokens. Es un relato, no una medición: verifica si el modo existe en tu versión y en la app.
Con o sin este modo, las condiciones son las mismas: éxito observable, límites en el pedido y un control real. Ejecutarlo durante mucho tiempo no demuestra nada; lo que cuenta es que se cumpla el criterio.
Rafael no usa el modo de meta para el sitio. Envía el pedido común, con las mismas tres partes.
Con modo de meta
La misma meta, los mismos límites y un control real de tiempo o gasto.
Sin modo de meta
Pedido común con las mismas tres partes. Funciona con cualquier asistente.
La función cambia la forma de ejecutar. La meta sigue siendo tuya.
Practica ahora 0/3
Escribe la meta de un error
Listo cuando tengas una meta con éxito observable, tres límites y las dos salidas. Unos 10 minutos, en un archivo meta.md en la carpeta del piloto o en el bloc de notas.
Solo tienes que escribir; no hace falta que lo envíes ahora. ¿No hubo ningún error difícil en el piloto? Usa el del total de Carla y cámbialo por tu hoja de cálculo o página.
Meta: con <la entrada que falla>, <el resultado esperado>.
Cómo comprobarlo: <la prueba o la verificación>.
Límites: solo <archivos>; máximo <3> intentos.
Si pasa, detente, sin agregar nada.
Si no pasa, detente y di qué intentaste, qué falló y qué falta.
Ya conviertes un error difícil en una tarea con inicio, fin y límite.
Resumen de bolsillo
Meta
Éxito observableentrada, resultado esperado, cómo comprobarlo.
Límites, control e informearchivos e intentos en el pedido, control fuera de él y cuándo detenerte para informar.
Dos salidassi pasa, se detiene; si no pasa, describe el bloqueo.
Tu próximo paso
Ya sabes ponerle una meta a un error difícil.
Guarda el molde de la meta en tu bloc de notas, listo para el próximo error que resista dos intentos.
En la próxima lección: todo verificado. ¿Quién decide si el piloto se incorpora y con base en qué?
Material complementario · Objetivo con condición de paradaProfundización del tema. No cuenta para el tiempo de la lección.
Nivel 5 del kit Use Both
Para un problema bien definido que requiere trabajo prolongado: escribe el objetivo con una condición de éxito observable (qué pruebas, qué entrada, qué resultado se espera); limita los archivos, las herramientas, las rondas de revisión y el gasto, empezando con poco; usa la función de meta de la aplicación si existe, o un pedido común con las mismas condiciones; establece un control real de uso o de tiempo si necesitas un tope; pide un informe en un punto definido o ante un bloqueo repetido. Cuando se aprueben las pruebas de aceptación, detente, sin agregar funciones.
Listo significa que hay evidencia de pruebas que cumple la condición, o un bloqueo informado con lo que se intentó. Un tiempo de ejecución prolongado no indica calidad. Las comparaciones de velocidad, persistencia y costo del video son la experiencia del autor, no una garantía basada en mediciones.
Puedes cerrar la aceptación de tu piloto: para cada criterio, la evidencia que viste y la decisión de incluirlo, incluirlo con un pendiente o volver.
Llegó la hora de entregar. Las pruebas pasaron, el otro asistente aprobó y lo usaste de verdad. Falta la decisión, por escrito, con lo que la respalda. Eso es lo que muestras si alguien pregunta «¿quién lo revisó?».
En 1 minuto
La aceptación es una decisión con evidencia, criterio por criterio.
La evidencia es lo que viste, no lo que dijo la IA.
Tres opciones: se incluye, se incluye con un pendiente registrado o se devuelve.
1La aceptación cabe en una ficha
Cada criterio de aceptación del briefing se convierte en una línea: el criterio, la evidencia y el resultado. Al final, la decisión y tu nombre.
Rafael preparó la aceptación del formulario de la clínica en un archivo aceite.md, junto a briefing.md.
aceite.md · formulario de la clínica
1 El mensaje llega a recepción → captura de la bandeja con «Paciente Teste» · ok
2 El teléfono rechaza letras → resultado de la prueba: falló antes, pasó después · ok
3 No se desplaza hacia los lados → captura del celular sin desplazamiento horizontal · ok
4 Decisión: se incluye · Rafael · 28/09
1Evidencia de revisión manual.
2Evidencia de prueba automática.
3El recorrido de quien lo usa, de la lección 17.
4La decisión, con nombre y fecha.
2La evidencia es lo que viste
«La IA dijo que pasó» no es evidencia. La evidencia es la captura de pantalla de la bandeja de entrada, el resultado de la prueba, la suma realizada, el enlace abierto en el celular. Para capturar la pantalla: Windows+Shift+S en Windows, Cmd+Shift+4 en Mac y el botón de encendido + bajar volumen en la mayoría de los celulares. Algo que otra persona pueda mirar y confirmar.
En la aceptación del informe, Carla cambió «revisado por la IA» por la celda de revisión con la palabra «correcto» y la lista de ciudades que ella leyó.
Declaración
«Codex lo revisó y dijo que todo está bien.»
Evidencia
«Celda de revisión: “correcto”. Lista de ciudades leída por mí: ninguna repetida.»
3Tres opciones, no dos
No todo es «perfecto» o «rehacer». Muchas veces lo correcto es incluirlo con un pendiente pequeño, por escrito, con responsable y plazo. Lo que no puede pasar es que el pendiente quede solo en tu cabeza.
Carla aprobó todos los criterios, pero el título del informe salió con la semana escrita incorrectamente. Lo aceptó con un pendiente: corregir el título antes del viernes.
Decisión de aceptación
1 Se acepta: todos los criterios tienen evidencia
2 Se acepta con pendiente: falla pequeña, escrita, con responsable y plazo
3 Se devuelve: un criterio importante no tiene evidencia o está fallando
1Entrega normal.
2Se entrega, y la pendiente queda escrita en el propio aceite.md: qué, quién y hasta cuándo.
3Corrección mínima y nueva revisión, como en la lección 18.
Si te trabaste aquí, es normal¿Dudas entre «se acepta con pendiente» y «se devuelve»? Pregúntate: si el cliente ve esta falla mañana, ¿igual puede usarlo? Si sí, queda como pendiente. Si no, se devuelve.
4Nadie firma por ti
La revisión cruzada y las pruebas ayudan a decidir. La decisión sigue siendo humana. Ni siquiera la aprobación de dos modelos firma en tu lugar.
Rafael envía a la clínica el enlace y una frase: «revisado por mí, criterio por criterio; la aceptación está en el proyecto».
Qué ayuda a decidir
Pruebas, recorrido de quien lo usa, revisión cruzada.
Quién decide
Tú, con nombre y fecha en la aceptación.
Ponte a prueba
Un criterio no tiene evidencia, pero las dos IA dicen que cumple. ¿Qué decisión corresponde?
Practica ahora 0/4
La aceptación de tu piloto
Está listo cuando la carpeta del piloto tenga un aceite.md con la evidencia de cada criterio y tu decisión firmada. Unos 12 minutos, en la computadora.
Es un archivo tuyo; no se envía nada. ¿El piloto todavía no está listo? Haz la aceptación de lo que existe: la decisión honesta puede ser «se devuelve», y eso también es un resultado.
# Aceptación: <nombre del piloto>
| criterio | evidencia (lo que vi) | resultado |
|---|---|---|
| <criterio 1> | <captura, resultado de la prueba, suma, enlace> | <ok, falló o no revisado> |
| <criterio 2> | <...> | <...> |
| <criterio 3> | <...> | <...> |
Decisión: <se acepta, se acepta con pendiente, o se devuelve>
Pendiente (si la hay): <qué, quién, hasta cuándo>
Firmado: <tu nombre> · <fecha>
Cerraste el módulo 4 con la aceptación de tu piloto, firmada y con evidencia.
Resumen de bolsillo
Aceptación
Por criteriocada fila con la evidencia y el resultado.
Evidencialo que viste y otra persona puede revisar.
Decisiónse aprueba, se aprueba con pendientes o se devuelve; con nombre y fecha.
Tu próximo paso
Ya cierras una entrega con una decisión escrita y evidencia para cada criterio.
Muéstrale el aceite.md a alguien de tu equipo y pregúntale si estaría de acuerdo con la decisión leyendo solo el archivo.
En el módulo 5: mañana, otra conversación u otro asistente continúa el piloto. ¿Cómo pasar el relevo sin explicar todo de nuevo?
Lección 20 · Dev con IA v6.2 · INEMA.CLUB
Módulo 5 · Lección 1 de 5
Handoff: el estado en un archivo
Puedes escribir en un archivo dónde se detuvo el trabajo, las decisiones, los pendientes y la próxima acción exacta.
Una conversación nueva con la IA empieza sin recordar nada. Sin un registro, explicas todo de nuevo y, a veces, la IA deshace una decisión que ya se había tomado. Un archivo breve resuelve eso.
En 1 minuto
El handoff es el cambio de turno: un archivo breve al final de la sesión.
Cuatro partes: dónde se detuvo, decisiones, pendientes y próxima acción exacta.
Registra lo que pasó. No es una orden para que la IA empiece a hacer cosas.
1La conversación nueva no recuerda nada
Cada conversación con el modelo tiene un límite de tamaño. Cuando termina, o cuando abres otra, lo acordado queda atrás.
El handoff lleva lo acordado a la próxima conversación. Es como el cambio de turno en un hospital: quien llega lee antes de atender al paciente.
Rafael dejó detenido el formulario de la clínica un viernes. El lunes abrió una conversación nueva y solo dijo «continúa el formulario».
Conversación nueva, lunes
RafaelContinúa el formulario de contacto.
IAPuedo crear el formulario con nombre, correo electrónico, teléfono y mensaje. ¿A qué correo quieres que llegue el envío?
La IA empezó desde cero y preguntó qué ya estaba decidido.
RafaelLee handoffs/latest.md y dime dónde nos quedamos, antes de modificar cualquier archivo.
IANos quedamos en el envío a recepción. Decidido: el campo de teléfono rechaza letras. Pendiente: el mensaje de prueba no llegó. Próxima acción: enviar una prueba y revisar la bandeja de recepción.
La IA empezó por lo que dice el archivo. Compara la respuesta con el archivo, línea por línea.
Toca o haz clic en los dos botones del recuadro y compara el mismo lunes.
2Las cuatro partes de un handoff
Un buen handoff cabe en una pantalla. Dice dónde se detuvo el trabajo, qué se decidió, qué quedó pendiente y cuál es la próxima acción.
Carla escribe el suyo cada viernes, al cerrar el informe de la semana. Le lleva cinco minutos.
handoffs/latest.md · informe de Carla
1 Dónde quedó: informe de la semana generado en la carpeta "relatorios"
2 Decisiones: ciudades en orden alfabético; las hojas de cálculo originales no cambian
3 Pendientes: el total de pedidos aún no se comparó con la suma
4 Próxima acción: sumar la columna de pedidos de las 5 hojas de cálculo y comparar
1Dónde está el trabajo, con el nombre de la carpeta.
2Lo que no se vuelve a discutir.
3Lo que aún no se verificó.
4Un solo paso, que se puede hacer mañana temprano.
3La próxima acción debe ser exacta
La parte que más suele fallar es la última. "Continuar el formulario" no dice nada. Una buena próxima acción dice qué hacer, dónde y cómo saber si salió bien.
Rafael cambió la frase vaga por una que cualquier asistente puede seguir, incluso otro modelo.
Vaga
"Próxima acción: continuar el formulario."
Exacta
"Próxima acción: enviar un mensaje de prueba desde la página de contacto y revisar la bandeja de entrada de recepción. Si no llega, revisar el envío en contato.html."
Balance: la nueva conversación empieza con el paso correcto, sin hacer preguntas.
Si te trabaste aquí, es normal¿No sabes cuál es la próxima acción? Escribe la pregunta que falta responder, como "descubrir por qué no llega el mensaje". Una pregunta clara también sirve.
4Pídele el handoff a la propia IA y revísalo
Al final de la sesión, pídele al asistente que escriba el handoff. Tiene a mano los detalles de la conversación, pero se equivoca. Después, léelo y corrígelo: tú respondes por lo que dice.
Una precaución: el handoff registra lo que pasó. No autoriza a la próxima conversación a enviar, publicar ni borrar nada por su cuenta.
Carla pide el handoff antes de cerrar. La primera vez, la IA escribió "total verificado". Carla no lo había verificado y lo corrigió a "pendiente".
Fin de la sesión
CarlaAntes de terminar, escribe el handoff en handoffs/latest.md con: dónde quedó, decisiones, pendientes y la próxima acción exacta. Marca como pendiente todo lo que yo no haya verificado.
IAHandoff guardado. Pendientes: el total de pedidos no se comparó con la suma de las hojas de cálculo. Próxima acción: sumar la columna de pedidos de las hojas de cálculo y comparar con el total del informe.
"Marca como pendiente lo que yo no haya verificado" evita que el handoff diga más de lo que pasó.
Practica ahora 0/3
El handoff de tu piloto
Listo cuando el archivo latest.md, dentro de la carpeta handoffs del piloto, tenga las cuatro partes. Unos 10 minutos, en la computadora: este módulo requiere una computadora.
Es solo un archivo de texto tuyo. ¿No hiciste el piloto de los módulos anteriores? Usa cualquier trabajo que vayas a retomar mañana. Archivo nuevo en Windows: haz clic derecho en la carpeta › Nuevo › Documento de texto y cámbiale el nombre (la lección 5 muestra los pasos). Primero activa Ver › Mostrar › Extensiones de nombre de archivo; si no, el archivo termina como latest.md.txt. También puedes pedirle al asistente: "crea handoffs/latest.md con esta plantilla".
# Handoff — <fecha>
## Dónde se detuvo
<qué se hizo y en qué carpeta o archivo está>
## Decisiones
- <qué no se vuelve a discutir>
## Pendientes
- <qué aún no se ha verificado>
## Próxima acción
<un paso exacto: qué, dónde y cómo saber si salió bien>
Ya dejas el trabajo listo para que cualquier conversación lo retome.
Resumen de bolsillo
Handoff
Relevoun archivo breve al final de cada sesión.
Cuatro partesdónde se detuvo, decisiones, pendientes, próxima acción.
Registro, no ordenquien llega lo lee; no empieza a hacer cosas.
Tu próximo paso
Ya sabes cómo cerrar una sesión sin perder lo acordado.
En la próxima sesión de trabajo con IA, pide el handoff antes de cerrar y corrige una línea que diga más de lo que pasó.
En la próxima lección: el handoff está escrito. ¿Cómo hacer que la nueva conversación lo lea y lo verifique antes de actuar?
Lección 21 · Dev con IA v6.2 · INEMA.CLUB
Módulo 5 · Lección 2 de 5
Prime: leer y verificar antes de actuar
Puedes pedirle a una nueva conversación un resumen del proyecto con las fuentes y las contradicciones antes de que modifique cualquier archivo.
El handoff solo ayuda si alguien lo lee. Y leer no basta: la nueva conversación necesita mostrarte lo que entendió, para que lo verifiques antes de que actúe. En este curso, este primer pedido se llama prime. No es un comando de la herramienta: es un texto que pegas.
En 1 minuto
El prime es el primer pedido de la sesión: lee los archivos y dime en qué punto estamos.
La respuesta contesta cinco preguntas e indica el archivo de cada respuesta.
Solo lectura. En esta etapa nadie envía, publica ni borra nada.
1El primer pedido es «lee y dime»
El prime complementa el handoff. Uno se escribe al final de la sesión; el otro se lee al comienzo de la siguiente.
En vez de decir «continúa», pides: lee estos archivos, no cambies nada y dime en qué punto estamos.
Carla siempre abre la conversación del lunes con el mismo pedido, guardado en un archivo de texto. Lo copia, lo pega y espera el resumen.
Conversación nueva, lunes
CarlaLee briefing.md y handoffs/latest.md. No modifiques ningún archivo. Dime: el objetivo, una regla, la última decisión, la próxima acción y cualquier contradicción, e indica el archivo de cada dato.
IAObjetivo: informe semanal de pedidos por ciudad (briefing.md). Regla: no modificar las hojas de cálculo originales (briefing.md). Última decisión: ciudades en orden alfabético (latest.md). Próxima acción: sumar la columna de pedidos y comparar con el total (latest.md). Contradicciones: no encontré ninguna.
Cada dato viene con el archivo del que salió. Así puedes verificarlo.
2Las cinco preguntas del prime
Un buen prime siempre responde las mismas cinco preguntas. El objetivo viene del briefing; la decisión y la próxima acción vienen del handoff. Si alguna respuesta está equivocada, el problema está en el archivo, no en la próxima tarea.
Rafael revisa el resumen en un minuto: compara cada línea con el handoff que él mismo escribió el viernes.
Lo que devuelve el prime
1 Objetivo y criterios de aceptación
2 Una regla, con el archivo de origen
3 La última decisión tomada
4 La próxima acción exacta
5 Contradicciones entre los archivos
1Viene de briefing.md.
2Muestra si leyó las reglas, no solo el handoff.
3Viene del handoff.
4Viene del handoff.
5Es donde el prime más ayuda.
3El prime solo lee; tú decides cuál es el próximo paso
El handoff es un registro del pasado, no un pedido nuevo. Si dice «falta enviar el informe», la nueva conversación no lo envía por su cuenta. Lo resume y te espera.
Una vez, el asistente de Rafael leyó «próxima acción: publicar la página» y empezó a publicarla de inmediato. Desde entonces, su prime dice «no cambies nada y espera mi orden».
Leyó y empezó a hacer cosas
«Vi en el handoff que falta publicar. Publicaré la página ahora».
Leyó, resumió y esperó
«El handoff indica que publicar la página es la próxima acción. Espero tu confirmación».
La frase «no cambies nada» en el prime separa leer de actuar.
Si te trabaste aquí, es normal¿Parece demasiada desconfianza hacia la IA? Es el mismo cuidado de quien llega al turno: primero lee y verifica, después hace cambios.
4Encontrar una contradicción vale oro
Cuando dos archivos dicen cosas distintas, el prime lo señala. Es mejor descubrirlo en el resumen que a mitad del trabajo.
Otra semana, el briefing de Carla pedía ciudades en orden alfabético. El handoff de esa semana registraba «ordenar por total de pedidos». El prime mostró el conflicto y ella decidió en diez segundos.
Respuesta del prime
IAContradicción: briefing.md pide ciudades en orden alfabético; handoffs/latest.md registra «ordenar por total de pedidos». ¿Cuál tiene prioridad?
CarlaTiene prioridad el orden alfabético. Corrige el handoff.
La duda surgió antes del trabajo, no después de que el informe estuviera listo.
Ponte a prueba
El prime respondió con una próxima acción que no aparece en ningún archivo. ¿Qué indica esto?
Practica ahora 0/3
Haz el prime de tu piloto
Está listo cuando una nueva conversación haya devuelto el resumen con las fuentes y hayas verificado cada línea. Cerca de 10 minutos, en la computadora: este módulo requiere la computadora.
El pedido prohíbe modificar archivos: solo es de lectura. ¿No tienes el handoff de la lección 21? Borra la línea del handoff del pedido y hazlo solo con el briefing.md de la lección 5, que está en la carpeta del piloto. Si tu archivo es briefing.txt, cambia el nombre en el pedido. Si la IA empieza a modificar algo, haz clic en el botón para detenerla (o presiona la tecla Esc).
Lee briefing.md y handoffs/latest.md, en ese orden.
No modifiques ningún archivo ni ejecutes nada.
Dime, citando el archivo de cada dato:
1. El objetivo y los criterios de aceptación.
2. Una regla, con el archivo de origen.
3. La última decisión.
4. La próxima acción exacta.
5. Cualquier contradicción entre los archivos.
Después, espera mi orden.
Ya empiezas una sesión sabiendo lo que entendió la IA, antes de que modifique algo.
Resumen de bolsillo
Prime
Primer pedidolee los archivos, no modifiques nada, dime en qué punto estamos.
Con fuentecada dato del resumen señala el archivo.
Espera la ordenel handoff es un registro, no una autorización.
Tu próximo paso
Ya verificas lo que entendió la conversación nueva antes de que trabaje.
Guarda el pedido de prime en un archivo de texto en la carpeta del piloto, para pegarlo siempre igual.
En la próxima lección: briefing, handoff, reglas. ¿Dónde está cada archivo y quién pide leerlo?
Lección 22 · Dev con IA v6.2 · INEMA.CLUB
Módulo 5 · Lección 3 de 5
Lo que importa vive en el proyecto, no en la herramienta
Puedes preparar, en la carpeta del piloto, los archivos mínimos y el orden de lectura que debe seguir cualquier asistente.
Las instrucciones, decisiones y tareas guardadas solo en la memoria de una herramienta quedan atadas a ella. Al cambiar de asistente, lo pierdes todo. Si las guardas en archivos de texto en el proyecto, cualquier asistente puede leerlas.
En 1 minuto
Lo que es tuyo vive en archivos de texto en la carpeta del proyecto.
El AGENTS.md indica las reglas y el orden de lectura.
Los nombres de las carpetas se acuerdan; quien pide la lectura es el AGENTS.md.
1Memoria de la herramienta × archivos del proyecto
Cada asistente guarda las cosas a su manera: memoria propia, historial de conversaciones, archivo de instrucciones. Esto funciona mientras usas solo ese asistente.
Cuando el conocimiento está en archivos de texto dentro de la carpeta del proyecto, el asistente pasa a ser solo quien ejecuta. Cambiar de asistente o de modelo deja de poner en riesgo tu trabajo.
Rafael tenía las reglas del sitio de la clínica solo en CLAUDE.md y en la memoria de Claude Code, que Codex no busca. Cuando probó Codex, tuvo que explicar todo de nuevo y olvidó dos reglas.
Atado a la herramienta
Reglas en la memoria de un asistente. Decisiones dispersas en conversaciones antiguas.
Al cambiar: explicar todo de nuevo.
En el proyecto
Reglas, tarea y handoff en archivos de texto en la carpeta del piloto.
Al cambiar: el otro asistente lee los archivos.
2Los archivos mínimos
No necesitas muchas cosas. Cinco archivos cubren el piloto: reglas, objetivo, tarea, contexto y entrega del turno.
Carla armó la carpeta del informe así en quince minutos. Ya tenía dos de esos archivos: el briefing y el handoff.
Carpeta del piloto de Carla
1 AGENTS.md
2 briefing.md
3 tasks
current.md
4 context
overview.md
5 handoffs
latest.md
1Reglas estables y orden de lectura.
2Objetivo, qué incluye y qué queda fuera, criterios y límites (lección 5).
3La tarea actual y lo que falta.
4Datos verificados del proyecto, con la fuente.
5La entrega del turno (lección 21).
3AGENTS.md es quien pide la lectura
Los nombres de las carpetas son solo un acuerdo. Ningún asistente abre "tasks" por su cuenta. Quien pide la lectura es AGENTS.md, con el orden de lectura justo al inicio. El asistente suele seguirlo; el prime de la lección 22 comprueba si lo siguió.
Codex lee AGENTS.md por su cuenta al empezar. Claude Code lee CLAUDE.md. Para que siga las mismas reglas, pon en CLAUDE.md la línea @AGENTS.md.
Rafael escribió las reglas una sola vez, en AGENTS.md. Su CLAUDE.md tiene una línea, y los dos asistentes siguen las mismas reglas.
AGENTS.md · sitio de la clínica
1 Orden de lectura: briefing.md, tasks/current.md, handoffs/latest.md
2 Regla: no modificar la página de inicio ni los colores
3 Regla: nada se publica sin la aprobación de Rafael
4 CLAUDE.md, al lado, con una línea: @AGENTS.md
1Qué leer y en qué orden.
2Lo que queda "Fuera" para todas las tareas.
3La decisión final es humana.
4Así Claude Code lee el mismo archivo.
Si te trabaste aquí, es normal¿Tu asistente no es ninguno de los dos? Está bien. En el primer pedido, escribe "lee el AGENTS.md antes de todo". En un chat común, que no puede abrir la carpeta, pega el AGENTS.md y después cada archivo en el orden de lectura, uno debajo del otro, con el nombre del archivo arriba.
4Cada archivo tiene un responsable
Un archivo sin responsable se vuelve un caos: la IA cambia una regla que era tuya o tú olvidas actualizar la tarea. Acuerden quién modifica qué.
Carla dejó claro en el AGENTS.md: solo ella cambia las reglas y decisiones; la IA escribe el handoff y ella lo revisa.
Tú decides
AGENTS.md, briefing.md y las decisiones. La IA puede sugerir cambios; quien los aprueba eres tú.
La IA escribe, tú revisas
handoffs/latest.md al final de la sesión y el avance en tasks/current.md.
Las dos tarjetas conviven: una guarda lo que es estable, la otra registra el día a día.
Practica ahora 0/3
Arma el núcleo de tu piloto
Está listo cuando la carpeta del piloto tenga AGENTS.md con el orden de lectura, tasks/current.md y handoffs/latest.md. Unos 12 minutos, en la computadora: este módulo requiere la computadora. Empieza por los tres; context/overview.md se agrega cuando haya datos verificados para registrar.
Son tus archivos de texto; no se borra nada. Para crear una carpeta en Windows: clic derecho › Nuevo › Carpeta. Para crear un archivo: como briefing.md de la lección 5. ¿No tienes el handoff de la lección 21? Crea el archivo con la frase "primera sesión".
# AGENTS.md — <nombre del piloto>
Orden de lectura: 1) briefing.md 2) tasks/current.md 3) handoffs/latest.md
Lee antes de actuar. No se envía ni publica nada sin mi aprobación.
## Reglas
- <lo que aplica a todas las tareas>
## Responsables
- AGENTS.md, briefing.md y decisiones: solo yo los cambio.
- handoffs/latest.md: la IA lo escribe al final de la sesión y yo lo reviso.
Ya tienes el conocimiento del piloto en un lugar que cualquier asistente puede leer.
Resumen de bolsillo
El cerebro en el proyecto
Archivos de textolo que es tuyo está en la carpeta, no en la herramienta.
AGENTS.mdreglas y orden de lectura; CLAUDE.md apunta a él.
Responsablestú decides las reglas; la IA escribe el handoff.
Tu próximo paso
Ya armaste el núcleo que hace que el piloto no dependa de un solo asistente.
Lee el AGENTS.md que escribiste como si fueras otra persona. Quita una regla que solo tú entiendes.
En la próxima lección: con todo en los archivos, pasar el piloto de un asistente a otro sin volver a empezar.
Material complementario · Migrar o mantenerse independienteProfundización del tema. No cuenta en el tiempo de la lección.
El núcleo completo
El kit agente-claude-codex usa siete lugares, cada uno con un responsable: AGENTS.md (reglas y orden de lectura), context/overview.md (datos verificados, con fuente y fecha), context/current-state.md (lo que funciona y lo que está pendiente), context/sources.md (de dónde viene cada información), context/decisions/ (una decisión aceptada por archivo), tasks/current.md (objetivo, responsable, criterio para darlo por listo, próxima acción) y handoffs/latest.md (la continuación para la próxima sesión).
Separar hechos, preferencias, hipótesis y decisiones
Mezclar hechos con hipótesis, o decisiones con preferencias, hace que el asistente repita errores antiguos y contradiga lo que ya se resolvió. Una información solo pasa de recuerdo suelto a contexto aprobado con tu aprobación.
Migrar todo de un asistente a otro
Llevar instrucciones, skills y memoria de un asistente a otro es el tema del curso Claude → Codex: auditar, adaptar, probar en una sesión nueva y hacer handoff.
Puedes pasar tu piloto de un asistente a otro con handoff y prime, y comprobar que el nuevo entendió antes de que trabaje.
Vas a cambiar de asistente. Se acaba el límite de uso, otro hace mejor una parte o quieres una mirada externa. Sin método, el cambio cuesta una hora de explicación. Con los archivos de la lección 23, cuesta diez minutos.
En 1 minuto
En el asistente que sale: handoff. En el que entra: prime.
Antes de dejarlo trabajar, comprueba las cinco preguntas del prime (lección 22).
Una respuesta incorrecta en el prime casi siempre se debe a un archivo impreciso. Corrige el archivo.
1El cambio va a ocurrir
Nadie usa un modelo para siempre. El uso de la cuenta se acaba a mitad de semana, el precio cambia o otro asistente hace mejor una parte del trabajo.
Un buen cambio no depende de la memoria. Se hace mediante los archivos: el handoff de quien sale y el prime de quien entra.
El miércoles apareció el aviso de que el límite de uso de Claude de Rafael estaba cerca. Pidió el handoff en ese momento y siguió en Codex. Si el límite ya se hubiera acabado, escribiría a mano las cuatro líneas del handoff.
Empezar de nuevo explicando
Contarle el proyecto de memoria al nuevo asistente. Una hora y dos reglas olvidadas.
Handoff y prime
El nuevo lee los archivos, resume con las fuentes y Rafael comprueba. Diez minutos.
2El proceso del cambio, en cuatro pasos
El orden importa. Primero el registro, después la lectura, luego la comprobación. Solo entonces, el trabajo.
Carla tiene Codex y un chat de IA. Hace el cambio al revés: Codex prepara el informe y, para revisarlo, pasa al chat en una conversación nueva y pega los archivos.
Cambiar de asistente
1 En el que sale: pide el handoff y revísalo
2 En el que entra: prime, sin cambiar nada
3 Revisa el resumen con las cinco preguntas
4 Solo entonces: "puedes seguir con la próxima acción"
1Lección 21.
2Lección 22.
3Las mismas cinco de la lección 22.
4El orden de trabajo lo decides tú.
3El prime también se ejecuta en el terminal, solo leyendo
Quien usa el terminal puede hacer el prime de Codex con una protección adicional: el modo de sandbox de solo lectura. Aunque quisiera, no podría cambiar archivos.
Rafael ejecuta el prime en la carpeta del sitio. La respuesta queda guardada en prime.md y él la lee con calma antes de autorizar el trabajo.
Terminal · carpeta del piloto
$ codex exec --sandbox read-only -o prime.md "Leia AGENTS.md e siga a ordem de leitura. Não altere nada. Responda as cinco perguntas do prime, com o arquivo de cada resposta."
...$ cat prime.md
-o guarda la última respuesta en un archivo. cat muestra ese archivo en la pantalla. Si la carpeta no usa Git, agrega --skip-git-repo-check: sin eso, codex exec se niega a ejecutarse.
En la app o en la extensión, el mismo pedido de prime de la lección 22 cumple la función de este comando.¿Y en Claude Code, desde el terminal?
El equivalente es claude -p --permission-mode plan "<el mismo pedido>" > prime.md. -p responde una vez y termina. El modo plan es el modo de planificación: lee, pero no cambia archivos.
4Las cinco preguntas antes de dejar que trabaje
El asistente que entró responde las cinco preguntas del prime, las mismas de la lección 22. Si una respuesta está equivocada, revisa primero los archivos. Casi siempre el problema está en un texto vago, como el briefing o el handoff, no en el modelo.
El Codex de Rafael se equivocó en la próxima acción: dijo "crear el formulario". El handoff solo decía "continuar". Rafael reescribió la próxima acción y volvió a ejecutar el prime.
Las cinco preguntas del prime
1 ¿Cuál es el objetivo y el criterio de aceptación?
2 Menciona una regla y el archivo de donde proviene.
3 ¿Cuál fue la última decisión?
4 ¿Cuál es la próxima acción exacta?
5 ¿Hay algún conflicto entre los archivos?
1Compruébalo con briefing.md.
2Verifica el AGENTS.md.
3Verifica el handoff.
4Verifica el handoff.
5Si los hay, tú decides cuál vale.
Si te trabaste aquí, es normal¿Cinco preguntas parecen muchas para cada cambio? Empieza por la 4. Si la próxima acción es correcta, las demás suelen serlo también.
Practica ahora 0/3
Pasa el piloto a otro asistente
Listo cuando el asistente que tomó el relevo haya respondido las cinco preguntas y hayas marcado cada una como correcta o incorrecta. Unos 10 minutos, en la computadora: este módulo requiere la computadora.
Todo aquí es lectura. ¿Solo tienes un asistente? Haz el cambio a una conversación nueva con ese asistente: el método es el mismo. ¿No tienes el AGENTS.md de la lección 23? Cambia la primera línea por "lee briefing.md y handoffs/latest.md".
Lee AGENTS.md y sigue su orden de lectura.
No cambies ningún archivo ni ejecutes nada.
Responde citando el archivo de cada respuesta:
1. ¿Cuál es el objetivo y el criterio de aceptación?
2. Cita una regla y el archivo del que proviene.
3. ¿Cuál fue la última decisión?
4. ¿Cuál es la próxima acción exacta?
5. ¿Hay algún conflicto entre los archivos?
Después, espera mi orden.
Ya puedes cambiar de asistente sin perder lo que sabe el piloto.
Resumen de bolsillo
Cambiar sin empezar de nuevo
Sale y entrahandoff en el que sale, prime en el que entra.
Cinco preguntasobjetivo, regla, decisión, próxima acción, conflicto.
Respuesta incorrectacorrige el archivo, no el asistente.
Tu próximo paso
Ya puedes pasar el trabajo de un asistente a otro y comprobar que lo entendió.
La próxima vez que aparezca el aviso de límite, haz el cambio siguiendo los cuatro pasos en vez de esperar a que vuelva el límite.
En la próxima lección: una segunda opinión dentro del mismo asistente y el laboratorio que cierra el ciclo.
Lección 24 · Dev con IA v6.2 · INEMA.CLUB
Módulo 5 · Lección 5 de 5
Segunda opinión y el ciclo handoff → prime
Puedes completar en tu piloto el ciclo entero: handoff en una sesión, prime en una sesión nueva, revisión y una segunda opinión.
En las cuatro lecciones anteriores viste las piezas: handoff, prime, archivos en el proyecto y cambio de asistente. Ahora se convierten en rutina. Y el mismo ciclo te da, de paso, una segunda opinión sin necesitar otro asistente.
En 1 minuto
Conversación nueva + prime + "señala fallas" = segunda opinión en el mismo asistente.
En Claude Code está /advisor, que cobra aparte. Verifica antes de usarlo.
El ciclo diario: sesión, handoff, prime, verificar.
1Segunda opinión dentro del mismo asistente
Una conversación nueva no carga con el apego de la anterior. Con el prime, lee el briefing, el handoff y el trabajo real. Entonces pides la crítica: fallas, con el fragmento que muestra cada una.
Es la revisión cruzada del módulo 1, hecha con lo que ya tienes. Otro modelo revisa con aún menos apego, cuando tengas acceso.
Carla tiene Codex y un chat de IA. Esta vez, revisó sin salir de Codex: abrió una conversación nueva, hizo el prime y pidió la crítica.
Conversación nueva, después del prime
CarlaAhora lee relatorios/semana.md y señala fallas frente a los criterios de aceptación de briefing.md, con el fragmento que muestra cada una. No cambies nada.
IAFalla 1: el criterio 2 de briefing.md dice "Cada ciudad aparece una vez, con su total". En la tabla de totales de relatorios/semana.md, la ciudad Pelotas aparece en dos filas.
El criterio viene del briefing de Carla, desde la lección 3. Abrió el informe y comprobó que sí eran dos filas.
2El /advisor de Claude Code: primero, descubre qué hace
En Claude Code existe el comando /advisor, seguido del nombre de un modelo. Activa un modelo más potente, al que el modelo principal consulta durante la sesión. El mismo comando cambia de asesor o lo desactiva.
Dos precauciones. El propio Claude Code avisa que el asesor cobra créditos de uso aparte. Y Codex no tiene ese comando. La conversación nueva con prime funciona en cualquier asistente, sin costo extra.
Rafael escribió /advisor en Claude Code y leyó el aviso de cobro. Para la prueba piloto, se quedó con la conversación nueva; deja el asesor para un error difícil.
Funciona en cualquiera
Conversación nueva, prime con los archivos, pedido de fallas con evidencia.
Solo en Claude Code, con costo
El /advisor: un modelo más potente al que se consulta durante la sesión, con cobro aparte. Comprueba el costo antes.
Empieza por la tarjeta "Funciona en cualquiera". La otra opción se usa cuando el costo valga la pena.
3El ciclo diario
Al juntar todo, el día de trabajo con IA tiene cuatro momentos. Es el mismo en cualquier asistente, porque solo depende de archivos de texto.
Rafael cierra cada sesión con el handoff y abre cada sesión con el prime. Dice que perdió el miedo a cerrar la conversación.
El ciclo diario
1 Sesión: trabajar en la próxima acción
2 Handoff: guardar y revisar handoffs/latest.md
3 Prime: una conversación nueva lee y resume, sin cambiar nada
4 Verifica: cinco preguntas y solo entonces empieza a trabajar
1El trabajo en sí.
2Antes de cerrar, siempre.
3Al abrir, siempre.
4Vuelve al 1.
Si te trabaste aquí, es normal¿Parece demasiado ritual para una tarea de media hora? Para tareas cortas, basta con el handoff de una línea: la próxima acción exacta.
4El laboratorio: el ciclo en tu piloto
El laboratorio del módulo reúne las cinco lecciones en una sola pasada. El resultado es el piloto listo para que cualquier asistente lo retome cualquier día.
Carla hizo el laboratorio un viernes y lo retomó el lunes. El prime acertó las cinco preguntas al primer intento.
Sin el ciclo
Cada lunes empieza con «¿dónde me había quedado?», y la IA repite las preguntas.
Con el ciclo
Cada lunes empieza con un resumen verificado y la próxima acción exacta.
Balance: diez minutos de handoff y prime en lugar de media hora de reconstrucción.
Practica ahora 0/4
Laboratorio: cierra el ciclo en el piloto
Está listo cuando una conversación nueva haya acertado las cinco preguntas y verificado cada criterio de aceptación con el fragmento correspondiente, marcando «fallo» o «ok». Que no haya fallos también es un resultado. Unos 12 minutos, en la computadora: este módulo requiere la computadora.
Todo es lectura, excepto el handoff, que es un archivo tuyo. ¿No hiciste las lecciones anteriores? Usa briefing.md de la lección 5 y un handoff de una línea. Si la IA empieza a cambiar algo, haz clic en el botón para detenerla.
Lee AGENTS.md y sigue el orden de lectura que indica.
No cambies ningún archivo ni ejecutes nada.
Responde citando el archivo de cada respuesta:
1. ¿Cuál es el objetivo y el criterio de aceptación?
2. Cita una regla y el archivo del que proviene.
3. ¿Cuál fue la última decisión?
4. ¿Cuál es la próxima acción exacta?
5. ¿Hay algún conflicto entre los archivos?
Después, para cada criterio de aceptación de briefing.md,
di «ok» o «fallo», con el fragmento del trabajo que lo demuestra.
Cerraste el módulo 5 con un piloto que cualquier asistente puede retomar y revisar.
Resumen de bolsillo
Ciclo y segunda opinión
Segunda opiniónconversación nueva, prime y pedido de fallos con fragmentos.
Comando nuevoverifícalo con tu asistente antes de usarlo.
Ciclo diariosesión, handoff, prime, verificar.
Tu próximo paso
Ya trabajas con IA sin depender de la memoria de una conversación o de una herramienta.
Mañana, empieza el día con el prime del piloto y cronometra cuánto tardas en llegar a la primera acción.
En el módulo 6: ¿cuánto costó todo esto? Modelo, esfuerzo y presupuesto por etapa.
Material complementario · Handoff y prime en los kitsProfundización del tema. No cuenta en el tiempo de la lección.
Nivel 6 de Use Both
El kit Use Both llama a esto «handoff y prime»: el handoff guarda el estado en un archivo portátil; el prime hace que el siguiente asistente lea y verifique ese estado antes de continuar. En el kit agente-claude-codex, cada handoff se convierte en una captura con fecha en handoffs/history/, que nunca se sobrescribe, y handoffs/latest.md es la copia más reciente.
El /advisor en Claude Code
El comando /advisor, seguido del nombre de un modelo, define un modelo consejero que el principal consulta durante la sesión. El consejero debe ser al menos tan capaz como el modelo principal, y su uso se cobra en créditos aparte. La síntesis del INEMA presenta el uso para investigar cuellos de botella como una orientación que debes verificar: prueba con una tarea tuya y compara con una conversación nueva con prime.
Puedes comparar dos modelos en una tarea tuya, con tus criterios de aceptación, y decir cuál dio mejores resultados en esa tarea.
Cada semana aparece una lista de «la mejor IA del momento». Responde a una pregunta general. Tu pregunta es otra: cuál da mejores resultados en esta tarea, con tu cuenta, hoy.
En 1 minuto
El ranking es el promedio de muchas tareas. La tuya es una sola.
Compara con la misma tarea, las mismas instrucciones y el mismo criterio.
Cuenta los criterios que se cumplieron, no el tono de la respuesta.
1El ranking no responde a tu pregunta
Un modelo al que le va bien en promedio puede irle mal en tu tarea. Y los nombres cambian rápido. En septiembre de 2026, los más mencionados en las fuentes de este curso eran Claude Opus 5.5 y GPT-6 Astra.
Dentro de unos meses serán otros. La forma de elegir sigue siendo la misma.
Rafael leyó que un modelo «era el mejor para programar». En el formulario de la clínica, ese modelo entregó el campo de teléfono aceptando letras.
La pregunta que haces
Rafael¿Cuál es el mejor modelo para programar?
IADepende del uso. Varios modelos se destacan en programación, cada uno con diferentes puntos fuertes.
Una pregunta general recibe una respuesta general.
RafaelLas mismas instrucciones para los dos modelos. ¿Cuál cumplió los tres criterios de aceptación del formulario?
Ficha de RafaelModelo A: 3 de 3. Modelo B: 2 de 3; le faltó rechazar letras en el teléfono.
La respuesta viene de tu revisión, no de la opinión de alguien.
Toca o haz clic en los dos botones del cuadro y compara las dos preguntas.
2Misma tarea, mismo briefing, mismos criterios
Una comparación justa cambia una sola cosa: el modelo. El pedido, el material y los criterios quedan iguales. Si cambias dos cosas, no sabes cuál marcó la diferencia.
Los criterios son los que ya tienes: el criterio de aceptación de tu briefing. ¿No hiciste el briefing de la lección 5? Escribe ahora tres criterios de sí o no para la tarea.
Carla hizo las dos rondas en Codex, con la misma carpeta de hojas de cálculo y el mismo briefing. Entre una y otra, solo cambió el modelo, en el selector cerca de su nombre.
Comparación de Carla
1 Mismo pedido: briefing.md del informe semanal
2 Mismo material: copia de las hojas de cálculo de la semana
3 Mismos criterios: los tres criterios de aceptación
4 Solo cambia: el modelo, en la misma herramienta
1El mismo archivo para ambos.
2Una copia para cada uno, para que uno no modifique la del otro.
3Escritos antes de ver las respuestas.
4La única diferencia entre las dos rondas.
Si te trabaste aquí, es normal¿No sabes dónde cambiar el modelo? En Claude Code, el comando /model muestra los modelos de tu cuenta; en la app, busca el selector cerca del nombre del modelo. ¿Solo tienes acceso a uno? Compara el mismo modelo en dos conversaciones nuevas, con el mismo pedido: ya aprenderás a usar los criterios.
3Cuenta los criterios, no el tono
Una respuesta cuidada, con títulos y frases seguras, parece mejor. Los criterios preguntan otra cosa: ¿cumplió o no cumplió cada uno?
El informe del primer modelo tenía un gráfico y un texto bonito, pero repetía una ciudad. El del segundo era sencillo y cumplió los tres criterios.
Más bonita
Apariencia: gráfico, títulos, resumen elegante.
Criterios: 2 de 3. Una ciudad aparece dos veces.
Cumplió los criterios
Apariencia: una tabla sencilla.
Criterios: 3 de 3. El total coincide, las ciudades son únicas y la fuente está abajo.
Balance: la elección sale de la ficha, no de la primera impresión.
4La elección vale para esa tarea, con fecha
El resultado de la comparación vale para ese tipo de tarea, en ese mes. Anota la tarea, el modelo, los criterios que cumplió y la fecha. Cuando cambie el modelo, el precio o la tarea, compara de nuevo.
Rafael guarda una línea por comparación en un archivo escolhas.md, en la carpeta del piloto. En tres meses, ya sabe qué modelo usa para cada tipo de pedido.
Qué anotar
28/09/2026 · formulario de contacto · modelo A 3 de 3, modelo B 2 de 3 · se queda el A.
Cuándo volver a comparar
Un modelo nuevo, un precio nuevo o una tarea de otro tipo.
Una línea por comparación ya se convierte en historial.
Ponte a prueba
Carla quiere saber qué modelo usar en el informe semanal. ¿Qué hace primero?
Practica ahora 0/3
¿Qué modelo se queda con esta tarea?
Listo cuando hayas respondido las tres preguntas del caso. Unos 10 minutos, en papel o en el bloc de notas.
Solo tienes que leer un caso. Si tienes dudas, vuelve a la vara: cuenta lo que cumplió, no lo que parece mejor.
El caso. Rafael dio la misma descripción a dos modelos para la página de precios de un cliente. Criterios: aparecen los tres planes; el botón lleva al pago; en el celular, la página no se desplaza hacia los lados. El modelo A entregó una página bonita: aparecen los tres planes y no se desplaza hacia los lados, pero el botón no abría nada. El modelo B entregó una página sencilla que cumplió los tres criterios. Usó un pedido un poco diferente para el B.
Ver respuestas
1. A: 2 de 3. B: 3 de 3. 2. No fue justa: el pedido para B era diferente. 3. Repite la prueba de A con el mismo pedido que usó para B, vuelve a comparar y solo entonces anota la línea con la fecha.
Ya comparas modelos con la vara de tu tarea, no con su fama.
Resumen de bolsillo
Elegir un modelo
Tu tareael ranking es un promedio; la pregunta es la tuya.
Una diferenciael mismo pedido y material; solo cambia el modelo.
Con fechaanota la elección y vuelve a probar cuando algo cambie.
Tu próximo paso
Ya eliges el modelo con evidencia de tu propia tarea.
Crea el archivo escolhas.md en la carpeta del piloto y escribe la primera línea, aunque sea solo del modelo que has usado hasta ahora.
En la próxima lección: dentro del mismo modelo hay otro control, el esfuerzo. ¿Cuándo vale la pena aumentarlo y cuándo es un desperdicio?
Material complementario · Ruta inicial, no rankingAmpliación del tema. No cuenta en el tiempo de la lección.
Qué dicen las fuentes
El área Codex + Claude de Eventos INEMA registra que el video de Mark Kashef menciona Claude Opus 5.5 y GPT-6 Astra. La síntesis de INEMA del 27 de septiembre de 2026 menciona los mismos nombres, pero destaca que los modelos, el acceso y los cobros varían. La recomendación es comparar la calidad de la entrega en la tarea concreta, en vez de establecer una regla universal sobre cuál es mejor.
La tarjeta de rutas del kit Use Both (Claude/Opus planifica, Codex critica; Claude construye, Codex revisa lo que cambió) es una preferencia inicial registrada en el video de Mark Kashef. El área Codex + Claude de Eventos INEMA advierte: son elecciones editoriales, no un ranking medido. Experimenta y quédate con la ruta que produzca mejor evidencia en tu tarea.
Puedes marcar el esfuerzo alto, medio o bajo para cada paso del ciclo de tu piloto y explicar por qué.
Mucha gente deja el esfuerzo al máximo para todo, por seguridad, o al mínimo, para ahorrar. Ambas decisiones tienen un costo: una en tiempo y uso de la cuenta, la otra en errores en las partes difíciles.
En 1 minuto
El esfuerzo es un control distinto del modelo: cuánto piensa antes de responder.
Planificar y resolver un problema difícil requieren un esfuerzo medio o alto. Para tareas rutinarias, necesitas menos.
Más esfuerzo no hace aparecer el archivo que falta.
1Modelo y esfuerzo son dos controles
El modelo es qué IA hace el trabajo. El esfuerzo de razonamiento es cuánto analiza antes de responder. Puedes cambiar uno sin cambiar el otro.
Rafael usa el mismo modelo todo el día. Lo que cambia es el esfuerzo: alto para planificar el área de acceso, bajo para cambiar los textos de los botones.
Modelo
Qué IA hace el trabajo. Cámbialo cuando la comparación de la lección 26 muestre que otra ofrece mejores resultados.
Esfuerzo
Cuánto analiza. Súbelo o bájalo en cada etapa, con el mismo modelo.
Son dos botones distintos. La lección de hoy trata del segundo.
2Dónde subirlo: al planificar, ante un problema difícil y en una revisión exhaustiva
Sube el esfuerzo cuando un error cuesta caro o hay muchas partes que debes considerar a la vez. Planificar, buscar un error que nadie encuentra y revisar un cambio grande son tareas para las que conviene subirlo.
El cuadro recorre el ciclo completo, desde el briefing hasta el handoff.
Carla pidió un esfuerzo alto solo al planificar cómo unir hojas de cálculo con columnas diferentes. El resto del trabajo se hizo con un esfuerzo medio.
Ciclo del piloto · esfuerzo por paso
1 Definir el briefing: tú lo escribes; la IA solo lo revisa, con esfuerzo medio
2 Planificar y criticar: esfuerzo medio o alto
3 Construir: esfuerzo medio; para las partes repetitivas, bajo
4 Revisar y comprobar: esfuerzo medio; para un cambio grande, alto
5 Registrar el handoff: esfuerzo bajo
1El criterio es tuyo; la IA solo señala los puntos débiles.
2Un mal plan arruina todo lo demás.
3Sigue el plan; sube el esfuerzo solo si te trabas.
4Cuanto mayor sea el cambio, más esfuerzo debes poner en la revisión.
5Resumir lo que ya existe es una tarea rutinaria.
3Dónde bajarlo y dónde no te ayuda el esfuerzo
Las tareas rutinarias, como cambiar nombres, dar formato o cambiar un texto, suelen quedar igual con menos esfuerzo, más rápido y con menos gasto. Comprueba que cumplan los criterios. Pero «el mínimo para todo» no es una regla segura: las partes difíciles salen peor.
Y hay un límite: si faltó la hoja de cálculo o el criterio, ningún esfuerzo lo resuelve. Primero el material, después el esfuerzo.
Carla subió el esfuerzo al máximo cuando el informe salió mal. Siguió mal: faltaba la hoja de cálculo del jueves en la carpeta.
Esfuerzo máximo, sin la hoja de cálculo
Pedido: "Piensa con calma y vuelve a hacer el informe."
Resultado: tardó el triple y el total siguió mal.
Esfuerzo medio, con la hoja de cálculo
Pedido: lo mismo, con la hoja de cálculo del jueves en la carpeta.
Resultado: total igual a la suma de las hojas de cálculo.
Balance: lo que faltaba era material, no razonamiento.
Si te trabaste aquí, es normal¿No sabes si la tarea es difícil? Empieza en medio. Sube el nivel solo si la respuesta falla en algún criterio por falta de análisis, y no por falta de material.
4Dónde se elige el esfuerzo
Cada herramienta muestra este control de una manera, y no todas lo muestran. En la app o en la extensión, cuando existe, está cerca del nombre del modelo. En el chat, puede aparecer como "razonamiento", "pensar más" o "pensamiento extendido"; a veces solo se activa o se desactiva. En el terminal, va en el propio comando.
Rafael pide la crítica del plan con esfuerzo alto y la lista de los textos de los botones con esfuerzo bajo, cada una en su propio comando.
Dónde está el control
1 App o extensión: cerca del nombre del modelo, cuando existe
2 Chat: "razonamiento", "pensar más" o "pensamiento extendido"
3 Terminal: en el propio comando, como en el cuadro de abajo
1A veces son niveles; a veces, un menú.
2Muchas veces solo se activa o se desactiva.
3El nivel se escribe junto con el pedido.
¿No encontraste el control? La herramienta decide por su cuenta. Lo demás de la lección sigue siendo válido: material primero, criterio después.
Terminal
$ codex exec -c model_reasoning_effort=high "Leia plan-v1.md e aponte falhas com evidência."
$ claude -p --effort low "Liste os textos de botão que aparecem em contato.html."
En Codex, el esfuerzo es model_reasoning_effort (de minimal a high; algunos modelos aceptan más), escrito en el config.toml de Codex o en el comando con -c. En Claude Code, es --effort (low, medium, high, xhigh o max).
El mismo modelo, dos niveles de esfuerzo, cada uno en la etapa que lo requiere.
Ponte a prueba
La IA se equivocó en el total del informe. Antes de subir el esfuerzo, ¿qué revisas?
Practica ahora 0/3
El esfuerzo de cada paso de tu piloto
Listo cuando cada uno de los cinco pasos de tu piloto tenga un nivel y una frase que explique el motivo. Unos 8 minutos, en papel o en el bloc de notas.
Solo tomas notas; no se ejecuta nada. ¿No tienes piloto? Usa como ejemplo el formulario de Rafael o el informe de Carla.
Una respuesta razonable: briefing medio (solo revisión); planificar y criticar alto (un plan malo arruina lo demás); construir medio; revisar medio, alto si el cambio es grande; handoff bajo. El paso 4 sirve para revisar el material: ¿faltó un archivo? Arréglalo antes de subir el esfuerzo.
Ya distribuyes el esfuerzo por etapas, en vez de usar un botón fijo para todo.
Resumen de bolsillo
Esfuerzo por etapa
Dos controlesel modelo indica cuál IA; el esfuerzo indica cuánto analiza.
Súbeloen el plan, ante el problema difícil y en una revisión grande.
Material primeroel esfuerzo no reemplaza el archivo que faltó.
Tu próximo paso
Ya eliges el esfuerzo según la etapa, no por costumbre.
En el próximo pedido de rutina, baja el esfuerzo un nivel y revisa con los criterios si el resultado sigue igual.
En la próxima lección: ¿cuánto costó cada etapa de tu piloto, en tiempo y uso de la cuenta?
Material complementario · Lo que dice la síntesis sobre el esfuerzoProfundización del tema. No cuenta en el tiempo de la lección.
El esfuerzo, según las fuentes
La síntesis del INEMA del 27 de septiembre de 2026: la planificación y los problemas difíciles pueden justificar un esfuerzo medio o alto; las tareas rutinarias pueden requerir menos; una revisión compleja también puede necesitar más. El nivel mínimo para todo lo demás no es una regla segura.
El mensaje que dio origen al curso resume el motivo: ajustar el modelo y el esfuerzo a cada etapa evita gastar los recursos de una tarea compleja en acciones simples.
Fuentes: síntesis ejecutiva y mensaje del 27/09/2026, en los archivos de origen del curso, carpeta docs/.
Lección 27 · Dev con IA v6.2 · INEMA.CLUB
Módulo 6 · Lección 3 de 5
El costo sin resultados no dice nada
Puedes completar, para cada etapa de tu piloto, el tiempo, el uso de la cuenta y los problemas que se encontraron.
«Salió caro» y «valió la pena» suelen ser impresiones. Sin una medida sencilla, la decisión de la lección 30 se convierte en una opinión. Medir es anotar tres números por etapa, en el momento.
En 1 minuto
Por etapa, anota: tu tiempo, el uso de la cuenta y los problemas encontrados.
Tu tiempo cuenta, incluido el que dedicas a revisar.
Un problema encontrado antes de la entrega es el resultado que compraste con ese costo.
1Una fila por etapa
La medida cabe en una hoja de cálculo de ocho columnas. Una fila por etapa del ciclo, completada apenas termina la etapa. Después de una semana, nadie recuerda cuánto tiempo tomó.
Rafael abrió la hoja de cálculo piloto-custos en la carpeta del piloto y completó la fila del plan apenas terminó la crítica.
piloto-custos · columnas
1 Etapa
2 Modelo y esfuerzo
3 Tu tiempo (min)
4 Método anterior (min)
5 Uso antes
6 Uso después
7 Problemas encontrados (por quién)
8 Criterios que pasaron
1Qué paso del ciclo.
2Con qué configuración.
3Pedir, esperar, leer y comprobar.
4Cuánto tardarías sin IA; se acepta una estimación, marcada como "estimado".
5Qué muestra la página de uso antes.
6Y después de la etapa.
7Revisión, prueba o tú.
8Cuántos de cuántos.
2Tu tiempo cuenta
La IA responde en dos minutos, pero tú pasaste veinte leyendo y comprobando. El tiempo que cuenta es el tuyo, desde que haces el pedido hasta que lo compruebas. Es lo que paga tu hora de trabajo.
Carla anotaba solo la espera de la respuesta: tres minutos. Cuando incluyó la comprobación del total, la etapa pasó a durar veinticinco.
Solo la espera
Anotado: 3 minutos.
Conclusión: "la IA hace el informe en tres minutos".
Del pedido a la comprobación
Anotado: 25 minutos, con 15 de comprobación.
Conclusión: sigue siendo menos que las dos horas a mano.
Balance: la comparación honesta es con la forma anterior, incluida la comprobación. Por eso la hoja de cálculo tiene la columna "Forma anterior".
3Uso de la cuenta: la página de uso antes y después
El uso de IA se mide en tokens. No necesitas contarlos: basta con abrir la página de uso de la cuenta antes y después de la etapa y anotar la diferencia, en la unidad que muestra.
La página de uso está en la configuración de la cuenta, en el sitio del servicio (en inglés, "Usage"). La lección 4 mostró dónde buscar. ¿Es una cuenta de la empresa? Pídele la página de uso a quien la administra.
Rafael anotó el porcentaje del límite semanal de la suscripción antes y después de la crítica del plan. La crítica con esfuerzo alto usó mucho más que el intercambio de textos.
Línea de Rafael · crítica del plan
AntesUso de la semana: 18%
DespuésUso de la semana: 23%
En la hoja de cálculoCrítica del plan · esfuerzo alto · 5 puntos del límite semanal · 2 fallas encontradas
El número exacto importa menos que comparar las etapas entre sí.
Si te trabaste aquí, es normal¿Tu página de uso no muestra un número por tarea? Anota lo que muestra, antes y después. Si no aparece nada de eso, quédate solo con el tiempo: ya puedes comparar. Si otras personas usan la cuenta al mismo tiempo, eso distorsiona el antes y el después: anota "cuenta compartida" al lado.
4El resultado son los problemas encontrados
El costo por sí solo no dice si valió la pena. El otro lado de la cuenta son los problemas encontrados antes de la entrega, y quién los encontró: la revisión cruzada, la prueba o tú.
En la semana del piloto, la revisión de otro modelo detectó la ciudad repetida, y la prueba manual encontró el total incorrecto. Ambos habrían llegado a la dirección.
Costo
Tu tiempo y el uso de la cuenta en cada etapa.
Resultado
Problemas detectados antes de la entrega, criterios que se cumplieron.
Una etapa costosa que detectó dos errores puede valer más que una barata que no detectó nada.
Ponte a prueba
La etapa de revisión fue la que más consumió de la cuenta. ¿Qué revisas antes de quitarla?
Practica ahora 0/3
La hoja de cálculo de costos de tu piloto
Está lista cuando la hoja de cálculo tenga las columnas y al menos dos filas completas. Unos 10 minutos, en la computadora.
Es tu hoja de cálculo; no se envía nada. ¿No recuerdas el tiempo de una etapa anterior? Escribe una estimación y marca "estimado": a partir de ahora, anótalo en el momento.
Columnas (una por celda, en la primera fila):
Etapa | Modelo y esfuerzo | Tu tiempo (min) | Método anterior (min) | Uso antes | Uso después | Problemas detectados (por quién) | Criterios que se cumplieron
Ejemplo de Carla:
Informe semanal | Codex, medio | 25 | 120 | 40% | 42% | ciudad repetida (revisión), total incorrecto (prueba) | 3 de 3
Ya tienes el costo y el resultado uno al lado del otro, etapa por etapa.
Resumen de bolsillo
Medir el piloto
En el momentouna fila por etapa, apenas termine.
Tu tiempodesde el pedido hasta la revisión.
Resultadoproblemas detectados antes de la entrega y quién los detectó.
Tu próximo paso
Ya mides el piloto con números, no con impresiones.
En la próxima tarea con IA, anota la hora de inicio y la hora en que termines la revisión. Te toma diez segundos.
En la próxima lección: el precio y el límite de tu cuenta cambian. ¿Dónde consultarlos y qué cambia entre una suscripción y el pago por uso?
Lección 28 · Dev con IA v6.2 · INEMA.CLUB
Módulo 6 · Lección 4 de 5
El precio y el límite cambian: consúltalos en tu cuenta
Puedes decir, al mirar tu cuenta, si pagas una suscripción o por uso y cuál es el límite. También anotas dónde lo consultaste y la fecha.
Los precios, los límites y las herramientas incluidas cambian de un mes a otro y de una cuenta a otra. Lo que viste en un video puede no aplicarse a la tuya. La única fuente segura es tu cuenta, ese día.
En 1 minuto
Suscripción: valor fijo, con un límite de uso por período. Por uso: pagas lo que consumes.
Anota el tipo, el límite, dónde lo viste y la fecha. Nunca la contraseña ni la clave.
OpenRouter y los modelos abiertos son opciones para consultar, no una receta.
1Suscripción y pago por uso
Con una suscripción, pagas un monto fijo y tienes un límite de uso por período. Cuando se acaba el límite, esperas a que comience el siguiente período o, si el plan lo ofrece, compras uso adicional. En el pago por uso, cada token consumido se suma a la cuenta, y tú defines el tope de gasto, cuando existe.
El pago por uso suele hacerse mediante una API, con una clave secreta.
Rafael usa Claude Code con una suscripción. Un cliente pidió una automatización que llama a la IA por sí sola todas las noches: esa se paga por uso, con una clave y un tope de gasto en la cuenta del cliente. Así, el gasto queda a cargo de quien la usa y su suscripción personal no se usa para el trabajo del cliente.
Suscripción
Paga: un monto fijo al mes.
Límite: uso por período; cuando se acaba, esperas o compras uso adicional, si el plan lo ofrece.
Por uso
Paga: por lo que consumes.
Límite: el tope de gasto, si lo defines.
Ninguna de las dos opciones es mejor en general. Depende del volumen y de quién la usa.
2Una ficha de la cuenta, con fecha
Anota en una ficha lo que muestra hoy tu cuenta: tipo, límite, dónde lo viste y la fecha. Cuando algo cambie, te darás cuenta al compararlo con la ficha. La contraseña y la clave nunca se anotan en la ficha ni en un archivo del proyecto.
Carla hizo la ficha de Codex de la empresa. Descubrió que su colega usaba una cuenta y ella otra, con límites diferentes.
conta-ia.md · ficha de Carla
1 Servicio: Codex, con la cuenta de la empresa
2 Tipo: suscripción
3 Límite: "40% de la semana usado, se renueva el lunes"
4 Dónde lo vi: configuración de la cuenta › Uso · 28/09/2026
5 Contraseña y clave: nunca aquí
1Qué servicio es y de quién es la cuenta.
2Suscripción o por uso.
3Copia lo que está escrito ahí, sin interpretarlo. Si solo aparece un porcentaje, anótalo así.
4Dónde y cuándo lo consultaste.
5Las credenciales van en el administrador de contraseñas.
3OpenRouter y modelos abiertos: verifica antes
OpenRouter es un servicio que da acceso a varios modelos con una sola cuenta, pagando por uso. Los modelos abiertos pueden ejecutarse en un servicio de este tipo o en tu propia computadora.
Pueden ser buenas opciones para ciertas tareas. Pero en el curso se presentan como opciones que debes verificar: el precio del día, la calidad en tu tarea según el criterio de la lección 26 y adónde van los datos.
Carla pensó en usar un modelo abierto más barato para el informe. Se detuvo antes: las hojas de cálculo tienen nombres de clientes y ella no sabía dónde guardaría los datos el servicio.
Cambiar por el precio
"Este es más barato, lo voy a usar." Sin probarlo, sin saber adónde van los datos.
Verificar antes
Precio de hoy, prueba con la rúbrica en una tarea sin datos de clientes y política de datos leída.
Si te trabaste aquí, es normal¿No sabes si puedes enviar datos de clientes a otro servicio? Si tienes dudas, no los envíes. Pregúntale a quien se encarga de eso en la empresa y prueba antes con datos inventados.
4"La IA va a ser más cara" es una hipótesis
Hay quienes dicen que hoy se subsidia el uso de IA y que va a encarecerse. Puede ser. Pero es una previsión del mercado, no un hecho demostrado.
El método de este curso se sostiene sin ella: medir el costo y el resultado por tarea, y guardar el conocimiento del proyecto en archivos que cualquier asistente puede leer. Si el precio sube, ya sabes dónde recortar. Si baja, sabes dónde ampliar.
Rafael no cambió nada por la previsión. Cambió cuando la hoja de cálculo de la lección 28 mostró dos cosas. La crítica con esfuerzo alto valía la pena. El intercambio de textos, no.
Decidir según la previsión
"Va a encarecerse, así que uso lo mínimo para todo."
Decidir según la medición
"La hoja de cálculo muestra dónde el esfuerzo da resultados. Ahí lo mantengo."
Ponte a prueba
Un video dice que el límite de la suscripción es de tantas horas por semana. ¿Qué haces?
Practica ahora 0/3
La ficha de tu cuenta
Está listo cuando el archivo conta-ia.md tenga el tipo, el límite, dónde lo verificaste y la fecha. Unos 8 minutos, en la computadora.
Solo lees la información de tu cuenta y la anotas; no se contrata ni se cambia nada. Nunca copies una contraseña o una clave en la ficha. ¿No encontraste el límite? Escribe "no se muestra" y la fecha.
# Cuenta de IA
Servicio: <cuál y de quién es la cuenta>
Tipo: <suscripción o por uso>
Límite: <lo que muestra la página; si solo aparece un porcentaje, anota el porcentaje>
Tope de gasto: <¿definido? ¿cuánto?>
Dónde lo vi: <ruta en el sitio> · <fecha>
Contraseña y clave: nunca aquí
Ya sabes qué cobra tu cuenta y hasta dónde llega, con fecha y fuente.
Resumen de bolsillo
Cuenta y precio
Tiposuscripción con límite por período o pago por uso con un tope.
Ficha con fechalo que muestra la cuenta hoy; nunca credenciales.
Por verificarOpenRouter, modelos abiertos y previsiones de precios.
Tu próximo paso
Ya verificas el precio y el límite en la fuente, no por lo que escuchaste.
Pon un recordatorio para dentro de un mes: volver a abrir la página de uso y actualizar la ficha.
En la próxima lección: con el costo, el resultado y la cuenta a la mano, decidir si el piloto se vuelve una rutina.
Material complementario · Lo que la síntesis marca como "por verificar"Profundización del tema. No cuenta para el tiempo de la lección.
Orientación adicional
La síntesis del INEMA del 27 de septiembre de 2026 separa lo que se verificó de lo que se sugirió en la conversación. OpenRouter y los modelos de código abierto pueden formar parte de la estrategia cuando sean adecuados para el proyecto, pero la página analizada no los recomienda como opciones verificadas. Antes de convertirlos en un procedimiento estándar, hay que confirmarlos en el entorno y con las herramientas disponibles.
Sobre el precio futuro
La idea de que hoy la IA está subsidiada y que en el futuro podría costar más por uso se trata como una hipótesis de mercado. La recomendación práctica ya se sostiene sin esa predicción: medir el costo y el resultado por tarea, y mantener portátil el conocimiento del proyecto.
Fuentes: síntesis ejecutiva del 27/09/2026, en los archivos de origen del curso, carpeta docs/.
Lección 29 · Dev con IA v6.2 · INEMA.CLUB
Módulo 6 · Lección 5 de 5
Ampliar, ajustar o parar: la decisión del piloto
Puedes entregar el informe de una página de tu piloto y escribir la decisión: ampliar, ajustar o parar, con el motivo.
Un piloto sin una decisión al final se queda en un simple experimento. El informe reúne lo que mediste en todo el curso y responde una pregunta: ¿vale la pena volver a hacerlo así, en más tareas?
En 1 minuto
Informe de una página: tarea, criterios, problemas encontrados, costo y decisión.
Tres opciones posibles: ampliar, ajustar o parar. Todas son un resultado.
La decisión es tuya, con fecha y la próxima revisión programada.
1El informe cabe en una página
Todo lo que produjiste en el curso se convierte en seis líneas. Incluyen la tarea del briefing, los criterios de aceptación que se cumplieron, los problemas encontrados y quién los encontró. Después, el costo y la comparación de la hoja de cálculo de la lección 28, y la decisión.
Rafael armó el informe del formulario de la clínica en quince minutos, copiando la información de los archivos de la carpeta del piloto.
relatorio-piloto.md · Rafael
1 Tarea: formulario de contacto de la clínica
2 Criterios: 3 de 3 se cumplieron en la prueba
3 Problemas encontrados: 2 en la revisión del plan, 1 en la prueba
4 Costo: tiempo y uso de la cuenta, según la hoja piloto-custos
5 Comparación: el mismo tipo de tarea realizado de la manera anterior
6 Decisión y fecha de la próxima revisión
1Del briefing.md.
2De la aceptación del módulo 4.
3De la hoja de cálculo, columna de problemas.
4De la hoja de cálculo de la lección 28.
5De la columna "Jeito antigo (min)" de la hoja de cálculo; la estimación sirve, marcada como "estimado".
6Lo que esta lección te enseña a escribir.
Si te trabaste aquí, es normal¿Te saltaste alguna etapa del piloto? Escribe "no hecho" en la línea. Un informe honesto con vacíos vale más que uno completo inventado.
2Tres opciones, todas válidas
Ampliar es usar el método en más tareas del mismo tipo. Ajustar es repetir el piloto cambiando una cosa. Parar es concluir que, para este tipo de tarea, la manera anterior es mejor. Parar también es un resultado.
Carla amplió la prueba al informe mensual. Rafael hizo un ajuste: la revisión cruzada del plan encontró problemas, pero la del cambio de textos no encontró nada, así que la va a quitar.
Cuándo elegir cada resultado
1 Ampliar: se cumplieron los criterios y el costo cabe en el presupuesto
2 Ajustar: funcionó, pero una etapa tuvo un costo sin encontrar nada
3 Parar: no funcionó o costó más que el método anterior
1Más tareas del mismo tipo.
2Cambia una cosa y repite.
3Registra el motivo y sigue sin culpa.
3La decisión es tuya, con fecha
El modelo puede resumir el informe y señalar cifras que no coinciden. La decisión de ampliar le corresponde a quien responde por el trabajo. Escribe la decisión, el motivo y cuándo la revisarás.
Carla escribió: "Ampliar al informe mensual. Motivo: 3 de 3 criterios y 25 minutos frente a dos horas. Revisar en 30 días."
Sin decisión
"El piloto fue interesante, ya veremos."
Después de un mes: nadie recuerda qué se midió.
Decisión escrita
"Ampliar. Motivo: 3 de 3 criterios, 25 minutos frente a 120. Revisar en 30 días."
Después de un mes: ella compara con el nuevo mes.
4Adónde ir después
El ciclo del curso es el comienzo. Tres rutas de INEMA, todas abiertas, continúan desde aquí.
La guía de Use Both presenta los seis niveles de uso conjunto y prompts listos. claudex automatiza el debate de un plan grande entre Claude y Codex. Y el curso Claude → Codex enseña a guardar el contexto del proyecto en archivos que cualquier asistente puede leer.
claudex se ejecuta en el terminal, con Claude Code y Codex listos para usar. Los otros dos sirven para quienes usan la app.
Rafael siguió con Use Both. Quiere darle al asistente una meta con una prueba de éxito y un límite para parar, como en la lección 19. Carla siguió con el curso Claude → Codex: su equipo usa distintos asistentes.
Rutas siguientes
1 Use Both: seis niveles y prompts listos
2 claudex: debate automático de un plan grande (terminal)
3 Claude → Codex: contexto portátil en archivos
1Para quienes quieren profundizar en el uso conjunto de ambos.
2Para quienes planifican cosas grandes con frecuencia.
3Para quienes cambian de asistente o trabajan en equipo.
Practica ahora 0/4
El informe y la decisión de tu piloto
Listo cuando relatorio-piloto.md tenga las seis líneas y la decisión con fecha de revisión. Unos 12 minutos, en la computadora.
Es un archivo tuyo; no se envía nada. ¿Te faltó un paso? Escribe "no hecho". Si quieres, pídele a un asistente que compruebe si los números del informe coinciden con la hoja de cálculo; la decisión sigue siendo tuya.
# Informe del piloto
Tarea: <del briefing.md>
Criterios: <cuántos de cuántos pasaron>
Problemas encontrados: <cuántos y quién los encontró: revisión, prueba, tú>
Costo: <tu tiempo y uso de la cuenta, de la hoja de cálculo>
Comparación: <columna "Manera antigua (min)" de la hoja de cálculo; si es una estimación, escribe "estimado">
Decisión: <ampliar, ajustar o parar> · Motivo: < > · Revisar el: <fecha>
Cerraste el piloto con una decisión que otra persona puede entender y comprobar.
Resumen de bolsillo
Cerrar el piloto
Una páginatarea, criterios, problemas, costo, comparación y decisión.
Tres opcionesampliar, ajustar o parar, todas con un motivo.
Revisión anotadala decisión tiene una fecha para revisarla.
Tu próximo paso
Terminaste el curso con un método probado en tu propia tarea: uno lo hace, otro lo comprueba y tú decides.
Muéstrale el informe del piloto a una persona de tu equipo o a un cliente. Toma cinco minutos y comprueba si se explica por sí solo.
Continúa en Use Both, en claudex y en el curso Claude → Codex.
