SAP TechEd es el evento de la compañía dedicado a los desarrolladores, que este año se celebró en Berlín, donde reunión a la comunidad de developers del Grupo a nivel mundial y presentó sus últimos lanzamientos. En este contexto, tuvimos la oportunidad de hablar con Casey West, Lead Developer Advocate de Google Cloud, quien nos acercó a este mundo en constante desarrollo, nunca mejor dicho, empezando por explicarnos su cargo.
¿Qué es un «developer advocate»?
Este concepto puede variar mucho según la organización, en algunas utilizan, en su lugar, el término «developer evangelist», que a mí, personalmente, no me gusta mucho. En Google Cloud empleamos el término «advocate» en su acepción de «defensor» o «partidario», por lo que nuestra misión principal es ayudar a los desarrolladores a tener éxito en su actividad en la empresa. Para lograr esto, debemos tener una sólida experiencia como desarrolladores y contar con productos que realmente resuelvan los problemas que nuestros usuarios desean solucionar.
Una de las responsabilidades de mi equipo es participar en la comunidad global de desarrolladores para obtener información y retroalimentarnos de conocimientos que podamos llevar de vuelta a nuestros equipos de ingeniería para que mejorar la experiencia del desarrollador y, también, el producto.
Muhammad Alam, responsable de Producto e Ingeniería de SAP, ha comentado en su sesión de bienvenida que el desarrollador debe ser perezoso, y que ahora lo será aún más. ¿Cómo interpreta estas palabras a la luz de la adopción de la IA?
El uso de la inteligencia artificial en el trabajo ha cambiado las reglas del juego, especialmente para los desarrolladores. Yo prefiero llamar al uso de esta tecnología «asistencia de codificación con IA», pues la empleo como un asistente, no para que haga el trabajo por mí. Creo que el comentario de Muhammad Alam se refiere al «Productivity Trap» (Trampa de la Productividad), que es el primer nivel de un modelo de madurez de IA que he establecido.
El uso de la inteligencia artificial en el trabajo ha cambiado las reglas del juego, especialmente para los desarrolladores
¿Podría detallar este modelo de madurez de la IA?
Por supuesto. Creo que existen tres niveles principales para el aprovechamiento de la IA: El nivel 1: Trampa de la Productividad (Productivity Trap), que se basa en la idea de que la IA puede, simplemente, acelerar los desarrollos y ayudarte a ser más rápido. Aquí es donde encajan esos desarrolladores que intentan aprovechar esta tecnología solo para obtener mayor rendimiento. Sin embargo, existe una diferencia entre rendimiento e impacto. Usar la IA solo para producir muchas cosas no es lo mismo que ser productivo.
Existe una diferencia entre rendimiento e impacto. Usar la IA solo para producir muchas cosas no es lo mismo que ser productivo
El nivel 2 se basa en cerrar la brecha de contexto (Closing the Context Gap). Para llegar a este nivel, un ingeniero debe ser mucho más reflexivo y profesional sobre cómo interactúa con la IA. La IA necesita contexto informativo. Empleando ingeniería de prompts muy cuidadosa y aportando mucha guía y contexto, la IA puede ayudarte a hacer un trabajo más inteligente, no solo más rápido.
Y, por último, el nivel 3, con enfoque en el impacto. La idea es usar la IA como un colaborador y compañero de equipo reflexivo, no solo como un interno al que puedes delegar tareas. Yo uso la IA en mi codificación diaria para que trabaje y colabore conmigo, desafiando mis ideas o sugiriendo mejores opciones. Los desarrolladores perezosos que no pongan esfuerzo ni supervisión obtendrán resultados deficientes.
¿Existe un temor generalizado entre los desarrolladores a perder sus empleos a causa de la IA? ¿Está este miedo justificado?
Considero que siempre habrá un lugar para los ingenieros profesionales que han trabajado duro, que son reflexivos y que se toman en serio la responsabilidad de construir sistemas de software. La razón es que la IA no produce grandes resultados sin intervención, supervisión y vigilancia humana. Necesitamos barandillas de seguridad (guard rails) sobre lo que produce la IA, y eso requiere experiencia en el dominio (domain expertise).
Sin embargo, en el caso de los desarrolladores que solo quieren hacer una sesión de codificación rápida y enviarla a producción (el vibe coding session), la IA puede hacer ese trabajo sin ellos, y es posible que esos desarrolladores no tengan muchas oportunidades en el futuro. Los desarrolladores que usen la IA como asistente, colaborador y acelerador, pero no para que haga su trabajo por ellos, tienen un futuro prometedor en el mundo del desarrollo.
Los desarrolladores que usen la IA como asistente, colaborador y acelerador, pero no para que haga su trabajo por ellos, tienen un futuro prometedor en el mundo del desarrollo
¿Las grandes compañías como Google están ofreciendo formación para que los ingenieros integren la IA en su trabajo?
Sí, en Google tenemos mucha formación interna. Desde la Dirección se ha trasladado a toda la empresa que la IA es un acelerador que queremos aprovechar, y queremos hacerlo de manera responsable. Se espera que todos los ingenieros de Google descubran cómo aprovechar la IA para hacer su trabajo de manera más eficiente, efectiva y rápida. Pero para hacer esto a escala y de manera responsable, se necesita contar con buenas actividades de capacitación. Esto no es solo para mejorar el trabajo, sino para establecer una gobernanza y una dirección clara sobre cómo debe usarse la IA. Por ejemplo, si se está interactuando con información interna sensible o de clientes, no se debe usar ChatGPT o una IA pública para construir un informe o hacer un análisis.
¿Están los principales desafíos futuros del desarrollador relacionados con la IA, o existen otros retos importantes en el panorama del software?
No diría que todos los desafíos están relacionados con la IA, porque el mundo del software es muy extenso y poliédrico. No todo es IA, ni todo debería ser IA. De hecho, uno de los desafíos más difíciles es determinar cuándo una solución debe ser agéntica (basada en agentes de IA) y cuándo no. Debido a la gran expectativa, muchos ven todos los problemas como resolubles por esta tecnología, pero hay muchos problemas para los que no se necesita la IA.
¿Cómo podemos diferenciar cuándo es necesario aplicar la IA a un problema y cuándo no?
Si el proceso de resolución de problemas requiere creatividad, es una buena oportunidad para utilizar la IA, al menos con el conjunto actual de modelos. Si no requiere creatividad, no se debe usar la IA. El ejemplo clásico es: no uses Gemini para hacer una calculadora. Las matemáticas son deterministas, y se debe usar un programa regular para ellas. Sin embargo, si quisieras interpretar un problema de palabras (como «Sally tiene cinco manzanas…»), la IA puede interpretarlo y extraer las piezas, pero luego la computadora debería hacer la matemática real. La dificultad radica en que las personas con una visión más ingenua asumen que la IA puede o debe hacer cualquier cosa.
Las personas con una visión más ingenua asumen que la IA puede o debe hacer cualquier cosa
Finalmente, hablemos de la explicabilidad de la IA. Es un desafío saber de dónde provienen los procesos y las respuestas, dado que la IA es vista como una «caja negra». ¿Cómo pueden las empresas y los desarrolladores gestionar esta cuestión?
Absolutamente, a día de hoy la IA es una caja negra. La realidad es que el razonamiento del modelo es esencialmente matemática difícil de traducir al lenguaje natural. Sin embargo, los desarrolladores de software que construyen soluciones con IA pueden aplicar buenos patrones de diseño arquitectónico. El error más común es hacer una única llamada al modelo (agentes monolíticos one-shot) con todas las instrucciones, lo que resulta en el problema de la caja negra. La solución es descomponer ese problema en una serie de tareas o pasos.
Lo idóneo es diseñar este modelo bajo el concepto de expertos que hacen un trabajo específico pero que trabajan juntos como un equipo. Si construimos una arquitectura multi-agente, cada experto recibe una tarea, genera una salida y podemos inspeccionar los resultados del trabajo en cada uno de estos pasos. Esto permite tener más visibilidad en las interacciones y es la mejor manera de manejar la falta de explicabilidad en estos momentos.
