# Como usar IA para aprender Java sem pular os fundamentos
Aprenda a revisar código sugerido por IA, testar falhas e adaptar uma solução em Java para entender a regra antes de depender do código pronto.
Por Bruno Rana
Publicado em: 2026-10-22
Atualizado em: 2026-11-04
Artigo original: https://buildrun.com.br/blog/java-junior-ia-sem-pular-fundamentos/
A recusa ao reabrir uma tarefa concluída preserva o estado CONCLUIDA.
A IA pode ajudar você a estudar Java, mas uma resposta que parece clara não mostra, sozinha, o que você aprendeu. A dúvida costuma aparecer depois: ao tentar mudar uma regra ou explicar uma falha, você percebe que ainda não sabe por onde começar.
Você não precisa abrir mão dessa ajuda. Precisa de uma forma de conferir o próprio entendimento enquanto a usa. Explicar o comportamento esperado, testar o que deve ser recusado e revisar o efeito de uma alteração são práticas que tornam esse aprendizado visível.
Vamos trabalhar essas três etapas com calma. A sintaxe que você não lembrar pode ser consultada; o que merece sua atenção é a relação entre a regra, as instruções do programa e o resultado que consegue observar.
## Defina o comportamento antes de pedir a implementação
Antes de pedir código, descreva o que deve acontecer com os dados. Isso cria uma referência que você pode usar para avaliar qualquer implementação, venha ela da IA ou de uma tentativa sua.
Neste exercício, uma tarefa pode ser concluída, mas não pode ser reaberta depois disso. A recusa deve preservar o estado: lançar uma exceção e deixar a tarefa aberta ainda seria descumprir a regra. O comportamento esperado é este:
| Estado inicial | Operação | Resultado esperado |
| --- | --- | --- |
| `ABERTA` | Concluir | Passa para `CONCLUIDA`. |
| `CONCLUIDA` | Concluir novamente | Permanece concluída, sem erro. |
| `ABERTA` | Reabrir | Permanece aberta, sem mudança. |
| `CONCLUIDA` | Reabrir | Operação recusada; continua concluída. |
Escrever a última coluna primeiro dá uma referência independente da resposta da IA. Se o programa se comportar de outra forma, você terá o que investigar em vez de aceitar a saída só porque ela apareceu na tela.
Tente implementar a regra em memória, sem servidor nem banco. Não precisa lembrar toda a sintaxe: consulte a documentação de Java quando necessário. Nesse primeiro passo, a pergunta é onde verificar a regra e em que momento alterar o estado.
## Use a IA para investigar uma hipótese
Depois de tentar implementar a regra, suponha que você encontre uma falha: reabrir a tarefa lança a exceção esperada, mas uma consulta ao objeto mostra que ele ficou aberto. É uma dúvida específica que você pode levar à IA:
Use a sugestão para orientar uma verificação observável com dados fictícios.
> Minha tarefa concluída não pode ser reaberta. A operação lança uma exceção, mas o objeto termina aberto. Sem reescrever a classe, sugira uma hipótese sobre a ordem das operações e um teste que revele o problema.
A hipótese a verificar é simples: a atribuição pode estar acontecendo antes da validação. Leia o método ou pare a execução no depurador, ferramenta que permite acompanhar o programa passo a passo. Confira o estado antes da tentativa, a ordem das instruções e o estado após a recusa.
Use uma reprodução com dados fictícios. Não envie credenciais, dados de clientes ou código que não está autorizado a compartilhar. Se a sugestão trouxer uma API desconhecida, confira a documentação da versão usada antes de adotá-la.
## Revise a mudança e teste o efeito sobre os dados
Leia o *diff*, a comparação entre a versão anterior e a alterada. A correção deve responder à regra definida: validar antes de mudar o estado. Dependências novas, remoção de validações e alterações em outros comportamentos precisam de uma justificativa própria.
A verificação precisa confirmar que a tarefa segue concluída depois da recusa.
Verificar apenas se houve exceção não basta. O teste também precisa conferir que a tarefa continua concluída. Veja uma implementação mínima; salve como `TarefaDemo.java` e execute `java TarefaDemo.java` com Java 21:
```java
public class TarefaDemo {
enum Status { ABERTA, CONCLUIDA }
static class Tarefa {
private Status status = Status.ABERTA;
Status status() { return status; }
void concluir() { status = Status.CONCLUIDA; }
void reabrir() {
if (status == Status.CONCLUIDA) {
throw new IllegalStateException("Tarefa concluida");
}
status = Status.ABERTA;
}
}
static void conferir(boolean condicao) {
if (!condicao) throw new AssertionError("Regra violada");
}
public static void main(String[] args) {
var tarefa = new Tarefa();
tarefa.reabrir();
conferir(tarefa.status() == Status.ABERTA);
tarefa.concluir();
conferir(tarefa.status() == Status.CONCLUIDA);
tarefa.concluir();
conferir(tarefa.status() == Status.CONCLUIDA);
boolean recusou = false;
try { tarefa.reabrir(); }
catch (IllegalStateException erro) { recusou = true; }
conferir(recusou && tarefa.status() == Status.CONCLUIDA);
System.out.println(tarefa.status()); // CONCLUIDA
}
}
```
O programa representa o estado com um `enum` e concentra a alteração dentro de `Tarefa`. O método `conferir` interrompe a execução se uma expectativa falhar, sem exigir uma biblioteca de testes neste primeiro exercício.
Agora tente duas alterações incorretas, uma de cada vez: mover a atribuição de `ABERTA` para antes do `if`; depois, restaurar o código e remover a validação. A verificação deve falhar nos dois casos. Essa experiência mostra que o teste protege a regra, em vez de apenas repetir a implementação.
## Mude o requisito sem pedir a solução inteira
Feche a conversa com a IA e explique por que a validação vem antes da atribuição. Depois acrescente um estado `CANCELADA`: uma tarefa só pode ser cancelada enquanto está aberta.
Antes do código, amplie a tabela. Decida o que acontece ao tentar concluir, reabrir ou cancelar uma tarefa já cancelada. Não deixe a ferramenta escolher essas regras por você. Implemente a mudança e repita os casos anteriores para conferir que a nova operação não quebrou a conclusão e a recusa de reabertura.
Se travar, leve à IA a regra, a tentativa e a divergência encontrada. Pedir uma pista específica mantém a decisão com você. Pedir novamente o projeto inteiro torna mais difícil perceber qual parte ainda não compreendeu.
## O que muda quando essa tarefa vira uma API
O exercício acima verifica um objeto em memória. Ao acrescentar HTTP e banco, surgem responsabilidades que precisam de testes próprios:
* **Entrada e resposta:** o cliente deve distinguir uma tarefa inexistente de uma tentativa proibida.
* **Persistência:** após a recusa, uma nova leitura do banco deve continuar mostrando a tarefa concluída.
* **Acesso:** uma pessoa não deve alterar tarefas de outra sem permissão.
* **Concorrência:** duas requisições simultâneas podem exigir controle adicional; validar um objeto isolado não resolve esse problema.
Implemente uma camada por vez e preserve os testes da regra. Se também passar a gravar um histórico, estude como uma [transação](https://www.postgresql.org/docs/current/tutorial-transactions.html) pode confirmar ou desfazer as gravações em conjunto. Esse será outro incremento, não uma capacidade do programa mostrado.
## Como avaliar o que aprendeu
Ao terminar, tente explicar a regra sem ler a resposta da IA, demonstrar um teste que detecta o defeito e modificar uma condição sem reconstruir tudo. Se só consegue repetir a explicação da ferramenta, volte à execução e acompanhe os dados.
Quando não conseguir distinguir hipóteses, peça revisão humana levando a tabela, o código mínimo e os resultados. Isso permite discutir uma dúvida concreta, inclusive o que ainda não foi testado.
Consulte o [material oficial de Java](https://dev.java/learn/) para objetos, coleções e exceções, e o [guia REST do Spring](https://spring.io/guides/gs/rest-service/) quando avançar para HTTP. As referências foram consultadas em 22/10/2026; registre as versões usadas no seu projeto.
Se faltou base para acompanhar o exercício, veja [o que estudar antes de Spring Boot](https://buildrun.com.br/blog/o-que-estudar-antes-spring-boot/). Para conhecer a sequência de conteúdos e projetos da Build & Run, consulte os [cursos da formação](https://buildrun.com.br/blog/formacao-buildrun/) e compare com a dificuldade que apareceu na sua tentativa.
