Leer código sin saber programar: lo mínimo para revisar lo que hace la IA

¿Qué tienes que entender como mínimo?

Una página web tiene tres capas, y cada una responde una pregunta distinta:

Las etiquetas HTML tienen apertura, contenido y cierre, como <p>texto</p>. Algunas no tienen contenido ni cierre, como <img>; MDN las llama elementos vacíos. Los atributos son ajustes de la etiqueta, por ejemplo alt, que describe una imagen para un lector de pantalla. Las etiquetas se anidan: <head> y <body> van dentro de <html>, y <title> dentro de <head>. El navegador muestra lo que está en <body> y el título en la pestaña (MDN, HTML basics).

JavaScript le da comportamiento. Un ejemplo típico: una variable guarda los elementos de la lista, una función cambia la clase de un elemento, y un evento click ejecuta la función cada vez que alguien hace clic (MDN, JavaScript basics).

¿Cómo se lee un cambio (diff)?

Casi siempre verás el trabajo de la IA como un diff: una lista de lo que cambió respecto a la versión anterior. En el formato estándar de Git, las líneas que empiezan con + son nuevas, las que empiezan con - se eliminaron y las que empiezan con un espacio no cambiaron y sirven de contexto (documentación de git diff). En GitHub, la pestaña Files changed de un pull request muestra ese diff y permite elegir vista unificada o dividida (documentación de GitHub).

Para empezar, ignora el detalle y mira la forma. ¿Cuántos archivos cambiaron? ¿Hay muchas líneas con - en un archivo que no tenía por qué tocarse? Un cambio pequeño y concentrado es más fácil de revisar que uno enorme y disperso. Si el diff es enorme, pide al agente que lo divida en pasos. El flujo completo está en ramas y pull requests.

¿Qué revisar en un cambio de la IA?

No hace falta entender cada línea. Si todavía no tienes claro el contexto de estos cambios, mira primero qué es vibe coding. Revisa cinco cosas:

1. Qué archivos cambiaron. Si el cambio pedía una pantalla y tocó la configuración de la base de datos, algo no cuadra.
2. Qué datos se guardan. Busca nombres de campos como email, password, phone o token.
3. Qué hace cada botón. Encuentra el texto del botón y el evento que lo dispara. Si borra o envía, debe pedir confirmación.
4. Si hay secretos a la vista. Claves con formato largo o palabras como api_key en un archivo que va al navegador son una señal de alarma.
5. Qué pasa en el caso raro. Campo vacío, dos usuarios distintos, conexión lenta.

Estas revisiones no sustituyen a una auditoría de seguridad, pero detectan los errores más comunes antes de publicar. Para el siguiente nivel, revisa seguridad básica para quien hace vibe coding, y para los secretos, variables de entorno y secretos.

¿Cómo preguntarle al agente?

Puedes pedir una explicación en lenguaje llano, y es válido hacerlo. Preguntas útiles:

• “¿Qué archivos cambiaste y por qué?”
• “Explícame qué hace este botón, paso a paso.”
• “¿Qué guarda esta función y dónde?”
• “¿Qué pasa si el usuario hace clic dos veces?”
• “¿Cómo puedo comprobar que esto funciona sin tocar código?”

Si la respuesta es vaga o cambia cada vez que la preguntas, no la tomes como prueba. Pide que la muestre en el código o en una prueba.

La guía de buenas prácticas de Claude Code va en la misma dirección: pide evidencia, es decir, el comando que el agente ejecutó y su salida, o una captura de pantalla. Un “todos los tests pasan” sin más dice muy poco. La regla sirve con cualquier herramienta: lo que importa es ver el resultado, no creer el resumen. Si algo falla, debugging con IA explica cómo pedirle al agente que investigue el problema antes de arreglarlo.

Ejemplo

Ejemplo ilustrativo: un diseñador revisa un cambio que añade un botón “Eliminar cuenta” a su app. Lee el nombre del botón, sigue el evento click hasta la función y ve que la función llama a una ruta de borrado directamente, sin confirmación. Le pide al agente que añada un diálogo de confirmación con el texto “Esta acción no se puede deshacer” y que haga la prueba de clic cancelado. Antes de aceptar, busca en los archivos la palabra key y no encuentra claves visibles. El diseñador no escribió código; leyó lo suficiente para hacer tres preguntas correctas.

¿Cómo practicarlo desde mañana?

1. Abre el proyecto en un editor y busca tres cosas sin entender nada más: los nombres de los archivos, los textos de los botones y las palabras de datos como email o password.
2. Elige un botón que haga algo importante y sigue su camino: el texto del botón, el evento que lo dispara y la función que se ejecuta. Anota en una frase qué hace.
3. Pide al agente que te explique ese camino en lenguaje llano y compara su explicación con lo que leíste. Si no coinciden, pregunta de nuevo.
4. Repite el ejercicio cada vez que un cambio toque algo de dinero, de datos personales o de accesos.

Empieza por un archivo que ya conozcas, como el texto principal de la página. Seguir una sola cosa pequeña de principio a fin da más confianza que hojear diez archivos. Una nota corta con el archivo que leíste, el botón que seguiste y la pregunta que hiciste te sirve de guía la próxima vez.

Errores comunes

• Aceptar un cambio porque la pantalla se ve bien, sin revisar qué datos toca.
• Pensar que no entender el código significa que no puedes preguntar sobre él.
• Confiar en una explicación del agente sin pedir que la muestre en el código.
• Dejar secretos en archivos que se envían al navegador.
• Revisar solo el camino feliz, sin probar un campo vacío o un clic doble.
• Creer que leer código equivale a auditar seguridad.

Fuentes

• MDN Web Docs, “HTML basics” (Learn web development): https://developer.mozilla.org/en-US/docs/Learn/Getting_started_with_the_web/HTML_basics
• MDN Web Docs, “JavaScript basics” (Learn web development): https://developer.mozilla.org/en-US/docs/Learn/Getting_started_with_the_web/JavaScript_basics
• Anthropic, “Best practices for Claude Code” (pedir evidencia, no solo afirmaciones): https://code.claude.com/docs/en/best-practices
• Git, documentación de git diff (marcas +, - y espacio en el formato unificado): https://git-scm.com/docs/git-diff
• GitHub Docs, “Reviewing proposed changes in a pull request” (pestaña Files changed, vista unificada o dividida): https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/reviewing-proposed-changes-in-a-pull-request