Tienes una tarea nueva delante y el cursor parpadeando en el chat. La decisión de ese momento, escribir el encargo o cerrar la pestaña y pensar diez minutos, es la que más determina cómo va a ir la siguiente hora.
Este es el recorrido corto para resolverla sin pensarlo demasiado. Tres preguntas en orden, cada una con una salida clara.
Por qué en este orden
Las tres preguntas están ordenadas por lo que cuesta el error, no por lo que cuesta responderlas.
La primera filtra las tareas donde no podrías detectar un fallo. La segunda, las que no podrías deshacer si lo detectaras. La tercera, las que son demasiado amplias para revisarlas de una vez.
Si una tarea pasa las tres, delegarla es seguro aunque salga mal, porque lo notarías y podrías volver atrás. Si falla en la primera, ninguna redacción del encargo lo arregla.
Las tres preguntas
Se responden en menos de un minuto y no requieren conocer la solución todavía.
1. ¿Sabrías verificar que el resultado está bien?
Verificar significa tener un procedimiento: ejecutar una prueba, comparar una salida con un valor esperado, reproducir un comportamiento. No significa leerlo y que te parezca razonable.
Si la respuesta es no, has encontrado el caso en el que delegar no tiene sentido. No porque el resultado vaya a estar mal, sino porque aceptarías igual uno correcto y uno incorrecto.
La salida aquí no es renunciar a la herramienta: es dedicar el rato a decidir qué debe pasar exactamente, que es lo que te falta.
2. ¿Se puede revertir en minutos?
Un cambio es reversible si deshacerlo cuesta un comando y no deja rastro. Un commit sin mezclar, sí. Una migración ya aplicada sobre datos de producción, no. Un cambio en un formato que otros sistemas ya consumen, tampoco.
Si no es reversible, no significa que no puedas delegar la escritura. Significa que la decisión de fondo la tomas tú y la escribes antes, aunque sea en diez líneas.
Esa asimetría es la clave de todo el árbol: lo caro no es equivocarse, es equivocarse en algo que no se puede deshacer.
3. ¿Es un patrón conocido y acotado?
Conocido significa que ya sabes cómo debería quedar, aunque no te apetezca teclearlo. Acotado significa que cabe en una revisión de una sentada, del orden de un par de cientos de líneas.
Si es conocido pero no acotado, la salida es partirlo. No hay que renunciar a nada, solo pedirlo en cuatro trozos en lugar de en uno.
Si no es conocido, estás explorando, y ahí lo que conviene es un prototipo desechable en una rama aparte, no un encargo formal.
Las cuatro salidas
El árbol termina siempre en una de estas cuatro, y cada una tiene un primer paso concreto.
Diséñalo tú primero. Escribe qué debe ocurrir en los casos normales y en los límite. Cuando tengas esa lista, vuelve al árbol: la tarea habrá cambiado de rama.
Escribe la especificación antes. Diez o veinte líneas con el comportamiento, las restricciones y lo que no debe cambiar. Después delega la implementación contra esa lista.
Divídelo en partes pequeñas. Trozos que funcionen por separado y que puedas integrar de uno en uno, cada uno con su commit.
Pídeselo y revisa el resultado. El caso normal, y el más frecuente en el día a día. Revisar sigue siendo obligatorio, pero es una lectura, no una auditoría.
Cómo hacer reversible lo que no lo es
La segunda pregunta tiene truco: muchas tareas parecen irreversibles y no lo son, si se prepara el terreno antes.
# Una rama desechable para cualquier encargo de tamano medio
git switch -c prueba/importar-csv
# Punto de retorno explicito antes de aceptar un cambio grande
git commit -am "antes de la refactorizacion del importador"
# Deshacer sin perder el trabajo, por si quieres mirarlo despues
git switch main
git branch -D prueba/importar-csvPara lo que toca datos, la reversibilidad se prepara de otra forma: una copia antes, y una migración que sepa volver atrás.
# Copia de seguridad antes de aplicar una migracion
pg_dump -Fc mi_base > respaldo-$(date +%F-%H%M).dump
# Comprobar que la migracion tiene marcha atras antes de aplicarla
npx prisma migrate diff --from-schema-datamodel schema.prisma --to-schema-datasource schema.prismaCon esos dos pasos, una tarea que caía en la rama de la especificación obligatoria pasa a la rama normal. Diez minutos de preparación cambian el resto.
Cómo saber si de verdad puedes verificar
La primera pregunta es la que más se responde mal, porque es fácil confundir entender el código con poder comprobarlo.
La comprobación honesta es esta: antes de ver el resultado, escribe en una línea qué comando vas a ejecutar y qué salida esperas. Si no puedes escribirlo, no tienes verificación.
# Fijar el criterio antes de pedir nada
echo "esperado: importa 3 filas, ignora la cabecera, error en la fila 4" > /tmp/criterio.txt
# Y comprobarlo despues contra la salida real
php importar.php ejemplos/ventas.csvPara la lógica con casos límite, la verificación que mejor funciona es la prueba escrita antes. Deja de ser una opinión y pasa a ser un comando que devuelve cero o no.
El caso de la exploración
Hay una situación que el árbol no cubre bien y conviene tratar aparte: cuando no sabes ni qué quieres.
Ahí la respuesta correcta no es ninguna de las cuatro salidas. Es hacer algo desechable, mirarlo, y tirarlo. El error es que ese prototipo se quede, porque un prototipo que sobrevive se convierte en la base del sistema sin que nadie lo haya decidido.
# Explorar sin contaminar el proyecto
git worktree add ../prueba-idea -b explora/idea
# Y borrar el experimento entero cuando ya te dijo lo que querias saber
git worktree remove ../prueba-idea --force
git branch -D explora/ideaLa regla que evita el problema: si el prototipo te gusta, no lo integres, reescríbelo con lo aprendido. Eso sí es una tarea que pasa las tres preguntas.
Cuatro tareas reales pasando por el árbol
El recorrido se entiende mejor con casos concretos, y estos cuatro cubren las cuatro salidas.
Convertir un CSV de proveedor a nuestro formato interno. ¿Sabrías verificar? Sí: tienes un archivo de ejemplo y sabes qué filas deben salir. ¿Reversible? Sí, es un script nuevo que no toca nada. ¿Acotado? Sí. Salida: pídelo y revisa. Es el caso ideal, y es más frecuente de lo que parece.
Añadir un campo de estado a la tabla de pedidos. ¿Sabrías verificar? Sí. ¿Reversible? No, porque en cuanto la migración se aplica sobre datos reales volver atrás implica otra migración y un rato de servicio degradado. Salida: escribe antes qué valores puede tomar el campo, qué pasa con las filas existentes y qué código tiene que entender el valor nuevo. Son ocho líneas y evitan la mayoría de los problemas.
Reorganizar el módulo de facturación, que tiene mil doscientas líneas. ¿Sabrías verificar? Solo si hay pruebas, y probablemente no las hay. Salida: la primera rama. Antes de tocar nada, escribe los comportamientos que deben seguir igual y conviértelos en pruebas de caracterización. Después el refactor pasa a ser una tarea normal.
Integrar una pasarela de pagos nueva. ¿Sabrías verificar? En parte: el camino normal sí, con el entorno de pruebas del proveedor; los reintentos y los webhooks duplicados, no tanto. ¿Reversible? El código sí, los cobros no. ¿Acotado? No: son varios archivos, configuración y manejo de eventos. Salida: partirlo, y tratar la parte de idempotencia como diseño propio en lugar de encargo.
El patrón que se repite en los cuatro: la respuesta del árbol casi nunca es no delegues, es delega después de haber hecho una cosa concreta primero.
Cuando la respuesta cambia a mitad de camino
Una tarea que empezó en la rama fácil puede salirse de ella, y conviene reconocer el momento.
La señal más clara es la tercera vuelta. Si llevas tres intentos y el resultado sigue sin servir, el problema ya no está en la redacción del encargo: falta una decisión que no has tomado.
La segunda señal es cuando empiezas a pegar errores sin leerlos. En ese punto ya no estás dirigiendo el trabajo, y lo que toca es parar, leer el código entero y volver a la primera pregunta.
La tercera es cuando el cambio crece: pediste algo de cincuenta líneas y llevas trescientas. Eso ya no es la misma tarea, y la rama correcta es la de partirlo.
Una versión corta para el día a día
Resumido en algo que se pueda recordar sin consultar nada:
Si no sabes cómo comprobarlo, no lo pidas todavía. Si no puedes deshacerlo, escríbelo antes. Si no cabe en una revisión, pártelo. Y si pasa las tres, pídelo sin darle más vueltas.
La mayoría de las tareas de un día normal pasan las tres. El valor del árbol está en las pocas que no, que son justamente las que más tiempo cuestan cuando se delegan sin pensar.
Qué se le escapa a una IA con esto
Preguntarle al asistente si esta tarea es para él tiene un problema evidente y otro menos evidente.
El evidente: acepta casi cualquier encargo. Pedirle que se autoevalúe produce una respuesta cooperativa, no una valoración.
El menos evidente: aunque quisiera, no puede responder la primera pregunta, que es sobre ti. No sabe si detectarías un error en lo que te entrega, y esa es la variable que decide el árbol entero.
Tampoco sabe si tu cambio es reversible, porque eso depende de si hay datos de producción detrás, de cuántos sistemas consumen ese formato y de si alguien más está trabajando en la misma rama. Nada de eso está en el código.
Lo que sí hace bien es lo previo: pídele que enumere los casos límite de la tarea o las decisiones que hay que tomar antes de empezar. Esa lista te ayuda a responder la primera pregunta, que es la única que importa de verdad.