O que construir uma API REST me ensinou antes de começar a estudar IA
Quando comecei a estudar desenvolvimento backend, meu objetivo era relativamente simples: aprender Java e Spring Boot e conseguir construir uma API REST.
No início, parecia que o desafio era apenas fazer o CRUD funcionar.
Criar um produto, salvar no banco, buscar, atualizar e excluir.
Só que, conforme o projeto foi crescendo, percebi que desenvolver uma aplicação não é apenas fazer o código funcionar. Existem várias outras decisões envolvidas: como organizar o projeto, onde colocar as regras de negócio, como validar os dados, como testar, como lidar com o banco de dados e até como garantir que tudo continue funcionando depois de uma alteração.
Foi justamente esse processo que começou a mudar minha forma de enxergar desenvolvimento de software.
Do CRUD para uma aplicação de verdade
O projeto que estou desenvolvendo é uma API REST para gerenciamento de um supermercado, utilizando Java 21, Spring Boot, Spring Data JPA, Hibernate e PostgreSQL.
No começo, trabalhei principalmente com operações básicas.
Mas o projeto foi crescendo e novas necessidades começaram a aparecer.
Produtos passaram a ter categorias. Surgiram clientes e fornecedores. Depois vieram compras, vendas, carrinho e itens relacionados a essas operações.
E junto com essas funcionalidades vieram também as regras de negócio.
Por exemplo, não basta simplesmente cadastrar uma venda. É necessário considerar estoque, produtos relacionados, quantidades e outras condições da operação.
Foi aí que comecei a perceber uma diferença importante:
fazer uma funcionalidade funcionar é diferente de construir uma aplicação.
A complexidade aparece aos poucos
Conforme fui avançando, comecei a trabalhar com arquitetura em camadas, separando responsabilidades entre Controller, Service e Repository.
Também passei a utilizar DTOs para controlar os dados que entram e saem da API, validações para evitar informações inválidas e JPA/Hibernate para trabalhar com persistência.
Depois vieram outras necessidades, como paginação, filtros e Specifications.
Uma consulta que inicialmente poderia ser simplesmente:
findAll()
começou a precisar considerar diferentes critérios de busca.
Por exemplo:
- produtos pelo nome;
- categoria;
- faixa de preço;
- fornecedores ativos;
- clientes por nome ou e-mail;
- compras e vendas por período.
Nesse momento percebi outra coisa que considero importante no aprendizado:
a complexidade de um sistema geralmente não aparece toda de uma vez.
Ela vai surgindo conforme tentamos resolver problemas reais.
“Funciona” não significa “está pronto”
Outro aprendizado importante veio quando comecei a trabalhar com testes.
É muito fácil olhar para uma API, fazer uma requisição no Postman e pensar:
“Funcionou. Está pronto.”
Mas o que acontece quando uma regra muda?
E quando uma nova funcionalidade quebra algo que já existia?
Foi aí que os testes unitários com JUnit e Mockito começaram a fazer mais sentido para mim.
Também comecei a utilizar JaCoCo para acompanhar cobertura de testes e GitHub Actions para executar a verificação automaticamente.
Isso mudou um pouco minha visão sobre qualidade.
Não se trata apenas de escrever código que funciona hoje.
É também criar uma estrutura que permita modificar o sistema amanhã com mais segurança.
E onde a IA entra nisso?
Foi nesse ponto que comecei a estudar IA com mais atenção.
Inicialmente, quando pensamos em aplicações com LLMs, é fácil imaginar que basta enviar uma pergunta para um modelo e receber uma resposta.
Mas quanto mais estudo agentes, RAG e aplicações baseadas em LLMs, mais percebo que o modelo é apenas uma parte do sistema.
Uma aplicação de IA pode precisar buscar informações, consultar bancos de dados, utilizar ferramentas, aplicar regras, processar documentos, manter contexto e disponibilizar tudo isso através de uma aplicação.
Algo como:
Usuário
↓
API
↓
Regras da aplicação
↓
Dados / Ferramentas
↓
LLM
↓
Resposta
E foi aí que comecei a enxergar uma conexão entre coisas que antes pareciam áreas diferentes.
A base de backend que estou construindo pode ser extremamente útil para desenvolver aplicações de IA mais completas.
A IA não substitui a engenharia do sistema
Uma das coisas que mais tenho percebido estudando IA é que uma LLM pode ser extremamente poderosa, mas isso não significa que ela resolva todos os problemas de uma aplicação.
Ainda precisamos pensar em arquitetura.
Precisamos decidir de onde os dados vêm, como são armazenados, como são recuperados, quais ferramentas o agente pode utilizar, como erros serão tratados e como o sistema será testado.
Ou seja, aprender IA não fez o backend parecer menos importante para mim.
Na verdade, fez o contrário.
Comecei a perceber que construir uma aplicação de IA também envolve muitos dos mesmos fundamentos que aparecem no desenvolvimento tradicional de software.
O que mudou na minha forma de estudar
Hoje, quando penso em aprender uma nova tecnologia, tento olhar menos para a tecnologia isoladamente e mais para o problema que ela resolve.
Aprender Java não é apenas aprender a sintaxe da linguagem.
Aprender Spring Boot não é apenas aprender a criar endpoints.
Aprender IA não é apenas aprender a fazer chamadas para uma API de LLM.
O mais interessante começa quando conseguimos juntar essas ferramentas para construir alguma coisa.
Foi isso que meu projeto de supermercado acabou me ensinando.
Eu comecei querendo aprender a fazer um CRUD.
Acabei aprendendo sobre arquitetura, persistência, regras de negócio, testes, CI e, principalmente, sobre como um sistema vai ficando mais complexo conforme tentamos resolver problemas mais próximos da realidade.
Agora, ao começar a estudar IA e agentes, estou levando essa experiência comigo.
Talvez esse seja um dos maiores aprendizados até agora:
antes de tentar construir sistemas inteligentes, é importante aprender a construir sistemas bem estruturados.
E essa é justamente a próxima etapa que quero explorar: descobrir como combinar essa base de backend com IA para construir aplicações que realmente façam algo útil.
