Seis tareas que le delego a la IA, y tres que no

Lunes, nueve de la mañana. En la lista de tareas hay un error en un módulo que nadie toca hace cuatro años, una función nueva sin pruebas y una consulta que tarda ocho segundos. Hace tres años, eso era la mañana entera. Hoy le paso tres de esas cosas a la IA, y me quedo con la parte que realmente necesita que la piense yo.

No es que no sepa hacerlas: la IA las hace más rápido, y mi tiempo rinde más en otro lado. Abajo están las seis tareas que delego casi siempre y cómo lo hago sin perder el control, y las tres que no delego nunca, con un caso de este mes que explica por qué. Sirve desde tu próxima tarea.

La regla: delego lo que puedo verificar barato

Antes de la lista, el criterio que la ordena. Le delego a la IA una tarea cuando puedo comprobar el resultado rápido y sin tener que confiar en ella. Una prueba unitaria se verifica en segundos: la corrés y pasa o falla. Una consulta SQL se verifica contando filas. En cambio, “¿conviene partir este servicio en dos?” no tiene una comprobación rápida: la respuesta se sabe un año después.

La otra mitad del criterio es quién responde si sale mal. Si la respuesta es “yo”, la decisión también es mía.

Las seis que delego

Para cada tarea cuento tres cosas: qué le pido, en qué me fijo cuando me devuelve el resultado y cómo lo verifico. Esas dos últimas son las que hacen que delegar me ahorre tiempo en vez de sumármelo.

Pensalo como cuando le pasás una tarea a alguien que recién entró al equipo. Le explicás bien qué querés, sabés en qué suele tropezar quien recién llega, y antes de que su trabajo salga le das una mirada rápida en esos puntos. Si no supieras dónde mirar, tendrías que revisar todo línea por línea, y para eso lo hacías vos. Con la IA pasa lo mismo: saber dónde mirar convierte una revisión de media hora en una de cinco minutos. Esa es la diferencia entre delegar y cruzar los dedos.

1. Escribir pruebas unitarias

Qué le pido:

Escribí pruebas para calcularDescuento(). Antes de escribirlas, listame los casos que vas a cubrir: los normales, los bordes (cero, negativos, fin de mes) y los errores. No modifiques la función.

En qué me fijo: que pruebe la regla, no lo que hace el código. La IA tiende a escribir las pruebas mirando el código, y si el código tiene un error, la prueba lo copia. Un ejemplo: la regla dice que las compras de 100 dólares o más tienen un 10 % de descuento, pero la función tiene un error y solo lo aplica a las de más de 100. Una compra de exactamente 100 dólares se queda sin descuento. La IA lee el código y escribe una prueba que dice “una compra de 100 paga 100”. La prueba pasa, y el error queda protegido: si mañana alguien lo arregla, esa prueba va a fallar y va a parecer que el arreglo rompió algo.

La otra trampa es peor. Si una prueba falla, la IA puede “arreglarla” cambiando el resultado que espera, en vez de corregir el código. Siguiendo el mismo ejemplo: la prueba espera que una compra de 100 pague 90, la función devuelve 100, y la IA cambia el 90 por 100 para que todas las pruebas pasen. El error sigue ahí, ahora con una prueba que lo aprueba.

Cómo lo verifico: leo la lista de casos antes que el código, porque ahí se ve si entendió la regla y no solo el código. Después rompo la función a propósito, por ejemplo cambiando el descuento del 10 % al 20 %, y corro las pruebas. Si ninguna falla, no estaban probando nada. En este artículo está qué pruebas valen la pena.

2. Entender código heredado

Qué le pido:

Explicame qué hace este módulo como si no supiera nada del negocio: qué entra, qué sale, qué reglas aplica y a qué otras partes llama. Marcá todo lo que no puedas deducir del código.

En qué me fijo: que no invente el porqué. Ve una línea como if (cliente.tipo == 3) total = total * 0.9 y te explica con total seguridad que “los clientes mayoristas tienen un 10 % de descuento”. Puede ser. O puede ser que el tipo 3 sean los empleados, y eso solo lo sabe alguien que estuvo cuando se escribió. Tampoco ve lo que vive fuera del archivo: un proceso que corre de noche, una columna que usa otra aplicación.

Cómo lo verifico: le pido que cite el archivo y la línea de cada cosa que afirma, y lo que marca como “no sé” se lo pregunto a una persona. Esa última parte es la más valiosa de la respuesta. Para módulos grandes, este artículo sobre migrar código heredado explica cómo mapear el dominio antes de tocar nada.

3. Depurar

Qué le pido: el error completo, la traza (la lista de funciones que se estaban ejecutando cuando falló) y qué cambió desde la última vez que funcionaba. Y esto:

Dame tres hipótesis ordenadas de más a menos probable, y cómo confirmar cada una sin tocar el código.

En qué me fijo: que encuentre la causa y no tape el síntoma. Suele quedarse con la primera idea y proponer un arreglo que solo esconde el problema, como envolver el código en un try/catch que atrapa el error y no hace nada con él. El programa deja de mostrar el error, pero sigue fallando por dentro, y ahora sin avisar.

Cómo lo verifico: no acepto ningún arreglo hasta confirmar la causa. Reproduzco el error antes del cambio y compruebo que desaparece después. Si los logs no alcanzan para reproducirlo, el problema está ahí: estos tres cambios los vuelven útiles.

4. La primera pasada de una revisión de código

Qué le pido:

Revisá estos cambios buscando errores de lógica, casos borde sin manejar y consultas a la base dentro de bucles. No comentes estilo.

En qué me fijo: que no se pierda en el estilo. Si no se lo pedís, llena la revisión de comentarios de formato y nombres, y deja pasar lo que importa. Y no conoce las reglas del negocio: si tu empresa exige que los reintegros de más de mil dólares los apruebe un supervisor, y el cambio los aprueba solos, la IA no va a ver nada raro. El código está bien escrito; lo que está mal es lo que hace.

Cómo lo verifico: la uso antes de pedir revisión a una persona, nunca en lugar de. Un estudio de Harvard que se discutió mucho este mes mostró que casi el 80 % de las empresas ya usa revisión con IA, pero solo el 23 % de los comentarios los hace la IA: la revisión humana sigue siendo el cuello de botella. Esta lista es lo que miro yo después.

5. Refactorizar

Refactorizar es cambiar cómo está escrito el código sin cambiar lo que hace: partir una función de doscientas líneas, sacar una lógica repetida.

Qué le pido:

Simplificá este método sin cambiar su comportamiento. Las pruebas actuales tienen que seguir pasando sin modificarlas. Hacelo en pasos chicos, uno por vez.

En qué me fijo: que no cambie lo que hace el código en detalles que no se ven: el orden de una lista, cómo redondea, qué hace con un valor vacío. Y que no toque de más, como renombrar tres variables en otro archivo “ya que estaba”.

Cómo lo verifico: corro las pruebas antes y después, y reviso que no haya tocado ninguna. Si el cambio tiene más archivos de los que esperaba, revierto lo que no pedí. Sin pruebas previas, no le pido refactorizar: le pido primero las pruebas.

6. Escribir consultas SQL

Qué le pido: el esquema de las tablas, nunca que lo adivine. Y:

Escribí la consulta, y decime cuántas filas esperás que devuelva y por qué.

En qué me fijo: que el resultado tenga sentido, porque el SQL generado falla en silencio: corre sin errores y devuelve datos de más o de menos. El caso típico: le pedís el total facturado del mes, y para calcularlo une la tabla de pedidos con la de productos (eso es un JOIN). Un pedido con tres productos aparece tres veces, su importe se suma tres veces, y el total sale inflado. La consulta no da ningún error: solo da un número equivocado.

Cómo lo verifico: cuento las filas antes y después de cada unión, y comparo contra una consulta simple que sí entiendo. Para las lentas, le pido a la base el plan de ejecución, que muestra cómo piensa resolver la consulta, y lo leo con la IA al lado.

Las tres que no delego

Las decisiones de arquitectura

Partir un servicio en dos, elegir una base de datos, decidir qué se procesa en el momento y qué de noche. Son decisiones que duran años y que dependen de cosas que no están en el código: cuánta gente hay en el equipo, cuánto se puede gastar, qué va a pedir el negocio el año que viene. La IA me sirve para listar opciones y sus costos. Elegir es mío.

Entender qué necesita el negocio

“Agregá un filtro por fecha” parece claro hasta que preguntás: ¿fecha de compra o de entrega? ¿En la zona horaria del cliente o en la del servidor? La respuesta no está en ningún archivo: está en una conversación con quien pidió la funcionalidad. Si eso lo adivina la IA, el código va a estar perfecto y va a hacer otra cosa.

Hacerme responsable de lo que llega a producción

El 20 de octubre, OpenAI publicó un informe (abre en una pestaña nueva) sobre dos de sus agentes de código internos. Uno estaba arreglando un proceso y le habían pedido que no mandara mensajes. Lo interpretó como permiso para apagar las alertas que avisaban al equipo de seguridad. El otro, en una migración, sacó el sistema que vigilaba su propio comportamiento, cambió las pruebas para que comprobaran que ya no estaba y, cuando le preguntaron, dijo que no lo había sacado.

Ninguno de los dos actuó con mala intención: interpretaron instrucciones de rutina de una manera que nadie esperaba. Si eso le pasa a OpenAI con sus propios agentes, me puede pasar a mí. Por eso la última mirada antes de producción la hace una persona que entiende qué cambió y que va a responder por eso. Esa persona soy yo.

Lo que hago con el tiempo que me queda

Delegar estas seis tareas no me deja con menos trabajo: me deja con el que más importa. El tiempo que antes se iba en pruebas repetitivas o en descifrar un módulo viejo ahora va a las tres cosas que no delego. Lo que se puede comprobar en minutos lo hace la IA; lo que solo se sabe con el tiempo, o alguien tiene que firmar, sigue siendo mi trabajo.