O conceito de Inteligência Artificial foi simplificado nos últimos anos desde o lançamento do ChatGPT ao público. Foi uma estratégia incrível de simplificar o que já existia para uma interface que qualquer pessoa que já utilizava a internet conseguisse usar, sem API, sem configuração, sem nada técnico, mas um simples chat. Só que, desta vez, do outro lado não há uma pessoa, mas uma LLM poderosa interagindo contigo.
E isso foi o suficiente para determinar uma nova tendência no mercado e acender novamente a dúvida: o trabalho humano pode ser substituído por uma máquina? Acho que Alan Turing ficaria orgulhoso e preocupado se pudesse viver esse momento.
Antes dessa ascensão das LLMs e da simplificação de todo um campo da computação, reduzindo isso a IA, muito se falava em como as máquinas poderiam substituir o trabalho humano. Fábricas já são operadas por robôs autônomos há décadas, aviões já são pilotados automaticamente, dentre outros exemplos, mas, pela primeira vez, o trabalho criativo foi ameaçado.
Já era claro no mercado que toda tarefa, física ou intelectual, que pudesse ser automatizada deveria ser automatizada para baratear custos e reduzir erros de processos, mesmo que isso levasse a demissões. A discussão é retomada agora.
Os defensores usam o exemplo da Revolução Industrial para justificar que o progresso pode e vai extinguir empregos. Porém, a meu ver, a grande diferença está no tempo dessa transição e na possível quantidade de pessoas afetadas de uma só vez. Quando as grandes fábricas foram criadas, houve um grande tempo de transição para isso, e os trabalhadores do campo conseguiram se realocar. Desta vez, talvez isso não aconteça.
A alta capacidade de automatizações que uma IA bem treinada é capaz de fazer pode não substituir trabalhadores braçais, como era esperado de início, mas o trabalho dito criativo, que até então era considerado inatingível. E, na velocidade que isso tem avançado, pode ser questão de tempo que se torne mais viável, para uma empresa, pagar um software que vai realizar o trabalho mais rápido e sem erros do que manter um funcionário.
Mas a pergunta que fica é: isso seria sustentável? Se não houver mais trabalhadores, quem vai consumir os produtos que as máquinas produzem? Na minha opinião, temos que achar um meio-termo para isso, seja combinar o trabalho humano com a máquina, além de sustentar aqueles que não poderão se realocar, não por falta de capacidade, mas por não haver mais vagas disponíveis.
Estamos caminhando para um futuro que, ao mesmo tempo, é brilhante e cheio de possibilidades, mas assustador. Como vamos lidar com isso como sociedade, só o futuro dirá.
[]`s
]]>Programar é assim também. Você começa com uma instrução, termina com um ponto e vírgula e, no meio… coloca ideias.
Nos últimos anos, vimos uma transformação impressionante no mercado com o avanço das inteligências artificiais generativas — os modelos de linguagem (LLMs) como o ChatGPT e seus concorrentes, o que comumente chamamos de IAs, e como vou chamar neste artigo para fins de simplificação.
A velocidade dessa revolução é espantosa. Em pouquíssimo tempo, essas tecnologias deixaram de ser curiosidades para se tornarem ferramentas de trabalho, estudo e criação. E aí surge a pergunta: a IA já roubou o seu emprego?
Talvez ainda não, mas, dependendo de como você a usa, ela pode estar se preparando para isso.
É preciso entender o que ela faz, por que faz e o que você está pedindo que ela faça. Usar IA sem senso crítico é perigoso, principalmente para quem ainda está aprendendo. Ela deve acelerar seu aprendizado, não substituí-lo.
Eu mesmo já usei IA para automatizar tarefas demoradas: gerar scripts, montar consultas, criar trechos de código ou pequenas aplicações inteiras, até para ajudar a escrever este texto. Mas sempre em situações em que eu sabia o que estava pedindo. Eu entendia a lógica, sabia validar o resultado e revisar o que foi entregue. Ela apenas acelerou um processo que eu já dominava.
Quando você pede à IA para fazer algo que você não sabe fazer, você não aprende. E se você não sabe revisar o resultado, não tem como saber se ela errou — e ela vai errar.
Um estudo da Veracode mostrou que ferramentas de desenvolvimento com IA geram código inseguro em 45% das vezes. Entre as linguagens analisadas, o Java teve o pior desempenho, com apenas 28,5% das gerações consideradas seguras. Os modelos foram bem em alguns tipos de falha (como criptografia insegura e SQL injection), mas foram desastrosos em cross-site scripting (13,5%) e log injection (12%).
Esse ponto é especialmente importante para quem ainda está na faculdade ou começando a carreira. Vejo muitos estudantes usando IA como substituto — deixando que ela faça os exercícios, escreva os códigos, monte os trabalhos. Isso é um grande erro!
Porque, se a IA pode te substituir, ela vai te substituir. E o mercado não vai precisar mais de você.
Tarefas repetitivas, mecânicas, que antes eram atribuídas a juniores ou estagiários, agora podem ser automatizadas em minutos. Se você pula essa etapa e se apoia na IA, você pode até entregar o resultado, mas não constrói conhecimento.
Aprender programação é como aprender a dirigir. No começo, você se preocupa com cada detalhe: trocar marcha, segurar a embreagem; na programação, você se esforça para lembrar o comando do for, o while, a sintaxe correta. Com o tempo, isso se torna natural. Você para de pensar no “como” e começa a pensar no “para onde”.
É nesse momento que a IA pode brilhar: quando você já domina a base e quer ir além. Quando a programação flui naturalmente, a IA pode te ajudar a pensar em alto nível, testar hipóteses, automatizar partes chatas. Mas se você ainda está decorando o básico, ela só vai te atrapalhar.
Programar é 90% pensar — entender o problema, planejar, testar hipóteses, buscar soluções, evitar bugs. O código é apenas o resíduo desse esforço mental.
Programação não é linha de produção — é design, é criação. Forçar movimento não gera valor. O que realmente importa é a qualidade do pensamento.
A IA é uma revolução, mas também traz grandes problemas. Ela amplifica tanto nossa capacidade quanto nossas limitações. Se você a usa para aprender, criar e pensar melhor, ela te torna mais forte. Mas se você a usa como atalho para pular etapas, ela vai te substituir.
No fim, a verdade é simples: você não vai perder seu emprego para a IA, mas sim para alguém que sabe usar IA melhor que você.
[]’s
]]>Deixo aqui, um resumo dos principais temas e discutidos:
A Inteligência Artificial foi abordada de forma prática: deve ser usada como auxílio, não como substituto. A recomendação é explorar a IA com curiosidade e ceticismo, focando em seu uso para otimizar processos, sem cair em “hypes” sem justificativa real.
Foi apresentada a ideia de Monorepo como uma alternativa aos microsserviços, usando modularização para separar responsabilidades e permissões em um único repositório. As vantagens incluem menor custo e maior facilidade de deploy e manutenção. Enquanto microsserviços são úteis para escalar times, não necessariamente aplicações, o monorepo pode oferecer escalabilidade de módulos e manter fronteiras bem definidas. A mensagem principal foi a importância de escalar a complexidade conforme a necessidade, evitando adicionar complexidade acidental sem justificativa clara. A regra é: “Do the Simplest Thing That Could Possibly Work”.
Microsserviços não servem para escalar aplicações, mas para escalar times
A refatoração deve ser uma prática constante da equipe, e não uma tarefa fixa. Sugere-se que entre 10% e 20% do tempo do desenvolvedor seja dedicado a isso, de forma natural, enquanto se trabalha em novas funcionalidades. Refatorar é essencial para manter o sistema coeso, atualizado e resistente a mudanças.
O teste unitário é o seu primeiro usuário e não existe uma boa arquitetura sem testes. A pirâmide de testes (unitário na base, integração no meio, e2e no topo) orienta onde concentrar os esforços, com testes unitários sendo mais “baratos” e importantes para diminuir a dependência do QA. Testes devem ser simples, objetivos, pequenos e fáceis de ler. Um ponto crucial é que “Code Coverage não é tudo, quantidade nem sempre significa qualidade”, e testes que falham intermitentemente devem ser corrigidos ou removidos, pois não são confiáveis.
O teste unitário é o seu primeiro usuário!
É melhor falhar para alguns usuários do que para todos, enfatizando a importância do conceito “Fail Fast”. APIs REST devem ser idempotentes, ou seja, chamar o mesmo endpoint várias vezes deve produzir o mesmo comportamento. Endpoints de escrita não devem ter efeitos colaterais de inserir o mesmo dado duas vezes, e as operações devem ser “tudo ou nada” para evitar inconsistências.
A aprendizagem se divide em duas formas: difusa (conhecimentos adquiridos em podcasts, eventos, conversas, palestras) e focada (conhecimento formal, cursos, estudo pessoal direcionado). “Aprender dói, tem que doer”, pois o crescimento ocorre quando saímos da zona de conforto. A mensagem final para a carreira é comece agora, não esperar o momento certo, pois “Feito é melhor do que bem feito!”. E lembre-se: “Nem tudo dá certo, mas o que importa é tentar. Falhe rápido, mas não deixe de tentar”.
Nem tudo dá certo, mas o que importa é tentar. Falhe rápido, mas não deixe de tentar.
Foi um evento incrível, quero poder voltar nas próximas edições.
]]>Ao longo de mais de 10 anos participando da seleção de candidatos para vagas de estágio, percebi que muita gente ainda acha que é preciso ter experiência prática para conseguir a primeira oportunidade. A verdade é que, para estagiários, a principal qualidade que buscamos é a disposição para aprender. O resto vem com o tempo e com o próprio aprendizado no dia a dia.
O que realmente faz diferença é a curiosidade e a vontade de se desafiar. Pesquisar por conta própria, perguntar, estudar novas tecnologias, se envolver em discussões técnicas, enfim, tudo que mostra que você não espera só o conhecimento cair no seu colo.
Não é esperado que o candidato chegue com experiência prática, dominando todos os requisitos técnicos, mas que a vontade de aprender se reflita em aplicações práticas. Nada melhor do que mostrar que a teoria que você aprendeu na faculdade, consegue ser aplicada na prática, um projeto pessoal, por exemplo. Não precisa ser algo grande nem útil, mas deve demonstrar que você está realmente colocando em prática o que está aprendendo. É isso que faz a diferença no início da carreira.
Já tive experiências com candidatos que diziam que estavam dispostos a aprender e a encarar qualquer desafio, mas que no dia a dia não se interessavam em nada diferente do que viam na faculdade. É esperado que que ele queira ir além da sala de aula.
Então fica aqui minha dica, para você estudante, para sua próxima entrevista: Ninguém espera que você domine uma determinada linguagem ou ferramenta, mas que demonstre, de forma prática, que tem capacidade e interesse de dominá-las.
Corra atrás disso e boa sorte.
]]>2. Agrupar configurações em classes específicas com @Configuration Centralize configurações relacionadas em classes dedicadas anotadas com @Configuration, como para banco de dados, segurança, mensageria ou cache. Facilita testes e mantém separação limpa entre serviços.
3. Manter separação clara entre Controller, Service e Repository
Controller: lida com chamadas HTTP, validação e delega o trabalho. Service: encapsula a lógica de negócio e orquestra interações entre repositórios e outros serviços. Repository: gerencia a persistência no banco de dados.
4. Manter controllers enxutos e serviços robustos Controllers devem apenas delegar a lógica; toda lógica de negócio deve ficar nos serviços, garantindo clareza, testabilidade e separação de responsabilidades.
5. Usar DTOs para requisição, entidade e resposta Não exponha entidades JPA diretamente nos controllers. Crie DTOs específicos (CreateUserRequest, UserEntity, UserResponse) para proteger camadas, evitar over-fetching, LazyInitializationException e proteger dados sensíveis.
6. Criar handlers globais de exceção com @ControllerAdvice Centralize o tratamento de erros usando @ControllerAdvice, retornando respostas consistentes e mapeando exceções para códigos HTTP apropriados.
7. Usar códigos HTTP significativos Retorne códigos adequados para cada operação: 201 Created para novos recursos, 204 No Content para exclusões, 400 Bad Request para erros de validação etc. Isso torna a API mais intuitiva.
8. Prefira injeção via construtor em vez de via campo Promove imutabilidade, facilita testes, identifica dependências ausentes em tempo de compilação e torna dependências explícitas.
9. Reduzir uso de classes utilitárias estáticas Encapsule a lógica em serviços ou beans que podem ser testados isoladamente. Reserve métodos estáticos apenas para funções puramente utilitárias.
10. Adicionar resiliência com Retry, Circuit Breaker e Rate Limiting Use @Retryable (Spring Retry), @CircuitBreaker (Resilience4j) e rate limiting (Redis ou Bucket4j) ao chamar APIs externas ou bancos de dados.
Referências:
(https://medium.com/@sanchitvarshney/ten-architecture-tips-every-spring-boot-developer-should-learn-early-26ce8327f3c4)
(https://medium.com/@ujjawalr/5-spring-boot-patterns-that-separate-senior-developers-from-juniors-3fdb110d7d30)
(https://medium.com/javaguides/12-best-practices-every-spring-boot-developer-should-follow-4d678d0d5ed6)
(https://medium.com/@pudarimadhavi99/advanced-spring-boot-concepts-every-java-developer-should-know-575fe023d4e5)
]]>Alguns mitos que considero importante discutir:
Quais mitos você ainda ouve por aí?
]]>Como já virou tradição, cataloguei os filmes, séries, jogos e leituras que consumi durante o ano, esta é a lista de 2022.