Contexto y CódigoDesarrollo de software e inteligencia artificial
English

Cómo revisar el código que escribió una IA

Leonardo Gurgitano5 minLeer en inglés

Superficie de hormigón regular y prolija, fotografiada de frente.
Superficie de hormigón regular y prolija, fotografiada de frente.

Le pediste una función, te la escribió, la ejecutaste y funciona. El código se ve prolijo: nombres claros, manejo de errores, hasta comentarios.

Y ahí está el problema. El código que escribe una IA siempre se ve bien. No tiene las señales que aprendiste a detectar en el código apurado de una persona: variables llamadas temp2, funciones de doscientas líneas, comentarios que dicen “arreglar esto después”. Está prolijo aunque esté mal.

Revisarlo no es leerlo con más atención. Es mirar cosas distintas. Estas seis, en este orden.

1. ¿Hace exactamente lo que pediste, o algo parecido?

Es el error más común y el más fácil de pasar por alto, porque el resultado se parece bastante a lo que querías.

Pediste “que ordene los usuarios por fecha de registro”. Te devuelve:

usuarios.sort((a, b) => a.fechaRegistro - b.fechaRegistro);

Ordena, sí. De más viejo a más nuevo. Si vos querías los últimos primero, está al revés. La función anda, no lanza ningún error, y la lista sale ordenada. Solo está al revés.

La comprobación: volvé a leer lo que pediste y compará frase por frase con lo que hace el código. No con lo que dice que hace: con lo que hace.

2. Los casos de los bordes

Una IA escribe el camino feliz muy bien. Los bordes, no tanto, porque en lo que aprendió esos casos aparecen menos.

function promedio(numeros) {
  const suma = numeros.reduce((a, b) => a + b, 0);
  return suma / numeros.length;
}

Correcto para [1, 2, 3]. Con una lista vacía devuelve NaN, que después recorre todo tu sistema y aparece en la pantalla del usuario como “NaN” sin que nada haya fallado en el camino.

Las cuatro preguntas que conviene hacerse siempre:

  • ¿Qué pasa si la lista está vacía?
  • ¿Qué pasa si el valor es null o no vino?
  • ¿Qué pasa si el número es cero, o negativo?
  • ¿Qué pasa si el texto está vacío o tiene acentos y emojis?

3. Bibliotecas que no existen

Este suena raro hasta que te pasa. A veces el código importa una biblioteca con un nombre muy razonable que simplemente no existe, o que existe pero no tiene esa función.

import { formatearFechaRelativa } from 'date-fns';   // no existe

Se detecta al instalar o al ejecutar, así que rara vez llega lejos. Pero hay una versión peligrosa: si el nombre inventado es plausible, alguien puede haber publicado un paquete con ese nombre exacto esperando que lo instales. Es un ataque conocido.

Antes de instalar algo que te sugirió una IA, mirá el paquete: cuántas descargas tiene, cuándo fue la última publicación, si el repositorio existe. Diez segundos.

4. El manejo de errores que esconde el error

Este patrón aparece muchísimo:

try {
  const datos = await traerDatos();
  return datos;
} catch (error) {
  console.error(error);
  return null;
}

Se ve responsable. Está manejando el error. Pero lo que hace es convertir una falla en un null que sigue viaje por tu programa. Tres funciones más adelante algo va a romperse, y el mensaje de error no va a tener nada que ver con la causa real.

La pregunta correcta ante cada catch: ¿este código puede seguir de verdad sin ese dato? Si la respuesta es no, que la falla se propague. Un error ruidoso en el lugar correcto vale más que uno silencioso en el lugar equivocado.

5. Lo que no aparece en el archivo que estás mirando

Una IA ve lo que le pasaste. Si le pediste una función de un archivo, no sabe que en otro archivo ya existe algo casi igual, ni que tu proyecto tiene una forma establecida de hacer las cosas.

El resultado es duplicación silenciosa: dos funciones que validan correos con reglas apenas distintas, dos formatos de fecha, dos maneras de llamar a la API.

Antes de aceptar una función nueva, buscá en tu proyecto si ya existe algo parecido. Un grep por el nombre del concepto alcanza casi siempre.

6. Los números y los textos escritos a mano

if (usuario.plan === 'premium' && diasDesdeRegistro > 30) {

¿De dónde salió el 30? ¿Y 'premium' es exactamente el texto que usa tu base de datos, o allá dice 'PREMIUM'?

Cuando una IA no conoce tus valores, los inventa razonables. Cada número y cada texto literal que aparece en el código generado es algo que hay que verificar contra tu sistema real.

El orden que uso

Cuando el código es corto, todo esto lleva un minuto. Cuando es largo, sirve un orden:

  1. Leer lo que pedí y compararlo con lo que el código hace.
  2. Buscar los valores literales y verificar cada uno.
  3. Probar mentalmente con lista vacía, null y cero.
  4. Mirar cada catch y preguntar si puede seguir sin ese dato.
  5. Verificar que las bibliotecas existan.
  6. Buscar si eso ya estaba en el proyecto.

Una forma de que aparezcan solos

Todo lo anterior es revisión manual. Hay algo que hace que varios de estos problemas se manifiesten sin que los busques: escribí la prueba antes de pedir el código, aunque sea una sola.

test('promedio de lista vacía devuelve 0', () => {
  expect(promedio([])).toBe(0);
});

Esa prueba de tres líneas convierte una instrucción ambigua en un criterio verificable, y detecta el caso 2 sin que tengas que acordarte de mirarlo.

Lo que no cambia

Sigue valiendo la regla de siempre: no subas código que no podés explicar. Si te preguntan por qué esa línea está ahí y la respuesta es “me lo dio la IA”, ese código todavía no es tuyo — y cuando falle a las tres de la mañana, tampoco vas a poder arreglarlo.

Comentarios