Cómo lograr que tu organización adopte agentes de programación (sin enviar código basura) — Eyal Blum, Figma
AAI Engineer
컴퓨터/소프트웨어경영/리더십
스크립트
00:00:00Eyal Blam: Buenas tardes, mi nombre es Eyal Blam, soy ingeniero de software en Figma y
00:00:17en mi charla de hoy vamos a hablar de cómo hemos adaptado o estamos adaptando los agentes a
00:00:25nuestro flujo de trabajo en Figma, manteniendo al mismo tiempo una gran calidad en nuestra base de código.
00:00:32Como ya sabrán, Figma es el editor basado en navegador donde el diseño, la ingeniería y ahora
00:00:40los agentes de IA colaboran juntos para entregar código.
00:00:44Figma ha dado un giro muy fuerte, pasando de ser una herramienta tradicional a una centrada en la IA,
00:00:52pero en esta charla no voy a hablar de nuestro producto, sino más bien de nuestra
00:00:55organización interna y de cómo nuestra organización de ingeniería ha ido adaptando los agentes de IA.
00:01:04Y lo que hemos descubierto internamente es que, tanto en las organizaciones como en las empresas y los individuos, hay
00:01:11un proceso de adopción de la IA en tres actos.
00:01:16Empiezas por probar algo, ya sea que muchas de las personas en esta sala
00:01:21estén muy metidas en la IA y la lleven usando un tiempo, probaron algo y lograron
00:01:27que algunas cosas sencillas funcionaran muy bien, siendo 10 veces más rápidos.
00:01:30Luego empiezas a aplicar esas mismas prácticas a problemas más grandes y la IA falla bastante en eso, te da malos resultados,
00:01:40muchos errores.
00:01:41La confianza que habías construido se viene abajo y a partir de ese punto es cuando empiezas a desarrollar la verdadera habilidad, que es
00:01:50aprender a usar la IA correctamente, poniendo los límites adecuados, las indicaciones correctas,
00:01:55el contexto idóneo y todo de lo que hemos estado hablando aquí todo el día en las charlas, para así adquirir una habilidad real.
00:02:02Y algo que ocurre internamente a medida que adoptamos esto, ya sea por equipos o individuos, es que la adopción es desigual.
00:02:12Tenemos equipos muy avanzados en IA que ya han transformado sus flujos de trabajo por completo, y otros que siguen experimentando en la etapa inicial o han perdido la confianza; sin embargo, todos deben trabajar juntos para lanzar nuestro producto.
00:02:28Por lo tanto, tienen que coexistir en la organización y debemos encontrar la manera de apoyarlos mientras integramிறோம் a todos en el proceso y logramos que alcancen el tercer acto de la historia.
00:02:44Aparte de ese punto de fricción principal, también hemos notado otros roces que surgen a medida que adoptamos la IA.
00:02:54Algo que hemos escuchado mucho de los desarrolladores y que los gerentes han estado notando es que la menor autonomía del desarrollador hace que los ingenieros pierdan parte de su satisfacción laboral.
00:03:04Mucha gente solía sentir mucho orgullo y disfrute al escribir código y entrar en estado de concentración, y sienten que eso se ha perdido o que están perdiendo gran parte de ese elemento, entrando en un ciclo de peticiones donde solo esperan resultados de la IA y le hablan a la IA, lo cual ya no es tan divertido como antes.
00:03:22Hemos notado otra cosa interesante: en realidad, nuestros mejores ingenieros quieren mantener todo el contexto en su cabeza y terminan cargando con ese peso, y lo que acaba pasando es que saben dónde están todos los problemas, mantienen unidos con cinta adhesiva mental todos los aspectos en los que los agentes no funcionan bien y evitan que entren cosas realmente malas, o tienen todo el contexto institucional que
00:03:52nunca se ha puesto por escrito en sus cabezas, acumulan tanta carga que se convierten en cuellos de botella y se frustran mucho, por lo que terminan tardando más en adoptar la tecnología al ver todos los problemas de primera mano.
00:04:04Ese es otro gran problema que hemos visto, y con este seguro que todos aquí se sienten identificados: de repente, todos los documentos de diseño, los mensajes de Slack y los correos se han vuelto tres o cuatro veces más largos, y recibimos dos o tres veces más correos, que básicamente dicen lo mismo que antes.
00:04:28Así que la comunicación se ha vuelto bastante ineficiente y distinguir qué es de gran calidad e importante frente a lo que no lo es tanto se ha vuelto difícil de manejar.
00:04:40Así que voy a dedicar los próximos minutos a hablar de algunas de las lecciones que hemos aprendido y de cómo hemos intentado aplicarlas.
00:04:50Este es un viaje del que aún no hemos salido por completo, pero hemos visto avances muy interesantes en muchos de estos aspectos.
00:04:57Creo que muchos de los ponentes aquí han mencionado esto, pero invertir en verificación es probablemente lo más valioso que podemos hacer en nuestra base de código.
00:05:11Cualquier cosa que podamos adelantar en nuestro flujo de trabajo para que pase de requerir a un humano a ser verificada por un agente.
00:05:19Por ejemplo, cuando salió el MCP de Playwright, en vez de tener a humanos explorando el código, ahora el agente puede explorarlo; eso supuso un gran avance para la productividad de muchos de nuestros equipos.
00:05:33Eso siempre es una gran victoria para nosotros.
00:05:37Lo otro, que es aún mejor, es que cuando encuentres algo que el agente haya considerado útil, te tomes el tiempo de codificarlo en un flujo determinista.
00:05:51Un flujo determinista que se pueda repetir fácilmente ahorra tokens y tiempo, y además te asegura que estás usando el LLM cuando realmente necesita razonar.
00:06:01Pero cuando tienes algo que ya se conoce y básicamente se puede convertir en una prueba, dedicarle ese tiempo siempre, siempre da frutos.
00:06:11Y otro consejo: si le pides a tus habilidades o a tu agente que escriba el código siguiendo el estilo de desarrollo guiado por pruebas (TDD), de rojo a verde, casi siempre obtendrás mejores resultados.
00:06:26Porque defines un objetivo y luego le pides al agente que se esfuerce por alcanzarlo.
00:06:30Casi siempre te dará mejores resultados escribiendo primero el código y luego las pruebas, ya que así adaptará la prueba al código en lugar de ajustar el código para pasar los criterios de verificación.
00:06:42Y esta es la pirámide de pruebas, la pirámide clásica de antes, pensando en las pruebas en sí, donde tenías las pruebas de extremo a extremo, las pruebas de integración y las pruebas unitarias.
00:06:54Aquí el cambio es similar: traslada todo lo que puedas hacia el análisis determinista, como el linter, el compilador y las propias pruebas unitarias; todo lo que se pueda cubrir fácilmente puede ser revisado por un agente basándose en criterios
00:07:12y estándares de arquitectura que hayan sido...
00:07:15Y estándares de arquitectura que se hayan integrado fácilmente en la base de código para que los gestione el agente.
00:07:19Y solo en la parte más alta necesitas algún tipo de revisión humana, que suele centrarse en la funcionalidad y en si esto es lo correcto a construir; deja al humano hacer únicamente aquello en lo que realmente debe intervenir.
00:07:31Y otra cosa realmente importante es la planificación frente a las indicaciones; esto está muy ligado a devolverles la autonomía a los desarrolladores y a encontrar un reemplazo para el oficio de escribir código.
00:07:50Por lo tanto, dedicar mucho tiempo a redactar el plan y luego enviárselo al agente como una implementación que se puede realizar de forma automática es algo que consideramos que reintroduce la alegría de construir en el proceso.
00:08:07Así que no es raro pasar una semana escribiendo planes muy detallados, tomando decisiones, perfilándolos, iterando y enviándolos a los compañeros de equipo para su revisión.
00:08:17Y solo cuando está listo y has pulido todas las decisiones, puedes enviárselo al agente, y este te lo devolverá cuando esté implementado.
00:08:26Eso ha tenido mucho éxito tanto para acelerar el proceso como para devolverle la alegría al desarrollo.
00:08:36Entonces, ¿qué hace que un plan sea bueno? Es muy importante empezar por el porqué arriba.
00:08:43Ayuda mucho a prevenir la desviación del agente si tienes una sección grande y destacada, similar a cuando escribes un documento de diseño.
00:08:49Quieres incluir el resumen ejecutivo para el agente, de lo contrario empezarán a desviarse con el tiempo y hay que asegurarse de que el agente no vuelva atrás a cambiarlo porque le apetezca.
00:08:58Así que empezamos por el porqué, asegurándonos de que el plan se pueda dividir en partes pequeñas que puedan verificarse de forma independiente.
00:09:08Y mi manera personal de saber cuál es un buen tamaño es preguntarme si querría revisar la PR correspondiente a esa parte, o si sería demasiado grande para revisarla de una sola sentada.
00:09:18Es como la prueba de: voy a necesitar tomarme una taza de café antes de leer esto.
00:09:22Eso significa que es demasiado grande y querré dividirlo en trozos.
00:09:26Luego me aseguro de que cada parte se pueda validar por separado, porque lo último que quiero es tener cinco etapas donde la primera se escribe pero no se valida, y todo lo demás se construye sobre suposiciones.
00:09:41Así que tener una puerta de validación o criterios de excepción para cada fase ayuda verdaderamente a que el plan sea resistente a las desviaciones.
00:09:51Y existen todo tipo de aspectos técnicos sobre cómo gestionar el contexto y montar una fábrica de software basada en ello.
00:09:58Pero una vez que tienes el plan, puedes usar el bucle o el flujo de trabajo que prefieras para implementarlo.
00:10:05Esta es una captura de pantalla de un plan que elegí al azar, pero es lo que suelo buscar.
00:10:12El resumen ejecutivo arriba.
00:10:14Las fases divididas y luego cada una con muchos detalles para poder ajustarla a un subagente.
00:10:20Y el subagente puede trabajar en eso de forma independiente sin tener que preocuparse por más.
00:10:24Y hay otros flujos de trabajo que funcionarían u otras estructuras para el plan.
00:10:29Considero que una de las maravillas de los flujos de trabajo con IA es que cada uno puede configurar lo que mejor le funcione.
00:10:41No, gracias.
00:10:43Cualquiera puede configurar muy fácilmente el flujo que se adapte exactamente a sus necesidades.
00:10:47Por eso, los rendimientos decrecientes surgen al intentar centralizar a todos en una sola opción.
00:10:51Pero mientras funcione para su flujo y otros puedan iterar con ellos, descubro que por lo general funciona muy bien.
00:10:58Y este es solo un ejemplo, por presumir, de lo que podría ser el resultado de un plan.
00:11:04Y probablemente haya unas 20 PRs aquí.
00:11:07Algunas tal vez tengan 10 líneas y otras 100, pero probablemente ninguna sea mayor que eso.
00:11:12Y eso nos permite... en el mundo pre-IA, en este plan probablemente habría trabajado durante una semana.
00:11:19Me habría alineado con otros tres equipos durante otra semana y luego simplemente se lo envío a un agente para que lo implemente de la noche a la mañana.
00:11:26Y regresó —esto probablemente sea de dos planes, no de uno— pero son básicamente seis semanas de trabajo de programación hechas en tan solo una semana.
00:11:36De ahí es de donde obtengo la aceleración de 5x.
00:11:40Si incluyo el ciclo de revisión al final, que siempre hay que tener presente.
00:11:45Y volviendo de la planificación al problema que teníamos con los escépticos y la gente agobiada con más trabajo:
00:11:53asegúrate de integrarlos y tomarte sus comentarios muy en serio.
00:11:59Ellos son escépticos porque ven dónde te falta validación y dónde fallan tus herramientas.
00:12:05Así que sus comentarios son básicamente la hoja de ruta sobre cómo mejorar tu agente y la interacción con la base de código.
00:12:12Tan solo asegúrate de incorporarlos en lugar de intentar averiguar cómo hacer que usen la IA.
00:12:19Haz que estén a cargo de la hoja de ruta para que la IA sea segura en tu organización.
00:12:25Y se sumarán en cuanto vean que las mejoras que están haciendo les facilitan realmente la vida.
00:12:33Y como puedes ver, no tendrán ningún reparo en decirte qué necesitas arreglar.
00:12:37Esto es menos de una hora reunido con un grupo de personas.
00:12:40Y este es el resultado de las lluvias de ideas.
00:12:45Otra cosa que ha sido de gran ayuda específicamente con mi equipo, y que estamos trabajando para adoptar también en el resto de la organización,
00:12:53es asegurarnos de practicar una comunicación consciente de la atención.
00:12:58En la era de la IA, la atención humana es un recurso escaso.
00:13:01Creo haberlo escuchado en múltiples charlas, y mucha gente ha llegado a la misma conclusión.
00:13:06No puedes conseguir más atención humana.
00:13:08Así que dónde gastas tu tiempo y lo que lees se vuelve muy importante.
00:13:13Y como es un recurso tan escaso, marcar qué fue generado por IA frente a lo que fue escrito por un humano es muy útil para saber cuánto tiempo necesitas dedicar a leer esto,
00:13:24y cuánta profundidad puedes esperar en esta parte de la comunicación.
00:13:31Y eso es construir una nueva cultura en torno a ese estilo de comunicación.
00:13:35De verdad ayuda.
00:13:36Y por ejemplo, el equipo con el que trabajo, hemos decidido que siempre, cada descripción de PR va a empezar con algo así.
00:13:45Algo que escribí a mano podría ser muy breve para describir lo que esto hace, y luego la descripción de la IA vendrá después de eso.
00:13:54Es solo que probablemente lo leeré.
00:13:55Probablemente lo editaré para quitar algunas cosas incorrectas, pero ellos no escribieron cada línea aquí.
00:14:00Así que deberían sospechar más, prestar más atención a lo que escribí arriba y deben anularlo.
00:14:05Cosas así en Slack, en el correo, simplemente apoyándose en el hecho de que todos saben que estás usando IA para redactar tu comunicación,
00:14:15pero sin dudar en decirles qué deben leer y a qué deben prestarle menos atención.
00:14:21Y recuerdo al principio, tal vez a principios de este año, intenté... tenía algunos ingenieros sénior en nuestra organización que eran muy escépticos de la IA,
00:14:35e intenté comunicarme con ellos para ver cuál era el problema, qué pasaba, y decirles que intenté hacer un análisis de algunos de los comentarios de PR que han hecho,
00:14:42y obviamente usé IA para hacer eso.
00:14:45Y luego no distinguí muy claramente lo que escribí frente a lo que ellos... lo que generó la IA, y se enojaron mucho.
00:14:54Dijeron: ¿por qué envías...? No esperaba que alguien a quien respeto tanto me enviara algo que es claramente tan descuidado.
00:15:02Y entonces yo... me disculpé.
00:15:05Me di cuenta de que debí haberlo marcado claramente y señalar mi intención.
00:15:08Como: esto es lo que escribí.
00:15:10Esto es lo que escribió la IA, y necesito tus comentarios al respecto porque no tengo el contexto para saber si es descuidado o no.
00:15:15Y eso es lo que te estoy pidiendo.
00:15:17Entonces, lecciones como esa y cambiar la cultura es tan importante como algunos de los desafíos de ingeniería que hemos estado enfrentando.
00:15:28Otra cosa que es muy útil en cuanto a la adopción es que, a medida que avanzas en la adopción, hay muchas herramientas muy sofisticadas y muchos flujos de trabajo avanzados que hemos estado implementando.
00:15:41Pero una de las cosas realmente efectivas es simplemente dejar que la gente use la IA donde ya está.
00:15:47Así que realmente ayuda a normalizar el uso de la IA para las tareas cotidianas y ayuda a reducir la fricción.
00:15:54Y de verdad, una de las cosas más poderosas es poder etiquetar a un agente en un mensaje de Slack con alguien y decir: ¿puedes hacer esto por mí?
00:16:02¿Y hacer que los agentes cierren el ciclo en el hilo?
00:16:07Y ese tipo de cosas son realmente poderosas.
00:16:09Y luego puedes construir sobre eso y hacer que todo esto sea automatizado y tener todo tipo de cosas sofisticadas.
00:16:14Pero si estás conversando con alguien que no está completamente convencido, puedes etiquetarlo de una forma no pasivo-agresiva y decir: probemos y veamos si el agente puede hacerlo esta vez.
00:16:26Y ellos cierran el ciclo, y si es una buena experiencia, eso realmente ayuda a que la gente lo pruebe por sí misma en otros casos.
00:16:33Y nuestro viaje continúa.
00:16:37Todavía estamos aprendiendo, aunque estamos lanzando IA al exterior, nuestra adopción de IA, y estamos experimentando con tantas cosas todo el tiempo, donde nuestra historia de automatización aún no está completa.
00:16:50Todavía estamos intentando averiguar cuándo deberíamos usar, cómo podemos usar Cloud Agent de manera efectiva, dadas todas las dependencias que tenemos para algunos de nuestros sistemas de compilación.
00:16:58Y por eso seguimos aprendiendo.
00:17:01Es un cambio cultural.
00:17:02Es un cambio de ingeniería.
00:17:03Y no sé ustedes, pero yo he estado trabajando en el Valle durante los últimos 15 años, y este es el cambio más grande por órdenes de magnitud de todo lo que he visto en términos de cultura y tecnología.
00:17:16Así que estamos todos aquí juntos, y todos lo estamos descubriendo.
00:17:19Y de eso quería hablarles hoy.
00:17:22Gracias.
00:17:28Gracias.
커뮤니티 글
아직 글이 없습니다. 이 영상에 대한 첫 번째 글을 작성해 보세요!
이 영상에 대해 글쓰기