El 7 de octubre de 2026, Theo Browne publicó bajo licencia libre el repositorio ts-rust y su correspondiente paquete de npm, tsc-rs. Se trata de una migración de código colosal: portar a Rust el compilador nativo de TypeScript 7 de Microsoft, su comprobador de tipos y el protocolo LSP (Language Server Protocol), que la compañía había rescrito previamente en Go. El proyecto calca fielmente las estructuras algorítmicas, el comportamiento, los comandos de terminal y las API de la versión oficial, fijando su base de código estrictamente en la versión TypeScript 7.1.0-dev del 29 de septiembre de 2026 (revisión 673a5f17d713). Ante un mismo objetivo de ingeniería, dos de las familias de modelos más avanzadas arrojaron una factura y unos plazos con un orden de magnitud de diferencia.
400.000 dólares a tarifa de API frente a 24.000 dólares en gasto real de suscripción
El intento inicial del autor dependió de GPT-5.6 Sol y GPT 6 Astra. Durante varios meses de bucles autónomos /goal, estos modelos consumieron el equivalente a más de 400.000 dólares a precios estándar de API y produjeron 1,3 millones de líneas de código en Rust, pero quedaron encallados sin remedio en un 84 % de compatibilidad. Tras cambiar a Claude Opus 5.5, la migración completa se cerró en apenas dos semanas. En X, el autor resumió la experiencia sin rodeos: «Quemé unos 400.000 dólares en tokens de Codex para no conseguir nada; quemé unos 20.000 dólares en Opus y lo resolví en dos semanas».
Esa cifra de 400.000 dólares refleja únicamente el valor nominal a tarifa de venta al público de la API. En la práctica, el gasto efectivo facturado a Opus fue de unos 24.047 dólares al aprovechar las cuotas de suscripciones profesionales de alto nivel, lo que equivalió a entre el 925 % y el 983 % del límite semanal de un plan de 200 dólares. El cuello de botella en proyectos de software a muy largo plazo radica en si el modelo es capaz de sostener el contexto y en si tiene la determinación de borrarlo todo cuando detecta que el trabajo acumulado es inservible. Pagar esa misma tarea a tarifa comercial de API quebraría la tesorería de cualquier equipo pequeño; por eso solo resultó viable dentro del esquema de tarifas planas de suscripción.
Figura: Comparativa de gasto en tokens y tiempo de ejecución entre ambos intentos. Fuente: @theo / X
Desechar 1,3 millones de líneas: empezar de cero como decisión estratégica
Al intervenir Opus 5.5, el modelo no intentó remendar el millón trescientas mil líneas de código dejadas por Astra. Dictaminó que esos archivos estaban en un estado irreparable, creó un crate completamente nuevo y arrancó desde cero. Apenas diez horas después, entregó una versión v0 funcional, superando de golpe las semanas de tropiezos del modelo anterior.
Bajo la presión de cientos de miles de tokens de contexto, la audacia de un agente para purgar artefactos inservibles y reiniciar el proyecto determina si este acabará estancado a mitad de camino. En tareas de generación de código prolongadas, acumular parches sobre cimientos viciados solo desemboca en cascadas de errores impredecibles. Hacer borrón y cuenta nueva resulta infinitamente más eficiente que seguir remendando código defectuoso, desafiando la tendencia humana a aferrarse a los costes hundidos.
Una línea defensiva respaldada por 181.711 pruebas upstream
En el apartado de advertencias del repositorio bajo licencia MIT —que rápidamente cosechó 572 estrellas y 5.963 commits—, el autor dejó una advertencia tajante: «No he leído una sola línea de este código». De hecho, todo el contenido del README a partir de la línea divisoria fue redactado íntegramente por Claude Code. La audacia de publicar un proyecto mastodóntico sin revisar una sola línea descansa por completo en la verificación automatizada: los 181.711 casos de prueba portados desde la versión en Go pasaron sin excepción.
Durante la fase de validación, los diagnósticos obtenidos en proyectos reales como el núcleo de TanStack Query y Hono coincidieron uno a uno con la versión en Go, y las respuestas del servidor de lenguaje y la API en las suites oráculo calcaron el comportamiento upstream. Tras evaluar 120 repositorios de código abierto, las discrepancias en la salida por terminal se limitaron a un puñado de problemas ya conocidos. La fiabilidad de bases de código generadas por LLM depende por entero de la barrera de contención que ofrecen las suites de pruebas upstream; la revisión manual basada en el ancho de banda cognitivo humano ha quedado desterrada de la cadena de confianza.
Figura: Tarjeta de vista previa social del repositorio ts-rust. Fuente: GitHub
Por detrás de Bun en velocidad pura, pero con diagnósticos de Effect integrados
El autor midió el rendimiento mediante hyperfine en un chip Apple M4 Pro (tomando la mediana de cinco ejecuciones) para fijar el perfil de velocidad. En la comprobación de tipos de seis proyectos de código abierto, la velocidad de media geométrica de tsc-rs fue 1,61 veces superior a la de tsc 7. En el proyecto de VS Code, con 3,75 millones de líneas de código, tsc 6 tardó 54,56 segundos y tsc 7 necesitó 6,84 segundos, mientras que tsc-rs redujo la marca a 4,20 segundos. Dado que las versiones de prueba actuales no incorporan optimizaciones de perfilado PGO ni BOLT, las entregas oficiales serán todavía más rápidas. Con todo, la utilidad bun check de Bun completó la comprobación de VS Code en tan solo 1,62 segundos, manteniéndose como el líder indiscutible en velocidad pura.
Donde tsc-rs demostró una ventaja arquitectónica sustancial fue en diagnósticos especializados de ecosistema. En las pruebas combinadas sobre los cinco subproyectos de T3 Code, sin diagnósticos de Effect, tsc-rs marcó 7,25 segundos frente a los 16,10 segundos de tsc 7. Al activar los diagnósticos de Effect (códigos de error 377xxx), tsc-rs tardó 11,13 segundos, frente a los 21,07 segundos que demandaba tsc 7 combinado con @effect/tsgo. Al integrar las reglas de Effect directamente en la pasada principal del compilador, se suprime por completo el coste de un segundo análisis del árbol sintáctico. Para acceder a este flujo de diagnóstico unificado, a los desarrolladores les basta con ejecutar npm install -D tsc-rs.
Límites de plataforma y la factura computacional desatan la controversia
Como proyecto experimental primerizo, tsc-rs afronta limitaciones claras de entorno. Por el momento solo admite distribuciones Linux x64 con enlace estático y la arquitectura macOS arm64, quedando pendientes Windows y Linux arm64. Entre los problemas documentados destacan errores TS6059 en ciertas estructuras de monorrepositorio (avisos de que ciertos archivos no residen bajo rootDir) y salidas desactualizadas ocasionales con tsc -b. Curiosamente, cuatro de los primeros cinco reportes abiertos en GitHub simplemente reproducían el comportamiento original de TypeScript. Cuando una herramienta copia con precisión milimétrica el sistema upstream, los defectos de este último quedan inevitablemente consagrados como características.
En los hilos de discusión de Hacker News, la arquitectura técnica quedó pronto eclipsada por divergencias de fondo. Hubo quienes sacaron la calculadora para señalar que con 400.000 dólares se habría contratado a un ingeniero de compiladores de primer nivel durante un año completo, en lugar de transferir ese capital a granjas de computación. Otros intervinieron para recordar que esos 400.000 dólares eran un valor nominal inflado de API y que el desembolso real apenas rozó los 24.000. También afloraron dudas sobre si es legítimo publicar código generado por IA sin la más mínima supervisión humana, e incluso hubo quien calificó el README de mera cuña publicitaria a favor de Claude Code. Con la barrera económica del desarrollo reducida al pago de una suscripción mensual, el debate central de la ingeniería de software ha dejado de centrarse en cómo escribir código para focalizarse en la ecuación que equilibra el coste computacional y la retribución del trabajo humano.
Enlaces de referencia:
- Publicación de Theo Browne en X
- README del repositorio pingdotgg/ts-rust
- Discusión comunitaria sobre la reescritura de TypeScript con IA
