José Hurtado_
Veinticuatro años de diseño de producto dejan un residuo específico. Empiezas a ver cada pieza de software a través de lo que le cuesta a las personas cuando falla: el spinner que nunca termina, el flujo de trabajo que pierde estado a mitad del proceso, el agente de IA que devuelve una respuesta equivocada con confianza. Después de suficiente tiempo, dejas de confiar en las cajas negras por principio.
Por qué Kernex
La mayor parte de mi carrera la pasé en entornos regulados y de alto riesgo: flujos de trabajo fintech, dashboards de salud, SaaS empresarial donde una experiencia rota tiene un precio medido en contratos, no solo en NPS. Las herramientas de agentes de IA disponibles cuando empezamos a construir Kernex eran rápidas para prototipar y lentas para confiar. La memoria se filtraba bajo carga. Los cold starts se medían en segundos. El proceso del agente tenía acceso a todo lo que tenía el host. Nadie estaba construyendo la infraestructura con el mismo cuidado que se espera de los equipos de producto en la interfaz.
Así que construimos Kernex en Rust. No porque estuviera de moda. Porque los requisitos eran fundamentales: sandboxing a nivel de SO que el kernel hace cumplir, memoria determinista que no se dispara bajo carga concurrente, cold starts de 12ms para cargas de trabajo programadas, y un sistema de tipos que detecta errores de pipeline antes del despliegue y no a mitad de ejecución. El mismo estándar que aplicaría a una interfaz de producción, aplicado al runtime debajo de ella.
Trayectoria
Director Senior de Diseño de Producto. Veinticuatro años en B2B SaaS, diseño de productos de IA/ML, sistemas de diseño y accesibilidad. Trabajo anterior incluye Nestlé, Mastercard Services, CBX Agency y productos que llegaron a escala en industrias reguladas. Basado en Austin, TX.
Antes de Kernex, DXagency. Antes de eso, dos décadas viendo qué pasa cuando la interfaz está pulida y la infraestructura debajo no lo está. En algún momento, la respuesta lógica es arreglar la infraestructura.