Sí, es un gran placer para mí compartir lo que sé, lo que aprendí sobre la escalabilidad de la asistencia de codificación de IA y, de manera más general, la adopción de herramientas de desarrollo nativas de IA en equipos de ingeniería de las organizaciones. Por supuesto, principalmente relevante para medianas y grandes empresas, pero las técnicas son aplicables porque veo que hay una gran brecha entre las empresas que compran licencias para esta o aquella herramienta y las empresas que ven un retorno de la inversión en este movimiento. Y en Microsoft, ayudo a los líderes de ingeniería a encontrar realmente el camino para esta adopción. Y lo que voy a compartir en los próximos, tal vez, seis, siete minutos son algunas piezas de un marco llamado Well-Architected, creado por mis queridos colegas de GitHub y también, por supuesto, mis aprendizajes personales de reuniones con líderes de ingeniería.
Y en mi trabajo diario, me encuentro con estas personas y sus equipos de desarrolladores casi todos los días. Así que hay una especie de paradoja de adopción y vamos a descubrir esta incómoda verdad. A menudo tratamos la adopción de la asistencia de IA y, de manera más general, las herramientas de desarrollo nativas de IA como un problema de tecnología cuando en realidad, es un problema de gestión del cambio. Y no se trata de comprar licencias y organizar algunos andamios técnicos sobre cómo usar eso. No, en realidad se trata de reconfigurar cómo trabajan los desarrolladores, cómo trabajan los equipos de desarrolladores completos. Y estoy aquí para compartir lo que permite en nuestro tiempo este, digamos, marco táctico. ¿Cuáles son tus próximos pasos y dónde poner la atención principal si también sientes esta brecha? Y tres etapas, tres fases, y podría ser tu modelo mental. Incorporar, adoptar, tener éxito. Y repasaremos brevemente estos tres pilares.
En primer lugar, incorporación. Solo para asegurarte de que tus desarrolladores tengan acceso a estas licencias, a estos asientos, suscripciones, lo que sea. Y, por supuesto, querrás proponer diferentes políticas para herramientas de desarrollador verificadas versus no verificadas, especialmente si estás hablando de IA. Definitivamente no quieres terminar en una situación que llamamos IA en la sombra. Es mucho peor que la TI en la sombra. Si tus desarrolladores no están usando las herramientas de IA que les sugeriste usar, asegúrate de que usen otra cosa, comenzando desde el viejo y conocido copiar y pegar hasta child GPT o lo que sea. Es una pesadilla. Es un desastre para cada gerente de TI. No querrás matarte distribuyendo manualmente licencias a los desarrolladores. Depende mucho de una herramienta particular, del proveedor particular con el que trabajes. Pero prueba aquellas con capacidades donde los desarrolladores puedan servirse a sí mismos. Y para dormir bien por la noche, asegúrate de que todas las barreras de seguridad estén en su lugar para que funcione tanto para ti como para los desarrolladores a los que ofreces estas herramientas de desarrollo. Comenzando desde, no sé, tal vez el ejemplo moderno de hoy, a qué servidores MCP pueden conectar sus asistentes de codificación de IA. En muchos casos, quiero decir, también dependiendo de un proveedor particular, algunos de ellos son todo o nada. Algunos de ellos proporcionan un control más granular. Así que asegúrate de elegir el correcto. Entonces, si te pido que recuerdes un término particular de mi presentación, es infraestructura humana.
Comments