Estudando com IA

2026-08-22

Recentemente fiz um estudo sobre kubernetes, comparando as funcionalidades da tecnologia com Docker.

A ideia desse artigo é explorar um pouco dessa jornada, o que aprendi estudando com IA, minhas impressões e considerações.

TL;DR

Usei o Kiro para me ajudar a montar um plano de estudo sobre Kubernetes. Gostei muito do resultado, e aprendi algumas lições no caminho:

• A IA responde a comandos: não fale com a IA como se fosse uma conversa corriqueira, dê a ela um comando, ou deixe claro se for uma pergunta/reflexão;
• Cuidado com o contexto: tudo é dado para a IA trazer resposta pra você, inclusive o que deveria ser descartado;
• A IA não sabe de tudo: ela não está certa sobre tudo, duvide dela;
• A IA não paga débito técnico: a IA não vai melhorar o que você já tem, a menos que explicitamente você peça por isso;
• Revise todo o código feito: mantenha seu código versionado e revise tudo que a IA faz. Trabalhe em baby steps quando estiver fazendo vibe code;
• A IA tem limites: se a resposta não tá na internet, a IA não vai saber te responder.

O Plano

Abri meu Kiro CLI e comecei a conversar com a IA para montar um plano de estudo. Expliquei meu objetivo e fui, junto do Kiro, montando cenários para estudar aquilo na prática. Fiz alguns ajustes aqui e outros ali, cortei algumas coisas, e em menos de meia hora eu tinha um plano. Não muito robusto, nem muito documentado, mas que atendia meu objetivo.

Impressões

A IA responde a comandos

O primeiro cenário era relativamente simples: uma aplicação products-service que expõe um endpoint para consumir dados de um banco. Um docker compose para subir um postgres e a aplicação.

Eu estava usando NX como workspace. Descuidadamente eu digitei o seguinte prompt: blz, vamos implementar o products service. Pra quê?! O Kiro começou a criar todos os arquivos que um nx g criaria. Percebi e cancelei o prompt antes de gastar meus preciosos créditos.

Ficou claro pra mim que eu errei no prompt. Fui no automático, como se estivesse tendo uma conversa enquanto fazia um pair com um colega. O que é uma prática bem comum, porém com suas limitações. O artigo Stop talking to AI. Start commanding it. fala um pouco sobre isso de forma bem didática.

Falar com a IA como se fosse um colega é uma ficção cultural útil para o público em geral. No ambiente empresarial, é um erro estratégico. A forma correta de instruí-la, em 2026, é a mesma que você usaria para qualquer computador: com instruções claras, explícitas e estruturadas.

Corroborando isso, o próprio guia de boas práticas do Claude (Best practices for prompt engineering for 2026), instrui que devemos ser explícitos e comandar a IA na criação dos nossos prompts:

Modelos modernos de IA respondem excepcionalmente bem a instruções claras e explícitas. Não presuma que o modelo vai inferir o que você quer — diga diretamente. Use uma linguagem simples que declare exatamente o que você deseja, sem ambiguidades.

Lição: não fale com a IA como se fosse uma conversa corriqueira, dê a ela um comando, ou deixe claro se for uma pergunta/reflexão.

Cuidado com o contexto

Logo em seguida fomos dockerizar a aplicação. Algo simples, mas que deu uma dor de cabeça terrível. Eu estava com o build demorando quase 5 minutos. Pedi ajuda pra IA, é claro.

O problema é que eu tinha trocado uma ideia com ela sobre algumas configurações da minha máquina e quantos containers dockers + minikube eu conseguiria rodar.

Resultado: quando apresentei pra ela o problema da demora no build, ela começou a trazer várias respostas sobre performance da máquina, quantidade de memória, CPU, etc. Devo ter gasto quase meia hora nessa conversa.

Abri um novo chat e comecei:

eu sempre rodei docker nessa máquina e nunca tive problemas, agora estou com o problema tal e tal e tal, analise o repositório e veja se tem algo na nossa aplicação que pode estar gerando esse problema

O novo chat escaneou todos os arquivos de novo e percebeu algo simples: estávamos fazendo um COPY . . no Dockerfile, e portanto estávamos copiando toda a node_modules pra dentro do container. A correção foi bem simples: adicionar um .dockerignore.

Segundo o artigo What Is the Slot Machine Method for AI Agents? Why Restarting Beats Correcting, esse problema é chamado de context drift. Uma poluição do contexto, que ocorre em grandes chats com o mesmo agente.

Cada conversa com um modelo de IA é moldada pela sua janela de contexto: o texto completo de tudo que foi dito até agora na sessão, incluindo seus prompts, as respostas do modelo, quaisquer saídas de ferramentas e as correções que você fez.

Drew Breunig declara que existem quatro motivos pelos quais os contextos se tornam sujos: confusion, clash, distraction, and poisoning. Segundo esses motivos, eu claramente gerei um cenário de confusão para o agente:

O problema é: se você coloca algo no contexto, o modelo precisa prestar atenção nisso. Pode ser informação irrelevante ou definições de ferramentas desnecessárias, mas o modelo vai levar em conta.

Lição: cuidado com o contexto que você cria durante a conversa com a IA. Tudo é dado para ela trazer resposta pra você, inclusive o que deveria ser descartado.

A IA não sabe de tudo

Gosto de trabalhar em pequenos passos durante o desenvolvimento. Então quando fomos implementar o Grafana + Prometheus, fui criando uma coisa de cada vez. Comecei com o endpoint de métricas, subi o Prometheus, vi as métricas no browser, subi o Grafana e verifiquei que conseguia pegar as métricas via query.

Em um determinado momento eu mandei o seguinte prompt: agora vamos criar o dashboard no grafana. O agente simplesmente me respondeu dizendo que não podia criar porque era algo visual, mas me instruiu como eu poderia criar na ferramenta.

Eu não acreditei. E comecei a instigar a IA a me trazer exemplos de como criar um dashboard do Grafana via json e como subir isso direto no volume do docker. Eis que ela me responde de novo que não conseguia fazer isso.

Depois de um período explicando pra ela como funcionavam os volumes do docker e como eu poderia mover arquivos pra dentro dele, conseguimos chegar ao resultado esperado.

O que sofri foi de um conceito de alucinação que o artigo A Survey on Hallucination in Large Language Models: Principles, Taxonomy, Challenges, and Open Questions define como Factual Fabrication (Invenção de Fatos). Quando a IA trás uma resposta como se fosse verdadeira: "não posso fazer isso", mesmo não sendo verdade.

Isso geralmente é causado por algo chamado Knowledge Boundary (Limites de Conhecimento), quando a LLM tem limites no material fonte para seu treinamento, e pode ser causado por falta de acesso a fontes privadas ou memória insuficiente para treinar.

Citando o artigo:

Embora os vastos corpora de pré‑treinamento tenham dotado os LLMs de amplo conhecimento factual, eles possuem, por natureza, limites de conhecimento. [...] Consequentemente, quando os LLMs encontram informações que caem fora desses limites de conhecimento, eles ficam mais suscetíveis a gerar alucinações. [...]

Lição: acho que essa daqui todo mundo sabe, mas é bom destacar, duvide da IA, ela não está certa sobre tudo.

A IA não paga débito técnico

Lá pelas tantas, abri outro chat e pedi para ele escanear o projeto em busca de melhorias, eis que ele me vem com o ponto de que nosso script de deploy estava referenciando muitos arquivos, algo que já estava me incomodando há algum tempo, mas que estava deixando passar. A IA então sugeriu que eu utilizasse arquivos kustomize para facilitar a referência entre os arquivos de configuração.

Algo simples, que podíamos ter feito desde o início, mas que ao utilizar uma abordagem de vibe coding não me questionei como melhorar. A forma como eu fui conduzindo a IA era para ela ir adicionando coisas, não para ir melhorando o que estava lá: adicione o serviço tal no deploy do kubernetes. Eu estava instruindo ela a adicionar coisas, o tempo todo.

A IA tende a introduzir novo código ao invés de refatorar o que já existe, e no meu caso, adicionando feature sobre feature, eu potencializei esse comportamento. O artigo Vibe Code at Scale: Managing Technical Debt When AI Writes Most of Your Codebase cita uma pesquisa que sugere que agentes de IA tendend a introduzir código ao invés de refatorar o que já existe.

[...] A IA gera código totalmente novo em vez de reconhecer e reutilizar padrões existentes. O refatoramento — que é a forma como as equipes mantêm a coerência das bases de código — parou. O resultado é uma base de código que cresce por adição, em vez de por organização.

Lição: a IA não vai melhorar o que você já tem, a menos que explicitamente você peça por isso.

Revise todo o código feito

Em vários momentos eu tive o seguinte problema: IA fazia alguma coisa, eu desfazia, na passada seguinte ela fazia de novo. Em geral os editores embutidos de IA guardam contexto dos arquivos para facilitar o processamento, quando a IA alterar um arquivo ela guarda esse novo contexto do arquivo. Na próxima vez que ela for editar aquele arquivo ela compara com a versão em contexto e aplica de novo.

Isso me deu várias dores de cabeça. Porque eu tinha que ficar constantemente revisando tudo que ela fazia. O que me ajudou bastante foi fazer as coisas passo a passo, quando algo estava funcionando eu fazia um commit (e depois um amend) ou apenas adicionava ao staged. Quando ela fazia algo errado eu conseguia comparar exatamente o que ela fez e dar um revert, ou editar, o que achava pertinente.

Debt Behind the AI Boom: A Large-Scale Empirical Study of AI-Generated Code in the Wild é um estudo em cima de mais de 6000 repositórios no GitHub, identificando e analisando código gerado por IA. Um achado muito importante é que o código produzido pelos agentes era composto por 89% de code smells, além de bugs e problemas de segurança.

[...] Isso sugere que o risco de qualidade é uma questão sistêmica no modo atual de desenvolvimento assistido por IA. Assim, desenvolvedores e equipes devem revisar cuidadosamente o código gerado por IA, independentemente da ferramenta utilizada. Análise estática, testes e verificações de segurança devem fazer parte do fluxo de trabalho normal. A revisão de código deve se estender além do ponto de merge. [...]

Dado isto, outro artigo que vale citar é o Git Guardian: Why Version Control is Non-Negotiable in Vibe Coding, que traz boas práticas de como utilizar versionamento para trabalhar de forma defensiva quando em vibe coding.

• Commit após os testes passarem: só faça commit de código quando todos os testes estiverem passando
• Branch para funcionalidades: crie branches separadas para novas funcionalidades importantes
• Reverter com confiança: não hesite em voltar para versões anteriores quando necessário
• Revisar diffs: examine o que mudou entre versões para entender melhor a abordagem da IA

Lição: mantenha seu código versionado e revise tudo que a IA faz. Trabalhe em baby steps quando estiver fazendo vibe code.

A IA tem limites

A situação que mais me incomodou, e que perdi umas 3 horas pra resolver, foi quando eu tentei adicionar uma métrica de negócio como gatilho de um HPA. A IA simplesmente não sabia como fazer isso.

Fui procurar na internet como se fazia isso. E pra minha surpresa eu não encontrei nada que pudesse me responder.

Juntei umas referências aqui, outras ali, e dei pra IA um contexto sobre o que eu tinha encontrado, e como aqui poderia nos ajudar. Depois de muita tentativa e erro, conseguimos fazer funcionar, o que pra mim foi uma grande vitória.

Foi um cenário parecido com o que tive com o dashboard do Grafana, mas a diferença aqui é que de fato a informação não existia na internet. Não havia um exemplo de como fazer isso. Havia conhecimentos dispersos que juntei para chegar ao meu objetivo.

Isso é chamado de Zero-Shot no artigo Language Models are Few-Shot Learners. Quando a LLM não tem exemplo nenhum para chegar a resposta esperada.

[No] Zero-Shot (0S) [...] o modelo recebe apenas uma instrução em linguagem natural descrevendo a tarefa. [...] É o cenário mais desafiador. Em alguns casos pode ser até difícil para humanos entenderem o formato da tarefa sem exemplos prévios, tornando esse cenário “injustamente difícil”. [...]

Lição: se a resposta não tá na internet, a IA não vai saber te responder.

Conclusão

De forma geral gostei muito de fazer esse estudo assistido. Eu já tinha usado IA para várias coisas, de desenvolvimento a bate-papo de arquitetura. Mas é a primeira vez que uso para estudar algo. No começo fiquei receoso de que não fosse aprender no processo. Mas aprendi tudo que esperava, e até um pouco mais.

Além disso, aprendi muito mais sobre como utilizar IA para trabalhar. Assim como compondo esse artigo, busquei bastante conteúdo para corroborar meu ponto de vista. Aprendendo tanto no processo de estudo quanto no processo de compartilhar o conhecimento.

Pra finalizar, algo que me ajudou bastante a validar meu conhecimento, foi abrir três IAs diferentes e pedir para elas fazerem um quiz sobre kubernetes pra mim. Acertei a maioria das questões, e repeti os testes mais algumas vezes.