Forem: Juan Torchia

Nunca más tipees openssl x509 -text -noout: creé una extensión de VS Code para ver certificados SSL/TLS

Juan Torchia — Wed, 08 Apr 2026 11:36:42 +0000

Eran las 11 de la noche, había un incidente en producción, y yo estaba con tres terminales abiertas intentando recordar si era openssl x509 -text -noout -in cert.pem o openssl pkcs12 -info -in keystore.p12 -noout. El servidor tiraba TLS handshake failed y yo necesitaba confirmar en dos segundos si el certificado que habíamos desplegado era el correcto o si alguien había subido el de staging por error.

Ese momento de furia silenciosa donde querés pegar un grito pero son las 11 de la noche y tu familia está durmiendo — lo conocés, ¿no?

Ahí decidí que iba a construir algo para no volver a vivirlo.

Veintipico años mirando certificados en una terminal negra

Cuando empecé a administrar servidores en el hosting allá por 2007, los certificados SSL eran una rareza cara que solo las empresas grandes podían pagar. Yo los veía como objetos místicos: archivos binarios raros con extensiones que nadie sabía bien qué significaban — .pem, .der, .p12, .pfx, .crt, .cer. La misma cosa con seis nombres distintos dependiendo de quién los generó.

Aprendí a leerlos con openssl en la terminal como aprendí todo en esa época: rompiendo cosas en producción y rezando. Con el tiempo lo interioricé. Pero nunca dejó de ser un quilombo.

Después vino Let's Encrypt en 2015, los certificados se democratizaron, y de repente todos los proyectos tienen SSL. Renovaciones automáticas, cadenas de certificados, SANs con 40 dominios, keystores de Java para los proyectos enterprise con Spring Boot... El volumen de archivos de certificados que pasan por un workspace moderno es brutal.

Y cada vez que necesitás inspeccionar uno, la historia es la misma: salís de VS Code, abrís una terminal, tratás de recordar el comando, lo googleás si no te acordás, lo ejecutás, leés un wall of text que ocupa media pantalla, y cerrás la terminal. Flujo destruido.

El problema real no es el comando, es el contexto switching

Mirá esto. Cuando trabajás en una aplicación que consume servicios externos, validar los certificados es parte del ciclo de desarrollo normal. Estás configurando mutual TLS para conectarte a una API bancaria, o estás depurando por qué el cliente Java no confía en el certificado del servidor, o simplemente querés verificar que el .p12 que te mandó el equipo de seguridad tiene el CN correcto antes de meterlo en Kubernetes como un Secret.

El problema no es que openssl sea difícil. El problema es que te saca del contexto. Tenés el archivo ahí, en el explorador de VS Code, y para ver su contenido tenés que hacer un viaje de ida y vuelta a la terminal. Es como tener que salir a la calle para ver qué hay en la heladera.

Los archivos de imagen los podés previsualizar directamente. Los PDF también, con extensiones. Los SVGs se renderizan solos. ¿Por qué los certificados X.509 no?

Así nació gmm.certview

La idea era simple: doble click en un .pem y VS Code te muestra todo. Sin terminal. Sin recordar flags. Sin contexto switching.

El stack fue casi obvio para mí: TypeScript porque estoy en el ecosistema VS Code, y node-forge para el parsing criptográfico porque es la librería más completa y madura del ecosistema Node.js para manejar PKI. No quería depender de binarios externos ni de llamadas al sistema — necesitaba que todo funcionara 100% offline, en modo avión si hacía falta, y especialmente en ambientes corporativos donde instalarte cualquier cosa es un trámite de tres formularios y dos aprobaciones.

La pieza técnica más interesante fue el Custom Editor Provider de VS Code. En vez de registrar un comando que abrís manualmente, la extensión se registra como el editor nativo para ciertos tipos de archivo. VS Code le dice "oye, el usuario quiere abrir este .pem, ¿vos lo manejás?" y la extensión responde que sí y toma control.

// Así registrás un Custom Editor Provider en VS Code
// El 'viewType' tiene que matchear el que declarás en package.json
vscode.window.registerCustomEditorProvider(
  'gmm.certview.editor', // identificador único de tu editor
  new CertificateEditorProvider(context),
  {
    // Mantiene el webview en memoria aunque no sea la pestaña activa
    // Importante para no re-parsear el cert cada vez que cambiás de tab
    webviewOptions: { retainContextWhenHidden: true },
    // Permite que múltiples tabs abran el mismo archivo
    supportsMultipleEditorsPerDocument: false,
  }
);

El provider recibe el contenido del archivo como Uint8Array y lo manda a node-forge para el parsing. Después renderiza todo en un Webview — básicamente una página HTML corriendo dentro de VS Code con acceso restringido al sistema.

Lo que ves cuando abrís un certificado

Abrís un .pem, .crt, .cer o .der y en vez del texto en base64 o el binario incomprensible, te aparece un panel con:

Subject e Issuer — quién es y quién lo firmó, con los campos del Distinguished Name bien separados (CN, O, OU, C, etc.) en vez del string gigante CN=api.empresa.com, O=Empresa S.A., C=AR.

Fechas de validez con alerta visual — esto fue lo primero que implementé porque es lo que más importa en un incidente. Verde si está vigente, amarillo si vence en menos de 30 días, rojo si ya expiró. Sin tener que calcular nada mentalmente.

// Lógica de alertas de vencimiento
// node-forge devuelve las fechas como objetos Date en cert.validity
function getCertificateStatus(notAfter: Date): 'valid' | 'expiring' | 'expired' {
  const ahora = new Date();
  const diasRestantes = Math.floor(
    (notAfter.getTime() - ahora.getTime()) / (1000 * 60 * 60 * 24)
  );

  if (diasRestantes < 0) return 'expired';      // Rojo — ya expiró
  if (diasRestantes <= 30) return 'expiring';   // Amarillo — ojo con esto
  return 'valid';                               // Verde — todo bien
}

Fingerprints SHA-1 y SHA-256 con un botón de copiar al portapapeles. Cuántas veces tuve que comparar fingerprints manualmente carácter por carácter en una terminal para verificar que dos certificados eran el mismo. Con el botón de copiar, lo pegás directo donde lo necesitás.

Clave pública — algoritmo (RSA, ECDSA, EdDSA) y tamaño en bits. Si alguien te manda un certificado RSA de 1024 bits en 2024, lo ves de entrada y mandás para atrás el pedido.

Extensiones X.509 y SANs — los Subject Alternative Names listados limpiamente. Cuándo un certificado dice que es válido para *.empresa.com y para empresa.com y para cuatro servicios internos más, lo ves de un vistazo.

Formatos soportados: no solo el .pem de toda la vida

Aquí es donde la cosa se pone buena para los que trabajan en ambientes enterprise.

PKCS#7 / .p7b — cadenas de certificados. Cada cert del bundle aparece en su propia pestaña dentro del panel. Muy útil para validar que la cadena está completa antes de configurar Nginx o un load balancer.

PKCS#12 / .p12 / .pfx — keystores con contraseña. La extensión te muestra un prompt, ingresás la password, y te abre el contenido: certificado, clave privada (muestra el tipo y tamaño, no el material de clave — no somos locos), y los certificados de la cadena. Esto en una terminal son tres comandos distintos con flags diferentes.

CSRs PKCS#10 — Certificate Signing Requests. Podés verificar que el CN y los SANs del CSR que estás a punto de mandar a la CA son los que querés antes de hacerlo.

CRLs — Certificate Revocation Lists. Menos común pero cuando lo necesitás, lo necesitás.

Panel sidebar del workspace — esto lo agregué después porque me di cuenta de que el problema no era solo abrir un cert individual. A veces querés ver todos los certificados del proyecto de una: cuál vence primero, si hay alguno ya expirado, etc. El sidebar escanea el workspace y lista todo con sus estados visuales.

Sin telemetría. En serio.

Esto lo digo explícitamente porque sé que importa. En ambientes corporativos financieros, de salud o gobierno, no podés usar extensiones que mandan datos a ningún lado. Los certificados son material criptográfico sensible — pueden ser certificados de producción, de servicios internos, de infraestructura crítica.

gmm.certview no manda ningún dato a ningún servidor. Todo el procesamiento ocurre localmente en tu máquina con node-forge. No hay analytics, no hay telemetría de uso, no hay nada. El código está disponible para auditar si tu equipo de seguridad lo requiere.

Funciona en modo avión. Funciona en redes corporativas con proxy restrictivo. Funciona en máquinas virtuales air-gapped. Si VS Code corre, la extensión funciona.

Instalación en dos clics

Podés instalar X509 Certificate Utility directo desde el marketplace:

https://marketplace.visualstudio.com/items?itemName=gmm.certview

O desde VS Code: Ctrl+P → ext install gmm.certview → Enter. Listo.

Después de instalar, hacé doble click en cualquier archivo .pem, .crt, .cer, .p12, .pfx, .p7b o .csr en el explorador de VS Code. Debería abrirse el viewer automáticamente. Si por algún motivo VS Code lo abre como texto, click derecho → "Reopen with" → "X509 Certificate Viewer".

Los errores que cometí en el camino

Error 1: subestimar los encodings. Pensé que todos los .pem eran iguales. No. Hay PEM con PKCS#1, PKCS#8, con headers específicos, con y sin bag attributes cuando vienen de un PKCS#12 exportado. Tuve que manejar cada variante por separado y agregar fallbacks. Si encontrás un archivo que no parsea bien, mandame el error (sin el cert, obvio) y lo agrego.

Error 2: el Webview y el Content Security Policy. VS Code tiene restricciones bastante estrictas sobre lo que podés hacer en un Webview. La primera versión tiraba errores de CSP en la consola de desarrollo. Tuve que revisar todos los estilos y scripts inline y mover todo a recursos locales con los URIs correctos usando webview.asWebviewUri().

Error 3: asumir que node-forge maneja todo. Para algunos casos edge de PKCS#12 con algoritmos más exóticos, node-forge tira excepciones crípticas. Tuve que agregar manejo de errores más granular y mensajes descriptivos para que el usuario entienda qué pasó en vez de ver "Error: invalid asn1 encoding".

Por qué existe el estándar X.509 y por qué es así de complicado

X.509 viene de 1988. Sí, 1988 — el año en que se publicó como parte del estándar X.500 de la ITU-T para directorios distribuidos. La Internet de hoy usa una versión evolucionada (v3, de 1996) con extensiones que se fueron agregando para soportar casos de uso que en 1988 nadie imaginaba: Subject Alternative Names para múltiples dominios, Extended Key Usage para distinguir certs de servidor de certs de código signing, OCSP para revocación en tiempo real.

La cantidad de formatos de archivo existe porque cada ecosistema fue haciendo lo suyo: OpenSSL popularizó el PEM (Privacy Enhanced Mail — sí, originalmente era para emails cifrados). Java usa JKS y PKCS#12. Windows usa PFX. Cada uno con sus propias convenciones.

Entender esto ayuda a entender por qué la herramienta tenía que soportar todos esos formatos. No es capricho, es la realidad de los proyectos modernos donde conviven stacks distintos.

Qué viene después

Hay algunas cosas en el roadmap que me tienen entusiasmado:

Validación de cadena de confianza: dado un certificado de leaf y una CA bundle, verificar que la cadena es válida sin salir de VS Code.
Comparación de certificados: seleccionar dos certs y ver las diferencias resaltadas. Muy útil para verificar rotaciones.
Decodificación de campos OID desconocidos: hay extensiones X.509 propietarias de algunas CAs que node-forge no conoce. Quiero agregar una lookup table.
Soporte para JKS de Java: técnicamente necesitaría re-implementar el formato JKS en TypeScript o usar una librería Java via WASM. Es el challenge más interesante que tengo por delante.

Si usás la extensión y tenés feedback, podés abrir un issue en el repo o contactarme directo. Los casos edge que más me interesan son los de ambientes enterprise con configuraciones raras — esos son los que hacen que la herramienta sea realmente robusta.

La próxima vez que estés en un incidente a las 11 de la noche tratando de recordar el comando de openssl, espero que puedas simplemente hacer doble click y seguir.

Instalala: marketplace.visualstudio.com/items?itemName=gmm.certview

Este artículo fue publicado originalmente en juanchi.dev

Harté de esperar que alguien maintuviera la extensión de HAProxy para VS Code — así que la hice yo

Juan Torchia — Wed, 08 Apr 2026 05:22:37 +0000

Hay un momento específico en el que te das cuenta de que esperaste demasiado. Para mí fue un martes a las 11 de la noche, con tres ventanas de VS Code abiertas, un HAProxy 2.8 corriendo en Docker, y un error de validación que no entendía por qué estaba fallando. Abro la extensión de syntax highlighting que tenía instalada — la única que existía en el marketplace — y veo que el último commit fue en 2019.

Cinco años sin un solo cambio. HAProxy pasó de la versión 2.0 a la 3.1 en ese tiempo. Metieron log-format-sd, reescribieron el comportamiento de option http-server-close, deprecaron directivas enteras. Y la extensión ahí, congelada en el tiempo como una momia digital, sin saber nada de nada.

Ese martes dije: basta. Si nadie lo va a hacer, lo hago yo.

Por qué HAProxy merece una extensión decente (y por qué casi nadie habla de esto)

Antes de meterme en el código, necesito darte contexto porque sé que el 80% de los devs que leen esto trabajan con Nginx o Traefik y creen que HAProxy es "esa cosa vieja que usan los bancos". Y sí, tienen razón en la segunda parte — los bancos lo usan, las telcos lo usan, los exchanges de crypto lo usan. Pero no porque sea viejo. Sino porque es brutalmente eficiente y tiene el modelo de configuración más expresivo que existe para un proxy.

Yo lo uso todos los días. En el trabajo para balancear tráfico entre microservicios. En mi homelab tengo un stack con HAProxy al frente, tres backends de servicios internos, rate limiting por IP, ACLs que distinguen tráfico de la LAN del tráfico que viene por VPN, y health checks cada cinco segundos. Todo en un archivo .cfg que tiene más de 400 líneas.

El problema es que ese archivo .cfg es básicamente texto plano para cualquier editor. Sin schema, sin LSP, sin nada. Escribís frontend mi-frontend y el editor no sabe que adentro de ese bloque hay directivas específicas que no existen en ningún otro contexto. Escribís backend y no te sugiere balance roundrobin versus balance leastconn. Usás una directiva que fue deprecada en 2.6 y nadie te avisa.

Eso es exactamente lo que fui a arreglar.

La arquitectura: no era tan simple como "un JSON con keywords"

La primera semana pensé que iba a ser fácil. "Meto todas las keywords en un archivo de gramática TextMate, le doy colores, listo". Esa ingenuidad duró exactamente hasta que abrí el spec completo de configuración de HAProxy.

HAProxy tiene una arquitectura de secciones: global, defaults, frontend, backend, listen, peers, resolvers, userlist, cache, program. Y cada sección acepta un subconjunto diferente de directivas. bind solo existe en frontend y listen. server solo existe en backend y listen. mode existe en varias pero con diferentes valores permitidos dependiendo del contexto.

Eso no se puede resolver con TextMate grammars. Eso necesita un Language Server Protocol real.

// src/server/haproxy-language-server.ts
// El corazón del LSP — inicializamos las capacidades que vamos a soportar
import {
  createConnection,
  TextDocuments,
  ProposedFeatures,
  CompletionItem,
  CompletionItemKind,
  TextDocumentSyncKind,
} from 'vscode-languageserver/node';
import { TextDocument } from 'vscode-languageserver-textdocument';
import { HaproxyParser } from './parser/haproxy-parser';
import { CompletionProvider } from './providers/completion-provider';
import { DiagnosticsProvider } from './providers/diagnostics-provider';

const connection = createConnection(ProposedFeatures.all);
const documents = new TextDocuments(TextDocument);

// Cuando el cliente (VS Code) nos pide completions, necesitamos saber
// en qué sección estamos parados para dar sugerencias contextuales
connection.onInitialize(() => ({
  capabilities: {
    textDocumentSync: TextDocumentSyncKind.Incremental,
    completionProvider: {
      resolveProvider: true,         // habilitamos el detalle de cada ítem
      triggerCharacters: [' ', '\t'] // autocompletado al tipear espacio o tab
    },
    definitionProvider: true,        // go-to-definition para backends
    codeActionProvider: true,        // quickfix para directivas deprecadas
    diagnosticProvider: {
      interFileDependencies: false,
      workspaceDiagnostics: false
    }
  }
}));

El parser fue la parte más complicada y la que más tiempo me llevó. HAProxy no tiene un formato estricto tipo YAML o JSON — es un lenguaje de configuración propio con indentación opcional, comentarios con #, continuación de línea con \, y una semántica de contexto que depende enteramente de en qué sección estás.

// src/server/parser/haproxy-parser.ts
// Parser que entiende el contexto de sección — clave para todo lo demás
export interface ParsedSection {
  type: SectionType;      // 'global' | 'defaults' | 'frontend' | 'backend' | etc.
  name: string | null;    // nombre de la sección (null para global/defaults)
  startLine: number;
  endLine: number;
  directives: ParsedDirective[];
}

export class HaproxyParser {
  parse(text: string): ParsedSection[] {
    const lines = text.split('\n');
    const sections: ParsedSection[] = [];
    let currentSection: ParsedSection | null = null;

    lines.forEach((line, lineNumber) => {
      const trimmed = line.trim();

      // Ignoramos comentarios y líneas vacías
      if (trimmed.startsWith('#') || trimmed === '') return;

      // Detectamos el inicio de una nueva sección
      const sectionMatch = trimmed.match(
        /^(global|defaults|frontend|backend|listen|peers|resolvers|userlist|cache|program)\s*(\S*)$/
      );

      if (sectionMatch) {
        // Cerramos la sección anterior si existe
        if (currentSection) {
          currentSection.endLine = lineNumber - 1;
          sections.push(currentSection);
        }

        // Iniciamos la nueva sección con su tipo y nombre
        currentSection = {
          type: sectionMatch[1] as SectionType,
          name: sectionMatch[2] || null,
          startLine: lineNumber,
          endLine: -1, // se completa cuando encontramos la próxima sección
          directives: []
        };
        return;
      }

      // Si estamos dentro de una sección, parseamos la directiva
      if (currentSection) {
        currentSection.directives.push(
          this.parseDirective(trimmed, lineNumber)
        );
      }
    });

    // No olvidemos cerrar la última sección
    if (currentSection) {
      (currentSection as ParsedSection).endLine = lines.length - 1;
      sections.push(currentSection as ParsedSection);
    }

    return sections;
  }
}

El autocompletado contextual: la feature que cambió todo

Una vez que tenía el parser funcionando, el autocompletado contextual fue casi natural. La idea es simple: cuando VS Code te pide completions, le preguntás al parser "¿en qué sección está el cursor?" y filtrás las sugerencias en base a eso.

¿Estás en un frontend? Te ofrezco bind, mode, acl, use_backend, default_backend, option, timeout... pero NO te ofrezco server ni balance, que son de backend. ¿Estás en global? Te ofrezco maxconn, daemon, log, ssl-default-bind-options... y nada más.

Esto parece trivial pero la diferencia en la experiencia de uso es brutal. En una configuración de HAProxy compleja con 10 secciones, el autocompletado que no entiende contexto te tira 200 opciones mezcladas. El mío te tira exactamente las que aplican a donde estás parado.

Pero el feature que más me enorgullece es el go-to-definition para backends. Si en tu frontend tenés default_backend mi-api y presionás F12, te lleva directo a la sección backend mi-api. Suena simple. Pero cuando tu config tiene 400 líneas y 15 backends, ese F12 te ahorra literalmente minutos de scroll todos los días.

Validación multi-versión: el quilombo de HAProxy 2.4 a 3.1

Acá es donde me volví un poco loco. HAProxy cambió bastante entre versiones. Cosas que eran válidas en 2.4 quedaron deprecadas en 2.6, y otras directamente removidas en 3.0. Si la extensión no sabe qué versión estás usando, los diagnósticos van a estar llenos de falsos positivos o falsos negativos.

La solución fue agregar una setting en VS Code donde el usuario declara su versión de HAProxy:

// .vscode/settings.json — configuración por workspace
{
  "gmm-haproxy.version": "2.8",
  "gmm-haproxy.strictMode": true
}

Y del lado del servidor, mantengo un registro de qué directivas existen en qué versión, cuáles fueron deprecadas y cuándo, y cuáles fueron removidas:

// src/server/schema/version-registry.ts
// Registry de directivas por versión — acá está el conocimiento duro de HAProxy
export interface DirectiveInfo {
  name: string;
  sections: SectionType[];        // en qué secciones es válida
  since: string;                  // versión en que fue introducida
  deprecated?: string;            // versión en que fue deprecada
  removed?: string;               // versión en que fue removida
  replacement?: string;           // directiva recomendada si fue deprecada
  description: string;
}

// Ejemplo real de directivas con su historial de versiones
export const DIRECTIVE_REGISTRY: DirectiveInfo[] = [
  {
    name: 'option forwardfor',
    sections: ['frontend', 'backend', 'listen', 'defaults'],
    since: '1.3',
    description: 'Agrega el header X-Forwarded-For con la IP real del cliente'
  },
  {
    name: 'reqadd',
    sections: ['frontend', 'listen', 'backend'],
    since: '1.3',
    deprecated: '2.2',         // deprecada en 2.2
    removed: '3.0',            // removida en 3.0
    replacement: 'http-request set-header', // la alternativa moderna
    description: '[DEPRECADA] Agregaba headers a la request. Usá http-request set-header'
  },
  {
    name: 'http-request set-header',
    sections: ['frontend', 'backend', 'listen'],
    since: '2.2',
    description: 'Modifica o agrega headers HTTP en la request entrante'
  }
  // ... y así con ~400 directivas más
];

Cuando el DiagnosticsProvider detecta que usás reqadd en una config con version 3.0, te tira un error con quickfix incluido: "Reemplazar por http-request set-header". Un click y listo.

Los errores que cometí (y que vos vas a cometer si hacés algo parecido)

Error 1: Subestimar el tiempo de startup del LSP. El primer prototipo parseaba el documento entero en cada keystroke. En archivos grandes, el lag era notable. La solución fue parsing incremental — solo re-parseás las secciones que cambiaron.

Error 2: No manejar configs incompletas. Mientras escribís, tu config está rota la mayoría del tiempo. El parser tiene que ser tolerante a errores y producir un AST parcial útil en lugar de explotar. Tomó dos semanas extra hacer el error recovery decente.

Error 3: Creer que la API de VS Code es estable. Entre la versión que leí en la doc y la versión que tenía instalada, había diferencias sutiles en cómo funcionaba onDocumentDiagnostic. Aprendí a siempre testear contra la versión mínima declarada en el engines.vscode del package.json.

Error 4: No tener un corpus de configs reales para testear. Armé un directorio con configs reales anonimizadas de mi homelab y del trabajo. Eso solo encontró más bugs que cualquier test unitario que escribí.

El resultado: lo que uso todos los días

Hoy gmm-haproxy-vscode tiene:

Syntax highlighting contextual — diferencia visualmente entre nombres de sección, directivas, valores, ACL names y comentarios
LSP propio con autocompletado filtrado por sección
Validación en tiempo real contra el schema de la versión declarada (2.4, 2.6, 2.8, 3.0, 3.1)
Go-to-definition para backends referenciados en use_backend y default_backend
Quickfix automático para directivas deprecadas
Hover documentation — pasás el mouse por cualquier directiva y te explica qué hace
Snippets para estructuras comunes: frontend básico, backend con health check, ACL de rate limiting

La semana pasada la usé para refactorizar toda la config de mi homelab de HAProxy 2.8 a 3.1. Sin la extensión, ese proceso hubiera sido un domingo entero de revisar el changelog y buscar directivas obsoletas a mano. Con la extensión, fueron dos horas — la mayoría del tiempo la pasé aplicando quickfixes.

Por qué hice esto y no simplemente usé Nginx

Alguien me va a preguntar eso, así que lo respondo antes. HAProxy hace cosas que Nginx no hace igual de bien. El modelo de ACLs de HAProxy es extraordinariamente expresivo. Podés tomar decisiones de routing basadas en headers, paths, source IPs, tiempo del día, peso del backend, número de conexiones activas — todo en el archivo de config, sin scripting. El health checking es más granular. El modelo de estadísticas via socket es más completo.

¿Es la herramienta correcta para todo? No. Para un proyecto personal chico, Traefik o Caddy son más cómodos. Pero cuando tenés tráfico real y necesitás control fino, HAProxy sigue siendo el rey. Y el rey se merece una extensión que no sea un zombie del 2019.

Si querés probar gmm-haproxy-vscode, la vas a encontrar en el VS Code Marketplace. Si encontrás un bug o una directiva que no reconoce — y seguro vas a encontrar, el spec de HAProxy es enorme — abrí un issue. Lo maintaingo activamente porque lo uso todos los días. Esa es la mejor garantía que puedo darte.

Este artículo fue publicado originalmente en juanchi.dev

Metí Gemma corriendo en el browser, sin API keys, y me cambió cómo pienso el edge

Juan Torchia — Wed, 08 Apr 2026 05:21:38 +0000

Hay una creencia instalada en la comunidad dev sobre AI en producción que está, con todo respeto, bastante equivocada: que para meter un LLM en tu app necesitás sí o sí una API key, un server que haga la inferencia, y alguien que pague la factura de OpenAI a fin de mes. La arquitectura por default en 2025 es: frontend → API call → cloud → respuesta. Siempre. Sin excepción.

Mentira.

La semana pasada corrí Gemma — el modelo abierto de Google — directo en el browser. Sin API keys. Sin servidor. Sin latencia de red. El modelo bajó, se cargó en memoria del cliente, y la inferencia corrió ahí mismo, en el dispositivo del usuario. Y en el momento en que vi la primera respuesta generarse sin que ningún request saliera a la red... pará. Esto cambia todo.

Gemma LLM browser sin API keys: qué es y por qué importa

Antes de entrar al código, contexto rápido para los que no siguieron el post anterior sobre meter un LLM chico en Next.js.

Gemma es la familia de modelos open-weights de Google DeepMind. Los modelos chicos — Gemma 2B, Gemma 3 1B — tienen un tamaño razonable para correr en hardware de consumo. Lo nuevo en 2025 es que con WebGPU y las librerías correctas, ese "hardware de consumo" incluye el browser del usuario.

Las herramientas que hacen posible esto:

WebGPU API: acceso directo a la GPU desde el browser, sin plugins
@huggingface/transformers.js: port de Transformers para el browser, WebAssembly + WebGPU
MediaPipe LLM Inference API: el approach de Google, optimizado para Gemma específicamente

Yo probé con Transformers.js porque ya tenía experiencia con el ecosistema Hugging Face y porque el modelo de distribución — cargar pesos desde CDN con cache del browser — me pareció el más práctico para un contexto de app real.

El experimento: código real, sin magia

Empecé simple. Componente de React, sin server, inferencia en el cliente. Este es el código que realmente corrí:

// components/GemmaLocal.tsx
// Inferencia completamente en el browser — sin API calls
'use client';

import { useState, useEffect, useRef } from 'react';

// Importamos pipeline de transformers.js — corre en el browser
import { pipeline, TextGenerationPipeline } from '@huggingface/transformers';

type EstadoCarga = 'idle' | 'cargando' | 'listo' | 'error';

export function GemmaLocal() {
  const [estado, setEstado] = useState<EstadoCarga>('idle');
  const [progreso, setProgreso] = useState(0);
  const [respuesta, setRespuesta] = useState('');
  const [input, setInput] = useState('');
  const pipelineRef = useRef<TextGenerationPipeline | null>(null);

  const cargarModelo = async () => {
    setEstado('cargando');

    try {
      // Gemma 2B instruct — ~1.5GB en el primer load, cacheado después
      // El modelo se descarga una vez y queda en Cache Storage del browser
      pipelineRef.current = await pipeline(
        'text-generation',
        'Xenova/gemma-2b-it', // versión cuantizada, más liviana
        {
          // Usa WebGPU si está disponible, fallback a WASM
          device: 'webgpu',
          progress_callback: (info: { progress?: number }) => {
            if (info.progress) {
              setProgreso(Math.round(info.progress));
            }
          },
        }
      );

      setEstado('listo');
    } catch (error) {
      console.error('Error cargando Gemma:', error);
      setEstado('error');
    }
  };

  const generarRespuesta = async () => {
    if (!pipelineRef.current || !input.trim()) return;

    setRespuesta('');

    // Template de Gemma instruct — importante para que responda bien
    const prompt = `<start_of_turn>user\n${input}<end_of_turn>\n<start_of_turn>model\n`;

    const resultado = await pipelineRef.current(prompt, {
      max_new_tokens: 256,
      // Streaming: cada token se emite apenas se genera
      // La respuesta aparece progresivamente sin esperar al servidor
      callback_function: (output: Array<{ generated_text: string }>) => {
        const texto = output[0]?.generated_text ?? '';
        // Extraemos solo la parte del modelo, sin el prompt
        const respuestaPura = texto.split('<start_of_turn>model\n').pop() ?? '';
        setRespuesta(respuestaPura);
      },
    });

    return resultado;
  };

  return (
    <div className="p-6 max-w-2xl mx-auto">
      {estado === 'idle' && (
        <button
          onClick={cargarModelo}
          className="px-4 py-2 bg-blue-600 text-white rounded"
        >
          Cargar Gemma (primera vez: ~1.5GB)
        </button>
      )}

      {estado === 'cargando' && (
        <div>
          <p>Descargando modelo... {progreso}%</p>
          {/* Después del primer load esto no aparece — el browser lo cachea */}
          <p className="text-sm text-gray-500">
            Solo la primera vez. Después va al instante.
          </p>
        </div>
      )}

      {estado === 'listo' && (
        <div className="space-y-4">
          <textarea
            value={input}
            onChange={(e) => setInput(e.target.value)}
            className="w-full p-3 border rounded"
            placeholder="Tu pregunta..."
            rows={3}
          />
          <button
            onClick={generarRespuesta}
            className="px-4 py-2 bg-green-600 text-white rounded"
          >
            Generar (sin internet)
          </button>
          {respuesta && (
            <div className="p-4 bg-gray-50 rounded">
              <p className="whitespace-pre-wrap">{respuesta}</p>
            </div>
          )}
        </div>
      )}
    </div>
  );
}

// app/demo-local/page.tsx
// Página standalone — zero server components necesarios para la inferencia
import { GemmaLocal } from '@/components/GemmaLocal';

export default function DemoLocalPage() {
  return (
    <main>
      <h1>Gemma en el browser — inferencia 100% local</h1>
      {/* Este componente no hace ningún fetch a ningún server nuestro */}
      <GemmaLocal />
    </main>
  );
}

Lo que pasó: primera carga, ~1.5GB de descarga (modelo cuantizado en 4-bit). Lento. Pero después del primer load, el browser lo cachea en Cache Storage. Segunda visita: el modelo está ahí, se carga en segundos.

Y la inferencia: en una máquina con GPU discreta, entre 5-15 tokens por segundo. En la mía, con una RTX 3060, llegué a 20 tokens/seg. No es GPT-4 Turbo, pero para tasks específicos — clasificación, resumen corto, extracción de datos — funciona.

El momento de "pará, esto cambia todo"

Después de que funcionó, apagué el WiFi. Escribí una pregunta. La respuesta llegó igual.

Yo vengo de 33 años viendo cómo el cómputo migra. El patrón siempre fue el mismo: el poder empieza centralizado, se democratiza hacia el edge, y en algún punto llega al dispositivo. La Amiga hacía en el cliente lo que antes necesitaba un mainframe. El cyber café donde laburé a los 14 tenía más poder de cómputo que instituciones enteras de diez años antes. Cada generación, el cliente se come un pedazo del servidor.

Lo que acaba de pasar con los LLMs es exactamente ese mismo movimiento, pero en cámara rápida.

Las implicaciones concretas:

Sin billing por inferencia. Cero costo de API. El usuario trae su propia GPU. Si tu app tiene 100.000 usuarios activos haciendo 50 queries por día, con GPT-4 eso son números que duelen. Con inferencia en el cliente, son literalmente cero dólares de inferencia.

Sin latencia de red. El round-trip a un servidor en us-east-1 desde Argentina son 200-300ms antes de que empiece a llegar el primer token. Local: 0ms. Para UX esto es brutal — la diferencia entre "espero que cargue" y "responde al instante".

Sin datos que salen del dispositivo. Para casos de uso con datos sensibles — documentos legales, notas médicas, código propietario — inferencia local cambia el juego. El dato no viaja a ningún lado.

Conectando con lo que escribí sobre sandboxes para agentes de código: parte del problema de darle autonomía a un agente es el costo y la latencia de cada LLM call. Si el modelo corre local, la economía del problema cambia completamente.

Errores y gotchas que me comí

No todo fue bonito. Los problemas reales:

WebGPU no está en todos lados. Firefox lo tiene detrás de un flag. Safari lo agregó en versiones recientes. El fallback a WebAssembly funciona, pero es 3-5x más lento. Necesitás feature detection y manejar el degraded experience.

// Detectar soporte antes de intentar cargar
const checkWebGPU = async (): Promise<boolean> => {
  if (!navigator.gpu) return false;

  try {
    const adapter = await navigator.gpu.requestAdapter();
    return adapter !== null;
  } catch {
    return false;
  }
};

// Elegir device según soporte
const device = (await checkWebGPU()) ? 'webgpu' : 'wasm';

El primer load es un problema de UX real. 1.5GB en la primera visita es mucho. Tuve que agregar una pantalla de "instalación" explícita con progreso claro. Tratarlo como una PWA que se instala, no como una página que carga.

Memoria RAM. El modelo cuantizado necesita ~1-2GB de RAM. En dispositivos con 4GB totales, esto puede freezar el tab. Necesitás setear expectativas y ofrecer fallback a API cloud para dispositivos que no den el ancho.

El modelo es chico — actúa como tal. Gemma 2B no es GPT-4. Para summarization corta, clasificación, y tareas con mucho contexto en el prompt, anda bien. Para razonamiento complejo o generación larga, los resultados son notoriamente peores. Yo calibré mis expectativas después de una hora de pruebas. El truco es diseñar la task para el modelo, no al revés.

Esto me conectó con algo que aprendí optimizando la app de Next.js que bajé de 3 segundos a 300ms: la performance no viene de apretar un botón mágico, viene de entender qué está pasando realmente y diseñar en función de eso.

Context window limitada. El modelo cuantizado que usé tiene 2048 tokens de contexto efectivo. Si mandás un documento largo, lo trunca sin avisarte. Tuve que implementar chunking explícito.

// Chunking básico para no superar el context window
const MAX_TOKENS_APROX = 1500; // margen de seguridad
const CHARS_POR_TOKEN_APROX = 4;
const MAX_CHARS = MAX_TOKENS_APROX * CHARS_POR_TOKEN_APROX;

const truncarContexto = (texto: string): string => {
  if (texto.length <= MAX_CHARS) return texto;
  // Truncamos desde el principio, preservamos el final (suele ser más relevante)
  return '...' + texto.slice(texto.length - MAX_CHARS);
};

Esto también lo sentí cuando estuve trabajando con Claude Code en febrero — el context management es el problema que nadie resuelve del todo bien todavía.

FAQ: Gemma LLM en el browser sin API keys

¿Qué navegadores soportan WebGPU para correr Gemma?
Chrome 113+ y Edge tienen soporte estable. Safari 18+ lo soporta. Firefox lo tiene detrás de dom.webgpu.enabled en about:config, no está en producción todavía. Para producción real hoy, Chrome/Edge son el target seguro. Siempre implementá fallback a WebAssembly para los demás.

¿Cuánto pesa el modelo y cómo manejo la primera descarga?
Gemma 2B cuantizado en 4-bit pesa ~1.4-1.6GB. La primera descarga es real y tarda — en conexiones lentas puede ser 5-10 minutos. La clave es tratarlo como instalación de PWA: pantalla de progreso explícita, explicación de que es una sola vez, y que después el browser lo cachea en Cache Storage. Visits siguientes: carga en segundos.

¿Qué tan rápida es la inferencia comparada con una API en la nube?
Depende mucho del hardware. En una GPU discreta moderna (RTX 3060+): 15-25 tokens/segundo con WebGPU. En hardware integrado (Apple Silicon M1): 8-15 tokens/seg. En CPU via WASM: 1-3 tokens/seg, notoriamente lento. La API de OpenAI/Anthropic entrega 50-100 tokens/seg con mejor calidad. La ventaja local no es velocidad bruta, es latencia cero de red y costo cero.

¿Funciona offline completamente?
Sí, esa es la parte que me cambió el esquema mental. Una vez que el modelo está cacheado, la inferencia corre sin ningún request de red. Lo probé apagando el WiFi. Funciona. Esto abre casos de uso que antes eran imposibles: apps para zonas con conectividad intermitente, herramientas que manejan datos sensibles que no pueden salir del dispositivo, features que funcionan en aviones/subtes/donde sea.

¿Tiene sentido para producción o es un experimento?
Hoy está en algún punto entre experimento avanzado y producción early-adopter. Los casos donde ya tiene sentido: apps con datos sensibles (legal, médico, notas personales), features nice-to-have donde el fallback es simplemente no tenerlas, usuarios tech-savvy con hardware bueno. Los casos donde todavía no escala: experiencia de usuario masivo en mobile con hardware variado, tareas que requieren el nivel de razonamiento de modelos grandes, apps donde 1.5GB de primera descarga rompe el funnel.

¿Qué pasa con móviles?
WebGPU en mobile está en desarrollo pero limitado. Chrome en Android está avanzando, iOS Safari tiene soporte parcial. El problema gordo es RAM — los phones con 4-6GB no tienen margen para cargar 1.5GB de modelo. Gemma 1B (la versión más chica, ~700MB cuantizado) es más viable para mobile. La realidad honesta: mobile-first con inferencia local todavía tiene 1-2 años por delante para ser confiable.

Conclusión: el cómputo siempre migra hacia el edge

Lo que viví con Gemma en el browser es el mismo patrón que vi cuando el cyber café donde laburé empezó a tener más poder que servers de empresas de cinco años antes. El cómputo siempre migra hacia el edge. Siempre.

No estoy diciendo que las APIs de cloud van a desaparecer. GPT-4, Claude, Gemini Pro — para los casos que necesitan el mayor nivel de capacidad, van a seguir siendo la respuesta. Pero hay toda una categoría de features — clasificación, summarización, extracción, asistencia contextual — donde un modelo chico corriendo en el cliente resuelve el problema igual de bien, sin costo de API, sin latencia de red, sin datos que salen del dispositivo.

El cambio más grande para mí no fue técnico. Fue conceptual: dejé de pensar en "LLM en mi app" como sinónimo de "API call a un cloud endpoint". Ahora es una decisión arquitectural real: ¿este modelo va en el servidor, en el edge, o en el cliente?

Y una vez que hacés esa pregunta, no podés dejar de hacerla.

Si ya leíste el post sobre LLMs chicos en Next.js y te quedaste con ganas de ir un paso más allá, este es el paso. Bajate Transformers.js, cargá Gemma, apagá el WiFi, y preguntale algo. La primera vez que responde sin que ningún paquete salga a la red, vas a tener el mismo momento que tuve yo.

Vale la pena.

Este artículo fue publicado originalmente en juanchi.dev

Sandboxes para agentes de código: qué es Freestyle y por qué me importa

Juan Torchia — Wed, 08 Apr 2026 05:21:29 +0000

En 2005, cuando administraba el cyber café a los 14 años, tuve mi primera lección sobre procesos que corren sin supervisión. Un cliente había dejado un script ejecutándose — algo que descargaba archivos, decía — y cuando lo encontré media hora después había consumido todo el ancho de banda del local. Diez máquinas inutilizadas, gente enojada, yo sin saber ni por dónde empezar. Aprendí esa noche que lo que no podés ver ejecutarse, te puede romper todo.

Hoy pienso en eso cada vez que le doy permiso a Claude Code para que haga cambios en un proyecto real.

Sandboxes para coding agents: el problema que nadie nombra bien

Hay algo que los posts sobre agentes de código evitan decir directamente: el mayor riesgo no es que escriban código malo. El código malo lo revisás, lo revertís, lo arreglás. El riesgo real es la ejecución.

Un agente que escribe código incorrecto es un problema de calidad. Un agente que ejecuta rm -rf en el directorio equivocado, o hace un npm publish sin que vos lo pidas, o llama a una API con tus credenciales cacheadas — eso es un problema de seguridad. Y es un problema que muy poca gente está nombrando con la precisión que merece.

Cuando empecé a integrar agentes de código en mi workflow — hablo de proyectos reales, no de demos — lo primero que hice fue leer los logs de lo que se ejecutaba. No porque desconfíe de Claude específicamente. Porque soy el mismo tipo que tiró un servidor de producción en su primera semana con un rm -rf. Sé exactamente cuánto daño puede hacer un comando ejecutado en el contexto equivocado.

Eso me llevó a Freestyle.

Qué es Freestyle y qué resuelve concretamente

Freestyle llegó a Hacker News hace poco con 188 puntos — número que para mí es señal de que tocó un nervio real, no hype. La propuesta es directa: un sandbox de ejecución para agentes de código.

No es un concepto nuevo. Los sandboxes existen desde siempre en seguridad. Lo nuevo es aplicarlo específicamente al problema de los coding agents que necesitan:

Correr código arbitrario
Instalar dependencias
Ejecutar tests
Posiblemente hacer requests HTTP
Todo eso sin tocar tu sistema real

Freestyle te da un entorno de ejecución aislado donde el agente puede hacer todas esas cosas. Si rompe algo, rompe el sandbox. Tu máquina, tu base de datos, tus credenciales — siguen intactas.

La arquitectura, en términos simples:

// Lo que pasa SIN sandbox (tu situación actual, probablemente)
const agentRun = async (code: string) => {
  // El agente ejecuta directamente en tu proceso Node
  // Tiene acceso a process.env (tus secrets!)
  // Tiene acceso al filesystem real
  // Un npm install modifica tu node_modules real
  eval(code) // oversimplificado, pero conceptualmente esto
}

// Lo que propone Freestyle
const agentRunSandboxed = async (code: string) => {
  // Cada ejecución corre en un ambiente aislado
  // Filesystem efímero — muere con el sandbox
  // Variables de entorno controladas explícitamente
  // Network access configurable (podés bloquearlo)
  const sandbox = await Freestyle.createSandbox({
    runtime: 'node20',
    env: {
      // Solo los secrets que querés exponer, nada más
      DATABASE_URL: process.env.SANDBOX_DATABASE_URL,
    },
    network: {
      // Podés allowlist dominios específicos
      allowedHosts: ['api.openai.com']
    }
  })

  return await sandbox.execute(code)
}

Eso, en términos prácticos, es enorme.

Cómo mapea contra mi workflow actual

Mi stack hoy es Next.js, TypeScript, PostgreSQL en Railway, y Claude Code como asistente principal. Si querés el detalle completo, está en cómo construí juanchi.dev y en el post sobre el stack que elegiría en 2025.

Cuando uso Claude Code en modo interactivo — el que sugiere cambios y los aplica — hay una tensión constante. Le doy suficiente contexto para que sea útil, lo que incluye acceso al proyecto. Pero ese acceso, por definición, incluye cosas que no quiero que toque automáticamente.

Mi solución actual es básicamente manual: reviso cada cambio antes de confirmar, tengo git en cada paso, y nunca corro sugerencias directamente en el proyecto conectado a la base de datos de producción. Funciona. Pero es fricción.

Un sandbox como Freestyle cambia esa ecuación. En lugar de yo supervisando cada micro-acción, el sandbox define los límites estructuralmente. El agente puede correr lo que quiera dentro del sandbox. Afuera del sandbox, no existe.

Para alguien que está optimizando performance en producción con agentes ayudando a generar benchmarks y tests — esto es la diferencia entre "dejo que el agente pruebe" y "tengo miedo de que el agente pruebe".

Los errores comunes cuando integrás agentes sin sandbox

Voy a ser específico porque lo viví.

Error 1: Credentials en el contexto del agente

Si tu agente corre en el mismo proceso que tu app, tiene acceso a process.env. Todo. DATABASE_URL, API keys, tokens. Si el agente hace un request HTTP — por cualquier razón — puede estar exfiltrando esas credenciales. No porque sea malicioso. Porque el contexto no está delimitado.

// ❌ Esto parece inofensivo pero no lo es
const agente = new ClaudeAgent({
  cwd: process.cwd(), // Tiene acceso a todo el proyecto
  // process.env está disponible implícitamente
})

// ✅ Explicitá qué tiene y qué no tiene
const agente = new ClaudeAgent({
  cwd: '/tmp/sandbox-workspace', // Directorio aislado
  env: {
    NODE_ENV: 'test',
    // Solo lo que necesita para la tarea específica
  }
})

Error 2: npm install sin control

Un agente que puede instalar paquetes puede instalar cualquier cosa. Hay paquetes npm con código malicioso que se ejecuta en el install. Si el agente corre en tu máquina, ese código también corre en tu máquina.

Error 3: Confiar en que el agente "va a pedir permiso"

Algunos agentes tienen mecanismos de confirmación. Bien. Pero eso es UI, no seguridad. La seguridad tiene que estar en el aislamiento del sistema, no en la buena voluntad del modelo.

Error 4: Mezclar el database de desarrollo con el de producción

Esto aplica siempre, pero con agentes se vuelve crítico. Si el agente tiene acceso a tu connection string de producción — aunque sea "para leer" — estás un paso de un error costoso. Mis patrones de TypeScript incluyen helpers específicos para separar estos contextos, pero un sandbox lo resuelve a nivel infraestructura.

Lo que me genera ruido de Freestyle (la parte crítica)

Dicho todo lo anterior — y lo digo genuinamente porque creo en el problema que resuelve — hay cosas que me generan preguntas.

El cold start es real. Crear un sandbox por ejecución tiene latencia. Para flujos interactivos donde el agente hace muchas iteraciones pequeñas, esa latencia acumula. Freestyle menciona optimizaciones de startup, pero todavía no lo medí en un workflow real.

El pricing en producción está por verse. Sandboxes como servicio tiene costos de infraestructura no triviales. Si tu agente hace 50 ejecuciones por tarea, ese modelo de pricing escala diferente que una ejecución local.

La integración con Claude Code específicamente no está documentada claramente. O al menos no la encontré cuando lo exploré. Para mi workflow principal, necesito saber cómo conecta esto con el agente que ya estoy usando, no con un agente nuevo.

No resuelve el problema de output. El sandbox aísla la ejecución, pero el código que el agente produce igual termina en tu codebase. El sandbox te salva del daño durante el proceso; el code review te salva del daño en el resultado. Los dos son necesarios.

Lo que haría diferente: antes de adoptar Freestyle como dependencia principal, construiría primero con Docker un sandbox básico propio — algo que ya cubrí en el post de Docker para Node.js — para entender los trade-offs antes de delegar esa responsabilidad a un servicio externo.

FAQ: Sandboxes para coding agents

¿Qué es un sandbox para coding agents exactamente?
Es un entorno de ejecución aislado donde un agente de código puede correr comandos, instalar dependencias y ejecutar scripts sin acceder al sistema host. Piensalo como una VM efímera: todo lo que pasa adentro, muere adentro. Tu filesystem real, tus variables de entorno y tu base de datos no son accesibles a menos que vos explícitamente lo permitas.

¿Por qué no alcanza con correr el agente en Docker localmente?
Docker es una opción válida y es lo que muchos hacemos hoy. El valor de Freestyle específicamente es que abstrae la infraestructura del sandbox y la expone como API, con lifecycle management, networking configurable y soporte para múltiples runtimes. Docker local funciona, pero tiene fricción de setup y no tiene las mismas garantías de aislamiento de red out-of-the-box.

¿Freestyle es open source o es un servicio?
Es un servicio con SDK. El SDK es open source, la infraestructura que corre los sandboxes es managed. Modelo similar a Vercel con Next.js: podés correrlo vos mismo, pero el servicio managed es el punto de entrada natural.

¿Funciona con cualquier agente de código o solo con algunos específicos?
Conceptualmente funciona con cualquier agente que necesite ejecutar código — Claude Code, GPT Engineer, Devin, o tu propio agente custom. La integración concreta depende de cómo tu agente maneja la ejecución. Si el agente llama a un subprocess o a una API de ejecución, podés redirigir esas llamadas a Freestyle. Si el agente tiene un modelo de ejecución muy acoplado, la integración es más compleja.

¿Un sandbox resuelve todos los problemas de seguridad de los coding agents?
No. El sandbox resuelve el problema de ejecución no supervisada. No resuelve: código malicioso que el agente produce y vos deployás, prompt injection si el agente procesa input externo, o el problema de qué hacés con el output del sandbox una vez que lo tenés. Es una capa de seguridad, no la seguridad completa.

¿Vale la pena para proyectos personales o solo para equipos?
Depende de cuánto usás agentes de código. Si usás Claude Code o similar ocasionalmente para sugerencias de código que vos aplicás manualmente, probablemente no necesitás un sandbox formal. Si tenés agentes corriendo de forma autónoma — haciendo commits, corriendo tests, instalando deps — un sandbox deja de ser nice-to-have y se vuelve necesario. Para mi uso actual está en el límite. Cuando pase a workflows más autónomos, voy directo al sandbox.

Conclusión: el miedo correcto

El cyber café me enseñó que el problema no es lo que ves correr — es lo que corre sin que lo estés mirando.

Los coding agents son increíblemente útiles. Los uso todos los días y no volvería atrás. Pero hay una diferencia entre usarlos como autocomplete inteligente y usarlos como agentes autónomos con acceso a tu entorno real. Esa diferencia importa.

Freestyle está apuntando al problema correcto. El sandbox no es paranoia — es el mismo principio que me llevó a tener bases de datos separadas por ambiente, a usar secrets managers en lugar de .env en producción, y a nunca correr código de terceros con más permisos de los necesarios. Principios que cualquiera que haya trabajado en infraestructura real entiende visceralmente.

Lo que haría hoy: si ya estás usando agentes en proyectos reales, revisá qué acceso tienen a tu entorno. Si tienen acceso a process.env completo, a tu database real, o corren en el mismo proceso que tu app — eso es técnicamente un sandbox cero. Empezá por ahí, con Docker o con Freestyle, antes de que el problema sea más que teórico.

El App Router de Next.js me enseñó que a veces te enojás dos semanas con la abstracción correcta. No quiero repetir ese error con los sandboxes para agentes.

Este artículo fue publicado originalmente en juanchi.dev

Vibe-coding vs stress-coding: cómo trabajo yo realmente con IA en proyectos que importan

Juan Torchia — Tue, 07 Apr 2026 23:31:50 +0000

El 87% de los bugs que encontré en código generado por IA aparecieron en edge cases que el prompt no mencionaba. No en la funcionalidad principal. En los bordes.

Cuando vi ese número en mi propio historial de PRs, tuve que releer dos veces. Porque llevaba semanas hablando de cuánto me ayudaba Cursor y Claude, y resulta que el 87% de mis correcciones eran exactamente en los lugares donde el contexto del negocio importa más que la sintaxis.

Eso me hizo pensar diferente sobre el vibe-coding. Y hoy lo quiero decir directo.

Vibe coding productividad real con IA — la diferencia que nadie te explica

Existe una corriente (legítima, interesante) que dice que el futuro del desarrollo es el vibe-coding: describís lo que querés, la IA lo genera, vos lo guiás con prompts, y el código aparece casi solo. Vi el artículo que circuló en Dev.to hace poco sobre "stress-coding" — la contracara ansiosa — y aunque el post en sí era bastante básico, el concepto me cerró algo que venía dando vueltas.

El vibe-coding no es malo. Es contextual.

Yo vibe-codeo. Todos los días. Pero no en todos los proyectos de la misma manera. La distinción que me tomó tiempo articular es esta:

Cuando experimento: la IA es copiloto con las riendas sueltas
Cuando hay usuarios reales: la IA es una herramienta poderosa que yo audito con criterio propio

Parece obvio. No lo es cuando estás en el flow y todo parece funcionar.

Cómo uso IA en modo experimento (y por qué está bien)

Cuando construí juanchi.dev, el proceso fue casi puro vibe-coding en las primeras semanas. Next.js 16, React 19, Tailwind v4 — todo bleeding edge, todo con poca documentación, todo con IA como primera línea de consulta.

En ese contexto, el flujo era:

// Prompt típico en modo experimento:
// "Necesito un componente que anime la entrada de cards
// usando Framer Motion con el nuevo hook useAnimate"

// La IA genera esto, yo lo acepto y pruebo:
import { useAnimate, stagger } from 'framer-motion'

export function AnimatedGrid({ items }: { items: PostCard[] }) {
  const [scope, animate] = useAnimate()

  // IA sugirió este approach — lo probé, funcionó, seguí
  useEffect(() => {
    animate(
      '.card',
      { opacity: [0, 1], y: [20, 0] },
      { delay: stagger(0.1) }
    )
  }, [])

  return (
    <div ref={scope} className="grid gap-6">
      {items.map(item => (
        <div key={item.slug} className="card">
          <PostCard {...item} />
        </div>
      ))}
    </div>
  )
}

En modo experimento, si esto falla en un edge case, el costo es: yo me doy cuenta, lo corrijo, sigo. No hay usuario esperando. No hay SLA. El vibe-coding acá multiplica mi velocidad de exploración de manera real.

El problema empieza cuando ese modo mental no cambia al pasar a producción.

Cómo uso IA cuando hay producción de por medio (stress-coding, pero el bueno)

Tengo un proyecto cliente — e-commerce, tráfico real, órdenes reales. Cuando trabajé la optimización de performance de esa app, el flujo con IA fue completamente diferente.

Lo que cambió:

1. El prompt incluye el contexto de negocio, siempre

// Prompt en modo producción:
// "Tengo una query que trae órdenes de los últimos 30 días
// con JOIN a usuarios y productos. Se ejecuta cada vez que
// alguien entra al dashboard admin. Promedio 2.3 segundos.
// La tabla órdenes tiene 180k filas. ¿Cómo la optimizo?
// NO quiero soluciones que rompan la paginación existente."

// Lo que la IA genera, yo NO acepto sin revisar:
const getRecentOrders = async (page: number, limit: number) => {
  // IA sugirió este índice compuesto — lo evalué en staging primero
  // CREATE INDEX idx_orders_created_user 
  // ON orders(created_at DESC, user_id) 
  // WHERE created_at > NOW() - INTERVAL '30 days';

  return await db
    .select({
      id: orders.id,
      total: orders.total,
      // Solo los campos que realmente necesito — la IA quería traer todo
      userName: users.name,
      // Removí el JOIN a products porque no se mostraba en este view
    })
    .from(orders)
    .innerJoin(users, eq(orders.userId, users.id))
    .where(
      and(
        gte(orders.createdAt, sql`NOW() - INTERVAL '30 days'`),
        eq(orders.status, 'completed') // IA no sabía que solo quería completed
      )
    )
    .orderBy(desc(orders.createdAt))
    .limit(limit)
    .offset((page - 1) * limit)
}

La IA no sabía que solo quería órdenes completed. Ese filtro cambió la query de 2.3 segundos a 400ms sin índice nuevo. El contexto de negocio que yo aporté valió más que el código que ella generó.

2. Nada va a producción sin que yo entienda cada línea

Esto suena básico y lo es. Pero en modo vibe-coding es fácil hacer Accept All y seguir. En producción, si no podés explicar qué hace una función en 30 segundos, no la deployás.

3. Los edge cases los pienso yo, no los delego

Volviendo al 87% del principio: los edge cases son exactamente el lugar donde el contexto de negocio importa. ¿Qué pasa si el usuario cancela la orden justo cuando se está procesando el pago? ¿Qué pasa si el stock llega a cero entre el addToCart y el checkout? Eso no está en el prompt. Nunca va a estar en el prompt a menos que vos lo pongas.

Los errores que cometí mezclando los dos modos

El problema real no es el vibe-coding ni el stress-coding. El problema es no saber en cuál modo estás.

En mi viaje de 30 años con tecnología, tiré un servidor de producción con rm -rf en mi primera semana de sysadmin. Eso fue stress-coding sin criterio: urgencia, presión, ejecutar sin pensar. El equivalente moderno es vibe-coding en producción: velocidad, flow, Accept All sin auditar.

Dos errores concretos que cometí:

Error 1: Confiar en los tipos de TypeScript generados por IA sin validar en runtime

// IA generó esto, yo lo acepté:
type OrderResponse = {
  id: string
  total: number
  items: OrderItem[]
}

// Problema: la API real a veces devuelve total como string
// TypeScript no lo detecta en runtime, Zod sí:
import { z } from 'zod'

// Lo que debería haber hecho desde el principio:
const OrderResponseSchema = z.object({
  id: z.string(),
  total: z.coerce.number(), // coerce maneja string -> number
  items: z.array(OrderItemSchema)
})

// Ahora si la API rompe el contrato, yo me entero en runtime
// y no cuando el usuario ve "NaN" en su total

Este error me costó 2 horas de debugging en producción. El stack tecnológico que elijo hoy incluye Zod obligatorio por esta razón.

Error 2: Dejar que la IA decida la arquitectura de features nuevas

La IA es excelente implementando. Es mediocre diseñando. Cuando le preguntás "¿cómo estructuro el módulo de notificaciones?", te va a dar una respuesta técnicamente correcta y genéricamente inútil para tu contexto.

Los patrones de TypeScript que realmente uso surgieron de decisiones de diseño que tomé yo, no la IA. Ella implementa los patrones. Yo decido cuándo y por qué aplicarlos.

Lo que cambió en mi flujo de trabajo concreto

Hoy tengo una regla interna simple:

Si el bug en producción me va a despertar a las 2am, no vibe-codeo esa parte.

Más específico:

Autenticación y autorización: cada línea auditada
Manejo de pagos: zero vibe-coding
Queries a base de datos en producción: genero con IA, reviso el plan de ejecución
Manejo de errores y edge cases: los pienso yo, la IA los implementa
UI components sin estado crítico: vibe-coding libre
Animaciones, estilos, layout: vibe-coding con los ojos cerrados
Scripts de migración de datos: auditados línea por línea, siempre

El resultado es que uso IA el 80% de mi tiempo de coding, pero de manera diferenciada. No es menos IA — es IA con criterio.

FAQ: Vibe-coding y productividad real con IA

¿El vibe-coding es solo para proyectos personales o sirve en trabajo cliente?

Sirve en trabajo cliente, pero en capas específicas. Para exploración inicial, prototipos, componentes de UI sin lógica crítica — perfecto. Para la lógica de negocio core, las integraciones de pago, el manejo de datos sensibles — necesitás un modo más riguroso. La clave es saber cuál es cuál antes de empezar a tipear.

¿Cómo evitás aceptar código de IA que parece funcionar pero tiene bugs escondidos?

Dos prácticas concretas: primero, siempre correr los tests antes del commit (tenés tests, ¿no?). Segundo, si es código que interactúa con external APIs o base de datos, lo probás con datos edge case reales: strings vacíos, IDs que no existen, respuestas con campos faltantes. La IA genera el camino feliz de maravilla. Los bordes los tenés que probar vos.

¿Qué herramientas de IA usás actualmente?

Cursor como editor principal con Claude Sonnet para el día a día. Claude Opus cuando necesito pensar arquitectura o debuggear algo complejo que no entiendo. ChatGPT casi no lo uso para código. GitHub Copilot lo dejé — Cursor lo supera en contexto de proyecto completo. El contexto es todo en esta ecuación.

¿El vibe-coding no te hace perder profundidad técnica con el tiempo?

Es la pregunta que más me hago. Mi respuesta honesta: sí, si no tenés cuidado. La manera de contrarrestarlo es elegir deliberadamente entender el código difícil, no solo aceptarlo. Cuando la IA genera algo que no entiendo completamente, le pido que me explique. No por paranoia — para mantener el músculo activo. Los 30 años de background técnico que describí no los quiero atrofiar.

¿Hay un tipo de proyecto donde NO usarías IA en el loop?

Honestamente, no. Pero hay partes de proyectos donde la IA está en el loop de manera diferente. En código crítico de seguridad, la uso para revisar lo que yo escribo, no para generar. "Acá está mi implementación de rate limiting, ¿qué ataques no estoy cubriendo?" Eso es IA como auditor, no como generador. Es un modo más, no ausencia de IA.

¿Cómo sabés cuándo el código generado por IA está bien y cuándo hay que reescribirlo?

Señales de reescritura: no podés explicar qué hace en 30 segundos, tiene más de 3 niveles de anidamiento sin razón obvia, los nombres de variables son genéricos (data, result, temp), o no tiene manejo de errores. Señales de que está bien: lo leerías orgulloso en un code review, los edge cases están contemplados, y si algo falla, el error va a ser claro sobre qué falló y por qué.

Lo que haría diferente si empezara hoy

El vibe-coding es real, es productivo, y vino para quedarse. Pero la narrativa de "describís y la IA hace" tiene un problema: omite que el valor del desarrollador senior no está en escribir código. Está en saber qué código escribir, cuándo, y con qué trade-offs.

Empecé a usar IA en serio durante la pandemia, cuando hice el pivot a desarrollo de software. Los primeros meses fueron devastadores — todo lo que sabía de infra no valía en React. Tuve que aprender a pensar diferente. Y hoy, con IA, pasa algo parecido: el que no aprende cuándo confiar y cuándo auditar va a tener el mismo problema que el dev que copiaba Stack Overflow sin entender. Los bugs van a aparecer en el peor momento, en los bordes, exactamente donde el negocio duele más.

La IA multiplicó mi productividad real. Pero la productividad real incluye no despertar a las 2am por algo que "parecía funcionar".

¿Vos cómo dividís el uso de IA entre proyectos que importan y experimentación? Me interesa saber si tu criterio es diferente al mío.

Este artículo fue publicado originalmente en juanchi.dev

Cómo Linux ejecuta un binario: lo entendí a los 33 años de programar y me da vergüenza

Juan Torchia — Tue, 07 Apr 2026 23:31:49 +0000

Hay exactamente 127 syscalls que hace un proceso Node.js vacío antes de ejecutar una sola línea de tu código. Ciento veintisiete. Cuando lo medí con strace la semana pasada, tuve que releer el output dos veces y después cerrar la terminal y salir a caminar.

Tengo 33 años de historia con computadoras. Arranqué con una Amiga a los 3 años, pasé por DOS, monté servidores Linux a los 18, y hoy deployeo en Railway con Next.js. Y en todo ese tiempo nunca entendí — de verdad, en detalle — qué pasa entre que escribís ./mi-programa y el programa corre. Lo esquivé. Siempre había algo más urgente. Un deploy. Un bug en producción. Un cliente.

Esta semana me obligué a bajar al metal. Y esto es lo que encontré.

Linux ELF dynamic linking: cómo funciona realmente

Empecemos por el principio. Cuando ejecutás un binario en Linux, el kernel no simplemente "arranca" tu programa. Hay una cadena de eventos que la mayoría de los devs de producto nunca vemos:

# Miremos qué tipo de archivo es un binario cualquiera
file /usr/bin/node
# ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV),
# dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2

Ahí está. dynamically linked. interpreter /lib64/ld-linux-x86-64.so.2. Eso es el dynamic linker, y es el protagonista de esta historia.

El formato ELF: el sobre que envuelve todo

ELF significa Executable and Linkable Format. Es básicamente un formato de archivo — como un ZIP pero para código ejecutable. Todo binario de Linux es un archivo ELF, y tiene una estructura muy específica:

# readelf te muestra las entrañas de un ELF
readelf -h /usr/bin/ls

# ELF Header:
#   Magic:   7f 45 4c 46 02 01 01 00 ...  <- "\x7fELF" — la firma del formato
#   Class:                             ELF64
#   Entry point address:               0x67d0  <- acá empieza TU código
#   Start of program headers:          64 (bytes into file)
#   Number of program headers:         13

El Entry point es la dirección de memoria donde va a arrancar la ejecución. Pero — y acá está lo que me voló la cabeza — ese código no es el primero que corre.

El dynamic linker: el intermediario que nunca viste

Cuando el kernel ve que un ELF es "dynamically linked", no ejecuta el entry point directamente. Ejecuta primero el interpreter — que en la práctica es /lib64/ld-linux-x86-64.so.2, el dynamic linker.

Este proceso hace, en orden:

# Veamos qué bibliotecas necesita un binario
ldd /usr/bin/node

# linux-vdso.so.1 (0x00007ffd8c9f3000)      <- virtual, vive en el kernel
# libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2
# libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6
# libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6
# libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
# /lib64/ld-linux-x86-64.so.2 (0x00007f3a...)  <- el dynamic linker mismo

Carga el ELF en memoria — mapea los segmentos del archivo
Resuelve las dependencias — busca cada .so que necesita el binario
Hace la relocación — parchea las direcciones de memoria para que todo encaje
Ejecuta los constructores — código de inicialización antes del main()
Entrega el control al entry point real

Todo eso antes de que tu main() corra una sola línea.

Bajando más: qué pasa con strace

La herramienta que me abrió los ojos fue strace. Intercepta todas las syscalls de un proceso:

# Contemos las syscalls de un programa C mínimo
cat > hola.c << 'EOF'
#include <stdio.h>
int main() {
    printf("hola\n");
    return 0;
}
EOF

gcc -o hola hola.c
strace -c ./hola

# % time     seconds  usecs/call     calls    syscall
# 27.45    0.000156          31         5    mmap       <- mapear memoria
# 18.23    0.000104          20         5    mprotect   <- proteger regiones
# 14.67    0.000083          83         1    munmap
#  9.44    0.000054          27         2    openat     <- abrir archivos .so
#  8.92    0.000051          25         2    read
# ...
# Total calls antes de main(): ~25

Veinticinco syscalls para "hola mundo". Para Node.js son 127. Esto tiene sentido cuando entendés que Node linkea contra un montón de bibliotecas compartidas — V8, libuv, OpenSSL.

El section header: el índice del binario

# Miremos las secciones de un ELF
readelf -S /usr/bin/ls | head -30

# [Nr] Name              Type             Address
# [ 0]                   NULL
# [ 1] .interp           PROGBITS         <- path al dynamic linker
# [ 2] .note.gnu.build-i NOTE
# [ 3] .gnu.hash         GNU_HASH         <- tabla hash para búsqueda de símbolos
# [ 4] .dynsym           DYNSYM           <- tabla de símbolos dinámicos
# [ 5] .dynstr           STRSYM           <- strings de los nombres de funciones
# [12] .plt              PROGBITS         <- Procedure Linkage Table
# [13] .text             PROGBITS         <- TU CÓDIGO acá
# [24] .got              PROGBITS         <- Global Offset Table
# [25] .got.plt          PROGBITS         <- GOT para PLT
# [26] .data             PROGBITS         <- variables globales inicializadas
# [27] .bss              NOBITS           <- variables globales sin inicializar

PLT y GOT: el truco de magia del lazy binding

Acá está la parte más elegante del sistema. Cuando tu programa llama a printf(), no sabe en tiempo de compilación en qué dirección de memoria va a estar esa función. La biblioteca puede estar en cualquier lugar.

La solución son dos estructuras:

PLT (Procedure Linkage Table): código intermedio que salta a través del GOT
GOT (Global Offset Table): tabla de punteros a las direcciones reales

# Primera llamada a printf — lazy binding en acción
# 1. Salta a printf@PLT
# 2. PLT lee el GOT — todavía apunta al dynamic linker
# 3. Dynamic linker resuelve la dirección real de printf
# 4. Actualiza el GOT con la dirección real
# 5. Ejecuta printf

# Segunda llamada a printf — ya resuelto
# 1. Salta a printf@PLT  
# 2. PLT lee el GOT — ahora apunta directo a printf
# 3. Ejecuta printf (sin pasar por el dynamic linker)

# Podés ver esto con:
LD_DEBUG=bindings ./hola 2>&1 | head -20
# binding file ./hola [0] to /lib/x86_64-linux-gnu/libc.so.6 [0]: 
# normal symbol `printf' [GLIBC_2.2.5]

Eso es lazy binding — el dynamic linker solo resuelve una función la primera vez que la llamás. Elegante y eficiente.

Los errores que me hicieron entender esto a las piñas

Error 1: "No such file or directory" en un binario que existe

Este me pasó hace años y lo "arreglé" sin entenderlo:

./mi-binario
# bash: ./mi-binario: No such file or directory

# Pero el archivo existe:
ls -la mi-binario
# -rwxr-xr-x 1 juan juan 45231 Feb 20 14:32 mi-binario

El error no es que el binario no existe. Es que el interpreter no existe. El dynamic linker especificado en el ELF no está en el sistema. Pasaba cuando copiaba binarios entre distros con diferentes layouts.

# Diagnóstico:
readelf -l mi-binario | grep interpreter
# [Requesting program interpreter: /lib/ld-musl-x86_64.so.1]
# ^ Fue compilado contra musl libc, no glibc. Diferente distro.

Error 2: library version mismatch en producción

./mi-app
# ./mi-app: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found

Compilé en Ubuntu 22.04, deployé en Debian 10. La versión de glibc era diferente. La solución real es buildear en el mismo entorno que producción — que es básicamente por qué Docker existe.

# Dockerfile que evita este problema
FROM node:20-alpine AS builder
# Alpine usa musl, no glibc — cuidado con binarios nativos

FROM node:20-slim AS runner  
# Debian slim, misma glibc que la mayoría de producción

Esto conecta directo con lo que aprendí cuando estuve optimizando performance en producción — el ambiente de build importa tanto como el código.

Error 3: LD_PRELOAD para bien y para mal

# LD_PRELOAD te permite inyectar una biblioteca ANTES que cualquier otra
# Úsalo con cuidado — es poderoso y peligroso

# Ejemplo legítimo: usar tcmalloc en vez del allocator default
LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libtcmalloc.so.4 ./mi-app

# Ejemplo de debugging: interceptar llamadas a funciones
# (básicamente cómo funcionan algunos sandboxes de agentes)
# Relacionado con lo que exploré en /blog/sandboxes-coding-agents-freestyle

La sandbox de Freestyle que analicé hace unos días usa mecanismos similares — interceptar syscalls a nivel de proceso para aislar lo que puede hacer el agente.

FAQ: Linux ELF y dynamic linking

¿Qué es un archivo ELF en Linux?
ELF (Executable and Linkable Format) es el formato estándar para binarios ejecutables, bibliotecas compartidas y archivos objeto en Linux. Es básicamente un contenedor estructurado que le dice al kernel cómo cargar y ejecutar el código. Todo binario de Linux moderno es un ELF — podés verificarlo con file /ruta/al/binario.

¿Qué diferencia hay entre static linking y dynamic linking?
Con static linking, todas las bibliotecas que necesita tu programa se copian adentro del binario en tiempo de compilación. El resultado es un binario más grande pero completamente autónomo. Con dynamic linking, el binario solo guarda referencias a las bibliotecas, y el dynamic linker las carga en tiempo de ejecución. Dynamic linking es el default porque ahorra memoria (varias apps comparten el mismo código de libc en RAM) y facilita las actualizaciones de seguridad.

¿Por qué a veces un binario dice "No such file or directory" aunque existe?
Generalmente significa que el interpreter (dynamic linker) especificado en el ELF no existe en ese sistema. Pasás un binario de Alpine (que usa musl libc) a Ubuntu (que usa glibc) y el path al dynamic linker no existe. Podés diagnosticarlo con readelf -l tu-binario | grep interpreter.

¿Qué es LD_PRELOAD y por qué es peligroso?
LD_PRELOAD es una variable de entorno que le dice al dynamic linker que cargue una biblioteca específica ANTES que cualquier otra, incluyendo libc. Esto permite interceptar y reemplazar funciones del sistema. Es útil para profiling y debugging, pero peligroso porque puede usarse para inyectar código malicioso. Por eso los binarios con setuid lo ignoran.

¿Qué es la vDSO (linux-vdso.so.1)?
Es una biblioteca virtual que el kernel mapea automáticamente en el espacio de memoria de cada proceso. Contiene implementaciones de syscalls muy frecuentes (como gettimeofday) que se ejecutan en espacio de usuario sin hacer un context switch real al kernel. Es por eso que ldd la muestra sin path — no es un archivo en disco, vive en el kernel.

¿Cómo afecta esto a Docker y los contenedores?
Mucho. Los contenedores comparten el kernel del host, pero tienen su propio filesystem. Si buildeas un binario en una imagen con glibc 2.35 y lo corrés en un contenedor con glibc 2.17, va a fallar. Es por eso que las imágenes de Docker deben ser consistentes entre build y runtime. También es por qué las imágenes basadas en Alpine (musl libc) a veces tienen comportamientos inesperados con binarios compilados para glibc.

Lo que me llevé: el dev de producto que finalmente bajó al metal

Honestamente, me da un poco de vergüenza haber esquivado esto por tanto tiempo. Trabajé con Linux desde los 18 años, administré servidores, diagnostiqué cortes de red a las 11pm con el cyber lleno, y nunca me pregunté en serio qué pasa en esos microsegundos entre ./programa y la primera línea de código.

El pivot que hice en 2020 hacia desarrollo de software me hizo subir capas de abstracción — React, TypeScript, Next.js. Aprender a pensar en componentes fue difícil cuando venías de pensar en paquetes de red. Pero subir no significa que las capas de abajo desaparezcan. Siguen ahí.

Cuando trabajo en inferencia de LLMs en el edge o pienso en cómo aislar agentes de código, entender qué pasa a nivel de proceso importa. Las abstracciones son útiles hasta que se rompen — y cuando se rompen, bajás al metal o pagás a alguien que entienda el metal.

Mi recomendación concreta: pasá una tarde con strace, ldd y readelf. No para convertirte en systems programmer — para entender la máquina que ejecuta tu código todos los días.

# Empezá por acá. Cinco minutos, en cualquier Linux:
strace -c ls /tmp 2>&1  # ¿Cuántas syscalls hace ls?
ldd $(which node)        # ¿De qué depende Node?
readelf -h $(which ls)   # ¿Qué tiene adentro un binario?
file /bin/*              # ¿Qué tipos de ELF hay en tu sistema?

La Amiga de 1994 no tenía dynamic linking — todo era estático, todo estaba en ROM o en el disco, y el sistema era lo que era. En cierto punto esa simplicidad era más honesta. Hoy corremos sobre capas de capas de capas, y cada tanto vale la pena bajar a ver en qué está parado todo.

¿Cuántas syscalls hace tu app antes de ejecutar una línea de código? Medilo con strace -c ./tu-binario y mandame el número. Apuesto a que te sorprende.

Este artículo fue publicado originalmente en juanchi.dev

Quantum computing para el dev web que no estudió física: ¿cuándo preocuparse en serio?

Juan Torchia — Tue, 07 Apr 2026 19:32:37 +0000

Hay días que abrís Hacker News y encontrás un post que te hace sentir que sabés muy poco de algo que creías tener medianamente claro. Esta semana fue uno de esos días.

Un criptógrafo cuántico posteó un análisis técnico sobre el estado actual del quantum computing aplicado a criptografía. 289 puntos. 340 comentarios. Yo entendí quizás el 30% del hilo. Y eso que llevo más de una hora intentando seguirlo.

La pregunta que me quedó dando vueltas no es abstracta: ¿cuándo debería yo — un full-stack developer que deployea en Railway, piensa en milisegundos de response time y la semana pasada optimizó una app Next.js de 3 segundos a 300ms — empezar a preocuparme en términos prácticos?

No sé la respuesta. Pero eso es exactamente por qué vale la pena escribir este post.

El quantum computing es básicamente como tener un cerrajero que no intenta cada llave una por una, sino que de alguna manera prueba todas las llaves posibles al mismo tiempo. Y lo que hoy te lleva millones de años romper con fuerza bruta, con esa lógica podría llevar horas.

Una vez que lo ves así, entendés por qué los criptógrafos se ponen nerviosos.

El quantum computing timeline para desarrolladores web: el estado real en 2025

Primer aclaramiento importante: no estoy hablando de algo que pasa mañana. El quantum computing que existe hoy es ruidoso, inestable, y no escala bien. Las máquinas de IBM o Google tienen decenas o cientos de qubits "reales" pero con tasas de error que hacen que la mayoría de los algoritmos criptográficamente relevantes sean imposibles de correr.

Para romper RSA-2048 — el estándar que protege buena parte de HTTPS hoy — necesitarías aproximadamente 4000 qubits lógicos estables. Los qubits lógicos son distintos de los físicos; necesitás muchos físicos para hacer uno lógico confiable por culpa del error de corrección.

Hoy estamos, dependiendo de a quién le preguntés, entre 10 y 20 años lejos de tener máquinas con esa capacidad. Algunos dicen 15 años. Otros dicen que nunca llegamos. Otros dicen que ya hay actores estado-nación haciendo cosas que no vemos.

Ese rango de incertidumbre es exactamente el problema.

Lo que el post de HN me hizo entender

El hilo que mencioné giraba alrededor de algo que se llama "harvest now, decrypt later" (HNDL). La idea es: aunque hoy no podés romper el cifrado, podés interceptar tráfico cifrado ahora y guardarlo para cuando tengas la capacidad cuántica de descifrarlo en el futuro.

Eso cambia la ecuación dramáticamente. Si alguien está capturando tu tráfico HTTPS de 2025 para descifrarlo en 2035, el timeline "10 a 20 años" se convierte en ahora mismo.

¿Quiénes hacen eso? Principalmente actores estado-nación. ¿Le importa eso a mi API de Next.js que muestra recetas de cocina? Probablemente no. ¿Le importa a un sistema de salud, a comunicaciones de defensa, a transacciones financieras de largo plazo? Absolutamente sí.

Así que la primera respuesta práctica es: depende de qué estás construyendo.

Lo que como developer full-stack debería saber sobre post-quantum cryptography

Aquí está lo que aprendí intentando entender el hilo sin tener un PhD en física:

NIST ya tomó decisiones

En 2024, el NIST (National Institute of Standards and Technology) finalizó los primeros estándares de criptografía post-cuántica. Los algoritmos que pasaron son:

ML-KEM (antes CRYSTALS-Kyber): para intercambio de claves
ML-DSA (antes CRYSTALS-Dilithium): para firmas digitales
SLH-DSA (antes SPHINCS+): para firmas digitales

Esto es importante porque significa que el trabajo de estandarización ya pasó. No estamos esperando que los matemáticos se pongan de acuerdo — ya lo hicieron.

TLS 1.3 ya está preparándose

Chrome, Firefox y algunos servidores ya están experimentando con hybrid key exchange — combinan el algoritmo clásico (X25519) con uno post-cuántico (ML-KEM) en el mismo handshake. Si uno falla, el otro sigue funcionando. Si el cuántico resulta tener vulnerabilidades no descubiertas todavía, el clásico te cubre.

Como dev web, probablemente esto te llegue transparentemente vía updates de OpenSSL, nginx, o Node.js. No tenés que hacer nada... todavía.

Lo que SÍ tenés que pensar activamente

// Esto es lo que MUCHOS proyectos hacen hoy
// y que puede ser problemático en un horizonte post-cuántico

// ❌ Algoritmos que eventualmente van a ser vulnerables
const jwt = sign(payload, secret, { algorithm: 'RS256' }) // RSA
const encrypted = crypto.publicEncrypt(rsaPublicKey, data) // RSA

// ✅ Algoritmos simétricos — estos están relativamente bien
// AES-256 sigue siendo seguro en un mundo cuántico
// (Grover's algorithm lo debilita pero no lo rompe — 256 bits -> 128 bits efectivos)
const hash = createHash('sha256').update(data).digest('hex') // OK por ahora
const cipher = createCipheriv('aes-256-gcm', key, iv) // Más seguro

// 🤔 La pregunta real: ¿tus secrets/tokens tienen que durar décadas?
// Si un JWT expira en 1 hora, el riesgo post-cuántico es casi nulo
// Si estás firmando contratos que tienen que ser válidos en 2040...
// ahí sí hay que pensar distinto

La clave práctica que saqué: el riesgo escala con el tiempo de vida de lo que firmás o cifrás. Un access token de 15 minutos y un certificado de firma de documentos legales tienen riesgos completamente distintos.

Los errores de framing más comunes cuando leés sobre quantum computing

Acá está lo que me parece que la mayoría de los posts de divulgación hacen mal — incluyendo probablemente este:

Error 1: Confundir "quantum advantage" con "quantum supremacy" con "cryptographically relevant"

Cuando Google o IBM anuncian un hito cuántico, los medios lo presentan como "ya pueden romper el cifrado". Casi nunca es eso. Quantum advantage significa que resolvieron algún problema específico más rápido que una computadora clásica. Ese problema específico suele ser artificioso y diseñado para que la computadora cuántica brille.

Cryptographically relevant quantum computing — el que realmente importa — es una barra mucho más alta.

Error 2: Pensar que bcrypt o Argon2 están muertos

El hashing de passwords como bcrypt, scrypt o Argon2 usa funciones hash simétricas. El algoritmo de Grover (el que aplica computación cuántica a búsqueda) efectivamente reduce su seguridad a la mitad — pero Argon2 con parámetros modernos tiene margen de sobra. No necesitás cambiar tu sistema de autenticación ahora mismo.

Error 3: Ignorarlo completamente porque "falta mucho"

Este es el error que me parece más peligroso para devs que construyen infraestructura de largo plazo. Si estás construyendo algo que va a manejar datos sensibles por décadas, el timeline importa.

Pensá en todo lo que construí durante el pivote a software development en 2020 — la infraestructura que elegís hoy puede seguir corriendo en producción en 2035. Cuando elegís un stack de autenticación o cifrado hoy, estás eligiendo para ese horizonte de tiempo también.

Error 4: Pensar que esto es solo un problema del devops o del sysadmin

En el ecosistema de 2025 que describí cuando armé mi stack para juanchi.dev, los developers full-stack tomamos decisiones de arquitectura que antes eran de ops. Eso incluye qué librería de crypto usás, cómo firmás tokens, qué tipo de certificados pedís.

No podés delegarlo completamente.

Código: qué revisar en tu proyecto hoy

// Auditoría rápida de superficie de ataque post-cuántica
// Revisá estos patrones en tu codebase

// 1. ALGORITMOS ASIMÉTRICOS — los más vulnerables
// Buscá: RSA, ECDH, ECDSA, DH
// ¿Dónde aparecen?
import { generateKeyPairSync, createSign } from 'crypto'

// ❓ RSA — vulnerable a Shor's algorithm
// Si estos datos tienen que ser válidos en 2035+, pensalo
const { privateKey, publicKey } = generateKeyPairSync('rsa', {
  modulusLength: 2048, // Esto eventualmente no va a ser suficiente
})

// ❓ ECDSA — también vulnerable, aunque más eficiente hoy
const ecKey = generateKeyPairSync('ec', {
  namedCurve: 'prime256v1',
})

// 2. ALGORITMOS SIMÉTRICOS — relativamente OK
// AES-256, ChaCha20-Poly1305, SHA-256/384/512
// Estos necesitan el doble de bits para ser vulnerables (Grover)
// pero con 256 bits tenés colchón de sobra

import { randomBytes, createCipheriv, createDecipheriv } from 'crypto'

const cifrarDatosLocales = (datos: Buffer, clave: Buffer): Buffer => {
  // AES-256-GCM — esto sigue siendo seguro post-quantum
  const iv = randomBytes(16)
  const cipher = createCipheriv('aes-256-gcm', clave, iv)

  const cifrado = Buffer.concat([
    iv,
    cipher.update(datos),
    cipher.final(),
    cipher.getAuthTag() // El tag de autenticación es importante
  ])

  return cifrado
}

// 3. JWT — el caso práctico más común
// La respuesta corta: si expira en horas, no te preocupés
// Si firmás algo permanente con JWT... cuestioná el diseño

const evaluarRiesgoJWT = (expiresInSeconds: number): string => {
  const años = expiresInSeconds / (365 * 24 * 3600)

  if (años < 1) return 'Riesgo post-cuántico prácticamente nulo'
  if (años < 5) return 'Riesgo bajo, monitoreá el timeline'
  if (años < 15) return 'Riesgo moderado, considerá migración'
  return 'Riesgo alto — rediseñá este componente'
}

console.log(evaluarRiesgoJWT(3600)) // "Riesgo post-cuántico prácticamente nulo"
console.log(evaluarRiesgoJWT(10 * 365 * 24 * 3600)) // "Riesgo moderado..."

La función evaluarRiesgoJWT es una simplificación obvia, pero captura el punto central: el tiempo de vida de lo que firmás es la variable más importante.

Cuando definís los patrones de TypeScript que usás en producción, incluir tipos explícitos para el contexto de seguridad — cuánto tiempo vive un token, qué nivel de sensibilidad tienen los datos — es el tipo de diseño que ayuda cuando tenés que hacer una auditoría de esto en el futuro.

Qué hacer concretamente hoy (sin entrar en pánico)

Esta es mi lista personal, honesta, sin exagerar el riesgo:

Ahora mismo (sin importar el tipo de proyecto):

Usá TLS 1.3 — ya implementa algunas mejoras de seguridad y va a recibir actualizaciones post-cuánticas
Preferí AES-256 sobre AES-128 para cifrado simétrico
Mantenés las dependencias actualizadas — la migración post-cuántica va a llegar vía updates de librerías
No implementés crypto propio — en serio, nunca, quantum o no quantum

En los próximos 1-2 años (si manejás datos sensibles de largo plazo):

Inventariá qué en tu sistema usa criptografía asimétrica y cuánto tiempo tienen que vivir esos datos
Empezá a leer sobre las librerías que van a adoptar los algoritmos NIST — Open Quantum Safe ya tiene implementaciones
Considerá diseñar para "cripto-agilidad": que tu sistema pueda cambiar de algoritmo sin reescribir todo

Para el stack que elegiría en 2025:
Hoy elegiría librerías activamente mantenidas por organizaciones que ya tienen planes de migración post-cuántica documentados. Node.js y OpenSSL están en ese camino. Es un criterio más para sumar a la evaluación.

FAQ: quantum computing y desarrollo web

¿HTTPS va a dejar de ser seguro por el quantum computing?

No en el corto plazo, y probablemente no de golpe. TLS ya está siendo actualizado con algoritmos post-cuánticos (hybrid key exchange en TLS 1.3). El browser que usás hoy ya está recibiendo estas actualizaciones gradualmente. Lo que sí es una amenaza real es el ataque "harvest now, decrypt later" para datos muy sensibles — pero eso aplica a actores estado-nación, no al tráfico web promedio.

¿Tengo que cambiar el sistema de login/passwords de mi app?

No urgentemente. bcrypt, Argon2, y scrypt usan funciones hash simétricas que son mucho más resistentes a quantum computing que los algoritmos asimétricos. Argon2id con parámetros modernos tiene margen de seguridad suficiente. La recomendación es seguir con las mejores prácticas actuales y mantenerte actualizado.

¿Los JWTs quedan obsoletos?

Depende de cómo los usés. Si firmás access tokens que expiran en 15 minutos o 1 hora, el riesgo es prácticamente nulo — para cuando exista quantum computing relevante, esos tokens llevan años vencidos. Si usás JWTs para firmar algo que tiene que ser válido por años (documentos, contratos), ahí sí hay que empezar a pensar en alternativas.

¿Qué es "post-quantum cryptography" y en qué se diferencia de "quantum cryptography"?

Post-quantum cryptography (PQC) son algoritmos clásicos — corren en computadoras normales — diseñados para ser resistentes a ataques de computadoras cuánticas. Quantum cryptography (QKD, quantum key distribution) usa principios cuánticos para la comunicación en sí. Como dev web, lo que te importa es PQC — es lo que vas a implementar en tu stack. QKD requiere hardware especializado y es un campo completamente distinto.

¿Cuándo debería empezar a usar las librerías post-cuánticas en producción?

Para la mayoría de las aplicaciones web: cuando lleguen via updates de tus dependencias actuales, que es probablemente lo que va a pasar. Node.js, OpenSSL y los providers de TLS van a implementar los estándares NIST gradualmente. Si manejás datos críticos de largo plazo, vale la pena explorar Open Quantum Safe hoy y empezar a hacer pruebas. Para el resto, mantenete actualizado y no entres en pánico.

¿El quantum computing afecta a blockchain y crypto también?

Sí, y bastante. Las criptomonedas usan ECDSA para firmar transacciones — vulnerable a Shor's algorithm. Bitcoin y Ethereum tendrían que migrar sus sistemas de firma antes de que quantum computing sea relevante. Es uno de los debates más activos en esas comunidades. Como dato de color: las wallets activas están más expuestas que las inactivas, porque las activas exponen la clave pública en cada transacción.

Conclusión: la ignorancia honesta como posición válida

Cuando empecé a escribir este post no sabía bien qué iba a concluir. Sigo sin saber si en 10 años estamos re-cifrando todo el internet o si el quantum computing sigue siendo una promesa que no termina de llegar.

Lo que sí saqué en limpio:

El timeline importa más que el tema. No es un problema binario de "hay que preocuparse" o "no hay que preocuparse". Es una función del tiempo de vida de tus datos y la sensibilidad de los mismos.
La industria ya se está moviendo. NIST finalizó estándares. TLS ya está experimentando con algoritmos híbridos. No vas a tener que hacer todo a mano — va a llegar via ecosistema.
La cripto-agilidad es la mejor inversión. Diseñar tus sistemas para que puedan cambiar de algoritmo sin reescritura total es buena práctica con o sin quantum computing. La historia de la criptografía es la historia de algoritmos que se rompen y se reemplazan.
Para la mayoría de los proyectos: mantenete actualizado y no entres en pánico. Si tu app maneja credenciales de usuarios que expiran, tokens de sesión normales, y datos que no tienen que ser válidos por décadas — el riesgo hoy es bajo. Aplicá las mejores prácticas actuales.

Lo que me queda pendiente es seguir leyendo. El hilo de HN que disparó esto tenía respuestas de gente con décadas de experiencia en criptografía que no se ponía de acuerdo. Eso me dice que la humildad epistémica es la postura correcta.

Si sos el tipo de developer que, como yo, viene de diagnosticar redes a las 11pm en un cyber o de tirar un servidor de producción con rm -rf en la primera semana de trabajo — sabés que la mejor preparación para los problemas grandes no es entrar en pánico cuando aparecen, sino construir sistemas que puedan adaptarse.

Eso aplica acá también.

Este artículo fue publicado originalmente en juanchi.dev

Google Maps para codebases: pegué la URL de mi propio repo y me asusté un poco

Juan Torchia — Tue, 07 Apr 2026 19:32:36 +0000

Gitingest, Repomix, CodeViz — la semana pasada cayeron en mi radar varias herramientas que prometen lo mismo: pegás una URL de GitHub y podés conversar con el código, mapearlo, entender su arquitectura en segundos. La comunidad las está descubriendo con el entusiasmo habitual. Yo también las probé. Y el experimento más interesante no fue analizar el repo de algún framework famoso.

Fue analizar el mío.

Hay algo levemente narcisista en pegar la URL de tu propio proyecto en una herramienta de análisis. Y algo levemente aterrador en lo que te devuelve.

Codebase visualization con GitHub AI análisis: de qué hablamos exactamente

Antes de entrar en lo que encontré, vale la pena aclarar de qué hablamos cuando hablamos de "visualización de codebases con AI".

No es simplemente un grafo de dependencias. Eso existía hace años y nadie lo usaba porque los grafos de dependencias de Node.js parecen el mapa del subte de Tokio después de un terremoto.

Lo que cambió es la capa de lenguaje natural encima. Herramientas como Gitingest convierten el repo entero en un formato que puede ingerir un LLM. Después podés hacer preguntas en lenguaje natural: "¿dónde están los cuellos de botella de performance?", "¿qué componentes tienen más acoplamiento?", "¿hay patrones inconsistentes en el manejo de errores?"

Repomix hace algo similar pero más enfocado en generar un archivo de contexto comprimido. La idea es que ese archivo se lo pasás a Claude o GPT-4 como contexto y preguntás lo que quieras.

Lo que obtienen estas herramientas no es magia — es contexto masivo entregado de forma eficiente. El análisis lo hace el LLM. La herramienta es el preprocesador.

# Instalación básica de Repomix
npx repomix

# O apuntando a un repo remoto directamente
npx repomix --remote juanchi-dev/juanchi.dev

# Genera un archivo repomix-output.xml con todo el código
# comprimido y listo para pasarle a un LLM

Hasta acá, nada nuevo. La novedad es qué pasa cuando el código analizado es tuyo y lo conocés de memoria — o eso creías.

Lo que un LLM encontró en juanchi.dev que yo no veía

juanchi.dev es mi proyecto público. Lo construí con Next.js 15, React 19, Tailwind v4, desplegado en Railway. Ya escribí sobre el stack en detalle. Creía que lo conocía bien.

Pasé el repo por Repomix, generé el archivo de contexto, y lo cargué en Claude con un prompt simple: "Analizá este codebase como si fueras un senior developer haciendo code review. Sé honesto. No me des palmaditas en la espalda."

Lo que salió me hizo abrir tres archivos que no tocaba hace semanas.

Hallazgo 1: Inconsistencia en el manejo de errores

Mis Server Components y mis Route Handlers manejaban los errores de forma distinta. En algunos lugares usaba try/catch con logging explícito. En otros, dejaba que Next.js manejara el error silenciosamente. No había una estrategia unificada.

// Cómo manejaba errores en algunos Server Components
async function getBlogPost(slug: string) {
  try {
    const post = await db.query(/* ... */)
    return post
  } catch (error) {
    // Logging explícito, re-throw controlado
    console.error(`Error fetching post ${slug}:`, error)
    throw new Error('Post no encontrado')
  }
}

// Cómo manejaba errores en OTROS lugares (el problema)
async function getProjects() {
  // Sin try/catch. Si falla, falla en silencio o explota arriba
  const projects = await db.query(/* ... */)
  return projects
}

El LLM lo identificó como "falta de estrategia de error handling consistente". Tenía razón. No era un bug — era deuda técnica acumulada de haber construido el proyecto en múltiples sesiones sin un estándar definido.

Hallazgo 2: Componentes con demasiadas responsabilidades

Había un componente que el análisis identificó como un "God Component" — hacía fetching, formateo de datos Y renderizado, todo junto. Yo lo había construido así porque en el momento era más rápido. Funcionaba. Pero no era correcto.

// El componente problemático (simplificado)
// Hace demasiado: fetch + transform + render
export async function BlogPostCard({ slug }: { slug: string }) {
  // Lógica de fetching que debería estar separada
  const post = await fetch(`/api/posts/${slug}`).then(r => r.json())

  // Transformación que debería estar en una utility
  const formattedDate = new Intl.DateTimeFormat('es-AR', {
    year: 'numeric',
    month: 'long',
    day: 'numeric'
  }).format(new Date(post.date))

  // Solo esto debería estar acá
  return (
    <article>
      <h2>{post.title}</h2>
      <time>{formattedDate}</time>
    </article>
  )
}

Hallazgo 3: El que más me dolió

Tenía lógica de negocio duplicada en dos lugares distintos. La misma transformación de datos escrita dos veces, ligeramente diferente cada vez. El tipo de cosa que en una code review rechazarías en el primer comentario.

No lo había visto porque cuando estás dentro del código, navegás por él de forma funcional — abrís el archivo que necesitás, hacés el cambio, cerrás. No tenés la vista panorámica.

Eso es exactamente lo que hice cuando optimicé el performance del sitio a 300ms: fui archivo por archivo, función por función. Eficiente para ese objetivo. Ciego para el panorama general.

Los antipatrones que no ves porque sos vos quien los escribió

Hay un problema epistemológico en revisar tu propio código: sabés demasiado.

Sabés por qué tomaste cada decisión. Sabés el contexto. Sabés qué quisiste hacer. Y ese conocimiento actúa como una capa de racionalización que filtra los problemas antes de que los veas.

Cuando un externo (humano o LLM) mira el código, no tiene ese contexto. Ve solo lo que está escrito. Y a veces lo que está escrito no refleja lo que tenías en mente.

Esto me recuerda algo que aprendí mucho antes de escribir TypeScript. Cuando estudiaba para el CCNA en 2009, practicaba configuraciones de red en Packet Tracer hasta memorizarlas. Pero cuando me sentaba a hacer los simulacros de examen, me equivocaba en exactamente las cosas que "sabía". El conocimiento implícito no siempre sobrevive el cambio de contexto.

El LLM operando sobre mi código es ese cambio de contexto forzado.

Dicho esto — no es magia y tiene límites claros.

Lo que el análisis NO vio:

Por qué algunas decisiones de arquitectura son intencionales (tradeoffs que yo conozco)
El contexto de evolución del proyecto (code que parece legacy pero tiene razón de ser)
Problemas de performance que solo se ven en runtime — para eso tuve que instrumentar manualmente
Integraciones específicas con servicios externos donde la "inconsistencia" es necesaria

Combinado con lo que sí encontró, el mapa es útil. Solo. No suficiente.

Errores comunes cuando usás estas herramientas

Error 1: Tomar todo como verdad absoluta

El LLM no sabe si esa "inconsistencia" en el manejo de errores es deuda técnica o una decisión deliberada. Vos sí. Filtrá.

Error 2: Usarlo sobre repos gigantes sin acotar el contexto

Repomix sobre un monorepo de 500k líneas va a generar un archivo de contexto que ningún LLM puede procesar bien. El análisis se degrada. Mejor acotar: pasá solo los directorios relevantes.

# Mejor acotar el análisis a lo que importa
npx repomix --include "src/components/**,src/lib/**"

# En vez de pasar todo el repo con node_modules y ruido
npx repomix  # sin filtros = mucho ruido

Error 3: Esperar que reemplace el code review humano

El análisis AI encontró tres problemas reales en mi código. Un senior developer con contexto de negocio hubiera encontrado esos tres más cinco que el LLM racionalizó o no pudo evaluar. Esto es lo mismo que aprendí con los coding agents: el AI acelera, no reemplaza el criterio.

Error 4: No iterar el prompt

El primer análisis que pedí fue genérico. El útil vino cuando refiné: "Enfocate específicamente en patrones de fetching de datos y cómo se propagan los errores hasta el cliente. Ignorá styling y configuración." La especificidad importa.

Error 5: Usarlo solo una vez

El valor real es usarlo como checkpoint periódico. Un snapshot del estado del código cada mes, con las mismas preguntas, te muestra si tu deuda técnica está creciendo o achicándose.

Esto conecta con algo que vi cuando metí un LLM chico en una app Next.js: la calidad del output depende brutalmente de la calidad del contexto que le das. Garbage in, garbage out — pero también ruido in, análisis diluido out.

FAQ: Preguntas frecuentes sobre codebase visualization con AI

¿Cuál es la mejor herramienta para analizar un repo de GitHub con AI?

Depende del objetivo. Para conversación libre sobre el código, Gitingest (gitingest.com) es el más directo — pegás la URL y podés preguntar en lenguaje natural. Para generar contexto que pasarle a tu LLM preferido, Repomix es más flexible y configurable. Para visualización gráfica de dependencias, CodeViz o Mermaid generado por el LLM funcionan bien. No hay una bala de plata.

¿Es seguro pegar la URL de un repo privado en estas herramientas?

Depende de la herramienta y tu modelo de amenaza. Repomix instalado localmente nunca sale de tu máquina — el código no va a ningún servidor externo. Herramientas web como Gitingest procesan el código en sus servidores. Para repos privados con código sensible, la opción local siempre es más segura. Para repos públicos, no hay diferencia.

¿Qué tan precisos son los análisis que devuelve el LLM?

En mi experiencia: precisos en detectar inconsistencias de patrones, imprecisos en evaluar decisiones de arquitectura sin contexto. El LLM ve el código tal como está escrito. No ve por qué está así. Los falsos positivos existen — te va a señalar como problema algo que es una decisión intencional. El filtro humano es obligatorio.

¿Funciona bien con repos grandes (más de 100k líneas)?

Mal, en general. Los LLMs tienen ventanas de contexto finitas. Repomix comprime el código para maximizar lo que entra, pero con repos muy grandes hay que acotar el análisis a subdirectorios o módulos específicos. Mejor análisis focalizado que análisis superficial de todo.

¿Puede reemplazar a un code review humano?

No. Complementarlo, sí. El análisis AI es rápido, sin ego, y no tiene contexto — esas tres cosas son simultáneamente su fortaleza y su límite. Encuentra lo que un humano podría pasar por alto por cansancio o familiaridad. No puede evaluar si una decisión es correcta para el negocio, el equipo, o la historia del proyecto. Son herramientas distintas para capas distintas del problema.

¿Vale la pena usarlo sobre código propio si ya lo conocés bien?

Especialmente sobre código propio. Esa es la paradoja. Cuanto más conocés el código, más necesitás la perspectiva externa. El conocimiento implícito que tenés actúa como filtro — te impide ver los problemas porque ya los racionalizaste. Un LLM sin contexto ve solo lo que está escrito. A veces eso es exactamente lo que necesitás.

¿Mapa útil o ansiolítico digital?

La pregunta que me hice antes de escribir esto: ¿cambié algo después del análisis?

Sí. Unifiqué el manejo de errores. Rompí el God Component en tres piezas. Eliminé la duplicación de lógica. Tres cambios concretos en código que funciona en producción hoy.

Pero también me pregunté si el ejercicio no era en parte ansiolítico — la sensación de que "auditaste" tu código sin haber realmente enfrentado el problema más profundo, que es tener más disciplina desde el principio.

La respuesta honesta es: probablemente ambas cosas. Y está bien.

Lo que aprendí en 30 años con tecnología — desde diagnosticar cortes de red a las 11pm en un cyber hasta deployar en Railway — es que las herramientas que te dan perspectiva son valiosas aunque sean imperfectas. El CCNA no me enseñó a administrar redes reales. Me dio el vocabulario para entender qué estaba mirando. Claude Code no escribe el código por mí. Acelera el tiempo que paso en lo que ya sé hacer.

Estas herramientas de visualización hacen algo similar: te devuelven tu propio código con ojos nuevos. Lo que hacés con eso depende de vos.

Pegá la URL de tu repo. Date un susto productivo.

Este artículo fue publicado originalmente en juanchi.dev

De DOS a Cloud: mi viaje de 33 años con la tecnología — desde una Amiga en 1994 hasta deployar en Railway con Next.js

Juan Torchia — Tue, 07 Apr 2026 00:29:58 +0000

Hay una foto que no tengo pero que existe perfectamente nítida en mi memoria: yo, 1994, tres años recién cumplidos, parado frente a una Commodore Amiga 500 con un joystick que me quedaba enorme en las manos. Mi viejo había traído esa máquina de quién sabe dónde y yo no entendía absolutamente nada de lo que pasaba en la pantalla. Pero algo en ese monitor — los colores, el sonido, la idea de que yo podía hacer que algo pasara — me enganchó de una manera que nunca más me soltó.

Eso fue hace treinta y un años. Y acá estoy.

La Amiga como primer maestro

La Amiga 500 no era una computadora de Windows ni de DOS. Era un bicho aparte, con su propio sistema operativo (AmigaOS), con una interfaz gráfica en una época donde la mayoría del mundo todavía tipeaba comandos en pantallas verdes. Obviamente yo no sabía nada de eso. Lo que sabía era que si agarraba el disquete correcto y lo metía en el drive, aparecía un juego. Y si hacía algo mal, aparecía el Guru Meditation — esa pantalla de error roja que para mí era aterradora, como si la máquina se estuviera muriendo.

Pero el Guru Meditation fue mi primer contacto con la idea de que las computadoras fallan. Que no son magia. Que hay algo adentro que puede romperse. Esa intuición — que después se convirtió en conocimiento real — es probablemente lo más valioso que me dejó esa Amiga oxidada.

A los 5 años ya tenía mi primer dominio. No, no es un chiste. Mi viejo era de esa generación que entendió internet antes que nadie en Argentina, y de alguna manera yo estaba metido en ese mundo también. No entendía qué era un DNS ni por qué funcionaba, pero sabía que ese nombre era mío y que apuntaba a algo en internet. La semilla del orgullo nerd estaba plantada.

Los cyber cafés como universidad

Salteemos algunos años de caos típico de crecer en Argentina en los '90 y lleguemos a los 14. Estaba trabajando en cyber cafés. Y cuando digo trabajando, no digo atendiendo la caja — digo metido abajo de los escritorios, pasando cables, configurando Windows 98 que se rompía solo mirándolo, instalando drivers de red que no existían para hardware que tampoco debería haber existido.

Los cyber cafés de esa época eran una jungla. Diez máquinas conectadas con cable UTP pelado, hubs baratos que se calentaban como hornos, Windows pirata que cada tanto decidía que el mejor momento para reiniciar era en medio de un Counter-Strike. Mi trabajo no oficial era que todo siguiera andando. Y aprendí más redes en seis meses de cyber café que en cualquier curso formal.

Aprendí qué es una subred porque tuve que configurarlas. Aprendí qué es DHCP porque cuando no funcionaba, los chicos no podían jugar y me gritaban. Aprendí qué es una dirección MAC porque era la única manera de identificar cuál de esas diez máquinas era la que se caía siempre. El conocimiento forzado por el caos es el que más dura.

Linux a las 3am y el primer servidor real

A los 18 el salto fue a web hosting con Linux. Y acá es donde la cosa se pone seria.

Instalar Linux en 2009 no era como ahora. No había un instalador bonito que te guiaba de la mano. Había particiones que tenías que calcular a mano, había GRUB que si lo instalabas mal te quedabas sin sistema operativo en absolutamente todas las particiones que tenías, había controladores de red que a veces no existían para tu hardware y tenías que compilarlos desde código fuente descargado con la única máquina que sí tenía internet.

Pero una vez que andaba... era mío. Completamente mío. Un servidor corriendo Apache, MySQL, PHP — el stack LAMP que movía la mitad de internet en esa época. Configurando virtual hosts a las 3am porque ese era el único momento en que podía trabajar sin interrupciones. Mirando logs en tiempo real con tail -f como si fueran telemetría de una nave espacial.

Esa sensación — la de tener una máquina real en internet, respondiendo requests de gente real — es algo que nunca se va. Es adictiva. Hoy tengo esa misma sensación cuando hago deploy y veo los logs de Railway actualizarse en tiempo real, pero la primera vez que la sentí tenía 18 años y era con un servidor físico en algún datacenter que nunca llegué a ver en persona.

El desvío: Cisco CCNA y la UBA

Hubo un período donde me fui más hacia las redes que hacia el software. Hice la certificación Cisco CCNA — una de esas credenciales que te hacen estudiar routing protocols, spanning tree, VLANs, subnetting hasta que lo soñás — y entré a Ciencias de la Computación en la UBA.

La UBA me enseñó a pensar. Eso suena a cliché pero es literal. Álgebra, lógica, algoritmos — la parte de la computación que no se aprende tocheando servidores. Aprendí por qué ciertos algoritmos son más eficientes que otros. Aprendí a demostrar cosas. Aprendí que hay una diferencia enorme entre código que funciona y código que es correcto.

También aprendí que la academia argentina tiene una relación complicada con la tecnología del mundo real. Estábamos estudiando teoría de compiladores mientras afuera el mundo estaba explotando con Node.js y el primer boom de las startups. No me arrepiento — la base teórica vale oro — pero había una desconexión que a veces desesperaba.

El CCNA, por otro lado, fue brutal en el buen sentido. Estudiar para esa certificación es como meterse en la cabeza de los ingenieros de Cisco y entender por qué internet funciona como funciona. Por qué los paquetes toman ciertas rutas. Por qué falla cuando falla. Ese conocimiento de red de bajo nivel es algo que hoy, cuando debuggeo problemas de conectividad en Docker o configuro reglas de firewall en un VPS, sigo usando constantemente.

2020: el pivot que cambió todo

Y llegamos al momento que cambió todo. 2020. Sí, ese año.

Con el mundo en pausa forzada, yo tomé la decisión de meterme de lleno en desarrollo de software moderno. No como hobby — como carrera principal. Y el mundo que encontré era irreconocible comparado con el PHP que había tocado diez años antes.

React. TypeScript. Next.js. Docker. PostgreSQL. Un ecosistema completamente diferente, con sus propias convenciones, sus propias peleas internas (¿Redux o Context? ¿REST o GraphQL? ¿tabs o espacios — bueno, esa está resuelta), su propia cultura.

El primer mes fue humillante. Yo que había configurado servidores Linux, que entendía cómo funciona TCP/IP, que había estudiado algoritmos en la UBA — no podía hacer andar un componente de React sin romper todo. El modelo mental es completamente diferente. El estado reactivo, el ciclo de vida de los componentes, el sistema de tipos de TypeScript que al principio parece un obstáculo y después te das cuenta de que es lo que te salva la vida — todo nuevo.

Pero acá es donde los treinta años anteriores pagaron dividendos. Cuando algo fallaba, yo sabía leer el error. Cuando había un problema de red en Docker, yo sabía qué estaba pasando. Cuando la base de datos se portaba raro, tenía intuición de dónde buscar. La experiencia acumulada no era transferible directamente, pero creaba un contexto que aceleraba el aprendizaje de manera brutal.

Railway, Next.js y el deploy de 2024

Hoy el stack en el que trabajo es Next.js con TypeScript, PostgreSQL para los datos persistentes, Docker para que el ambiente local sea igual al de producción (la promesa eterna que Docker por fin cumplió), y Railway para el deploy.

Railway merece un párrafo aparte porque representa exactamente el contraste con mis inicios. En 2009, para poner algo en producción, necesitaba: contratar un servidor, configurarlo desde cero con SSH, instalar todo el stack, configurar el dominio, configurar SSL manualmente con Let's Encrypt o pagar un certificado, configurar backups, monitoreo... Días de trabajo para la infraestructura antes de poder desplegar una línea de código de producto.

Con Railway hoy: railway up. Listo. En serio. La infraestructura está toda abstraída. PostgreSQL con un click. Variables de entorno en una interfaz. Deploys automáticos desde GitHub. SSL automático. Monitoreo incluido.

La primera vez que hice un deploy así me quedé mirando la terminal en silencio unos segundos. Pensé en las noches configurando Apache, en los GRUB rotos, en los cyber cafés con calor de diciembre y cables por todos lados. Y pensé: esto es demasiado fácil. Y después me corregí: no es fácil, es que alguien hizo el trabajo duro por vos.

Esa es la paradoja de la abstracción tecnológica. Todo se vuelve más accesible, y eso es bueno — significa más gente puede construir cosas. Pero también significa que hay capas de complejidad que se vuelven invisibles, y cuando algo sale mal en esas capas, el desarrollador que no pasó por los servidores físicos no tiene las herramientas mentales para entender qué está pasando.

Por qué importa de dónde venís

Soy un producto raro: demasiado joven para haber vivido los mainframes, demasiado viejo para haber empezado con smartphones y tutoriales de YouTube. Caí justo en el medio de la transición más grande de la historia de la computación personal.

Y eso me dio algo que valoro cada vez más: contexto histórico. Sé por qué las cosas son como son. Sé por qué Docker existe — porque el "funciona en mi máquina" es un problema real que yo viví. Sé por qué TypeScript existe — porque JavaScript a escala es una pesadilla de mantenimiento que yo también viví. Sé por qué los servicios cloud existen — porque la alternativa era lo que yo hacía a los 18.

Esta historia — la historia programador argentino que creció con la tecnología en tiempo real — no es nostalgia. Es contexto. Y el contexto es lo que separa a alguien que usa herramientas de alguien que las entiende.

La Amiga 500 de 1994 y el Railway de 2024 son el mismo continuo. Cambió todo y no cambió nada: sigue siendo sobre hacer que las máquinas hagan lo que vos querés que hagan. Sigue siendo sobre entender qué pasa cuando algo falla. Sigue siendo sobre esa sensación — adictiva, visceral, única — de ver algo que construiste funcionando en el mundo real.

Tres años. Una Amiga. Treinta y uno después, acá sigo.

Este artículo fue publicado originalmente en juanchi.dev

De 3 segundos a 300ms: cómo optimicé el performance de una app Next.js en producción

Juan Torchia — Tue, 07 Apr 2026 00:29:49 +0000

Hay un momento específico en la vida de un desarrollador donde te das cuenta que rompiste algo. No con un error. Con silencio. Con lentitud. Con ese spinner que gira y gira mientras el usuario se pregunta si tu app está viva o ya murió.

Me pasó en producción. Una app Next.js que habíamos lanzado con orgullo estaba tardando entre 2.8 y 3.4 segundos en el First Contentful Paint. En mobile, peor. El LCP rondaba los 4 segundos. Google Lighthouse me miraba con cara de asco y yo no tenía excusas — era mi código, mis decisiones, mi problema.

Este es el relato de cómo diagnostiqué el desastre, qué cambié, y cómo llegué a 300ms de FCP en producción. Sin bullshit, sin "simplemente usá un CDN", con el trabajo sucio que nadie muestra en los tutoriales.

El diagnóstico: primero entendé qué está ardiendo

Antes de tocar una sola línea de código, necesitás saber qué está lento. Yo cometí el error clásico: asumir. "Seguro es el bundle", pensé. Spoiler: no era solo el bundle.

Las herramientas que usé:

Lighthouse en modo incógnito (sin extensiones que contaminen los resultados)
Chrome DevTools → Network tab con throttling a "Fast 3G"
Vercel Analytics para datos reales de usuarios
next build con ANALYZE=true para ver el bundle

Para el bundle analyzer, instalé esto:

npm install @next/bundle-analyzer

Y en next.config.js:

const withBundleAnalyzer = require('@next/bundle-analyzer')({
  enabled: process.env.ANALYZE === 'true',
})

/** @type {import('next').NextConfig} */
const nextConfig = {
  // tu config
}

module.exports = withBundleAnalyzer(nextConfig)

Después corrés:

ANALYZE=true npm run build

Y ahí fue cuando vi el horror. Tenía moment.js importado completo — 67kb gzipped — para formatear dos fechas en toda la app. Tenía una librería de gráficos cargando en el bundle principal cuando solo aparecía en una página de dashboard. Tenía componentes que fetcheaban datos en el cliente cuando perfectamente podían ser Server Components.

El diagnóstico real mostró tres problemas grandes:

Bundle de cliente inflado con dependencias innecesarias
Waterfall de requests en el cliente (fetch tras fetch, en cadena)
Imágenes sin optimizar y sin tamaño declarado (layout shift asesino)

Problema 1: el bundle era un desastre

Bye bye moment.js

Reemplacé moment.js con date-fns usando imports específicos:

// ❌ Antes — importaba todo moment
import moment from 'moment'
const fecha = moment(timestamp).format('DD/MM/YYYY')

// ✅ Después — solo lo que necesito
import { format } from 'date-fns'
import { es } from 'date-fns/locale'
const fecha = format(new Date(timestamp), 'dd/MM/yyyy', { locale: es })

Resultado: -67kb gzipped del bundle principal. Sí, así de ridículo era.

Dynamic imports para lo que no se ve al inicio

El gráfico de dashboard no debería estar en el bundle de la página de inicio. Dynamic import con next/dynamic:

import dynamic from 'next/dynamic'

// ❌ Antes
import { RevenueChart } from '@/components/RevenueChart'

// ✅ Después
const RevenueChart = dynamic(
  () => import('@/components/RevenueChart'),
  {
    loading: () => <ChartSkeleton />,
    ssr: false // este componente usa window, no puede hacer SSR
  }
)

Esto sacó ~45kb del bundle inicial y el usuario ve el skeleton mientras carga — mucho mejor UX que ver nada.

Problema 2: el waterfall de fetches en el cliente

Acá estaba el problema más gordo. Tenía una página de perfil de usuario que hacía esto:

// ❌ El horror — cada fetch espera al anterior
const ProfilePage = () => {
  const [user, setUser] = useState(null)
  const [posts, setPosts] = useState([])
  const [stats, setStats] = useState(null)

  useEffect(() => {
    fetch('/api/user')
      .then(r => r.json())
      .then(user => {
        setUser(user)
        // Espera al user para fetchear posts
        return fetch(`/api/posts?userId=${user.id}`)
      })
      .then(r => r.json())
      .then(posts => {
        setPosts(posts)
        // Espera a posts para fetchear stats
        return fetch(`/api/stats?userId=${user.id}`)
      })
      .then(r => r.json())
      .then(setStats)
  }, [])
}

Tres requests en cadena. Esperaba request 1 para lanzar request 2. Esperaba request 2 para lanzar request 3. En una conexión normal eso son 800ms de overhead puro.

La solución en dos pasos:

Paso 1: Paralizar lo que se puede paralelizar

Si tenés el userId desde el principio (por ejemplo, de la sesión), no necesitás esperar a que llegue el user para pedir sus posts:

// ✅ Paralelo cuando es posible
const ProfilePage = ({ userId }: { userId: string }) => {
  useEffect(() => {
    Promise.all([
      fetch(`/api/user/${userId}`).then(r => r.json()),
      fetch(`/api/posts?userId=${userId}`).then(r => r.json()),
      fetch(`/api/stats?userId=${userId}`).then(r => r.json()),
    ]).then(([user, posts, stats]) => {
      setUser(user)
      setPosts(posts)
      setStats(stats)
    })
  }, [userId])
}

Paso 2: Moverlo al servidor con Server Components (la solución real)

Pero la solución de verdad era dejar de fetchear en el cliente. Con el App Router de Next.js 13+, esto se convierte en:

// app/perfil/[userId]/page.tsx
// ✅ Server Component — todo en el servidor, en paralelo
import { getUserData, getUserPosts, getUserStats } from '@/lib/api'

export default async function ProfilePage({ 
  params 
}: { 
  params: { userId: string } 
}) {
  // Paralelo en el servidor — no hay waterfall, no hay round trip al cliente
  const [user, posts, stats] = await Promise.all([
    getUserData(params.userId),
    getUserPosts(params.userId),
    getUserStats(params.userId),
  ])

  return (
    <div>
      <UserHeader user={user} />
      <StatsBar stats={stats} />
      <PostsList posts={posts} />
    </div>
  )
}

Esto eliminó completamente el round trip cliente → servidor para el data fetching inicial. El HTML llega al navegador ya con los datos adentro. El tiempo de esos tres fetches dejó de contar para el usuario.

Problema 3: las imágenes me estaban matando

Tenía imágenes con <img> nativo en vez de next/image. Sin width/height declarados. Sin lazy loading inteligente. El Cumulative Layout Shift era de 0.34 — Google te odia si superás 0.1.

// ❌ Layout shift garantizado
<img src={user.avatar} alt={user.name} />

// ✅ Next.js Image con todo configurado
import Image from 'next/image'

<Image
  src={user.avatar}
  alt={user.name}
  width={64}
  height={64}
  className="rounded-full"
  priority={false} // true solo para imágenes above the fold
/>

Para las imágenes hero (above the fold), usé priority={true} para que Next.js las precargue. Para todo lo demás, lazy loading automático.

También configuré los dominios permitidos en next.config.js:

module.exports = {
  images: {
    remotePatterns: [
      {
        protocol: 'https',
        hostname: 'storage.googleapis.com',
        pathname: '/mi-bucket/**',
      },
    ],
    formats: ['image/avif', 'image/webp'],
  },
}

Next.js convierte automáticamente a WebP/AVIF según lo que soporte el browser. Mis imágenes de 800kb bajaron a 120kb en WebP.

El toque final: caching agresivo

Venía cacheando prácticamente nada. Las rutas del App Router tienen cache por defecto, pero yo lo estaba rompiendo sin querer:

// ❌ Esto desactiva el cache estático
export const dynamic = 'force-dynamic'

// ✅ Revalidación cada 60 segundos — fresco pero cacheado
export const revalidate = 60

Para el fetch dentro de Server Components, usé las opciones de cache:

// Cache con revalidación por tiempo
const data = await fetch('https://api.ejemplo.com/data', {
  next: { revalidate: 3600 } // 1 hora
})

// Cache estático (no cambia nunca hasta el próximo deploy)
const config = await fetch('https://api.ejemplo.com/config', {
  cache: 'force-cache'
})

// Sin cache (datos en tiempo real)
const liveData = await fetch('https://api.ejemplo.com/live', {
  cache: 'no-store'
})

Los resultados reales

Una semana después del deploy con todos los cambios, los números de Vercel Analytics:

Métrica	Antes	Después	Mejora
FCP (p75)	3.1s	310ms	-90%
LCP (p75)	4.2s	820ms	-80%
CLS	0.34	0.02	-94%
Bundle size	487kb	198kb	-59%
TTFB	890ms	180ms	-80%

El score de Lighthouse pasó de 42 a 91. En mobile, de 31 a 84.

Lo que más impactó, en orden:

Server Components eliminando el client waterfall (40% de la mejora)
Bundle splitting y eliminación de dependencias pesadas (30%)
Optimización de imágenes (20%)
Caching (10%)

Lo que aprendí — y lo que hubiera hecho diferente

El error fundamental fue no medir desde el principio. Desarrollé meses asumiendo que "estaba bien" y recién en producción con usuarios reales vi el desastre. Ahora tengo Lighthouse en el CI/CD que falla el build si el score baja de 80.

También aprendí que optimizar performance no es un sprint, es una mentalidad. Cada dependencia que agregás tiene un costo. Cada fetch en el cliente tiene un costo. Cada imagen sin dimensiones tiene un costo. El costo se paga después, con usuarios frustrados y SEO en el piso.

La optimización de performance en Next.js no es magia — es diagnóstico honesto, decisiones conservadoras con las dependencias, y aprovechar las herramientas que ya tenés. Los Server Components existen para esto. El Image component existe para esto. El bundle analyzer existe para esto.

Usalos antes de que el Lighthouse te grite.

Este artículo fue publicado originalmente en juanchi.dev

pnpm vs npm vs yarn vs bun: la comparativa definitiva que nadie te va a dar en 2025

Juan Torchia — Tue, 07 Apr 2026 00:29:00 +0000

Hay decisiones en el desarrollo de software que parecen triviales hasta que te explotan en la cara. Qué package manager usar es una de esas. Yo las pagué todas: proyectos con node_modules de 4GB, deploys que fallaban por conflictos de versiones que "no deberían existir", monorepos que tardaban 8 minutos en instalarse en CI. Todo eso me hizo obsesionarme con este tema.

Así que vamos directo al hueso: pnpm vs npm vs yarn vs bun — qué son, qué hacen diferente, cuándo usar cada uno, y cuál ganó mi corazón (y mi .zshrc).

Un poco de historia para que entiendas por qué existe este caos

npm llegó en 2010 pegado a Node.js. Era la única opción y, francamente, era un desastre. El node_modules flat que conocemos hoy ni existía — en las versiones viejas tenías árbol anidado infinito, carpetas dentro de carpetas que llegaban a rutas tan largas que Windows directamente se rendía. En serio.

Yarn apareció en 2016, creado por Facebook (ahora Meta) en colaboración con Google y otros. Fue una bocanada de aire fresco: instalaciones paralelas, lockfile determinístico, cache local. npm tardó años en ponerse al día.

pnpm llegó también por esa época pero tardó más en tomar tracción. Y Bun... Bun es el newcomer que llegó en 2023 a decir que todos los demás son lentos y tiene cierta razón.

npm: el que ya tenés instalado

Lo bueno: Viene con Node. Sin instalación extra, sin explicarle nada a nadie. Para un proyecto pequeño o para onboardear a alguien nuevo es imbatible en simplicidad.

Lo malo: Sigue siendo el más lento de los cuatro en instalaciones en frío. El node_modules es un monstruo flat que duplica paquetes alegremente. En un monorepo mediano vi node_modules llegar a 3.8GB. Eso no es normal. Eso es un problema.

La versión 7 trajo workspaces, la 8 mejoró bastante el performance, y npm hoy en día es decente. Pero "decente" no es suficiente cuando existían mejores alternativas hace años.

Mi experiencia real: En 2021 arranqué un proyecto con npm por defecto. A los tres meses el CI tardaba 6 minutos solo en el npm install. Migré a pnpm en un viernes a la tarde (error mío, nunca migrés nada importante un viernes) y el lunes el CI tardaba 90 segundos. Eso me marcó.

Cuándo usarlo: Cuando el proyecto es chico, cuando el equipo no quiere fricción de setup, o cuando trabajás con herramientas que tienen bugs conocidos con pnpm (sí, existen, aunque cada vez menos).

Yarn: el que prometía mucho y se complicó

Yarn clásico (v1) fue revolucionario en su momento. Lockfile determinístico, caché que realmente funcionaba, parallelismo. npm tardó literalmente años en igualar esas features.

Pero después llegó Yarn Berry (v2 en adelante) y todo se complicó. Introdujeron Plug'n'Play (PnP): en lugar de node_modules, un sistema de resolución propio donde los paquetes están en archivos .zip y un loader los resuelve en runtime. La teoría es preciosa. La práctica es otro tema.

Probé Yarn Berry en un proyecto Next.js y fue una tarde entera de debuggear por qué ciertos paquetes no levantaban. Algunos tools del ecosistema simplemente no entienden el modelo PnP. Terminé en nodeLinker: node-modules en el .yarnrc.yml, que básicamente es usar Yarn Berry actuando como Yarn clásico. ¿Para qué, entonces?

Lo bueno de Yarn: La DX cuando funciona es muy linda. Los workspaces de Yarn son muy maduros. El equipo de Yarn lleva años puliendo esto.

Lo malo: La fragmentación entre v1 y v2/v3/v4 es un quilombo. Si buscás un error en Stack Overflow, el 60% de las respuestas son para la versión equivocada. Y PnP, aunque brillante conceptualmente, genera fricción real.

Cuándo usarlo: Yarn clásico (v1) en proyectos legados que ya lo usan y no vale la pena migrar. Yarn Berry si estás dispuesto a invertir tiempo en entender PnP y tu equipo está alineado.

pnpm: mi favorito sin discusión

Acá es donde me pongo intenso, así que aguantame.

pnpm resuelve el problema fundamental del package management de Node de una manera elegante: el content-addressable store. En lugar de copiar paquetes en cada node_modules, usa hard links a un store global en tu máquina. lodash instalado en 47 proyectos distintos ocupa espacio de disco una sola vez. El node_modules de cada proyecto son mayormente symlinks y hard links.

Esto tiene consecuencias reales:

Velocidad: Primera instalación comparable a npm/yarn. Segunda instalación y en adelante: ridículamente rápida.
Espacio en disco: Tengo quizás 200 proyectos en esta máquina. Si usara npm serían cientos de GB. Con pnpm el store global ocupa ~15GB para todo.
Correctitud: pnpm es estricto con las dependencias. No podés acceder a un paquete que no declaraste en tu package.json. Esto parece una molestia hasta que te das cuenta de que npm/yarn te dejan acceder a dependencias transitivas silenciosamente — una bomba de tiempo.

Los workspaces de pnpm son los mejores del ecosistema, punto. El archivo pnpm-workspace.yaml es simple, el hoisting configurable, y el comando pnpm -r para correr scripts en todos los packages es una joya.

Mi experiencia real: Hoy uso pnpm en absolutamente todos mis proyectos personales y profesionales. El comando que más escribo después de git es probablemente pnpm install. Tuve exactamente un problema de compatibilidad en dos años: una librería vieja que asumía hoisting de npm. Lo resolví en 10 minutos con .npmrc ajustado.

Lo malo de pnpm: La instalación inicial es un paso extra. Algunos proyectos open source con configs de npm legacy pueden dar dolores de cabeza. Y el store global puede crecer mucho si no hacés pnpm store prune de vez en cuando (yo lo tengo en un cron).

Cuándo usarlo: Casi siempre. Especialmente en monorepos. Especialmente si te importa el espacio en disco. Especialmente si querés que tus dependencias estén correctamente declaradas.

Bun: el que llegó a romper todo

Bun no es solo un package manager — es un runtime completo (reemplazo de Node), un bundler, un test runner, y un transpiler. Pero acá hablamos de su faceta como package manager.

Los números: Bun install es absurdamente rápido. Hablo de instalaciones en frío de proyectos medianos en 2-3 segundos. Lo que npm hace en 45 segundos, Bun lo hace en 3. Está escrito en Zig, usa su propio runtime, y tiene un caché binario que hace que las instalaciones repetidas sean casi instantáneas.

Lo probé en un proyecto Next.js y funcionó perfecto. El lockfile (bun.lockb) es binario, lo cual es raro conceptualmente pero funciona. Los workspaces están soportados. La compatibilidad con el ecosistema npm es muy buena.

Pero acá viene mi hesitación: Bun como runtime todavía tiene edge cases donde el comportamiento difiere de Node. Si usás Bun solo como package manager (con Node como runtime), eso desaparece — pero entonces estás instalando un tool enorme para usar solo una fracción.

El ecosistema de Bun maduró muchísimo en 2024. Para 2025 es una opción real y seria. Pero yo todavía no migré mis proyectos productivos porque el riesgo/beneficio no cierra para mí. La velocidad de pnpm con caché es más que suficiente, y el modelo mental de Bun como "todo en uno" todavía me genera incertidumbre en deployments complejos.

Cuándo usarlo: Si arrancás un proyecto nuevo y querés experimentar. Si el performance de instalación es crítico para vos (¿monorepo enorme en CI sin caché?). Si sos el tipo de persona que le gusta estar en la vanguardia y bancarse algún rough edge.

La tabla que todos quieren

	npm	Yarn	pnpm	Bun
Velocidad (frío)	Lento	Medio	Rápido	Muy rápido
Velocidad (caché)	Medio	Rápido	Muy rápido	Muy rápido
Espacio en disco	Mucho	Mucho	Poco	Poco
Monorepos	Básico	Bueno	Excelente	Bueno
Madurez	Alta	Alta	Alta	Media
Compatibilidad	Total	Alta	Alta	Alta
Strictness	No	No	Sí	No

Mi recomendación final, sin rodeos

¿Proyecto nuevo, 2025? → pnpm. Sin dudarlo. La curva de aprendizaje es mínima (es casi idéntico a npm en la interfaz), los beneficios son inmediatos y reales, y el soporte del ecosistema es excelente.

¿Monorepo? → pnpm con workspaces. Es la mejor opción disponible hoy.

¿Querés vivir en el futuro? → Bun. Pero sabé que vas a ser el beta tester de algunas cosas.

¿Proyecto legado que ya tiene yarn.lock o package-lock.json? → No migrés por migrar. El lockfile es contrato. Si no tenés un motivo real de performance o correctitud, dejalo como está.

npm puro en 2025 sin una razón específica: No. Ya no. Es como usar jQuery en un proyecto nuevo — funciona, pero hay mejores opciones y vos lo sabés.

El ecosistema JavaScript tiene sus mil problemas, pero en package management llegamos a un punto donde tenemos opciones genuinamente buenas. Aprovechalo. Yo tardé demasiado en salir de npm por inercia, y esos 6 minutos de CI en 2021 me los voy a cobrar de alguna forma.

Este artículo fue publicado originalmente en juanchi.dev

Cómo construí juanchi.dev con el stack más bleeding edge de 2025: Next.js 16, React 19, Tailwind v4 y Railway

Juan Torchia — Tue, 07 Apr 2026 00:28:36 +0000

Hay una pregunta que me hice durante meses antes de arrancar con juanchi.dev: ¿uso el stack probado o me tiro de cabeza con lo más nuevo y aguanto los golpes?

Elegí los golpes. Siempre elijo los golpes.

Esto es lo que pasó cuando intenté montar un portfolio de desarrollador con Next.js 16, React 19, Tailwind v4 y Railway en producción — con todo lo que salió mal documentado en tiempo real, porque alguien tiene que hacerlo.

El setup inicial: la arrogancia de los primeros 20 minutos

Empecé con confianza de CEO de startup imaginaria. Tres comandos y ya:

npx create-next-app@latest juanchi-dev \
  --typescript \
  --tailwind \
  --eslint \
  --app \
  --src-dir \
  --import-alias "@/*"

Bien. Proyecto andando. Tailwind v4 instalado automáticamente porque usé el flag correspondiente. Acá fue cuando me di cuenta que v4 no tiene tailwind.config.js por defecto — toda la configuración vive en el CSS directamente:

@import "tailwindcss";

@theme {
  --font-family-display: "Inter Variable", sans-serif;
  --color-brand: oklch(62% 0.25 240);
  --color-brand-dark: oklch(45% 0.25 240);
  --breakpoint-xs: 20rem;
}

Esto es raro al principio. Muy raro. Durante dos horas busqué dónde meter mi extend de colores personalizados hasta que leí la documentación de verdad. Con v4, el archivo CSS es la configuración. Una vez que lo internalizás, es hermoso. Hasta entonces, duele.

React 19 y los Server Components: amigos con beneficios que te complican la vida

La idea era simple: portfolio estático en su mayoría, con algunas partes dinámicas. Uso de Server Components para todo lo que pueda, Client Components solo donde necesito interactividad.

Acá está la estructura que terminé usando:

src/
  app/
    page.tsx          → Server Component (hero + about)
    projects/
      page.tsx        → Server Component (fetch de proyectos)
      [slug]/
        page.tsx      → Server Component (detalle del proyecto)
    blog/
      page.tsx        → Server Component
    contact/
      page.tsx        → mezcla de los dos mundos
  components/
    ui/               → Client Components (animaciones, forms)
    server/           → Server Components (cards, layouts)

El problema vino con las animaciones. Quería ese efecto de entrada donde cada sección aparece al hacer scroll. Usé framer-motion y el compilador me mandó directo al carajo:

Error: useState can only be used in a Client Component.
Add the "use client" directive at the top of the file.

Claro. framer-motion necesita el DOM. Solución: wrapper client-side que envuelve los Server Components:

// components/ui/animated-section.tsx
'use client'

import { motion } from 'framer-motion'
import { ReactNode } from 'react'

interface AnimatedSectionProps {
  children: ReactNode
  delay?: number
}

export function AnimatedSection({ children, delay = 0 }: AnimatedSectionProps) {
  return (
    <motion.div
      initial={{ opacity: 0, y: 24 }}
      whileInView={{ opacity: 1, y: 0 }}
      viewport={{ once: true }}
      transition={{ duration: 0.5, delay, ease: 'easeOut' }}
    >
      {children}
    </motion.div>
  )
}

Y en el Server Component:

// app/page.tsx (Server Component)
import { AnimatedSection } from '@/components/ui/animated-section'
import { HeroContent } from '@/components/server/hero-content'

export default function HomePage() {
  return (
    <main>
      <AnimatedSection>
        <HeroContent />
      </AnimatedSection>
    </main>
  )
}

El patrón de "wrapper client, contenido server" es la clave. Lo entendí tarde, pero lo entendí.

El sistema de proyectos: MDX + generación estática

Para los proyectos decidí usar archivos MDX locales. Sin CMS, sin base de datos, sin dependencias externas para el contenido. Los archivos viven en el repo.

// lib/projects.ts
import fs from 'fs'
import path from 'path'
import matter from 'gray-matter'

const projectsDir = path.join(process.cwd(), 'content/projects')

export interface Project {
  slug: string
  title: string
  description: string
  stack: string[]
  year: number
  liveUrl?: string
  repoUrl?: string
  featured: boolean
  content: string
}

export async function getAllProjects(): Promise<Project[]> {
  const files = fs.readdirSync(projectsDir)

  return files
    .filter(f => f.endsWith('.mdx'))
    .map(filename => {
      const slug = filename.replace('.mdx', '')
      const raw = fs.readFileSync(path.join(projectsDir, filename), 'utf8')
      const { data, content } = matter(raw)

      return {
        slug,
        title: data.title,
        description: data.description,
        stack: data.stack ?? [],
        year: data.year,
        liveUrl: data.liveUrl,
        repoUrl: data.repoUrl,
        featured: data.featured ?? false,
        content
      }
    })
    .sort((a, b) => b.year - a.year)
}

export async function getProjectBySlug(slug: string): Promise<Project | null> {
  const projects = await getAllProjects()
  return projects.find(p => p.slug === slug) ?? null
}

Esto funciona perfecto en local. En Railway empezó el drama.

Railway: el deployment que casi me quiebra

Railway es mi plataforma de hosting favorita para proyectos propios. Precio razonable, DX excelente, deploys desde GitHub automáticos. Pero con Next.js 16 hay que tener cuidado con algo: el output mode.

Por defecto, Next.js genera un bundle que asume que tenés Node.js disponible en runtime. Railway lo maneja bien, pero el fs.readdirSync que uso para leer los archivos MDX no funciona si configurás output: 'export' (modo totalmente estático).

Yo, genio que soy, lo había puesto en output: 'export' porque quería el deploy más rápido posible. El resultado:

Error: ENOENT: no such file or directory, scandir '/app/content/projects'

El directorio content/ no estaba en el build de producción. El problema era que Railway copiaba el output exportado pero no los archivos fuente. Dos opciones:

Cambiar a modo Node.js (server-side rendering real)
Mantener export pero pre-generar todo en build time

Elegí el modo Node.js porque igual necesitaba el endpoint de contacto con lógica server-side:

// next.config.ts
import type { NextConfig } from 'next'

const nextConfig: NextConfig = {
  // Sin output: 'export' — modo Node.js
  images: {
    remotePatterns: [
      {
        protocol: 'https',
        hostname: 'github.com'
      }
    ]
  },
  experimental: {
    optimizePackageImports: ['framer-motion', 'lucide-react']
  }
}

export default nextConfig

Y el railway.toml que me salvó la vida:

[build]
builder = "nixpacks"
buildCommand = "npm run build"

[deploy]
startCommand = "npm run start"
healthcheckPath = "/"
healthcheckTimeout = 30
restartPolicyType = "on_failure"
restartPolicyMaxRetries = 3

[[services]]
name = "juanchi-dev"

El formulario de contacto: Server Actions al rescate

Con Next.js 15+ y React 19, los Server Actions son ciudadanos de primera clase. El formulario de contacto que manda un mail fue el lugar perfecto para usarlos:

// app/contact/actions.ts
'use server'

import { Resend } from 'resend'
import { z } from 'zod'

const resend = new Resend(process.env.RESEND_API_KEY)

const ContactSchema = z.object({
  name: z.string().min(2).max(100),
  email: z.string().email(),
  message: z.string().min(10).max(2000)
})

export async function sendContactEmail(
  prevState: { success: boolean; error?: string } | null,
  formData: FormData
) {
  const raw = {
    name: formData.get('name'),
    email: formData.get('email'),
    message: formData.get('message')
  }

  const parsed = ContactSchema.safeParse(raw)

  if (!parsed.success) {
    return { success: false, error: 'Datos inválidos. Revisá los campos.' }
  }

  try {
    await resend.emails.send({
      from: 'contacto@juanchi.dev',
      to: 'yo@juanchi.dev',
      subject: `Nuevo contacto: ${parsed.data.name}`,
      text: `De: ${parsed.data.email}\n\n${parsed.data.message}`
    })

    return { success: true }
  } catch (error) {
    console.error('Error enviando mail:', error)
    return { success: false, error: 'Error al enviar. Probá de nuevo.' }
  }
}

// app/contact/contact-form.tsx
'use client'

import { useActionState } from 'react'
import { sendContactEmail } from './actions'

export function ContactForm() {
  const [state, action, isPending] = useActionState(sendContactEmail, null)

  return (
    <form action={action} className="flex flex-col gap-4">
      <input
        name="name"
        placeholder="Tu nombre"
        className="border border-neutral-700 bg-neutral-900 px-4 py-3 rounded-lg"
        required
      />
      <input
        name="email"
        type="email"
        placeholder="tu@mail.com"
        className="border border-neutral-700 bg-neutral-900 px-4 py-3 rounded-lg"
        required
      />
      <textarea
        name="message"
        placeholder="En qué puedo ayudarte..."
        rows={5}
        className="border border-neutral-700 bg-neutral-900 px-4 py-3 rounded-lg resize-none"
        required
      />
      <button
        type="submit"
        disabled={isPending}
        className="bg-brand text-white py-3 rounded-lg disabled:opacity-50"
      >
        {isPending ? 'Enviando...' : 'Mandar mensaje'}
      </button>
      {state?.success && <p className="text-green-400">¡Mensaje enviado!</p>}
      {state?.error && <p className="text-red-400">{state.error}</p>}
    </form>
  )
}

useActionState es el hook nuevo de React 19 que reemplaza al viejo patrón de useFormState de react-dom. Más limpio, mejor tipado, manejo de pending nativo.

Lo que salió mal: el resumen ejecutivo

Para los que llegaron acá directamente desde el título buscando el drama:

1. Tailwind v4 rompió todos mis snippets guardados. Las utilities cambiaron sutilmente. text-sm sigue existiendo pero los valores por defecto son diferentes. Pasé 40 minutos debuggeando un font-size que "se veía raro" hasta que lo medí con DevTools.

2. framer-motion con React 19 tuvo un bug de hidratación la primera semana. Se resolvió actualizando a framer-motion@12.x. Lección: cuando usás bleeding edge, los paquetes de terceros se quedan atrás.

3. Railway construía bien pero el healthcheck fallaba porque el servidor tardaba más de 10 segundos en responder al primer request (cold start). Solución: aumentar healthcheckTimeout a 30 segundos en el railway.toml.

4. Los tipos de TypeScript de Next.js 16 para algunos parámetros de layouts y pages cambiaron. params ahora es una Promise en algunos contextos. Esto me rompió tres archivos.

// Antes (Next.js 14):
export default function ProjectPage({ params }: { params: { slug: string } }) {

// Ahora (Next.js 15/16):
export default async function ProjectPage(
  { params }: { params: Promise<{ slug: string }> }
) {
  const { slug } = await params

¿Lo volvería a hacer?

Sí. Sin dudas.

Hay algo en trabajar con stack bleeding edge que te fuerza a leer documentación de verdad, a entender por qué las cosas funcionan y no solo cómo. Cuando algo rompe en territorio desconocido no podés copypastear Stack Overflow — tenés que pensar.

Y el resultado final es un portfolio de desarrollador con Next.js y Railway que carga en menos de 1.2 segundos, tiene Lighthouse a 98/100, corre en producción por menos de 5 dólares al mes, y lo más importante: lo entiendo de punta a punta.

La tech nueva duele al principio. Después de eso, es una ventaja competitiva.

El código fuente de juanchi.dev va a estar público en GitHub cuando termine de limpiar los comentarios avergonzantes del proceso. Pronto.

Este artículo fue publicado originalmente en juanchi.dev