Hanze Li es uno de los Forward Deployed Engineers fundadores de Cresta. Con una trayectoria que abarca hardware, investigación en aprendizaje automático, ingeniería de software y gobierno estudiantil, encarna la filosofía de «conectar los puntos» que define el rol de FDE. Nos sentamos con Hanze en el primer retiro del equipo de FDE en Salt Lake City para escuchar su historia.
Cuéntenos sobre su trayectoria: suena como todo un viaje.
Realmente es un viaje. Empecé a programar cuando tenía ocho años en China; mis padres me enviaron a un club de programación extraescolar y lo odiaba. Me dije a mí mismo que nunca volvería a tocar código.
Avancemos rápido hasta la universidad en Canadá: me matriculé en un programa que pensé que no requeriría mucha programación, pero al cabo de uno o dos años me enamoré por completo de la programación. A partir de ahí fui en muchas direcciones: hice unas prácticas de hardware con FPGA y Verilog, sentado en un laboratorio probando chips de silicio reales. Dije «no, esto no es para mí» y volví al software. Luego me atrajo la investigación en ML, publiqué tres o cuatro artículos y pensé que quizás haría un doctorado en entrenamiento de modelos fundacionales. A mitad de mi tesis de grado dije «no, esto tampoco soy yo».
Terminé haciendo un máster en IA en la University of Toronto y, en paralelo, cofundé con muchos amigos lo que sigue siendo uno de los clubes estudiantiles de aprendizaje automático más grandes de allí: University of Toronto Machine Intelligence Student Team (UTMIST). También hice campañas para el consejo de gobierno como representante estudiantil. En ese momento, nada de eso parecía conectar. Y luego me uní a Cresta como FDE y, de repente, cada una de esas piezas de mi trayectoria resultó útil.
¿Cómo se conectan todas esas experiencias con el rol de FDE?
Hay una analogía de Steve Jobs a la que vuelvo una y otra vez: su famosa teoría de «conectar los puntos». Trabajó en tecnología, hardware, estudió caligrafía y viajó a la India. Todo parecía tiempo perdido, hasta que dejó de serlo. Con el FDE es lo mismo: no necesita ser un ingeniero de backend sénior que conozca cada rincón de la infraestructura, ni tampoco un científico investigador que desarrolle modelos fundacionales. Pero si está por encima de la media en todas esas cosas combinadas (programación, aprendizaje automático, comunicación con el cliente, incluso hablar en público), es realmente muy bueno como FDE.
Cada FDE es casi como un CTO en una empresa emergente: sólido en tecnología, capaz de gestionar directamente la relación con el cliente, pero que prefiere trabajar en el lado técnico más que puramente en el lado del negocio. Necesita generar confianza con el cliente y elaborar juntos un buen plan para que las cosas sucedan. No se trata de seguir ciegamente lo que quiera el cliente: es una conversación, basada en la confianza, la experiencia y la habilidad.
La trampa habitual es la mentalidad tradicional de la ingeniería de software: un PM le da un ticket y usted dice «me pongo con ello, dos semanas, entrega de alta calidad». Como FDE, ese podría no ser el mejor enfoque. Tiene que entender lo que el cliente realmente quiere, proponer opciones e impulsar la priorización. Opción uno: cambiarlo correctamente, dos semanas, perfecto. Opción dos: un cambio menor, el ochenta por ciento del beneficio, un esfuerzo mínimo. Opción tres: no hacer nada, sigue siendo lo suficientemente bueno. La mayoría de los clientes eligen la opción intermedia. Como FDE, usted es quien crea ese menú.
¿Cómo es un día típico?
La respuesta oficial es 1/3 desarrollo de agentes de IA, 1/3 relación con el cliente, 1/3 trabajo relacionado con el producto. En la práctica, va cambiando con el tiempo.
Cuando me incorporé, probablemente más de la mitad de mi tiempo se dedicaba al desarrollo de agentes de IA: ponerme al día con nuestra infraestructura, herramientas como Claude Code, todas las primitivas de ingeniería agéntica. Esos son multiplicadores de eficiencia que le ahorran una enorme cantidad de tiempo más adelante.
Después de unos seis meses, mi reparto se ha invertido. Ahora menos de un tercio es programación. Puedo crear una versión lista para demostración incluso de casos de uso complejos en uno o dos días. El resto son pruebas, evaluación y relación con el cliente. Aunque no soy FDPM, también estoy en el lado del negocio: soy el representante que explica el mundo técnico. Cuando un cliente me hace una solicitud puedo decir: «Esta funcionalidad parece compleja, pero en realidad es fácil», o «Esta parece sencilla, pero tiene implicaciones importantes en el backend». Ese ir y venir, generando confianza real, es una parte enorme del trabajo.
Algo que realmente me inspiró después de unirme a Cresta: muchos problemas que suenan técnicos terminan resolviéndose con habilidades interpersonales. Un cliente reporta un error. En realidad no es un error: es una funcionalidad que aún no hemos entregado, o algo que podemos sortear. La habilidad está en saber presentar las opciones con claridad, dejar que el cliente tome una decisión informada y avanzar rápido en lo correcto. En el mundo de los LLM siempre hay algo de alucinación por muy cuidadosamente que gestione los casos límite, así que realmente hay que priorizar en lugar de simplemente corregir.
Usted trabaja con Brinks Home, uno de los clientes de Cresta. ¿Cómo es esa relación?
Brinks Home es un cliente muy especial. He trabajado con bastantes clientes, y lo que hace único a Brinks es el nivel de confianza: avanzamos juntos. No es «Cresta construye algo y luego Brinks decide si lo compra». Es más bien: «Tenemos algo nuevo. Confiamos en que funciona, pero nadie lo ha adoptado todavía. ¿Quiere ser el primero?». Y Brinks siempre dice que sí.
La metáfora que uso es al estilo omakase. En un restaurante omakase tradicional, uno confía plenamente en el chef; le trae lo mejor que puede ofrecer, y su trabajo es probarlo con la mente abierta. Brinks nos brinda esa misma confianza. Nos aseguramos de que todo lo que llevamos sea seguro, esté probado y sea lo mejor que podemos ofrecer. Y como lo hemos hecho bien en el pasado, confían en nosotros para el siguiente paso.
Un producto reciente que acabamos de lanzar con Brinks se llama Agent Operations Center: es un sistema con intervención humana («human-in-the-loop») para agentes de IA. En lugar de reemplazar a los agentes humanos, asigna a los agentes de IA el trabajo simple y repetitivo y les permite levantar la mano cuando algo se vuelve complejo, como una solicitud de descuento, un caso límite inusual, cualquier cosa que no quiera que la IA decida por sí sola. El agente de IA presenta el contexto, un supervisor en el backend dice «dé un veinte por ciento de descuento» o «no ceda», y el agente continúa la conversación sin problemas. Esto es muy similar a los agentes humanos reales, que de vez en cuando necesitarán que un supervisor sénior les ayude en asuntos complejos o delicados.
Como FDE principal en ese lanzamiento, hay que pensar en cada caso límite. ¿Qué pasa si no hay ningún supervisor en línea? ¿Qué pasa si el que recibió el aviso olvidó responder? ¿Qué pasa si el agente de IA malinterpreta la instrucción? La primera vez que hace algo, todas esas preguntas son preguntas abiertas. La segunda vez es mucho más fácil porque tiene experiencia y un producto maduro. Pero la primera vez, hay que pensarlo todo, y esa es una de las partes más emocionantes del trabajo.
¿Cómo abordan los FDE las pruebas y la evaluación?
Esto es algo que me apasiona. Construir un agente de IA es un problema de investigación: siempre puede hacer que algo funcione de forma rápida y provisional, pero nunca sabe si es la mejor versión para su cliente o su sector.
Por ejemplo: mostrar siempre empatía puede ser bueno en el sector sanitario, pero en el fintech, si alguien debe dos o cuatro mil dólares a un banco y el agente de IA es excesivamente empático, la gente tiene sentimientos encontrados. Sectores diferentes, clientes diferentes quieren cosas diferentes. Una determinada herramienta de función o prompt que funciona a la perfección en un sector puede fallar por completo en otro.
La respuesta son los datos. Construya un conjunto de datos, construya un benchmark, valide que su elección de herramientas de función, prompts y bloques de agente reutilizables es realmente la mejor opción, y eso lleva tiempo. No es «probé esto, funcionó para este cliente, así que debe ser lo mejor». Hay que ejecutar evaluaciones adecuadas, comparar las opciones A, B y C, y usar un enfoque basado en datos para ver cuál es genuinamente mejor.
Ahora estamos usando GPT-4.1 para algunos flujos de trabajo. Cuando actualizamos a una versión de modelo más reciente, ¿nuestros prompts siguen siendo la mejor práctica? No lo sabemos, a menos que tengamos un benchmark. El objetivo es: para este sector, con estos prompts, con este modelo base, la conversación sigue funcionando bien. Entonces podemos iterar rápidamente, añadir nuevas capacidades del modelo y confiar en que las regresiones siguen pasando.
Eso es parte de la fórmula secreta de Cresta: tenemos tantas relaciones con clientes y puntos de datos que solo nosotros podemos construir este tipo de benchmark para agentes de IA empresariales. El «vibe coding» funciona a la perfección para demostraciones y agentes de juguete, pero en producción nunca puede confiar en él sin suficientes datos y evaluación detrás.
¿Cuál es su consejo para alguien que está considerando una carrera como FDE?
Pruebe cosas diferentes. Hardware, software, investigación en aprendizaje automático, gobierno estudiantil, trabajo emprendedor: todo puede conectar. Nunca se sabe cuándo una experiencia inusual le ayudará a generar confianza con un líder técnico o a resolver un problema de una manera más sistemática.
El cambio de mentalidad también es importante: sea el dueño, no el ejecutor. No piense «el PM me dio una tarea, me pongo con ella». Comprenda siempre el panorama general, proponga distintas opciones y use un enfoque basado en datos. El código en sí es solo una forma de hacer que las cosas sucedan. El diseño arquitectónico, el modelo de negocio y la relación con los clientes pueden importar aún más ahora, y aún más en el futuro.
He entrevistado a más de treinta personas para puestos de FDE. Muchos dicen «construí un chatbot en casa». Pero cuando profundizamos, han pasado por alto una parte enorme de lo que necesita un chatbot de producción real. Siempre puede leer blogs, pero sin experiencia real de producción en distintos casos de uso y sectores, no obtiene el panorama completo. Hay mucho conocimiento oculto en cualquier industria: cosas que parecen de sentido común solo si ha estado dentro. No sabe lo que no sabe.
¿Hacia dónde ve que se dirige la IA empresarial en los próximos años?
En dos o tres años, espero que nadie tenga que esperar en espera durante una hora para hablar con una aerolínea. Usted comparte su intención, el sistema recuerda su cuenta y las cosas se resuelven en unos minutos. Entonces podremos pasar más tiempo con nuestras familias, con nuestros libros, ir a esquiar, y centrarnos en lo que realmente importa.
Hacia eso se dirige el trabajo de FDE. No solo demostraciones ingeniosas, sino agentes de IA que sean fiables, confiables y genuinamente mejores para las personas que los usan. Siento que nada de mi trayectoria se desperdició al unirme a Cresta. Todos esos puntos se conectaron de una manera que no podría haber planificado.
¿Tiene curiosidad por la ingeniería de despliegue (Forward Deployed Engineering) o por crear agentes de IA empresariales? Cresta está contratando FDE en distintos dominios. Consulte nuestra página de empleo para obtener más información.
Vea la entrevista completa de Hanze aquí.
