# 🤖 A IA escreve o código. Quem responde por ele é você

 # 🤖 A IA escreve o código. Quem responde por ele é você


Quem nunca ouviu (ou pensou) algo assim: "agora que a IA gera o código, qualquer pessoa consegue programar e fundamentos já não importam tanto"?

É um mito tentador. E, na prática, quase sempre é o contrário. 😅

A IA acelera muito o trabalho de quem sabe aonde quer chegar. Para quem não sabe, ela só acelera a chegada no lugar errado.

Neste artigo, vamos conversar sobre por que o profissional que investiu em **fundamentos** e entendeu **o negócio** ganha ainda mais valor na era da IA, e como usar isso para entregar rápido sem abrir mão de segurança, padrão e qualidade.

---

## 🚗 Copiloto não dirige sozinho

Gosto de pensar na IA como um estagiário brilhante e incansável: escreve rápido, conhece muita coisa, nunca reclama de pedir "só mais um ajuste"... e responde com a **mesma confiança** quando acerta e quando erra.

Esse último detalhe é o ponto principal. O código gerado quase sempre **compila**, **roda** e **parece certo**. Mas parecer certo não é estar certo.

Alguém precisa:

- entender o que foi gerado;
- dizer "isso está bom";
- ou dizer "isso aqui não vai passar".

Essa pessoa é quem dá segurança ao time. E ela só consegue fazer isso se tiver base.

---

## 🧱 Onde os fundamentos viram superpoder

Eu uso IA para programar e gosto muito. Mas percebo que o que me permite **guiar, aprovar ou reprovar** o resultado vem de três frentes:

| Frente | O que ela me permite avaliar |
|---|---|
| **Fundamentos técnicos** | Estruturas de dados, concorrência, comportamento da JVM, tratamento de erros, complexidade |
| **Segurança e padrões** | Validação de entrada, injeção de SQL, dados sensíveis, padrões e arquitetura do time |
| **Negócio** | Se a regra implementada é mesmo a regra que o cliente precisa (e não só uma regra "plausível") |

Sem isso, o código vira uma caixa-preta que a gente só espera que funcione. Com isso, a IA vira ferramenta, e não aposta.

---

## 🔍 Exemplo 1: funciona, mas tem falha de segurança

Imagine que você pede à IA: "busque um cliente pelo e-mail". Um resultado comum é este:

```java
String sql = "SELECT * FROM clientes WHERE email = '" + email + "'";
Statement st = conn.createStatement();
ResultSet rs = st.executeQuery(sql);
```

Roda. Passa no teste feliz. E está vulnerável a **SQL Injection**, porque a entrada do usuário vira parte do comando.

Quem tem fundamentos reconhece o problema na hora e pede (ou ajusta) algo assim:

```java
String sql = "SELECT * FROM clientes WHERE email = ?";
try (PreparedStatement ps = conn.prepareStatement(sql)) {
    ps.setString(1, email);
    try (ResultSet rs = ps.executeQuery()) {
        // processar o resultado
    }
}
```

✔️ Parâmetros separados do comando e recursos fechados corretamente.

---

## 💰 Exemplo 2: o bug que o teste feliz não pega

Agora uma regra de negócio simples: calcular o total de um pedido com desconto.

```java
double total = preco * quantidade * (1 - desconto);
```

Parece inofensivo. Mas, para dinheiro, `double` acumula imprecisão (o clássico `0.1 + 0.2`) e o arredondamento passa despercebido. Uma versão mais segura:

```java
BigDecimal total = preco
        .multiply(BigDecimal.valueOf(quantidade))
        .multiply(BigDecimal.ONE.subtract(desconto))
        .setScale(2, RoundingMode.HALF_UP); // a regra de arredondamento vem do negócio!
```

✔️ Repare no comentário: o **modo de arredondamento é decisão de negócio**, não detalhe técnico. Só quem entende o domínio sabe qual usar. A IA vai chutar um. Você precisa saber se é o correto.

---

## ✅ Meu checklist para revisar código gerado por IA

Antes de aprovar, eu me pergunto:

1. **Entendi o que esse código faz?** Se não consigo explicar para um colega, não entra.
2. **E a segurança?** Entradas validadas, segredos fora do código, nada de dado sensível em log.
3. **A regra de negócio está certa?** Confiro com a especificação, não com a "cara" do código.
4. **Segue o padrão do time?** Nomenclatura, camadas, tratamento de erros, estilo.
5. **Os testes cobrem os casos de borda?** Nulos, listas vazias, valores limites, falhas externas.
6. **As dependências existem e são confiáveis?** A IA às vezes sugere bibliotecas ou métodos que não existem ou estão desatualizados.
7. **Tem risco de performance ou concorrência?** Loops pesados, consultas repetidas, estado compartilhado.

---

## 🛠️ Exercício prático

Peça à sua IA favorita para gerar um serviço simples de cálculo de pedido com desconto e consulta de cliente por e-mail. Depois, **revise como se fosse code review de um colega**:

- Use o checklist acima.
- Anote tudo que você aprovaria, ajustaria e reprovaria.
- Reescreva os trechos problemáticos e compare.

Você vai perceber quanto da qualidade vem de **quem revisa**, não de quem digitou. 😉

---

## 📚 Conclusão

A IA não tira o valor do desenvolvedor. Ela **muda onde está o valor**: sai de digitar código e vai para **entender, direcionar e garantir** o resultado.

Quem investe em fundamentos e no entendimento do negócio consegue usar a IA com velocidade e com segurança, e passa tranquilidade para o time inteiro. Esse é o profissional que eu quero ser, e que a gente pode construir junto.

Se esse conteúdo fez sentido para você, compartilhe com outros devs. E me conta nos comentários: **qual foi o pior (ou melhor) código gerado por IA que você já revisou?** Quero ler! 🚀

Comentários

Postagens mais visitadas deste blog

👷‍♂️ Código em Construção: Começando do Começo

O Motor Secreto da JVM — Entendendo o Compilador JIT

🎭 Polimorfismo em Java: Deixe Seu Código Mais Flexível