La IA es el medio, no el fin: cómo usarla sin dejar de entender

Mon, 31 Aug 2026 00:00:00 GMT

import { MountainExperienceComparisonDemo } from "@/components/react/ComponentComparison/MountainExperienceComparisonDemo";

Un caso concreto: construir un playground

Quería comparar un componente de experiencia de montaña antes y después de una refactorización. La petición parecía sencilla: mostrar el código, permitir editarlo y renderizar el resultado en un sandbox.

La pieza que se quería comparar era React, pero se usaba desde Astro. Esa diferencia importa. Experience.astro no es la montaña ni contiene la interacción de las flags. Es el componente de página que prepara los datos y monta MountainExperience con client:load.

La relación original se parecía a esto:

Experience.astro
└── MountainExperience.tsx
    ├── Popover.tsx
    ├── icons/FlagIcon.tsx
    └── style.module.css

El antes: un consumidor Astro y un componente React

En el proyecto, Experience.astro importaba el componente React así:

---
import { MountainExperience } from "../react/MountainExperience/MountainExperience";
import dataExperiences from "@/utils/data/experience.json";
---

<MountainExperience client:load experiences={dataExperiences} />

Para mostrar el “Antes” en Sandpack había que decidir qué se quería ejecutar. Sandpack podía ejecutar MountainExperience.tsx con React, pero no el archivo Astro que lo consumía. Por eso el archivo Experience.astro podía aparecer como referencia en el editor, mientras que el preview necesitaba un App.js equivalente:

App.js                  ← punto de entrada ejecutable del sandbox React
MountainExperience.tsx  ← componente original
Popover.tsx             ← dependencia del componente
FlagIcon.tsx            ← dependencia del componente
old-style.module.css    ← estilos originales
Experience.astro        ← referencia del consumidor real

Este es el ejemplo real que acompaña al artículo. El bloque incluye el editor y el preview del “Antes”, además de Experience.astro como archivo de referencia.

La primera propuesta mezcló esos dos entornos. Intentaba ejecutar un componente Astro dentro de un sandbox configurado para React. El archivo podía aparecer en el editor, pero el servidor no sabía cómo arrancarlo. Después de cambiar la plantilla, Astro seguía cayéndose con una página mínima.

Ese no fue el único problema. El sandbox nuevo no cargaba el SVG de la montaña porque la ruta pública no se resolvía como esperaba. En otra prueba, la navegación interna reemplazaba la página antes de que algunos estilos del playground estuvieran disponibles. El resultado funcionaba después de recargar, pero no al llegar desde el menú.

El después: una demo autocontenida

El “Después” ya no reutiliza la estructura antigua. MountainExperienceLab.tsx concentra la interacción, la lista y los estados de selección. style.module.css contiene sus estilos, y App.js solo le pasa los datos y el título de la demo:

App.js                    ← consumidor React del sandbox
MountainExperienceLab.tsx ← componente refactorizado
style.module.css           ← estilos del componente
styles.css                 ← estilos generales del preview

En la página del laboratorio, estos dos bloques pueden colocarse uno debajo del otro: primero el “Antes”, con el árbol y la pantalla del componente original, y después el “Después”, con la versión autocontenida. Así se compara el resultado sin hacer pasar un archivo Astro por un archivo React ejecutable.

La IA produjo código válido en partes, pero no entendió todas las fronteras del sistema: qué ejecuta Sandpack, qué archivos sirve como públicos, cómo se hidrata un island de Astro y qué ocurre durante una navegación cliente. Leer el diff y reproducir cada fallo fue más útil que pedir otra implementación completa.

La pregunta correcta reduce el problema

Una respuesta extensa puede abrir más caminos de los que cierra. Añade bibliotecas, patrones y supuestos que no estaban en la pregunta original. En ese punto, pedir otra alternativa suele empeorar la decisión.

Antes de usar IA conviene escribir tres cosas:

Qué resultado debe ver la persona usuaria.
Qué tecnología y archivos forman parte del problema.
Cómo sabremos que la solución funciona.

En el playground, esa tercera respuesta podía ser concreta: el sandbox debía iniciar, el componente debía mostrar la montaña, el SVG debía cargar y la navegación desde el menú debía conservar los estilos. La IA debería reducir una incertidumbre concreta, no acumular posibilidades.

Comprender no significa hacerlo todo a mano

No hace falta escribir cada línea para revisar un cambio. Sí hace falta entender lo suficiente para hacer preguntas útiles y detectar una solución que solo funciona en el caso feliz.

En el ejemplo anterior, conocer la diferencia entre un archivo fuente y un archivo ejecutable permitió separar dos necesidades. Experience.astro podía mostrarse como referencia, pero no podía ejecutarse dentro de un sandbox React. También hizo falta distinguir entre una ruta de importación y una URL pública. Son detalles pequeños, pero de ellos dependía que la demo funcionara.

Cuando todavía estás aprendiendo una tecnología, la IA puede servir para explorar. Pídele una explicación, un ejemplo pequeño y una forma de comprobarlo. Cuando ya conoces el entorno, puede preparar una implementación más amplia. En ambos casos, la revisión sigue siendo tuya.

La explicación no es la prueba

Una respuesta bien redactada puede ser falsa, contradictoria o estar respaldada por referencias inexistentes. El perfil de riesgos de IA generativa de NIST incluye la producción de contenido erróneo o inconsistente entre los riesgos de estos sistemas.

En software, que el código compile tampoco basta. Hay que mirar el diff, abrir la pantalla, probar los casos importantes y repetir el recorrido que fallaba. En este caso, la prueba decisiva no era "el componente compila". Era entrar al laboratorio desde la navegación y comprobar que el editor, el preview, el SVG y los estilos aparecían juntos.

Una explicación de la IA puede señalar dónde mirar. No puede reemplazar esa comprobación.

Un flujo corto para trabajar con IA

Este proceso me resulta suficiente para cambios de este tamaño:

Definir: escribir el resultado esperado y el contexto que no puede perderse.
Acotar: separar los archivos que puede modificar de los que solo debe consultar.
Dividir: pedir primero una parte que pueda ejecutarse o revisarse por separado.
Inspeccionar: leer el diff y comprobar que no aparecieron decisiones nuevas sin explicar.
Verificar: ejecutar la prueba que representa el riesgo real, incluida la navegación o el caso límite.
Decidir: aceptar, corregir o descartar según la evidencia.

La productividad de estas herramientas depende de la tarea y del entorno. En un experimento controlado sobre una tarea acotada, quienes usaron GitHub Copilot terminaron un 55,8 % más rápido (Peng et al., 2023). En cambio, un ensayo de METR con desarrolladores experimentados en repositorios maduros encontró que el uso de herramientas de IA aumentó el tiempo de resolución en un 19 %, aunque los participantes creían haber sido más rápidos (Becker et al., 2025). Son resultados de escenarios concretos, no una promesa general.

Antes de aceptar un resultado, comprueba:

¿Resuelve el problema definido?
¿Respeta las tecnologías y los límites del proyecto?
¿Puedo explicar las decisiones importantes?
¿Probé el comportamiento que más riesgo tiene?
¿Sé qué queda sin verificar?

La IA puede escribir más rápido que nosotros. La decisión de qué conservar sigue necesitando una persona que entienda el problema.

quesocaliente.dev