Efectos Shader con IA: Cómo Construí Magia con 3JS en 4 Minutos

Efectos Shader con IA: Cómo Construí Magia con 3JS en 4 Minutos

Seis horas. Eso es lo que pasé mirando código GLSL la primera vez que intenté añadir un efecto de distorsión al hacer hover en la página de galería de un cliente.

No seis horas construyendo toda la página. Seis horas en una animación de hover que duraba exactamente 0.4 segundos cuando el ratón del usuario se movía sobre una imagen.

El vertex shader estaba bien. El fragment shader funcionaba de forma aislada. ¿Pero pasar las variables uniform correctamente? ¿Conseguir que las coordenadas del ratón estuvieran normalizadas? ¿Manejar el redimensionamiento del canvas en diferentes tamaños de viewport? Seguía chocando con muros que no sabía que existían — y cada respuesta de Stack Overflow que encontraba tenía tres años de antigüedad, usaba una versión completamente diferente de Three.js, o asumía que yo ya sabía cosas que claramente no sabía.

Lancé la página sin el efecto shader. Solo una aburrida transición de opacidad CSS. El cliente no lo notó. Pero yo sí — porque había pasado seis horas fracasando en algo que había visto a desarrolladores creativos junior ejecutar impecablemente en sitios premiados, y la brecha entre lo que podía imaginar y lo que podía construir se sentía personal.

Eso fue hace unos 14 meses.

La semana pasada, apliqué cinco efectos shader de hover diferentes — wobble, wave, aberración cromática, distorsión y un RGB split — a una página de galería completa y lancé todo en menos de 45 minutos. ¿Un solo efecto desde cero hasta vista previa funcional? Cuatro minutos.

La diferencia no fue que finalmente dominé GLSL. Todavía no puedo escribir un shader de desplazamiento desde cero sin abrir documentación. La diferencia es que construí un skill de Claude Code que lo hace por mí — y más importante aún, lo hace correctamente, con limpieza apropiada, manejo de viewport y cobertura de casos límite del mundo real.

Esa brecha que acabo de crear — "¿cómo funciona eso exactamente?" — es lo que vamos a cerrar aquí. Pero primero, necesitas entender por qué el consejo de "simplemente aprende shaders como es debido" es el camino equivocado para la mayoría de los desarrolladores front-end.

Por Qué los Shaders Siguen Fuera de Alcance (Y Por Qué No Es Tu Culpa)

Esto es lo que pasa con los shaders en el desarrollo front-end: la brecha de conocimiento no es una curva de aprendizaje. Es un precipicio vertical.

¿Animación CSS? Aprendes haciendo — rompes cosas, arreglas cosas, lanzas cosas. ¿Grid y flex? Una tarde enfocada desbloquea la mayor parte de lo que necesitas. Incluso patrones complejos de JavaScript como debouncing, scroll virtual o gestión de estado compleja — puedes hacer que funcionen con paciencia y buena documentación.

Los shaders son diferentes de una manera que la mayoría de los tutoriales no admiten.

GLSL (OpenGL Shading Language) es un lenguaje similar a C que corre directamente en la GPU, procesando vértices y fragmentos en paralelo con casi cero tolerancia para la comprensión difusa de "suficientemente bueno" con la que puedes salir adelante en JavaScript. No puedes hacer console.log dentro de un shader. Depurar es adivinar visualmente — cambias una variable, reconstruyes, entrecierras los ojos ante el resultado, repites. Three.js añade una capa de abstracción que a veces hace que la integración de shaders sea más difícil de razonar, no más fácil.

El camino real de aprendizaje para escribir shaders personalizados de producción desde cero se ve algo así:

1. Entender álgebra lineal apropiadamente — matrices, productos punto, coordenadas homogéneas
2. Aprender cómo funciona el pipeline de renderizado de WebGL a nivel de GPU
3. Dominar la sintaxis de GLSL y las restricciones de los programas shader (sin bucles dinámicos, sin recursión, tipado estricto)
4. Entender el ShaderMaterial de Three.js y cómo los uniforms, attributes y varyings fluyen a través de él
5. Descifrar la normalización de coordenadas del ratón, las matemáticas del espacio de viewport y la gestión del uniform de tiempo
6. Depurar resultados cambiando una variable a la vez hasta que algo se parezca más a lo que querías

Eso no es un fin de semana. Son meses de estudio enfocado si empiezas desde cero. Y esto es lo que la mayoría de los tutoriales no dicen directamente: la mayor parte de ese conocimiento no se transfiere limpiamente al resto de tu trabajo. Es especialización profunda — valiosa si estás construyendo una agencia creativa o haciendo arte generativo a tiempo completo. Para todos los demás que trabajan a lo largo de un full stack, lanzando producto y gestionando relaciones con clientes, el retorno de esa inversión de tiempo es genuinamente cuestionable.

El verdadero dolor no es que los shaders sean difíciles. Es que los shaders son difíciles en relación con la frecuencia con la que los necesitas.

Pero — y esta es la parte que importa — se ven increíbles. Un efecto de aberración cromática bien ejecutado en hover sobre una galería puede ser la diferencia entre un sitio que se siente como un producto premium y uno que se siente como una plantilla. El delta visual es masivo. La complejidad de implementación también es masiva.

¿Y si pudieras obtener el delta visual sin la complejidad?

Qué Es Realmente un Skill de Claude Code

Antes de entrar en la implementación del shader, necesito explicar qué significa un "skill" en Claude Code en la práctica — porque no es lo que la mayoría de la gente imagina cuando escucha "generación de código con IA".

Cuando los desarrolladores imaginan IA escribiendo código, se imaginan un chatbot generando algo que copias y pegas en tu proyecto y luego pasas una hora adaptando manualmente. Ese modelo funciona para boilerplate. Falla para tareas complejas y conscientes del contexto como la integración de shaders, donde la salida correcta depende en gran medida de cómo está estructurado tu proyecto.

Un skill de Claude Code es diferente. Piensa en él como un conjunto de instrucciones versionado y reutilizable que:

• Tiene contexto persistente — sabe qué estructuras de proyecto espera, qué opciones están disponibles y cómo han fallado generaciones anteriores
• Lee tu código primero — antes de escribir una sola línea, un skill bien construido escanea tu proyecto para entender qué existe, qué patrones se usan y qué necesita cambiar
• Aplica cambios quirúrgicamente — modifica solo lo que necesita modificarse, integrándose con tus patrones existentes en lugar de sobrescribirlos
• Acepta parámetros configurables — tipo de shader, intensidad, estilo de animación se pasan como opciones estructuradas en lugar de descripciones en prosa

El skill de shader que construí — llamémoslo apply-shader-hover — funciona exactamente así. Cuando se invoca en un proyecto:

• Escanea el archivo HTML que especifico para encontrar elementos de imagen dentro de contenedores tipo galería
• Identifica si el proyecto usa JavaScript vanilla, un bundler como Vite, o un framework
• Genera la configuración apropiada de Three.js (inicialización del canvas, WebGL renderer, scene, camera)
• Escribe el código fuente GLSL específico del shader para el efecto seleccionado
• Inyecta listeners de eventos del ratón con normalización correcta de coordenadas
• Añade un ResizeObserver para mantener las dimensiones del canvas correctamente
• Conecta todo con un patrón de inicialización que no produce fugas de memoria

Ese último punto importa más de lo que parece. El código WebGL generado por IA frecuentemente falla en liberar correctamente los recursos del renderer, eliminar listeners de eventos o manejar el desmontaje de componentes. Mi skill ha aprendido estos modos de fallo a partir de pruebas iterativas en el mundo real y los aborda explícitamente.

Pero las opciones de shader en sí son donde las cosas se ponen interesantes. Esto es lo que realmente distingue a cada uno — no solo visualmente, sino a nivel de código.

Los Cuatro Efectos Shader: Qué Está Pasando Realmente Bajo el Capó

Distortion — La Deformación Fluida

El shader de distorsión deforma la geometría de la imagen alrededor de la posición del ratón, creando un efecto de burbuja que hace que la imagen se sienta como si se estuviera alejando de tu cursor.

El mecanismo central es una función de desplazamiento en el fragment shader que muestrea la textura en una coordenada UV ligeramente desplazada — el desplazamiento calculado basándose en la distancia desde la posición normalizada del ratón. A intensidad "media", el desplazamiento máximo es de alrededor de 0.08 unidades UV. A "fuerte", estamos hablando de 0.15+, lo cual empieza a leerse como casi líquido.

Uniforms clave que impulsan el efecto:

• u_mouse — posición normalizada del ratón 0.0–1.0 en espacio de pantalla
• u_time — tiempo transcurrido para animación suave de entrada/salida en hover
• u_intensity — multiplicador escalar al que mapea la opción del CLI (0.04 para sutil, 0.08 medio, 0.15 fuerte)

Este funciona de maravilla en galerías de tema oscuro con fotografía de alto contraste. En layouts más claros y corporativos, puede percibirse como excesivo — el parámetro de estilo de animación ayuda a afinarlo, pero el efecto subyacente tiene una personalidad fuerte.

Wave — La Ondulación Elegante

Wave es más sutil que distortion y funciona mejor donde quieres que el hover se sienta sofisticado en lugar de dramático. En lugar de deformarse alrededor del cursor, crea un patrón de ondulación que se irradia hacia afuera desde el punto de interacción.

El detalle de ingeniería interesante aquí es el parámetro de estilo de animación. "Snappy" usa una curva de decaimiento exponencial — el efecto alcanza intensidad total casi inmediatamente y retrocede rápidamente, como presionar cristal. "Languid" usa una curva más lenta con un ligero sobrepaso, así que la onda continúa justo más allá del evento de activación antes de asentarse, como agua. "Smooth" usa simple interpolación coseno entre estados.

Esto parece una minucia de implementación hasta que los ves uno al lado del otro. La variante snappy se siente digital y precisa. La variante languid se siente orgánica y física. Para un portfolio de fotografía, esa elección moldea toda la experiencia.

Chromatic Aberration — El Que Genera Reacciones

Este es consistentemente el efecto que detiene a la gente a mitad del scroll. La aberración cromática simula el desflecamiento de color de una lente que no enfoca todas las longitudes de onda en el mismo punto focal — una ligera separación de los canales rojo, verde y azul, especialmente hacia los bordes.

En el fragment shader, muestreas la textura tres veces:

• Canal rojo: texture2D(u_texture, uv + offset)
• Canal verde: texture2D(u_texture, uv) — sin desplazamiento, este es el ancla
• Canal azul: texture2D(u_texture, uv - offset)

La dirección del desplazamiento es dinámica — sigue el vector de movimiento del ratón, así que la aberración "arrastra" mientras te mueves por la imagen, lo cual se lee como un comportamiento de lente físicamente preciso.

A intensidad "fuerte" con animación "snappy" en una galería oscura con fotografía de alto contraste, este efecto es casi agresivo — en el buen sentido. Uno de mis clientes recibió una consulta no solicitada de un prospecto que mencionó específicamente "los efectos geniales de las imágenes" en su sitio. Eso vino de este shader. En un layout más claro y conservador, los mismos ajustes se percibirían como recargados. El juicio de diseño es tuyo. La implementación es del skill.

Wobble — El Que Vive en el Vertex Shader

Wobble es el más juguetón de los cuatro, y técnicamente el más distinto — opera en el vertex shader en lugar del fragment shader. En lugar de manipular cómo se colorean los píxeles, manipula la geometría en sí.

Una distorsión sinusoidal se propaga a través del plano de la imagen desde el punto de entrada del ratón y se amortigua en aproximadamente 0.8 segundos, creando una oscilación tipo gelatina. El resultado visual es como presionar sobre una imagen de goma estirada sobre un marco rígido. Genial para tarjetas de producto, imágenes de avatar, cualquier cosa donde quieras fisicalidad en una interfaz que de otra forma sería plana.

Este requiere la configuración más cuidadosa — si el canvas de Three.js no está configurado con el manejo correcto de pixelRatio, el wobble se ve dentado en pantallas retina. El skill lo tiene en cuenta explícitamente. Si estás adaptando el código de salida manualmente en lugar de usar el skill tal cual, este es el primer lugar donde verificar cuando el resultado se ve mal.

Construyendo el Skill: El Proceso Real, No la Versión de Demo

Quiero ser directo sobre algo: este skill no llegó completamente formado de una sola sesión de prompts. Tomó 8–10 rondas iterativas llegar al nivel de calidad donde lo desplegaría en un proyecto de cliente sin revisar cada línea.

La primera versión era vergonzosamente ingenua. Le pedí a Claude Code que "creara un skill que aplique efectos shader de hover con Three.js a imágenes de galería". Lo que volvió era código sintácticamente correcto que no ejecutaba — porque asumía que había un module bundler disponible cuando el proyecto objetivo real usaba JavaScript vanilla con etiquetas script.

La ronda 2 arregló la detección de entorno pero falló cuando los elementos de imagen estaban anidados dentro de estructuras complejas de envoltorios de galería en lugar de ser hijos directos.

La ronda 3 manejó el anidamiento pero pasó por alto imágenes implementadas como background-image de CSS en lugar de elementos <img> — que una porción significativa de implementaciones de galería usa por razones de control de relación de aspecto.

Cada fallo se convirtió en parte de la base de conocimiento del skill. Añadí ejemplos documentados de cada patrón: "aquí hay una galería que usa imágenes de fondo, aquí está lo que el skill debería hacer diferente". El skill acumuló conocimiento contextual de fallos del mundo real en lugar de suposiciones teóricas.

El punto de inflexión fue cuando empecé a añadir lo que llamo "documentación de modos de fallo" — no solo describiendo qué debería hacer el skill cuando todo funciona, sino documentando explícitamente qué debería hacer cuando las cosas salen mal. ¿Qué pasa si Three.js no está disponible en la página? ¿Qué pasa si el selector objetivo encuentra cero elementos? ¿Y si el navegador no soporta WebGL?

Un skill que maneja fallos con gracia es infinitamente más confiable en proyectos reales que uno que solo funciona en condiciones de demo limpias. Ese es un principio que vale la pena mantener mientras construyes los tuyos.

El Flujo de Trabajo Real: Desde la Invocación Hasta la Vista Previa

Así es exactamente como se ve el flujo de trabajo actual — la versión de producción, no una demo simplificada.

Paso 1: Invocar desde dentro del proyecto

Desde el directorio del proyecto en Claude Code:

/apply-shader-hover

El skill inmediatamente hace dos preguntas:

1. ¿Qué archivo contiene la galería? (Proporciono la ruta)
2. ¿Qué efecto shader? (distortion / wave / chromatic / wobble)

Paso 2: Configurar parámetros

Después de elegir el tipo de shader, el skill presenta las opciones relevantes. Para aberración cromática:

Intensity: subtle | medium | strong
Animation style: smooth | snappy | languid
Apply to: all gallery images | specific selector

Selecciono "strong" + "snappy" + "all gallery images". Toda la interacción — incluyendo mi escritura — toma unos 20 segundos.

Paso 3: Lectura de contexto del código

Antes de generar cualquier código, el skill lee:

• El archivo HTML objetivo (estructura de imágenes, includes de JavaScript existentes)
• El CSS del proyecto (contexto de tamaño y posicionamiento de elementos)
• Cualquier uso existente de Three.js (para evitar inicialización duplicada del renderer)

Este pase de contexto es lo que hace que la salida se integre en lugar de simplemente coexistir con el proyecto.

Paso 4: Generación e inyección

El skill genera:

• Inicialización de Three.js (renderer, scene, camera, elemento canvas con pixelRatio correcto)
• Strings de código fuente GLSL del shader tanto para vertex como para fragment shaders
• Gestión de uniforms y bucle de actualización
• Listeners de eventos del ratón con normalización de coordenadas en espacio de viewport
• Integración de ResizeObserver
• Limpieza/liberación al descargar la página

La salida aterriza en un nuevo archivo shader-hover.js (o equivalente), con una sola etiqueta script añadida al HTML. No dispersa entre archivos existentes.

Paso 5: Revisión

La generación en sí toma 2–3 minutos. La revisión y cualquier ajuste toman otros 5–10. Busco: selección correcta de selectores, z-index y posicionamiento del canvas, cualquier caso límite específico del proyecto que el skill haya pasado por alto. Las correcciones en esta etapa son casi siempre menores.

Ese es el flujo de trabajo. El código debajo es genuinamente complejo. La capa de interacción no lo es. Y esa asimetría — interfaz simple sobre implementación compleja — es exactamente lo que un skill bien construido debería proporcionar.

La Opinión Honesta: Qué Cambia Esto Realmente (Y Qué No)

La mayoría del contenido sobre herramientas de IA que he visto omite los casos de fallo y muestra demos que funcionan perfectamente una vez, en condiciones ideales, y luego declara que el futuro ha llegado. Ese enfoque es inútil.

Esto es lo que realmente cambió en mi trabajo.

Lo que genuinamente mejoró:

El mayor cambio no es el ahorro de tiempo — es el acceso. ¿El efecto de aberración cromática que describí? Nunca se lo habría ofrecido a un cliente antes de que existiera este skill. El costo de implementación lo hacía impráctico para la mayoría de los proyectos. Ahora puedo proponerlo como diferenciador porque el costo de implementación es esencialmente cero. El rango de lo que puedo ofrecer se expandió sin una demanda correspondiente sobre mi experiencia técnica.

Concretamente: una implementación de shader que me habría tomado 6+ horas (si la intentaba en absoluto) ahora toma menos de 45 minutos incluyendo revisión. Los 4 minutos de generación y 10–15 minutos de revisión dejan 25–30 minutos para cosas que solo yo puedo hacer — decidir si el efecto pertenece a este contexto, probar en tamaños de dispositivos reales, asegurarme de que sirve a la experiencia general.

Lo que todavía requiere juicio real:

El skill sabe cómo aplicar un shader de aberración cromática fuerte a cada imagen en una galería. No sabe si un shader de aberración cromática fuerte debería estar en esa galería — si encaja con la marca, si sirve a la audiencia, si el estilo fotográfico lo soporta.

Esa decisión sigue siendo tuya. La IA maneja la complejidad mecánica. Las decisiones de diseño siguen siendo humanas.

Donde todavía falla:

Estructuras HTML no estándar — proyectos que mezclan JavaScript vanilla con patrones de módulos, o configuraciones inusuales de carga de assets — a veces confunden la fase de lectura de contexto. Estos casos se han vuelto más raros a través de la iteración pero no han desaparecido.

También hay una clase de errores que vienen de configuraciones de proyecto ambiguas: un proyecto que parece usar un bundler pero en realidad no lo hace, o uno donde Three.js se carga condicionalmente. El skill maneja estos mejor que antes, pero un pase de revisión rápido antes de desplegar en un proyecto de cliente todavía vale la pena.

La predicción a la que me comprometo:

Los casos de fallo se reducirán significativamente en los próximos 12–18 meses a medida que los skills mejoren en leer contextos de proyectos complejos. Ahora mismo el skill funciona de manera confiable en aproximadamente el 80–85% de las estructuras de proyecto estándar sin corrección manual. Ese número se dirige hacia el 95%+.

La opinión impopular:

Algunos desarrolladores escuchan este tipo de flujo de trabajo y piensan que representa una pérdida de oficio — reemplazar habilidad real con dependencia de IA. He escuchado este argumento aplicado a cada abstracción en la historia del desarrollo web. jQuery abstrayendo el DOM. Webpack abstrayendo el bundling de módulos. TypeScript abstrayendo la seguridad de tipos de JavaScript.

Los desarrolladores que construyeron experiencia encima de esas abstracciones son los que avanzaron. Saber cuándo un efecto de aberración cromática pertenece a un diseño, cómo configurarlo para máximo efecto, cómo adaptarlo para diferentes contextos — esa es experiencia real que vale la pena desarrollar. El hecho de que no tengas que escribir el GLSL desde cero no hace esas decisiones menos valiosas. Las hace más accesibles para las personas que las tienen.

Construye Tu Propia Versión: El Enfoque Que Recomendaría

Si quieres una versión de este skill en tu propia configuración de Claude Code, este es el enfoque que tomaría ahora — no el enfoque que realmente tomé, que desperdició tiempo.

No empieces prompting desde cero. Encuentra la mejor implementación existente de efecto shader con Three.js que puedas — algo que realmente funcione en producción, maneje casos límite correctamente y haya sido probado en dispositivos reales. Usa eso como el ejemplo base en la base de conocimiento de tu skill.

Un skill es tan bueno como sus ejemplos. Una implementación de shader excelente y probada en producción le enseña al skill más que cinco snippets de tutorial que cortan camino.

Construye incrementalmente:

• Empieza con un tipo de shader aplicado a una estructura de proyecto
• Pruébalo en 3–4 proyectos reales (no demos con HTML limpio)
• Documenta cada caso donde la salida necesita corrección manual — esos se convierten en tus ejemplos de mejora
• Añade el siguiente tipo de shader
• Repite

Añade manejo de modos de fallo temprano. Dile al skill explícitamente qué hacer cuando Three.js no está disponible, cuando el selector no encuentra nada, cuando WebGL no está soportado, cuando el elemento objetivo está dentro de un contenedor con scroll. Los skills que degradan con gracia son los que realmente inspiran confianza.

Si logras que un tipo de shader se genere correctamente y maneje fallos en tres estructuras de proyecto diferentes, ya has construido algo más prácticamente útil que la mayoría de los ejemplos en este espacio. Todo después de eso es iteración.

La página de galería que lancé la semana pasada — aberración cromática corriendo en hover, canales RGB separándose y volviendo a su lugar mientras el ratón cruza cada imagen — se veía como el tipo de trabajo que solía descartar como "para que alguien más lo construya".

La brecha entre lo que puedes imaginar y lo que puedes construir se cierra cuando las herramientas cambian. No porque tus límites técnicos desaparezcan. Porque la complejidad mecánica que solía sentarse entre la idea y el resultado es manejada por algo que es realmente bueno en complejidad mecánica.

Tu desafío para las próximas 48 horas: identifica un efecto visual que hayas admirado en otros sitios y siempre hayas descartado como demasiado complejo de implementar. Construye una primera versión de un skill alrededor de él. Aunque sea una versión tosca. Pruébalo en un proyecto real y documenta dónde falla.

El efecto que pensabas que requería seis horas y experiencia especializada podría estar a cuatro minutos de distancia.

Let's Work Together

Looking to build AI systems, automate workflows, or scale your tech infrastructure? I'd love to help.

• Fiverr (custom builds & integrations): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (enterprise solutions): ramlit.com
• ColorPark (design & branding): colorpark.io
• xCyberSecurity (security services): xcybersecurity.io