DEV Community: lu1tr0n

MOOP Map 2025: el dataset de 20 años que cambió a 70.000 personas

lu1tr0n — Thu, 07 May 2026 14:23:40 +0000

Cada agosto, 70.000 personas convergen en un lago seco del desierto de Nevada para levantar desde cero una ciudad temporal. Ocho días después, Black Rock City se desvanece. Pero queda algo: 150 voluntarios formados hombro con hombro recorriendo 1.540 hectáreas (3.800 acres) de polvo a paso humano, registrando cada tornillo, cada lentejuela, cada colilla. El resultado es uno de los proyectos de datos comunitarios más particulares del mundo: el Burning Man MOOP Map. La edición 2025 acaba de publicarse y, como cada año desde 2006, cuenta una historia poco común para una comunidad de 70.000 personas: cómo un dataset puede modificar el comportamiento colectivo sin policías, sin multas, sin algoritmos de moderación. Solo con un mapa público pintado de verde, amarillo y rojo.

Para los desarrolladores en LATAM acostumbrados a dashboards de observabilidad, mapas de cobertura de tests o métricas DORA, el MOOP Map es un caso de estudio inesperado: una infraestructura analógica de accountability comunitaria, sostenida durante dos décadas, con resultados medibles que mejoran año tras año. Vamos a revisar qué dicen los números de 2025, cómo llegamos hasta acá, y qué lecciones tiene este modelo para cualquier equipo que use datos para cambiar conductas.

El MOOP Map 2025 en cifras

El 2025 MOOP Map fue publicado por el equipo de Restauración Ambiental de Burning Man tras varias semanas de barrido forense de la playa. El método es brutalmente analógico: 150 personas alineadas a la distancia de un brazo cada una, caminando lentamente sobre 3.800 acres (15,4 km²) de lecho seco, recogiendo y catalogando todo objeto humano que encuentren. Cada hallazgo se geolocaliza y se incorpora al mapa, que se publica con un código de color por severidad: verde (limpio), amarillo (limpieza moderada que ralentiza al equipo) y rojo (zonas tan contaminadas que detienen el avance).

En palabras de Dominic "DA" Tinio, gerente de Restauración Ambiental de Burning Man, "en términos simples, mientras más MOOPier es un área, más trabajo y tiempo de campo toma limpiarla hasta que las cuadrillas dejan de encontrar restos". MOOP, por sus siglas en inglés, significa Matter Out of Place: cualquier objeto humano que no debería estar en el desierto.

Lo más llamativo del informe 2025 son los lag bolts —tirafondos largos que anclan tiendas, instalaciones y arte al suelo— que dominaron el ranking de basura encontrada. A diferencia de las colillas o los purpurinas, los lag bolts no responden a un comportamiento específico de un grupo; son fallas distribuidas: prácticamente todos los campos perdieron algunos. Para los lectores con background en ingeniería, suena familiar: un bug sistémico que aparece con baja frecuencia en muchos servicios distintos, no un problema concentrado en un módulo.

El balance general: Black Rock City 2025 pasó la inspección oficial sin sobresaltos. Pero la historia detrás de este "sin sobresaltos" es mucho más interesante.

Severidad de cleanup por zona: verde, amarillo y rojo. Cada color implica horas de trabajo distintas.

20 años haciendo Leave No Trace data-driven

El MOOP Map no nació por iniciativa estética: nació por necesidad legal. El terreno donde se realiza Burning Man pertenece al Bureau of Land Management (BLM), la agencia federal que administra tierras públicas en Estados Unidos. Para que el evento pueda regresar cada año, debe pasar una inspección post-evento estricta: no más de un pie cuadrado de basura por acre (0,23 m²/ha). El BLM mide en 120 puntos repartidos por el sitio, y como máximo 12 de esos puntos pueden superar el umbral. Si 13 o más fallan, Black Rock City no vuelve.

En la práctica, el evento aprueba con holgura casi todos los años. Pero "casi" deja espacio para sustos. En 2023, 11 de los 120 puntos del BLM se pasaron del límite —el resultado más cercano al fracaso en la historia reciente. Una unidad más por encima del umbral y la edición 2024 podría no haber sucedido. La comunidad lo asumió como un wake-up call: cuando un sistema que toleras como margen se aproxima a su techo, los costos de un fracaso son catastróficos. En lenguaje de SRE: estás quemando tu error budget más rápido de lo previsto y es hora de reevaluar todo el proceso.

El MOOP Map mismo lleva dos décadas en operación. Su origen fue la necesidad de demostrarle al BLM que la comunidad tomaba en serio la limpieza, pero rápidamente evolucionó en una herramienta interna: un feedback loop público que cada campamento, cada proyecto artístico y cada participante recibe sobre el impacto que dejó su huella. "Desde 2006, en el largo arco del MOOP Map, la tendencia más llamativa es que la comunidad ha mejorado consistentemente en Leave No Trace, incluso cuando Black Rock City ha crecido dramáticamente en tamaño, complejidad y población", afirma DA. La medición empezó como obligación regulatoria y se convirtió en cultura.

💭 Clave: Este es uno de los efectos más potentes de las métricas públicas en cualquier organización: empiezan como cumplimiento y terminan como identidad. Cuando los datos son visibles y atribuibles, dejan de ser una imposición externa y se convierten en parte de cómo la gente se ve a sí misma.

Los números que revelan una mejora sostenida

Los datos detrás del MOOP Map son los que vuelven al proyecto fascinante. Si normalizamos la basura por persona —MOOP per cápita— el pico histórico está en 2010. Desde entonces, pese a que la población anual del evento creció considerablemente, la cantidad de basura por persona ha tendido a bajar. La mejora absoluta es aún más impactante: con un evento más grande, más complejo, con instalaciones más ambiciosas y más arte, el residuo total se mantiene bajo el techo legal.

Los principales tipos de basura encontrados en 2025 son:

Lag bolts (tirafondos): el #1 absoluto, distribuido entre prácticamente todos los campamentos.
Madera y restos de construcción: residuos de carpintería estructural cortada en sitio.
Tela, cuerdas y elásticos: especialmente trozos pequeños cortados durante el desmontaje.
Plásticos pequeños: tapas, envoltorios, partes de utilería.
Lentejuelas y micro-purpurina: el horror eterno del MOOP, prácticamente imposible de recoger una vez disperso.

Los cigarrillos y colillas, que históricamente fueron un problema importante en festivales similares, hoy aparecen en cantidades pequeñas. La señal cultural funcionó.

Los datos también permiten al equipo de DA distinguir entre fallas sistémicas y fallas específicas. Si una zona tiene mucho MOOP concentrado, la responsabilidad cae sobre el campamento o instalación en ese lugar. Si la basura está distribuida (como los lag bolts en 2025), el problema es del proceso colectivo de desmontaje. Esa distinción es clave: permite atacar la causa raíz en lugar de solo culpar al actor visible.

Para entender cómo se traduciría esto a código, una verificación BLM mínima podría modelarse así:

moop_zones = [
    {"id": "7:30-A", "color": "green",  "items_found": 2,  "area_acres": 4.2},
    {"id": "7:30-B", "color": "yellow", "items_found": 18, "area_acres": 4.2},
    {"id": "7:30-C", "color": "red",    "items_found": 47, "area_acres": 4.2},
]

BLM_THRESHOLD_SQFT_PER_ACRE = 1
SQFT_PER_ITEM_AVG = 0.05  # estimacion gruesa

def passes_blm_inspection(zones, max_failures=12):
    failures = sum(
        1 for z in zones
        if (z["items_found"] * SQFT_PER_ITEM_AVG) / z["area_acres"]
        > BLM_THRESHOLD_SQFT_PER_ACRE
    )
    return failures  **💡 Tip:** Si tu equipo opera con SLOs, esta es la analogía exacta: cada zona del MOOP Map es un SLI individual, el umbral por acre es el SLO, y el límite de 12 fallas es el error budget. Burning Man lleva 20 años haciendo SRE sin llamarlo así.

## De métrica de cumplimiento a herramienta de cultura

Lo más interesante del MOOP Map no son los números: es lo que la gente hace con ellos. El reporte oficial detalla, campo por campo, qué se encontró en su footprint. Los grupos en zonas rojas reciben un breakdown de su contribución a la basura total, con la expectativa de que mejoren al año siguiente. Los infractores reincidentes son flagueados al equipo que asigna ubicaciones futuras —si dejaste basura, te toca peor lugar el año siguiente, o no te toca lugar.

Pero la fuerza más poderosa no es institucional. Es social. Cada año, al publicarse el mapa, el subreddit de Burning Man lanza el "MOOP Map shame thread", donde los participantes señalan públicamente a los campamentos que dejaron zonas rojas. Es un mecanismo informal, no orquestado por la organización, pero brutalmente efectivo: nadie quiere que su crew aparezca en el thread. La transparencia genera vergüenza, y la vergüenza disciplina.

Para cualquier equipo de software, esto es profundamente familiar:

- **Dashboards públicos de uptime** tipo status pages.
- **Mapas de cobertura de tests** visibles en cada PR.
- **Rankings de contribución open source** en GitHub.
- **Métricas DORA** visibles para toda la organización.
- **Heat maps de errores** en Datadog o Sentry, atribuibles por servicio y owner.

Todos operan bajo la misma lógica. Cuando el dato es público y atribuible, el comportamiento cambia. El MOOP Map demuestra que esto funciona incluso fuera del software, con una población de 70.000 personas, sin enforcement automatizado.

> **⚠️ Ojo:** Las métricas tienen un costo: gobernarlas mal puede generar gaming (la gente optimiza para el número, no para el resultado real). El MOOP Map evita esto porque la métrica está alineada al outcome real (limpieza física), no a un proxy. Cuando diseñes métricas para tu equipo, pregúntate primero: ¿qué pasa si alguien optimiza esto al máximo? ¿El resultado real mejora, o solo el número?

El barrido forense lo hacen 150 voluntarios alineados a la distancia de un brazo.

## Cómo funciona el ciclo MOOP de punta a punta

El proceso completo, desde el final del evento hasta la decisión del BLM, sigue una secuencia clara que vale la pena visualizar:

graph LR
A["Evento Burning Man 8 dias"] --> B["Desmontaje de campamentos"]
B --> C["Equipo MOOP entra al sitio"]
C --> D["Barrido forense semanas"]
D --> E["Geolocalizacion y catalogo"]
E --> F["Publicacion MOOP Map"]
F --> G["Inspeccion BLM 120 puntos"]
G --> H{"Pasa la prueba"}
H -->|Si| I["Black Rock City vuelve"]
H -->|No| J["Permiso en riesgo"]




Lo interesante de este pipeline es que el output con mayor impacto no es la decisión del BLM (que casi siempre es "sí"), sino la publicación del mapa. Es ahí donde se cierra el feedback loop con la comunidad y donde se genera la presión social que lleva a la mejora del año siguiente. El BLM es la condición de borde; el mapa público es la herramienta de cambio.

## Qué sigue para el MOOP Map

¿Para dónde va el MOOP Map? La metodología base —barrido humano más georreferenciación manual— probablemente se mantenga, porque la precisión de un humano caminando despacio en busca de objetos pequeños es difícil de superar con sensores. Pero hay espacio para innovación.

### Posibles innovaciones tecnológicas

- **Drones con cámaras de alta resolución**: para escaneo previo de zonas y priorización de cuadrillas.
- **Computer vision**: clasificación automática de tipos de basura en imágenes de drone.
- **Análisis predictivo**: identificar campamentos con riesgo alto antes del desmontaje, basándose en patrones históricos por ubicación, tamaño y tipo de instalación.
- **Datasets abiertos**: publicación estructurada de los hallazgos para análisis externo, con investigadores académicos ya interesados en el material.

Por ahora, el equipo de Restauración Ambiental se mantiene en el método clásico, pero con un dataset que ya cubre dos décadas, hay material rico para que investigadores externos lo estudien. La comunidad data science alrededor del MOOP Map empieza a tomar forma —no formal, pero existente.

La lección más importante para 2026 y más allá: la mejor manera de crear cultura de Leave No Trace no es predicarla. Es medirla y publicar la medición. Para los equipos en LATAM que están construyendo sistemas, productos o comunidades, ese principio es totalmente exportable.

📖 Resumen en Telegram: [Ver resumen](#)

## Preguntas frecuentes

### ¿Qué significa MOOP exactamente?

MOOP significa *Matter Out of Place*: cualquier objeto humano que no debería estar en el desierto de Black Rock. Va desde un tornillo perdido hasta un pedazo de plástico de medio milímetro. La única excepción son las pisadas humanas en el polvo, que son inevitables.

### ¿Quién hace el barrido y cuánto dura?

Aproximadamente 150 voluntarios y empleados del equipo de Restauración Ambiental hacen el sweep. El proceso dura varias semanas después del cierre oficial del evento, dependiendo del tamaño del año y de qué tan MOOPier esté el sitio. Caminan en líneas paralelas a un brazo de distancia entre sí.

### ¿Qué pasa si Burning Man no pasa la inspección del BLM?

Si más de 12 de los 120 puntos de muestreo del BLM superan el límite de un pie cuadrado de basura por acre, el evento podría perder el permiso para regresar. Hasta hoy nunca ha fallado, pero en 2023 estuvo a un solo punto de hacerlo.

### ¿Por qué los lag bolts son el problema dominante en 2025?

Los lag bolts son tirafondos largos que se usan para anclar tiendas, instalaciones de arte y estructuras al suelo. Al desmontar, es fácil que uno se afloje y desaparezca bajo el polvo. No hay un solo culpable: prácticamente todos los campamentos perdieron alguno. Es un patrón distribuido, no concentrado.

### ¿Cómo se castiga a un campamento que deja mucha basura?

Los reincidentes son flagueados al equipo que asigna ubicaciones futuras dentro de Black Rock City. Pueden recibir peor ubicación al año siguiente o, en casos graves, perder el derecho a tener un placement en el evento. Adicionalmente hay presión social informal en redes (el famoso "MOOP Map shame thread" en Reddit).

### ¿Hay datasets abiertos disponibles para análisis?

Burning Man publica el mapa con sus colores y estadísticas agregadas, pero no un dataset estructurado completo. Los datos crudos quedan internos al equipo de Restauración Ambiental. Hay interés creciente en abrir más datos para investigación académica.

## Referencias

- [Not-Ship: The map that keeps Burning Man honest](https://www.not-ship.com/burning-man-moop/) — análisis original con visualizaciones del MOOP Map 2025.
- [Burning Man Project](https://burningman.org/) — sitio oficial del evento, incluye documentación sobre Leave No Trace y proceso MOOP.
- [Wikipedia: Burning Man](https://en.wikipedia.org/wiki/Burning_Man) — historia del evento, contexto regulatorio y estadísticas de asistencia.
- [r/BurningMan](https://www.reddit.com/r/BurningMan/) — comunidad activa donde se publica anualmente el MOOP Map shame thread.

📱 **¿Te gusta este contenido?** Únete a nuestro canal de Telegram [@programacion](https://t.me/programacion) donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.

Permacomputing: 10 principios para una computación sostenible

lu1tr0n — Thu, 07 May 2026 08:20:10 +0000

El concepto de permacomputing empieza a salir de los círculos académicos y los foros de hackers para instalarse en debates serios sobre el futuro del software. La idea es simple en su enunciado y radical en sus consecuencias: aplicar las éticas de la permacultura —cuidar la tierra, cuidar las personas, redistribuir lo justo— al diseño, construcción y mantenimiento de sistemas computacionales. El sitio oficial permacomputing.net publica diez principios que guían esta práctica, y en 2026 el debate ha ganado relevancia frente al crecimiento explosivo del consumo energético de la inteligencia artificial y de los desechos electrónicos.

Para quien escribe código, configura infraestructura o decide qué dispositivo comprar, permacomputing no es una doctrina prescriptiva sino un marco para hacerse mejores preguntas. ¿Necesito desplegar este modelo en GPUs nuevas o un modelo más pequeño basta? ¿Tiene sentido reescribir esta app en Electron y triplicar el consumo de RAM? ¿Vale la pena renovar la flota de laptops cada tres años cuando la mayoría sigue funcionando? Las respuestas no están escritas, pero los principios ayudan a formularlas.

Qué es permacomputing

El término permacomputing fue acuñado en 2020 por el programador finlandés Ville-Matias "viznut" Heikkilä, conocido en la escena demoscene por sus experimentos con computación en condiciones extremas (programas que generan música compleja con apenas unas líneas de C). Su ensayo original proponía repensar la informática desde una perspectiva post-crecimiento, asumiendo que los recursos materiales para fabricar chips, baterías y data centers son finitos.

El movimiento se inspira directamente en la permacultura, una corriente de diseño agrícola y ecológico nacida en Australia en 1978 con los trabajos de Bill Mollison y David Holmgren. Permacultura no es solo agricultura orgánica: es un sistema de diseño que observa los ciclos naturales y crea soluciones de bajo consumo, alta resiliencia y mínima intervención. Permacomputing toma ese mismo espíritu y lo traduce al hardware, los sistemas operativos, los protocolos y las prácticas de desarrollo.

La comunidad —que mantiene un working group activo y publica documentación abierta— deja claro que permacomputing no es prescriptivo. No te dice qué lenguaje usar ni qué editor abrir. Lo que ofrece son lentes para mirar tu propia práctica y preguntarte si lo que estás construyendo aporta valor proporcional al costo socioambiental que implica.

Contexto: de la permacultura a los servidores solares

Antes de entrar en los principios conviene situar el movimiento dentro de una genealogía. Hay precedentes claros que prepararon el terreno:

Low-tech Magazine (Kris De Decker, 2007) — una revista digital que desde 2018 corre sobre un servidor alimentado por paneles solares. Cuando no hay sol, el sitio se cae. Esa "limitación" es el punto.- The Small Web y el 250kb Club — iniciativas que celebran sitios web livianos, sin trackers ni frameworks pesados.- 100R / Hundred Rabbits — el colectivo de Devine Lu Linvega y Rekka Bellum, que vive en un velero y desarrolla herramientas (Uxn, Orca, Left) optimizadas para correr con energía limitada.- Solarpunk — el movimiento estético-político que imagina futuros tecnológicos en armonía con la biósfera.

Permacomputing recoge ideas de todas estas tradiciones y las organiza alrededor de diez principios concretos. El sitio permacomputing.net documenta cada uno con ejemplos, lecturas adicionales y estrategias de aplicación tanto para personas técnicas como para usuarios casuales.
Servidores de bajo consumo: la práctica que inspira a permacomputing.

Los 10 principios, en español

A continuación una traducción comentada de los diez principios. La versión completa con todos los matices vive en permacomputing.net/principles:

1. Cuidar la vida

Toda decisión técnica debe ponderar su impacto sobre los seres vivos —humanos y no humanos— y sobre los ecosistemas. Es el principio raíz, equivalente al "Earth Care" de la permacultura.

2. Cuidar todo el hardware (especialmente los chips)

Los microchips son los componentes más caros de fabricar en términos energéticos y materiales: requieren litros de agua ultrapura, gases raros, energía intensiva y son prácticamente imposibles de reciclar. Maximizar la vida útil de cada dispositivo es un acto político.

3. Mantenerlo pequeño

El bloat es enemigo. Un binario más liviano no solo carga más rápido: cabe en hardware viejo, consume menos memoria, pesa menos en la red. Hay un linaje claro entre suckless, plan9 y este principio.

4. Esperar lo mejor, prepararse para lo peor

Diseñar sistemas resilientes a interrupciones, fallas de red, cortes de energía o colapso parcial. No por catastrofismo, sino porque la fragilidad ya es la realidad de millones de personas con conexiones inestables y hardware limitado.

5. Mantenerlo flexible

Sistemas que se adaptan a contextos diversos en lugar de imponer un único entorno "óptimo".

6. Construir sobre tierra firme

Apoyarse en estándares abiertos, formatos durables, dependencias estables. Evitar construir sobre arenas movedizas (APIs propietarias que mañana cambian, frameworks que se reescriben cada dos años).

7. Amplificar la conciencia

La computación puede fortalecer ecosistemas mediante proyectos de citizen science: medición de calidad del aire, biodiversidad, contaminación. Datos abiertos para tomar mejores decisiones colectivas.

8. Exponer todo (sin cajas negras)

Transparencia en arquitectura, código y procesos. El usuario debería poder entender qué hace su software y por qué.

9. Responder a los cambios

Adaptarse en lugar de imponer. Permacomputing prefiere sistemas evolutivos a soluciones rígidas.

10. Todo tiene su lugar (y a veces lo correcto es no hacer)

Antes de añadir tecnología, preguntarse si realmente hace falta. El principio "Not Doing" reconoce que la mejor solución muchas veces es no construir nada nuevo.

💡 Tip: Antes de aceptar un ticket que pide "agregar IA" a una feature existente, pasalo por el filtro del principio 10. ¿Se resuelve mejor con un select bien hecho? ¿Ya existe la funcionalidad y basta documentarla?

Datos y cifras: por qué importa ahora

Los números detrás de la urgencia de permacomputing son contundentes:

62 millones de toneladas de basura electrónica generadas en 2022 según el UN Global E-Waste Monitor —el equivalente al peso de unos 1.500 buques cargueros— y se proyectan 82 millones para 2030.- Entre 1% y 2% del consumo eléctrico mundial proviene de los data centers, una cifra que la Agencia Internacional de Energía estima podría duplicarse para 2030 por la demanda de IA.- Producir un solo chip moderno consume miles de litros de agua ultrapura y emite gases con potencial de calentamiento global miles de veces superior al CO₂.- Apenas el 22% del e-waste mundial se recicla formalmente. El resto termina en vertederos del Sur Global, contaminando suelos y aguas.- Una laptop promedio emite alrededor de 300 kg de CO₂ en su fabricación —más que un vuelo Buenos Aires–Madrid en clase económica.

Estos números explican por qué hablar de "computación sostenible" sin revisar el modelo de fabricación y descarte es una conversación incompleta.

Impacto en la práctica de desarrollo

Aplicar permacomputing al día a día como developer no requiere mudarse a un velero. Hay decisiones cotidianas con impacto real:

Stack técnico

Preferir lenguajes y runtimes eficientes cuando el caso lo permite. No todo necesita correr sobre Node + Electron + 80 dependencias. Una CLI en Go, una app TUI en Rust, un script en Python sencillo: muchas veces alcanza.

Infraestructura

Elegir proveedores con energía renovable verificable. Un servidor en una región con grid limpio (Quebec, Islandia, partes de Brasil con hidroeléctrica) tiene una huella significativamente menor que el mismo workload en una región dominada por carbón.

Hardware

Refurbished antes que nuevo. Reparar antes que reemplazar. Iniciativas como Framework Laptop o iFixit demuestran que es posible diseñar hardware reparable y seguir siendo competitivo.

Software

Empacar binarios optimizados, no incluir dependencias innecesarias, soportar arquitecturas viejas cuando sea barato hacerlo. Aceptar que tu código va a correr en un equipo con 4GB de RAM en algún lugar del mundo.

# Auditar el peso real de tu app antes de shipear
du -sh dist/
# 245M  dist/  ← ¿es necesario?

# Bundle analyzer para webpack/vite
npx vite-bundle-visualizer

# Para imágenes Docker, dive permite explorar capa por capa
dive my-image:latest

⚠️ Ojo: "small" no significa "primitivo". Permacomputing no romantiza la pobreza tecnológica. La idea es construir lo mínimo necesario para resolver el problema con elegancia, no privarse de herramientas útiles por dogmatismo.
La cultura de la reparación: permacomputing avant la lettre en LATAM.

Permacomputing en clave LATAM

América Latina tiene una relación particular con muchos de estos principios porque, en gran medida, ya los practica por necesidad. La cultura de la reparación —del taller que arregla un Nokia 3310 al técnico que mantiene servidores Pentium 4 corriendo en el ministerio— es permacomputing avant la lettre.

Algunos puntos donde la región está naturalmente alineada con el movimiento:

Reuso de hardware — laptops corporativas usadas que llegan al mercado secundario después de ciclos de 3-5 años en empresas. En Argentina, Chile, México y Colombia hay un mercado robusto de equipos refurbished.- Conexiones inestables — apps que funcionan offline-first, PWAs livianas y código que tolera latencia son parte del kit básico de cualquier developer regional.- Cortes de energía — UPS, generadores, salvado automático cada minuto. La resiliencia no es teoría.- Frugalidad técnica — no hay presupuesto para reemplazar todo cada año, así que mantener viejo es la norma.

Donde permacomputing puede aportar más a la región es en darle marco conceptual y dignidad a prácticas que muchas veces se ven como signos de subdesarrollo, cuando en realidad son ventajas competitivas para construir software resiliente.

Diagrama: permacultura como raíz

graph TD
    A["Permacultura (1978)"] --> B["Earth Care"]
    A --> C["People Care"]
    A --> D["Fair Share"]
    B --> E["Permacomputing"]
    C --> E
    D --> E
    E --> F["10 principios"]
    F --> G["Cuidar el hardware"]
    F --> H["Mantenerlo pequeno"]
    F --> I["Resiliencia"]
    F --> J["No hacer"]

Qué sigue para el movimiento

Permacomputing está en una etapa de consolidación. La working group publica artículos, organiza encuentros y mantiene el sitio principal. Hay una comunidad activa en el fediverso (Mastodon) bajo el hashtag #permacomputing, conferencias relacionadas como handmade.network y HOPE, y una creciente literatura académica sobre "computación sustentable" que dialoga con estas ideas.

El próximo desafío del movimiento es escalar sin perder coherencia. Que un principio inspire una práctica concreta —y verificable— es mucho más útil que diez principios bonitos sin tracción. Iniciativas como bandwidth budgets en sitios estáticos, calculadoras de huella de carbono para websites (websitecarbon.com) y certificaciones de software verde empiezan a operacionalizar estos valores.

💭 Clave: Permacomputing no es anti-tecnología. Es anti-desperdicio. La pregunta no es "¿menos computación?" sino "¿qué computación, para quién y por cuánto tiempo?".

📖 Resumen en Telegram: Ver resumen

Preguntas frecuentes

¿Permacomputing es lo mismo que green computing?

No exactamente. Green computing suele enfocarse en eficiencia energética dentro del paradigma actual. Permacomputing cuestiona el paradigma mismo: el modelo de crecimiento perpetuo, la obsolescencia programada y la dependencia de hardware nuevo.

¿Tengo que dejar de usar Kubernetes?

No. Permacomputing no prohíbe tecnologías, propone preguntarse si son la herramienta adecuada para cada caso. Si tu workload realmente justifica orquestación distribuida, adelante. Si lo usás para un blog estático que recibe 100 visitas al día, quizá un VPS de cinco dólares al mes alcanza.

¿Quién mantiene permacomputing.net?

Una working group informal compuesta por desarrolladores, artistas, investigadores y activistas. Es un proyecto comunitario sin financiamiento corporativo.

¿Existen herramientas concretas alineadas con estos principios?

Sí. Algunos ejemplos: el navegador Dillo, el sistema operativo 9front, los lenguajes Uxn y Orca de Hundred Rabbits, distribuciones Linux livianas como Alpine y Void, y el ecosistema suckless (dwm, st, surf).

¿Cómo empiezo a aplicar permacomputing en mi trabajo?

Auditá. Medí el peso de tus apps, el consumo de tu pipeline de CI/CD, el ciclo de vida del hardware que decidís comprar. Sin datos no hay diagnóstico, y sin diagnóstico no hay cambio.

¿Es viable para una startup que necesita escalar rápido?

Depende del nicho. Para muchas startups B2B con tracción incipiente, ir lean en stack y hardware reduce burn rate y alarga la pista. Permacomputing y unit economics se llevan mejor de lo que parece.

Referencias

permacomputing.net/principles — los 10 principios oficiales con explicaciones extendidas y estrategias de aplicación.- solar.lowtechmagazine.com — la revista que corre sobre un servidor solar y se cae cuando no hay sol suficiente.- wiki.xxiivv.com — la página de Devine Lu Linvega (Hundred Rabbits) sobre permacomputing y herramientas asociadas.

📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.

Valve libera los CAD del Steam Controller bajo Creative Commons

lu1tr0n — Wed, 06 May 2026 20:16:54 +0000

Valve volvió a hacer lo que pocos fabricantes de hardware hacen: publicó los archivos CAD del nuevo Steam Controller y de su accesorio Puck bajo una licencia Creative Commons. Con esta movida, cualquier maker, modder o estudio de diseño puede descargar la geometría exacta del control, abrirla en su software favorito e imprimir, fresar o moldear accesorios que encajen al milímetro: skins, soportes para teléfono, bases de carga, extensores de grip o adaptadores de accesibilidad.

La decisión llega pocos días después de que las primeras unidades del nuevo Steam Controller empezaran a llegar a los compradores afortunados que lograron reservarlo. Y aunque Valve ya tenía costumbre de publicar este tipo de material —lo hizo con Steam Deck, con Valve Index e incluso con el Steam Controller original hace una década— el gesto sigue siendo notable en una industria donde lo habitual es proteger cada milímetro de la carcasa con NDAs y patentes defensivas.

Qué publicó Valve exactamente

El paquete liberado por Valve, anunciado en Steam Community, contiene la topología de superficie (surface topology) del cuerpo externo tanto del Steam Controller como del Puck. Para quienes no vienen del mundo del CAD: la topología de superficie es básicamente la geometría exterior del dispositivo —la cáscara que toca tu mano— sin los componentes electrónicos internos. Es lo justo y necesario para diseñar accesorios que encajen, sin exponer secretos industriales sobre el sensor de movimiento o la electrónica de los trackpads.

Cada dispositivo viene en tres formatos:

STP (Standard for the Exchange of Product Data) — el formato neutro estándar de la industria. Es el que querés abrir en SolidWorks, Fusion 360, FreeCAD, Onshape o cualquier CAD paramétrico serio. Mantiene la geometría como sólidos B-rep editables.- STL (Stereolithography) — la malla triangulada lista para impresión 3D. Si tu objetivo es tirarla a una Bambu Lab, una Prusa o una Ender, este es el archivo que cargás directo en el slicer.- Diagrama de ingeniería — un plano con cotas que marca explícitamente las zonas que no pueden quedar cubiertas, principalmente para preservar la integridad de las antenas inalámbricas y el funcionamiento de los sensores.

Ese último archivo es probablemente el más subestimado del paquete. Sin él, un diseñador podría tapar una antena interna sin querer y degradar la conectividad del control. Con el plano oficial, queda claro qué áreas del chasis hay que dejar libres para que el dispositivo siga funcionando como Valve lo diseñó.
Los archivos STP y STL permiten diseñar accesorios con tolerancias precisas.

Una licencia generosa, pero con condiciones

El detalle fino está en la licencia. Valve eligió una variante Creative Commons bastante específica que combina tres cláusulas conocidas en el mundo del open content:

NC (Non-Commercial): el uso debe ser no comercial. No podés vender accesorios impresos a partir de estos archivos sin un acuerdo aparte.- BY (Attribution): hay que atribuir el origen a Valve.- SA (Share-Alike): los diseños derivados deben compartirse con la comunidad bajo la misma licencia.

La cláusula más restrictiva es la NC. Para un maker que quiere imprimir un soporte para su teléfono y compartirlo en Printables o Thingiverse, la licencia es perfecta. Para un emprendedor que quería abrir una tienda de accesorios en MercadoLibre o Tienda Nube vendiendo grips ergonómicos al por mayor, la cláusula es un freno. La buena noticia: Valve aclaró explícitamente que las empresas interesadas en hacer accesorios comerciales pueden contactarlos directamente para discutir términos. Es decir, hay puerta abierta a licencias comerciales caso por caso.

📌 Nota: CC-BY-NC-SA es una licencia perfectamente legítima del ecosistema Creative Commons, pero NO es considerada "libre" según las definiciones estrictas de la FSF o la OSI porque restringe el uso comercial. Es "open" en el sentido coloquial, no en el sentido legal estricto.

Por qué esto importa para LATAM

Para la comunidad maker latinoamericana, esta liberación tiene un valor concreto que va más allá del fanservice gamer. En la región, donde los accesorios oficiales suelen llegar tarde, caros o directamente nunca llegan, contar con archivos CAD oficiales abre tres oportunidades inmediatas:

1. Accesorios de accesibilidad. Diseñadores y terapeutas ocupacionales en Argentina, México, Colombia o Chile pueden adaptar el control para personas con movilidad reducida sin esperar que Valve saque una versión "adaptive" como la que Microsoft tiene para Xbox. Tomás los STP, agregás extensiones, botones más grandes, un sistema de switch externo, y lo imprimís en una FabLab universitaria por una fracción del costo de un controlador adaptativo importado.

2. Reparación y reemplazo. Cuando un control oficial cuesta el equivalente a un sueldo mínimo en muchos países de la región, poder imprimir piezas exteriores de repuesto —tapas, bumpers, gatillos rotos— se vuelve una alternativa real frente a tirar el dispositivo o pagar repuestos importados con impuestos.

3. Educación técnica. Los STP de Valve son material didáctico de primera línea para cursos de diseño industrial, ergonomía o ingeniería mecatrónica. Se trata de un dispositivo real, vendido en producción, con una geometría compleja, restricciones electromagnéticas y consideraciones ergonómicas explicadas en los planos. No hay manera de comprar ese tipo de caso de estudio en un libro.

Cómo abrir y usar los archivos

Para quien nunca trabajó con CAD, la barrera de entrada en 2026 es más baja que nunca. El flujo típico para imprimir un accesorio sería el siguiente:

flowchart LR
  A["Descarga STP/STL"] --> B["Abrir en CAD"]
  B --> C["Diseñar accesorio"]
  C --> D["Exportar STL"]
  D --> E["Slicer"]
  E --> F["Impresora 3D"]

Algunas opciones de software, todas con planes gratuitos para uso personal:

FreeCAD 1.0 — open source, multiplataforma, importa STP nativo. Ideal si querés mantener todo el flujo en software libre.- Onshape — corre en el navegador, gratis para proyectos públicos. No requiere instalar nada, ideal para quienes están en computadoras con poca RAM.- Autodesk Fusion 360 — gratis para uso personal con cuenta verificada. Es el estándar de facto en muchos hubs de fabricación.- Bambu Studio / PrusaSlicer / OrcaSlicer — para slicear el STL final hacia G-code. Todos gratuitos.

Un comando típico para validar un STL antes de imprimir, usando la herramienta admesh disponible en los principales sistemas operativos:

# Linux / macOS / Windows (con admesh instalado)
admesh --write-binary-stl=fixed.stl --check --tolerance=0.01 steam_controller.stl

Esto verifica que la malla esté cerrada, sin triángulos invertidos ni huecos, antes de mandarla al slicer. Un STL roto puede arruinar una impresión de 12 horas, así que vale el minuto de validación.
FreeCAD, Onshape o Fusion 360 son opciones gratuitas para abrir los STP.

El patrón Valve: hardware con vocación de ecosistema

La liberación de archivos CAD encaja con un patrón que Valve ha venido cultivando durante años. Cuando publicaron el CAD del Steam Deck en 2022, la comunidad respondió con una explosión de docks, soportes refrigerantes, mochilas con corte exacto y carcasas con shrouds modificados. JSAUX, dbrand y media docena más de fabricantes construyeron negocios alrededor del ecosistema Steam Deck, varios bajo licencias comerciales acordadas directamente con Valve.

El Valve Index siguió la misma lógica con sus mounts, faceplates y mods de confort que la comunidad de VR adoptó masivamente. El Steam Controller original, hace ya una década, también recibió este tratamiento. La consistencia del patrón sugiere que para Valve no se trata de un gesto aislado de buena voluntad, sino de una estrategia: hardware diseñado para que un ecosistema de terceros lo amplíe, lo personalice y lo mantenga vigente más allá del ciclo de vida que el fabricante puede sostener por sí solo.

💭 Clave: Mientras Sony y Nintendo persiguen modders con cartas de cease-and-desist, Valve les entrega los CAD oficiales. Son dos teorías opuestas sobre qué es realmente "el producto": el hardware aislado o el ecosistema completo.

Datos clave del lanzamiento

2 dispositivos cubiertos: el Steam Controller y el Puck.- 3 formatos por dispositivo: STP, STL y diagrama de ingeniería con zonas restringidas.- Licencia: Creative Commons con cláusulas Attribution, Non-Commercial y Share-Alike (variante CC BY-NC-SA).- 4 ediciones previas: Valve ya había liberado CAD para Steam Controller original (2015), Valve Index (2019), Steam Deck (2022) y ahora el nuevo Steam Controller (2026).- Canales de uso comercial: Valve invita a las empresas interesadas a contactar directamente para términos personalizados.

Lo que viene

En las próximas semanas se espera la oleada habitual de publicaciones en Printables, Thingiverse y MakerWorld con accesorios derivados. Históricamente los primeros suelen ser los más útiles: clips de teléfono para streaming con Steam Link, soportes verticales para escritorio, extensores de gatillo para manos grandes, y rampas de carga que se integran con el Puck. Después llegan las propuestas más creativas —shells temáticas, integraciones con setups de simulación, montajes para sillas de ruedas eléctricas— que Valve nunca habría sacado oficialmente pero que prosperan justamente porque la geometría está en manos de la comunidad.

Para los desarrolladores, hay además una segunda capa de oportunidad: con la geometría exacta del control disponible, se vuelve trivial generar modelos 3D precisos para tutoriales en video, documentación interactiva, simuladores de control en el navegador con WebGL/Three.js o materiales de marketing para juegos que quieran mostrar el mapeo de botones de manera fiel.

Es, en suma, otro recordatorio de que el hardware abierto —incluso parcialmente abierto, como en este caso— suele generar más valor que el hardware cerrado de manual. Y que en una industria donde la mayoría de los grandes fabricantes invierten en perseguir modders, hay todavía espacio para una compañía que prefiera entregarles las herramientas oficiales.

📖 Resumen en Telegram: Ver resumen

Preguntas frecuentes

¿Puedo vender accesorios impresos con estos archivos?

No bajo la licencia por defecto. La cláusula NC de Creative Commons restringe explícitamente el uso comercial. Sin embargo, Valve aclaró que las empresas interesadas en comercializar accesorios pueden contactarlos directamente para acordar términos comerciales caso por caso, como ya hicieron empresas como JSAUX y dbrand con accesorios para Steam Deck.

¿Qué diferencia hay entre los archivos STP y STL?

El STP (a veces llamado STEP) es un formato paramétrico que conserva la geometría como sólidos editables: podés modificarlo, agregar features, hacer operaciones booleanas. El STL es una malla de triángulos pensada para impresión 3D: ya no es editable como sólido, pero es lo que el slicer necesita. Para diseñar un accesorio nuevo querés el STP; para imprimir directamente sin modificar nada, el STL alcanza.

¿Por qué Valve no liberó también los componentes internos?

Lo que Valve liberó es la "topología de superficie", es decir, solo la cáscara externa. Los componentes internos —placa, sensores, electrónica— siguen siendo propiedad cerrada y no se publicaron. La razón es práctica: para diseñar accesorios externos no se necesita la electrónica, y publicar la PCB completa expondría secretos industriales que sí están protegidos por patentes.

¿Qué software gratuito puedo usar para abrir los archivos?

FreeCAD 1.0 es completamente open source y abre STP nativamente. Onshape funciona en el navegador y es gratuito para proyectos públicos. Autodesk Fusion 360 es gratis para uso personal con cuenta verificada. Para impresión 3D directa con los STL, cualquier slicer estándar como Bambu Studio, PrusaSlicer u OrcaSlicer abre los archivos sin problema.

¿Esto significa que Valve va a abrir el firmware del Steam Controller?

No necesariamente. Liberar los CAD de la carcasa externa es muy distinto de liberar el firmware o el código del software del controlador. Hasta el momento, Valve no anunció planes en esa dirección y mantiene tanto el firmware como los drivers como código cerrado, aunque parte del stack de Steam Input es accesible mediante su SDK.

¿Hay riesgo de que un accesorio mal diseñado dañe el control?

Sí, especialmente si tapa zonas que el diagrama de ingeniería marca como restringidas. Cubrir antenas internas puede degradar el alcance inalámbrico, y mecanismos mal ajustados podrían forzar gatillos o sticks. La buena práctica es respetar al pie de la letra el plano oficial con las áreas restringidas y hacer pruebas progresivas antes de imprimir versiones finales.

Referencias

Digital Foundry — cobertura original del anuncio de Valve y detalles de los formatos liberados.- Creative Commons — explicación oficial de las variantes de licencia y qué permite cada cláusula (BY, NC, SA).- FreeCAD — software CAD paramétrico open source compatible con archivos STP del paquete de Valve.

Coverage Cat busca Growth Engineer fraccional a $15-25/hora

lu1tr0n — Wed, 06 May 2026 14:19:11 +0000

Introducción

El 5 de mayo de 2026, Coverage Cat —el corredor de seguros AI-native respaldado por Y Combinator— publicó una vacante peculiar: un puesto de Growth Engineer fraccional a $15-25 por hora. No es una contratación de tiempo completo. No es un becario. Es una figura nueva que está ganando terreno en las startups de Silicon Valley: el ingeniero de crecimiento bajo contrato, dispuesto a saltar entre código, automatizaciones, integraciones con IA y, si hace falta, contratar gente en Craigslist para hacer canvassing presencial.

La oferta de Coverage Cat parece menor a primera vista, pero ilustra tres tendencias que vienen acelerando desde 2024: el auge del rol de growth engineer como disciplina propia, la fragmentación del trabajo a tiempo parcial en tecnología y el aprovechamiento de talento global por parte de startups Y Combinator. Este puesto en particular abre interrogantes sobre cómo las empresas AI-native están repensando su estructura de personal y dónde caben los desarrolladores latinoamericanos en esa ecuación.

Qué pasó

Coverage Cat publicó la vacante en su página oficial de careers el 5 de mayo de 2026. La descripción es breve pero reveladora: buscan a alguien self-starter, entry level, dispuesto a apoyar al equipo con "organic growth engineering implementation and operations". El abanico de responsabilidades es deliberadamente amplio: desde "diseñar herramientas de IA para crecimiento" hasta "contratar gente para hacer canvassing presencial vía Craigslist".

El salario es modesto para Estados Unidos: $15-25 por hora, con posibilidad de incentivos adicionales. La empresa explícitamente prohíbe aplicar a residentes de California, Massachusetts, Nueva Jersey, Oregon, Washington, Connecticut, Illinois, Rhode Island, Maryland, Michigan, Nuevo Hampshire y Hawái. La aplicación se canaliza únicamente a través de la plataforma Work at a Startup de Y Combinator. Las solicitudes por correo electrónico, advierten, son descartadas sin revisión.

Coverage Cat se autodescribe como "the world's AI-native insurance broker", una posición que ha estado promocionando desde su salida de Y Combinator. La frase clave de su anuncio resume la filosofía: "Growing the world's AI-native insurance broker still takes some IRL effort". Es decir: incluso una empresa AI-first necesita esfuerzo presencial humano que alguien tiene que coordinar.

Contexto: el ascenso del Growth Engineer

El término Growth Engineer surgió en empresas como Facebook, Pinterest y Airbnb a inicios de la década pasada. En esos primeros años, el rol consistía en aplicar técnicas de growth hacking con una base sólida de programación: instrumentar funnels de conversión, automatizar A/B tests, optimizar tasas de signup, integrar herramientas de analítica. Era una mezcla entre desarrollador full-stack, product manager y especialista en marketing digital.

Hacia 2024, con la masificación de las APIs de modelos generativos, el rol se redefinió. Hoy, un Growth Engineer en una startup AI-native ya no escribe solamente código de tracking: orquesta agentes de IA que ejecutan campañas, integra LLMs en flujos de prospección, optimiza prompts para conversión y, en muchos casos, codea pipelines de datos para alimentar modelos de scoring. La línea entre marketing, producto e ingeniería se diluye más cada trimestre.

La novedad de la oferta de Coverage Cat no está en el rol en sí, sino en su modalidad: fraccional. La empresa no busca contratar a alguien por 40 horas semanales. Quiere acceso a un especialista por horas, sin compromiso laboral fijo. Este formato —típico hasta ahora del consultoring legal o financiero— está penetrando rápidamente en el mundo del software, y refleja la presión por mantener equipos centrales pequeños mientras se accede a habilidades especializadas bajo demanda.

El growth engineer fraccional alterna entre código, analítica y operaciones tácticas.

¿Qué hace exactamente un Growth Engineer fraccional?

La descripción de Coverage Cat es deliberadamente amplia, pero podemos desglosar las áreas típicas de un growth engineer fraccional en una startup AI-native de 2026.

Primero: experimentación de adquisición. Esto incluye montar landing pages, configurar herramientas de analítica, instrumentar eventos en frontend y backend, y montar pipelines de datos para medir conversión por canal. Un fragmento típico de tracking server-side podría verse así:

import { track } from "@growth/analytics";

export async function handleSignup(req: Request) {
  const user = await createUser(req.body);

  await track({
    event: "user_signed_up",
    distinctId: user.id,
    properties: {
      source: req.headers.get("x-utm-source") ?? "direct",
      campaign: req.headers.get("x-utm-campaign"),
      experiment_variant: req.cookies.get("ab_variant"),
      first_touch_at: user.created_at,
    },
  });

  return Response.json({ ok: true });
}

Segundo: automatización de prospección con IA. Un growth engineer moderno integra modelos como Claude o GPT para generar mensajes personalizados, scoring de leads y filtrado automático de prospects. La frontera con un AI engineer es porosa.

Tercero: operaciones híbridas. La frase de Coverage Cat sobre contratar gente en Craigslist no es retórica: en una startup AI-native, el growth engineer también orquesta humanos cuando los algoritmos no llegan. Diseña scripts de canvassing, gestiona contratistas, mide ROI por canal humano.

Cuarto: integración con CRM y herramientas SaaS. Conectar HubSpot con Stripe, Stripe con Slack, Slack con un workflow LangChain. Es plomería con propósito de crecimiento, y exige fluidez en muchas APIs distintas.

💡 Tip: El stack típico de un growth engineer fraccional combina Segment o PostHog para analítica, Retool o Internal para herramientas internas, Make/Zapier o n8n para automatización, y un LLM de OpenAI/Anthropic para tareas de razonamiento.

El flujo de trabajo de un Growth Engineer

El ciclo de iteración es deliberadamente corto: hipótesis, código, datos, decisión. Un growth engineer competente cierra varios de estos ciclos por semana, no por trimestre.

flowchart LR
    A["Hipotesis de crecimiento"] --> B["Diseno de experimento"]
    B --> C["Implementacion tecnica"]
    C --> D["Tracking y analitica"]
    D --> E["Analisis de resultados"]
    E --> F{"Funciono?"}
    F -- "Si" --> G["Escalar"]
    F -- "No" --> A

Datos y cifras: el mercado fraccional en tech

El trabajo fraccional crece a tasas de doble dígito en Estados Unidos desde 2023. Según estimaciones de plataformas como Toptal, Upwork y Contra, el segmento de fractional executives y fractional engineers creció más de 40% año contra año en 2025. El salario reportado en la oferta de Coverage Cat —$15 a $25 por hora— es bajo respecto a la mediana del Bay Area, pero competitivo internacionalmente: equivale a entre $2.400 y $4.000 mensuales asumiendo 40 horas semanales.

Para contexto: el salario promedio de un desarrollador junior en Buenos Aires, Ciudad de México o San Salvador ronda los $1.500 a $2.500 mensuales en 2026. Un puesto remoto pagando $20/hora con flexibilidad horaria está, por tanto, en la franja superior del mercado regional, especialmente para perfiles entry-level. La narrativa de "salario bajo en EE.UU., competitivo en LATAM" no es nueva, pero la modalidad fraccional añade una capa: no estás compitiendo por uno de cinco puestos full-time, sino por horas de varias startups.

La restricción geográfica que aplica Coverage Cat —excluyendo doce estados de Estados Unidos— responde a complejidades laborales y fiscales: California, Massachusetts y Washington tienen leyes estrictas sobre clasificación de contratistas (en la línea de la AB5 californiana). La empresa no excluye explícitamente a aplicantes internacionales, lo que abre la puerta a desarrolladores de LATAM siempre que la aplicación se realice por la plataforma de Y Combinator.

Impacto y análisis: oportunidad para LATAM

El puesto de Coverage Cat es un microcosmos de una tendencia más amplia: las startups AI-native están externalizando funciones tácticas a contratistas remotos para mantener equipos centrales pequeños. Esto tiene implicaciones concretas para los desarrolladores en América Latina que sepan posicionarse.

Primero, la barrera de entrada al ecosistema YC se reduce. Aplicar a un puesto fraccional es menos competido que aplicar a un puesto full-time, y permite construir trayectoria con startups de alto perfil sin reubicación. Segundo, las habilidades pedidas son combinaciones híbridas que muchos desarrolladores latinos ya cultivan por necesidad: full-stack ligero, automatización, integración de SaaS, prompt engineering, gestión de contratistas.

Tercero, la oferta sienta un precedente: empresas YC con foco en IA están dispuestas a pagar $20/hora por trabajo de growth engineering remoto. Es una señal de calibración para freelancers y consultores hispanohablantes que pueden posicionar sus servicios con esa referencia, sin caer en la trampa de cobrar por debajo del mercado regional.

El trabajo fraccional remoto abre la puerta de las startups YC al talento LATAM.

📌 Nota: La oferta exige aplicar exclusivamente vía Y Combinator's Work at a Startup. Crear un perfil sólido en esa plataforma —con repos en GitHub, casos de estudio y links a productos en producción— es prerrequisito para cualquier desarrollador LATAM que quiera competir por estos roles.

Qué sigue: el futuro del trabajo en startups AI-native

La oferta de Coverage Cat encaja con una hipótesis que viene tomando forma: en 2026, las startups AI-native operarán con plantillas más pequeñas pero ecosistemas extendidos de contratistas. Los founders mantienen un núcleo de 5 a 10 ingenieros senior y rodean ese núcleo de 10 a 30 contratistas fraccionales —diseñadores, growth engineers fraccionales, data engineers, content writers— escalando o desescalando según necesidad.

Para los desarrolladores que sepan aprovechar esta dinámica, la oportunidad es doble: ingresos diversificados (varios contratos pequeños en lugar de uno grande) y exposición a múltiples industrias y tecnologías. Para los que no se adapten, el riesgo es la commoditización: si tu trabajo es replicable y por horas, vas a competir globalmente con todos los demás candidatos por horas.

💭 Clave: La diferencia entre un growth engineer fraccional commodity y uno premium no es la velocidad de tipeo. Es el portafolio de experimentos exitosos documentados, el dominio de stacks AI-native concretos y la capacidad de explicar resultados en términos de revenue, no de líneas de código.

📖 Resumen en Telegram: Ver resumen

Preguntas frecuentes

¿Qué es exactamente un growth engineer fraccional?

Un ingeniero que trabaja por horas o proyectos —no a tiempo completo— en iniciativas de crecimiento de una empresa. Combina código, analítica, automatización con IA y operaciones tácticas como gestión de campañas o canvassing presencial.

¿Puedo aplicar al puesto de Coverage Cat desde LATAM?

La oferta no excluye explícitamente aplicantes internacionales. Sin embargo, exige aplicar mediante Y Combinator's Work at a Startup. Crear un perfil verificado en esa plataforma con repos, casos de estudio y experiencia documentada es el primer paso obligatorio.

¿Es competitivo el salario de $15-25/hora?

Para mercados como California o Nueva York, está por debajo del estándar local. Para LATAM, es competitivo: $20/hora a 40 horas semanales equivale a unos $3.200 mensuales, por encima de la mediana de developers junior y mid-level en la región en 2026.

¿Qué habilidades necesito para un puesto así?

TypeScript o Python para automatizaciones, conocimiento de herramientas de analítica (PostHog, Mixpanel, Segment), experiencia integrando APIs de SaaS, dominio básico de SQL, y comodidad usando LLMs (Claude, GPT-4) para tareas de razonamiento y generación de contenido.

¿Qué diferencia hay entre un growth engineer y un AI engineer?

Un AI engineer construye sistemas que dependen de modelos de IA: pipelines, embeddings, fine-tuning, evaluación. Un growth engineer aplica esos sistemas (entre otras herramientas) para mover métricas de negocio: adquisición, activación, retención. Hay solapamiento creciente, pero el foco diferencia.

¿Por qué Coverage Cat excluye varios estados de EE.UU.?

Por leyes laborales locales que complican la clasificación de contratistas independientes (típicamente AB5 en California y leyes similares en otros estados). Es una decisión de cumplimiento regulatorio, no de preferencia técnica.

Referencias

Coverage Cat — Fractional Growth Engineer — La oferta original analizada en este artículo.
Y Combinator's Work at a Startup — Plataforma exclusiva de aplicación al puesto.
Wikipedia: Growth hacking — Antecedentes y definición de la disciplina de la que deriva el rol de growth engineer.
Wikipedia: Y Combinator — Contexto sobre la aceleradora detrás de Coverage Cat.

Cloudflare Agents Week 2026: 20 productos en una semana para reescribir cómo se construye software con agentes

lu1tr0n — Wed, 06 May 2026 12:48:50 +0000

La semana del 13 al 20 de abril de 2026, Cloudflare ejecutó la batería de anuncios más densa de su historia: más de veinte productos lanzados o promovidos a disponibilidad general durante lo que la empresa llamó Agents Week 2026. El resumen oficial, el press release del 13 de abril y la página de updates coinciden en una tesis estratégica: la red global de Cloudflare —330 ciudades, infraestructura edge, isolates de V8 como sustrato de cómputo— se reorganiza para tratar a los agentes IA como ciudadanos de primera clase, no como una capa decorativa sobre Workers tradicionales.

La frase del CEO Matthew Prince que enmarca el lanzamiento es directa:

"The way people build software is fundamentally changing. We are entering a world where agents are the ones writing and executing code."

Y la pieza que cierra el círculo es la cita de Rohan Varma, jefe de producto de Codex en OpenAI, en el mismo press release:

"Cloud agents are quickly becoming a foundational building block for how work gets done, and with Cloudflare, we're making it dramatically easier for developers to deploy production-ready agents powered by GPT-5.4 and Codex to run real enterprise workloads at scale."

El alcance del lanzamiento no permite cobertura uniforme: este artículo se concentra en los cinco productos con mayor impacto operativo —Dynamic Workers, Sandboxes en GA, Artifacts, AI Platform y la nueva cf CLI— y enumera el resto en bloques temáticos. La cobertura técnica se apoya en los blogs oficiales de Cloudflare, la cobertura de InfoQ sobre Sandboxes GA, InfoWorld sobre Dynamic Workers, y The Register sobre la unificación de Wrangler CLI.

Dynamic Workers: isolates V8 100× más rápidos que containers

Dynamic Workers es la pieza arquitectónica más relevante del lanzamiento. La premisa es simple pero radical: cuando un agente IA genera código en tiempo de ejecución —típicamente TypeScript— ¿dónde lo ejecutás? Las opciones tradicionales son containers, máquinas virtuales o sandboxes WASM. Cloudflare propone usar isolates de V8, los mismos que Workers usa desde hace años, pero adaptados para una carga de trabajo distinta: ejecuciones efímeras de alta concurrencia donde cada solicitud de usuario puede instanciar un isolate propio.

Los números que Cloudflare publica son contundentes:

Cold start: ~5 ms —comparado con ~500 ms típicos de containers, es 100× más rápido.
Memoria: 10-100× más eficiente que containers de propósito general.
Cada isolate consume del orden de unos pocos megabytes de RAM, frente a las decenas o centenas de un container.

El patrón de uso oficial se llama "Code Mode": en lugar de pedir al modelo que ejecute múltiples llamadas a herramientas separadas —el patrón clásico de tool calling—, se le pide que escriba una función TypeScript corta contra una API definida y se ejecuta una sola vez. Esto reduce la chatter agente↔backend de decenas de round-trips a uno solo, y aprovecha que los modelos modernos generan código TypeScript bien.

// Ejemplo conceptual de Code Mode con Dynamic Workers
const generated = await llm.generate(`
  Escribe una función TypeScript que tome el array {{products}}
  y devuelva los tres más caros con descuento del 15%.
`);

// Cloudflare ejecuta el código generado en un isolate fresco
const result = await env.DYNAMIC_WORKER.run(generated, { products });
// Latencia total: ~5ms para arrancar el isolate + tiempo de cómputo

El producto está en beta abierta bajo plan pagado de Workers desde marzo de 2026. El pricing es 0.002 USD por Worker único cargado al día, más cargos de CPU e invocación —tarifa waived durante la beta—. Las Durable Object Facets, anunciadas en la misma semana, permiten agregar bases de datos SQLite aisladas dentro de Dynamic Workers para estado persistente sin salir del isolate.

Cloudflare Sandboxes GA: un computador completo por agente

Sandboxes alcanzó GA en Agents Week. La diferencia con Dynamic Workers es de naturaleza: si Dynamic Workers son para ejecución efímera de código, Sandboxes son para sesiones largas de desarrollo agente donde se requiere shell, filesystem, procesos en background y herramientas Linux completas. Un Sandbox es, literalmente, un entorno Linux persistente y aislado que un agente puede usar como un developer humano usa una VM.

Las capacidades específicas que la GA agrega sobre la beta:

Inyección segura de credenciales con egress proxies, para que el agente pueda hacer push a GitHub o llamar APIs autenticadas sin que las credenciales pasen por el modelo.
Soporte de PTY terminal —el agente puede correr vim, top, htop, programas interactivos.
Code interpreters persistentes —Python, Node.js, etcétera, con estado entre invocaciones.
Filesystem watching —el sandbox emite eventos en tiempo real cuando un archivo cambia, sin necesidad de polling.
Recuperación basada en snapshots: el disco completo se serializa, y restaurar de un snapshot toma ~2 segundos contra los ~30 segundos de bootear desde cero, clonar repo y correr npm install.
Active CPU pricing —solo se cobra por ciclos efectivamente usados, no por tiempo de pared del sandbox.

El patrón de uso más interesante que Cloudflare destaca son forks de sesión: bootear cuatro Sandboxes desde el mismo snapshot para explorar cuatro abordajes en paralelo. Para una tarea de "intentá tres formas distintas de resolver este bug y reportá la mejor", el agente literalmente paraleliza la exploración sin pelear con merges en el filesystem.

Figma ya está corriendo workloads de agentes en producción sobre Sandboxes, según el anuncio. Es el primer cliente de referencia público y explícito.

# Crear un sandbox y conectarse
cf sandboxes create --name agent-debug-1 --image ubuntu-24.04
cf sandboxes ssh agent-debug-1

# El agente trabaja dentro del sandbox:
git clone git@github.com:my-org/repo.git
cd repo && npm install && npm test

# Cuando termina, snapshot para reusar
cf sandboxes snapshot agent-debug-1 --tag clean-state-after-tests

# Forkear cuatro veces para exploración paralela
cf sandboxes restore --tag clean-state-after-tests --count 4

Artifacts: storage versionado que habla Git

Artifacts responde a una pregunta concreta: cuando un agente trabaja en una sesión larga, ¿dónde guarda el estado intermedio de su trabajo de manera que sea reproducible, versionable y compartible? Las respuestas tradicionales son S3 + lockfiles caseros, o GitHub con sus límites de cuenta y latencia. Cloudflare propone un storage Git-compatible nativo, construido sobre Durable Objects y un servidor Git en WASM.

Las propiedades técnicas:

Decenas de millones de repositorios por cuenta, con bajo overhead por repo.
Cada repo es un Git remote auténtico —cualquier cliente Git, incluyendo git clone, git push, git fetch, funciona contra una URL HTTPS de Artifacts—. No hay protocolo nuevo que aprender.
Fork desde cualquier remote —incluyendo repositorios públicos de GitHub, GitLab, Codeberg— para que el agente parta de un estado conocido.
Operaciones nativas para agentes: git diff, git log, git search directamente sobre la URL, sin necesidad de clonar localmente primero.
Cloudflare usa Artifacts internamente para que sus propios agentes persistan estado de sesión: cada sesión del agente Lee genera un repo per-session que captura tanto el filesystem como el historial conversacional, permitiendo time-travel.

# Un agente crea un repo nuevo en Artifacts
git clone https://artifacts.cloudflare.com/u/my-org/empty.git project-x
cd project-x

# Trabaja normalmente
echo "console.log('hi')" > index.js
git add . && git commit -m "first iteration"

# Al final de la sesión, el repo queda persistido
git push origin main

# Un humano luego puede explorar desde su laptop
git clone https://artifacts.cloudflare.com/u/my-org/project-x.git

El changelog del 16 de abril marca el inicio de la beta privada. La beta pública estaba programada para inicios de mayo de 2026. El pricing se cobra por almacenamiento consumido + operaciones (clones, forks, pushes, pulls), con repos grandes proporcionalmente más caros que pequeños.

AI Platform: una API para 70+ modelos de 12+ proveedores

AI Platform consolida el catálogo de modelos. La premisa: cualquier agente serio terminará llamando a múltiples proveedores de modelos —OpenAI para razonamiento, MiniMax para video, AssemblyAI para audio, modelos open-source para tareas específicas—. Hoy eso significa integrar siete SDKs distintos, gestionar siete sets de credenciales, y reconciliar siete estructuras de pricing. AI Platform ofrece un único binding AI.run() que enruta cualquier llamada al proveedor adecuado.

La lista de proveedores soportados al día del lanzamiento incluye Alibaba Cloud, AssemblyAI, Bytedance, Google, InWorld, MiniMax, OpenAI, Pixverse, Recraft, Runway, Vidu, además de los modelos open-source corriendo nativamente en Workers AI. El total reportado: más de 70 modelos desde 12+ proveedores, con expansión planeada.

// Worker que llama a varios modelos sin cambiar SDK
export default {
  async fetch(request, env) {
    // Modelo de OpenAI
    const summary = await env.AI.run('@openai/gpt-5.4', {
      messages: [{ role: 'user', content: 'Resume este texto: ...' }]
    });

    // Modelo de imagen de Recraft
    const image = await env.AI.run('@recraft/recraft-v3', {
      prompt: summary.choices[0].message.content
    });

    // Modelo open-source en Workers AI
    const embedding = await env.AI.run('@cf/baai/bge-large-en-v1.5', {
      text: [summary.choices[0].message.content]
    });

    return Response.json({ summary, image, embedding });
  }
};

La API REST está en camino para entornos fuera de Workers, lo cual permite usar AI Platform desde aplicaciones Python, Go, o cualquier stack tradicional sin migrar el código a edge. La capa de monitoreo de costos centralizado es notable: una sola vista para todo el gasto en IA de la organización, con metadatos personalizados que permiten desglose por usuario final, cliente del SaaS, o flujo de trabajo específico.

La comparación natural es con OpenRouter —un agregador que cobra un margen sobre los proveedores subyacentes—. La diferencia estructural es que Cloudflare ya hostea muchos de los modelos open-source en su red y puede ofrecer latencias competitivas para esos sin pago de margen al proveedor original. Para los modelos comerciales (OpenAI, Google, etc.), Cloudflare es esencialmente un proxy con observabilidad agregada.

cf CLI: el reemplazo unificado de Wrangler

La nueva cf CLI es la pieza con menor visibilidad mediática pero quizás la mayor consecuencia ergonómica de la semana. Hasta ahora, un developer de Cloudflare que toca varios productos vive en un infierno de fragmentación: Workers se gestiona con wrangler, DNS se gestiona desde el dashboard, R2 tiene su propio CLI, los Pages tenían su propio flujo, y para infraestructura IaC se usa Terraform o Pulumi. Cada herramienta cubre un subconjunto de la API total y los nombres de comando son inconsistentes.

cf, anunciada en preview técnica el 13 de abril por The Register, consolida todo en una herramienta:

# Instalación
npx cf
# o
npm install -g cf

# Comandos unificados de ejemplo
cf workers deploy ./my-worker.ts
cf dns records add example.com www A 192.0.2.1
cf r2 bucket create my-bucket
cf sandboxes create --name agent-1
cf artifacts repo create my-project

La arquitectura interna es notable: Cloudflare construyó un schema TypeScript que define la totalidad de su API, los comandos CLI, los argumentos y el contexto de uso. Desde ese schema se generan automáticamente la CLI, los SDKs en distintos lenguajes, y la documentación. La motivación explícita es que los agentes IA puedan descubrir y usar la API de Cloudflare sin que un humano les tenga que enseñar cada producto nuevo —el schema es la fuente de verdad—.

A día de la preview, cf cubre solo una porción de los productos de Cloudflare. La integración total con las funciones de Wrangler está prevista para los próximos meses. Para producción seria, todavía conviene mantener wrangler en el flujo principal y experimentar con cf en paralelo.

Los otros 15 productos: panorama completo

Más allá de las cinco piezas anteriores, Agents Week incluyó otros 15 lanzamientos que vale la pena nombrar para tener el mapa completo.

Compute y orquestación:

Outbound Workers — proxy de egreso para Sandboxes con control granular sobre tráfico saliente, esencial para inyección de credenciales sin exponerlas al modelo.
Workflows v2 — motor de ejecución durable con límite de concurrencia de 50.000 y 300 creaciones por segundo. Para agentes que requieren correr tareas que duran minutos u horas con tolerancia a fallos, esto es el motor de orquestación nativo.

Seguridad:

Cloudflare Mesh — red privada segura para que agentes hablen entre sí o con servicios internos sin pasar por internet pública.
Managed OAuth for Access — autenticación de agentes contra servicios protegidos con OAuth, gestionada por Cloudflare en lugar del developer.
API Tokens mejorados — tokens escaneables con prefijos identificables y permisos con alcance de recursos específicos, no solo de servicios completos.
Enterprise MCP — arquitectura de referencia para desplegar Model Context Protocol en organizaciones grandes con compliance.

Toolbox de agentes:

Project Think — SDK para tareas de larga duración con manejo nativo de contexto persistente, retomas y deltas de estado.
Voice Agents — pipeline experimental de voz (STT → LLM → TTS) con baja latencia agregada.
Cloudflare Email Service — beta pública. Send/receive/process email nativo desde código de agentes, sin necesidad de SendGrid o SES.
Agent Memory — servicio de memoria persistente compartida entre sesiones del agente.
AI Search — primitivo de búsqueda optimizado para queries generadas por agentes, con resultados estructurados.
Browser Run — entorno de navegador headless para agentes con 4× más concurrencia que la versión anterior. Útil para web scraping, automation, testing.

De prototipo a producción:

Agent Lee — agente integrado al dashboard de Cloudflare con sandbox TypeScript para ayudar al developer mientras configura productos.
Flagship — feature flags nativos con evaluación sub-milisegundo en edge, sin necesidad de LaunchDarkly o Split.io para casos básicos.
Integración PlanetScale + Workers — bases de datos MySQL escalables consumibles desde Workers con bajo overhead.
Cloudflare Registrar API (beta) — automatización completa de compra y gestión de dominios, importante para agentes que crean infra programáticamente.

Web agéntica:

Agent Readiness Score — herramienta de evaluación que mide qué tan bien preparado está un sitio web para ser leído por agentes IA.
Redirects for AI Training — control granular sobre qué crawlers verificados pueden indexar contenido y qué redirecciones específicas reciben.
FL2 — nueva arquitectura interna que mejora rendimiento global en 60% vs configuración anterior.
Shared Dictionary Compression — compresión optimizada para tráfico repetido entre cliente y edge.
Unweight — técnica que reduce 22% la huella de modelos sin pérdida significativa de calidad, importante para hosting eficiente en Workers AI.

Cómo empezar: implementación práctica

Para un equipo que quiere empezar a usar este stack hoy, la ruta más razonable depende del caso de uso.

Caso A: Quiero darle a mi agente un computador completo donde correr código real.

// Suscribirse al plan Workers (paid). Habilitar Sandboxes en el dashboard.
// npm install @cloudflare/sandbox-sdk

import { Sandbox } from '@cloudflare/sandbox-sdk';

const sandbox = await Sandbox.create({
  image: 'ubuntu-24.04',
  cpu: 'shared',
  memory: '2GB',
  egressProxy: 'outbound-workers'
});

await sandbox.run('git clone https://artifacts.cloudflare.com/u/me/empty.git');
await sandbox.run('npm install && npm test');
const snapshot = await sandbox.snapshot('after-tests');

Caso B: Quiero que mi agente ejecute código TypeScript que él mismo escribe.

// Code Mode con Dynamic Workers
import { DynamicWorker } from '@cloudflare/dynamic-workers';

const worker = DynamicWorker.create({
  bindings: { products: env.PRODUCTS_KV }
});

const code = await env.AI.run('@openai/gpt-5.4', {
  messages: [{
    role: 'user',
    content: 'Escribí TypeScript que filtre productos por precio.'
  }]
});

const result = await worker.run(code.choices[0].message.content);

Caso C: Quiero unificar mi stack multi-modelo bajo una sola API.

// AI Platform desde Workers
const claude = await env.AI.run('@anthropic/claude-opus-4-7', { ... });
const gpt = await env.AI.run('@openai/gpt-5.4', { ... });
const llama = await env.AI.run('@meta/llama-4-90b-instruct', { ... });

Caso D: Quiero gestionar todo Cloudflare desde una sola herramienta.

npm install -g cf
cf login
cf workers list
cf sandboxes list
cf artifacts repo list
# La preview todavía no cubre 100% de la API, complementar con wrangler donde haga falta

Posicionamiento estratégico: ¿qué cambia el panorama?

El conjunto de anuncios deja a Cloudflare en una posición distinta a la del año pasado. Donde antes era una CDN con extras, ahora es una plataforma de cómputo agente edge-first, con tres ejes que explican la apuesta.

Primer eje: la economía del isolate vs el container. Si los agentes IA generan código que se ejecuta una vez y se descarta, el modelo de pricing y arquitectura de containers tradicional no escala. Un container que arranca en 500 ms y consume 100 MB es prohibitivo para 10.000 invocaciones por minuto. Un isolate que arranca en 5 ms y consume 5 MB hace ese mismo workload trivial. Cloudflare apuesta a que la ejecución agente será de muy alta concurrencia y muy baja duración, donde su arquitectura de isolates V8 nativa es estructuralmente mejor.

Segundo eje: integración con el ecosistema de modelos comerciales. La cita de Rohan Varma de OpenAI no es decorativa: indica que OpenAI está empujando a Cloudflare como sustrato preferido para correr Codex y GPT-5.4 en producción enterprise. Para Cloudflare, esto es legitimación competitiva: el hyperscaler que vende hospedaje de modelos comerciales sin requerir AWS o GCP. Para OpenAI, es diversificación de infraestructura sin construir datacenters propios.

Tercer eje: la API como producto consumible por agentes. La cf CLI con su schema TypeScript es la pieza más radical. La hipótesis es que los agentes serán el principal consumidor de las APIs de cloud computing en el futuro próximo, y que la herramienta que mejor exponga su superficie a los modelos —no a los humanos— ganará ese mercado. Cloudflare está construyendo para esa hipótesis hoy.

Lección de fondo

Hay una pregunta de gobernanza técnica detrás de Agents Week que vale la pena retener: ¿qué pasa cuando una empresa tiene la velocidad para lanzar veinte productos coordinados en una semana en una categoría que sus competidores apenas están empezando a explorar? AWS, Azure y GCP tienen ofertas equivalentes esparcidas a lo largo de doce meses de re:Invent, Build e I/O respectivamente. Cloudflare condensa el equivalente de un re:Invent en cinco días. La consecuencia operativa es que establece el vocabulario y los defaults del campo —"isolate-based agent runtime", "Git-compatible artifact storage", "unified inference platform"— mientras los competidores todavía piensan en cómo posicionarse.

La otra lección es de calado para developers. El stack agente está dejando de ser un experimento y se está convirtiendo en infraestructura tratable como cualquier otra. Sandboxes con pricing por CPU activo, Workflows con SLA de concurrencia, OAuth gestionado, observabilidad centralizada: estos son los atributos de un producto enterprise maduro, no de un demo. Para equipos que estaban esperando "a que el campo se asiente antes de invertir", el momento de evaluar es ahora —no porque los productos sean perfectos, sino porque los defaults se están definiendo y vale la pena participar de la conversación con código en mano—.

Y para quien recién empieza: el plan razonable es suscribirse al Workers paid plan, crear una cuenta, abrir un Sandbox y escribir un agente trivial de extremo a extremo. La barrera de entrada bajó esta semana significativamente.

Fuentes

Cloudflare — Agents Week 2026 in review (resumen oficial): https://blog.cloudflare.com/agents-week-in-review/
Cloudflare — Sandboxing AI agents, 100x faster (Dynamic Workers): https://blog.cloudflare.com/dynamic-workers/
Cloudflare — Agents have their own computers with Sandboxes GA: https://blog.cloudflare.com/sandbox-ga/
Cloudflare — Artifacts: versioned storage that speaks Git: https://blog.cloudflare.com/artifacts-git-for-agents-beta/
Cloudflare — AI Platform: an inference layer designed for agents: https://blog.cloudflare.com/ai-platform/
Cloudflare — Building a CLI for all of Cloudflare (cf CLI): https://blog.cloudflare.com/cf-cli-local-explorer/
Cloudflare — Press release oficial Agent Cloud (13 abril 2026): https://www.cloudflare.com/press/press-releases/2026/cloudflare-expands-its-agent-cloud-to-power-the-next-generation-of-agents/
Cloudflare — Página oficial Agents Week + updates: https://www.cloudflare.com/agents-week/
Cloudflare Sandbox SDK docs: https://developers.cloudflare.com/sandbox/
Cloudflare changelog — Artifacts beta (16 abril 2026): https://developers.cloudflare.com/changelog/post/2026-04-16-artifacts-now-in-beta/
InfoQ — Cloudflare Sandboxes Reach General Availability: https://www.infoq.com/news/2026/04/cloudflare-sandboxes-ga/
InfoWorld — Cloudflare launches Dynamic Workers for AI agent execution: https://www.infoworld.com/article/4149869/cloudflare-launches-dynamic-workers-for-ai-agent-execution.html
The Register — Cloudflare rebuilds Wrangler CLI for broader API coverage (13 abril 2026): https://www.theregister.com/2026/04/13/cloudflare_expanding_wrangler_cli_functionality/
Wikipedia — Cloudflare: https://en.wikipedia.org/wiki/Cloudflare
Wikipedia — V8 (JavaScript engine): https://en.wikipedia.org/wiki/V8_(JavaScript_engine)

pnpm 11 ya está aquí: defaults de seguridad anti-cadena de suministro, store en SQLite y por qué npm y Yarn quedan atrás

lu1tr0n — Wed, 06 May 2026 11:52:59 +0000

El 28 de abril de 2026 la fundación detrás de pnpm publicó la versión 11.0 del gestor de paquetes JavaScript que en los últimos cuatro años pasó de proyecto alternativo a opción default para una porción creciente de equipos serios. El anuncio oficial en pnpm.io/blog/releases/11.0, el release en GitHub firmado por Zoltan Kochan —mantenedor principal— y la cobertura analítica de InfoQ coinciden en que esta no es una versión menor: pnpm 11 cambia la postura de seguridad por defecto del gestor, reemplaza la arquitectura interna de la store por una base de datos SQLite, drop-ea soporte de Node.js 18-21, distribuye en ESM puro, y agrega siete comandos nuevos —entre ellos pnpm sbom para generar Software Bill of Materials en formatos CycloneDX y SPDX—.

La pieza más relevante para cualquier equipo que despliegue código JavaScript en producción es el cambio en los defaults de mitigación contra ataques a la cadena de suministro. Específicamente, minimumReleaseAge ahora vale 1.440 minutos —24 horas— por defecto, lo cual significa que pnpm 11 rehúsa instalar versiones de paquetes que se hayan publicado en las últimas 24 horas salvo que el operador relaje explícitamente la regla. La medida ataca directamente la ventana temporal en que se ejecutan los compromisos modernos del registro npm: un atacante consigue credenciales de un publisher, sube una versión maliciosa, y depende de instalaciones automáticas en CIs que se disparan en minutos. Bloquear las primeras 24 horas le da a la comunidad —investigadores como Socket, npm registry team, los propios mantenedores de paquetes— el tiempo de detectar y purgar la versión maliciosa antes de que entre a tu pipeline.

Este artículo es continuación natural de cobertura previa en este blog sobre la campaña Contagious Interview que infectó 1.700 paquetes en abril, sobre la doble ola TeamPCP/Trivy + ShinyHunters/Hashicorp del 1 de mayo, sobre el CVE-2026-3854 de GitHub que daba RCE con un git push del 30 de abril, y la onda larga del ataque a Rspack que en enero de 2025 había forzado a pnpm 10 a bloquear scripts de lifecycle por defecto. La política de defaults seguros que pnpm consolida hoy no es un capricho de ingeniería: es la respuesta acumulada del proyecto a más de un año de ataques exitosos al ecosistema. Vale la pena entenderla por dentro.

La nueva línea base: minimumReleaseAge + blockExoticSubdeps

minimumReleaseAge: bloquear las primeras 24 horas

La idea es elegantemente simple. La documentación oficial de mitigación lo explica así: cuando pnpm resuelve dependencias, descarta cualquier versión cuyo published_at sea más reciente que el umbral configurado. El valor por defecto en pnpm 11 es 1440 minutos = 1 día.

# pnpm-workspace.yaml
minimumReleaseAge: 1440          # default en pnpm 11
# minimumReleaseAge: 10080       # una semana, para infraestructura crítica
# minimumReleaseAge: 0           # opt-out global (no recomendado)

Para casos puntuales —parche de seguridad emitido por mantenedores de un paquete crítico, hotfix urgente del propio equipo— existe un escape hatch:

minimumReleaseAge: 1440
minimumReleaseAgeExclude:
  - "@my-org/*"                  # paquetes propios sin gating
  - "react"                      # un paquete específico que necesitás al instante

El razonamiento detrás del valor de 24 horas está documentado por el equipo: la mayoría de los paquetes maliciosos publicados en npm son detectados y removidos del registro en menos de un día. La ventana de exposición típica para un usuario que instala automáticamente —en CI, con npm install o pnpm install desde un container que se construye en cada push— es de minutos, no horas. Comprimir 24 horas de aire entre publicación y resolución reduce esa ventana a casi cero para la mayoría de incidentes históricos analizados.

blockExoticSubdeps: cerrar la puerta de las dependencias raras

El segundo default nuevo es blockExoticSubdeps: true. Una dependencia exótica es cualquiera que se resuelve fuera del registro estándar: un tarball remoto, un repositorio Git, un protocolo link: o file: apuntando a directorios fuera del workspace. Estas formas de declarar dependencias son legítimas en algunos workflows —monorepos con packages cruzados, forks privados— pero también son un vector clásico de ataque: los registries no las indexan ni escanean, los advisories no las cubren, y un atacante con commit access a un repositorio aparentemente inocente puede inyectar código sin que ningún sistema lo detecte.

El nuevo default rechaza esas resoluciones para subdependencias —dependencias indirectas, traídas por paquetes que vos no controlás—. Las dependencias directas de tu propio package.json siguen pudiendo declararse así, pero pnpm cortarse el camino para que un paquete de tu node_modules traiga, transitivamente, código desde un Git arbitrario.

strictDepBuilds y verifyDepsBeforeRun

Hay dos defaults adicionales que vale la pena nombrar:

strictDepBuilds: true — pnpm falla la instalación si una dependencia declara un build script y no está explícitamente permitida en allowBuilds. La opción amigable de pnpm 10, donde el script simplemente no se ejecutaba, deja el estado limpio pero no avisaba: ahora avisa.
verifyDepsBeforeRun: true — antes de ejecutar cualquier script (pnpm run, pnpm exec), pnpm verifica que node_modules esté en sincronía con pnpm-lock.yaml. Esto previene que un build corra contra una resolución antigua después de que cambiaste el lockfile pero olvidaste reinstalar.

Mini Shai-Hulud y por qué la velocidad importa

Para entender por qué pnpm endurece estos defaults conviene mirar un caso concreto reciente. El equipo de Socket ancla su análisis de pnpm 11 en una campaña que apodaron Mini Shai-Hulud: un atacante comprometió cuentas de mantenedores en npm, PyPI y Packagist simultáneamente, y publicó versiones envenenadas de paquetes con un script preinstall que descargaba un runtime de Bun ofuscado, lo ejecutaba, y exfiltraba credenciales locales —tokens de GitHub, claves SSH, archivos de ~/.aws/credentials—. El patrón es reconocible: lo vimos en Rspack, lo vimos en la campaña Contagious Interview con 1.700 paquetes infectados, lo vimos en el incidente Mini Shai-Hulud, y lo veremos otra vez.

Lo que hace particularmente efectivos a estos ataques es la combinación de tres factores:

Velocidad. La cadena de eventos —compromiso → publicación → instalación automática en CIs de víctimas— ocurre en minutos.
Escala. Un solo paquete popular puede tener millones de descargas semanales y aparecer como dependencia transitiva de paquetes que sí controlás.
Confianza implícita. Tu CI confía en npm.org, npm.org confía en el publisher, el publisher fue comprometido. La cadena de confianza no detecta la pérdida.

Las dos defensas que pnpm 11 activa por defecto —minimumReleaseAge y blockExoticSubdeps— atacan directamente el primer y tercer factor. Bloquear 24 horas inserta latencia donde antes había ninguna. Bloquear subdependencias exóticas elimina vías de cargar código sin pasar por el registry. Socket es honesto en su análisis: pnpm 11 "no habría prevenido cada parte de esta campaña" —los ataques modernos combinan múltiples técnicas—, pero las dos defensas suman un eslabón importante que antes no existía por defecto en ningún gestor mainstream de JavaScript.

El otro lado: la store reescrita en SQLite

La parte menos discutida pero técnicamente más interesante de pnpm 11 es la nueva versión del content-addressable store, llamada internamente Store v11. La store es el directorio donde pnpm guarda todos los paquetes que descargó alguna vez, deduplicados por hash, para que múltiples proyectos puedan reutilizarlos sin duplicación de disco.

Hasta pnpm 10, la store mantenía un índice como millones de archivos JSON —uno por paquete— bajo $STORE/index/. Para un usuario activo que tiene varios proyectos sobre Node.js, ese directorio puede acumular cientos de miles de archivos pequeños y la performance del sistema de archivos se vuelve un cuello de botella: cada operación de listado, cada readdir, cada lookup es un syscall.

Pnpm 11 reemplaza ese diseño con una única base de datos SQLite ubicada en $STORE/index.db. Las propiedades técnicas son notables:

Valores en MessagePack, un formato binario compacto y rápido de deserializar.
WAL mode (Write-Ahead Logging) para permitir lecturas concurrentes sin bloquear escrituras.
Manifests bundled en el índice: name, version, bin, engines, scripts se guardan directamente en la base, eliminando la necesidad de leer package.json desde la CAS durante la resolución.
Hex digests en lugar de strings de integridad completos del estilo <algo>-<digest>, con el algoritmo de hash registrado una sola vez por archivo en lugar de por entrada. Esto evita conversiones base64→hex en cada lookup de path en la CAS.

A nivel de instalación en frío, los desarrolladores reportan reducciones significativas. El cambio elimina aproximadamente 30.000 syscalls de rename por instalación en frío gracias a escritura directa al CAS, usa el cliente HTTP undici —el mismo que usa Node.js internamente— y pre-aloca memoria para descargas de tamaño conocido. La instalación de un runtime de Node.js además ya no extrae los binarios de npm, npx y corepack por defecto, cortando aproximadamente la mitad de los archivos que pnpm tenía que hashear, escribir a la CAS y enlazar.

Lo que rompe: migración desde pnpm 10

pnpm 11 no es un upgrade transparente. Estos son los breaking changes que un equipo necesita planificar antes de actualizar.

Versión de Node.js

# Verificar tu versión actual
node --version

# pnpm 11 requiere Node 22 o superior
# Si estás en 18, 19, 20 o 21, primero actualizá Node
nvm install 22
nvm use 22

Para distribuciones que aún empaquetan Node 20 o 18 LTS, esto puede requerir cambiar a un repositorio externo (NodeSource, devsnek/node) o usar un volume manager como fnm, nvm o el propio pnpm runtime set —que ahora también gestiona instalaciones de Node—.

Configuración: .npmrc ya no es para pnpm

Hasta pnpm 10, configuraciones específicas de pnpm como auto-install-peers o prefer-frozen-lockfile se podían declarar en .npmrc. En pnpm 11, .npmrc queda restringido a auth y registry settings. Cualquier configuración propia de pnpm debe vivir en uno de:

# pnpm-workspace.yaml (configuración por workspace)
packages:
  - "packages/*"
auto-install-peers: true
prefer-frozen-lockfile: true
minimumReleaseAge: 1440

# ~/.config/pnpm/config.yaml (configuración global)
storeDir: /var/cache/pnpm
verifyStoreIntegrity: true

Las variables de entorno también cambian de prefijo: npm_config_* ya no funciona; ahora es pnpm_config_*. Esto rompe scripts de CI que pasaban configuración inline con npm_config_registry=https://....

allowBuilds reemplaza cinco settings legacy

Cinco campos distintos que controlaban qué scripts de lifecycle se permitían se unificaron en un solo allowBuilds:

# Antes (pnpm 10)
onlyBuiltDependencies: ["esbuild", "sharp"]
neverBuiltDependencies: ["puppeteer"]
ignoredBuiltDependencies: ["@playwright/test"]
ignoreDepScripts: false
onlyBuiltDependenciesFile: "./trusted.json"

# Ahora (pnpm 11)
allowBuilds:
  - esbuild
  - sharp
  - "!puppeteer"          # explícitamente bloqueado
  - "!@playwright/test"

La consolidación es lógica pero exige rescribir la configuración existente.

Audit migrado a GHSA

auditConfig.ignoreCves se renombró a auditConfig.ignoreGhsas. La razón: GitHub Security Advisories (GHSA) tienen identificadores más estables y mejor cobertura para el ecosistema npm que los CVEs tradicionales. La migración es directa, pero hay que pasar por todos los lockfiles del workspace.

Distribución pure ESM

pnpm 11 ya no embarca un build CommonJS. Si en algún script tenés algo como:

const pnpm = require("pnpm");

falla en pnpm 11. Hay que migrar a import o usar un dynamic import:

const pnpm = await import("pnpm");

Para uso normal en línea de comandos, esto no afecta —solo afecta integraciones programáticas—.

Comandos nuevos que vale la pena conocer

pnpm 11 agrega una colección de comandos que reflejan dónde el proyecto piensa que está la frontera de utilidad:

pnpm ci (alias clean-install, ic, install-clean) — equivalente al npm ci clásico. Borra node_modules, instala desde el lockfile congelado, falla si el lockfile no está en sincronía. Usable en CI sin sorpresas.
pnpm clean — borra node_modules en todo el workspace. Con --lockfile también borra los lockfiles si querés un reset total.
pnpm sbom — genera un Software Bill of Materials en formato CycloneDX 1.7 o SPDX 2.3. Esto pasó de ser un nice-to-have a un requerimiento regulatorio en muchos sectores —compliance gubernamental, supply chain audits—. Tener el comando incorporado al gestor evita la dependencia de tools externas como syft o cdxgen.
pnpm peers check — valida que todas las peer dependencies declaradas estén satisfechas. Hasta ahora era un dolor de cabeza típico que terminaba en runtime; ahora se chequea explícitamente.
pnpm runtime set — instala una versión específica de Node.js como runtime para el workspace. Por primera vez, pnpm gestiona el toolchain completo, no solo los paquetes.
pnpm with — ejecuta un comando con una versión específica de pnpm en una sola invocación, útil para troubleshooting de migraciones.
pnpm pack-app — empaqueta una aplicación Node.js como Single Executable Application (la API SEA agregada en Node.js reciente), produciendo un binario standalone. Este comando solo es ergonomía, no magia: el upstream de Node se hace cargo del verdadero trabajo.
Aliases pn → pnpm y pnx → pnpm dlx. Para gente que escribe pnpm cien veces al día, dos teclas menos por comando es un cambio real.

La pregunta operativa: ¿npm y Yarn van a seguir el camino?

A marzo de 2026, ni npm ni Yarn bloquean por defecto los lifecycle scripts ni implementan algo equivalente al minimumReleaseAge. La asimetría es importante porque significa que un equipo que usa npm o Yarn como gestor primario no tiene esta línea de defensa, salvo que la configure manualmente —cosa que la mayoría no hace, porque las defaults siguen siendo seguir el comportamiento histórico—.

El argumento del equipo de pnpm, articulado en su post de diciembre de 2025 sobre cómo protegieron su propio newsroom, es que los defaults son la línea de defensa real. Una configuración avanzada que el 90% de los usuarios no aplica no protege al 90%. Un default seguro sí. La objeción del campo opuesto es que defaults agresivos rompen workflows establecidos —y de hecho minimumReleaseAge rompe pnpm install cuando un mantenedor publica una versión legítima que tu equipo necesita ya—.

El balance final dependerá de cómo evolucione el panorama de ataques. Si los próximos seis meses traen otra campaña al estilo Mini Shai-Hulud o Contagious Interview, la presión sobre npm y Yarn para seguir el camino se vuelve casi imposible de resistir. Si los ataques se desplazan hacia otros vectores —tokens robados, compromiso de CI/CD, dependencias firmadas pero pre-comprometidas— las defensas de pnpm 11 quedan como una capa más en una defensa por capas, no como la solución definitiva.

Cómo actualizar

Para usuarios que ya tienen pnpm instalado:

# Self-update si tenés pnpm 10.x instalado
pnpm self-update next-11

# O instalación limpia desde npm (si aún no tenés Node 22)
nvm install 22
nvm use 22
npm install -g pnpm@latest

# Verificar
pnpm --version
# 11.0.0 (o superior)

Para CI: actualizar la imagen base a una con Node 22+, actualizar las versiones especificadas en packageManager field del package.json raíz, y revisar que el lockfile se regenere correctamente:

{
  "packageManager": "pnpm@11.0.0"
}

Si tu organización maneja varios proyectos, el patrón conservador es probar pnpm 11 en uno solo durante una semana, especialmente con los nuevos defaults activos, y validar que los pipelines de CI no se rompan por el verifyDepsBeforeRun o el strictDepBuilds. Luego propagar al resto.

Lección de fondo

Hay una pregunta más amplia detrás de esta release que vale la pena retener. ¿Quién es responsable de la seguridad de la cadena de suministro en software open source? Durante años la respuesta implícita fue: el desarrollador individual que mantiene el lockfile. Lo cual era una abstracción cómoda pero falsa. Un proyecto típico de 2026 tiene cientos de dependencias directas y miles transitivas; auditar cada actualización es trabajo de tiempo completo.

pnpm 11 propone un modelo diferente: la seguridad razonable debe estar embebida en el gestor, no como configuración opcional sino como default. La filosofía es paralela a lo que pasó con HTTPS: durante años fue opt-in y la mayoría de los sitios lo dejaba off; cuando los browsers empezaron a marcar HTTP como inseguro y los deployment platforms a hacer HTTPS automático, la situación cambió. Lo que no se hace por defecto, no se hace en escala.

La otra lección es de cadencia política. pnpm es un proyecto open source mantenido por un puñado de personas; sin embargo, ha movido la frontera del comportamiento por defecto del ecosistema npm más que cualquier discusión en TC39 o cualquier RFC del registry. El cambio incremental por defaults agresivos ha resultado más efectivo que la reforma centralizada. Para quien está construyendo herramientas, ese es un patrón a estudiar: no esperes consenso, ofrecé una alternativa con defaults sustancialmente mejores y dejá que la migración hable.

Y para quien usa pnpm hoy: upgrade.

Fuentes

pnpm 11.0 — anuncio oficial: https://pnpm.io/blog/releases/11.0
pnpm v11.0.0 — release en GitHub: https://github.com/pnpm/pnpm/releases/tag/v11.0.0
pnpm — Mitigating Supply Chain Attacks (documentación oficial): https://pnpm.io/supply-chain-security
pnpm — How We're Protecting Our Newsroom from npm Supply Chain Attacks (5 dic 2025): https://pnpm.io/blog/2025/12/05/newsroom-npm-supply-chain-security
pnpm — CHANGELOG.md (changelog técnico completo): https://github.com/pnpm/pnpm/blob/main/pnpm/CHANGELOG.md
InfoQ — pnpm 11 Release Candidate: ESM Distribution, Supply Chain Defaults and a New Store Format (Daniel Curtis, abril 2026): https://www.infoq.com/news/2026/04/pnpm-11-rc-release/
Socket — pnpm 11 Adds New Supply Chain Protection Defaults: https://socket.dev/blog/pnpm-11-adds-new-supply-chain-protection-defaults
Socket — pnpm 10.0.0 Blocks Lifecycle Scripts by Default: https://socket.dev/blog/pnpm-10-0-0-blocks-lifecycle-scripts-by-default
Wikipedia — pnpm: https://en.wikipedia.org/wiki/Pnpm
Wikipedia — npm: https://en.wikipedia.org/wiki/Npm
Wikipedia — Supply chain attack: https://en.wikipedia.org/wiki/Supply_chain_attack
Node.js — sitio oficial: https://nodejs.org/

Stripe Projects + Cloudflare: agentes IA crean cuentas y compran dominios solos

lu1tr0n — Wed, 06 May 2026 08:16:35 +0000

El 30 de abril de 2026, Cloudflare y Stripe anunciaron una integración que cambia las reglas de cómo los agentes de IA interactúan con la infraestructura cloud. La iniciativa, llamada Stripe Projects + Cloudflare, permite que un agente —sin intervención humana más allá del consentimiento inicial— cree una cuenta de Cloudflare, contrate una suscripción de pago, registre un dominio y obtenga un API token listo para desplegar código a producción.

Hasta ahora, cuando un agente de codificación quería publicar una aplicación, había tres pasos que solo un humano podía completar: abrir una cuenta en el proveedor cloud, configurar un método de pago y generar un API token. Eran fricciones inevitables. La nueva colaboración entre Cloudflare y Stripe elimina esos cuellos de botella mediante un protocolo abierto co-diseñado por ambas empresas, que combina estándares ya existentes (OAuth, OIDC y tokenización de pagos) en un flujo unificado para máquinas. Cualquier plataforma con usuarios autenticados podrá integrarse de la misma manera que lo hace Stripe.

Qué pasó: el lanzamiento de Stripe Projects

El anuncio fue publicado por Sid Chatterjee y Brendan Irvine-Broque en el blog de Cloudflare. La pieza central es un nuevo plugin del CLI de Stripe llamado stripe projects, que sirve como puente entre el agente, la identidad del usuario en Stripe y los proveedores cloud disponibles —empezando por Cloudflare como socio de lanzamiento.

El flujo es radicalmente más corto que cualquier setup tradicional:

# Instalación del CLI con el plugin Stripe Projects
# macOS
brew install stripe/stripe-cli/stripe
stripe plugins install projects

# Linux
curl -fsSL https://cli.stripe.com/install.sh | sh
stripe plugins install projects

# Windows (PowerShell)
scoop install stripe
stripe plugins install projects

# Login y arranque del proyecto
stripe login
stripe projects init

A partir de ese momento, el agente puede preguntarle a Stripe qué servicios cloud están disponibles, escogerlos por sí mismo, aprovisionarlos en una cuenta nueva o existente, y desplegar código sin que el usuario abra un solo dashboard. La promesa se resume en una sola frase de la documentación: «de cero a producción sin pasos manuales».

Las tres piezas del protocolo

La integración entre Stripe Projects y Cloudflare se apoya en tres mecanismos que funcionan como un único contrato de máquina a máquina:

Descubrimiento — El agente ejecuta stripe projects catalog y recibe un JSON con todos los servicios disponibles (registrar dominios, Workers, R2, KV, D1, etc.). Es la primera vez que un catálogo de productos cloud se expone en formato pensado para LLMs.- Autorización — Stripe actúa como Identity Provider (IdP). Si el correo del usuario ya tiene cuenta en Cloudflare, se inicia un flujo OAuth estándar. Si no existe, Cloudflare crea automáticamente una cuenta nueva y devuelve credenciales firmadas al CLI.- Pago — Stripe entrega un payment token con el que los proveedores pueden cobrar suscripciones, compras únicas o consumo por uso, sin que el agente vea jamás los datos de la tarjeta. El protocolo une OAuth, OIDC y tokenización en un flujo de tres pasos. ## Contexto e historia: por qué esto importa ahora

La pregunta obligada es por qué este anuncio aparece en abril de 2026 y no antes. La respuesta tiene tres capas: madurez del ecosistema MCP, presión competitiva entre clouds y la economía emergente de los agentes autónomos.

El protocolo MCP cambió las reglas en 2025

Durante 2025, el Model Context Protocol (MCP) impulsado por Anthropic se consolidó como el estándar de facto para conectar modelos de lenguaje a herramientas externas. Cloudflare fue uno de los early adopters más agresivos: lanzó su Code Mode MCP server y los Agent Skills, paquetes de instrucciones que permiten a un agente entender cómo desplegar Workers, manejar Durable Objects o configurar R2 sin tener que aprender a leer la documentación humana.

El cuello de botella, sin embargo, seguía siendo el momento de la verdad: el agente sabía construir, sabía desplegar, pero no podía contratar. Cada nueva aplicación creada por un agente exigía que el usuario interrumpiera el flujo, fuera al dashboard, generara un token, lo copiara y lo pegara. La fricción mataba la experiencia y limitaba el potencial de los autonomous coding agents.

La carrera por ser el cloud-de-elección de los agentes

Cloudflare no está solo en esta apuesta. Vercel, Netlify, Render, Fly.io y Railway llevan meses optimizando sus APIs y onboarding pensando en agentes. AWS lanzó hace unos meses su propio set de tools MCP, y Google Cloud está experimentando con flujos similares vía Genkit. Lo que diferencia a la jugada de Cloudflare-Stripe es que el protocolo se publica como abierto: cualquier proveedor cloud puede integrarse del mismo lado que Cloudflare, y cualquier plataforma con usuarios autenticados puede actuar como Stripe (es decir, como IdP + procesador de pagos).

💭 Clave: Stripe Projects no es un producto cerrado de Cloudflare. Es una capa de protocolo. Quien controle la capa de identidad y pagos para agentes —Stripe, en este caso— tendrá una posición estructural similar a la que Visa tiene en el comercio físico.

Datos y cifras del lanzamiento

El anuncio vino acompañado de una serie de cifras y compromisos concretos que vale la pena desglosar para entender la dimensión real del movimiento:

USD 100.000 en créditos de Cloudflare para cualquier startup nueva que se incorpore vía Stripe Atlas, el producto de Stripe para constituir una empresa en Delaware desde cualquier país del mundo.- 6 minutos de lectura es la longitud del post original, pero esconde un cambio arquitectónico mucho más grande: un agente pasa de cero a producción en aproximadamente 2 minutos de video demo.- Cero pasos manuales entre el prompt inicial y el despliegue, salvo dos confirmaciones: aceptación de términos de servicio de Cloudflare y, si aplica, agregar un método de pago al Stripe del usuario.- Múltiples productos Cloudflare disponibles en el catálogo desde el día uno: Workers, Pages, R2, D1, KV, Durable Objects, Cloudflare Registrar, además de servicios de terceros que Stripe agregará en los próximos meses.

Para LATAM hay un dato adicional importante: Stripe Atlas es uno de los caminos más directos para que un emprendedor centroamericano o sudamericano constituya una entidad legal en Estados Unidos sin viajar. Combinado con USD 100.000 en créditos cloud, baja brutalmente la barrera de entrada para startups regionales que quieran lanzar productos serverless globales.

Impacto y análisis: qué cambia para desarrolladores y plataformas

El cambio más visible es para quien hoy trabaja con agentes de codificación tipo Claude Code, Cursor Background Agents, Devin, Aider o cualquier flujo CI/CD donde una IA genera infra como código. Pero hay tres consecuencias estructurales que vale la pena analizar.

1. Los agentes pasan de constructores a operadores

Hasta ahora, los agentes eran muy buenos generando código y subiéndolo a un repositorio. La operación en producción seguía siendo humana: comprar el dominio, configurar DNS, contratar el plan, monitorear la facturación. Con Stripe Projects, los agentes pueden ejercer el rol completo de un equipo de DevOps en miniatura. Eso obliga a repensar permisos, auditoría y límites de gasto.

⚠️ Ojo: Si tu agente puede registrar dominios y contratar suscripciones, también puede equivocarse y registrar 50 dominios. La documentación de Stripe Projects insiste en que los spending limits y los scope-restricted tokens son responsabilidad del integrador. Configurálos antes del primer stripe projects init.

2. La identidad se vuelve la nueva base de la nube

El diseño donde Stripe atestigua la identidad y Cloudflare confía en esa atestación recuerda a cómo Apple y Google funcionan en mobile: un IdP central que firma todo. Si el modelo se generaliza, las plataformas que hoy compiten por ser la nube empezarán a competir por ser la identidad de los agentes. GitHub, Microsoft, Google y los propios proveedores de modelos (Anthropic, OpenAI) son los candidatos obvios para el siguiente movimiento.

3. Aparece un nuevo vector de ataque

Si un agente compromete una sesión de Stripe, ahora puede aprovisionar infraestructura cloud y cobrar a la tarjeta del usuario. Esto no es teórico: a lo largo de 2025 vimos varios incidentes con MCP servers maliciosos que filtraban credenciales. Las buenas prácticas que ya conocemos —scopes mínimos, expiración corta, rotación, alertas de uso anómalo— ahora se vuelven obligatorias para quien integre Stripe Projects en producción.
El agente provisiona cuenta, dominio y token sin abrir un solo dashboard.

El flujo end-to-end visualizado

sequenceDiagram
    participant U as Usuario
    participant A as Agente IA
    participant S as Stripe Projects
    participant C as Cloudflare
    U->>A: "Construí y desplegá esta app"
    A->>S: stripe projects catalog
    S-->>A: "lista de servicios disponibles"
    A->>S: stripe projects add cloudflare/registrar:domain
    S->>C: solicita aprovisionamiento
    C->>S: cuenta nueva + API token
    S-->>A: credenciales seguras
    A->>C: deploy del código
    C-->>U: app en producción

Qué sigue: hoja de ruta y consecuencias

El anuncio del 30 de abril es el primer paso de una agenda más larga. Cloudflare y Stripe han adelantado tres líneas de trabajo para los próximos meses:

Más proveedores en el catálogo — Stripe Projects está abierto para que cualquier proveedor cloud o servicio (bases de datos, observabilidad, CDNs alternativos) se sume al catálogo expuesto a los agentes.- Más plataformas como IdP — La capa de identidad podría ser ofrecida por GitHub, Vercel, Linear o cualquier producto SaaS con base de usuarios. Esto democratiza la posibilidad de que un agente actúe en nombre del usuario en cualquier ecosistema.- Integración nativa en Code Mode y Agent Skills — Cloudflare ya está actualizando sus Skills para que los agentes sepan, sin instrucciones adicionales, cuándo usar Stripe Projects para autoaprovisionarse.

💡 Tip: Si estás construyendo un agente o producto que quiere desplegar a Cloudflare, no esperes la integración manual. Hoy mismo podés ejecutar stripe plugins install projects && stripe projects init y experimentar el flujo completo en menos de 10 minutos. La curva de adopción de este tipo de protocolos suele ser muy rápida cuando el primer mover (Stripe + Cloudflare) define el estándar.

Implicaciones para LATAM

Para el ecosistema hispano hay dos lecturas. La primera es operativa: cualquier desarrollador de LATAM con cuenta de Stripe puede empezar a usar Stripe Projects sin trámites adicionales. La segunda es más estratégica: el modelo plataforma + identidad + pagos abre un espacio para que actores regionales —Mercado Pago, Ualá Bis, Kushki, Conekta, dLocal— consideren seriamente convertirse en IdPs para agentes. La oportunidad no es competir contra Stripe globalmente; es ofrecer la misma capa de protocolo para flujos de pago locales (PIX, SPEI, transferencias 3.0) que las plataformas globales no manejan bien.

La carrera por ser la identidad de los agentes en LATAM está abierta. Y a juzgar por la velocidad con la que Stripe se posicionó como el primer IdP global de agentes, la ventana para responder no será larga.

📖 Resumen en Telegram: Ver resumen

Preguntas frecuentes

¿Necesito ya tener cuenta en Cloudflare para usar Stripe Projects?

No. Si el correo con el que iniciás sesión en Stripe no tiene cuenta de Cloudflare, el sistema crea una nueva automáticamente. Si ya existe una cuenta vinculada a ese correo, se dispara un flujo OAuth estándar para autorizar al agente.

¿Cuánto cuesta usar Stripe Projects?

El protocolo en sí no tiene costo adicional. Pagás los servicios cloud que tu agente contrate (dominios, suscripciones de Workers, etc.) y las comisiones normales de Stripe por procesar los pagos. La promoción de USD 100.000 en créditos Cloudflare aplica solo a startups nuevas constituidas vía Stripe Atlas.

¿Qué pasa si el agente se equivoca y compra cosas que no debe?

El control queda en el integrador del agente. Stripe permite definir límites de gasto, scopes restringidos y métodos de pago dedicados. Cloudflare exige aceptación humana de los términos de servicio y notifica al usuario cuando se aprovisionan recursos. Aún así, conviene configurar alertas de facturación y revisar los permisos antes de soltar al agente.

¿Stripe Projects funciona solo con Cloudflare?

Cloudflare es el primer proveedor cloud integrado, pero el protocolo es abierto. Stripe ya anunció que más proveedores se sumarán al catálogo en los próximos meses. Cualquier plataforma cloud puede implementar el lado proveedor del protocolo y aparecer en stripe projects catalog.

¿Cómo se compara con MCP?

Son complementarios. MCP define cómo un modelo habla con herramientas externas. Stripe Projects define cómo se aprovisionan cuentas, identidades y pagos para que esas herramientas existan. Cloudflare combina ambos: usa Code Mode MCP para que el agente sepa qué hacer, y Stripe Projects para que tenga dónde hacerlo.
¿Es seguro dejar que un agente compre dominios en mi nombre?</h3
Es tan seguro como la configuración que le pongas. El protocolo usa OAuth, OIDC y tokenización de pagos —los mismos estándares que protegen las apps que ya usás todos los días. La buena práctica es: scopes mínimos, tokens de corta duración, alertas activas y un límite de gasto explícito.

Referencias

Cloudflare Blog: Agents can now create Cloudflare accounts, buy domains, and deploy — Anuncio original de Sid Chatterjee y Brendan Irvine-Broque (30 de abril de 2026).- Stripe Atlas — Producto de Stripe para constituir una empresa en Delaware desde cualquier país.- Model Context Protocol — Especificación abierta de MCP usada por Cloudflare en su Code Mode server.- Cloudflare Developer Docs — Documentación oficial de Workers, R2, D1 y demás servicios incluidos en el catálogo.- OAuth 2.0 — Estándar de autorización en el que se apoya el flujo de Stripe Projects.

DNSSEC Debugger de Verisign: cómo auditar tu cadena de confianza DNS

lu1tr0n — Wed, 06 May 2026 02:19:20 +0000

El sistema de nombres de dominio (DNS) traduce nombres legibles como programacion.org en direcciones IP, pero su diseño original de 1983 no incluyó autenticación criptográfica. Cualquiera con la posición de red adecuada podía suplantar respuestas y redirigir tráfico hacia servidores controlados por un atacante. DNSSEC (Domain Name System Security Extensions) es la respuesta de la IETF a ese problema: firma digitalmente cada conjunto de registros para que el resolvedor pueda verificar que la respuesta no fue alterada en tránsito. Verisign Labs mantiene desde hace más de una década un DNSSEC Debugger gratuito y público que recorre la cadena de confianza de cualquier dominio y muestra exactamente en qué eslabón se rompe la validación, una capacidad indispensable para cualquier equipo de infraestructura que opere zonas firmadas en 2026.

Qué es el DNSSEC Debugger de Verisign Labs

El DNSSEC Debugger vive en dnssec-analyzer.verisignlabs.com y funciona como un validador stateless: introduces un dominio, la aplicación consulta los servidores autoritativos, descarga los registros relevantes —DNSKEY, RRSIG, DS, NSEC o NSEC3— y verifica cada firma criptográfica desde la raíz hasta la zona consultada. El resultado se muestra como una lista de comprobaciones marcadas con check verde cuando todo cuadra, o con cruces rojas y mensajes específicos cuando algo está roto.

La herramienta soporta dos opciones avanzadas que la diferencian de validadores más simples. La primera es Trust Anchor: se puede pegar un registro DS o DNSKEY arbitrario para iniciar la validación desde cualquier punto de la jerarquía, no necesariamente desde la raíz. Esto resulta clave cuando una organización opera una zona privada con su propia ancla de confianza, o cuando se necesita auditar una zona antes de que el padre publique el DS correspondiente. La segunda permite especificar servidores autoritativos alternativos, útil para verificar comportamientos en servidores secundarios, validar una zona alojada en un proveedor distinto al productivo, o confirmar la consistencia entre primario y secundarios tras un cambio.

A diferencia de un dig +dnssec puntual, el Debugger explica cada paso en lenguaje natural: indica qué registros DS publicó la zona padre, qué DNSKEY hashea contra ese DS, qué RRSIG firma cada conjunto, cuándo expiran las firmas y si el algoritmo (RSASHA256, ECDSAP256SHA256, ED25519) es soportado por validadores modernos. Para equipos que recién adoptan DNSSEC, esa narrativa pedagógica vale más que cualquier dump técnico.
El Debugger recorre cada eslabón de la cadena y reporta éxitos y fallos.

La cadena de confianza DNSSEC explicada

DNSSEC añade cuatro tipos de registros al DNS tradicional. DNSKEY publica las claves públicas que firman la zona; típicamente hay dos roles diferenciados: KSK (Key Signing Key) que firma DNSKEY, y ZSK (Zone Signing Key) que firma el resto de los registros. RRSIG contiene la firma criptográfica de un conjunto de registros (RRset) usando una de esas claves. DS (Delegation Signer) es un hash del DNSKEY de la zona hija publicado en la zona padre, y constituye el puente que une dos zonas. Finalmente NSEC y NSEC3 prueban la inexistencia de un nombre o tipo de registro de forma firmada, evitando que un atacante diga falsamente que un registro no existe.

La cadena de confianza fluye desde la raíz hacia abajo. La IANA mantiene la KSK de la raíz, conocida como ancla de confianza global y preinstalada en todos los validadores. El resolvedor empieza con esa clave, valida los DNSKEY de la raíz, busca el DS para .com, valida el DNSKEY de .com, busca el DS para ejemplo.com, y así sucesivamente hasta verificar la firma sobre el registro A o AAAA solicitado.

graph TD
    A["Raíz . (KSK IANA)"] --> B["DS para com"]
    B --> C["com (DNSKEY firmado)"]
    C --> D["DS para ejemplo.com"]
    D --> E["ejemplo.com (DNSKEY firmado)"]
    E --> F["RRSIG sobre A/AAAA"]
    F --> G["Respuesta validada"]

Cualquier eslabón mal alineado rompe toda la cadena para esa rama. Si el registro DS publicado en .com no coincide con el DNSKEY actual de la zona —algo común tras una rotación de claves mal coordinada con el registrar—, el resolvedor responderá SERVFAIL y el dominio quedará inaccesible para todos los validadores estrictos. El navegador del usuario simplemente verá un error genérico de DNS, sin pista alguna del origen del fallo.

⚠️ Ojo: firmar una zona y olvidarse de monitorear las firmas es peor que no firmarla. Las RRSIG expiran cada 7 a 30 días; si tu firmador automático se cae un fin de semana largo, tu dominio desaparece para validadores estrictos.

Historia y adopción de DNSSEC

DNSSEC fue estandarizado en marzo de 2005 con los RFC 4033, 4034 y 4035, y la raíz se firmó en 2010 después de años de coordinación entre ICANN, Verisign y los operadores de raíz. El registro .com, el TLD más grande del mundo y operado por Verisign, fue firmado en 2011, lo que abrió la puerta a la adopción masiva entre empresas comerciales.

La adopción real, sin embargo, ha sido lenta. Según las mediciones públicas de APNIC Labs, alrededor de un tercio de los usuarios de internet a nivel mundial usan resolvedores con validación DNSSEC habilitada (Cloudflare 1.1.1.1, Google Public DNS 8.8.8.8, OpenDNS, ISPs europeos). Pero del lado de los dominios firmados, solo TLDs muy específicos como los de República Checa, Suecia o Países Bajos superan el 50% de su zona firmada. .com, .net y la mayoría de ccTLDs latinoamericanos siguen por debajo del 5% de zonas firmadas.

En América Latina la situación es heterogénea. NIC.br habilitó DNSSEC para .br en 2010 y mantiene un programa activo de promoción y capacitación. NIC.mx, NIC.ar, NIC.cl y NIC.co soportan la publicación de registros DS, pero la adopción entre registrantes finales es marginal. Esto significa que la mayoría de los dominios LATAM firmados pertenecen a organismos públicos, instituciones académicas y operadores de infraestructura crítica como bancos centrales, mientras que el comercio electrónico y el SaaS regional rara vez activan DNSSEC.

Auditando una zona DNSSEC desde la línea de comandos

El DNSSEC Debugger es excelente para una auditoría puntual desde el navegador, pero quienes operan zonas a escala suelen integrar verificaciones en pipelines de monitoreo. Las herramientas tradicionales de DNS soportan validación DNSSEC desde hace años y permiten automatizar alertas mucho antes de que un usuario reporte el problema.

En Linux y macOS, dig con +dnssec muestra los registros RRSIG y el flag ad (Authenticated Data) cuando el resolvedor validó la respuesta:

# Linux (Debian/Ubuntu) y macOS
dig +dnssec +multi programacion.org

# Verificar contra un resolvedor específico que valide
dig @1.1.1.1 +dnssec +multi programacion.org

El comando delv (Domain Entity Lookup & Validation), parte del paquete bind9-utils, ejecuta una validación completa desde la raíz e imprime el árbol de evidencia, lo que lo convierte en el equivalente de línea de comandos del Debugger de Verisign:

# Linux (Debian/Ubuntu)
sudo apt install bind9-dnsutils
delv +rtrace programacion.org

# macOS con Homebrew
brew install bind
delv +rtrace programacion.org

En Windows 10 y posteriores, PowerShell ofrece Resolve-DnsName con el flag -DnssecOk:

Resolve-DnsName -Name programacion.org -Type A -DnssecOk -Server 1.1.1.1

Para automatizar la verificación en CI/CD se puede combinar dig con grep y reportar a Prometheus, Datadog o el sistema de observabilidad interno cuando el flag ad no aparece o cuando la firma expira en menos de siete días. La librería getdns permite consultar y validar desde código C, mientras que en Python dnspython 2.x soporta validación nativa, ideal para scripts de monitoreo internos.
delv +rtrace imprime cada paso de validación criptográfica desde la raíz.

Errores comunes que el DNSSEC Debugger detecta

Después de operar zonas firmadas durante años, los equipos de infraestructura coinciden en cinco categorías de fallo recurrente que el DNSSEC Debugger señala con claridad y que conviene tener presentes a la hora de diseñar runbooks y alertas:

DS desactualizado: el padre publica un DS que no corresponde al DNSKEY actual. Suele ocurrir tras rotación de KSK sin actualizar el registrar.- Firma expirada: las RRSIG tienen ventana de validez típica de 7 a 30 días. Si el firmador automático falla, las firmas expiran y la zona se vuelve no validable sin previo aviso.- Algoritmo no soportado o débil: usar SHA-1 o RSASHA1 en 2026 produce advertencias de seguridad en validadores modernos. La recomendación actual es ECDSAP256SHA256 o Ed25519.- NSEC3 mal configurado: el parámetro iterations debe ser bajo. RFC 9276 recomienda 0 iteraciones; valores altos son rechazados por algunos resolvedores como abuso de recursos.- Glue records sin firmar para servidores in-bailiwick: cuando los NS de la zona viven dentro de la propia zona, los registros A/AAAA del padre deben coincidir con los de la zona firmada o la cadena se rompe.

💡 Tip: programá una alerta en tu sistema de monitoreo que dispare cuando cualquier RRSIG de tu zona tenga menos de 7 días para expirar. Es la única señal que te avisa con tiempo de un firmador caído antes de que afecte al usuario final.

Qué sigue para DNSSEC en 2026

Tres movimientos están moldeando el futuro de DNSSEC. El primero es la transición a Ed25519 definida en RFC 8080, un algoritmo de curva elíptica que produce firmas más cortas que ECDSA y consume menos CPU al validar. La raíz aún usa RSASHA256, pero un creciente número de TLDs y zonas grandes ya migraron, reduciendo el tamaño de las respuestas DNS y aliviando la presión sobre el límite de fragmentación UDP.

El segundo es la estandarización de NSEC3 con iteraciones cero, formalizada en RFC 9276 publicado en 2022, que neutraliza el ataque de amplificación de CPU sin perder la prueba de inexistencia firmada. Los grandes resolvedores ya rechazan zonas con iterations excesivas, así que conviene revisar tu firmador.

El tercero, todavía en discusión activa en la IETF, es la transición a algoritmos post-cuánticos. Las firmas DNSSEC actuales son vulnerables a un atacante con computador cuántico capaz de romper RSA y curvas elípticas, y el grupo de trabajo dnsop trabaja desde 2024 en perfiles experimentales con SLH-DSA (Sphincs+) y ML-DSA (Dilithium). El reto técnico es que las firmas post-cuánticas son entre 5 y 50 veces más grandes que las actuales, lo que satura el límite tradicional de 4 KB de UDP y empuja al ecosistema hacia DNS sobre TCP, TLS o QUIC como transporte por defecto.

💭 Clave: la migración a DNSSEC post-cuántico no es solo cambiar un algoritmo. Implica revisar el transporte (UDP vs TCP/TLS), el tamaño de paquete y el rendimiento del firmador. Los equipos prudentes ya están ejercitando sus pipelines con firmas grandes para descubrir cuellos de botella.

📖 Resumen en Telegram: Ver resumen

Preguntas frecuentes

¿Necesito DNSSEC si ya uso HTTPS en todo mi sitio?

HTTPS protege la conexión después de que el navegador resuelve el dominio, pero un atacante que envenene el caché DNS puede dirigirte a una IP completamente distinta antes de que se inicie el handshake TLS. DNSSEC valida la propia resolución; las dos capas son complementarias, no redundantes.

¿El DNSSEC Debugger de Verisign es gratis para uso comercial?

Sí. Verisign Labs lo ofrece como servicio público sin autenticación ni cuotas explícitas. No publica un SLA formal, pero la herramienta lleva más de una década operativa de forma estable y es la referencia informal de toda la comunidad de operadores DNS.

¿Mi proveedor DNS soporta DNSSEC?

Cloudflare, Route 53, Google Cloud DNS, Azure DNS, NS1 y la mayoría de proveedores empresariales soportan firmado automático con un solo clic. Algunos hosting compartido económicos no lo ofrecen; verificá antes de migrar tu zona crítica.

¿Qué pasa si firmé mi zona pero no publiqué el DS en el padre?

La zona aparece como insegura para validadores: las respuestas se aceptan pero sin validación criptográfica. No rompe el sitio, pero anula completamente el beneficio de seguridad. El DS en el padre es lo que ancla tu firma a la cadena global.

¿Cuántas veces al año debo rotar las claves DNSSEC?

Las recomendaciones varían según el operador. La práctica común es rotar la ZSK cada 1 a 3 meses (proceso automatizado por el firmador) y la KSK cada 1 a 2 años (proceso manual que requiere actualizar el DS en el padre vía registrar). Algunos operadores grandes ya practican rotación continua.

¿Qué hago si mi dominio falla en el Debugger pero parece funcionar en mi navegador?

Significa que tu resolvedor local no valida y devuelve la respuesta, mientras que resolvedores estrictos como 1.1.1.1 responderán SERVFAIL. Es solo cuestión de tiempo hasta que más usuarios pierdan acceso. Hay que arreglar la cadena cuanto antes en lugar de esperar a que se reporte la incidencia.

Referencias

DNSSEC Debugger de Verisign Labs — herramienta oficial gratuita para auditar cadenas de confianza DNSSEC.- RFC 4033 — DNS Security Introduction and Requirements, documento base que define DNSSEC.- ICANN — DNSSEC — página oficial sobre la KSK de la raíz, ceremonias de claves y adopción global.- Wikipedia: DNSSEC — artículo enciclopédico con historia, arquitectura y referencias técnicas.- APNIC Labs DNSSEC Stats — estadísticas en vivo de adopción de validación DNSSEC por país y red.

Apache HTTP Server 2.4.67 cierra 11 vulnerabilidades de mayo: el RCE en HTTP/2 (CVE-2026-23918) que obliga a parchear hoy

lu1tr0n — Tue, 05 May 2026 21:57:06 +0000

El 4 de mayo de 2026 la Apache Software Foundation publicó la versión 2.4.67 de Apache HTTP Server, el servidor web open source que sigue sirviendo cerca de un tercio de los sitios activos en internet. La versión llega como release de seguridad, features y bugfixes, e incluye parches para 11 vulnerabilidades documentadas en el advisory oficial publicado el 5 de mayo. La pieza más relevante de este conjunto, marcada por el equipo Apache como severidad Important y con CVSS de 8.8, es CVE-2026-23918: un double-free en la implementación de HTTP/2 que abre la puerta a ejecución remota de código en servidores que tienen el módulo mod_http2 activo —es decir, la mayoría de los Apache modernos detrás de un sitio HTTPS—.

A las pocas horas del anuncio, SecurityWeek, securityonline.info, The CyberSec Guru, Cybersecurity News y Undercode Testing cubrieron la noticia con análisis técnicos. No hay PoC público al momento de escribir y no se ha confirmado explotación activa, pero el bug se reportó privadamente el 10 de diciembre de 2025 y el commit del fix —r1930444— quedó registrado al día siguiente. Eso significa que un atacante con acceso al log de commits de Apache pudo identificar la primitiva vulnerable hace casi cinco meses; el ciclo de armar y publicar un exploit a partir del diff del fix suele tardar entre días y semanas. La ventana de parcheo, en otras palabras, es ya.

Este artículo documenta los 11 CVEs en el orden de criticidad real, explica con detalle el mecanismo del double-free en HTTP/2, lista mitigaciones temporales para quien no pueda actualizar de inmediato, y ofrece comandos copy-paste para detectar versiones vulnerables. Si administras Apache en producción —en un VPS, en un cluster Kubernetes, en una instancia AWS EC2 con LAMP, en una Synology o en cualquier panel tipo cPanel/Plesk— este es material operativo.

La pieza central: CVE-2026-23918, RCE en HTTP/2

Qué es exactamente

mod_http2 es el módulo de Apache que implementa el protocolo HTTP/2. Casi todos los Apache 2.4 modernos lo cargan por defecto cuando el sitio sirve por HTTPS, porque navegadores como Chrome y Firefox negocian HTTP/2 automáticamente sobre TLS desde 2015. La vulnerabilidad se dispara cuando un cliente envía una secuencia maliciosa de tramas HTTP/2 conocida como «early stream reset», una solicitud que cancela un stream en un momento muy temprano de su ciclo de vida.

En esa secuencia, la lógica de gestión de memoria del servidor termina liberando dos veces la misma región de heap: un bug clásico llamado double-free. La primera vez, la región pasa a la free-list del alocador; la segunda vez, el alocador interpreta esa región como reusable y rompe sus propias estructuras internas. A partir de ahí, un atacante con conocimiento del layout de la heap puede manipular asignaciones futuras, sobrescribir punteros de función o estructuras críticas, y en última instancia redirigir el flujo de ejecución del proceso del servidor.

Severidad oficial

Severidad Apache: Important (la segunda más alta en su escala interna, debajo de Critical).
CVSS base: 8.8 (High).
Impacto: ejecución remota de código en el contexto del usuario que corre httpd (típicamente apache, www-data o nobody).
Versión vulnerable: Apache HTTP Server 2.4.66.
Versión parcheada: 2.4.67.

Conviene notar la sutileza: el bug solo afecta la versión más reciente previa al parche, 2.4.66. Las versiones anteriores no tienen este defecto particular —fue introducido por un cambio reciente en mod_http2—. Eso es paradójico: los administradores que se mantuvieron actualizados quedaron expuestos, mientras que quienes corren versiones más viejas no son vulnerables a este CVE específico (aunque sí a los otros diez del advisory, que sí se arrastran desde antes).

Investigadores que reportaron el bug

El advisory oficial acredita a Bartlomiej Dmitruk (striga.ai) y Stanislaw Strzalkowski (isec.pl), quienes reportaron el bug de forma privada al equipo de seguridad de Apache. La cooperación responsable funcionó: el fix se commitó al día siguiente del reporte y se incluyó en el siguiente release planificado.

Por qué el RCE no es trivial pero sí real

A diferencia de un bug clásico de stack overflow donde un atacante controla directamente un puntero, en un double-free moderno el camino al RCE pasa por manipular la heap —el llamado heap grooming—. El atacante necesita encadenar asignaciones específicas para que la región liberada dos veces termine ocupada por una estructura cuyo puntero de función o tabla de virtuales pueda controlar. Esto es complicado, pero completamente factible y forma parte del repertorio estándar de las técnicas de explotación contemporáneas. Las mitigaciones del kernel —ASLR, NX, stack canaries— ayudan, pero no eliminan el riesgo.

Lo que sí es robusto es el DoS: incluso sin una explotación completa de RCE, un atacante puede tirar el servidor con la misma trama maliciosa, simplemente corrompiendo la heap hasta que httpd haga un crash. Para servicios públicos eso ya es un problema operativo grave por sí solo.

Los otros diez: el panorama completo

Más allá de la RCE estrella, el advisory cierra otras diez vulnerabilidades. Las agrupo por familia de impacto.

Información sensible y privilegio local (Moderate)

CVE-2026-24072 (Moderate, mod_rewrite y otros). Permite a un autor local de archivos .htaccess leer archivos con los privilegios del usuario httpd. Es relevante en hostings compartidos donde múltiples clientes alojan sus sitios bajo el mismo proceso de Apache. Versiones afectadas: hasta 2.4.66. Reportado por el investigador anónimo y7syeu.

CVE-2026-33006 (Moderate, mod_auth_digest). Un ataque de timing side-channel permite a un atacante remoto eludir la autenticación Digest. La autenticación Digest está en franco desuso —reemplazada por OAuth, JWT y autenticación basada en formularios sobre HTTPS—, pero algunos sitios legacy todavía la usan. Reportado por Nitescu Lucian.

Cuatro CVEs en mod_proxy_ajp: el módulo que acumula deuda

Cuatro de los once CVEs aplican al mismo módulo: mod_proxy_ajp, el conector que permite a Apache reenviar peticiones a backends Tomcat o Jetty mediante el Apache JServ Protocol.

CVE-2026-28780 (Low) — Heap-based buffer overflow en ajp_msg_check_header(). Si mod_proxy_ajp se conecta a un servidor AJP malicioso, ese servidor puede provocar una escritura de 4 bytes controlados por el atacante más allá del final de un buffer heap. Reportado independientemente por Andrew Lacambra, Elhanan Haenel, Tianshuo Han y Tristan Madani entre febrero y marzo de 2026 —cuatro investigadores convergiendo al mismo bug es una señal clara de que el módulo está en el radar—.
CVE-2026-33857 (Low) — Out-of-bounds read en funciones getter de AJP. Reportado por Elhanan Haenel.
CVE-2026-34032 (Low) — Improper null termination y out-of-bounds read en ajp_msg_get_string(). Reportado por Tianshuo Han y Jérôme Djouder.
CVE-2026-34059 (Low) — Buffer over-read y memory disclosure en ajp_parse_data(). Reportado por Elhanan Haenel.

El patrón es elocuente: AJP es un protocolo viejo —diseñado en los noventa para Apache JServ— y el código de su parser en C sigue revelando bugs después de décadas. Si tu Apache no está reenviando a un Tomcat, deshabilitar mod_proxy_ajp es la mitigación más simple y efectiva contra estos cuatro CVEs.

Denegación de servicio y crashes

CVE-2026-29168 (Low, mod_md). Vulnerabilidad de asignación de recursos sin límite en respuestas OCSP del módulo ACME que gestiona certificados Let’s Encrypt y similares. Una respuesta OCSP de tamaño excesivo agota recursos del servidor. Versiones afectadas: 2.4.30 hasta 2.4.66. Reportado por Pavel Kohout (Aisle Research).

CVE-2026-29169 (Low, mod_dav_lock). NULL pointer dereference: una solicitud maliciosa al módulo de WebDAV crashea el servidor. El advisory aclara que mod_dav_lock no es usado internamente por mod_dav o mod_dav_fs, así que removerlo si no se usa explícitamente es la mitigación trivial. Reportado por Pavel Kohout.

CVE-2026-33007 (Low, mod_authn_socache). Otro NULL deref. Permite a un usuario remoto sin autenticar crashear un proceso hijo en configuraciones de caching forward proxy. Versiones afectadas: 2.4.0 hasta 2.4.66. Reportado por Pavel Kohout y Arkadi Vainbrand.

HTTP response splitting

CVE-2026-33523 (Low, múltiples módulos). Vulnerabilidad de HTTP response splitting cuando Apache reenvía a backends comprometidos o no confiables. Permite a un atacante con control parcial del backend inyectar headers HTTP arbitrarios en la respuesta al cliente. Versiones afectadas: 2.4.0 hasta 2.4.66. Reportado por Haruki Oyama (Waseda University), Merih Mengisteab y Dawit Jeong.

Cómo detectar si tu servidor es vulnerable

El primer paso es saber qué versión corres. Los comandos varían según distribución y método de instalación.

# Linux (compilación desde fuente o paquete)
apache2 -v
# o
httpd -v

# RHEL / CentOS / Rocky / Alma
rpm -qa | grep httpd

# Debian / Ubuntu
dpkg -l | grep apache2

# Verificar módulos cargados (HTTP/2 y AJP en uso)
apache2ctl -M | grep -iE "http2|proxy_ajp"
# o en RHEL
httpd -M | grep -iE "http2|proxy_ajp"

# Ver si HTTP/2 está realmente activo en algún virtualhost
grep -r -i "Protocols" /etc/apache2/ /etc/httpd/ 2>/dev/null

# Windows (Apache Lounge u otros builds Windows)
C:\Apache24\bin\httpd.exe -v

Si la salida indica 2.4.66, eres vulnerable a CVE-2026-23918. Si indica una versión entre 2.4.0 y 2.4.66, eres vulnerable a varios de los otros diez —dependiendo de qué módulos cargues—. La versión correcta es 2.4.67.

Para chequear desde fuera, sin acceso al servidor, basta con una petición curl al header Server:

curl -I -k https://tu-dominio.tld/ 2>&1 | grep -i server
# Server: Apache/2.4.66 (Unix)

Muchos administradores ocultan el banner con ServerTokens Prod, lo cual es buena práctica de seguridad pero impide la detección remota fácil. En esos casos, un escaneo con Nmap usando el script http-apache-server-status o herramientas como Nuclei pueden inferir la versión por comportamiento.

Cómo parchear: ruta principal

La actualización es una tarea estándar. Variantes según distribución:

# Debian / Ubuntu
sudo apt update
sudo apt install --only-upgrade apache2

# RHEL / Rocky / Alma
sudo dnf update httpd

# Tras la actualización
sudo systemctl restart apache2  # o httpd

# Verificar la nueva versión
apache2 -v
# Server version: Apache/2.4.67 (Ubuntu)

Para sitios construidos sobre paneles de control —cPanel, Plesk, DirectAdmin, Webmin— la actualización suele venir empaquetada por el panel y se aplica desde su propio gestor. cPanel típicamente emite un upcp (update cPanel) que arrastra Apache; Plesk usa su propio updater. Si la versión empaquetada por la distribución todavía no incluye 2.4.67, es legítimo compilar desde fuente desde downloads.apache.org/httpd como medida temporal, pero hay que tener disciplina para volver al paquete oficial cuando la distro libere la versión.

Mitigaciones temporales si no podés actualizar ahora

A veces el calendario de mantenimiento no permite reiniciar Apache de inmediato. Hay mitigaciones que reducen sustancialmente el riesgo sin requerir actualización.

Deshabilitar HTTP/2 (cierra CVE-2026-23918)

# En httpd.conf o equivalente
# Comentar la carga del módulo:
# LoadModule http2_module modules/mod_http2.so

# O forzar solo HTTP/1.1 a nivel de virtualhost:
Protocols http/1.1

Tras editar:

sudo apachectl configtest
sudo systemctl reload apache2

El costo: HTTP/1.1 es más lento sobre TLS y los navegadores modernos están optimizados para HTTP/2. Para sitios de tráfico alto, esta mitigación puede afectar Core Web Vitals y experiencia de usuario. Es aceptable como puente de horas o un día, no como configuración permanente.

Deshabilitar mod_proxy_ajp si no se usa (cierra los 4 CVEs AJP)

# Debian / Ubuntu
sudo a2dismod proxy_ajp
sudo systemctl reload apache2

# RHEL / Rocky / Alma — comentar la línea LoadModule en
# /etc/httpd/conf.modules.d/00-proxy.conf

La gran mayoría de los Apache modernos no usan AJP. Si tu stack es LAMP puro, PHP-FPM, Node detrás de Apache via proxy_pass HTTP, esto se puede deshabilitar sin impacto.

Deshabilitar mod_dav_lock si no se usa

sudo a2dismod dav_lock

Solo dejar habilitado si tu sitio usa WebDAV con locking explícito.

Cómo se rompe y cómo se arregla, en términos del código

El commit del fix —r1930444, registrado el 11 de diciembre de 2025— se incluyó en la rama 2.4.x del repositorio Subversion oficial de Apache. El advisory no cita la función exacta del double-free, pero el patrón es reconocible para quien haya leído el código de mod_http2: la implementación de Apache mantiene estructuras de stream que se asignan al iniciar una nueva petición HTTP/2 y se liberan al cerrarla. Cuando el cliente envía un RST_STREAM muy temprano —antes de que la inicialización del stream haya completado todos los pasos— la lógica de cleanup intenta liberar la estructura por una ruta de error, mientras que el flujo principal también la libera por su ruta normal. Dos liberaciones, una sola estructura: double-free.

La corrección típica de este tipo de bug es marcar la estructura con un flag freed = true después de la primera liberación, y verificar el flag antes de cualquier liberación posterior. Apache tiene infraestructura para esto en su pool de memoria APR, y en general el arreglo consiste en que la ruta de cleanup detecte el caso y no toque la región dos veces.

Cuán fuerte es la noticia

Hay tres elementos a calibrar.

Lo serio. Es una RCE en el servidor web más usado del planeta —Apache sigue corriendo aproximadamente un tercio de los sitios activos según las series de Netcraft—, en una primitiva muy expuesta —HTTP/2 sobre TLS—, y con CVSS 8.8. No requiere autenticación. La superficie potencial es muy grande.

Lo que matiza. No hay PoC público todavía. Las primitivas de double-free a RCE en heap moderna no son triviales y requieren heap grooming específico para la versión de glibc o jemalloc del binario en cuestión. La explotabilidad real depende de mitigaciones del kernel y de las características del binario. Como mínimo, esto es un DoS confiable; el RCE confiable suele requerir trabajo adicional.

El factor tiempo. El commit del fix lleva publicado desde el 11 de diciembre de 2025. Cualquier atacante competente con acceso al log puede haber identificado la primitiva vulnerable hace meses. La ventana entre fix público y exploit público en este tipo de bugs es típicamente de días a semanas, no meses. El hecho de que la versión 2.4.67 se libere recién ahora —cinco meses después del commit— sugiere que el equipo de Apache esperaba completar la batería de releases con todos los fixes acumulados, pero el costo de esa espera es exposición prolongada para administradores que no compilaban desde el branch en desarrollo.

Lección de fondo

Hay un patrón en este advisory que vale la pena retener para quien planifica seguridad en infraestructura web. No es un solo bug; son once. La concentración de cuatro CVEs en mod_proxy_ajp confirma que los protocolos legacy mantenidos por compatibilidad acumulan deuda silenciosa. La pregunta operativa, más allá de aplicar este parche, es: ¿qué módulos cargás por defecto que no estás usando? El principio de superficie mínima —deshabilitar todo lo no necesario— sigue siendo la defensa más barata y efectiva contra clases enteras de vulnerabilidades futuras.

La otra lección es de cadencia. La política de Apache de no publicar advisories hasta tener un release estable que parche las cosas es defendible, pero crea una ventana de riesgo donde el commit del fix está en público y el binario nuevo todavía no. Para infraestructura crítica, suscribirse al httpd-announce@apache.org —la lista oficial de anuncios— y al feed RSS de los advisories es lo mínimo viable. Para entornos altamente expuestos, mirar directamente el repositorio Subversion del proyecto en busca de commits con tags Fixes ... CVE es práctica de equipos de seguridad maduros.

Y para el resto: 2.4.67 hoy.

Fuentes

Apache HTTP Server — Vulnerabilities in 2.4 (advisory oficial): https://httpd.apache.org/security/vulnerabilities_24.html
Apache HTTP Server 2.4 — Changelog completo: https://downloads.apache.org/httpd/CHANGES_2.4
NVD — CVE-2026-23918: https://nvd.nist.gov/vuln/detail/CVE-2026-23918
SecurityWeek — Critical, High-Severity Vulnerabilities Patched in Apache MINA, HTTP Server (Ionut Arghire, 5 may 2026): https://www.securityweek.com/critical-high-severity-vulnerabilities-patched-in-apache-mina-http-server/
securityonline.info — Millions at Risk: Apache HTTP Server Fixes Critical Remote Code Execution Flaw: https://securityonline.info/apache-http-server-rce-vulnerability-cve-2026-23918-patch-2-4-67/
The CyberSec Guru — Apache HTTP Server RCE Vulnerability: Critical Patch for CVE-2026-23918: https://thecybersecguru.com/news/apache-rce-vulnerability-cve-2026-23918/
Undercode Testing — Critical Apache HTTP Server Flaw Exposes Millions of Servers to RCE Attacks: A Technical Deep Dive Into CVE-2026-23918: https://undercodetesting.com/critical-apache-http-server-flaw-exposes-millions-of-servers-to-rce-attacks-a-technical-deep-dive-into-cve-2026-23918-video/
Wikipedia — Apache HTTP Server: https://en.wikipedia.org/wiki/Apache_HTTP_Server
Wikipedia — HTTP/2: https://en.wikipedia.org/wiki/HTTP/2
Wikipedia — Apache JServ Protocol: https://en.wikipedia.org/wiki/Apache_JServ_Protocol
Cobertura adicional consultada: Cybersecurity News (cybersecuritynews.com bloquea acceso programático; la versión canónica se navega directamente).

Susam Pal propone tres leyes inversas de la IA para humanos en 2026

lu1tr0n — Tue, 05 May 2026 20:17:29 +0000

El 12 de enero de 2026, el ingeniero indio Susam Pal publicó en su sitio personal un ensayo breve y provocador titulado Three Inverse Laws of AI. La propuesta es simple, casi obvia una vez enunciada, y sin embargo tan necesaria que llama la atención que nadie la haya formalizado antes con esta claridad. Pal afirma que las famosas tres leyes inversas que necesitamos en la era de los modelos de lenguaje no son reglas para constreñir a los robots, como las que Isaac Asimov inventó hace ochenta años, sino reglas que nos constriñen a nosotros, los humanos que interactuamos con ellos a diario.

El ensayo apareció justo cuando la conversación pública sobre IA atravesaba un punto delicado: ChatGPT, Claude, Gemini y compañía ya están integrados en buscadores, IDE, suites ofimáticas y bots de soporte. Para millones de personas, una respuesta generada por IA es la primera (y muchas veces única) fuente consultada. Las leyes inversas de Susam Pal aterrizan en ese contexto con un mensaje incómodo pero saludable: el problema no es solo la máquina, sino cómo la usamos.

Qué pasó: el ensayo y su recepción

Pal publica desde hace años notas técnicas en susam.net, su sitio personal. Sus textos suelen oscilar entre seguridad informática, criptografía y filosofía del software. Este ensayo, sin embargo, dio un salto desde su comunidad habitual hacia foros como Hacker News, Lobsters y varias listas de correo académicas. La razón fue simple: el texto invierte un marco mental que llevábamos décadas asumiendo como inamovible.

Las tres leyes inversas que propone son las siguientes:

Los humanos no deben antropomorfizar a los sistemas de IA.
Los humanos no deben confiar ciegamente en lo que producen los sistemas de IA.
Los humanos deben mantener plena responsabilidad y rendición de cuentas por las consecuencias de usarlos.

Pal usa el término inverse no en el sentido lógico de negación, sino para señalar que el sujeto se invirtió: ya no es el robot el que tiene reglas, somos nosotros. Es una lectura sobria, casi conservadora, en un campo dominado por el entusiasmo y los discursos transformadores.

Cada interacción con un LLM es una oportunidad para verificar, no para delegar.

Contexto: las tres leyes de Asimov y por qué ya no alcanzan

Para entender la jugada de Pal hay que recordar las leyes originales. Isaac Asimov las introdujo en su cuento Runaround, publicado en 1942 en la revista Astounding Science Fiction. En su forma canónica:

Un robot no hará daño a un ser humano ni, por inacción, permitirá que un ser humano sufra daño.
Un robot debe obedecer las órdenes que le dan los seres humanos, salvo cuando entren en conflicto con la primera ley.
Un robot debe proteger su propia existencia, salvo cuando esto entre en conflicto con la primera o la segunda ley.

Esas leyes funcionaron como dispositivo narrativo durante toda la edad de oro de la ciencia ficción. Sin embargo, presuponen un mundo donde los robots tienen agencia clara, intenciones reconocibles y un sustrato moral que se puede gobernar con axiomas. Los modelos de lenguaje grandes no son nada de eso. Un LLM no quiere nada. No obedece en ningún sentido fuerte. Es, en palabras de Pal, un modelo estadístico que produce texto plausible a partir de patrones en datos.

Aplicarles las leyes de Asimov a sistemas como Claude o GPT es una categoría errónea. La pregunta interesante, dice Pal, es otra: ¿qué reglas necesitamos los humanos para no salir lastimados de esta convivencia?

Primera ley inversa: no antropomorfizar la IA

La primera regla es la más sutil y, para muchos desarrolladores, la más incómoda. Antropomorfizar significa atribuir emociones, intenciones o agencia moral a los sistemas de IA. Pal nota que los chatbots modernos están deliberadamente afinados para sonar conversacionales, empáticos y educados. Esto los hace agradables de usar, pero también facilita olvidar lo que son: distribuidores probabilísticos sobre el siguiente token.

💭 Clave: Cuando un modelo dice "entiendo tu frustración", no entiende nada. Es una secuencia de tokens estadísticamente apropiada para el contexto. Confundir fluidez con comprensión es el primer paso del error.

El argumento de Pal es que esta confusión no es neutral. Tiene consecuencias prácticas: usuarios que desarrollan dependencia emocional con asistentes virtuales, equipos de producto que asumen que un chatbot "sabe lo que el usuario quiere", legisladores que debaten si una IA tiene "derechos" antes de discutir si su despliegue tiene riesgos. La cura, según Pal, es lingüística y mental: hablar de los sistemas como lo que son, evitar pronombres personales si es posible, no atribuirles estados anímicos en la documentación interna.

Para los desarrolladores en LATAM esto tiene un eco particular. Muchas startups regionales están vendiendo "agentes" como si fueran empleados digitales con personalidad. La presión comercial empuja en dirección contraria a la primera ley inversa, lo cual es justamente la razón por la que conviene formularla.

Segunda ley inversa: no delegar el juicio

La segunda regla es la que tiene más consecuencias inmediatas para nuestro trabajo diario. Pal lo plantea así: el contenido generado por IA no debe tratarse como autoritativo sin verificación independiente apropiada al contexto. Suena obvio, pero los buscadores ya están entrenando un hábito contrario.

Google, Bing y Brave colocan respuestas generadas por IA en el primer pixel de la página. La consecuencia esperable es que el usuario lea esa respuesta y deje de scrollear. Con el tiempo, el reflejo cognitivo cambia: la IA pasa de ser un punto de partida a ser la conclusión. Pal pide que cada servicio de IA generativa muestre una advertencia conspicua sobre las posibles alucinaciones. En la práctica, los avisos existen pero están deliberadamente atenuados.

Como desarrolladores, podemos materializar la segunda ley inversa en código. Un patrón útil es envolver toda llamada a un LLM en una capa que registre fuentes a verificar, deje rastro de quién fue el responsable humano y nunca consuma la salida directamente sin paso intermedio:

from dataclasses import dataclass, field
from typing import Optional

@dataclass
class LLMResponse:
    raw_text: str
    claims_to_verify: list[str] = field(default_factory=list)
    verified_by: Optional[str] = None
    accountable_user: str = ""
    notes: str = ""

    def is_actionable(self) -> bool:
        return self.verified_by is not None

def ask_llm(prompt: str, user: str, client) -> LLMResponse:
    completion = client.complete(prompt)
    return LLMResponse(
        raw_text=completion.text,
        claims_to_verify=extract_factual_claims(completion.text),
        accountable_user=user,
        notes="requiere revisión humana antes de ejecutar",
    )

response = ask_llm("¿Cuándo expira esta licencia?", user="ana@empresa.cl", client=llm)
assert not response.is_actionable(), "verifica antes de actuar"

El patrón no impide errores, pero los hace visibles. Un campo verified_by vacío grita: "nadie revisó esto". Y el equipo aprende a no automatizar acciones sobre salidas no verificadas.

La verificación humana puede modelarse en el tipo de retorno del wrapper.

Tercera ley inversa: no abdicar la responsabilidad

La tercera regla es la más jurídica y, para Pal, la más urgente. Si un equipo médico usa IA para apoyar un diagnóstico y el diagnóstico falla, el responsable sigue siendo el equipo médico. Si una empresa usa IA para generar copy y el copy contiene información falsa que perjudica a un cliente, la empresa responde. Si un programador usa IA para generar código y el código introduce una vulnerabilidad, el programador responde.

⚠️ Ojo: "La IA me dijo que lo hiciera" no es una defensa legal en ninguna jurisdicción seria de LATAM. Los marcos regulatorios emergentes (AI Act europeo, propuestas en Brasil, México y Chile) refuerzan que el operador es siempre responsable.

Pal advierte sobre dos modos en que la responsabilidad se evapora silenciosamente. El primero es la difusión: cuando un proceso involucra a varias personas y una IA, todos asumen que otro verificó. El segundo es la obstrucción: cuando los proveedores hacen tan opacas las cadenas de decisión que se vuelve imposible auditar quién decidió qué. Ambos son fallas organizacionales, no técnicas.

Esto se conecta con el ejemplo del veterano abogado de Nueva York que en 2023 presentó un escrito con casos inventados por ChatGPT y fue sancionado por el juez. Tres años después, el caso se cita como precedente: la responsabilidad del producto de salida es del profesional, no del modelo.

Cómo se ven las leyes inversas en la práctica

El siguiente diagrama resume la lógica que Pal propone aplicar a cada interacción con un LLM:

flowchart LR
    A["Pregunta del usuario"] --> B["LLM produce salida"]
    B --> C{"¿Verificación humana?"}
    C -->|Sí| D["Acción consciente y atribuible"]
    C -->|No| E["Riesgo: confianza ciega"]
    D --> F["Responsabilidad clara"]
    E --> G["Responsabilidad difusa"]

El nodo de verificación es el corazón del marco. Sin él, las otras dos leyes pierden tracción.

Datos y cifras: por qué esto importa en LATAM

El reporte AI Index 2026 de Stanford, publicado en abril, registra que la inversión privada global en IA llegó a 581 mil millones de dólares en 2025, un crecimiento de 26% interanual. Gartner, por su parte, revisó al alza su pronóstico de gasto en TI para 2026 hasta un 13.5% interanual, impulsado en gran parte por adopción de IA generativa en empresas.

En América Latina, la tendencia es similar pero con un componente preocupante: la mayoría de los despliegues son sobre infraestructura de proveedores extranjeros (OpenAI, Anthropic, Google), con baja capacidad local para auditar comportamiento. Chile lanzó en 2026 LatamGPT, el primer modelo generativo regional, justamente para reducir esta asimetría. Aun así, las herramientas que llegan a la mayoría de usuarios siguen siendo cajas negras.

💡 Tip: Si tu equipo en LATAM está integrando IA en producción, agregá a la documentación interna una versión local de las leyes inversas. Es una cláusula barata que evita debates incómodos cuando algo falla.

Implicaciones para desarrolladores

Las leyes inversas no son retórica filosófica. Tienen consecuencias muy concretas para quienes construimos software:

Diseño de interfaces: evitar que la IA se presente como autoridad. Mostrar siempre fuentes, contradicciones, niveles de confianza textuales ("esto puede ser incorrecto") y un camino claro para verificar.
Logging y trazabilidad: cada llamada a un modelo debería quedar asociada a un usuario humano y a un contexto, para que la responsabilidad sea atribuible.
Tono del producto: resistir la tentación de darle nombre, voz y "personalidad" al asistente si eso induce confianza injustificada. Un copy más sobrio puede ser comercialmente menos sexy y técnicamente más sano.
Tests adversariales: incluir en CI casos donde el modelo alucina deliberadamente (datos falsos, citas inexistentes) y validar que la pipeline lo detecta antes de mostrarlo al usuario.
Educación interna: los onboardings de equipo deberían incluir literalmente la lectura del ensayo de Pal o un equivalente. La cultura es parte de la arquitectura.

Qué sigue

Pal cierra su ensayo reconociendo lo obvio: ningún conjunto finito de reglas es a prueba de balas, exactamente como las leyes de Asimov tampoco lo eran en sus propios cuentos. La utilidad de las leyes inversas está en abrir un vocabulario común para discutir riesgos sin caer en la dicotomía estéril entre tecno-optimismo y tecno-pánico.

Lo que esperamos ver en los próximos meses: regulación europea y latinoamericana citando explícitamente principios cercanos a los de Pal, empresas grandes incorporando cláusulas de "verificación humana obligatoria" en sus términos de servicio para casos sensibles, y un debate más maduro en la comunidad sobre cómo entrenar a los usuarios, no solo a los modelos.

📖 Resumen en Telegram: Ver resumen

Preguntas frecuentes

¿Qué son las leyes inversas de la IA?

Son tres principios propuestos por Susam Pal en enero de 2026 que rigen el comportamiento humano frente a sistemas de IA: no antropomorfizar, no confiar ciegamente y no delegar la responsabilidad. Se llaman "inversas" porque, a diferencia de las leyes de Asimov, no constriñen al robot sino al humano.

¿Reemplazan estas leyes a las de Asimov?

No. Las leyes de Asimov son un dispositivo narrativo de ciencia ficción para gobernar agentes hipotéticos con voluntad propia. Las leyes inversas de Pal son principios prácticos para usuarios humanos de sistemas estadísticos sin agencia. Ambas pueden coexistir conceptualmente, aunque hoy las inversas tienen mayor utilidad real.

¿Cómo afectan estas leyes a los desarrolladores que usan IA en su flujo?

Implican adoptar prácticas como verificar siempre la salida de un LLM antes de aceptarla en código de producción, mantener trazabilidad de qué humano aprobó qué decisión, y diseñar interfaces que no induzcan confianza injustificada en los usuarios finales del producto.

¿Cuál es la principal crítica de Susam Pal al diseño actual de los chatbots?

Pal sostiene que los proveedores afinan deliberadamente a los modelos para sonar empáticos y conversacionales, lo cual aumenta la usabilidad pero también la antropomorfización. Sugiere que un tono ligeramente más mecánico sería más saludable a largo plazo para la sociedad.

¿Hay regulación en LATAM que recoja estos principios?

De momento no de forma explícita, pero las propuestas de regulación de IA en Brasil, México y Chile incluyen cláusulas sobre responsabilidad humana del operador y obligación de verificación, que se alinean con la tercera ley inversa de Pal.

¿Dónde puedo leer el ensayo original?

El texto completo está disponible en el sitio personal de Susam Pal, susam.net, bajo el título Three Inverse Laws of AI. Es de lectura corta (unos 15 minutos) y abierto sin paywall ni registro.

Referencias

Three Inverse Laws of AI — Susam Pal — ensayo original publicado el 12 de enero de 2026.
Three Laws of Robotics — Wikipedia — historia y formulación canónica de las leyes de Asimov.
Anthropomorphism — Wikipedia — base conceptual del primer principio inverso.

Quadsqueezing: Oxford logra el primer efecto cuántico de cuarto orden con un solo ion atrapado, 100 veces más rápido de lo…

lu1tr0n — Tue, 05 May 2026 19:44:36 +0000

El 1 de mayo de 2026, la revista Nature Physics publicó un trabajo del Departamento de Física de la Universidad de Oxford que demuestra, por primera vez en cualquier plataforma experimental, una interacción cuántica de cuarto orden conocida como quadsqueezing. El paper, titulado "Squeezing, trisqueezing and quadsqueezing in a hybrid oscillator–spin system" y firmado por O. Băzăvan, S. Saner, D. J. Webb, E. M. Ainley, P. Drmota, D. P. Nadlinger, G. Araneda, D. M. Lucas, C. J. Ballance y R. Srinivas, está disponible bajo el DOI 10.1038/s41567-026-03222-6 y como preprint arXiv 2403.05471 desde marzo de 2024. El equipo demostró, sobre un único ion atrapado, no solo el squeezing tradicional —ya conocido desde 1985 en óptica cuántica— sino también el trisqueezing (tercer orden) y el quadsqueezing (cuarto orden), generando este último más de 100 veces más rápido de lo que predicen los métodos convencionales.

La cobertura mediática fue inmediata: ScienceDaily, The Quantum Insider, Phys.org, EurekAlert y HPCwire reportaron el resultado el mismo día. El logro tiene aplicaciones concretas en simulación cuántica, sensores cuánticos y computación cuántica, e incluye una demostración temprana en simulación de teorías gauge de red, una de las áreas más exigentes de la física teórica computacional. Este artículo es la continuación natural de la cobertura del Turing Award 2025 a Bennett y Brassard, que recorrió la criptografía cuántica desde BB84 hasta el horizonte de Q-Day; quadsqueezing pertenece al mismo paisaje, pero del lado de la información cuántica como recurso.

Qué es squeezing en términos accesibles

Para entender qué significa el resultado de Oxford hay que partir de un hecho de la mecánica cuántica que distingue ese mundo del clásico: dos magnitudes complementarias no pueden conocerse simultáneamente con precisión arbitraria. La formalización más conocida es el principio de incertidumbre de Heisenberg, que para una partícula relaciona posición y momento. En óptica cuántica, las dos magnitudes son las llamadas cuadraturas del campo electromagnético, conceptualmente análogas a la posición y velocidad de un oscilador. La luz láser ordinaria —llamada estado coherente— distribuye su incertidumbre por igual entre ambas cuadraturas. Es la luz "más clásica" que la naturaleza permite.

Un estado comprimido, o squeezed state, redistribuye esa incertidumbre. Reduce el ruido en una cuadratura por debajo del límite cuántico estándar, a costa de aumentar el ruido en la otra. La analogía clásica útil es un balón redondo que uno aplasta para hacerlo elipsoidal: el volumen total se conserva, pero una dimensión se vuelve más estrecha. Esa estrechez tiene valor práctico: si lo que medimos depende de la cuadratura comprimida, podemos medir mejor que con luz láser ordinaria. La idea fue propuesta teóricamente en los años setenta y se demostró experimentalmente por primera vez en 1985, hace cuarenta y un años. Hoy es infraestructura operativa de los detectores de ondas gravitacionales Advanced LIGO y GEO600, donde la luz comprimida permite detectar variaciones de longitud menores a una fracción del diámetro de un protón a escalas de kilómetros.

Hasta aquí, squeezing es un efecto de segundo orden: las matemáticas lo describen con un operador que contiene términos cuadráticos en la cuadratura. La pregunta natural en el campo desde hace décadas era si se podían generar análogos de orden superior —tercer orden (trisqueezing) y cuarto orden (quadsqueezing)— donde el operador contiene términos cúbicos o cuárticos. Esos estados de orden superior tienen estructura geométrica más rica y, en principio, podrían ofrecer ventajas que el squeezing tradicional no permite.

Por qué los efectos de orden superior son tan difíciles

Hay una razón física directa por la que estos efectos no se habían observado hasta ahora. Las interacciones de orden superior son, en términos de los acoplamientos físicos disponibles, naturalmente débiles. La intensidad cae rápidamente con cada orden adicional, de modo que cualquier ruido del experimento —fluctuaciones térmicas, decoherencia, imperfecciones de los pulsos láser— ahoga la señal antes de que pueda manifestarse. Generar quadsqueezing por la vía directa requeriría tiempos de interacción tan largos que el sistema se decohera antes de completarse el efecto; o, alternativamente, intensidades tan altas que los componentes experimentales se rompen.

Hasta este trabajo, la comunidad había explorado trisqueezing en algunas plataformas con resultados parciales y muy cortos en duración. El quadsqueezing era considerado, en términos de muchas conferencias del campo, "experimentalmente fuera de alcance" para sistemas existentes. La barrera no era teórica sino práctica: la naturaleza no entrega ese tipo de interacción de manera fácil.

La idea: fuerzas no-conmutativas como atajo

El equipo de Oxford resolvió el problema con un truco conceptual elegante que está en el corazón del paper. No intentaron generar la interacción de cuarto orden directamente. Aplicaron al ion atrapado dos fuerzas controladas, cada una de las cuales por separado produce un efecto lineal sencillo. Lo que hace la combinación de las dos fuerzas es lo interesante: el conjunto no es la suma de las partes, sino algo cualitativamente diferente.

La pieza física que permite este atajo se llama no-conmutatividad. En matemática elemental, sumar tres a cinco da el mismo resultado que sumar cinco a tres. En el mundo cuántico, no todas las operaciones se comportan así. Hay pares de operaciones donde el orden importa: hacer A y luego B no produce el mismo estado final que hacer B y luego A. Esa diferencia entre los dos órdenes —el conmutador de las dos operaciones— es, técnicamente, otra operación. Y si las operaciones lineales se eligen con cuidado, su conmutador puede ser una operación de orden superior.

La autora principal, Oana Băzăvan, lo expresó con esta cita en el comunicado oficial de Oxford:

"En el laboratorio, las interacciones no-conmutativas suelen verse como una molestia porque introducen dinámicas no deseadas. Aquí tomamos el enfoque opuesto: usamos esa característica para generar interacciones cuánticas más fuertes."

La estrategia replanteó la economía del experimento. En vez de luchar contra la debilidad intrínseca de una interacción de cuarto orden, el equipo construyó esa interacción combinando dos efectos lineales —que sí son fuertes y robustos— y dejando que la no-conmutatividad hiciera el trabajo. El resultado: la interacción de quadsqueezing emergió más de 100 veces más rápido que el tiempo previsto por el cálculo directo convencional, lo cual significa que el efecto se completa antes de que la decoherencia destruya la coherencia cuántica del ion.

La teoría que predijo el experimento

El experimento se apoya en una propuesta teórica publicada en 2021 por Raghavendra Srinivas —coautor también del experimento— y Robert Tyler Sutherland, en Physical Review A (volumen 104, número 032609). El paper teórico mostró formalmente cómo dos interacciones lineales spin-dependent en un ion atrapado pueden combinarse para implementar interacciones bosónicas no lineales de hasta cuarto orden. Conviene retener el detalle: la predicción precedió al experimento por cinco años. Es un caso instructivo de cómo la teoría cuántica adelanta hipótesis sobre fenómenos que la experimentación todavía no puede ejecutar, y luego la ingeniería avanza para alcanzarlos.

La propuesta de Srinivas y Sutherland generaliza un patrón conocido en óptica cuántica desde hace décadas: las interacciones bosónicas no lineales —procesos donde la energía del campo no se reparte linealmente— son la materia prima de la mayoría de los fenómenos cuánticos interesantes. Lo nuevo en su trabajo era ofrecer una receta concreta y experimentalmente factible usando un ion atrapado y los pulsos láser que ya forman parte del repertorio estándar de los laboratorios del campo. El trabajo de Oxford convierte esa receta en realidad medida.

Cómo es físicamente el experimento

Aunque el paper original contiene los detalles instrumentales completos, el esquema general se puede describir sin perder el sentido. El sistema experimental consiste en:

Un único ion atrapado, sostenido en una trampa de iones mediante campos electromagnéticos cuidadosamente configurados. Las trampas de iones son la plataforma más madura para experimentos cuánticos de este tipo: el ion queda suspendido en el vacío, aislado de la mayoría de fuentes de ruido, donde sus estados internos —spin— y su movimiento mecánico —oscilación en la trampa— pueden manipularse con pulsos láser.
Dos haces láser que aplican fuerzas distintas al ion. La intensidad y la frecuencia de cada haz se controlan con precisión, y juntas producen la combinación no-conmutativa que da origen a la interacción de orden superior.
Detección por reconstrucción de la función de Wigner, una representación matemática del estado cuántico que permite caracterizar de qué tipo de squeezing se trata. La función de Wigner del estado quadsqueezed tiene una estructura geométrica con simetría rotacional de cuatro lados, distinguible de la elipse del squeezing ordinario y del triángulo del trisqueezing.

Lo notable es que el mismo aparato genera los tres tipos de squeezing —segundo, tercer y cuarto orden— con solo cambiar los parámetros de los láseres. Esa universalidad del setup es importante para aplicaciones futuras: una plataforma flexible puede simular muchos sistemas físicos sin reconfiguración mecánica.

Por qué importa: tres aplicaciones concretas

Quadsqueezing no es un efecto curioso confinado a la metrología fundamental. El paper menciona y, en algunas demostraciones tempranas dentro del propio trabajo, ya explora tres familias de aplicaciones.

Simulación cuántica de teorías gauge de red

Las teorías gauge de red son una herramienta central de la física de altas energías. Permiten estudiar, en una computadora, cómo se comportan las interacciones fuertes que mantienen unidos los protones y neutrones, en regímenes donde la teoría continua no se puede resolver con lápiz y papel. El cálculo en supercomputadoras clásicas es extremadamente costoso: las simulaciones modernas de QCD en red consumen decenas de millones de horas-CPU al año en centros como Oak Ridge o Jülich. Una alternativa que se ha desarrollado en los últimos quince años es simular las teorías gauge directamente en hardware cuántico, donde la dinámica cuántica del sistema simulador refleja la dinámica del sistema simulado.

Los términos de orden superior que aparecen naturalmente en algunas teorías gauge de red eran difíciles de implementar en simuladores cuánticos pre-quadsqueezing. El equipo de Oxford ya demostró una simulación temprana de un modelo gauge usando su técnica, lo cual posiciona el resultado como pieza directamente útil para esta línea de investigación. La conexión con el premio Turing 2025 es clara: ambas tradiciones —criptografía cuántica e información cuántica— convergen en la idea de usar dinámica cuántica controlada como recurso computacional.

Sensores cuánticos de mayor sensibilidad

El squeezing tradicional ya se usa en LIGO para detectar ondas gravitacionales. La intuición es directa: comprimir el ruido en la cuadratura que se mide permite medir más fino. Los sensores que incorporan estados quadsqueezed pueden, en principio, detectar señales con perfiles de ruido distintos a los que el squeezing ordinario optimiza. Algunos escenarios donde esto puede importar: detección de magnetómetros para imagen cerebral funcional, sensores inerciales para navegación inercial sin GPS en submarinos o cápsulas espaciales, y mediciones de fuerzas extremadamente débiles en el contexto de búsqueda de materia oscura. El campo todavía está en fase exploratoria sobre cuáles aplicaciones específicas se benefician más, pero la herramienta ya existe.

Computación cuántica con menor sobrecarga

En computación cuántica con qubits superconductores o iones atrapados, las operaciones no lineales son escasas y caras. Cada operación que requiere interacciones de orden superior se descompone, en el modelo estándar, en una secuencia larga de operaciones lineales más simples. Esa secuencia consume tiempo de coherencia y acumula errores. Si se puede ejecutar la operación de orden superior en un solo paso, como permite quadsqueezing, la profundidad del circuito disminuye y la fidelidad del resultado mejora. Los autores señalan en el comunicado oficial que su técnica abre la posibilidad de implementar puertas lógicas no estándar con menos pasos, lo cual es directamente relevante para escalar la computación cuántica más allá de los aproximadamente cien qubits que la mayoría de procesadores comerciales manejan hoy con fidelidad útil.

Cuán fuerte es el resultado

Conviene calibrar el resultado. Esto no es un computador cuántico universal. Es un único ion en una trampa, y el efecto demostrado es un componente, no un sistema completo. La pregunta operativa para alguien que sigue el campo es: ¿qué barreras de escala van a aparecer cuando se intente extender este truco a sistemas con muchos modos —es decir, muchos iones— y cuando se intente integrarlo con las arquitecturas de error correction que ya están en desarrollo? Esos son problemas abiertos, y el paper los menciona explícitamente como dirección de trabajo futuro.

Lo que sí es robusto es el principio. La idea de explotar no-conmutatividad como recurso, en lugar de tratarla como una molestia que hay que minimizar, tiene aplicaciones más allá de squeezing. La cita de Raghavendra Srinivas, supervisor del trabajo, en el comunicado oficial es ilustrativa:

"Fundamentalmente, hemos demostrado un nuevo tipo de interacción que nos permite explorar la física cuántica en territorio inexplorado, y estamos genuinamente entusiasmados por los descubrimientos que vendrán."

Hay un patrón en este tipo de avances. Las técnicas inicialmente desarrolladas en sistemas pequeños y bien controlados —un solo ion en una trampa— suelen migrar primero a sistemas medianos —pequeños arrays— y luego a la infraestructura común de la disciplina, como ya pasó con el squeezing tradicional. La adopción no es inmediata; los detectores de ondas gravitacionales tardaron veinticinco años en pasar de las primeras demostraciones de squeezing en laboratorio a la integración operativa. La ventana de tiempo para ver quadsqueezing fuera del laboratorio puede ser comparable, o más rápida si las aplicaciones de simulación cuántica empujan.

Cómo experimentar con squeezing desde el código

Para quien quiera explorar la física desde una herramienta de programación sin acceso a un laboratorio de física atómica, las plataformas de simulación cuántica modernas exponen estos conceptos directamente. Qiskit, Cirq, Strawberry Fields y QuTiP permiten construir y simular estados squeezed con pocas líneas de Python. Un ejemplo mínimo en QuTiP, una biblioteca abierta de simulación cuántica:

import numpy as np
from qutip import basis, displace, squeeze, wigner, plot_wigner

N = 30  # dimensión del espacio de Hilbert truncado
alpha = 0.0  # sin desplazamiento, vacío comprimido
r = 1.0  # parámetro de squeezing (en unidades naturales)
theta = 0.0  # ángulo de squeezing

vac = basis(N, 0)  # estado vacío
sq_op = squeeze(N, r * np.exp(1j * theta))  # operador de squeezing
sq_state = sq_op * vac  # vacío comprimido

# función de Wigner: distribución de cuasi-probabilidad en el espacio de fase
plot_wigner(sq_state)

El resultado visual es una distribución elíptica en el espacio de fase: la firma del squeezing de segundo orden. Para trisqueezing y quadsqueezing las funciones equivalentes no están todavía como primitivas en QuTiP, pero pueden construirse extendiendo el operador squeeze con potencias mayores del operador de aniquilación. Es un buen ejercicio para entender por qué las interacciones de orden superior son matemáticamente más complejas, aun cuando la física experimental ahora las habilite.

# Instalación de QuTiP
pip install qutip

# Para Strawberry Fields (Xanadu), específico para óptica cuántica continua
pip install StrawberryFields

Strawberry Fields es particularmente útil porque trata estados squeezed como ciudadanos de primera clase del lenguaje, y es la plataforma sobre la cual Xanadu desarrolla sus computadoras cuánticas fotónicas comerciales. El código, sin instalación física, es la entrada más accesible al mundo conceptual donde Oxford acaba de empujar la frontera.

Lección de fondo

El paper de Oxford hace algo que vale la pena retener para entender la dinámica del avance científico. Toma una "molestia" —la no-conmutatividad de operaciones cuánticas— y la convierte en recurso. Es el mismo movimiento que hace BB84 con la perturbación cuántica de la medición: lo que en otros contextos es una limitación, en el contexto correcto es la herramienta. Esta inversión de perspectiva es el patrón estructural de muchos avances en información cuántica.

La otra lección es de método. La predicción teórica de Srinivas y Sutherland en 2021 anticipó precisamente lo que el experimento demuestra ahora. Cinco años entre la propuesta sobre el papel y el resultado en el laboratorio es un ciclo razonablemente corto en física experimental, y depende crucialmente de que la teoría haya identificado un camino implementable con la tecnología existente, no un camino que requiera plataformas de generación futura. Cuando la teoría, los experimentos y la ingeniería operan en sincronía, el campo avanza rápido. Cuando se desincronizan, los resultados quedan en la lista de "experimentos pendientes" durante décadas.

Para quien sigue el panorama de información cuántica desde fuera del campo, lo importante es que la frontera ya no está en demostrar que el squeezing existe ni en optimizar el squeezing tradicional. Está en construir el repertorio completo de interacciones de orden superior y aprender a integrarlas en sistemas que escalen. Quadsqueezing es la primera baldosa de un piso que recién empieza a ponerse.

Fuentes

Squeezing, trisqueezing and quadsqueezing in a hybrid oscillator–spin system — Băzăvan et al., Nature Physics, mayo 2026: https://doi.org/10.1038/s41567-026-03222-6
Preprint en arXiv (versión open access): https://arxiv.org/abs/2403.05471
Comunicado oficial Oxford Department of Physics: https://www.physics.ox.ac.uk/news/oxford-team-achieves-first-ever-quadsqueezing-quantum-interaction
ScienceDaily — Oxford physicists achieve first-ever "quadsqueezing" breakthrough in quantum physics: https://www.sciencedaily.com/releases/2026/05/260501052828.htm
The Quantum Insider — Oxford Team Achieves First-ever 'Quadsqueezing' Quantum Interaction: https://thequantuminsider.com/2026/05/01/oxford-team-achieves-first-ever-quadsqueezing-quantum-interaction/
EurekAlert (comunicado de prensa primario): https://www.eurekalert.org/news-releases/1126499
Wikipedia — Squeezed coherent state: https://en.wikipedia.org/wiki/Squeezed_coherent_state
Wikipedia — Trapped ion quantum computer: https://en.wikipedia.org/wiki/Trapped_ion_quantum_computer
Wikipedia — Ion trap: https://en.wikipedia.org/wiki/Ion_trap
Trabajo teórico precedente: Srinivas y Sutherland, Physical Review A 104.032609 (2021). El sitio de APS bloquea agregadores externos; la cita canónica se consulta directamente en journals.aps.org.
Cobertura adicional consultada: phys.org, HPCwire, Yahoo News (algunos de estos publishers bloquean acceso programático; las versiones canónicas se navegan directamente).
Artículo previo en línea con esta cobertura: Turing 2025 a Bennett y Brassard, elsolitario.org, 3 mayo 2026: https://elsolitario.org/2026/05/03/turing-2025-a-bennett-y-brassard-por-que-la-criptografia-cuantica-que-inventaron/

Bun explora migrar de Zig a Rust con un port asistido por IA: lo que dice la guía oficial publicada hoy

lu1tr0n — Tue, 05 May 2026 19:31:55 +0000

El 5 de mayo de 2026 apareció en el repositorio oficial de Bun una rama llamada claude/phase-a-port con un archivo nuevo: docs/PORTING.md. El commit, identificado como 46d3bc29f270fa881dd5730ef1549e88407701a5, es la primera evidencia pública de que el equipo de Bun —desde diciembre de 2025 propiedad de Anthropic— está experimentando con la idea de migrar el runtime completo del lenguaje Zig al lenguaje Rust, usando agentes de inteligencia artificial como traductores principales del código fuente. Horas después, Jarred Sumner, creador y mantenedor principal de Bun, salió a aclarar en Hacker News que el experimento no es un compromiso de reescribir el runtime, sino una exploración técnica que podría descartarse por completo. La discusión escaló en pocas horas: 692 puntos y 511 comentarios en HN, una cobertura de The Register firmada por Tim Anderson, hilos en Lobsters y respuestas en cadena desde el ecosistema Zig.

Esta noticia cae apenas un día después de la cobertura sobre Bun bajo Anthropic y los miedos comunitarios que arrastra la adquisición. El port a Rust convierte una preocupación abstracta de gobernanza en una decisión técnica concreta y verificable. Vamos a desarmar el anuncio: qué dice exactamente la guía oficial, por qué Zig fue la elección original, qué fricción produjo la política no-IA del proyecto Zig, cómo está estructurado el experimento de traducción, y qué implicaciones reales tiene para el millón largo de proyectos que hoy dependen de Bun en producción.

Qué pasó el 5 de mayo

A las 14:08 UTC, el The Register publicó la nota titulada "Bun posts Rust porting guide, says rewrite is still half-baked". La pieza, basada en el commit público y en respuestas directas de Sumner en redes sociales, sintetiza el contexto en una línea que resume el conflicto: "Zig's no-AI policy is at odds with view that most open source code will be AI-written in future". La frase de Sumner que resumió su postura sobre el ecosistema, citada por The Register, es contundente:

"I expect OSS to go the opposite direction: no human contribution allowed."

Esa es una de las posiciones más radicales que ha expresado un mantenedor relevante hasta hoy sobre el futuro del open source y los agentes de código. La aclaración inmediata sobre el experimento concreto, también de Sumner, fue más mesurada:

"We haven't committed to rewriting. There's a very high chance all this code gets thrown out completely. I'm curious to see what a working version of this looks like, what it feels like, how it performs."

La rama claude/phase-a-port no es una propuesta de merge; es un experimento que vive en paralelo a la rama principal main. El nombre mismo —incluir claude/ como prefijo— es revelador: el port se está realizando con un agente coordinador construido sobre Claude Code, el agente de programación de Anthropic.

Bun en 2026: cuán importante es el proyecto

Antes de discutir si tiene sentido reescribirlo, conviene establecer escala. Bun es un runtime alternativo a Node.js y Deno, lanzado como versión 1.0 en septiembre de 2023 por Jarred Sumner. Combina runtime de JavaScript, gestor de paquetes, bundler y task runner en un único binario. Sus números públicos a inicios de 2026 son significativos:

88.000 estrellas en GitHub, muy por encima de Deno y comparable con frameworks históricos.
7,2 millones de descargas mensuales desde el registro npm.
Aproximadamente 3,1 millones de descargas semanales del paquete bun, con crecimiento interanual reportado del +85%.
Empresas con uso documentado en producción incluyen Stripe, X (anteriormente Twitter), Midjourney y Tailwind CSS, que distribuye su CLI standalone como un binario construido con Bun.
El propio Anthropic lo usa internamente para Claude Code, su producto de agente CLI.
Aproximadamente 770.000 líneas de código en el repositorio principal, predominantemente en Zig.

A diferencia de Node, que está en C++ y cuyo desarrollo lleva más de quince años, o de Deno, que está escrito en Rust desde su origen, Bun apostó por Zig, un lenguaje de sistemas diseñado por Andrew Kelley a partir de 2016 para reemplazar C en escenarios donde se requiere control bajo nivel sin la complejidad sintáctica de Rust. Esa decisión fue distintiva durante años y forma parte de la identidad técnica del proyecto.

Por qué Zig fue la elección original

La elección de Zig por parte de Sumner respondía a tres factores que en su momento eran defendibles:

Compilación rápida. Zig produce binarios sin las pesadas operaciones de monomorfización que Rust hace para cada genérico. En proyectos grandes como Bun esa diferencia se nota: los tiempos de iteración del desarrollador son sustancialmente menores.
Control explícito de memoria sin borrow checker. Zig deja la responsabilidad al programador, lo que evita pelear con el verificador de préstamos, pero exige disciplina manual. Sumner ha argumentado que para un runtime con caminos calientes muy específicos, eso permite optimizaciones difíciles de expresar en Rust idiomático sin caer en unsafe.
comptime y monomorfización selectiva. Zig permite ejecutar código en tiempo de compilación para generar variantes especializadas de funciones. Esto encaja con el patrón típico de un runtime, donde se quiere una implementación rápida para casos comunes y un fallback genérico para casos raros.

El precio de esa elección era estabilidad. Zig estaba —y sigue estando— en versión 0.16, lo que significa que tanto la sintaxis del lenguaje como la biblioteca estándar pueden cambiar entre versiones menores. El equipo de Bun mantiene un fork interno de Zig precisamente para amortiguar ese ritmo, además de incorporar mejoras propias. Una de esas mejoras —generación de código en paralelo, que cuadruplicaba la velocidad de compilación en modo debug— se convirtió, paradójicamente, en parte del detonante del experimento actual.

La política no-IA de Zig y el bloqueo del fork

Cuando Bun intentó proponer la mejora de compilación paralela al proyecto Zig upstream, dos obstáculos aparecieron al mismo tiempo. El primero fue técnico: el equipo core de Zig argumentó que la implementación paralela del análisis semántico podía exhibir comportamientos no deterministas en ciertos órdenes de evaluación, y que aceptar el cambio sin un análisis exhaustivo podía romper supuestos del compilador. El segundo fue de gobernanza: el proyecto Zig adoptó formalmente una política contra contribuciones asistidas por modelos de lenguaje grandes.

El argumento detallado de esa política fue publicado por Loris Cro, ingeniero del equipo Zig, en su blog kristoff.it el 29 de abril de 2026. Cro lo enmarca en lo que llama "contributor poker": apostar el tiempo y la energía de los mantenedores en contribuyentes humanos que desarrollen pericia y confianza con el equipo. La cita central de su tesis es:

"From the perspective of contributor poker it's simply irrational for us to bet on LLM users while there's a huge pool of other contributors. To be able to provide impactful work a contributor needs to be familiar with the codebase and the problem space."

El equipo Zig sostiene que las contribuciones generadas por LLMs presentan tres problemas recurrentes: pull requests con alucinaciones, código que no compila, y autores que consultan modelos en privado mientras niegan hacerlo en el hilo público. La política no prohíbe a desarrolladores usar IA en su flujo personal; prohíbe contribuciones donde el LLM es el autor efectivo del código.

Para Bun la política fue una pared. La mejora de compilación paralela, junto con varios parches adicionales, no podía mergearse upstream sin reescritura humana. Esto implica que cualquier mejora seguirá viviendo en el fork interno de Bun, multiplicando el esfuerzo de mantenimiento a medida que Zig sigue evolucionando independientemente. La pregunta empezó a ser: si el proyecto va a desviarse cada vez más del Zig upstream, ¿por qué no usar un lenguaje que sí acepte los flujos de trabajo modernos?

Phase A y Phase B: la guía oficial

PORTING.md divide el proceso en dos fases con objetivos muy distintos. La estructura está pensada para usar agentes de IA como motor de traducción, pero conserva control humano explícito.

Fase A: capturar la lógica

El objetivo de la fase A es producir un archivo .rs al lado de cada .zig que represente la misma lógica, sin que el código necesite compilar. La consigna es estructural: respetar el orden de los campos, los nombres de las funciones (en snake_case) y el flujo de control. Cada función traducida lleva un comentario que indica el grado de confianza:

// CONFIDENCE: high
fn parse_header(buffer: &[u8]) -> Option {
    // TODO(port): verificar manejo de end-of-stream
    // PERF(port): zig usaba un arena allocator de 4096 bytes
    // ...
}

Las restricciones explícitas que enumera la guía son sorprendentemente estrictas para un proyecto Rust. Citando textualmente:

"No tokio, rayon, hyper, async-trait, futures. No std::fs, std::net, std::process."

Tampoco se permite async fn. Todo concurrencia se expresa con callbacks y máquinas de estado, "igual que en el Zig original". Los bloques unsafe requieren anotaciones // SAFETY: <razón> que reflejen los invariantes del código original. Los crates relacionados con el AST mantienen arenas; el resto usa el alocador global.

Estas restricciones son, en términos de comunidad Rust, profundamente no-idiomáticas. La mayoría de los proyectos Rust modernos asumen tokio para asíncrono, hyper para HTTP, rayon para paralelismo de datos. Renunciar a todo el ecosistema asíncrono de alto nivel no es una decisión accidental: el equipo de Bun necesita preservar el modelo de concurrencia del runtime original, donde el bucle de eventos está construido manualmente y los handles se pasan como argumentos explícitos.

Fase B: hacer que compile

La fase B toma los archivos producidos por la fase A y los hace compilar crate por crate. Aquí los tipos se ajustan, los imports se resuelven, los lifetimes se anotan, y el borrow checker se enfrenta. Esta es la parte donde la mayor parte del trabajo humano resulta inevitable.

El estado actual reportado por la comunidad es elocuente: aproximadamente el 80% de los archivos porteados tiene confianza marcada como medium, lo cual significa que la lógica probablemente está bien capturada, pero el código no compila. La fase B no ha empezado en serio. Sumner lo confirmó al moderar la discusión en HN:

"This whole thread is an overreaction. 302 comments about code that does not work."

Cómo se traduce código entre lenguajes con agentes

El método operativo descrito implícitamente en PORTING.md y discutido en los hilos públicos es lo que en la comunidad se ha empezado a llamar "vibe-port": un agente coordinador lee el archivo Zig, identifica las construcciones idiomáticas, las mapea a equivalentes en Rust según un libro de reglas, y produce el .rs con marcadores TODO/PERF para los puntos donde la traducción es ambigua. Un humano —o un segundo agente— revisa los marcadores antes de pasar a la fase B.

La ventaja teórica de este enfoque sobre una reescritura humana es la velocidad: 770.000 líneas de código se pueden traducir en días, no en años. La desventaja es que el código resultante puede ser correcto en lógica pero feo en estilo, lleno de unsafe para imitar punteros crudos del Zig original, con asignaciones manuales que un programador Rust expresaría con primitivas estándar.

Un comentario destacado en Lobsters sintetiza la crítica:

"Está absolutamente lleno de unsafe y producirá toneladas de código Rust no idiomático. Nunca conocí mantenedores felices con Rust en codebases de más de 100k líneas que tengan ese perfil."

Otro punto crítico es la verificación: ¿cómo sabe el equipo que el código traducido se comporta igual al original? La respuesta probable es la batería de tests del runtime, que ya es muy extensa por la naturaleza del proyecto (cubrir compatibilidad con Node.js obliga a una cobertura amplia). Si los tests pasan idénticos en ambas implementaciones, la traducción se considera válida; si fallan, los marcadores TODO en el archivo son las pistas que un humano usa para investigar.

La discusión pública: 692 puntos en HN

El hilo en Hacker News ha sido el más activo de la semana en el espacio runtime/lenguaje. Las posiciones se distribuyen de forma reconocible:

Defensores del experimento. Validan la curiosidad técnica de comparar lenguajes lado a lado. Argumentan que usar LLMs para PoCs de traducción es legítimo si el código se descarta después. Notar que algunos modelos manejan mejor Rust que Zig en código generado, lo cual sesga el experimento a favor del port.
Escépticos del AI-coding. Preocupación por código sin comprensión humana profunda. Desconfianza en que un modelo genere Rust idiomático con borrow checker correcto a esta escala. Crítica a la falta de claridad sobre si esto es experimento real o cambio de dirección encubierto.
Observadores del ecosistema. Apuntan que Rust tiene tiempos de compilación más lentos que Zig, lo cual es paradójico si la motivación inicial era acelerar la compilación. Otros notan que Rust no necesariamente tiene que arrastrar todo su ecosistema asíncrono pesado, y que evitando tokio/rayon —como hace la guía de Bun— se puede mantener un perfil de dependencias relativamente liviano.
Sospecha post-adquisición. Aparecen comentarios que conectan este experimento con la cobertura previa sobre la degradación de Claude Code y los miedos a la "enshittification" de Bun. Para esta fracción de la comunidad, ver código generado por agentes Anthropic dentro del runtime que esos mismos agentes consumen confirma una espiral preocupante de auto-referencia: la herramienta usa la herramienta para reescribir la herramienta.

El comentario más votado en Lobsters, de un usuario llamado pyfisch, documenta con citas explícitas el uso extensivo de agentes LLM en pull requests recientes del repositorio de Bun, incluso en la rama principal. La línea entre "experimento aislado" y "metodología principal de desarrollo" es tenue.

Conexión con la adquisición y el caso Claude Code

Este movimiento técnico no se puede leer aislado del contexto corporativo. Anthropic compró Bun a finales de 2025. Cinco meses después, Claude Code mostró señales de degradación que despertaron alarmas comunitarias. El experimento de port a Rust llega justo cuando esas alarmas todavía están vigentes, y la postura pública de Sumner —"espero que el OSS vaya en la dirección opuesta: que no se permita contribución humana", según recogió The Register— pone gasolina al fuego.

Para una parte de los usuarios productivos de Bun la pregunta práctica es simple: ¿qué hago con mis pipelines si el runtime que despliego cada noche está siendo reescrito por agentes con el sello de la empresa que también vende el agente que escribe el código? La respuesta razonable, mientras el experimento esté en fase A, es ninguna acción urgente. La rama claude/phase-a-port no afecta la rama main. Los releases públicos de Bun siguen saliendo del Zig original.

Pero la pregunta que sí cambia con este anuncio es de otro orden: si el equipo decide promover el port a producción —lo cual depende fundamentalmente de los resultados de la fase B—, los usuarios estarán dependiendo de un runtime cuyo código fuente no fue escrito por humanos en su mayoría. Para escenarios de auditoría, compliance, certificaciones gubernamentales o seguridad sectorial, eso es una conversación nueva que pocas organizaciones tienen modelada.

Qué viene después

Tres escenarios concretos quedan abiertos:

Escenario 1: El experimento se descarta. Sumner termina la fase B parcialmente, descubre que el código resultante es lento o lleno de bugs sutiles, y archiva la rama. Bun sigue en Zig. Costo: tiempo gastado, no más. Probabilidad estimada por el propio Sumner: alta.
Escenario 2: Coexistencia de runtimes. La fase B se completa lo suficiente como para producir un binario funcional pero con desempeño inferior. Bun mantiene la versión Zig como producción estable y la versión Rust como experimento. Esto fragmentaría la comunidad de mantenedores en dos bases de código.
Escenario 3: Migración completa. La fase B produce un runtime Rust con desempeño aceptable o superior, el equipo abandona la base Zig, y Bun pasa a ser oficialmente un proyecto Rust. Esto sería un terremoto para el ecosistema Zig (perdería su usuario más visible) y enviaría una señal fuerte sobre el lugar del AI-coding en el desarrollo serio de software.

Los plazos típicos para experimentos de este tamaño en la práctica de Sumner sugieren resoluciones en orden de semanas, no meses. La gente que sigue el repositorio de cerca podrá observar el avance directamente: la rama es pública, los commits son visibles, y el PORTING.md se actualiza con cada cambio metodológico. El thread de Hacker News probablemente se reactivará cada vez que aparezca un commit relevante.

Cómo seguir el experimento desde el código

Para desarrolladores que quieran seguirlo de cerca sin instalar nada, los puntos de observación son:

# Ver el árbol completo de la rama experimental
git clone --branch claude/phase-a-port https://github.com/oven-sh/bun.git bun-port
cd bun-port

# Comparar la cantidad de archivos zig vs rust
find . -name "*.zig" | wc -l
find . -name "*.rs" | wc -l

# Buscar marcadores TODO específicos del port
grep -r "TODO(port)" --include="*.rs" .
grep -r "PERF(port)" --include="*.rs" .

# Ver el grado de confianza por archivo
grep -h "CONFIDENCE:" --include="*.rs" -r . | sort | uniq -c | sort -rn

Para quien tenga una instalación de Bun en producción, no hay acción técnica requerida hoy. Los releases de la rama main se siguen produciendo desde Zig. Sin embargo, vale la pena empezar a documentar internamente la decisión: si alguna vez Bun pasa a producción Rust, querrás tener registrado el momento exacto, los flags de versión y el hash del commit del binario que estabas usando. La auditoría retrospectiva cuesta mucho más cuando se difiere.

Lección de fondo

Este episodio es un caso de estudio temprano de una pregunta que va a definir buena parte de la próxima década del software: ¿qué pasa cuando los agentes escriben código que va a producción a una escala que ningún equipo humano podría revisar línea por línea? La respuesta optimista dice que las pruebas, el control de versiones y la presión competitiva del ecosistema mantendrán la calidad. La respuesta pesimista dice que el código generado por agentes va a tener categorías nuevas de bugs sutiles —patrones de error que humanos no producirían— y que el ecosistema todavía no tiene herramientas para detectarlos.

Lo interesante de Bun es que la decisión se toma a la vista del público, en un repositorio open source, con un mantenedor que verbaliza explícitamente su postura. No es una empresa cerrada decidiendo internamente cómo escribe su backend; es un proyecto que millones de personas instalan, ejecutado por agentes que esos mismos millones consumen, en un lenguaje cuya gobernanza se opone a la práctica que el proyecto adopta. Las tensiones de la próxima década en el open source quedan condensadas en este experimento. Vale la pena seguirlo.

Fuentes

Bun — sitio oficial
Bun — repositorio principal en GitHub
PORTING.md — guía oficial del port Zig → Rust (rama claude/phase-a-port)
The Register — Bun posts Rust porting guide, says rewrite is still half-baked
Hacker News — Bun is being ported from Zig to Rust
Lobsters — Bun (the js runtime) is being vibe-ported from zig to rust
kristoff.it — Contributor poker and AI (Loris Cro, abril 2026)
Wikipedia — Bun (software)
Wikipedia — Zig (programming language)
Wikipedia — Rust (programming language)
elsolitario.org — Anthropic y Bun: ¿el runtime seguirá el camino de Claude Code? (4 mayo 2026): https://elsolitario.org/2026/05/04/anthropic-bun-claude-code-runtime-2026/