Fallow: el ESLint para los problemas del código generado por IA

Fallow: El ESLint para los problemas del código generado por IA

El mes pasado lancé una funcionalidad que Claude Code escribió casi por completo. Funcionaba. Las pruebas pasaron. El PR se fusionó. Me sentí genial durante aproximadamente una semana.

Luego volví para hacer un pequeño cambio y encontré tres copias de exactamente la misma lógica de extracción de audio viviendo en el mismo archivo. Diferentes nombres de variables, comportamiento idéntico. Una función exportada llamada extractAllAudio que nada en el código base importaba. Una dependencia de dev instalada en las dependencies de producción. Nada de esto rompía nada. Todo era deterioro, acumulándose silenciosamente.

Ese es el secreto sucio de la codificación rápida con IA: el código funciona, así que dejas de mirar. Y la herramienta a la que normalmente recurrirías — ESLint — no detecta nada de esto. ESLint te dice que falta un punto y coma. No dice nada sobre el bloque de 100 líneas que has copiado y pegado en cuatro rutas.

Así que cuando encontré fallow, una herramienta gratuita de calidad de código generado por IA en línea de comandos, construida específicamente para los fallos de mantenibilidad que introducen las herramientas de codificación con IA, despejé una tarde y la apunté a mi repositorio más desordenado. Lo que descubrió cambió la forma en que reviso la salida de los agentes. Déjame mostrarte exactamente lo que encontró — y dónde se ganó su lugar en mi flujo de trabajo frente a dónde no lo hizo.

Por qué el código generado por IA se deteriora de formas que ESLint nunca ve

La cuestión con un LLM escribiendo código es esta: no tiene memoria de lo que escribió cuatro archivos atrás. Optimiza para este prompt, ahora mismo, producir una salida funcional. La mantenibilidad en todo el código base simplemente no está en su función de pérdida.

Eso produce tres modos de fallo específicos, una y otra vez, tanto en proyectos codificados a mano como en proyectos vibecoded — aunque es mucho peor cuando un agente está escribiendo.

Duplicación. El modelo necesita la misma lógica en dos lugares, así que la escribe dos veces. Luego una tercera vez. No extrae un helper compartido porque extraer requiere mantener todo el código base en la memoria de trabajo, y no lo hace. He visto más de 100 líneas idénticas repetidas en un solo archivo. ESLint se encoge de hombros ante esto. El código es válido.

Inflado y complejidad. Pídele a un agente que "maneje todos los casos límite" y lo hará — apilando condicionales dentro de bucles dentro de condicionales hasta que una sola función tiene 1,500 líneas y nadie, ni humano ni máquina, puede mantenerla en la cabeza. Cada rama es correcta. El todo es un pantano.

Peso muerto. Archivos sin usar. Funciones exportadas que nada importa. Dependencias añadidas para un experimento y nunca eliminadas. Los agentes crean andamiaje constantemente y rara vez limpian después, porque la limpieza no era la tarea.

¿Y la cruel ironía? Las herramientas de IA son malas detectando su propio deterioro. Pregúntale a Claude o Cursor "¿hay duplicación en este archivo?" y obtendrás una respuesta segura, plausible y frecuentemente incorrecta. Es una suposición probabilística sobre su propia salida. Lo que realmente necesitas es algo determinístico — algo que analice el código en lugar de razonar sobre él.

Ese es el vacío que fallow llena. Y la forma en que lo llena es la parte interesante.

Qué es realmente fallow (y por qué Rust importa aquí)

Fallow es inteligencia de código base para TypeScript y JavaScript, construida enteramente en Rust. El equipo detrás — la organización fallow-rs en GitHub — lo describe como la consolidación de todo un conjunto de herramientas de análisis estático en un solo binario que se ejecuta en menos de un segundo. A principios de junio de 2026 está en la línea de versiones 2.8x, lanzando actualizaciones casi a diario.

El modelo se divide limpiamente en dos:

• Inteligencia estática — completamente gratuita y de código abierto. Analiza la estructura de tu código: dead code, duplicación, dependencias circulares, complejidad, límites de arquitectura. Esta es la parte que uso y de la que trata todo este artículo.
• Inteligencia en tiempo de ejecución — una capa paga opcional que añade revisión de rutas calientes y evidencia de eliminación de rutas frías basada en tráfico real de producción. Te dice qué código "muerto" está realmente muerto según lo que se ejecuta en producción. Útil para equipos grandes que toman decisiones de eliminación. No he pagado por ella, y quiero ser honesto: estoy evaluando la capa estática gratuita, que es donde vive el valor cotidiano.

No necesitas instalar nada para probarlo. Un solo comando:

# Ejecuta un análisis completo en el repo actual, sin instalar nada
npx fallow

En la primera ejecución, fallow auto-detecta tu stack. En mi proyecto con Vite + TanStack Query cargó los plugins para Vite, TanStack Query y Tailwind CSS sin que yo configurara nada — viene con alrededor de 95 plugins de framework y conecta los correctos basándose en tu package.json. También crea un directorio .fallow de caché para que las ejecuciones posteriores sean rápidas.

¿Por qué importa Rust? Porque la velocidad cambia el comportamiento. Un linter que tarda 40 segundos se ejecuta una vez por semana. Un linter que termina antes de que muevas la mano del teclado se ejecuta en cada guardado, en cada PR, por cada agente en un bucle. El análisis en menos de un segundo es lo que hace viable a fallow dentro de un flujo de trabajo agéntico, lo cual — argumentaré más adelante — es donde se vuelve genuinamente poderoso.

Pero primero, el informe. Porque la primera vez que lees un informe de fallow sobre código escrito por IA, es un poco humillante.

Leyendo un informe de fallow: las cuatro secciones que importan

Cuando lo ejecuté, la salida se dividió en categorías claras. Recorreré cada una de la forma en que las leí, empezando por el peor infractor.

Dead code: lo que olvidaste que escribiste

Esta sección encuentra tres cosas, y los flujos de trabajo con IA generan las tres en volumen:

• Archivos sin usar — módulos que nada importa. Andamiaje de agentes que nunca se conectó.
• Exportaciones sin usar — ese extractAllAudio que mencioné. Exportado, con apariencia pública, importado por nada. Fallow lo marca con la ubicación exacta.
• Dependencias sin usar — y esta es sigilosa. Detectó una librería de testing instalada en las dependencies de producción que debería haber estado en devDependencies. Eso no es solo desorden; son bytes enviados a los usuarios sin razón.

El dead code es la victoria fácil. También es la categoría donde la auto-corrección de fallow brilla, lo cual abordaré más adelante.

Duplicación: la sección más importante, sin discusión

Esta es la que más me importa, y es donde el código de IA está en su peor momento. Fallow reporta la duplicación con rangos de líneas específicos — no "hay algo de duplicación en algún lugar" sino "las líneas 412-518 aquí coinciden con las líneas 1,090-1,196 allá." Concreto. Accionable.

La funcionalidad que me hizo prestar atención fueron las clone families: en lugar de arrojar 40 advertencias de duplicados por pares, agrupa los patrones recurrentes en familias. Así, una pieza de lógica que el agente pegó en cinco controladores de ruta aparece como una familia con cinco miembros, no diez pares ruidosos. Esa agrupación es la diferencia entre un informe sobre el que actúas y un informe que cierras.

La duplicación funciona en dos modos, y la diferencia importa:

• Modo mild (el predeterminado) detecta duplicados donde los nombres de variables son idénticos. Conservador, pocos falsos positivos.
• Modo semántico detecta duplicados donde la lógica es la misma pero los nombres de variables difieren — exactamente el tipo de cosa que un LLM produce cuando reescribe la misma función con nombres ligeramente diferentes cada vez. Más estricto, más exhaustivo, más ruido.

Para un código base con mucha IA, el modo semántico es el que quieres, porque el cambio de nombres de variables es la firma del LLM. Más sobre cómo cambiar de modo más adelante.

Complejidad: la revisión de salud que nadie ejecuta

Esta sección es un chequeo para funciones que han crecido fuera de control. Cuatro números hacen el trabajo:

• Tamaño de función — marca los monstruos. Tenía una acercándose a las 1,500 líneas.
• Complejidad ciclomática — el número de ramas independientes a través de una función. Una lectura de 115 ramas significa 115 caminos distintos. Imposible de testear en la práctica.
• Carga cognitiva — qué tan difícil es para un humano seguir el código, dando peso extra a los bucles y condicionales anidados. Un desorden anidado puede puntuar 133 incluso si la complejidad ciclomática se ve meramente mala.
• Puntuación CRAP — Change Risk Anti-Patterns (Patrones Anti-Riesgo de Cambio). Esta es la inteligente. Combina la complejidad con la cobertura de pruebas. Una función compleja que está bien testeada puntúa bajo — puedes cambiarla de forma segura. Una función compleja sin pruebas puntúa brutalmente alto, porque cambiarla es un volado. CRAP es el número que te dice dónde está el peligro real.

Esa última métrica reformuló cómo pienso sobre la deuda. No es "esta función es compleja." Es "esta función es compleja y nada me va a atrapar cuando la rompa." Esos son niveles de urgencia completamente diferentes.

Las puntuaciones: salud, riesgo y la que clasifica tu trabajo por ti

Fallow resume todo en unos pocos números compuestos:

• Puntuación de salud del archivo — un compuesto de 0-100 de dead code, conectividad de import/export, complejidad y CRAP. Más alto es más mantenible. Puedes obtener la versión a nivel de proyecto con fallow health --score y obtener una calificación con letra junto a ella.
• Puntuación de riesgo — impulsada fuertemente por CRAP. Este es tu indicador de "qué es más probable que explote".
• Puntuación general del resumen — un número para toda la ejecución, para que puedas comparar proyectos entre sí o rastrear el mismo repositorio a lo largo del tiempo.

Una puntuación por sí sola es solo una métrica de vanidad. La sección que realmente te dice qué hacer es la siguiente — y es lo más inteligente de la herramienta.

La sección de hotspots: donde fallow deja de ser un linter

La mayoría de las herramientas de calidad te dan una lista plana de problemas ordenados por severidad. Fallow hace algo que no he visto hecho de forma tan limpia: correlaciona la complejidad con tu historial de commits de git.

Piensa en lo que eso significa. Una función puede ser horriblemente compleja pero si nadie la ha tocado en dos años, está congelada — arriesgado cambiarla, pero no la estás cambiando, así que déjala en paz. El archivo peligroso es el que es tanto complejo como modificado constantemente. Cada commit en él es un lanzamiento de dados, y estás lanzando semanalmente.

Esa intersección — complejidad × frecuencia de cambios — es el hotspot. Lo ejecutas así:

# Archivos más riesgosos = frecuencia de cambios en git cruzada con complejidad
npx fallow health --hotspots

La lista de hotspots es tu cola de prioridad de refactorización, ordenada por dónde la limpieza da el mejor retorno de tu tiempo. Incluso puedes agregar señales de propiedad y drift (--hotspots --ownership) para ver el riesgo de bus factor — archivos que solo una persona entiende.

Esta es la sección que ahora reviso primero. No "qué está mal" sino "qué está mal y es costoso y se está modificando." Esa es una pregunta fundamentalmente mejor, y es la que convierte un informe en un plan.

Si prefieres que un equipo audite y refactorice un código base con mucha IA por ti en lugar de aprender las herramientas tú mismo, construir este tipo de pipeline de limpieza es exactamente el tipo de proyecto que acepto — pero honestamente, fallow hace que el camino de hacerlo uno mismo sea realista para la mayoría de los equipos ahora.

Integrando fallow en un flujo de trabajo real

Un informe que lees una vez y olvidas no vale nada. La razón por la que fallow se quedó para mí es que vive en cuatro lugares donde realmente trabajo. Esto se conecta directamente con el ciclo de vida de desarrollo agéntico sobre el que he escrito antes — las puertas de calidad tienen que moverse de "revisión humana ocasional" a "continua, automatizada, legible por máquinas" cuando los agentes están escribiendo la mayor parte del código.

1. La CLI, filtrada a una cosa a la vez

Un informe completo es abrumador en un repositorio legacy. Así que lo reduces. ¿Quieres solo dead code? ¿Solo salud y complejidad? Pasa un filtro de métrica y fallow te muestra esa porción y nada más:

npx fallow dead-code   # solo archivos, exportaciones y dependencias sin usar
npx fallow dupes       # solo duplicación
npx fallow health      # complejidad, puntuaciones, hotspots

Yo ataco una categoría por sesión. Elimino todo el dead code el lunes. Ataco las peores clone families el martes. Mantiene el trabajo sin sentirse infinito.

2. La extensión de VS Code: deterioro, subrayado

La extensión de fallow para VS Code ejecuta el análisis en vivo a través de un servidor de lenguaje. Obtienes una barra lateral con advertencias y errores agrupados por tipo, y — la parte que me gusta — indicadores en línea directamente en el editor. Los archivos sin usar y las exportaciones sin usar se marcan. Las líneas duplicadas obtienen subrayados ondulados, para que veas el copy-paste mientras pasas. Incluso muestra conteos de referencias vía CodeLens, para que sepas de un vistazo cuántas cosas realmente usan una exportación dada.

Ver la duplicación resaltada en el editor, mientras lees el código, impacta diferente que leerlo en un informe. Es la diferencia entre una nota del médico y un espejo.

3. La skill del agente de IA: código que se auto-revisa

Esta es la que genuinamente cambió mi modelo mental, y merece su propia sección. Salta hacia abajo — pero primero, la última pieza del flujo de trabajo.

4. CI/CD: la puerta de calidad antes del merge

Fallow incluye un flujo de trabajo pre-construido para GitHub Actions (y soporte para GitLab CI) que se ejecuta en cada push y PR. Publica un comentario en markdown directamente en el pull request resumiendo qué cambió, y puede imponer una puerta de calidad — fallar la build si la puntuación de salud cae por debajo de un umbral:

# Falla el PR si la salud del proyecto cae por debajo de 70
- run: npx fallow health --min-score 70

Tú eliges si los hallazgos son bloqueantes (inline, de corrección obligatoria) o informativos (un comentario que informa sin bloquear). Una advertencia de la documentación que vale la pena conocer: GitHub Actions hace checkout con fetch-depth: 1 por defecto, lo que rompe las líneas base basadas en historial de git. Configura fetch-depth: 0 si estás comparando contra una etiqueta base de larga duración. Perdí veinte minutos con eso antes de leer la letra pequeña, así que considera esto tu atajo.

La funcionalidad estrella de CI, sin embargo, es la comparación de ramas. En lugar de auditar todo tu repositorio en cada PR — lo que te inunda con problemas preexistentes que nadie va a arreglar hoy — fallow puede comparar tu rama de funcionalidad contra main y reportar solo los problemas nuevos o modificados que tu rama introdujo. Esa es la unidad de análisis correcta para un PR. No eres responsable de toda la historia del código base. Eres responsable de lo que tú (o tu agente) acaba de añadir. Incremental, justo, y mantiene la señal limpia.

La skill del agente: dejando que la IA califique su propia tarea — correctamente

Aquí es donde se pone realmente interesante, y donde fallow deja de ser "un linter mejorado" y se convierte en algo que creo que más stacks agénticos copiarán.

Hay un repositorio complementario, fallow-skills, que instala un módulo de skill para agentes vía npx. Le enseña a un agente de IA — Claude Code, Cursor, Codex, Gemini CLI, más de 30 de ellos — cómo invocar fallow por sí mismo y leer la salida JSON estructurada.

Quédate con lo que eso habilita. El agente que escribió el código descuidado ahora puede ejecutar una herramienta determinística que detecta el descuido, recibir hallazgos legibles por máquina, y corregir su propia salida antes de que llegue a ti. Cada problema en el JSON de fallow lleva un array actions con un flag auto_fixable — así el agente sabe no solo qué está mal sino si puede arreglarlo automáticamente.

Puedes pedírselo directamente. Literalmente he escrito en Claude Code: "Ejecuta fallow y dime cuáles cinco archivos debería refactorizar primero." Ejecuta el análisis de hotspots, analiza el JSON y regresa con una respuesta clasificada y razonada basada en datos reales analizados — no una suposición basada en vibraciones sobre su propio código. Esa distinción lo es todo. El agente ya no está razonando sobre su salida; la está midiendo.

Esto cierra el bucle que ha estado roto desde que la codificación con IA despegó. La cosa que produce el deterioro ahora tiene un instrumento determinístico para detectar y eliminar el deterioro, por sí misma, en la misma sesión. Si estás construyendo flujos de trabajo de agentes, las skills son el mecanismo que hace que este tipo de auto-corrección sea composable — fallow-skills es uno de los ejemplos del mundo real más limpios que he visto.

La salida JSON no es solo para agentes, tampoco. Cualquier script de CI puede analizarla y actuar sobre ella programáticamente. Estructurada, tipada, determinística — lo opuesto a pedirle a un LLM que revise un diff a ojo.

Configuración: eliminando falsos positivos antes de que eliminen tu confianza

Un analizador estático solo es útil si confías en él, y la confianza muere en el momento en que grita sobre cosas que hiciste a propósito. Fallow te da válvulas de escape reales. Inicializa una configuración en la raíz de tu proyecto:

npx fallow init

Eso genera un archivo de configuración que afinas con el tiempo. (Una nota honesta: la documentación referencia un par de formatos de configuración — JSON vía algo como .fallowrc.json y una opción TOML a través de fallow init --toml. El nombre exacto del archivo depende de tu versión, así que verifica lo que init realmente genera en tu setup en lugar de confiar en el nombre de archivo de cualquier blog post, incluyendo este.) Así es como yo lo configuro:

Ignora rutas generadas y de duplicación intencional. Tengo una carpeta /src/data/productinfo llena de definiciones de tarjetas generadas — cada entrada se ve duplicada porque están diseñadas para ser uniformes. Ignorar esa ruta cortó una gran cantidad de ruido. Lo mismo para las pruebas: un glob **/tests/**, porque los archivos de prueba duplican la configuración a propósito y eso está bien.

Elige tu modo de duplicación deliberadamente. Modo mild predeterminado para una línea base tranquila; cambia al modo semántico cuando específicamente quieras cazar los clones con variables renombradas que los LLMs adoran producir.

Usa overrides inline para las excepciones puntuales:

// fallow-ignore  -> desactiva fallow para todo este archivo
// fallow-ignore-next-line  -> salta solo la siguiente línea
export const publicApiShim = whatever // fallow-ignore-next-line

Ese último es perfecto para una exportación que sabes que no se usa internamente porque es una superficie de API pública. Lo reconoces, fallow deja de molestar y el informe sigue siendo confiable. Un informe en el que confías es un informe sobre el que realmente actuarás — ese es todo el juego.

La auto-corrección: 20 problemas eliminados en un comando

Leer problemas es una cosa. Arreglarlos a mano es la parte que todo el mundo se salta. El comando fix de fallow maneja lo mecánico automáticamente — eliminando exportaciones sin usar, limpiando dead code, actualizando el grafo de import/export para que nada quede colgando después de una eliminación.

Siempre haz un dry-run primero:

npx fallow fix --dry-run   # previsualiza cada cambio, no toca nada
npx fallow fix             # aplica las correcciones mecánicas y seguras

En una de mis ejecuciones resolvió 20 problemas en una sola pasada — principalmente exportaciones muertas e importaciones huérfanas, lo tedioso que nunca habría limpiado manualmente. No intenta auto-refactorizar una función de 1,500 líneas ni fusionar una clone family; eso requiere juicio humano sobre la abstracción correcta, y fallow hace bien en no adivinar. Arregla lo que es seguro y deja las decisiones arquitectónicas para ti. Esa contención es exactamente lo que quieres de un auto-corrector.

Dónde fallow se queda corto (la parte honesta)

No voy a pretender que esta herramienta es mágica, porque no lo es, y me atraparías de todas formas la primera vez que la ejecutaras.

Es solo TypeScript y JavaScript. Si tu stack es Python o Go, esta no es tu herramienta hoy.

La capa estática no sabe qué se ejecuta realmente. Un trozo de código "muerto" podría invocarse por reflexión, una importación dinámica o una ruta basada en strings que el parser no puede seguir. Para eso literalmente existe la capa paga de runtime — y es por eso que deberías revisar antes de eliminar, no confiar ciegamente en la lista de código sin usar.

El modo de duplicación semántica produce falsos positivos. Dos funciones genuinamente diferentes que comparten una forma serán marcadas. Pasarás tiempo triando y te apoyarás en esas reglas de ignore. Ese es el costo de detectar los clones sutiles — no hay almuerzo gratis.

Y no arreglará tu arquitectura. Te dice que una función es un hotspot de 1,500 líneas con 115 ramas. No te dirá la forma correcta de descomponerla. Ese juicio sigue siendo tuyo. Fallow apunta la linterna; tú todavía tienes que limpiar la habitación.

Nada de eso es un factor decisivo. Es la forma normal de una herramienta afilada: hace una categoría de cosas excepcionalmente y se mantiene fuera del trabajo que no puede hacer de forma segura. Prefiero eso a una herramienta que auto-refactoriza mi código con confianza en algo sutilmente roto.

Lo que cambió después de empezar a ejecutarlo

No te voy a citar un falso "redujo los bugs un 47%" porque no lo tengo y tampoco lo tiene nadie que te diga que sí. Lo que puedo decirte es lo que realmente cambió en mi forma de trabajar.

Dejé de confiar en "funciona" como definición de "está terminado." La salida del agente ahora recibe una pasada de fallow antes de que yo la lea, de la misma forma que ejecutaría las pruebas. La lista de hotspots se convirtió en mi backlog real de refactorización en lugar de una vaga sensación de culpa sobre "los archivos desordenados." Y en CI, la puerta de comparación de ramas significa que el PR vibecoded de un compañero no puede meter silenciosamente 200 líneas de lógica duplicada en el código base sin que aparezca un comentario en el PR — la conversación ocurre antes del merge, que es el único momento en que es barata.

El resultado realista que deberías esperar: no cero deuda, sino deuda visible, clasificada y decreciente. Conocerás tus cinco peores archivos por nombre. Detectarás el nuevo deterioro en el PR en lugar de descubrirlo tres sprints después. Para una herramienta estática gratuita que se instala con npx, ese es un retorno notable.

El cambio más grande es mental. Una vez que una IA está escribiendo la mayor parte de tu código, tu trabajo pasa de autor a editor y puerta de calidad. Fallow es una de las primeras herramientas construidas nativamente para ese trabajo — determinística, rápida y usable tanto por ti como por el propio agente.

Así que aquí está mi desafío para las próximas 24 horas: apunta npx fallow al repositorio con mucha IA del que estés más orgulloso. El que estás seguro de que está limpio. Lee la sección de duplicación primero. Apostaría a que encuentras al menos una clone family que no sabías que existía — y una vez que la veas, no podrás dejar de verla. Ese es exactamente el punto.

Preguntas Frecuentes

¿Es fallow gratuito?

Sí — toda la capa de inteligencia estática de fallow es gratuita y de código abierto, cubriendo dead code, duplicación, complejidad, hotspots y análisis de arquitectura. Hay una capa paga opcional de runtime que añade evidencia de tráfico de producción para la revisión de rutas calientes y la eliminación de rutas frías, pero la capa estática gratuita es donde vive el valor cotidiano. Ejecútalo con npx fallow, sin cuenta requerida.

¿En qué se diferencia fallow de ESLint?

Fallow se enfoca en fallos de mantenibilidad en todo tu código base — duplicación, dead code, complejidad y hotspots — mientras que ESLint se enfoca en reglas de estilo y corrección por archivo. ESLint no marcará 100 líneas que copiaste y pegaste en cuatro archivos; fallow las agrupa en una clone family con rangos de líneas exactos. Son complementarios, no competidores. Consulta las secciones de duplicación y hotspots arriba para ver lo que fallow detecta y los linters no.

¿Puede fallow auto-corregir problemas de código generado por IA?

El comando fix de fallow auto-resuelve problemas mecánicos y seguros — eliminando exportaciones sin usar, borrando dead code y actualizando el grafo de import/export — y una sola ejecución puede limpiar más de 20 problemas. Siempre previsualiza con npx fallow fix --dry-run primero. Deliberadamente no auto-refactoriza funciones gigantes ni fusiona duplicados, ya que esos necesitan juicio arquitectónico humano.

¿Funciona fallow con agentes de IA como Claude Code?

Sí — el módulo fallow-skills (instalado vía npx) les enseña a agentes como Claude Code, Cursor, Codex y Gemini CLI a invocar fallow y leer su salida JSON estructurada. Esto permite que un agente auto-revise y auto-corrija su propio código antes de abrir un PR. Puedes pedir cosas como "¿cuáles cinco archivos debería refactorizar primero?" y obtener una respuesta basada en datos. Consulta la sección de la skill del agente arriba para el flujo de trabajo completo.

¿Qué lenguajes soporta fallow?

Fallow analiza proyectos de TypeScript y JavaScript únicamente, con alrededor de 95 plugins de framework que auto-detectan stacks como Vite, Next.js, TanStack Query y Tailwind CSS. No hay soporte para Python o Go a partir de la línea de versiones 2.8x en junio de 2026. Si tu proyecto es JS/TS, se configura solo en la primera ejecución con cero preparación.

Trabajemos Juntos

¿Buscas construir sistemas de IA, automatizar flujos de trabajo o escalar tu infraestructura tecnológica? Me encantaría ayudar.

• Fiverr (desarrollos personalizados e integraciones): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (soluciones empresariales): ramlit.com
• ColorPark (diseño y marca): colorpark.io
• xCyberSecurity (servicios de seguridad): xcybersecurity.io