Bun lanzó código de IA inseguro
Bun reescribió recientemente su núcleo en Rust. También añadieron multihilo experimental. Estos son movimientos importantes. Sin embargo, el método utilizado para alcanzar estos objetivos es preocupante.
El equipo de Bun admitió que Claude AI escribió gran parte de la reescritura en Rust. Este cambio añadió más de 13,000 bloques unsafe a la base de código. También se lanzó sin un recolector de basura concurrente.
En la programación de sistemas, el código unsafe elude la seguridad de memoria. Un bloque unsafe es un riesgo. Trece mil bloques de una IA son un peligro.
Entiendo la necesidad de velocidad. Los equipos pequeños deben moverse rápido para competir con Node.js y Deno. Pero la velocidad sin cuidado es peligrosa.
Cada bloque unsafe es una promesa de acceso válido a la memoria. Cuando una IA escribe el código, ¿quién firma esa promesa?
Los riesgos son claros:
- El código de IA carece del razonamiento humano para la gestión de memoria.
- La generación de alta velocidad requiere una revisión de alta velocidad.
- La falta de un recolector de basura concurrente hace que las cargas de trabajo multihilo sean inestables.
Un runtime no es una simple librería. Es la base de toda tu aplicación. Eliges un runtime basándote en la confianza. Cuando la infraestructura se siente experimental, los desarrolladores vuelven a herramientas estables como Node.js.
Uso herramientas de IA todos los días. Trato el código de la IA de la misma manera que trato el código de un ingeniero junior. Necesita una revisión que esté a la altura de su impacto.
El impacto del multihilo dentro de un runtime es masivo. Trece mil bloques unsafe necesitan trece mil buenas razones. No necesitan trece mil aprobaciones automáticas.
Ser ambicioso es bueno. Ser descuidado con el código de sistemas es un riesgo.
¿Ejecutarías 13,000 bloques unsafe generados por IA en tu aplicación de producción? ¿Cuál es tu límite de confianza en la IA para la infraestructura?
Comunidad de aprendizaje opcional: https://t.me/GyaanSetuAi