Estuve dos semanas sin escribirte y la razón es más o menos el tema de hoy, así que parto por ahí.
A mediados de agosto se fue una persona del equipo y de un día para otro quedé a cargo de dos proyectos que nunca había abierto, uno que estaba a punto de entregarse y otro a medio construir, los dos con el detalle importante viviendo en la cabeza de alguien que ya no iba a estar disponible para explicármelo. Esto le pasa a cualquiera que tenga equipo, sea de dos personas o de veinte, y no importa si la salida fue buena o mala ni si hubo aviso con tiempo. El problema tampoco es el código, el código está ahí y se lee. El problema es que del otro lado el cliente sigue esperando su entrega y a nadie le interesa que internamente hubo un cambio, así que necesitas estar operativo en días y no en semanas.
Llevo veinte años programando y lo que aprendí es que leer un proyecto ajeno por completo es la forma más lenta de entenderlo, y aun así es lo que uno hace por instinto, abrir el repositorio y empezar a leer archivos en orden como si eso fuera un plan.
Lo primero que hice no fue leer el código
Le pedí a la IA un mapa. No una explicación de qué hace cada función, que es lo que uno pide al principio y es justo lo que menos sirve, sino las cuatro cosas que necesitas para moverte sin romper nada, que son por dónde entra la información al sistema, por dónde sale, dónde está desplegado cada pedazo y qué se toca cuando cambias algo. Con eso puedes empezar a trabajar aunque no entiendas todavía la mitad del proyecto, porque sabes en qué parte estás parado.
Lo que leyendo me habría tomado varios días quedó armado en menos de una hora, y a partir de ahí ya no estaba explorando a ciegas sino verificando una hipótesis, que es un trabajo mucho más rápido y mucho menos angustiante.
Después viene la segunda pregunta, que es la que casi nadie hace, y es pedirle que liste lo que no pudo deducir del código. Ahí aparecen las variables de entorno que no sabe de dónde salen, los servicios externos que no puede ver, los procesos que alguien dispara a mano. Esa lista fea es el verdadero plan de trabajo de tu primera semana, porque cada línea es algo que vas a tener que preguntarle a alguien y mientras antes preguntes, más barata sale la pregunta.
Lo que la IA no te va a poder decir
El qué lo reconstruye muy bien y el cómo bastante bien, pero el porqué no está escrito en ninguna parte del código. Por qué este proceso corre a las tres de la mañana y no a medianoche, por qué este dato se guarda duplicado en dos lugares, por qué existe una excepción para un caso que a primera vista parece absurdo. Nada de eso se deduce del código, cada una de esas rarezas fue una conversación con un cliente o un incendio de una noche que alguien apagó, y cuando la IA no lo sabe no te dice que no lo sabe, te ofrece una explicación razonable que suena perfecta y que puede estar completamente equivocada. Un resumen impecable de algo que no funciona así es bastante peor que no tener resumen, porque te da confianza para tocar justo lo que no había que tocar.
Lo que de verdad me salvó no fue la IA sola. Hace rato que en los proyectos dejamos la documentación al día como parte del trabajo y no como algo que se hace al final si sobra tiempo, así que buena parte de esos porqués ya estaba escrita y el mapa que me armó la IA terminó siendo una verificación más que un descubrimiento, cosa de minutos. Ese es el punto incómodo del asunto, porque la IA acelera muchísimo cuando encuentra algo escrito, y cuando no hay nada escrito acelera igual, solo que hacia una explicación inventada.
Cómo lo replicas
Si te toca heredar un proyecto que no escribiste, sea porque alguien se fue, porque el cliente te pasa algo que hizo otro proveedor o porque volviste a un código tuyo de hace dos años, que es casi lo mismo:
Pide el mapa antes que la explicación. Entradas, salidas, dónde está desplegado y qué se rompe si tocas cada cosa. Una página, no un informe de cuarenta.
Pídele expresamente la lista de lo que no pudo deducir. Suena a poco y es lo más valioso de todo el ejercicio, porque te ordena a quién tienes que preguntarle qué, y te lo dice el primer día en vez del jueves de la semana siguiente.
Verifica levantando el proyecto, no leyendo el resumen. Haz un cambio chico y visible el mismo día, algo que se note en pantalla. Hasta que no levantas el proyecto y tocas algo no sabes qué parte del mapa era real.
Separa lo que el código hace de lo que el negocio decidió. Lo primero te lo saca la IA en minutos, lo segundo se pregunta, y la mitad de las cosas raras que vas a encontrar tienen una explicación comercial y no técnica.
Escribe el mapa en el repositorio el mismo día, mientras todavía no entiendes nada. Esa es la única ventana en que ves lo que a los de adentro ya se les hizo invisible, y se cierra rápido. En dos semanas vas a estar tan acostumbrado a las rarezas del proyecto que ya no te van a parecer rarezas.
Y una cosa que no es técnica y que me costó más que el resto. Cuando heredas un proyecto a la fuerza, la tentación es reescribir, porque nada está como tú lo habrías hecho y porque reescribir se siente como avanzar. La entrega que estaba pendiente salió porque no reescribí nada, entendí lo mínimo para mover lo que había que mover y lo demás quedó igual. El derecho a opinar sobre la arquitectura se gana después de la primera entrega, no antes.
La regla de una línea: la IA te reconstruye en menos de una hora qué hace un proyecto ajeno, pero por qué se hizo así no está en el código, así que o alguien lo dejó escrito aparte o se lo tienes que preguntar antes de tocar nada.
Las últimas noticias
Hablando de heredar cosas que no controlas, SpaceX cerró este mes la compra de Cursor por 60.000 millones de dólares, y a los pocos días OpenAI avisó que le corta el suministro de sus modelos con fecha 12 de noviembre, con el argumento de que no puede confiar en que SpaceX use su tecnología de acuerdo a sus términos de servicio, citando de paso los antecedentes de las otras empresas de Musk. Anthropic hizo justo lo contrario y salió a decir en cosa de horas que sigue considerando a Cursor un socio de confianza y que le va a subir el cómputo para que Claude siga funcionando ahí. Según la propia OpenAI el golpe es chico, porque sus modelos son alrededor del 5% del tráfico de Cursor y la mayoría de la gente que trabaja ahí ya lo hace con Claude o con Gemini, pero el fondo del asunto es otro, y es que la herramienta con la que programas todos los días puede cambiar de dueño una semana y perder un proveedor a la siguiente sin que tú participes en ninguna de las dos conversaciones.
Fuentes: OpenAI · CNBC · InfoWorld · The New Stack