El error que cometen al dejar que IA genere componentes React

Acabás de pedirle a ChatGPT que te genere un componente React para un formulario de contacto. En 30 segundos tenés 80 líneas de código que funcionan. Lo copiás, lo pegás, lo probás en el navegador y todo se ve perfecto. Commiteas y seguís con lo siguiente. Tres semanas después, cuando necesitás reutilizar ese componente en otro contexto, te das cuenta de que es un bloque monolítico con props sin tipar, estilos hardcodeados y cero accesibilidad. El código que te ahorró 20 minutos te va a costar 3 horas de refactor.

La IA genera código funcional, no código escalable. Y la diferencia entre ambos es exactamente lo que separa un proyecto que crece de uno que se pudre.

El problema real no es la IA, es la validación cero

El código generado por IA está optimizado para funcionar rápido en un caso de uso específico. No está pensado para:

• Reutilizarse en múltiples contextos
• Escalar cuando el producto crece
• Ser mantenido por otras personas (o por vos mismo en 6 meses)
• Cumplir estándares de accesibilidad
• Integrarse con una arquitectura existente

Cuando copiás sin validar, estás introduciendo deuda técnica silenciosa. El componente funciona hoy, pero mañana alguien va a necesitar:

• Cambiar el color del botón → descubre que está hardcodeado en 5 lugares
• Agregar validación → no hay separación entre UI y lógica
• Hacer el formulario accesible → faltan todos los atributos ARIA
• Reutilizar el input → está acoplado al formulario completo

Y ahí empieza el refactor que nadie planeó.

Props sin tipar y componentes que mienten

Uno de los errores más frecuentes en código generado por IA es la falta de tipado real. La IA suele generar algo así:

interface CardProps {
  title: string;
  description: string;
  image: string;
  onClick: () => void;
}

function Card({ title, description, image, onClick }: CardProps) {
  return (
    <div onClick={onClick}>
      <img src={image} alt="image" />
      <h3>{title}</h3>
      <p>{description}</p>
    </div>
  );
}

Parece correcto. Tiene TypeScript, tiene una interfaz. Pero:

• image debería ser imageUrl o imageSrc para ser más explícito
• El alt está hardcodeado como "image", violando accesibilidad básica
• onClick en un div no es semántico ni accesible (debería ser un button)
• No hay manera de pasar clases CSS o estilos personalizados
• Faltan props opcionales como imageAlt, variant, size

En un componente real y escalable, las props deberían reflejar todos los casos de uso posibles y estar documentadas:

interface CardProps {
  title: string;
  description: string;
  imageSrc: string;
  imageAlt: string;
  onPress?: () => void;
  variant?: 'default' | 'outlined' | 'elevated';
  className?: string;
  testId?: string;
}

La IA genera el mínimo viable para que funcione. Vos tenés que completar el resto.

Componentes monolíticos que no reutilizan nada

La IA tiende a generar componentes autosuficientes que resuelven todo en un solo lugar. Es lógico: su objetivo es que el código funcione de inmediato. Pero en un proyecto real, eso mata la composición.

Ejemplo típico generado por IA:

function UserProfile() {
  const [user, setUser] = useState(null);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(null);

  useEffect(() => {
    fetch('/api/user')
      .then(res => res.json())
      .then(data => {
        setUser(data);
        setLoading(false);
      })
      .catch(err => {
        setError(err.message);
        setLoading(false);
      });
  }, []);

  if (loading) return <div>Loading...</div>;
  if (error) return <div>Error: {error}</div>;

  return (
    <div>
      <img src={user.avatar} alt="avatar" />
      <h2>{user.name}</h2>
      <p>{user.email}</p>
    </div>
  );
}

Este componente hace todo: fetching, manejo de estado, UI, loading, errores. Ahora intentá:

• Reutilizar la lógica de fetch en otro componente → no podés
• Cambiar el diseño del loading → está hardcodeado
• Agregar un placeholder mientras carga la imagen → requiere refactor completo
• Testear la UI sin hacer un fetch real → imposible

En un código escalable, separás responsabilidades:

// Hook personalizado
function useUser() {
  const [user, setUser] = useState(null);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(null);

  useEffect(() => {
    fetchUser().then(setUser).catch(setError).finally(() => setLoading(false));
  }, []);

  return { user, loading, error };
}

// Componente de UI pura
function UserProfile() {
  const { user, loading, error } = useUser();

  if (loading) return <LoadingSpinner />;
  if (error) return <ErrorMessage message={error} />;
  if (!user) return null;

  return <UserCard user={user} />;
}

Ahora cada pieza es reutilizable, testeable y fácil de modificar.

Accesibilidad: el agujero negro del código generado

La IA rara vez genera código accesible. Y no es porque no sepa, es porque la accesibilidad requiere decisiones de diseño que la IA no tiene contexto para tomar.

Errores típicos:

• <div onClick> en lugar de <button>
• Imágenes sin alt descriptivo
• Formularios sin <label> asociados
• Falta de atributos ARIA en elementos interactivos
• Sin manejo de teclado (onKeyDown, tabIndex)
• Colores sin contraste suficiente

Código generado por IA:

<div className="card" onClick={handleClick}>
  <img src={image} />
  <div className="title">{title}</div>
</div>

Código accesible:

<button
  className="card"
  onClick={handleClick}
  aria-label={`Ver detalles de ${title}`}
>
  <img src={image} alt={imageAlt} />
  <h3 className="title">{title}</h3>
</button>

Si copiás sin validar, estás dejando afuera a usuarios con discapacidades. Y eventualmente, eso se convierte en un problema legal y ético.

Checklist: qué validar antes de usar código generado por IA

Antes de commitear código generado por IA, pasá por esta lista:

• Props bien tipadas: ¿Están todas las props necesarias? ¿Son opcionales las que deben serlo?
• Accesibilidad básica: ¿Hay alt en imágenes? ¿Se usan elementos semánticos? ¿Funciona con teclado?
• Separación de responsabilidades: ¿El componente mezcla lógica y UI? ¿Se puede dividir?
• Reutilización: ¿Este componente sirve en otros contextos? ¿O está acoplado a un caso específico?
• Estilos: ¿Están hardcodeados? ¿Se pueden personalizar vía props o CSS?
• Testing: ¿Se puede testear sin hacer fetch real? ¿La lógica está aislada?
• Performance: ¿Hay re-renders innecesarios? ¿Se usan useMemo o useCallback donde corresponde?

Si la respuesta a más de dos preguntas es "no", necesitás refactorizar antes de mergear.

La IA es un primer borrador, no el producto final

La IA te da velocidad, pero no criterio. Te genera un componente funcional en segundos, pero no sabe si ese componente va a convivir con otros 200 en un design system. No sabe si tu equipo prioriza accesibilidad, performance o testing.

Usar IA para generar componentes React está bien. Copiar sin revisar es el error.

El código generado por IA debería ser tratado como un wireframe: te da estructura, pero después vos le agregás las decisiones que importan. Props bien tipadas, accesibilidad, composición, reutilización. Todo eso sigue siendo tu responsabilidad.

Preguntas frecuentes

¿La IA puede generar componentes React escalables?

La IA puede generar código funcional, pero rara vez genera código escalable sin intervención humana. Podés usar prompts más específicos ("genera un componente React con TypeScript estricto, accesible, y props bien documentadas"), pero aún así vas a necesitar revisar y ajustar. La IA no tiene contexto de tu arquitectura, tu design system o tus decisiones de escalabilidad.

¿Cómo saber si un componente generado por IA es reutilizable?

Preguntate: ¿puedo usar este componente en otro contexto sin modificarlo? ¿Las props son lo suficientemente genéricas? ¿Está acoplado a lógica de negocio específica? Si tenés que tocar el código interno para reutilizarlo, entonces no es reutilizable. Un buen componente acepta props que cambian su comportamiento sin necesidad de modificar su implementación.

¿Qué herramientas ayudan a validar componentes React generados por IA?

ESLint con plugins de accesibilidad (eslint-plugin-jsx-a11y), TypeScript en modo estricto, Storybook para documentar variantes, y herramientas como axe DevTools para auditar accesibilidad. También podés usar Lighthouse en Chrome para validar performance y accesibilidad automáticamente.