Todo el resto del sitio habla de lo que tenés que construir alrededor del agente. Esta página habla de para qué. Ocho trabajos sobre un solo eje: qué tan barato te sale comprobar el resultado, y qué te cuesta equivocarte.
No es que la IA sirva o no sirva. Sirve muchísimo para algunas cosas y es peligrosa para otras, y la diferencia no es el modelo: es cuánto de lo que hace podés verificar.
Cada trabajo dice en qué disciplinas se apoya, cuánto proceso merece y cómo comprobás el resultado. Si un trabajo tuyo no está acá, fijate cuál se le parece en la forma de verificarlo — esa es la parte que se transfiere.
No, y decirlo importa. Un proceso que se vende como siempre-correcto se abandona la primera vez que alguien lo aplica a un cambio de dos líneas, y se lleva puesto al resto del proceso. Son tres escalones y se elige por el costo de equivocarse, no por el tamaño del cambio.
01 · Proceso
Sin ceremonia
Qué vive acá
Cambios donde leer el resultado cuesta menos que explicar de antemano lo que querés. Un typo, un helper de cuatro líneas, una pregunta sobre código que ya existe.
La regla
¿Podés darte cuenta de un vistazo si está bien o está mal? Entonces no escribas nada antes. Pedilo y miralo.
Cómo se pudre
Se estira más allá de donde llega: alguien manda una feature de tres días sin escribir nada, porque los cambios de cuatro líneas venían saliendo bien.
Trabajo cuyo costo de estar mal no lo pagás vos hoy. Una feature nueva, una migración, una decisión de arquitectura. Cosas que quedan.
La regla
¿Alguien va a tener que entender esto dentro de seis meses sin poder preguntarte? Entonces la especificación y el porqué son parte del entregable, no papeleo alrededor.
Cómo se pudre
Se aplica por defecto a todo, la gente la vive como burocracia y a los dos meses no queda ni el proceso ni la costumbre de verificar.
El mismo eje, en orden. Arriba están los trabajos donde comprobar sale barato y equivocarse cuesta una explicación mala; abajo, aquellos donde no pasa ninguna de las dos cosas y el error queda en producción.
01
Entender código
¿Qué hace esto, y por qué está así?
Pedirle que te explique un sistema que no escribiste vos —o que escribiste hace ocho meses, que a esta altura es lo mismo.
Dónde rinde
Es donde más rinde y donde menos arriesgás: si se equivoca, lo pagás en una explicación mala, no en código roto. Y seguir un flujo de punta a punta es exactamente lo que un humano hace lento, tarde y con ganas de rendirse a mitad de camino.
Dónde falla
Te va a explicar con total seguridad la intención de un código que nunca tuvo ninguna. Lee el resultado, no la discusión que lo produjo: si eso fue un parche apurado de un viernes, te lo presenta como diseño. La intención no está en el código, está en la memoria — y si nadie la guardó, no la va a encontrar.
Cómo sabés que salió bien
Pedile archivo y línea de cada afirmación. Una explicación sin coordenadas es una hipótesis con buena redacción.
Proceso por defecto
Sin ceremonia
Dónde corre
Aparte si hace ruido
Lo que se lee para entender queda ocupando lugar después de haber servido. Si el barrido toca cuatro archivos o más, que lo haga otro agente y te devuelva las tres frases que importan. Para un archivo que ya tenés abierto, el traspaso cuesta más que la lectura.
02
Encontrar por qué falla
¿Por qué se rompe esto, y desde cuándo?
Darle un síntoma para que encuentre la causa, en vez de que pruebe arreglos hasta que uno haga desaparecer el error.
Dónde rinde
Formular hipótesis a partir de un stack trace y descartarlas rápido. Un humano se enamora de la primera y se queda dos horas defendiéndola; el agente no tiene ego con ninguna.
Dónde falla
Salta a arreglar antes de haber reproducido. Si lo dejás, terminás con un parche que tapa el síntoma y deja la causa entera adentro — y esos son los bugs que vuelven en producción tres semanas después, cuando ya nadie se acuerda del parche.
Cómo sabés que salió bien
Un test que falla antes del cambio y pasa después. Sin eso no arreglaste nada: cambiaste algo y el síntoma se fue solo.
Proceso por defecto
Ceremonia liviana
Dónde corre
Aparte si hace ruido
Rastrear el origen puede costar muchos archivos; arreglarlo, tres líneas. Delegá el rastreo, quedate con el arreglo.
03
Refactorizar
¿Cómo cambio la forma sin tocar el comportamiento?
Mover, renombrar, extraer y partir código que ya funciona, sin que cambie nada de lo que hace.
Dónde rinde
El cambio mecánico repetido a lo largo de muchos archivos. Es el trabajo donde el humano se cansa en el archivo doce y empieza a cometer errores justo cuando cree que ya le agarró la mano.
Dónde falla
Mirando el código no distingue entre “esto es equivalente” y “esto es casi equivalente”. Y “casi” en un refactor es un bug que nadie va a atribuir al refactor, porque el refactor no cambiaba nada.
Cómo sabés que salió bien
La suite verde antes y después. Si tuviste que cambiar lo que un test afirma sobre el comportamiento, no era un refactor: era un cambio de comportamiento con otro nombre.
Proceso por defecto
Ceremonia liviana
Dónde corre
Aparte si hace ruido
Si primero hay que mapear quién usa qué, eso va aparte. La edición en sí conviene en un solo hilo: son cambios que tienen que ser coherentes entre archivos.
04
Implementar
¿Cómo escribo esto sin tener que revisarlo línea por línea?
Escribir código nuevo: una feature, un endpoint, una pantalla. El trabajo que todo el mundo piensa primero cuando piensa en IA.
Dónde rinde
Escribir la vigésima variante de un patrón que ya existe en tu repositorio. Ahí no está inventando nada: está copiando bien, y copiar bien es la mayor parte del trabajo de cualquier día normal.
Dónde falla
Cuanto más nuevo es lo que pedís, más se parece la salida a un promedio de internet. Y una feature grande en un solo pedido derrapa a la hora: la instrucción del principio queda compitiendo con doscientas líneas de salida de tests, y pierde.
Cómo sabés que salió bien
Los criterios de aceptación escritos antes de que empiece a escribir. Si no podés escribir cómo vas a comprobar que está bien, todavía no sabés qué estás pidiendo.
Proceso por defecto
Ceremonia completa
Dónde corre
En el hilo principal
Una unidad coherente la escribe un solo autor. Eso no contradice partir en tandas: si la feature se corta en pedazos que no se pisan, cada pedazo es su propio hilo con su propio autor único. Lo que nunca funciona es dos agentes editando en paralelo la misma unidad.
05
Revisar
¿Qué se me está pasando en este diff?
Que lea un cambio ya escrito y te diga qué está mal, con el archivo, la línea y el escenario en el que se rompe.
Dónde rinde
Leer un diff entero sin saltearse el archivo aburrido. La atención no se le gasta — que es exactamente lo que le pasa al revisor humano a partir del sexto archivo.
Dónde falla
Te aprueba tu propio trabajo si el que revisa es el mismo hilo que escribió. Y sin un límite declarado encuentra hallazgos para siempre: la mitad son ruido, presentados con la misma seguridad que el hallazgo real.
Cómo sabés que salió bien
Cada hallazgo con archivo, línea y un escenario concreto de falla. Un hallazgo sin escenario es una opinión de estilo con tono de urgencia.
Proceso por defecto
Ceremonia liviana
Dónde corre
Siempre en un agente aparte
No es por ruido, es por independencia. El que revisa no puede haber visto cómo se escribió: si vio el razonamiento, va a revisar el razonamiento y no el resultado.
06
Decidir arquitectura
¿Qué opción tomamos, y dónde queda escrito el porqué?
Usarlo para abrir el abanico de alternativas y nombrar el costo de cada una, antes de que alguien —vos— elija.
Dónde rinde
Enumerar opciones que no se te habían ocurrido y ponerle nombre al costo de cada una. Como generador de alternativas es excelente, y encima no tiene el sesgo de haber trabajado seis años con una sola.
Dónde falla
Como decisor es directamente peligroso, porque no paga ninguna de las consecuencias. Y si le contás cuál preferís, te va a traer razones para tu preferencia. Eso no es una segunda opinión: es un espejo que redacta bien.
Cómo sabés que salió bien
La decisión guardada con las alternativas que descartaste y por qué las descartaste. Si en tres meses nadie puede reconstruir el porqué, la vas a volver a discutir entera.
Proceso por defecto
Ceremonia completa
Dónde corre
En el hilo principal
Decidir es lo único que no se delega. Podés delegar la investigación de cada alternativa; la elección la firma una persona.
07
Documentar
¿Cómo escribo lo que ya existe sin que quede viejo en un mes?
Convertir código en prosa: un README, la explicación de un módulo, el changelog que nadie escribió.
Dónde rinde
Sabe leer y sabe redactar, y esa combinación es rara en alguien apurado. Documentar es el trabajo que todos posponen, así que el piso contra el que compite es no tener nada.
Dónde falla
Documenta lo que el código hace, no lo que se supone que tiene que hacer. Y esa diferencia es toda la documentación que sirve: lo que hace ya lo podés leer del código.
Cómo sabés que salió bien
Que alguien que no participó pueda seguirlo sin preguntarte nada. No hay comprobación automática para esto, y pretender que la hay es peor que aceptar que no.
Proceso por defecto
Sin ceremonia
Dónde corre
Aparte si hace ruido
Si hay que leer medio repositorio para escribir dos páginas, que lo lea otro. Si estás documentando lo que acabás de hacer, delegarlo obliga al otro a redescubrirlo desde cero.
08
Migrar
¿Cómo subo de versión sin romper lo que ya andaba?
Subir una dependencia mayor, cambiar de framework o mover un módulo entero a otra forma de hacer las cosas.
Dónde rinde
El volumen. Una migración son cientos de llamadas que cambian igual, y ese trabajo es mecánico, enorme y absolutamente insoportable de hacer a mano.
Dónde falla
Aplica la API que aprendió en el entrenamiento, no la de la versión a la que estás migrando — que casi siempre es más nueva que lo que vio. Es el trabajo donde la documentación desactualizada hace más daño, porque el error recién se ve al ejecutar.
Cómo sabés que salió bien
La suite verde en la versión nueva, y las notas de cada cambio incompatible leídas por vos — no resumidas por el mismo agente que está haciendo la migración.
Proceso por defecto
Ceremonia completa
Dónde corre
Aparte si hace ruido
El inventario de qué hay que tocar va aparte y vuelve como lista. La migración se hace en tandas, cada una verificable sola.
Si mirás la columna de verificación de arriba abajo vas a ver el patrón: los trabajos que salen bien son aquellos donde comprobar el resultado es barato. Ahí está la palanca real — no en pedirle mejor, sino en construir la manera de comprobarle.