The long path from idea to deployment is rarely a straight line. I started as a veterinary student in Brazil, detoured through livestock management, and ended up building full-stack web applications and AI automation systems. This isn't a 'career pivot' story - it's a story about how systems thinking transfers between domains.
In veterinary science, you learn to diagnose by working through systems: cardiovascular, respiratory, musculoskeletal. Each system has inputs, outputs, and failure modes. Software engineering works the same way. A slow API endpoint is like a constricted blood vessel - you trace the flow, find the bottleneck, and fix the constraint. The diagnostic mindset is identical.
My first real web project was a WordPress site for a veterinary clinic, with a custom theme, an appointment form and a patient intake questionnaire. It connected what happened on the screen to the work behind it. A useful form needs a clear destination, a confirmation and a way for reception to handle exceptions.
From WordPress I moved to React, then Next.js. From JavaScript to TypeScript. From REST APIs to Python backends with FastAPI. Each jump felt enormous at the time but, looking back, each one was just learning a new module in the same system. The fundamentals - HTTP, state management, data modeling, user flows - stay constant across every framework.
The AI chapter started with the WhatsApp Business API. A client asked: 'Can the bot answer patient questions after hours?' That question led me to build ClinicaSync IA, which led to building the same pattern for law firms (JusTriagem), barbershops (BarberFlow), and sales teams (OmniAtende). Every project was the same architecture - WhatsApp webhook → intent classifier → domain-specific handler → structured response - adapted to a different business context.
Building LCC (Local Context Compiler) introduced a different challenge: selecting context for another AI system. Its public repository documents local context processing and auditable reports. Reducing text and preserving task quality are separate checks; a smaller input alone does not prove a better answer.
The most important lesson from crossing all these domains: small modules can carry heavy systems when each one has a clear job and a visible boundary. A 50-line function that validates a date is more valuable than a 500-line class that tries to handle every edge case internally. Keep the surface area small, keep the contracts explicit, and the system stays debuggable.
Today I'm building at the intersection of three things: product interfaces (dashboards, CRMs, operational panels), automation systems (WhatsApp bots, n8n workflows, scheduled pipelines), and AI tooling (agent observability, context optimization, prompt engineering). The stack keeps evolving, but the diagnostic mindset stays the same: trace the flow, find the constraint, fix it, move on.