DEV Community: Raúl González (rafex)

Claude Code Leak: cuando el hype supera a la ingeniería

Raúl González (rafex) — Wed, 01 Apr 2026 18:55:54 +0000

El día de ayer circularon titulares alarmantes:

“Se filtraron más de 500 000 líneas del código de Claude Code”.

Sin embargo, al analizar el incidente con calma, la realidad es mucho menos dramática.
Lo que realmente se publicó por error fue un source map.

Y el código funcional ya estaba disponible en el paquete npm del proyecto.

1️⃣ El punto de partida: el bundle JS ya estaba público

Si el paquete npm ya incluía el bundle JS, entonces:

La lógica del programa ya estaba disponible.
Cualquiera podía analizarlo con:
- deobfuscadores
- herramientas AST
- agentes LLM
- ingeniería inversa clásica.

En otras palabras:

El bundle JS ya contiene la lógica ejecutable del programa.

El .map no agrega lógica nueva.

Solo agrega:

nombres originales
estructura de archivos
comentarios
metadata de compilación.

Por lo tanto no revela funcionalidad que no estuviera ya ahí.

🧪 Ejemplo simple: cómo funciona un source map

Para entender por qué el .map no contiene lógica nueva, veamos un ejemplo mínimo.

Código original (TypeScript)

export function sum(a: number, b: number): number {
  return a + b;
}

Código compilado/minificado (JavaScript distribuido)

function a(b,c){return b+c}

Este es el código que normalmente termina dentro del bundle publicado en npm.

Archivo source map (simplificado)

Un .map contiene información que permite relacionar el bundle con el código original:

{
  "version": 3,
  "sources": ["src/math.ts"],
  "names": ["sum","a","b"],
  "mappings": "AAAA,SAASA,IAAIC,EAAGC..."
}

Ese archivo indica cosas como:

qué archivo original generó ese código
cómo se llamaban realmente las funciones
qué variables corresponden a qué posiciones en el bundle

Con esa información una herramienta puede hacer esto:

bundle.js + bundle.js.map
        ↓
reconstruir
        ↓
src/math.ts

Pero observa algo importante:

La lógica (return a + b) ya estaba en el bundle.

El source map solo permite reconstruir:

nombres originales
estructura de archivos
posiciones de código

No añade comportamiento nuevo al programa.

2️⃣ Lo que realmente aporta el .map: información para humanos

Esto es clave:

los nombres y comentarios son para humanos

Un agente puede inferir cosas como:

function a(b,c){...}

→ inferir que probablemente es:

executeAgentTask(task, context)

Hoy con análisis semántico eso es trivial.

Por eso muchos proyectos open-source publican directamente el JS compilado sin preocuparse demasiado.

3️⃣ El bundle no “oculta” arquitectura

El bundle no elimina la arquitectura del programa; simplemente reduce su legibilidad.

Aunque esté minificado, aún puedes ver:

imports
llamadas a APIs
flujo del programa
dependencias
estructura de módulos

Ejemplo:

require("./agentLoop")
require("./tools/fileTool")

Eso ya te revela cómo funciona el runtime.

4️⃣ Lo que sí cambia el .map (pero no dramáticamente)

El .map reduce el trabajo humano.

Caso	Esfuerzo
bundle minificado	medio
bundle + LLM	bajo
bundle + map	inmediato

Pero no cambia la información disponible, solo la fricción para analizarla.

Bundle publicado en npm
        ↓
Código JavaScript ejecutable
        ↓
Puede analizarse con
- herramientas AST
- ingeniería inversa
- agentes LLM

Source map
        ↓
solo añade
- nombres originales
- estructura de archivos
- comentarios

5️⃣ El verdadero motivo del ruido mediático

Las noticias exageran por tres razones:

~~“512 000 líneas filtradas”~~ suena dramático

Pero esas líneas ya estaban en el bundle.

~~“código interno de Anthropic”~~

Pero Claude Code no es el modelo ni la infraestructura.

narrativa de ~~“AI company leak”~~

Eso genera clics.

6️⃣ Qué sí sería un leak serio

Algo realmente grave sería filtrar:

pesos del modelo
prompts internos del sistema
pipelines de entrenamiento
datasets
infra de serving
estrategias de RLHF

Eso no ocurrió.

7️⃣ En resumen

El “leak” de Claude Code no es un leak real, sino un source map.
El bundle JS ya estaba público, por lo que la lógica del programa ya era accesible.
El .map solo facilita la lectura humana, pero no revela funcionalidad nueva.
El impacto técnico real es limitado, aunque el hype mediático ha sido grande.

map file ≠ código nuevo
map file = metadata para humanos

El código funcional ya estaba público en npm.

Por eso varios desarrolladores también han comentado que la noticia es más hype que incidente de seguridad real.

Este episodio deja una lección simple:

Si publicas JavaScript en npm, tu lógica ya es pública.

Los source maps solo hacen que el código sea más fácil de leer para humanos.

La verdadera propiedad intelectual de las empresas de IA no está en el CLI que distribuyen,
sino en:

los modelos
los datos
la infraestructura
los sistemas de entrenamiento

Nada de eso fue filtrado en este caso.
Lo único que ocurrió fue que un archivo de depuración llegó a producción.

Este caso también sirve como recordatorio para leer con espíritu crítico las noticias sobre “filtraciones” tecnológicas.
Muchas veces el impacto técnico real es muy diferente al que sugieren los titulares.

COBOL, IA y la democratización del conocimiento técnico

Raúl González (rafex) — Tue, 17 Mar 2026 08:01:22 +0000

Durante décadas, COBOL fue el corazón de muchos sistemas críticos del mundo: banca, seguros, aerolíneas y gobierno.

No porque fuera el único lenguaje capaz de resolver esos problemas, sino porque estaba profundamente integrado con el ecosistema de mainframes, donde gran parte del conocimiento técnico estaba concentrado en pocos lugares.

Aprender COBOL en serio significaba, muchas veces:

trabajar dentro de una gran organización,
acceder a entornos mainframe,
o aprender de consultores especializados.

El conocimiento estaba ahí, pero no era fácilmente accesible.

Durante muchos años, ese modelo funcionó. La tecnología y el conocimiento estaban controlados por un ecosistema relativamente cerrado.

Hoy el panorama es muy distinto. Con la aparición de herramientas abiertas, documentación pública y ahora inteligencia artificial, entender sistemas heredados o incluso escribir código COBOL ya no requiere acceso a un mainframe corporativo.

De hecho, hoy puedes programar COBOL desde tu laptop con Linux usando un compilador open source.

Y ahí aparece una ironía interesante de la historia tecnológica:

Muchos de los expertos que durante años formaron parte de un ecosistema donde el conocimiento era escaso y difícil de acceder, hoy participan activamente en difundir ese conocimiento en internet.

El resultado es algo positivo:

una democratización del conocimiento técnico.

Y para demostrarlo, hagamos algo simple. Programar COBOL en Linux.

Programando COBOL hoy en Linux

Existe un compilador open source llamado GnuCOBOL, disponible en la mayoría de distribuciones Linux.

Este compilador traduce código COBOL a C y luego usa el compilador de C del sistema para generar el ejecutable. Es decir:

COBOL funcionando sobre un stack completamente open source.

Instalar el compilador

En Debian o Ubuntu:

sudo apt update
sudo apt install gnucobol

Verificamos la instalación:

cobc -v

Nuestro primer programa COBOL

Creamos un archivo llamado:

hola.cob

Con el siguiente contenido:

IDENTIFICATION DIVISION.
PROGRAM-ID. HOLA.

PROCEDURE DIVISION.
DISPLAY "Hola mundo desde COBOL en Linux".
STOP RUN.

COBOL tiene una estructura muy clásica basada en divisiones:

IDENTIFICATION DIVISION → metadatos del programa
DATA DIVISION → definición de datos
PROCEDURE DIVISION → lógica del programa

En este ejemplo solo usamos la parte más simple.

Compilar el programa

Usamos el compilador:

cobc -x hola.cob

Esto generará un ejecutable llamado:

hola

Ahora lo ejecutamos:

./hola

Resultado:

Hola mundo desde COBOL en Linux

Lo interesante de todo esto

Hace algunas décadas, compilar COBOL implicaba tener acceso a:

un mainframe
licencias costosas
y conocimientos muy específicos del entorno

Hoy puedes hacerlo con:

Linux
software open source
y documentación pública

Esto refleja un cambio profundo en la industria tecnológica.

El verdadero cambio no es solo la modernización de sistemas COBOL con IA.

El cambio real es que el conocimiento que antes estaba concentrado ahora está disponible para cualquiera que quiera aprenderlo.

Y eso, probablemente, sea una de las transformaciones más importantes de nuestra industria.

Cómo la IA está ayudando a modernizar COBOL

Aquí es donde entra el fenómeno actual.

Durante muchos años, modernizar sistemas COBOL implicaba:

leer millones de líneas de código
entender dependencias
reescribir todo manualmente

Un proceso extremadamente caro y lento.

Hoy la IA está empezando a ayudar en tres áreas clave.

¿Por qué deberíamos decir bibliotecas y no librerías en software?

Raúl González (rafex) — Wed, 25 Feb 2026 19:03:57 +0000

Uno de los errores más comunes que cometemos al hablar de programación en español es referirnos a las software libraries como “librerías”. Aunque parezca una traducción directa e inocente, este término es, en realidad, un falso amigo. En este artículo te explico por qué deberíamos usar la palabra correcta: bibliotecas.

🧠 La trampa del falso amigo

En inglés, library hace referencia a una colección organizada de funciones, clases o recursos reutilizables. En español, la palabra más cercana por significado no es “librería” (que es una tienda de libros), sino biblioteca. Ambas palabras comparten raíz etimológica (liber en latín, biblion en griego), pero tomaron caminos distintos.

Así que cuando decimos ~~“librería de software”~~, estamos usando una palabra que en español significa otra cosa completamente diferente. Es como si tradujéramos actually como “actualmente” cuando realmente significa “en realidad”.

📌 ¿Y por qué importa?

Porque el lenguaje técnico también construye pensamiento. Usar correctamente “biblioteca” en lugar de “librería” no es solo una cuestión de purismo lingüístico: es una forma de comunicarnos con precisión y evitar malentendidos, especialmente cuando explicamos conceptos a personas que están aprendiendo.

Además, muchas traducciones oficiales y comunidades en español ya han adoptado este estándar. Por ejemplo:

En Python, hablamos de la biblioteca estándar.
En Java, usamos el término bibliotecas externas.

📚 Conceptos relacionados

Aquí tienes algunos términos útiles para entender mejor este fenómeno lingüístico:

Falso amigo (False friend)

Palabras que parecen similares en dos idiomas pero tienen significados diferentes. Por ejemplo: library → biblioteca, no librería.
Traducción literal (Literal translation)

Traducir palabra por palabra sin considerar el contexto real.
Calco lingüístico

Adoptar literal y directamente una expresión extranjera, aunque no sea natural en el idioma destino.
Anglicismo

Uso innecesario o incorrecto de una palabra en inglés cuando existe una opción correcta en español.
Malapropismo

Error en el uso de una palabra confundiéndola con otra de sonido similar.

🤔 ¿Y si ya todo el mundo dice “librería”?

Es verdad que el uso está bastante extendido. Pero eso no significa que sea correcto ni que no podamos mejorar nuestra precisión técnica. Muchos términos se han ido afinando con el tiempo, y este es uno que vale la pena corregir.

🇫🇷 Bonus: ¿y en francés?

Sí, es totalmente cierto: en francés, el término correcto para software library también es bibliothèque, no librairie.

Library (software) → bibliothèque logicielle
Librairie → tienda de libros

En la documentación oficial de Python en francés se habla de la “bibliothèque standard de Python”.

The World of Rafex's

¿Te gustó este artículo? ¡Comparte y ayúdame a promover un uso más preciso del lenguaje técnico! 💬