Andi Gutmans, uno de los colaboradores en la creación de PHP 3 y responsable de Agentic Data Cloud en Google, no presenta el desarrollo de software basado en agentes como una ruptura completa con el pasado. En una conversación con Eira May y Peter O'Connor en el programa Leaders of Code de Stack Overflow, comparó la transformación actual con el impacto que tuvo PHP al hacer posible la creación de sitios web para un mayor número de personas, incluidos quienes no se especializaban en ciencias de la computación.
Pero la nueva accesibilidad no significa que la experiencia de ingeniería vaya a desaparecer. Según el planteamiento de Gutmans, el desarrollador individual se está convirtiendo gradualmente en algo parecido a un «líder de un equipo de agentes»: define lo que se necesita, distribuye el trabajo, revisa los resultados y toma las decisiones que no pueden delegarse sin restricciones.
El valor pasa de escribir código al criterio de ingeniería
Gutmans considera que algunas preguntas fundamentales no han cambiado con la aparición de los agentes. El equipo todavía debe asegurarse de que la solución aborda el problema correcto, de que la arquitectura puede escalar y de que el sistema es seguro, está bien gobernado, es fácil de usar y resulta adecuado en términos de costes. Lo nuevo es que el agente puede ejecutar una mayor cantidad de trabajo de forma autónoma, por lo que es necesario diseñar cómo supervisarlo, en lugar de limitarse a revisar el código generado.
Gutmans puso un ejemplo cuando utilizó un agente para crear cerca de mil pruebas y después recurrió a otro agente para criticarlas. La revisión reveló que el resultado no era lo bastante bueno y tuvo que mejorarlo personalmente. En este caso, la necesidad del criterio humano no desapareció; cambió de lugar: pasó de la ejecución detallada al diseño, la coordinación y la evaluación.
Este cambio también se extiende a la comprensión de una base de código desconocida. Los agentes pueden recorrer una parte más amplia del proyecto y quizá encuentren categorías de errores que a un revisor humano le resulte difícil detectar al examinar una parte limitada del sistema. Aun así, Gutmans afirmó que Google utiliza conjuntamente la revisión humana y la revisión de agentes, especialmente cuando las decisiones o los cambios son sensibles.
La revisión no es una cuestión de confianza absoluta, sino de gestión de riesgos
La conversación propone considerar la supervisión mediante tres modalidades: el humano dentro del circuito, el agente dentro del circuito y el agente por encima del circuito. Esto no significa elegir una única opción válida para todos los casos, sino determinar el nivel de revisión adecuado según la probabilidad de error y su impacto.
En los cambios relacionados con componentes de seguridad sensibles, como los tokens de seguridad, la participación de un experto humano es más importante. En cambio, para modificaciones de CSS y HTML o algunos scripts de Python, con la ayuda del agente en una revisión de seguridad, puede resultar práctico recurrir a un nivel diferente de automatización. La idea fundamental no es que los agentes no cometan errores ni que los humanos revisen todo con la misma eficiencia, sino que la decisión sobre la revisión debe reflejar la magnitud del riesgo y sus consecuencias.
Gutmans utilizó la experiencia de Waymo como ejemplo ilustrativo de la brecha entre la percepción y los datos. Dijo que la probabilidad de que una persona sufra un accidente con lesiones es un 80% menor con Waymo que al viajar con un conductor de Uber, aunque muchas personas sigan sintiéndose más cómodas cuando hay un humano al volante. Del mismo modo, un equipo puede rechazar la autonomía del agente por una impresión subjetiva, incluso cuando los indicadores señalan que utilizarlo en una tarea concreta podría reducir los riesgos frente a la alternativa humana.
La contratación y el aprendizaje se orientan a evaluar la capacidad de dirigir
Gutmans cree que la enseñanza de las ciencias de la computación no se detendrá, pero que los estudiantes podrán realizar proyectos más complejos y de mayor alcance con ayuda de los agentes. Por ello, seguirá siendo necesario saber cómo construir, operar y ampliar sistemas, mientras que también será importante tener la capacidad de formular el problema, evaluar las soluciones y dirigir las herramientas inteligentes.
Afirmó que Google está cambiando una parte del proceso de entrevistas de ingeniería. En lugar de centrarse en pedir al candidato que escriba manualmente un algoritmo como quick sort, le permitirá utilizar Gemini y el agente para resolver un problema y después evaluará su forma de pensar, la secuencia con la que aborda la cuestión y cómo dirige al agente. Esto no elimina las habilidades técnicas, pero cambia lo que la entrevista intenta medir: de la rapidez para producir una solución abstracta a la calidad del razonamiento, el diseño y la coordinación.
El mayor obstáculo podría estar en los datos, no en los modelos
Según Gutmans, modelos como Gemini y Opus ya son capaces de automatizar una gran proporción de las tareas empresariales, por lo que el problema de los modelos por sí solo ya no es el principal cuello de botella. El desafío más importante es lograr que los datos de la empresa sean comprensibles y utilizables por los agentes, preservando al mismo tiempo las relaciones semánticas, los permisos y la gobernanza.
Esto incluye datos estructurados y operativos, además de imágenes, archivos PDF, contratos y otros datos no estructurados que se encuentran en el almacenamiento en la nube o en otros lugares. Google considera que los agentes pueden ayudar a descubrir dónde están los datos, comprender sus conexiones y construir las representaciones semánticas que antes requerían un gran número de administradores de datos. Gutmans describe esta tendencia dentro del concepto de «borderless lakehouse», cuyo objetivo es activar los datos independientemente de que se encuentren en GCP, AWS, Azure o entornos locales.
También señaló la importancia de formatos de datos abiertos como Iceberg y que las integraciones entre nubes podrían ayudar a acceder a los datos sin depender por completo de las tarifas de transferencia por cada gigabyte. Asimismo, habló del «knowledge catalog» y de trasladar la construcción de la ontología de un proceso dirigido completamente por humanos a otro dirigido por agentes, manteniendo al ser humano en el papel de coordinación y edición, en lugar de ejecutar el trabajo manual pesado.
¿Qué cambia en la práctica? Para los equipos técnicos, no basta con proporcionar un agente de software y dejarlo trabajar. El uso eficaz requiere identificar las tareas que merecen automatizarse, establecer niveles de revisión proporcionales a sus riesgos y garantizar la calidad de los datos y los permisos a los que accede el agente. En cuanto al desarrollador, su papel no desaparece; se vuelve más parecido al de un ingeniero que dirige un conjunto de herramientas capaces de ejecutar tareas y asume la responsabilidad del juicio final sobre lo que producen.