Sou dev Java júnior: como usar IA sem pular os fundamentos?

Você pode usar IA enquanto aprende Java. O cuidado é conferir se consegue explicar, testar e alterar o código que recebeu. Pense na última sugestão que você aceitou: se o requisito mudasse agora, você saberia por onde começar? Essa pergunta ajuda a perceber o que aprendeu e o que ainda precisa estudar.

Vamos trabalhar com uma regra pequena. Você tenta implementá-la, pede ajuda em uma dificuldade específica e confere o resultado. Assim, a conversa com a IA acompanha o seu raciocínio e deixa espaço para você tomar as decisões.

A dificuldade aparece quando o código funciona, mas você ainda não sabe explicar por quê. Se você já executa um programa ou uma API simples, este guia ajuda a usar essa dúvida como ponto de partida para estudar.

Como saber se estou aprendendo ou apenas copiando?

Separe três resultados que costumam ser confundidos:

Resultado	Evidência que você pode produzir
Fazer funcionar	Executar uma entrada conhecida e observar a saída esperada.
Entender	Seguir os dados da entrada à resposta, apontando a regra e a alteração de estado.
Modificar	Mudar um requisito, localizar os pontos afetados e preservar os comportamentos anteriores.

Imagine um cadastro de tarefas com os estados ABERTA e CONCLUIDA. Agora a regra determina que uma tarefa concluída não pode ser reaberta. Você consegue encontrar onde essa decisão acontece? Consegue demonstrar que uma tentativa recusada deixa o registro intacto?

Você não precisa lembrar toda a sintaxe para fazer isso. Pode consultar a documentação. O que vale observar é se consegue dizer “acho que o erro está aqui, por este motivo” e conferir a hipótese. Se ainda só consegue repetir a explicação da ferramenta, acompanhe uma execução com o depurador: pare antes da mudança de status e veja o valor do objeto antes e depois.

O que um CRUD sozinho não demonstra sobre sua base Java

CRUD reúne criação, leitura, atualização e exclusão. É um laboratório útil, mas quatro endpoints funcionando não mostram como você lida com as decisões ao redor deles.

Fundamento	Pergunta para fazer no seu próprio projeto
Objetos e estado	Duas tarefas compartilham acidentalmente o mesmo objeto? Quem pode mudar o status?
HTTP	Onde estão identificador, corpo e resposta? O cliente distingue recurso ausente de operação recusada?
Validação e regras	A regra vale quando a chamada não passa pela tela original?
Persistência	A mudança sobrevive ao reinício? Em que momento é gravada?
Transações	Se a operação também registra um histórico, o que acontece se só uma gravação funciona?
Testes e falhas	O teste verifica o estado após uma recusa ou apenas a resposta?

No exemplo do histórico, uma transação pode reunir alterações para que sejam confirmadas ou desfeitas juntas. A introdução a transações do PostgreSQL explica essa propriedade. Ela não resolve automaticamente toda disputa entre requisições simultâneas: concorrência exige decisões adicionais conforme a implementação.

Escolha uma lacuna por exercício. Você pode estudar a regra em memória antes de adicionar HTTP e banco. Introduzir todas as camadas de uma vez dificulta descobrir qual conceito provocou a falha.

Como estudar com IA sem perder o raciocínio

1. Escreva o requisito e faça uma tentativa

Registre entrada, estado inicial e resultado esperado antes do prompt. Para a tarefa concluída: a tentativa de reabrir deve ser recusada e o status deve continuar CONCLUIDA. Assim, você sabe o que espera antes de ler a solução sugerida.

Faça a menor tentativa que conseguir. Se houver erro, reduza o exemplo e registre a mensagem relevante. Use dados fictícios; não envie chaves, credenciais, informações de clientes ou código que você não está autorizado a compartilhar.

2. Peça uma pista que possa ser verificada

Um pedido útil seria:

Tenho uma tarefa concluída. Minha tentativa de reabertura é recusada, mas o objeto já foi alterado. Quero entender a ordem das operações. Sem reescrever a classe inteira, sugira uma hipótese e um teste que revele o problema.

Esse pedido dá à ferramenta um problema delimitado. Você continua responsável por abrir o código e procurar a ordem das operações. Se a resposta mencionar uma API que você não conhece, consulte a documentação da versão usada antes de adotá-la.

3. Leia o diff antes de executar

Procure mudanças além da regra pedida: dependências novas, tratamento de exceções e remoção de validações. Para cada mudança, identifique o requisito que a justifica.

Se aparecer uma abstração que você não consegue explicar, compare com a solução direta. SOLID e design patterns ajudam a avaliar responsabilidades e dependências; não precisam virar uma obrigação de criar interfaces e fábricas para qualquer classe.

4. Teste a decisão e seus efeitos

Aqui está um erro fácil de deixar passar. A tarefa 42 começa como CONCLUIDA. O código troca o status para ABERTA e só depois verifica que a reabertura era proibida. A exceção aparece, mas o objeto já mudou.

Um teste que pergunta apenas “lançou exceção?” pode aprovar essa implementação. Acrescente outra pergunta: “depois da tentativa, a tarefa 42 continua CONCLUIDA?”. Agora você está verificando a regra e o efeito sobre os dados.

Se a IA escrever os testes, leia o resultado esperado antes de rodar. Pergunte: “Se alguém remover a validação, esse teste falha?”. Se ele continuar passando, falta algo para proteger a regra que você queria testar.

Veja uma implementação mínima. A validação vem antes da atribuição, e a verificação final exige tanto a recusa quanto o estado preservado. Salve como TarefaDemo.java e execute java TarefaDemo.java com Java 21:

public class TarefaDemo {
    enum Status { ABERTA, CONCLUIDA }

    static class Tarefa {
        private Status status = Status.ABERTA;

        void concluir() { status = Status.CONCLUIDA; }

        void reabrir() {
            if (status == Status.CONCLUIDA) {
                throw new IllegalStateException("Tarefa concluida");
            }
            status = Status.ABERTA;
        }
    }

    public static void main(String[] args) {
        var tarefa = new Tarefa();
        tarefa.concluir();
        boolean recusou = false;
        try {
            tarefa.reabrir();
        } catch (IllegalStateException erro) {
            recusou = true;
        }
        if (!recusou || tarefa.status != Status.CONCLUIDA) {
            throw new AssertionError("Recusa deve preservar o estado");
        }
        System.out.println(tarefa.status); // CONCLUIDA
    }
}

A saída esperada é CONCLUIDA. Para revelar o erro descrito acima, experimente mover a atribuição para antes do if: a verificação deve falhar. Remover a validação também deve fazê-la falhar. Esse programa usa uma verificação explícita para dispensar bibliotecas no primeiro exercício; em um projeto, transforme os casos em testes automatizados da sua suíte.

Executamos este exemplo com OpenJDK 21.0.2: a versão correta passou, e as duas alterações incorretas foram detectadas. Isso valida este recorte em memória, não persistência ou concorrência.

5. Explique e altere sem pedir a solução inteira

Feche a conversa e descreva onde a regra é verificada, quando o estado muda e o que acontece no erro. Em seguida, altere uma condição do exercício. Caso trave, volte a uma pergunta delimitada em vez de solicitar a reconstrução do projeto.

Exercício: impedir a reabertura de uma tarefa concluída

Use um projeto de estudo com as operações concluir e reabrir. Defina explicitamente: concluir uma tarefa já concluída mantém o estado, sem erro; reabrir uma tarefa concluída é proibido. Essa é uma regra didática escolhida aqui, não um padrão obrigatório de APIs.

Estado inicial e operação	Resultado esperado	O que conferir depois
ABERTA, concluir	Operação aceita	Estado CONCLUIDA.
CONCLUIDA, concluir novamente	Sem nova alteração	Estado e demais dados preservados.
CONCLUIDA, reabrir	Operação recusada	Estado continua CONCLUIDA.
Identificador inexistente, concluir	Ausência tratada	Nenhuma outra tarefa é alterada.

Implemente primeiro em memória. Se seu projeto já tem banco, repita a leitura após a tentativa recusada e confira o registro persistido. Não basta olhar a resposta da API.

Agora mude o requisito: uma tarefa pode ser cancelada apenas enquanto está aberta. Escreva a nova tabela antes de alterar o código e reexecute os casos anteriores. Ao terminar, mostre a tabela de regras, os testes e o diff. Depois explique, com suas palavras, por que a validação precisa acontecer antes de alterar o estado.

O exercício não cobre autenticação, autorização, concorrência ou todas as combinações de estados. Anote esses limites. Conseguir explicá-los também faz parte da revisão.

Erros comuns ao estudar programação com IA

• Pedir o projeto inteiro e tentar entender depois: reduza para uma regra cuja entrada e saída você consegue prever.
• Aceitar dependências desconhecidas: confirme existência, versão e necessidade antes de instalar.
• Mudar o teste para acompanhar uma saída errada: volte ao requisito escrito antes da implementação.
• Repetir a pergunta quando trava: registre a hipótese atual e a evidência que a contradiz.
• Confundir código curto com código compreendido: siga o fluxo com um caso de sucesso e outro de falha.

Dúvidas sobre IA e fundamentos Java

Preciso programar sem IA o tempo inteiro?

Você pode alternar tentativa própria, consulta e revisão. Reserve partes do exercício para explicar e modificar sem a conversa aberta. Isso ajuda a identificar qual conhecimento ficou disponível para você e qual ainda está apenas na resposta da ferramenta. Não há uma proporção universal de tempo para esse diagnóstico.

Posso pedir para a IA explicar uma stack trace?

Sim, com uma reprodução pequena e sem dados sensíveis. Peça uma hipótese e localize a chamada correspondente no seu código. Compare a explicação com a mensagem e o encadeamento da falha; não suprima exceções apenas para o erro desaparecer.

Quando vale pedir revisão humana?

Quando você repete tentativas sem distinguir as hipóteses ou quando a decisão envolve consequências que ainda não sabe avaliar. Leve o requisito, a reprodução e o que já verificou. Questões de acesso, dados e concorrência merecem revisão compatível com o risco.

Checklist antes de aceitar código sugerido

• Consigo explicar entradas, saídas e estado alterado?
• Conferi APIs e dependências em fontes oficiais?
• Tenho um teste que falharia com o defeito original?
• Verifiquei que a operação recusada preserva os dados?
• Consigo adaptar uma regra sem pedir toda a solução novamente?
• Registrei o que ainda não foi testado e precisa de revisão?

Continue o estudo

Se a dificuldade estiver nos pré-requisitos, use as tarefas de diagnóstico de o que estudar antes de Spring Boot para escolher o próximo exercício.

Referências e próximo passo com a formação

Use o material oficial de Java para consultar objetos, coleções e exceções conforme as lacunas do exercício. O guia REST do Spring ajuda a acompanhar uma requisição e sua representação JSON; a referência de transações do PostgreSQL aprofunda a confirmação conjunta de alterações. Referências consultadas em 22/10/2026. Registre as versões de Java e das ferramentas quando implementar o exercício.

Se você quer continuar esse estudo com uma sequência de conteúdos e projetos, veja os cursos da Formação Build & Run. A proposta conecta engenharia de software e IA, com Java na prática. Use a dúvida que apareceu no exercício para avaliar qual conteúdo faz sentido estudar agora.

Para levar à prática

Ao aceitar código sugerido por IA, procure entender a regra, observar o estado depois de uma falha e conseguir alterar uma condição. O teste da tarefa concluída mostra por que lançar uma exceção, sozinho, não garante que os dados foram preservados.