<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Victor Laurance on Victor Laurance - Software Engineer</title><link>https://laurance.dev/</link><description>Recent content in Victor Laurance on Victor Laurance - Software Engineer</description><generator>Hugo</generator><language>pt</language><lastBuildDate>Fri, 09 Oct 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://laurance.dev/index.xml" rel="self" type="application/rss+xml"/><item><title>Harness Engineering e Orquestração de Agentes de Código</title><link>https://laurance.dev/blog/harness-engineering/</link><pubDate>Fri, 09 Oct 2026 00:00:00 +0000</pubDate><guid>https://laurance.dev/blog/harness-engineering/</guid><description>&lt;p>Existe um momento comum quando começamos a usar agentes de código em tarefas reais. O agente recebe a tarefa, trabalha por alguns minutos e devolve uma alteração que compila. Os testes passam. À primeira vista, parece tudo certo.&lt;/p>
&lt;p>Então você abre o diff e percebe: a regra de negócio foi parar no controller, a injeção de dependência foi feita por campo, apesar da convenção do projeto, e um &lt;code>catch (Exception e)&lt;/code> esconde uma falha que deveria ser tratada. Você corrige, pede novamente e, na próxima tarefa, o agente repete parte dos mesmos erros.&lt;/p></description></item><item><title>Apache Kafka com Java: Eventos, Consistência e Confiabilidade</title><link>https://laurance.dev/blog/kafka-java/</link><pubDate>Mon, 28 Sep 2026 00:00:00 +0000</pubDate><guid>https://laurance.dev/blog/kafka-java/</guid><description>&lt;p>Se você já precisou explicar para o time de negócio por que uma transferência foi debitada duas vezes, sabe que o problema quase nunca está na regra de negócio. Ele mora no espaço entre os serviços: a mensagem que chegou duplicada, o evento que foi publicado antes do commit, o consumidor que caiu no meio do processamento. É nesse espaço que a mensageria deixa de ser um detalhe de infraestrutura e vira uma decisão de engenharia sobre consistência.&lt;/p></description></item><item><title>Como Funcionam as IAs Generativas (LLMs)</title><link>https://laurance.dev/blog/funcionamento-llms/</link><pubDate>Tue, 22 Sep 2026 00:00:00 +0000</pubDate><guid>https://laurance.dev/blog/funcionamento-llms/</guid><description>&lt;p>Toda vez que alguém me pergunta &amp;ldquo;mas como o ChatGPT realmente funciona?&amp;rdquo;, eu esbarrava em duas respostas prontas: ou um &amp;ldquo;é mágica&amp;rdquo; disfarçado de explicação, ou um mergulho em matemática que me fazia perder a pessoa na segunda frase. Não precisa ser assim. Dá pra explicar direito, sem simplificar até virar mentira, e sem exigir que você saiba de cálculo. É isso que eu quero fazer aqui.&lt;/p>
&lt;h2 id="não-é-mágica-é-um-previsor-de-próxima-palavra-só-que-gigante">Não é mágica: é um previsor de próxima palavra, só que gigante&lt;/h2>
&lt;p>Na essência, um LLM (Large Language Model, &amp;ldquo;modelo de linguagem grande&amp;rdquo;) faz uma coisa só: dado um pedaço de texto, ele calcula qual é a palavra mais provável de vir a seguir. É o mesmo princípio do corretor do teclado do seu celular quando sugere a próxima palavra enquanto você digita, só que treinado com uma fração relevante de tudo que já foi escrito publicamente na internet, com bilhões de ajustes internos, em vez de umas poucas mensagens suas.&lt;/p></description></item><item><title>Virtual Threads e Concorrência no Java 25 com Spring Boot 4</title><link>https://laurance.dev/blog/virtual-threads/</link><pubDate>Mon, 21 Sep 2026 00:00:00 +0000</pubDate><guid>https://laurance.dev/blog/virtual-threads/</guid><description>&lt;p>Todo backend Java que precisa aguentar muita requisição simultânea esbarra no mesmo problema: threads de sistema operacional são caras. Cada uma reserva memória de stack, e o sistema operacional não segura mais que algumas milhares delas sem sofrer. Por anos, a resposta pra isso foi migrar pra uma stack reativa como: WebFlux, Reactor e callbacks, trocando código imperativo simples por um estilo bem mais difícil de ler e depurar. Foi tentando resolver esse tipo de gargalo sem pagar esse preço que as Virtual Threads chegaram, e o Java 25 finalmente deixou essa história bem mais madura do que era em 2023, quando o recurso foi lançado.&lt;/p></description></item><item><title>Aplicando Hexagonal Architecture em uma aplicação Spring Boot</title><link>https://laurance.dev/blog/hexagonal-architecture/</link><pubDate>Sun, 13 Sep 2026 00:00:00 +0000</pubDate><guid>https://laurance.dev/blog/hexagonal-architecture/</guid><description>&lt;p>Se você já manteve por tempo suficiente uma aplicação Spring Boot, provavelmente já viu regra de negócio, controller e entidade JPA misturados no mesmo lugar. Funciona, até o dia em que você precisa trocar o banco de dados, escrever um teste unitário decente ou simplesmente entender onde termina a lógica do negócio e começa o framework. Foi justamente esse tipo de dor que me fez estudar a fundo a Hexagonal Architecture, e neste artigo eu quero mostrar como apliquei os conceitos numa aplicação Spring Boot real.&lt;/p></description></item><item><title>Veira Streaming</title><link>https://laurance.dev/projects/veira/</link><pubDate>Sun, 30 Aug 2026 00:00:00 +0000</pubDate><guid>https://laurance.dev/projects/veira/</guid><description>&lt;h2 id="overview">Overview&lt;/h2>
&lt;p>Veira é uma plataforma de streaming desenvolvida como um projeto de engenharia de software.&lt;/p>
&lt;p>O objetivo do projeto é explorar, de forma prática, conceitos de backend, frontend, sistemas distribuídos, arquitetura, mensageria, cloud e DevOps.&lt;/p>
&lt;p>Mais do que construir uma aplicação de streaming, o projeto funciona como um laboratório para experimentar diferentes estratégias arquiteturais e documentar suas decisões.&lt;/p>
&lt;h2 id="architecture">Architecture&lt;/h2>
&lt;p>A arquitetura será construída e evoluída progressivamente.&lt;/p>
&lt;p>Entre os principais conceitos explorados estão:&lt;/p></description></item></channel></rss>