Olá a todas as pessoas! Meu nome é Maurício, sou o CTO da Alura, tenho mais de 20 anos de experiência no mundo do software. Já passei por grandes empresas como a Uber e a Agen, fiz um pós-doutorado na Universidade de Delft, onde entrei no mundo da IA. Hoje vou contar um pouco dessa história e estou aqui para falar sobre qualidade e estratégias de adoção nesse novo mundo do desenvolvimento, no qual a IA nos auxilia no trabalho do dia a dia.
Nossa trajetória com IA começou antes de imaginarmos o quanto ela seria impactante no desenvolvimento. Em 2016, ao iniciar o pós-doutorado na Universidade de Delft — na foto do primeiro dia, caminhando até o prédio da universidade, em um dia chuvoso — conhecemos um grupo muito focado em inteligência artificial para resolver problemas de engenharia de software. Naquele momento, não se falava em LLMs (Modelos de Linguagem de Grande Porte). O foco estava em algoritmos de busca — o que chamamos de "search-based software engineering (engenharia de software baseada em busca)" — e em técnicas de "shallow learning (aprendizado superficial)", como "decision trees (árvores de decisão)" e "Random Forest (floresta aleatória)".
A ideia central era escolher um problema de engenharia de software que fosse complexo ou exigisse muito trabalho humano e ensinar a máquina a resolvê-lo. Esses são problemas que, se tentássemos solucionar de forma determinista, codificando um algoritmo específico, seriam extremamente difíceis. Um exemplo é gerar um teste automatizado para um programa ou função específicos: como escrever um programa determinista que faça isso?
Nosso doutorado havia sido, em parte, voltado para análise estática, por isso tínhamos paixão por inspecionar código-fonte e encontrar problemas. Ingressamos nessa área em busca de um novo desafio no pós-doutorado, aprendemos bastante e publicamos muito sobre o que estávamos estudando. Exploramos "search-based software engineering (engenharia de software baseada em busca)", utilizando, por exemplo, algoritmos genéticos para resolver problemas.
Publicamos um paper (artigo) no qual queríamos escrever testes para uma query (consulta) SQL. Testar uma consulta SQL é análogo a testar um programa: queremos exercitar todos os caminhos possíveis da consulta. Se existe um WHERE A > 10, precisamos de dados na tabela em que A > 10 e A < 10, garantindo que a consulta retorne apenas os registros com A > 10. Para isso, aplicamos algoritmos de busca, com resultados muito bem-sucedidos.
Também produzimos vários trabalhos com técnicas de shallow learning (aprendizado superficial), como decision trees (árvores de decisão) e Random Forest (floresta aleatória). Nosso trabalho mais impactante na área — e o mais citado até hoje — tratou de refatoração. A proposta era recomendar à pessoa desenvolvedora quando uma classe ou um método precisaria ser refatorado. Como fizemos isso? Na época, não havia LLMs (Modelos de Linguagem de Grande Porte); precisávamos treinar nossos próprios modelos, e era difícil contar com um modelo pronto para problemas genéricos, como acontece hoje com o ChatGPT.
Coletamos diversos exemplos de commits (registros de alteração) do mundo real em que uma refatoração havia sido realizada e extraímos o antes e o depois — o método antes e depois da refatoração. Reunimos métricas de código, como tamanho e complexidade do método antes e depois, e treinamos diferentes algoritmos de Machine Learning (aprendizado de máquina) para prever se uma classe deveria ou não ser refatorada.
Recomendamos a leitura desse paper (artigo), que mostra como pensávamos em Machine Learning (aprendizado de máquina) antes das LLMs (Modelos de Linguagem de Grande Porte). Os resultados indicaram que os modelos eram altamente capazes de analisar uma classe e, com base no histórico de refatorações observadas, indicar quando um método ou classe precisava ser refatorado.
Implantamos essa ferramenta, esse modelo, no ING, um banco holandês de grande porte, e realizamos testes com as pessoas desenvolvedoras do banco. A percepção foi muito positiva em relação às sugestões de refatoração.
Nos últimos anos (2019, 2020, 2021), o deep learning (aprendizado profundo) se tornou cada vez mais popular. Passamos a ter mais acesso a GPUs (unidades de processamento gráfico), então começamos a treinar redes neurais para resolver problemas da área de software. Trabalhamos diferentes problemas, como prever bugs. Publicamos um artigo no qual propusemos prever o erro off-by-one (erro por uma unidade) — quando usamos > e deveríamos usar >=. Treinamos a rede neural e o resultado foi apenas aceitável, longe de perfeito. É um problema complexo, pois exige compreender a semântica do código. Além disso, as redes neurais que treinávamos naquela época não eram tão profundas quanto as que vemos hoje com o ChatGPT, com trilhões de neurônios. Ainda assim, esses foram passos importantes que a comunidade deu ao longo do tempo ao tentar usar IA na engenharia de software.
As LLMs (Modelos de Linguagem Grande) mudaram tudo. Agora não é necessário treinar modelos altamente específicos, coletar dados por conta própria ou dispor de um grande volume de GPUs para treinar modelos muito profundos. ChatGPT, Claude, Kimi e outros modelos amplamente conhecidos são gigantescos e têm conhecimento sobre praticamente tudo. Assim, a tarefa que fornecermos tende a ser resolvida, mesmo sem um pós-treinamento. Se passarmos um método, o modelo poderá indicar se esse método precisa ser refatorado com base nas regras fornecidas. Também poderá apontar um possível erro off-by-one apenas a partir do método, pois já “viu” inúmeros exemplos de código.
De certa forma, muito do que pesquisamos em quatro ou cinco anos na Universidade de Delft hoje faz menos sentido. Contamos isso para mostrar que nossa trajetória com IA já tem 10 anos — estamos gravando este curso em 2026 —, e estamos muito entusiasmados com este novo mundo do Dev (desenvolvimento). Acreditamos que a IA vem para ajudar pessoas desenvolvedoras a entregar mais software para a sociedade, com maior qualidade.
Quais são nossos objetivos neste curso? Dois pontos:
Ao final deste curso, queremos que você saia com um conjunto de guardrails (conjunto de regras e restrições a serem aplicadas no seu ambiente para assegurar a qualidade do software). Vamos usar muito a palavra guardrails (conjunto de regras e restrições). Também vamos discutir como adotar IA minimizando riscos: estamos falando da adoção de uma ferramenta nova; a IA escreve muito código para você; provavelmente não será possível ler todo o código gerado. Como reduzir esse risco? E como medir o impacto do seu time para entender se a adoção de IA está evoluindo como esperado, sem cair em vanity metrics (métricas de vaidade), que surgem quando monitoramos uma métrica de uma pessoa usuária ou de uma pessoa desenvolvedora e acabamos nos confundindo, pois a métrica, analisada de forma isolada, costuma ser enganosa.
Não vamos apresentar verdades absolutas neste curso, porque elas ainda não existem nesse mundo da IA. Estamos aprendendo coletivamente, experimentando em diferentes frentes e extraindo lições do que deu certo e do que deu errado. Vamos propor discussões, relatar desafios que enfrentamos aqui na Alura durante nosso processo de adoção de IA e compartilhar muitos aprendizados acumulados nessa trajetória próxima desse novo cenário. Você vai identificar o que faz sentido no seu contexto, aplicar na sua empresa e promover a melhoria contínua para seguir refinando a adoção de IA.
Está bem? Vamos!
Vamos começar nossa aula discutindo a realidade do novo mundo do desenvolvimento em 2026 em diante. A realidade é que a IA já não é um experimento; é realidade. Se olharmos as empresas que começaram a adotar IA há algum tempo, como as Big Tech (grandes empresas de tecnologia) Google, Uber, Stripe, entre outras, já vemos que grande parte do código escrito pela equipe de desenvolvimento é assistido por algum tipo de inteligência artificial.
Nos nossos slides (apresentações), trazemos duas notícias. Uma delas mostra a Google informando que cerca de 30% do seu código já é escrito por IA; o mesmo ocorre na Microsoft. Também trazemos o exemplo do Stripe Minion, inspirado nos personagens famosos. Os Minions são agentes autônomos que a Stripe criou para resolver tarefas de código. Observamos que há empresas como a Stripe que já saíram do modo no qual a IA roda local no nosso computador — abrimos o Codex, o Cloud Code, codificamos no nosso computador e consultamos o código-fonte no nosso IDE (ambiente de desenvolvimento integrado). Esses Minions já estão 100% executando na nuvem de forma autônoma, com muito pouca intervenção humana. Sem dúvida, este é o futuro: grande parte do código sendo escrito por IA de maneira assistida, nós trabalhando em conjunto com a IA no código-fonte, e o código-fonte também sendo gerado de forma possivelmente até 100% autônoma, sem necessidade de uma pessoa por perto.
Contudo, Big Tech é Big Tech. Vamos falar de empresas comuns. Vamos trazer números da empresa DX, uma empresa norte-americana que faz benchmarks (referências comparativas) de mercado sobre diversos temas em engenharia de software, incluindo a adoção de IA. Na palestra de Laura Tacho, ex-CTO (cargo de direção de tecnologia) da DX, são apresentados números interessantes. Esse benchmark é baseado em aproximadamente 400 empresas de diferentes portes, e hoje o ganho médio de produtividade de uma pessoa desenvolvedora usando IA é de cerca de 4 horas — ou seja, 10% da semana de trabalho, assumindo 40 horas. Um ganho de 10% já é bastante aceitável; qual empresa não gostaria de 10% a mais?
Esses números variam de acordo com a senioridade da pessoa profissional. Houve muita discussão sobre a pessoa desenvolvedora 10X — aquela 10 vezes mais produtiva que outra. No mundo da IA, falamos da pessoa desenvolvedora 20X, 20 vezes mais rápida do que antes, porque o gargalo de escrever o código diminuiu drasticamente. No benchmark, 25% do código dessas empresas já está sendo escrito por IA, número semelhante ao de Google e Microsoft, que relatam cerca de 30%. Essa tem sido a média de mercado: 30% do código escrito por IA.
Outro dado relevante é que a IA reduz o tempo de onboarding (integração) pela metade. Quando uma pessoa desenvolvedora chega a um projeto novo, conhece pouco do domínio, talvez nem conheça a linguagem de programação e os frameworks (estruturas) utilizados, e precisava aprender antes de começar a ser produtiva no ambiente. Nesse novo contexto, em que detalhes da linguagem e do framework deixam de ser barreiras, o tempo de onboarding de uma pessoa desenvolvedora nova já caiu à metade, ao menos segundo o benchmark da DX. São números bastante interessantes para quem atua em liderança e direção de Engenharia de Software, CTO e funções correlatas, indicando que a IA vem para aumentar nossa produtividade.
Nem tudo são flores; os desafios existem. No benchmark, notou-se que, em termos de qualidade — incidentes em produção, que foi o que mediram no número mostrado no slide —, algumas equipes estão enfrentando o dobro de incidentes em relação ao período anterior. Ou seja, a equipe introduziu IA e os incidentes aumentaram, exatamente o que não queremos. Por outro lado, há equipes que adotaram IA e o número de incidentes caiu pela metade. Além de entregar mais software, entregamos mais software com menos problemas — o cenário ideal.
Não por acaso, este curso trata de qualidade no mundo da IA e de guardrails (diretrizes de segurança), pois isso fará muita diferença para ajudar a IA a escrever código que funcione. Vamos falar de IA escrevendo código que não funciona em produção. A IA, sem dúvida, nos acelera, mas também pode amplificar nossos erros.
Vamos considerar casos que apareceram na internet e geraram repercussão, pois são bons exemplos para discussão. Um deles foi na Amazon, que teve alguns incidentes em sequência e, internamente, atribuiu a responsabilidade à IA por esses bugs (defeitos). Chegou-se até a exigir que pessoas desenvolvedoras sêniores revisassem código escrito com IA por pessoas mais juniores. Ou seja, a Amazon, uma Big Tech muito conhecida e referência em engenharia de software, também está sofrendo com bugs oriundos de código gerado por IA.
O mesmo ocorre no mundo open source (código aberto). Contribuir sempre teve seus desafios, com uma barreira alta de entrada. Agora, com a IA, assim como ficou mais fácil fazer onboarding no nosso projeto, também ficou muito mais fácil fazer onboarding em um projeto open source. O número de contribuições aumentou significativamente, mas, ao mesmo tempo, o número de vulnerabilidades introduzidas no ecossistema open source também cresceu. Portanto, a IA não apenas pode escrever código que não funciona, como também pode escrever código inseguro.
Por fim, à direita do slide, há um tweet (publicação no X/Twitter) de Summer.
Summer é responsável por privacidade, segurança e temas relacionados na Meta. Ela estava executando um desses CLOs, assistentes inteligentes 100% guiados por IA, e mostrou sua conversa com o CLO dizendo: “Não faça isso”. O CLO respondeu: “Vou apagar tudo”. Ela pediu para parar, mas o CLO continuou tentando apagar seus dados. Na sequência de tuítes, ela relata que precisou correr pelos escritórios da Meta para desligar fisicamente o computador, porque o CLO deixou de obedecer aos comandos. Isso evidencia que tudo tem prós e contras em engenharia de software. Sabemos disso há décadas, e isso não muda neste novo mundo da inteligência artificial.
Mais exemplos: comentamos o caso da Amazon, que está contendo o uso de código gerado por IA ao exigir que uma pessoa desenvolvedora sênior faça revisão de código. Podemos pausar o vídeo e ler esses tuítes. Nossa mensagem aqui é que, se até organizações como a Amazon — com sistemas de integração contínua de ponta, suites (conjuntos) de testes automatizados robustas e várias ferramentas de análise estática para garantir o funcionamento do código —, isto é, no estado da arte da engenharia de software, ainda assim estão entregando software com problemas no contexto da IA, o que dizer de nós, que construímos sistemas em uma escala muito menor? Precisamos refletir seriamente sobre qualidade.
No slide, trouxemos também o exemplo da Anthropic, fabricante do Claude Code. Eles destacam muito as capacidades de seus modelos e, no momento em que criamos este slide, mencionavam bastante o Mythos, um modelo de inteligência artificial que gerou receio por potencialmente deixar vulnerabilidades. O próprio Claude Code tem sofrido diversas inestabilidades por vários motivos. Não afirmaram que a causa seja código escrito por IA — não seriam inconsequentes a ponto de dizer isso publicamente, pois seus investidores reagiriam —, mas é curioso notar que a empresa que afirma ter o modelo mais potente do mundo não consegue entregar software 100% resiliente. Os desafios só aumentam.
Se acompanhamos Anthropic e OpenAI e a velocidade com que estão lançando software, vemos que o Claude Code e o Codex evoluem diariamente. Surgem novas versões o tempo todo, e o número de pessoas usuárias cresce rapidamente. Todas estão percebendo que software é mais do que código: envolve a operação desse código em produção, com resiliência. Entregar mais código, muito mais rápido do que antes, traz desafios operacionais significativos. Estamos implantando em uma velocidade inédita. Como resolvemos isso?
Falemos de guardrails (barreiras de proteção). O que são? São proteções que adicionamos ao sistema para garantir que, se a IA escrever um código que não funciona, o teste falhe e a IA receba um sinal de retorno indicando “este código não funciona”, retomando o trabalho até que o teste fique em verde, isto é, passe.
Trouxemos um tuíte de Addy Osmani, gerente de engenharia no Google, responsável por equipes que trabalham no Chrome. Ele destacou que toda mudança de abstração no mundo da engenharia de software torna pessoas desenvolvedoras mais produtivas, elevando o nível de intenção ao escrever código. Saímos de Assembly (linguagem de montagem), muito próximo da máquina e difícil de ler, para linguagens de mais alto nível como C e Java. Ao adicionar IA, elevamos novamente o nível de abstração: grande parte do trabalho agora é especificar, em linguagem natural, o que queremos fazer, elaborar um bom prompt (instrução) e assim por diante.
Ele comenta que o problema não resolvido não é a geração de código. Essa parte evoluiu muito: se compararmos os modelos de 2025 com os que temos hoje, em 2026 — como Opus, GPT 5.4, 5.5 —, a geração está razoavelmente encaminhada. Já a verificação do código, para assegurar que realmente funcione, está longe de uma resposta definitiva. É aqui que nosso julgamento como pessoas engenheiras de software se torna a habilidade mais importante e valiosa: garantir que todo o código produzido com assistência de IA funcione, pois a IA ainda não está pronta para fazer isso sozinha.
Neste curso, vamos falar bastante sobre guardrails (barreiras de proteção) e vamos utilizá-los amplamente: testes automatizados, revisão de código e outras práticas conhecidas. Vamos discutir como essas abordagens mudaram e estão sendo reinventadas neste novo contexto.
Antes de avançarmos para o próximo vídeo, propomos uma reflexão em três pontos:
Nesta parte do curso, vamos falar sobre guardrails (trilhos de proteção) de qualidade. No mundo da engenharia de software, em um contexto pré-LLM (Modelo de Linguagem Grande) e pré-IA, sempre tivemos guardrails.
Por exemplo, mantínhamos uma suíte de testes automatizados. Por que a mantínhamos mesmo antes da IA? Porque sabíamos que é muito fácil uma pessoa desenvolvedora alterar um trecho de código e quebrar algo que já estava funcionando, e esperar para ver isso acontecer em produção não é uma boa ideia. Por isso, escrevemos testes automatizados — sejam unitários ou end-to-end (ponta a ponta) — para detectar esse problema antes de o código chegar à produção.
Também realizamos revisão de código e utilizamos ferramentas de análise estática para tentar encontrar problemas de qualidade do código, identificando pontos onde podem ocorrer erros como NullPointerException, entre outros.
Sempre refletimos sobre a ideia de ter uma camada de proteção que nos informe se o código escrito manualmente — digitando caractere por caractere — funciona ou não. A proposta é a mesma no contexto de IA. A diferença é que o volume de código aumentou de forma expressiva. O que conseguíamos escrever com os nossos dedos, e o que nossa equipe como um todo conseguia produzir, é muito menor se comparado ao que a IA pode gerar, escrevendo milhares de linhas de código em poucos minutos.
Aqui não apresentaremos nenhuma guardrail (barreira de proteção) nova. Não criamos uma guardrail (barreira de proteção) que, de forma mágica, resolva todo o problema. As guardrails (barreiras de proteção) que temos hoje são suficientes para resolver esses problemas. Precisamos apenas encontrar a forma exata de como implementá-las — ou melhor, de como adaptá-las — para este mundo da inteligência artificial. Portanto, vamos nos preparar: nós vamos discutir várias delas.
O curso IA na engenharia de software: guardrails de qualidade e estratégias de adoção possui 142 minutos de vídeos, em um total de 33 atividades. Gostou? Conheça nossos outros cursos de IA para Programação em Inteligência Artificial, ou leia nossos artigos de Inteligência Artificial.
Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:
O Plano Plus evoluiu: agora com Luri para impulsionar sua carreira com os melhores cursos e acesso à maior comunidade tech.
2 anos de Alura
Matricule-se no plano PLUS 24 e garanta:
Jornada de estudos progressiva que te guia desde os fundamentos até a atuação prática. Você acompanha sua evolução, entende os próximos passos e se aprofunda nos conteúdos com quem é referência no mercado.
Programação, Data Science, Front-end, DevOps, Mobile, Inovação & Gestão, UX & Design, Inteligência Artificial
Formações com mais de 1500 cursos atualizados e novos lançamentos semanais, em Programação, Inteligência Artificial, Front-end, UX & Design, Data Science, Mobile, DevOps e Inovação & Gestão.
A cada curso ou formação concluído, um novo certificado para turbinar seu currículo e LinkedIn.
Acesso à inteligência artificial da Alura.
No Discord, você participa de eventos exclusivos, pode tirar dúvidas em estudos colaborativos e ainda conta com mentorias em grupo com especialistas de diversas áreas.
Faça parte da maior comunidade Dev do país e crie conexões com mais de 120 mil pessoas no Discord.
Acesso ilimitado ao catálogo de Imersões da Alura para praticar conhecimentos em diferentes áreas.
Explore um universo de possibilidades na palma da sua mão. Baixe as aulas para assistir offline, onde e quando quiser.
Luri Vision chegou no Plano Pro: a IA da Alura que enxerga suas dúvidas, acelera seu aprendizado e conta também com o Alura Língua que prepara você para competir no mercado internacional.
2 anos de Alura
Todos os benefícios do PLUS 24 e mais vantagens exclusivas:
Chat, busca, exercícios abertos, revisão de aula, geração de legenda para certificado.
Envie imagens para a Luri e ela te ajuda a solucionar problemas, identificar erros, esclarecer gráficos, analisar design e muito mais.
Aprenda um novo idioma e expanda seus horizontes profissionais. Cursos de Inglês, Espanhol e Inglês para Devs, 100% focado em tecnologia.
Escolha os ebooks da Casa do Código, a editora da Alura, que apoiarão a sua jornada de aprendizado para sempre.
Para quem quer atingir seus objetivos mais rápido: Luri Vision ilimitado, vagas de emprego exclusivas e mentorias para acelerar cada etapa da jornada.
2 anos de Alura
Todos os benefícios do PRO 24 e mais vantagens exclusivas:
Catálogo de tecnologia para quem é da área de Marketing
Envie imagens para a Luri e ela te ajuda a solucionar problemas, identificar erros, esclarecer gráficos, analisar design e muito mais de forma ilimitada.
Escolha os ebooks da Casa do Código, a editora da Alura, que apoiarão a sua jornada de aprendizado para sempre.
Conecte-se ao mercado com mentoria individual personalizada, vagas exclusivas e networking estratégico que impulsionam sua carreira tech para o próximo nível.
