El exfundador tecnológico de Meta comparte tres cosas que todo CTO debe hacer antes de tocar la IA

James Everingham ha dirigido la ingeniería de algunas de las empresas más avanzadas del mundo, incluida Meta. Actualmente es el CEO 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 sentamos 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 CEO 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 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 desarrollaba y dirigía 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 multimedia 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 de mis propias empresas.

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 de 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 durante las semanas de mayor riesgo, nadie hacía entregas. 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 LLM que calcula la probabilidad de que una diferencia de código provoque la caída de 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 del riesgo. Asignaba una puntuación de riesgo continua a cada diferencia, ajustada para ofrecer una alta cobertura; por ejemplo, marcaba 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 decisión 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.

Ese es un buen ejemplo de mi filosofía general: no impongas a los ingenieros un mandato de IA verticalista; dales infraestructura — una plataforma centralizada, una señal de riesgo, un plano de control — y deja que ellos mismos descubran 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 más capacidad para aplicar ese criterio a gran escala.

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

En qué destacan los humanos:

• Gobernanza y límites de seguridad en torno a los propios agentes: Cuando los equipos integran modelos de razonamiento y agentes profundamente en la infraestructura, detectan rápidamente fallos de gobernanza: los agentes se multiplican más rápido de lo que nadie esperaba 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 establecerías para las personas que utilizan esa infraestructura, lo que significa que las personas siguen fijando 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 con mérito 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 adoptarla no se puede automatizar.

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

La informática comenzó con un ordenador central que todos compartían y después pasó a grupos 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 computación. 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 de conexión.

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 uniformes. Abandoné ese enfoque y lo sustituí por un modelo mental basado en una plantilla. Esto replantea las cuestiones de diseño organizativo —quién aprueba qué, quién es responsable del 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 esforzarse de repente para satisfacer la demanda: literalmente intentaba encontrar decenas de miles de servidores libres.

En retrospectiva, esto se podría haber evitado. Si asumes que la adopción podría volverse viral internamente, incorporas los controles de costes y las fronteras de acceso a la plataforma desde el primer día, en lugar de aplicarlos como 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 donde debe residir la gobernanza.

James comparte

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 donde 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 para 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 comprobar qué agentes ya existen para esa tarea y bifurcar uno en lugar de empezar desde cero. Las organizaciones deben crear procesos que permitan apropiarse fácilmente de los agentes.

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

Este es mi consejo:

1. No lo impongas — gánatelo. La imposición del uso de la IA para mejorar la productividad me frustra porque produce una adopción superficial; las mejores herramientas de desarrollo consiguen que se utilicen, y los desarrolladores son lo bastante inteligentes como para resistirse a que les digan qué herramientas deben adorar. Los CTO deberían plantear a la organización desafíos empresariales de un orden de magnitud superior: 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 evangelistas orgánicos. 
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 a una plantilla, no como gobernarías un software. Los agentes impulsados por modelos de razonamiento no son deterministas: proporciona dos veces la misma entrada al mismo agente y puedes obtener resultados diferentes. Esto no es un error que haya que corregir; es la naturaleza fundamental de la tecnología. Los CTO ya gestionan a diario sistemas no deterministas con empleados. Debes aplicar a los agentes algunas de las mismas medidas de protección que aplicas a tu plantilla. No concedas a un agente acceso sin restricciones a producción, credenciales de superusuario ni un presupuesto ilimitado para la nube desde el primer día, del mismo modo que no concederías nada de eso 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 a expertos en The CTO Club!