Como ter mentalidade colaborativa com a IA (e como isso me ajudou a construir o Quita)

Durante o curso de Fundamentos de IA do Google, cheguei num tema que parece simples, mas muda completamente a forma como você trabalha com inteligência artificial no dia a dia: mentalidade colaborativa.

Tratar a IA como parceira de desenvolvimento significa entregar contexto, direção e feedback técnico pra receber algo útil de volta, do jeito que um colega júnior de time precisaria de orientação clara pra entregar um trabalho bom.

Foi construindo o Quita, minha ferramenta que ajuda pessoas a interpretarem relatórios de crédito do Banco Central (Registrato) e gerarem reclamações automáticas no Consumidor.gov.br, que entendi isso na prática, em cima de decisões técnicas reais de arquitetura, backend e integração com IA. Quero compartilhar o que aprendi, com foco maior em como especificar melhor e em como usei a colaboração com a IA como parte do meu próprio aprendizado técnico.

O problema de conversar mal com a IA

Muita gente trata a IA como um oráculo: pergunta pouco, espera muito, e se frustra quando a resposta vem genérica, incompleta ou simplesmente errada. O erro geralmente não está na ferramenta, está na forma como a conversa foi conduzida.

Quando comecei a desenvolver o Quita, percebi que quanto mais eu jogava perguntas soltas pra IA, mais eu recebia respostas soltas de volta. O ponto de virada foi entender que colaborar com IA é um processo de duas mãos: eu preciso trazer clareza técnica, e só assim a IA consegue trazer precisão.

Visão clara do que o sistema precisa fazer

Antes de pedir qualquer linha de código, eu precisava conseguir descrever o fluxo de dados do Quita em termos técnicos, não em termos de pitch. O sistema recebe um payload de consulta do Registrato, precisa normalizar esses dados num formato interno consistente, identificar inconsistências entre os valores reportados por diferentes instituições, e gerar um texto estruturado que siga o schema aceito pelo Consumidor.gov.br.

Quando descrevo esse fluxo assim, com entrada, transformação e saída bem definidas, a IA para de preencher lacunas com suposições e começa a propor soluções dentro dos limites reais do sistema. Especificação vaga gera código genérico. Especificação técnica, com fluxo de dados explícito, gera solução alinhada com a arquitetura que já existe.

Público definido também é um requisito técnico

O Quita é usado por pessoas que não têm familiaridade com jargão financeiro ou jurídico. Isso parece um detalhe de UX, mas na prática vira requisito técnico: as mensagens de erro da API, os textos gerados pela IA nas reclamações, e até a estrutura das respostas JSON que o frontend consome precisam carregar esse cuidado.

Quando informo isso explicitamente pra IA nos prompts (por exemplo, ao pedir a estrutura de um endpoint que retorna o resultado da análise de crédito), as sugestões de nomenclatura de campos, mensagens de validação e formato de resposta mudam. Público bem definido funciona como um filtro que reduz o espaço de interpretação da IA em cada camada do sistema, do banco de dados até a interface.

Problema bem delimitado é o que mais reduz alucinação

Esse é o ponto central que eu já intuía antes mesmo do curso confirmar: quanto mais delimitado o problema, menos espaço a IA tem para inventar solução.

Pedir "ajuda a melhorar meu sistema de crédito" é vago demais. A IA vai preencher as lacunas com suposições, e suposições geram alucinação. Pedir "a partir do JSON retornado pela consulta do Registrato, com os campos que já defini no meu DTO, o sistema precisa identificar inconsistências entre valores reportados por diferentes instituições e gerar um texto de reclamação seguindo a estrutura aceita pelo Consumidor.gov.br" é um problema com bordas claras: entrada conhecida, regra de comparação explícita, saída num formato definido. A IA não tem motivo pra inventar nada, porque o espaço de resposta já está desenhado pela especificação.

Saber o básico da stack técnica não é opcional

Esse é um aprendizado que só veio com a prática: colaborar bem com a IA exige que eu também entenda, ainda que no básico, cada peça do que estou construindo. Sem isso, não dá pra avaliar se a resposta que recebi está certa, nem pra pedir algo mais específico na próxima rodada.

A arquitetura do Quita hoje é essa: backend em Java 21 com Spring Boot e Spring Security pra autenticação via JWT, banco PostgreSQL com Flyway controlando as migrations, tudo rodando em produção no Railway. O frontend é Next.js com TypeScript e Tailwind, publicado na Vercel, consumindo a API via chamadas autenticadas. A camada de IA (Gemini e OpenAI) entra como serviço interno do backend, recebendo os dados já normalizados do relatório de crédito e devolvendo o texto estruturado da reclamação.

Entender essa arquitetura, mesmo que no nível de "o que conversa com o quê", foi o que me deu autonomia pra identificar erros da IA em vez de aceitá-los. Alguns exemplos concretos:

• Ao configurar CORS entre o frontend na Vercel e o backend no Railway, recebi sugestões de configuração que liberavam origem * junto com credentials: true, uma combinação que o próprio navegador rejeita. Só percebi o problema porque já sabia como o CORS trata essa combinação.


• Numa sugestão de migration do Flyway, a IA propôs alterar uma coluna sem considerar dados já existentes na tabela em produção, o que quebraria o deploy. Entender como o Flyway versiona e aplica migrations foi o que me fez revisar antes de rodar.


• Em uma integração com a API do Gemini, recebi um exemplo de código usando um parâmetro de um SDK desatualizado. Sem conhecer o básico de como a chamada deveria se estruturar, eu teria copiado e colado sem perceber que aquilo não compilaria.

Nenhum desses casos exigiu expertise profunda. Exigiu o suficiente pra desconfiar, testar e perguntar de novo. É esse "suficiente" que a mentalidade colaborativa pressupõe: você não precisa saber tudo, mas precisa saber o bastante pra não aceitar qualquer resposta só porque ela parece coerente.

Isso também muda a qualidade da pergunta que eu faço. Entender o básico de autenticação me leva a perguntar "como validar esse token JWT no middleware do Next.js sem quebrar o server-side rendering", em vez de simplesmente "como fazer login". Pergunta mais específica gera resposta mais específica, e resposta mais específica tem menos espaço pra alucinação.

Contexto de negócio e regras externas também blindam contra alucinação

Não é só código. O Quita opera sobre regras que vêm de fora: o formato de dados do Bacen, as exigências de estrutura do Consumidor.gov.br. Quando trago essas regras explicitamente pra conversa com a IA, e não só o requisito técnico, a chance de receber uma solução tecnicamente correta, mas inútil na prática, cai bastante.

Colaborar com a IA como forma de aprender enquanto desenvolve

Esse foi o aprendizado mais valioso do processo todo: a mentalidade colaborativa pode ser usada deliberadamente para aprender, não só pra produzir mais rápido.

Existe uma diferença técnica relevante entre pedir "implemente a validação do token JWT" e pedir "explique como funciona a validação de um JWT nesse middleware, e só depois implemente". A primeira forma entrega uma solução pronta pra colar. A segunda entrega o raciocínio por trás dela, o que me permite manter, depurar e estender aquele código sozinho depois, sem depender de voltar pra IA a cada ajuste.

Foi assim que aprendi, construindo o Quita, coisas que fui aplicando direto na arquitetura:

• Por que o Flyway versiona migrations de forma sequencial e imutável, e por que alterar uma migration já aplicada em produção é considerado prática ruim, o que mudou como eu planejo alterações de schema.


• Por que um access token JWT de vida curta é combinado com um refresh token de vida mais longa, e como isso equilibra segurança e experiência do usuário sem exigir login constante.


• Por que o navegador aplica a política de mesma origem e quando exatamente o CORS entra em ação, o que resolveu de vez os erros recorrentes na integração entre a Vercel e o Railway.


• Como estruturar prompts pra API do Gemini de forma a obter uma saída em JSON consistente, o que exigiu entender um pouco de como o modelo lida com formatação estruturada versus texto livre.

Cada um desses pontos começou como um problema prático do Quita e virou conhecimento que eu carrego pra próxima decisão técnica, mesmo fora do projeto. Isso cria um ciclo: quanto mais eu entendo, melhor formulo a próxima pergunta; quanto melhor a pergunta, mais precisa a resposta; e quanto mais precisa a resposta, mais eu aprendo com ela.

O risco desse processo é aprender de forma rasa, aceitando o código sem entender por que ele funciona. A forma como me protejo disso é simples: antes de aceitar qualquer solução mais complexa, peço pra IA explicar o "porquê" da abordagem escolhida, não só o "como" implementar. Se a explicação não faz sentido pra mim, é sinal de que preciso entender melhor o conceito antes de colocar aquele código em produção.

Iteração faz parte do processo, não é sinal de erro

O design system do Quita, o conceito "Da névoa à rota", com glassmorphism e verde floresta como cor primária, não nasceu pronto. Passou por várias rodadas de ajuste com a IA, cada uma refinando um pouco mais a identidade visual. Entender que a primeira resposta é só um rascunho, não a entrega final, tirou a pressão de "acertar de primeira" e trouxe mais qualidade pro resultado.

Você continua no controle

Colaborar não é delegar cegamente. Cada sugestão de código, cada texto gerado, cada decisão de design que a IA propôs pro Quita passou por revisão minha antes de ir pra produção. A IA acelera o processo, mas a responsabilidade pelo resultado final continua sendo do desenvolvedor.

Mentalidade colaborativa como método de trabalho

No fim, o que aprendi construindo o Quita é que colaborar com IA se parece com orientar um colega júnior talentoso, mas que não conhece o seu contexto: é preciso trazer especificação clara, público, problema delimitado, arquitetura real e um mínimo de conhecimento técnico pra reconhecer quando algo sai fora do esperado. Em troca, o ganho não é só velocidade de entrega, é aprendizado técnico acumulado a cada rodada de conversa.

O Quita está em produção hoje porque cada uma dessas peças, especificação técnica clara, público definido, problema delimitado, arquitetura explícita, revisão humana e aprendizado contínuo, trabalhou junto. Não porque pedi pra IA "criar um sistema de análise de crédito" e recebi de volta uma solução pronta.