El exfundador de tecnología de Meta comparte tres cosas que todo director de tecnología debe hacer antes de tocar la IA

James Everingham ha dirigido la ingeniería en algunas de las empresas más avanzadas del mundo, incluida Meta. Actualmente es el director ejecutivo y cofundador de Guild.ai, un plano de control para agentes de IA que ofrece a las organizaciones un único lugar para implementar, gobernar, observar y optimizar cada agente en producción.

Nos reunimos con James para saber cómo la IA está cambiando los flujos de trabajo de ingeniería y qué deben cambiar los equipos de ingeniería antes de que la IA pueda integrarse de forma eficaz. Esto es lo que nos contó.

De Meta a una startup de IA

Soy el director ejecutivo y cofundador de Guild.ai, el plano de control para agentes de IA que ofrece a las organizaciones un único lugar para implementar, gobernar, observar y optimizar cada agente en producción. Hemos recaudado 44 millones de dólares: una ronda de serie A liderada por Google Ventures, con la participación de NFX, Acrew, Scribble Ventures, Khosla Ventures y Webb Investment Network. Somos un equipo de unas 35 personas con sede en San Francisco.

Antes de esto, fui vicepresidente de Ingeniería en Meta DevInfra, donde construía y gestionaba las herramientas, los servicios y las plataformas centrales para desarrolladores que impulsaban los productos de Meta. Mi equipo creó el primer agente de IA interno de Meta, lo que tuvo un impacto inmediato en la forma en que los ingenieros de Meta utilizaban las herramientas de IA. Durante mi etapa en Meta, también cocreé Diem y fui director de Ingeniería de Instagram.

Con una carrera de 40 años como gerente, emprendedor y desarrollador tecnológico, he dirigido numerosos equipos de ingeniería de primer nivel mundial. En Yahoo, fui vicepresidente de Ingeniería de las propiedades de medios de Yahoo después de que adquirieran Luminate, una empresa de tecnología de imágenes interactivas que fundé. Antes de eso, dirigí equipos en Oracle, Netscape Communications, Tellme (adquirida por Microsoft) y varias empresas propias.

Cómo la IA ayudó a eliminar la congelación anual del código de Meta

Cuando estaba en Meta, utilizamos un modelo de riesgo basado en IA para acabar con la congelación anual del código.

Antes, Meta congelaba su base de código todos los años desde mediados de diciembre hasta enero, porque ese es el periodo de mayor tráfico para sus productos. Durante años, para evitar incidentes en producción en las semanas de mayor riesgo, nadie hacía lanzamientos. Esto era seguro, pero también paralizaba la productividad de toda la empresa durante más de un mes.

Mi equipo creó y publicó como código abierto Diff Risk Score, un sistema basado en un modelo de lenguaje de gran tamaño que calcula la probabilidad de que una diferencia de código provoque un fallo en producción. En lugar de tratar todos los cambios como igual de peligrosos durante el periodo de congelación, el modelo realizaba una clasificación de riesgos. Asignaba una puntuación de riesgo continua a cada diferencia, ajustada para lograr una alta cobertura: por ejemplo, señalaba el 10 % de las diferencias y detectaba el 60 % de los cambios que realmente provocaban incidentes. El modelo permitía incorporar diferencias de bajo riesgo incluso durante la congelación, pero retenía aquellas que señalaba como arriesgadas.

Como resultado, la congelación ya no es una medida de todo o nada. Además, Diff Risk Score está permitiendo que Meta empiece a eliminar por completo la congelación del código: los ingenieros están recuperando semanas de su calendario que antes eran tiempo perdido, sin sacrificar la red de seguridad que proporcionaba la congelación.

Es un buen ejemplo de mi filosofía general: no impongas a los ingenieros un mandato de IA de arriba abajo; dales infraestructura —una plataforma centralizada, una señal de riesgo, un plano de control— y deja que ellos descubran por sí mismos cómo aprovecharla.

Por qué los humanos deben poder explicar el código antes de ponerlo en producción

Si no puedes explicarlo, no puedes ponerlo en producción.

Utilizo herramientas de IA de forma intensiva para acelerar el trabajo, pero aconsejo a los ingenieros que exijan siempre una validación antes de que nada llegue a producción. La IA no sustituye el criterio de ingeniería; proporciona a los ingenieros una mayor capacidad para aplicar ese criterio a escala.

Ahora la IA también informa el trabajo de evaluación de riesgos, así como el de descubrimiento de herramientas y flujos de trabajo.

En qué destacan los humanos:

• Gobernanza y barreras de protección en torno a los propios agentes: Cuando los equipos integran modelos de razonamiento y agentes profundamente en la infraestructura, rápidamente detectan fallos de gobernanza: los agentes se multiplican más rápido de lo esperado y los presupuestos se evaporan de la noche a la mañana. Necesitas la misma capa de gobernanza en torno a los agentes no deterministas que la que implementarías para las personas que utilizan esa infraestructura, lo que significa que los humanos siguen estableciendo los límites presupuestarios, las fronteras de acceso y los requisitos de auditoría.
• Estrategia de adopción: No se puede imponer la adopción de herramientas de IA: el uso que se gana supera al uso impuesto, ya que los mandatos producen una adopción superficial. Decidir cómo integrar la IA en el flujo de trabajo de un equipo es claramente una decisión humana de liderazgo y cultura; la herramienta puede demostrar su valor, pero la decisión de adopción no puede automatizarse.

Por qué los equipos de ingeniería deben replantearse su arquitectura

La informática comenzó con un único ordenador central que todos compartían y después pasó a bastidores de servidores que ejecutaban servicios especializados. Los agentes están siguiendo el mismo recorrido.

La antigua premisa era crear un puñado de agentes de propósito general y centralizar su uso en torno a ellos, como se centraliza la capacidad de cómputo. Pero las empresas se dan cuenta de que su realidad no consiste en un puñado de herramientas compartidas, sino que se parece más a un ecosistema de agentes especializados y diseñados para fines concretos. Esto obliga a replantearse qué significa realmente «arquitectura» para una base de código: menos un monolito con complementos y más un mundo de microservicios, salvo que los servicios sean agentes en lugar de puntos finales.

El instinto en la mayoría de las organizaciones es tratar un agente como cualquier otra pieza de software: redactar la especificación, ponerlo en producción y esperar resultados coherentes. Yo abandoné ese enfoque y lo sustituí por un modelo mental basado en una plantilla laboral. Esto replantea las preguntas sobre el diseño de la organización —quién aprueba qué, quién controla el presupuesto y quién rinde cuentas cuando algo falla— como cuestiones de gestión, no de despliegue. Es una forma diferente de estructurar la relación de un equipo con sus herramientas.

Por qué la gobernanza debe estar implantada antes de que despegue la adopción de la IA

En mis puestos anteriores, me habría gustado que hubiéramos creado la capa de gobernanza antes de que despegara la adopción, no después.

Cuando estaba en Meta, los ingenieros empezaron a crear y publicar sus propios agentes en la plataforma interna; los agentes se multiplicaron rápidamente y el equipo de infraestructura tuvo que apresurarse de repente para satisfacer la demanda, intentando literalmente encontrar decenas de miles de servidores libres.

Visto en retrospectiva, esto se podía haber evitado. Si supones que la adopción podría hacerse viral internamente, incorporas los controles de costes y las fronteras de acceso como parte de la plataforma desde el primer día, no como una respuesta de emergencia.

Los CTO deben rediseñar el límite entre «dónde vive la IA» y «qué puede tocar la IA», trasladándolo fuera del editor y a su infraestructura, porque esa es la capa donde se origina el riesgo y debe residir la gobernanza.

James comparte

Los CTO deben rediseñar el límite entre “dónde vive la IA” y “lo que la IA puede tocar” — trasladándolo fuera del editor y a su infraestructura, porque esa es la capa donde se origina el riesgo y debe residir la gobernanza.

Por qué las organizaciones deben disponer de un lugar centralizado donde se puedan bifurcar los agentes

Como ingeniero, era mejor ladrón que programador. Encontraba algo que satisfacía parcialmente mis necesidades, lo adaptaba a mi propósito específico y aprendía por el camino.

El primer paso del flujo de trabajo no es «pedirle algo a un modelo», sino explorar un lugar centralizado para ver qué agentes existen ya para esta tarea y bifurcar uno en lugar de empezar desde cero. Las organizaciones deben crear procesos que permitan copiar agentes fácilmente.

Tres consejos para los CTO que integran la IA en organizaciones técnicas

Este es mi consejo:

1. No lo impongas: gánatelo. El uso obligatorio de la IA para mejorar la productividad me frustra porque produce una adopción superficial; las mejores herramientas para desarrolladores se ganan su uso, y los desarrolladores son lo bastante inteligentes como para resistirse a que les digan qué herramientas deben apreciar. Los CTO deberían plantear a la organización retos empresariales de gran magnitud: problemas tan grandes que la IA sea la única solución realista. Después, hay que dejar que los ingenieros que los resuelvan se conviertan en defensores espontáneos. 
2. Deja de tratar la IA como una herramienta de creación y empieza a tratarla como infraestructura. 2025 fue el año en que las herramientas de programación como Cursor y Copilot se generalizaron; ahora, los modelos de razonamiento y los agentes de varios pasos dejan de ser complementos del editor y pasan a formar parte de la infraestructura de las empresas: envían código, ejecutan pruebas, incorporan a nuevos ingenieros y gestionan el comportamiento en producción. Si tu estrategia de IA sigue siendo «¿qué complemento del IDE deberíamos comprar?», estás resolviendo un problema antiguo.
3. Gobierna los agentes como gobernarías una plantilla, no como gobernarías un software. Los agentes impulsados por modelos de razonamiento no son deterministas: proporciona la misma entrada dos veces al mismo agente y puedes obtener resultados diferentes. Esto no es un error que haya que corregir; es la naturaleza fundamental de esta tecnología. Los CTO ya gestionan a diario sistemas no deterministas con empleados. Debes aplicar a los agentes algunas de las mismas medidas de seguridad que aplicas a tu plantilla. No concedas a un agente acceso sin restricciones a producción, credenciales raíz ni un presupuesto ilimitado en la nube el primer día, del mismo modo que tampoco se lo concederías a una persona recién contratada.

Sigue su trabajo

Puedes seguir el trabajo de James Everingham en X y LinkedIn.

¡Próximamente habrá más entrevistas con expertos en The CTO Club!