Plugin de ESLint para errores de código de IA

¿Y si tu compañero de código con IA estuviera saboteando tu app en secreto con bugs que solo asoman en producción?

Esa es la pesadilla detrás de la historia de eslint-plugin-llm-core. Imagínate: vas volando con tu LLM, soltando features sin parar. Pruebas verdes. Revisores contentos. ¡Bum! — llega el despliegue y todo es un desastre de promesas sin resolver y errores engullidos. Lo he visto. Joder, el creador también, tras radiografiar 500 metidas de pata de código generado por IA.

Y aquí el giro brutal: no se limitó a quejarse. Forjó eslint-plugin-llm-core, un plugin de ESLint hiperpreciso con 20 reglas clavadas en los puntos débiles de la IA. Nada de prácticas de manual de abuelita. Estas reglas cazan patrones exactos que los LLM la cagan siempre.

Mira.

Async/await hecho un lío dentro de callbacks de arrays. Catch vacíos devorando errores como si nada. Anidamientos profundos que gritan ‘infierno de callbacks versión 2.0’. Es como si la IA hubiera cogido las peores aristas de JavaScript y las malabarizara con los ojos vendados.

¿Por qué pasa? Los LLM arrasan con sintaxis y caminos felices — son máquinas de patrones en esteroides. ¿Casos extremos, consistencia o mugre del mundo real? Alucinan APIs, saltan nulls, inventan números mágicos. Los estudios lo confirman: 40% de bloques de código faltantes, 20% de lecturas erróneas, 15% ciegos a casos límite.

¿Por qué el código de IA explota en producción?

Piensa en los LLM como becarios ansiosos. Genios en tutoriales, perdidos en la fábrica.

Clavan las pruebas unitarias porque estas aíslan el caos. ¿Producción? Datos impredecibles: nulls, timeouts, fallos parciales. El código de IA se desmorona.

Clásico ejemplo:

const results = items.map(async (item) => { return await fetchItem(item); });

Parece bien, ¿no? Tu asistente de IA lo escribió. Pruebas OK. Revisión aprobada.

Llega producción, y results es un array de Promises — no los valores que esperabas.

La regla no-async-array-callbacks de eslint-plugin-llm-core lo pilla al vuelo: “57:27 error Evita pasar funciones async a métodos de array llm-core/no-async-array-callbacks. Este patrón devuelve un array de Promises, no los valores resueltos. Usa Promise.all() o un for…of en su lugar.”

¿Educativo, verdad? No solo “arregla”, explica para que hasta tu IA aprenda de cara a la próxima.

O los catch vacíos:

try { await processData(data); } catch (e) { // TODO: handle error }

“63:11 error Catch vacío que traga errores en silencio.” ¡Zas! Eliminado.

¿Y los anidamientos? La IA apila ifs como si estuviéramos en 1999. La regla prefer-early-return los aplana: sin datos, sal temprano. Limpio, legible, a prueba de balas.

No es humo. Viene extraído de carnicerías reales — estudios empíricos, 333 bugs, 558 snippets nefastos. Los puntos ciegos de la IA, codificados.

¿Convertirá eslint-plugin-llm-core a la IA en tu nuevo lead developer?

Respuesta corta: más cerca de lo que crees.

¿Recuerdas JSLint en los 2000? JavaScript era el salvaje oeste de quirks de navegadores y código vaquero. El linter de Crockford lo domó, allanando el camino al desarrollo web moderno. ¿eslint-plugin-llm-core? Eso es el JSLint de la era IA.

Mi apuesta audaz — y el insight que le falta al original: este plugin pasa la IA de ‘asistente’ a ‘copiloto de confianza sin supervisión’. Entrénalo con sus mensajes de error en prompts, y la calidad del output se dispara. Estamos hablando de diffs listos para producción desde el día uno. Adiós a hacer de niñera con Copilot o Claude.

Para los corporativos: sí, hay reglas de typescript-eslint. Pero son puras de TypeScript, obsesionadas con specs. Esto va afinado para la guerra de IA. Úsalos juntos — como mantequilla de maní y chocolate.

¿Inst