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

> Lo mínimo para revisar código generado por IA sin saber programar: HTML, CSS y JavaScript, qué mirar en un cambio y cómo preguntarle al agente.

*Tags: ia, codigo, revision, ux-para-ia*

---


> [!info] Definición Rápida
> **Leer código sin saber programar** es entender la estructura de lo que la IA generó: qué partes forman la página, qué hace cada acción y qué datos toca. Permite revisar un cambio con criterio aunque no escribas una línea.


## ¿Qué tienes que entender como mínimo?

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

| Capa | Pregunta que responde | Cómo se reconoce |
|---|---|---|
| HTML | ¿Qué hay en la página? | Etiquetas entre paréntesis angulares: `<h1>`, `<button>`, `<img>` |
| CSS | ¿Cómo se ve? | Reglas de color, tamaño y espacio, por ejemplo `color: red;` |
| JavaScript | ¿Qué pasa cuando alguien hace algo? | Funciones, eventos como `click` y valores que cambian |

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](https://developer.mozilla.org/en-US/docs/Learn/Getting_started_with_the_web/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](https://developer.mozilla.org/en-US/docs/Learn/Getting_started_with_the_web/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](https://git-scm.com/docs/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](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/reviewing-proposed-changes-in-a-pull-request)).

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|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 [[que-es-vibe-coding|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-basica-en-vibe-coding|seguridad básica para quien hace vibe coding]], y para los secretos, [[variables-de-entorno-y-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|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](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](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](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](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](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/reviewing-proposed-changes-in-a-pull-request)


---

Source: https://www.fernandoux.com/es/wiki/ia/leer-codigo-sin-saber-programar/