Hanze Li es uno de los Forward Deployed Engineers fundadores de Cresta. Su trayectoria abarca hardware, investigación en machine learning, ingeniería de software y representación estudiantil. Encarna así la filosofía de «conectar los puntos» que define el rol de FDE. Nos sentamos con Hanze en el primer offsite del equipo de FDE en Salt Lake City para escuchar su historia.
Cuéntenos su trayectoria: suena a todo un viaje.
Lo es, desde luego. Empecé a programar con ocho años en China: mis padres me apuntaron a un club de programación extraescolar y lo odiaba. Me dije que no volvería a tocar código nunca más.
Avancemos hasta la universidad, en Canadá. Me matriculé en un programa que creía que no exigiría mucha programación, pero a los uno o dos años me enamoré del código. A partir de ahí probé muchas direcciones. Hice unas prácticas de hardware con FPGA y Verilog, sentado en un laboratorio probando chips de silicio reales. Dije «esto no es para mí» y volví al software. Después me atrajo la investigación en ML, publiqué tres o cuatro artículos y pensé en hacer un doctorado en entrenamiento de modelos fundacionales. A mitad de mi trabajo de fin de grado dije «esto tampoco es lo mío».
Acabé haciendo un máster en IA en la University of Toronto. En paralelo cofundé con muchos amigos lo que sigue siendo uno de los mayores clubes estudiantiles de machine learning de allí: University of Toronto Machine Intelligence Student Team (UTMIST). También me presenté al consejo de gobierno como representante estudiantil. En su momento nada de aquello parecía conectar. Luego entré en Cresta como FDE y de repente cada pieza de esa trayectoria resultó útil.
¿Cómo conectan todas esas experiencias con el rol de FDE?
Hay una analogía de Steve Jobs a la que vuelvo siempre: su famosa teoría de «conectar los puntos». Trabajó en tecnología y hardware, estudió caligrafía y viajó a la India. Todo parecía tiempo perdido, hasta que dejó de serlo. Con el FDE pasa igual: no hace falta ser un ingeniero de backend sénior que conozca cada rincón de la infraestructura, ni un científico investigador que desarrolle modelos fundacionales. Pero si está por encima de la media en todo eso combinado (programación, machine learning, comunicación con el cliente e incluso hablar en público), es muy, muy bueno como FDE.
Cada FDE es casi como el CTO de una startup: fuerte en tecnología, capaz de llevar la relación con el cliente y con preferencia por el lado técnico antes que por el puramente comercial. Hay que generar confianza con el cliente y trazar juntos un buen plan. No se trata de seguir a ciegas lo que pida el cliente: es una conversación basada en la confianza, la experiencia y el oficio.
La trampa habitual es la mentalidad clásica de la ingeniería de software: un PM le pasa un ticket y usted responde «me pongo, dos semanas, entrega de calidad». Como FDE, ese quizá no sea el mejor enfoque. Hay que entender lo que el cliente quiere de verdad, plantear opciones y dirigir la priorización. Opción uno: hacerlo bien, dos semanas, perfecto. Opción dos: un cambio menor, el ochenta por ciento del beneficio, esfuerzo mínimo. Opción tres: no hacer nada, sigue siendo suficiente. La mayoría de los clientes elige la opción intermedia. Como FDE, usted es quien crea ese menú.
¿Cómo es un día normal?
La respuesta oficial es 1/3 desarrollo de agentes de IA, 1/3 relación con el cliente y 1/3 trabajo de producto. En la práctica va cambiando con el tiempo.
Cuando entré, seguramente más de la mitad de mi tiempo iba al desarrollo de agentes de IA: ponerme al día con nuestra infraestructura, herramientas como Claude Code y todas las primitivas de ingeniería agéntica. Son multiplicadores de eficiencia que después le ahorran muchísimo tiempo.
Unos seis meses después, el reparto se ha invertido. Ahora programo menos de un tercio del tiempo. Puedo montar una versión lista para demo 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 de negocio: soy quien traduce el mundo técnico. Cuando un cliente me plantea una petición puedo decirle: «Esta funcionalidad parece compleja, pero en realidad es fácil», o «Esta parece sencilla, pero tiene implicaciones serias en el backend». Ese ir y venir, generando confianza real, es una parte enorme del trabajo.
Algo que me inspiró mucho al entrar en Cresta: muchos problemas que suenan técnicos se acaban resolviendo con habilidades interpersonales. Un cliente informa de un error. En realidad no lo es: es una funcionalidad que aún no hemos entregado, o algo que podemos sortear. La habilidad está en presentar las opciones con claridad, dejar que el cliente decida con información y avanzar rápido en lo correcto. En el mundo de los LLM siempre hay algo de alucinación por muy bien que cubra los casos límite, así que hay que priorizar más que 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 la del 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 da esa misma confianza. Nos aseguramos de que todo lo que llevamos sea seguro, esté probado y sea lo mejor que podemos dar. Y como lo hemos hecho bien antes, 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 sustituir a los agentes humanos, da a los agentes de IA el trabajo simple y repetitivo y les permite levantar la mano cuando algo se complica: una solicitud de descuento, un caso límite poco común, cualquier cosa que no quiera dejar en manos de la IA. El agente de IA muestra el contexto, un supervisor en el backend dice «aplica un veinte por ciento de descuento» o «no cedas», y el agente sigue la conversación sin fricciones. Se parece mucho a lo que ocurre con los agentes humanos, que de vez en cuando necesitan a un supervisor sénior en asuntos complejos o delicados.
Como FDE responsable de ese lanzamiento, hay que pensar en cada caso límite. ¿Y si no hay ningún supervisor conectado? ¿Y si quien recibió el aviso olvidó responder? ¿Y si el agente de IA malinterpreta la instrucción? La primera vez que hace algo, todas esas preguntas están abiertas. La segunda vez es mucho más fácil, porque ya tiene experiencia y un producto maduro. Pero la primera vez hay que pensarlo todo, y esa es una de las partes más apasionantes del trabajo.
¿Cómo abordan los FDE las pruebas y la evaluación?
Es un tema que me toca de cerca. Construir un agente de IA es un problema de investigación: siempre puede sacar algo rápido y provisional que funcione, pero nunca sabe si es la mejor versión para su cliente o su sector.
Un ejemplo: mostrar siempre empatía puede ir bien en sanidad, pero en fintech, si alguien debe dos o cuatro mil dólares a un banco y el agente de IA se pasa de empático, la gente tiene sentimientos encontrados. Sectores distintos y clientes distintos quieren cosas distintas. Una herramienta de función o un prompt que funciona a la perfección en un sector puede fallar del todo en otro.
La respuesta son los datos. Construya un conjunto de datos, construya un benchmark y valide que su elección de herramientas de función, prompts y bloques de agente reutilizables es realmente la mejor. Y eso lleva tiempo. No vale con «probé esto, funcionó con este cliente, así que debe de ser lo mejor». Hay que ejecutar evaluaciones en condiciones, comparar las opciones A, B y C y usar un enfoque basado en datos para ver cuál es genuinamente mejor.
Ahora usamos GPT-4.1 para algunos workflows. Cuando pasamos a una versión más reciente del modelo, ¿nuestros prompts siguen siendo la mejor práctica? No lo sabemos, salvo que tengamos un benchmark. El objetivo es este: para este sector, con estos prompts y con este modelo base, la conversación sigue funcionando bien. A partir de ahí podemos iterar rápido, añadir nuevas capacidades del modelo y confiar en que las regresiones siguen pasando.
Esa es parte de la fórmula secreta de Cresta: tenemos tantas relaciones con clientes y tantos puntos de datos que solo nosotros podemos construir este tipo de benchmark para agentes de IA enterprise. El vibe coding funciona a la perfección para demos y agentes de juguete, pero en producción nunca puede fiarse de él sin datos y evaluación suficientes detrás.
¿Qué consejo daría a quien se plantea una carrera como FDE?
Que pruebe cosas distintas. Hardware, software, investigación en machine learning, representación estudiantil, proyectos emprendedores: todo puede conectar. Nunca se sabe cuándo una experiencia poco común le ayudará a generar confianza con un responsable técnico o a resolver un problema de forma más sistemática.
El cambio de mentalidad también importa: sea el dueño, no el ejecutor. No piense «el PM me dio una tarea, me pongo». Entienda siempre el panorama completo, plantee opciones distintas y use un enfoque basado en datos. El código en sí es solo una manera de hacer que las cosas pasen. El diseño arquitectónico, el modelo de negocio y la relación con los clientes pueden importar aún más hoy, y todavía más en el futuro.
He entrevistado a más de treinta personas para puestos de FDE. Muchas dicen «me hice un chatbot en casa». Pero al profundizar se han saltado una parte enorme de lo que necesita un chatbot real en producción. Siempre puede leer blogs, pero sin experiencia real de producción en distintos casos de uso y sectores no ve el cuadro completo. En cualquier industria hay mucho conocimiento oculto: cosas que parecen de sentido común solo si ha estado dentro. No sabe lo que no sabe.
¿Hacia dónde ve que va la IA enterprise en los próximos años?
En dos o tres años espero que nadie tenga que esperar una hora al teléfono para hablar con una aerolínea. Usted expresa lo que necesita, el sistema recuerda su cuenta y todo se resuelve en unos minutos. Así podremos pasar más tiempo con la familia, con nuestros libros, ir a esquiar y centrarnos en lo que de verdad importa.
Hacia ahí apunta el trabajo del FDE. No solo demos ingeniosas, sino agentes de IA fiables, de confianza y genuinamente mejores para quienes los usan. Siento que nada de mi trayectoria se desaprovechó al entrar en Cresta. Todos esos puntos se conectaron de una forma que no podría haber planificado.
¿Le interesa el Forward Deployed Engineering o crear agentes de IA enterprise? Cresta está contratando FDE en distintos dominios. Consulte nuestra página de empleo para saber más.
Vea aquí la entrevista completa de Hanze.
