Desarrollo de interfaces con IA y componentes de shadcn/ui

Los asistentes de programación con IA producen bien código de interfaz, y shadcn/ui es una base popular para ese código porque los componentes viven en tu propio repositorio. Esa combinación te puede poner una pantalla funcionando adelante en poco tiempo. Que se pueda publicar rápido depende de lo que revises antes de lanzarla: accesibilidad, dependencias y el propio código generado.

Qué es shadcn/ui y por qué encaja con el trabajo asistido por IA

La documentación de shadcn/ui describe el proyecto sin rodeos: "This is not a component library. It is how you build your component library." (no es una biblioteca de componentes, es la forma en que armás tu biblioteca de componentes). En lugar de instalar un paquete e importar una caja negra, usás su CLI para agregar un componente, y el código fuente de ese componente se escribe dentro de tu proyecto. Ese código es tuyo y lo podés cambiar.

La documentación menciona "AI-Ready" como objetivo de diseño, descripto como "Open code for LLMs to read, understand, and improve." (código abierto para que los LLM lo lean, lo entiendan y lo mejoren). En la práctica esto importa porque un asistente de IA que trabaja en tu editor puede ver el componente real de botón, diálogo o formulario que está combinando, en lugar de adivinar la API de una biblioteca.

El repositorio con el código fuente en GitHub está publicado bajo la licencia MIT.

Esa misma característica tiene su contracara. Como los componentes son tu código, nadie los corrige por vos desde el proyecto original después de que los cambiás, y un asistente de IA los puede editar con la misma libertad con la que edita cualquier otra cosa.

Cómo empezar con la CLI actual

La CLI se publica como el paquete shadcn. La documentación muestra estos comandos para configurar un proyecto existente y agregar un componente:

npx shadcn@latest init
npx shadcn@latest add button

La CLI también tiene un comando view para previsualizar elementos del registro antes de instalarlos, y un comando docs que trae la documentación de un componente. Los comandos y las opciones cambian entre versiones, así que revisá la página de la CLI y no un tutorial viejo ni la memoria de un asistente de IA. Un asistente entrenado con material anterior puede sugerir comandos u opciones que ya cambiaron.

Después de add, el componente aparece en tu proyecto, en los ejemplos de la documentación normalmente importado como @/components/ui/button. Hacé un commit solo con ese componente antes de que vos o la IA lo modifiquen. Así tenés una base limpia para comparar el diff de cada cambio posterior.

Un patrón de trabajo para interfaces con IA

1. Agregá con la CLI los componentes de shadcn/ui que necesites y hacé el commit sin tocarlos.
2. Pedile al asistente una pantalla o un componente por vez, y decile qué componentes existentes tiene que usar. "Armá el formulario de configuración con nuestros componentes Input, Label y Button de components/ui" produce código más coherente que "hacé una página de configuración".
3. Revisá el diff. Buscá paquetes nuevos, estilos copiados que duplican tu tema y ediciones que no pediste en los componentes compartidos de components/ui.
4. Corré los controles de accesibilidad y los tests que siguen.
5. Hacé el merge solo después de que una persona distinta de la que escribió el pedido lo haya mirado en un navegador.

Controles de accesibilidad que la interfaz generada por IA suele pasar por alto

La documentación de shadcn/ui describe los componentes como accesibles. Esa es una característica de los componentes tal como vienen. El código generado que los usa igual puede romper la accesibilidad, y estos son los huecos que conviene buscar:

• Botones que tienen solo un ícono y ningún nombre accesible. Un ícono de tacho de basura no le dice nada a un lector de pantalla si el botón no tiene una etiqueta.
• Campos de formulario sin una etiqueta asociada, o con el texto de ejemplo (placeholder) como única etiqueta.
• Divs clickeables en lugar de botones o links, a los que no se llega con el teclado.
• Links con estilo de botón que terminan con el rol equivocado. La página de Button en la documentación advierte puntualmente sobre uno de estos patrones y recomienda aplicar los estilos de botón a un link común.
• El color como única señal para errores o estados.
• El foco que desaparece después de cerrar un diálogo, o directamente ningún estilo de foco visible.

Probá solo con el teclado: recorré la pantalla con Tab, abrí y cerrá cada diálogo, enviá cada formulario. Después corré un verificador automático en las herramientas para desarrolladores del navegador. Ninguna de las dos cosas reemplaza las pruebas con tecnología de asistencia real para los flujos importantes, pero juntas detectan la mayor parte de lo que el markup generado por IA hace mal.

Un ejemplo de componente con test

Este es un componente chico armado sobre el Button de shadcn/ui, con un test que verifica lo que la IA más seguido se olvida: un nombre accesible en un botón que tiene solo un ícono.

// components/delete-row-button.tsx
import { Trash2 } from "lucide-react"
import { Button } from "@/components/ui/button"

type Props = {
  itemName: string
  onDelete: () => void
}

export function DeleteRowButton({ itemName, onDelete }: Props) {
  return (
    <Button
      variant="ghost"
      size="icon"
      aria-label={`Delete ${itemName}`}
      onClick={onDelete}
    >
      <Trash2 aria-hidden="true" />
    </Button>
  )
}

// components/delete-row-button.test.tsx
import { render, screen } from "@testing-library/react"
import userEvent from "@testing-library/user-event"
import { expect, test, vi } from "vitest"
import { DeleteRowButton } from "./delete-row-button"

test("has an accessible name and calls onDelete", async () => {
  const onDelete = vi.fn()
  render(<DeleteRowButton itemName="Invoice 42" onDelete={onDelete} />)

  const button = screen.getByRole("button", { name: "Delete Invoice 42" })
  await userEvent.click(button)

  expect(onDelete).toHaveBeenCalledTimes(1)
})

El test encuentra el botón por su rol y su nombre accesible, que es la consulta que la documentación de Testing Library recomienda como "your top preference for just about everything" (tu primera opción para casi todo). Si alguien, o un asistente, saca después la etiqueta, el test falla. El ejemplo supone que Vitest, Testing Library y el set de íconos lucide-react ya están en el proyecto; adaptalo al test runner y al set de íconos que uses. Los nombres de variante y tamaño salen de la documentación actual de Button, así que confirmalos contra la versión que instalaste.

Revisión de dependencias y licencias

Cada shadcn add y cada sugerencia de la IA pueden sumar paquetes. Antes del merge:

• Leé los cambios de dependencias en el diff del manifiesto de paquetes y del lockfile. Preguntate por qué está ahí cada paquete nuevo.
• Revisá la licencia de cada paquete nuevo contra lo que tu empresa puede aceptar. Que shadcn/ui tenga licencia MIT no te dice la licencia de lo que arrastra un componente.
• Revisá el mantenimiento: versiones recientes, avisos de seguridad abiertos y quién lo publica.
• Corré el comando de auditoría de tu gestor de paquetes y leé el resultado en lugar de dejar que lo corrija solo.
• Rechazá los paquetes que el asistente agregó para resolver algo que tus componentes existentes ya resuelven.

Revisión del código generado

Estos controles cuestan mucho menos que rehacer una interfaz después de lanzarla.

Dónde entra automotif

Si tu equipo arma herramientas internas o pantallas para clientes y quiere una forma repetible de usar asistentes de IA con shadcn/ui, el servicio que más encaja es adopción de IA: capacitación sobre tus tareas reales de interfaz y una guía por escrito para escribir instrucciones, revisar y testear. Para ver si le sirve a tu equipo, reservá una llamada gratis de 30 a 60 minutos.

Fuentes

• Introduction (shadcn/ui docs)
• CLI (shadcn/ui docs)
• Button (shadcn/ui docs)
• shadcn-ui/ui repository and license (GitHub)
• About Queries (Testing Library docs)