Dei uma palestra chamada Leveraging AI in Development Workflows para 47 engenheiros no BMO. O tema era configuração de guardrails e padrões de qualidade de código corporativo, e ela terminou com um Q&A aberto. Apresentar ferramentas de código com IA dentro de um banco regulado exige mais do que demos de capacidade. Exige reconhecer os medos que as pessoas não dizem em voz alta, redução de quadro, ofício, exatidão, e mostrar os guardrails que tornam a ferramenta compatível com o ambiente.
Escrevo isto de memória e das minhas próprias anotações, não de uma gravação, então leia a estrutura abaixo como o formato da sessão e não como uma transcrição. O que eu consigo precisar é o raciocínio: por que escolhi esse tema, quais demonstrações valem o tempo, quais objeções merecem uma resposta de verdade e o que eu mudaria se fizesse de novo.
Por Que Eu Me Tornei a Pessoa a Conduzir Isso
Ninguém me pediu isso. Eu propus porque já usava ferramentas de IA todo dia no meu próprio trabalho com Angular havia anos, tinha configurado o assistente do meu time, o GitHub Copilot Business, com guardrails, e tinha acompanhado os desenvolvedores do time no uso dele. A diferença de produtividade era grande o bastante para que manter isso dentro de um time de cinco parecesse errado. Gente que eu respeitava passava tardes inteiras em trabalho que a ferramenta resolve em segundos.
A outra motivação era mais pragmática. Adoção de IA em grandes organizações tende a acontecer de duas formas: mandatos top-down que criam conformidade sem adoção genuína, ou disseminação orgânica bottom-up que é lenta e descoordenada. Um showcase estruturado que reconhecesse as preocupações reais enquanto demonstrava valor real parecia um caminho mais rápido para o resultado que eu queria: equipes usando essas ferramentas de forma eficaz e segura.
Escolhendo o Tema
A maior parte da preparação foi para três coisas: entender com o que a audiência estava realmente preocupada, escolher demonstrações que fossem críveis para desenvolvedores experientes e antecipar objeções bem o suficiente para respondê-las com honestidade. A metade de capacidades era a metade fácil. Qualquer um consegue deixar um assistente de IA impressionante por dez minutos.
Não fiz nenhuma pesquisa, e não tiraria muito de uma se tivesse feito. Entrei com as preocupações que eu tinha ouvido em conversas gerais sobre essas ferramentas e com as que eu mesmo tinha: risco de segurança e compliance, qualidade e correção do código, e uma mais pessoal que decidi tratar separadamente. A suspeita de que interesse em ferramentas de IA é, na verdade, interesse em fazer o mesmo trabalho com menos gente.
Abordando o Medo de Redução de Quadro Primeiro
Coloquei a questão da redução de quadro na abertura em vez de deixá-la esperando no Q&A até alguém perguntar. O enquadramento que usei: não posso falar pelos planos de longo prazo de ninguém, mas a minha posição é que essas ferramentas são sobre a qualidade e o impacto do trabalho, não sobre substituir quem o faz. Julgamento, conhecimento de domínio e entendimento de sistema não automatizam. O que automatiza é o trabalho de que ninguém gosta.
Eu manteria essa ordem. Uma preocupação desse tamanho colore tudo o que é dito depois, e uma sala que desconfia de uma agenda escondida não faz perguntas de verdade quando você abre o microfone. Diga em voz alta antes da primeira demo, ou passe o resto da sessão falando ao lado do assunto.
Como Eu Estruturaria a Sessão
A estrutura que vale a pena manter é um enquadramento curto, a maior parte do tempo em demonstrações ao vivo, um walkthrough dos guardrails e então Q&A aberto sem hora para acabar. Mantenha poucos slides. Engenheiros não precisam de um deck. Precisam ver código que funciona aparecer e depois ver você conferir.
- Enquadramento: o que a sessão cobre, o que não cobre e a questão da redução de quadro abordada logo no começo
- Geração de testes: dar ao assistente uma função com edge cases chatos e montar a suíte ao vivo
- Uma refatoração mecânica: uma migração de padrão que todo mundo na sala já fez na mão
- Um walkthrough de debugging: descrever um bug de concorrência ao assistente e percorrer a análise dele em voz alta
- Guardrails: a configuração do Copilot Business, as custom instructions do repositório e o pipeline que rejeita código ruim independentemente de quem escreveu
- Q&A aberto, sem hora para terminar
As Demonstrações Que Funcionam
Geração de testes é a que funciona. Pegue uma função com um conjunto bagunçado de edge cases, descreva, peça uma suíte, e o arquivo volta em menos de um minuto com casos de fronteira que um desenvolvedor sob pressão de prazo pularia. É a capacidade menos vistosa da lista e a mais convincente, porque todo mundo na sala já adiou escrever exatamente esse arquivo.
Use código cuja forma a audiência reconheça. Não código do repositório que está na frente deles, que num banco levanta as próprias perguntas e abre uma conversa que você não quer no meio de uma demo, mas o mesmo framework, as mesmas convenções, o mesmo tipo de função que eles mexeram semana passada. Um exemplo de brinquedo tirado de um tutorial soa como pitch de vendas e é tratado como tal.
A demonstração de debugging é a segunda mais forte. Um race condition é bom candidato: duas requisições concorrentes em que o resultado precisa refletir a última iniciada, não a última resolvida. Mostre o bug, descreva em linguagem simples e percorra a análise em voz alta. Chega em switchMap rápido. O que está em exibição não é a resposta, é a velocidade com que você chega a uma hipótese que vale testar.
A Demonstração Que Não Empolga
Gerar um componente do zero é a demo fraca. A saída está correta e desenvolvedores experientes não se impressionam, porque conseguem escrever esse componente em cinco minutos de qualquer jeito. Eu tinha errado na proposta de valor. Velocidade de scaffolding importa quando você está gerando muitos componentes de uma vez, ou quando o scaffolding é realmente intrincado. Para um componente simples, é erro de arredondamento.
Eu trocaria por code review assistido por IA. Rodar o Copilot code review em um pull request e depois comparar o que ele apontou com o que os revisores humanos apontaram. É o caso de uso que surpreende desenvolvedores experientes, porque traz à tona os problemas que eles pegariam numa segunda leitura e deixam passar na primeira, sob pressão de tempo.
As Objeções Que Valem a Pena Preparar
O Q&A é onde o trabalho de verdade acontece. Eu tinha me preparado para as perguntas de segurança e compliance, elas vieram, e eu tinha boas respostas. As duas objeções para as quais eu tinha me preparado mal não eram sobre segurança.
A primeira é a objeção do ofício: gerar código em vez de escrever produz desenvolvedores que entendem os próprios sistemas com menos profundidade ao longo do tempo. Essa não está errada, e merece uma resposta de verdade em vez de um aceno. O mesmo argumento foi feito sobre IDEs, sobre frameworks, sobre copiar do StackOverflow, e em cada caso a resposta não foi recusar a ferramenta, e sim ser deliberado sobre quando usar e quando escrever do zero para construir ou manter o entendimento. Diga com clareza que é um risco real, porque é.
A segunda é a objeção da exatidão. Ela erra. Sim, erra. A saída da IA exige revisão, sempre. O ganho é gerar um primeiro rascunho em trinta segundos que um desenvolvedor sênior depois revisa e ajusta, em vez de digitar esse rascunho você mesmo. Suba saída de IA sem revisão e você vai se dar mal, e isso é problema de workflow, não de ferramenta.
O Que Realmente Move um Cético
Se a objeção é segurança, o walkthrough dos guardrails é a parte que importa. Ver as regras escritas como custom instructions concretas do Copilot, e ver o quality gate de CI que rejeita o código independentemente de quem ou do que escreveu, muda o enquadramento de 'esta ferramenta é um risco' para 'esta ferramenta pode ser configurada e cercada'.
Se a objeção é qualidade, mostre a ferramenta errando. Faça uma pergunta de acompanhamento que a leve por um caminho de diagnóstico ruim, pegue o erro no raciocínio dela em voz alta e corrija. Uma demo em que tudo funciona é pitch de vendas. Uma demo em que você pega o erro passa o recado de verdade: a habilidade de revisão continua sendo sua, e velocidade de IA mais revisão sênior ganha de qualquer uma das duas sozinha.
O Que Mudou Depois
Não fiz uma medição formal de adoção, e essa é a lacuna que eu fecharia primeiro. Tive conversas de acompanhamento, não um dashboard. Então não consigo dizer o que uma única sessão mudou em 47 pessoas, e quem te entrega um número redondo de adoção a partir de uma palestra só está chutando.
- No meu time, nada precisou mudar: o assistente já estava configurado com guardrails e os desenvolvedores estavam treinados. A palestra principalmente deu mais legitimidade a esse workflow
- Esse time concluiu o desenvolvimento de um projeto de compliance AML cerca de 35% antes do prazo
- Além do meu time, compartilhei o arquivo de custom instructions com quem pediu. Vários participantes voltaram com perguntas sobre como adaptá-lo aos próprios repositórios, que era o sinal que me importava
- O que eu não tenho é um número de adoção no nível da organização. Tive conversas, não um dashboard, e da próxima vez eu combinaria uma medição leve antes da sessão
Lições Para Quem Estiver Impulsionando Adoção de IA em Engenharia
O processo me ensinou mais sobre gestão de mudança do que sobre IA. Pessoas tecnicamente sofisticadas não precisam ser convencidas sobre capacidade: elas precisam que suas preocupações sejam abordadas honestamente. O caminho para adoção é reconhecer os riscos legítimos, demonstrar que esses riscos podem ser gerenciados, e mostrar o valor com código que reconhecem do seu próprio trabalho.
- Use código que se pareça com o trabalho da audiência. Um exemplo de tutorial soa como pitch de vendas
- Aborde a preocupação com redução de quadro explicitamente e cedo. Ela colore todo o resto se não for abordada
- Mostre a IA errando algo e a recuperação. Isso constrói mais confiança do que um resultado impecável
- Traga a configuração de guardrails e o quality gate de CI, não apenas a capacidade. Em ambiente regulado, a camada de segurança é a metade interessante
- Deixe o Q&A se estender. As perguntas reais, as objeções reais e o interesse real surgem depois que o conteúdo preparado termina
- Semeie o acompanhamento encontrando dois ou três participantes engajados e dando a eles algo específico para experimentar naquela semana
- Decida antes da sessão como você vai saber que funcionou. Eu me baseei em conversas depois, e mesmo um acompanhamento de três perguntas teria facilitado o argumento para a próxima sessão
O objetivo de um showcase não é gerar entusiasmo. É baixar a energia de ativação para pessoas que já estão curiosas mas não agiram. Você não precisa convencer todos na sala. Precisa dar aos interessados as ferramentas e a confiança para experimentar.
Se você é um engenheiro sênior ou tech lead considerando uma iniciativa similar na sua organização, meu conselho mais forte é começar com as pessoas que já são curiosas. Encontre três engenheiros que expressaram interesse em ferramentas de IA, trabalhe com eles por duas semanas, documente o que aprenderam e então leve essa experiência combinada para um grupo maior. Evidência de pares é mais persuasiva do que um showcase de um único defensor. Essa é a única coisa que eu faria diferente: teria co-apresentadores de outros times em vez de apresentar sozinho.
Referências
- 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