Escrevendo SQL com IA sem confiar cego no resultado

Pedir SQL para a IA é uma das coisas em que ela mais impressiona: você descreve em português o que quer, e sai uma query pronta em segundos. O problema é que SQL tem uma armadilha cruel — uma query errada não dá erro. Ela roda lindamente e te devolve o número errado. E aí você toma decisão em cima de um dado furado sem nem desconfiar.

Uso IA para escrever SQL o tempo todo. Mas com um método, porque já tomei susto. Aqui está como aproveitar a velocidade sem cair na cilada.

1. Dê o schema. Sem ele, é chute educado

A IA não conhece as suas tabelas. Se você só pede "me dá o total de vendas por mês", ela adivinha nomes de tabela e coluna — e adivinha errado. Cole o schema: nomes de tabelas, colunas e, principalmente, como elas se relacionam (as chaves). Com o schema real, a query sai utilizável. Sem ele, sai ficção plausível.

Vale colar junto duas informações que quase ninguém lembra e que mudam o resultado: o dialeto (PostgreSQL, MySQL, BigQuery e SQL Server divergem justamente em função de data, que é onde mais se erra) e as convenções sujas do seu banco. Coisas do tipo "a coluna status usa 'A' para ativo, não 'ativo'", ou "pedidos cancelados continuam na tabela, com deleted_at preenchido". Essa segunda categoria é responsável por boa parte dos números errados — e é invisível no schema.

2. Desconfie de JOIN e de duplicação

O erro campeão de SQL gerado por IA é o JOIN que multiplica linhas. Você pede o total de vendas, ela faz um join com uma tabela que tem várias linhas por venda, e de repente seu total está inflado 3x — sem nenhum aviso. O número aparece, parece razoável, e está errado.

SQL não avisa quando está errado. Ele te entrega o número errado com a mesma cara de quem entrega o certo.

Sempre que houver JOIN, faça uma checagem: o número de linhas bate com o que você esperava? Um COUNT antes e depois do join denuncia a duplicação na hora.

Um primo próximo desse erro é o LEFT JOIN com filtro no WHERE. Você pediu "todos os clientes, com as compras de julho se houver", a IA escreveu o LEFT JOIN certinho e depois colocou WHERE compras.data >= '2026-07-01' — o que silenciosamente transforma o LEFT em INNER e some com todo cliente que não comprou. A query roda, o número sai menor, e a explicação parece perfeita. O filtro precisava estar na cláusula ON, não no WHERE.

3. Valide com um caso que você já conhece

Esta é a técnica que mais me salvou: antes de confiar na query, rode ela para um caso cujo resultado você já sabe. "As vendas do cliente X em maio foram R$ 4.200 — a query devolve isso?" Se bate no caso conhecido, você ganha confiança para o resto. Se não bate, você acabou de evitar um relatório inteiro errado.

Duas variações que valem o esforço. A primeira: teste o caso-limite, não só o caso típico — o cliente que cancelou e recomprou, o pedido no dia 1º do mês, o registro sem valor preenchido. É lá que a lógica quebra. A segunda: confira se o total fecha. Se você quebrou vendas por categoria, a soma das categorias tem que dar o total geral. Quando não dá, ou você duplicou linha ou perdeu linha — e as duas coisas são graves.

4. Peça a IA para explicar a própria query

Depois de gerar o SQL, peça: "explica em português o que essa query faz, linha por linha, e quais premissas ela assume". Duas coisas acontecem. Primeiro, você entende o que vai rodar (e às vezes percebe que ela filtrou algo que não devia). Segundo, a própria IA às vezes percebe o próprio erro ao ter que explicar — é impressionante como "explique seu raciocínio" melhora a resposta.

A pergunta que mais rende, porém, é outra: "quais premissas essa query assume que podem estar erradas no meu banco?". A resposta vem em forma de lista de riscos — "assumi que cada pedido tem um único pagamento", "assumi que valor já está líquido de desconto" — e cada item é algo que você consegue conferir em trinta segundos. É a forma mais barata de revisão que existe.

5. Cuidado redobrado com números que viram decisão

Nem toda query tem o mesmo peso. Uma consulta exploratória para você "dar uma olhada" pode ser aproximada. Mas um número que vai para um relatório de diretoria, para o cálculo de comissão ou para decidir orçamento — esse precisa de conferência dobrada. Regra prática: quanto mais consequência tem o número, mais você valida a query que o produziu.

Para essa categoria, vale um passo extra: escrever a mesma pergunta de duas formas diferentes (por exemplo, uma com JOIN e outra com subconsulta) e comparar. Se os dois caminhos independentes chegam ao mesmo número, sua confiança sobe muito. Se divergem, você achou um problema que teria descoberto na reunião, na frente de todo mundo.

6. Nunca deixe a IA escrever direto no banco

Um ponto de segurança que precisa ser dito. Query gerada por IA é para leitura. UPDATE, DELETE e ALTER gerados automaticamente e rodados sem revisão são a receita para um incidente — um DELETE sem WHERE não pede confirmação. Use um usuário de banco só-leitura para o trabalho de análise. É a proteção mais barata que existe e evita a categoria inteira de erro em que não tem desfazer.

O que a IA faz muito bem em SQL

Para não parecer que estou só desconfiando: a IA é excelente em SQL para várias coisas. Lembrar a sintaxe daquela função de data que você sempre esquece. Traduzir uma query de um banco para outro. Otimizar uma consulta lenta e te explicar por que estava lenta — inclusive lendo o plano de execução, que é um texto que quase ninguém tem paciência de decifrar. Escrever o esqueleto de uma query complexa que você só ajusta. Documentar uma query legada de 200 linhas que ninguém entende mais. Nessas, ela economiza tempo real e raramente erra feio.

Repare no padrão: ela é ótima quando o critério de acerto é verificável na hora (a sintaxe funciona ou não funciona) e arriscada quando o critério é o número estar certo — porque aí não tem como o computador te avisar. Saber de que lado dessa linha está a sua tarefa é metade do trabalho.

Conclusão: velocidade da IA, responsabilidade sua

A IA transforma "vou levar 20 minutos montando esse SQL" em "tenho a query em 20 segundos". Isso é ganho de verdade. Mas o número que sai dela vira sua decisão, com o seu nome. Dê o schema com as convenções sujas, desconfie dos JOINs, valide com um caso conhecido, confira se o total fecha e peça a explicação das premissas. Faça isso e você tem o melhor dos dois mundos: a rapidez da IA com a segurança de quem não decide em cima de dado furado.