IA First · Episódio 2
Do Zero ao Prompt: Como Explicar IA Para o Time Sem Virar Palestra Motivacional
Como explicar IA generativa para o time sem hype: partir da dor real, um molde de prompt, sessão prática em código de verdade e governança.
Neste artigo · 10 seções
- Por que a conversa sobre IA costuma dar errado
- Comece pelo problema, não pelo modelo
- Explique IA generativa em três blocos simples
- Fale das capacidades e limites no idioma do time
- Do zero ao prompt: um modelo mental simples
- Faça uma sessão prática, não uma palestra
- Enderece medos e cinismo de frente
- Conecte a explicação com governança e risco
- Conclusão: seu time não precisa de show, precisa de clareza
- Insights & Takeaways
Todo mundo quer falar de IA. Pouca gente consegue sair da apresentação inspiracional e cair em conversa útil para quem escreve código, prioriza backlog ou assina budget.
Enquanto isso, empresas que de fato conseguiram colocar IA na rotina de engenharia já estão vendo aumento de produtividade, redução de lead time e melhoria na qualidade do código. Só que esses ganhos aparecem onde existe uma coisa “básica”: o time entende o que está fazendo, não só copia prompt da internet.
Esse artigo é justamente sobre isso. Como explicar IA para o seu time de forma extremamente didática, sem infantilizar ninguém e sem virar show motivacional.
Por que a conversa sobre IA costuma dar errado
Normalmente a conversa segue um desses roteiros:
- PowerPoint cheio de buzzword, com slide de “Revolução Industrial 4.0”.
- Deep dive técnico em Transformer, attention e parâmetros que só empolga quem já estava convencido.
- Demonstração “olha que legal” sem conexão com o trabalho real do time.
Resultado: dev acha que é marketing, gestor acha que é moda, diretor acha que é caro e nebuloso. E ninguém muda a forma de trabalhar.
Tem dois buracos principais aí:
- Falta de letramento em IA básico, alinhado à realidade do negócio.
- Falta de exemplo concreto aplicado à stack e ao fluxo daquele time específico.
O alvo aqui é resolver esses dois pontos.
Comece pelo problema, não pelo modelo
Se você começar a reunião falando de LLM, modelo de linguagem e parâmetros, metade da sala mentalmente abre o VS Code. Melhor inverter: começar pelos problemas chatos que o time enfrenta hoje.
Alguns exemplos que batem na veia de engenharia:
- Tempo gasto em tarefa repetitiva: CRUD igual, teste de integração boilerplate, parser de JSON, DTO sem fim.
- Dificuldade de entender sistema legado, principalmente em áreas reguladas com regras de negócio estranhas.
- Falta de documentação decente, tanto técnica quanto de processos.
- Demora para explorar alternativas de solução porque escrever código de prova de conceito consome tempo.
Você não precisa convencer ninguém de que isso dói. Eles vivem isso todo dia. Depois que o problema está claro, aí sim você puxa a conversa para “onde IA entra aqui”.
Uma frase possível, bem direta:
“Eu não quero que vocês saiam daqui decorando nome de modelo. Quero que a gente entenda juntos como usar IA para reduzir o que ninguém gosta de fazer e abrir espaço para o que só vocês conseguem fazer.”
Explique IA generativa em três blocos simples
Seu objetivo não é formar pesquisador. É dar um modelo mental que caiba na cabeça do time inteiro.
Você pode explicar IA generativa em três blocos, sem exagerar no jargão:
- Modelo de linguagem como autocomplete esteroidal É um sistema treinado em muito texto e código que aprendeu padrões de sequência. Ele tenta prever o próximo token dado o contexto. Não “pensa”, não “entende” como humano, mas reconhece padrões em escala absurda.
- Entrada, contexto, saída O prompt é só a forma como você estrutura a entrada. Você pode adicionar contexto (código, documentação, exemplos, dados) e pedir uma saída em formato específico: código, texto, JSON, explicação passo a passo.
- Probabilístico e falho por definição O modelo sempre trabalha com probabilidade, não com verdade. Isso significa que erros, alucinações e respostas inconsistentes são parte do jogo, principalmente sem estrutura.
Se você ancorar nesses três pontos, já foge tanto da palestra de futurismo quanto do reducionismo “é só autocomplete”.
Fale das capacidades e limites no idioma do time
Aqui é onde você evita o hype.
Em vez de prometer que IA “vai revolucionar” o desenvolvimento, é melhor falar em termos de caso de uso concreto + limitação clara.
Alguns exemplos que funcionam bem para engenharia:
- Bom em:
- Gerar a primeira versão de código repetitivo, que depois o dev revisa.
- Explicar código ou arquitetura em linguagem natural, ajudando em onboarding.
- Criar testes a partir de código existente ou especificação de alto nível.
- Resumir issues, PRs longos e discussões técnicas.
- Ruim em:
- Garantir aderência completa a regras de negócio complexas sem validação externa.
- Lidar com contexto ambíguo ou incompleto.
- Provar corretude ou segurança de código crítico.
- Tomar decisão sozinho em cenários regulados sem supervisão.
Você quer que o time saia com a sensação de: “Ok, entendi onde isso pode me ajudar, onde pode me ferrar e onde eu preciso colocar guarda-corpo”.
Do zero ao prompt: um modelo mental simples
Agora entra a parte “ao prompt”. Se você falar de “prompt engineering” como se fosse um novo cargo, perde parte da credibilidade. Melhor tratar como design de interface entre humano e modelo.
Um modelo que funciona bem para explicar para o time é esse aqui:
- Papel Dizer ao modelo explicitamente quem ele é e que tipo de comportamento você espera: “Você é um desenvolvedor sênior em .NET focado em performance e legibilidade.”
- Contexto Colocar o material relevante: trecho de código, assinatura de método, regra de negócio, contrato de API. Sem isso, o modelo inventa.
- Tarefa Dizer o que você quer ver: “Refatore para remover duplicação mantendo a mesma funcionalidade.” “Escreva testes de unidade cobrindo cenários X, Y, Z.”
- Formato da resposta
Deixar claro como a saída deve vir:
“Responda apenas com o código C#, sem explicações.”
“Retorne um JSON com os campos
name,description,edge_cases.” - Restrições e critérios de aceitação “Não altere a assinatura pública do método.” “Não use bibliotecas externas.” “Considere que isso roda num sistema de negociação em tempo real.”
Você pode mostrar alguns prompts ruins que o time já usou e reescrevê-los ao vivo usando esse molde. É aí que a ficha cai.
Faça uma sessão prática, não uma palestra
Nada mata mais o interesse que uma hora de teoria sem ninguém encostar na ferramenta. Uma abordagem que funciona bem com times técnicos é:
- Escolher um caso real da base de código Algo pequeno, mas significativo. Um serviço meio feio, uma função com regra de negócio difícil, um teste que ninguém quer escrever.
- Rodar primeiro “do jeito antigo” Mostrar como o time resolveria aquilo sem IA. Só para ter referência de esforço mental.
- Rodar o mesmo problema com IA, ao vivo
- Começar com prompt ingênuo.
- Mostrar onde a resposta vem errada, incompleta ou insegura.
- Iterar o prompt, adicionando papel, contexto, restrições.
- Comparar o resultado com o que o time faria na mão.
- Discutir o fluxo de trabalho, não a demo em si
O ponto não é “olha como o modelo é incrível”, é:
- Onde isso encaixa no seu dia a dia?
- O que você ainda precisa revisar manualmente?
- O que você deixa de fazer se tiver essa ajuda?
Estudos sobre adoção de IA em engenharia mostram justamente isso: os ganhos vêm quando IA entra como parte do fluxo, não como brinquedo paralelo.
Enderece medos e cinismo de frente
Se você não falar de medo de substituição, alguém vai. E normalmente vem em formato de piada ácida no fundo da sala.
Aqui compensa ser bem explícito:
- Para devs: “IA está muito boa em gerar o primeiro rascunho e bem fraca em entender o contexto completo do seu sistema. Quem sabe o que pode ou não pode em produção ainda é você.”
- Para líderes: “O risco não é o dev ser substituído, é o dev que usa IA bem substituir o que continua trabalhando como se nada tivesse mudado.”
- Para diretoria: “O maior risco agora não é adotar IA, é adotar mal. Sem governança, sem guardrails e sem métrica de impacto.”
Ao mesmo tempo, vale reconhecer que IA exige novas habilidades, o que muitos chamam de AI literacy: entender capacidades, limites, riscos e implicações de uso da tecnologia. Seu papel como líder técnico é acelerar esse aprendizado, não controlar tudo sozinho.
Conecte a explicação com governança e risco
Para não virar só papo motivacional, ajuda amarrar a conversa a três tópicos concretos:
- Qualidade e revisão
- Quem é responsável pela revisão de código gerado por IA?
- O que não pode ir para produção sem olhar humano?
- Como vamos dar feedback para ajustar o uso da ferramenta?
- Segurança e privacidade
- Quais dados nunca podem ir para o prompt?
- Qual ferramenta é aprovada e configurada para ambiente corporativo?
- Métricas
- O que queremos ver mudar: lead time, tempo de code review, bugs, MTTR?
- Como vamos saber se IA está ajudando ou só gerando volume?
Quando você traz IA para essa camada de decisão, o time entende que não é brinquedo, é parte da disciplina de engenharia.
Conclusão: seu time não precisa de show, precisa de clareza
Explicar IA para o time não é sobre impressionar. É sobre dar modelo mental simples, exemplos reais e espaço seguro para testar, errar e ajustar.
Se você conseguir:
- Partir de problemas que o time realmente sente.
- Explicar capacidades e limites em linguagem direta.
- Mostrar ao vivo como desenhar bons prompts.
- Conectar tudo isso com governança, qualidade e risco.
Então a conversa deixa de ser palestra motivacional e vira alinhamento de como a equipe vai trabalhar nos próximos anos.
O resto é prática diária.
Insights & Takeaways
- Comece pela dor real do time, não pelo diagrama de Transformer.
- Explique IA em três blocos: modelo de linguagem, entrada/contexto/saída, natureza probabilística.
- Ensine um molde simples de prompt: papel, contexto, tarefa, formato, restrições.
- Faça sessão prática em cima de código real, iterando prompts ao vivo.
- Traga medo, risco e governança para a mesa, para que o assunto saia da camada de “brinquedo” e entre em “como vamos trabalhar daqui para frente”.
