DEV Community

Cover image for Agente Smith de Google Escribe el 25% del Código: Lo que los Equipos API Deben Saber
Roobia
Roobia

Posted on • Originally published at apidog.com

Agente Smith de Google Escribe el 25% del Código: Lo que los Equipos API Deben Saber

En resumen

El agente interno de codificación de IA de Google, Agent Smith, ahora genera más del 25% del nuevo código de producción de la compañía. A diferencia de herramientas de autocompletado como Copilot, Agent Smith trabaja asincrónicamente en segundo plano, escribiendo, probando e iterando código sin interacción humana. Para los equipos de API, esto plantea preguntas sobre la estabilidad de los contratos, la cobertura de pruebas, la desactualización de la documentación y los flujos de trabajo de revisión cuando una cuarta parte de su base de código es generada por máquina.

Prueba Apidog hoy

Introducción

Durante una llamada de ganancias en marzo de 2026, el CEO de Google, Sundar Pichai, reveló una cifra que hizo que toda la industria del software se detuviera: el código generado por IA ahora representa más del 25% del nuevo código producido en Google.

Esto no es autocompletado. No son sugerencias de Copilot aceptadas por desarrolladores. Es código que se envía a producción después de ser generado por IA. La herramienta detrás de esto, internamente llamada Agent Smith (un guiño al antagonista autorreplicante de The Matrix), se volvió tan popular entre los más de 180,000 empleados de Google que la compañía tuvo que restringir el acceso para gestionar la tensión de la infraestructura.

Agent Smith representa una categoría diferente de las herramientas de codificación de IA que la mayoría de los desarrolladores utilizan hoy en día. Mientras que Copilot y Claude Code asisten en tiempo real, Agent Smith trabaja en segundo plano. Los ingenieros asignan tareas, se ausentan y regresan más tarde para revisar el trabajo completado.

Para los equipos de desarrollo de API, este cambio de código "asistido por IA" a "generado por IA" plantea preguntas prácticas. Cuando el 25% de su base de código es escrita por un agente autónomo, ¿cómo mantiene estables los contratos de API? ¿Cómo se asegura de que las pruebas cubran los puntos finales generados por máquina? ¿Cómo evita que la documentación se desactualice?

💡 La plataforma integrada del ciclo de vida de las API de Apidog mantiene el diseño, las pruebas, los simulacros y la documentación sincronizados, independientemente de si un humano o un agente de IA realiza el cambio. Prueba Apidog gratis para construir flujos de trabajo de API a prueba de agentes.

Este artículo desglosa qué hace Agent Smith, cómo difiere de otras herramientas de codificación de IA y para qué deben prepararse los equipos de API.

Qué hace Agent Smith

Codificación autónoma asincrónica

Agent Smith no se sienta en tu IDE esperando instrucciones. Opera asincrónicamente en segundo plano. El flujo de trabajo es el siguiente:

  1. Un ingeniero describe una tarea en lenguaje natural.
  2. Agent Smith descompone la tarea en subtareas.
  3. Escribe código en varios archivos.
  4. Ejecuta pruebas e itera sobre los fallos.
  5. El ingeniero revisa el trabajo completado.

A diferencia de Copilot o Claude Code, Agent Smith actúa como un desarrollador junior que toma un ticket, desaparece y regresa con una pull request preparada.

Los ingenieros delegan tareas y verifican el progreso desde la plataforma de chat interna de Google, incluso desde dispositivos móviles. La herramienta accede automáticamente a perfiles y documentación relevante, extrayendo contexto de la base de conocimientos interna.

Construido sobre Gemini y Antigravity

Agent Smith utiliza la familia de modelos Gemini de Google, complementados con sistemas de recuperación para acceder a la base de código y documentación interna. Se basa en Antigravity, la plataforma de codificación de agentes de Google, y la expande con descomposición y ejecución autónoma de tareas.

La recuperación aumentada permite a Agent Smith buscar patrones similares, referencias y convenciones internas, elevando la calidad de la salida generada.

Qué significa "25% de código nuevo"

El 25% se refiere a código:

  • Generado por IA, no autocompletado.
  • Que pasa revisión de código humana.
  • Que se despliega en producción.
  • Medido en toda la producción de ingeniería de Google.

No es el 25% de la base total, sino del código nuevo generado. El porcentaje aumenta constantemente, y Google lo considera una ventaja estratégica.

Cómo Agent Smith difiere de otras herramientas de codificación de IA

El espectro de herramientas de codificación de IA

Herramienta Modo Interacción Alcance ¿Código de producción?
GitHub Copilot Autocompletado en tiempo real En línea en el IDE Nivel de línea/función Tras aceptación humana
Claude Code Sesión interactiva Conversacional Cambios de varios archivos Tras revisión humana
Cursor Agent Fondo + interactivo Integrado en el IDE Nivel de proyecto Tras revisión humana
Agent Smith Autónomo asincrónico Delegación de tareas Implementación de características Tras revisión humana
KAIROS (no lanzado) Daemon siempre activo Monitoreo en segundo plano A nivel de repositorio Por determinar

Agent Smith está en el extremo autónomo del espectro. El siguiente paso sería despliegue sin revisión humana, algo que aún no ocurre.

Por qué la asincronía es importante para los equipos de API

Las herramientas en tiempo real permiten control y contexto inmediato. Los agentes asincrónicos separan la creación del código de su revisión, lo que introduce riesgos:

  • El revisor puede no entender por qué se eligió un formato.
  • Cambios en el contrato pueden no ser obvios en la revisión estándar.
  • Artefactos relacionados (pruebas, docs, mocks) pueden quedar desactualizados.
  • Cambios drásticos pueden pasar desapercibidos si no se revisa el impacto global.

Qué se rompe cuando la IA escribe el código de tu API

Desactualización del contrato de API

Un contrato de API define endpoints, esquemas y formatos. Los desarrolladores humanos suelen actualizar la especificación OpenAPI y notificar a los consumidores. Un agente autónomo puede modificar la API sin actualizar la especificación ni coordinar con consumidores.

Ejemplo:

  • Agent Smith recibe "Agregar preferencias de usuario al perfil".
  • Añade un campo preferences al endpoint GET /api/users/{id}.
  • Las pruebas pasan porque no afirman la ausencia de nuevos campos.
  • Los tipos del frontend no incluyen preferences.
  • El análisis JSON estrictamente tipado en móvil falla.

El código es correcto, las pruebas pasan, pero el contrato está roto.

Brechas en la cobertura de pruebas

El código generado por IA suele tener pruebas que validan solo lo que se implementó, no la integridad global. Esto deja puntos ciegos:

  • Tiempos de respuesta no probados.
  • Formatos de error inconsistente.
  • Limitación de velocidad no validada.
  • Casos extremos de autenticación omitidos.
  • Paginación inconsistente con otros endpoints.

Desactualización de la documentación

Si la documentación se genera desde el código, los cambios se propagan. Pero muchos equipos la mantienen manualmente. Si el agente añade o modifica endpoints, la documentación puede quedar desfasada. Incluso con generación automática, faltarán contexto, ejemplos y motivaciones que solo el humano puede aportar.

Fatiga de revisión

Revisar código generado por IA puede volverse una rutina superficial, dado lo estructurado y "correcto" que parece. Sin embargo, puede no alinearse con decisiones arquitectónicas, convenciones o requisitos no escritos. La fatiga lleva a aprobaciones automáticas (rubber-stamping), aumentando el riesgo de errores en producción.

Cómo construir flujos de trabajo de API a prueba de agentes

1. Hacer de los contratos de API la fuente de verdad

Adopta un enfoque design-first: la especificación OpenAPI es la referencia. Cualquier cambio debe respetar el contrato.

Sin design-first:

Cambio de código → Pruebas pasan → Despliegue → Contrato roto
Enter fullscreen mode Exit fullscreen mode

Con design-first:

La especificación define el contrato → El código debe coincidir → Validación detecta desactualización
Enter fullscreen mode Exit fullscreen mode

El diseñador visual de API de Apidog permite definir endpoints, esquemas y respuestas antes de codificar. Valida el código generado (sea humano o IA) contra la especificación, no solo contra pruebas.

2. Usar pruebas de contrato, no solo pruebas unitarias

Las pruebas unitarias validan lógica interna; las de contrato validan acuerdos entre servicios.

Ejemplo de prueba de contrato:

// Esta prueba falla si la forma de la respuesta cambia,
// incluso si la nueva forma es "válida"
describe("GET /api/users/:id contract", async () => {
  it("returns expected schema", async () => {
    const response = await request(app).get("/api/users/123");

    expect(response.body).toMatchSchema({
      type: "object",
      required: ["id", "name", "email", "created_at"],
      properties: {
        id: { type: "string" },
        name: { type: "string" },
        email: { type: "string", format: "email" },
        created_at: { type: "string", format: "date-time" }
      },
      additionalProperties: false  // Esto detecta campos inesperados
    });
  });
});
Enter fullscreen mode Exit fullscreen mode

La línea additionalProperties: false es crítica: obliga a actualizar la especificación si cambia el esquema.

Apidog automatiza las pruebas de contrato desde la especificación.

3. Restringir despliegues por validación de especificaciones

Integra la validación de la especificación en CI/CD. Antes de desplegar cambios, valida que el código cumpla el contrato:

# Paso del pipeline de CI/CD
- name: Validar contrato de API
  run: |
    apidog run --test-scenario-id CONTRACT_TESTS

    if [ $? -ne 0 ]; then
      echo "Violación de contrato de API detectada. Revisar cambios."
      exit 1
    fi
Enter fullscreen mode Exit fullscreen mode

Así, los cambios que rompen el contrato son detectados antes de llegar a producción.

4. Requerir actualizaciones de la especificación para cambios en la API

Crea una regla: cualquier PR que modifique la API debe actualizar la especificación OpenAPI. Si la PR es generada por IA, el agente debe actualizar la spec, o un humano debe hacerlo antes de fusionar.

En Apidog, los cambios en la especificación se propagan automáticamente a:

  • Documentación de la API
  • Mock server
  • Pruebas
  • Tipos de SDK de cliente

Esto asegura que ningún artefacto quede desactualizado.

5. Monitorear el comportamiento de la API en producción

Aunque tengas pruebas, el monitoreo detecta incidencias reales:

  • Violaciones de esquema: loguea respuestas que no coinciden con la spec.
  • Nuevos campos: alerta si aparecen campos no documentados.
  • Cambios en la tasa de error: monitorea endpoints generados por IA.
  • Cambios en la latencia: compara el rendimiento de código humano vs. IA.
  • Cambios en el patrón de tráfico: detecta patrones anómalos en nuevos endpoints.

6. Separar la revisión de la API de la revisión de código

La revisión de código pregunta "¿Funciona este código?". La revisión de API pregunta "¿Rompe a algún consumidor?".

Lista de verificación para cambios de API generados por IA:

  • ¿Este cambio rompe algún consumidor existente?
  • ¿Está actualizada la especificación OpenAPI?
  • ¿Se han versionado los cambios incompatibles?
  • ¿Las respuestas de error son consistentes?
  • ¿Están documentados los nuevos endpoints con ejemplos?
  • ¿Se ha notificado a los equipos dependientes?

La trayectoria: hacia dónde se dirige la codificación autónoma

Agent Smith hoy vs. mañana

Agent Smith al 25% es solo el inicio. Sergey Brin lo calificó como "gran foco" para Google. El porcentaje crecerá a medida que la herramienta mejore y se expanda su acceso.

Otras empresas están desarrollando soluciones similares:

  • KAIROS de Claude Code: daemon con webhooks de GitHub y tareas en segundo plano.
  • Modo Agente de Copilot: tareas de varios pasos con edición autónoma.
  • CodeWhisperer de Amazon: ampliándose hacia agentes.

La tendencia: de asistentes a colaboradores autónomos e infraestructura invisible. Pronto, la pregunta no será si la IA escribe tu código, sino cuánto.

Para qué deben prepararse los equipos de API ahora

  • El diseño "design-first" es esencial. La especificación es el único artefacto estable.
  • Invierte en pruebas de contrato. Las unitarias no bastan cuando el autor no conoce las convenciones.
  • Elige herramientas integradas. Plataformas desconectadas fomentan la desactualización. Apidog sincroniza todo.
  • Crea procesos de revisión para código generado por IA. Automatiza validaciones y checklist de API.

Prueba Apidog gratis para construir flujos de trabajo de API consistentes, sin importar si el próximo cambio viene de un desarrollador humano, Agent Smith o cualquier herramienta autónoma futura.

Preguntas frecuentes

¿Qué es Google Agent Smith?

Agent Smith es el agente interno de codificación de IA de Google, basado en Gemini y Antigravity. Trabaja asincrónicamente: los ingenieros asignan tareas y Agent Smith escribe, prueba e itera código sin interacción humana en tiempo real. A partir de marzo de 2026, genera más del 25% del código nuevo de producción en Google.

¿Está Agent Smith disponible fuera de Google?

No. Es una herramienta interna exclusiva de Google. No hay planes anunciados de lanzamiento público. Tecnologías similares incluyen el modo Agente de Copilot y Claude Code, pero Agent Smith está más profundamente integrado en la infraestructura de Google.

¿El código generado por IA rompe los contratos de API?

Puede hacerlo. Los agentes de IA escriben código que pasa pruebas, pero estas pueden no cubrir todos los aspectos del contrato. Cambios de esquema, campos nuevos o formatos de error distintos pueden romper consumidores descendentes. Las pruebas de contrato y el desarrollo "design-first" previenen estos problemas.

¿Deberían preocuparse los equipos de API por Agent Smith?

No por Agent Smith en sí, sino por la tendencia que representa. Herramientas similares llegarán a tu equipo. Prepara tu flujo de trabajo con especificación "design-first", pruebas de contrato y herramientas integradas.

¿Cómo evito que los agentes de IA rompan mis API?

Utiliza desarrollo "design-first" con OpenAPI como fuente de verdad. Añade pruebas de contrato usando additionalProperties: false para detectar cambios inesperados. Restringe despliegues a validaciones de especificación y usa una plataforma integrada como Apidog para mantener todo sincronizado.

¿Cuál es la diferencia entre código asistido por IA y código generado por IA?

El código asistido por IA (Copilot, Claude Code) se produce con supervisión humana en tiempo real. El desarrollado por IA (Agent Smith) se genera asincrónicamente y es revisado después. Esto aumenta el riesgo de violaciones de contrato no detectadas.

¿Los agentes de IA reemplazarán a los desarrolladores de API?

No. Agent Smith aún requiere definición de tareas, revisión y aprobación humanas. El rol cambia de escribir código a definir tareas, revisar resultados y mantener la coherencia arquitectónica.

Conclusiones clave

  • Agent Smith de Google genera el 25% del nuevo código de producción mediante operación autónoma y asincrónica.
  • Representa el cambio de código asistido por IA a código generado por IA, impactando la dinámica de revisión en APIs.
  • El mayor riesgo es la desactualización del contrato de API.
  • El desarrollo "design-first" con OpenAPI como fuente de verdad previene rupturas.
  • Las pruebas de contrato con validación estricta detectan cambios que las unitarias no ven.
  • Plataformas integradas como Apidog sincronizan especificaciones, pruebas y documentación.
  • La tendencia hacia agentes de codificación autónomos se acelera; prepara tus flujos de trabajo de API ahora.

Agent Smith al 25% es solo el principio. Las empresas que construyan flujos de trabajo de API a prueba de agentes hoy serán las que adopten herramientas de codificación autónoma de forma segura mañana.

Top comments (0)