AI Engineer & Software Architect
Hi, I’m Luke.
I’ve spent more than two decades building software, with Magento part of my work since 2010. I’ve worked as a developer, tech lead and architect, taking responsibility for both the design of a system and the work needed to get it into production.
I work with new products and established systems: turning an idea into something a team can build, or getting into a codebase with years of customizations and figuring out how to improve it while the business keeps running.
I’m still hands-on. I write code, review it, investigate performance problems and work through implementation details with other engineers. Being able to move between those details and the wider architecture is a big part of what I bring to a project.
Magento and Adobe Commerce, since 2010
Commerce has been a substantial part of my career. Through Act Digital, I led the architecture of Saint-Gobain Brazil’s B2B Adobe Commerce platform. At Visualr, I joined as the first Magento specialist and worked as a hands-on architect on a complex B2B platform. That work involved pricing rules, large catalogs, integrations, performance and the technical decisions behind delivery.
At Infobase, I was Tech Lead on Magento and Adobe Commerce projects for brands such as Panini, Yara and BASF, among others. One of them was the e-commerce of Dufry, the global duty-free retailer, at the time one of the largest Adobe Commerce stores in the world.
I’ve also led developers, reviewed technical decisions and worked with business teams to turn complicated requirements into a practical implementation.
My experience runs from Magento 1 through Magento 2 and Adobe Commerce. Custom modules, dependency injection, service contracts, plugins, observers, GraphQL and REST APIs, indexers and RabbitMQ consumers are all part of that background. So are checkout, payments, shipping and ERP integrations, where a change in one part of the system can have consequences somewhere else.
Before adding a customization, I look at where it belongs, what it couples together and how it will behave during an upgrade. That affects how much effort the next feature will take.
Working with complex code
When I get into an unfamiliar codebase, I start by following a real operation through it. Where does the business rule live? Which component owns the data? What else changes when this code runs? That usually tells me more than the folder structure.
That is where I apply SOLID, domain-driven design and Clean Architecture: deciding where responsibilities belong, defining bounded contexts and keeping business rules from becoming tangled with frameworks or external providers.
If payment-provider details are spreading through an order module, a clear integration contract can give us a useful boundary. If a service is applying business rules and formatting a page, those responsibilities need separating. Neither change requires rebuilding the application.
My approach to Clean Code and refactoring is to understand the existing behavior, protect it with useful tests and make focused improvements. Sometimes that calls for an adapter or a strategy. Sometimes it means removing an abstraction that adds nothing.
Python, TypeScript and AI applications
Python and TypeScript are central to the backend and AI application work I’m focused on today. I use Python for AI workflows, data handling and service integrations, and TypeScript for services, APIs and product workflows. Across both, I pay attention to contracts, runtime validation, asynchronous work and error handling.
With AI, I start by deciding what the model should actually be responsible for. Which parts need language understanding or generation? Which should remain ordinary application logic? What can the model suggest, and what is it allowed to change?
With RAG, that means working through the documents, chunking, updates, access permissions and retrieval quality. With agents, it means defining tools, state and execution limits, including what happens when a tool fails or an action needs confirmation.
Model choice is part of that work. So are structured outputs, context, latency and cost. I want examples we can evaluate, traces we can investigate and a way to compare behavior when the model, prompt or retrieval changes. Producing valid JSON is useful; it does not tell us whether the result is right.
Getting software into production
My work also covers CI/CD, deployment and production support. I’ve worked with Docker, Linux, Nginx and AWS infrastructure, alongside automated testing, code reviews and delivery pipelines.
I want the path from a code change to a release to be understandable: what is being built, which checks matter, how configuration and secrets are handled, and how we will know whether the release is healthy. Database changes, compatibility and recovery need attention before the deployment, not during the incident.
The work does not end at the release. Once the software is running, I want logs, metrics and traces, in tools such as New Relic, Grafana and CloudWatch, that show how it actually behaves: which requests are slow, where the time goes between the application, the database and external services, and which errors are growing. That is how bottlenecks stop being guesses. Production becomes feedback for the platform: what to optimize, what to simplify and what to fix before it turns into an incident.
When planning for growth, I look at the workload and the likely pressure points: database access, caching, background processing and external dependencies. That informs what needs to scale independently and what can stay together. It also helps avoid adding operational complexity before it solves a real problem.
Microservices are part of that decision, not a starting point. Splitting a system can give teams independent deployments and let a busy part scale on its own, but it also brings network calls, partial failures, data consistency and more to observe. I prefer clear modules inside one application until there is a real reason to separate them. When a service is justified, its contract, ownership and observability need to be defined from the start.
The process should fit the project. A personal publishing site and an enterprise commerce platform do not need the same delivery machinery.
What I’m building
My own projects give me a place to bring those decisions together. Lukre is a conversational finance product built around WhatsApp.
I’m also experimenting with agent-assisted development, execution graphs, Gas City and Beads: how agents get the right context, how dependencies are tracked and how their work is verified before it becomes part of the codebase.
Away from the keyboard
Early forties, and enjoying them more than I expected. The experience pays off, the patience is longer, the eye for what matters is sharper, and the appetite for life somehow went up instead of down. The silver hairs came with the package. Fair trade.
The nerd never logged off. Series, films and books fill a good part of my free time, with The Lord of the Rings near the top of the list and Star Wars right next to it, old school. History is the other rabbit hole. Hand me a good book about how something really happened and the evening is gone.
Wine and good food are a serious passion. A good bottle, a well-made meal and good company make a near-perfect evening, and travel puts it all on the same table: new places, their cuisine, their wine and the history behind them. It’s also the best garbage collector I know for a brain that spends most of the day inside systems.
Home these days is São Francisco de Paula, in the Serra Gaúcha, in southern Brazil: araucaria forests, real winters, a fog that can turn a sunny morning into a mystery in about ten minutes, and wineries within weekend range.
Outside the technical details, I write about life as a programmer: focus, self-doubt, mental health and the strange things we find funny after spending enough time with software. I enjoy the work, especially when I can build something useful with people who care about doing it well and can still have a laugh along the way.
Building intelligent systems. Staying human.
