Di una charla llamada Leveraging AI in Development Workflows a 47 ingenieros en BMO. El tema era la configuración de guardrails y los estándares de calidad de código empresarial, y cerró con Q&A abierto. Presentar herramientas de código con IA dentro de un banco regulado requiere más que demos de capacidades. Requiere reconocer los miedos que la gente no dice en voz alta, la reducción de personal, el oficio, la exactitud, y mostrar los guardrails que hacen a la herramienta compatible con el entorno.
Escribo esto de memoria y a partir de mis propias notas, no de una grabación, así que lee la estructura de abajo como la forma de la sesión y no como una transcripción. Lo que sí puedo precisar es el razonamiento: por qué elegí ese tema, qué demostraciones valen el tiempo, qué objeciones merecen una respuesta real y qué cambiaría si la repitiera.
Por Qué Fui Yo Quien Impulsó Esto
No me asignaron esto. Lo propuse porque llevaba años usando herramientas de IA todos los días en mi propio trabajo con Angular, había configurado el asistente de mi equipo, GitHub Copilot Business, con guardrails, y había acompañado a los desarrolladores de mi equipo para que trabajaran con él. La diferencia de productividad era lo bastante grande como para que mantenerla dentro de un equipo de cinco se sintiera mal. Gente que yo respetaba pasaba tardes enteras en trabajo que la herramienta resuelve en segundos.
La otra motivación era más pragmática. La adopción de IA en grandes organizaciones tiende a ocurrir de dos maneras: mandatos de arriba hacia abajo que crean cumplimiento sin adopción genuina, o expansión orgánica de abajo hacia arriba que es lenta y descoordinada. Un showcase estructurado que reconociera las preocupaciones reales mientras demostraba valor real parecía un camino más rápido hacia el resultado que quería: equipos usando estas herramientas de manera efectiva y segura.
Eligiendo el Tema
La mayor parte de la preparación se fue en tres cosas: entender qué preocupaba realmente a la audiencia, elegir demostraciones creíbles para desarrolladores con experiencia y anticipar las objeciones lo suficiente como para responderlas con honestidad. La mitad de capacidades era la mitad fácil. Cualquiera puede hacer que un asistente de IA se vea impresionante durante diez minutos.
No hice una encuesta, y tampoco habría sacado mucho de una. Entré con las preocupaciones que había escuchado en conversaciones generales sobre estas herramientas y las que yo mismo tenía: riesgo de seguridad y cumplimiento, calidad y exactitud del código, y una más personal que decidí tratar aparte. La sospecha de que el interés en herramientas de IA es en realidad el interés en hacer el mismo trabajo con menos gente.
Abordando el Miedo a la Reducción de Personal Primero
Puse la pregunta sobre reducción de personal en la apertura en vez de dejarla esperando bajo el Q&A a que alguien la hiciera. El encuadre que usé: no puedo hablar por los planes a largo plazo de nadie, pero mi posición es que estas herramientas tratan de la calidad y el impacto del trabajo, no de reemplazar a quienes lo hacen. El juicio, el conocimiento del dominio y la comprensión del sistema no se automatizan. Lo que se automatiza es el trabajo que a nadie le gusta.
Mantendría ese orden. Una preocupación de ese tamaño tiñe todo lo que se dice después, y una sala que sospecha una agenda oculta no hace preguntas reales cuando abres el micrófono. Dilo en voz alta antes de la primera demo, o pasa el resto de la sesión hablando al lado del tema.
Cómo Estructuraría la Sesión
La estructura que vale la pena conservar es un encuadre corto, la mayor parte del tiempo en demostraciones en vivo, un recorrido por los guardrails y luego Q&A abierto sin hora de cierre. Mantén pocas diapositivas. Los ingenieros no necesitan un deck. Necesitan ver aparecer código que funciona y después verte revisarlo.
- Encuadre: qué cubre la sesión, qué no cubre y la pregunta sobre reducción de personal abordada desde el inicio
- Generación de tests: darle al asistente una función con casos límite incómodos y construir la suite en vivo
- Una refactorización mecánica: una migración de patrón que todos en la sala hicieron a mano alguna vez
- Un recorrido de debugging: describirle un bug de concurrencia al asistente y recorrer su análisis en voz alta
- Guardrails: la configuración de Copilot Business, las custom instructions del repositorio y el pipeline que rechaza código malo sin importar quién lo escribió
- Q&A abierto, sin hora de cierre
Las Demostraciones Que Impactan
La generación de tests es la que impacta. Toma una función con un conjunto desordenado de casos límite, descríbela, pide una suite, y el archivo vuelve en menos de un minuto con casos frontera que un desarrollador con la fecha encima se saltaría. Es la capacidad menos vistosa de la lista y la más convincente, porque todos en la sala han pospuesto escribir exactamente ese archivo.
Usa código cuya forma la audiencia reconozca. No código del repositorio que tienen delante, que en un banco levanta sus propias preguntas y abre una conversación que no quieres en medio de una demo, sino el mismo framework, las mismas convenciones, el mismo tipo de función que tocaron la semana pasada. Un ejemplo de juguete sacado de un tutorial se lee como un pitch de ventas y se trata como tal.
La demostración de debugging es la segunda más fuerte. Una race condition es buena candidata: dos peticiones concurrentes donde el resultado tiene que reflejar la última iniciada, no la última resuelta. Muestra el bug, descríbelo en lenguaje simple y recorre el análisis en voz alta. Llega a switchMap rápido. Lo que se exhibe no es la respuesta, es la velocidad con la que llegas a una hipótesis que vale la pena probar.
La Demostración Que No Impacta
Generar un componente desde cero es la demo débil. El resultado es correcto y a los desarrolladores con experiencia no les mueve nada, porque igual pueden escribir ese componente en cinco minutos. Había calculado mal la propuesta de valor. La velocidad de scaffolding importa cuando generas muchos componentes a la vez, o cuando el scaffolding es realmente enredado. Para un componente simple es un error de redondeo.
La reemplazaría por revisión de código asistida por IA. Correr Copilot code review sobre un pull request y después comparar lo que marcó contra lo que marcaron los revisores humanos. Ese es el caso de uso que sorprende a los desarrolladores con experiencia, porque saca a la luz los problemas que atraparían en una segunda lectura y se les pasan en la primera, bajo presión de tiempo.
Las Objeciones Que Vale la Pena Preparar
El Q&A es donde pasa el trabajo real. Estaba preparado para las preguntas de seguridad y cumplimiento, llegaron, y tenía buenas respuestas. Las dos objeciones para las que estaba mal preparado no eran sobre seguridad en absoluto.
La primera es la objeción del oficio: generar código en lugar de escribirlo produce desarrolladores que entienden sus sistemas con menos profundidad con el tiempo. Esa no está equivocada, y merece una respuesta real en lugar de un manotazo. El mismo argumento se hizo sobre los IDE, sobre los frameworks, sobre copiar de StackOverflow, y en cada caso la respuesta no fue rechazar la herramienta sino ser deliberado sobre cuándo usarla y cuándo escribir desde cero para construir o mantener el entendimiento. Di claramente que es un riesgo genuino, porque lo es.
La segunda es la objeción de la exactitud. Se equivoca. Sí, se equivoca. La salida de la IA requiere revisión, siempre. La ganancia es generar un primer borrador en treinta segundos que un desarrollador senior después revisa y ajusta, en vez de escribir ese borrador tú mismo. Manda a producción salida de IA sin revisar y lo vas a pasar mal, y ese es un problema de workflow, no de herramienta.
Lo Que Realmente Mueve a un Escéptico
Si la objeción es de seguridad, el recorrido por los guardrails es la parte que importa. Ver las reglas escritas como custom instructions concretas de Copilot, y ver el quality gate de CI que rechaza el código sin importar quién o qué lo escribió, cambia el marco de 'esta herramienta es un riesgo' a 'esta herramienta se puede configurar y acotar'.
Si la objeción es de calidad, muestra a la herramienta equivocándose. Haz una pregunta de seguimiento que la lleve por un mal camino de diagnóstico, detecta el error en su razonamiento en voz alta y corrígelo. Una demo donde todo funciona es un pitch de ventas. Una demo donde atrapas el error deja el punto real: la habilidad de revisión sigue siendo tuya, y la velocidad de la IA más la revisión senior le gana a cualquiera de las dos por separado.
Lo Que Cambió Después
No hice una medición formal de adopción, y ese es el hueco que cerraría primero. Tuve conversaciones de seguimiento, no un dashboard. Así que no puedo decirte qué cambió una sola sesión en 47 personas, y cualquiera que te entregue un número limpio de adopción a partir de una sola charla está adivinando.
- En mi equipo, nada tuvo que cambiar: el asistente ya estaba configurado con guardrails y los desarrolladores estaban entrenados. La charla sobre todo le dio más legitimidad a ese workflow
- Ese equipo terminó el desarrollo de un proyecto de cumplimiento AML alrededor de un 35% antes de lo programado
- Más allá de mi equipo, compartí el archivo de custom instructions con quien lo pidiera. Varios asistentes volvieron con preguntas sobre cómo adaptarlo a sus propios repositorios, que era la señal que me importaba
- Lo que no tengo es un número de adopción a nivel de toda la organización. Tuve conversaciones, no un dashboard, y la próxima vez acordaría una medición ligera antes de la sesión
Lecciones para Cualquiera que Impulse la Adopción de IA en Ingeniería
El proceso me enseñó más sobre gestión del cambio que sobre IA. Las personas técnicamente sofisticadas no necesitan que les vendan la capacidad: necesitan que sus preocupaciones sean abordadas con honestidad. El camino hacia la adopción es reconocer los riesgos legítimos, demostrar que esos riesgos pueden gestionarse, y mostrar el valor con código que reconozcan de su propio trabajo.
- Usa código que se parezca al trabajo de la audiencia. Un ejemplo de tutorial se lee como una presentación de ventas
- Aborda la preocupación sobre reducción de personal explícitamente y al principio: tiñe todo lo demás si se deja sin abordar
- Muestra a la IA equivocándose y la recuperación: construye más confianza que un resultado impecable
- Trae la configuración de guardrails y el quality gate de CI, no solo la capacidad: en un entorno regulado la capa de seguridad es la mitad interesante
- Deja que las preguntas se extiendan: las preguntas reales, las objeciones reales y el interés real surgen después de que termina el contenido preparado
- Siembra el seguimiento encontrando dos o tres asistentes comprometidos y dándoles algo específico para probar esa misma semana
- Decide antes de la sesión cómo vas a saber que funcionó. Yo me apoyé en conversaciones posteriores, e incluso un seguimiento de tres preguntas habría facilitado el argumento para la siguiente sesión
El objetivo de un showcase no es generar entusiasmo. Es reducir la energía de activación para personas que ya son curiosas pero no han actuado. No necesitas convencer a todos en la sala. Necesitas dar a los interesados las herramientas y la confianza para probar.
Si eres un ingeniero senior o tech lead considerando una iniciativa similar en tu organización, mi consejo más fuerte es empezar con las personas que ya son curiosas. Encuentra tres ingenieros que hayan expresado interés en herramientas de IA, trabaja con ellos durante dos semanas, documenta lo que aprendan, y luego lleva esa experiencia combinada a un grupo más grande. La evidencia de pares es más persuasiva que un showcase de un solo defensor. Eso es lo que haría diferente: habría tenido co-presentadores de otros equipos en lugar de presentar solo.
Referencias
- GitHub Copilot repository custom instructions. https://docs.github.com/en/copilot/how-tos/copilot-on-github/customize-copilot/add-custom-instructions/add-repository-instructions
- GitHub Copilot. https://github.com/features/copilot