Bernardo Secades
Backend engineer — Go & distributed systems. I build with AI in production and write about what actually works.
Software engineer building backend microservices in Go. I focus on distributed systems: service boundaries, event-driven communication, and finding the right balance between simplicity and resilience.
I have Claude Code wired into my daily workflow — it's open whenever I code. I use it for reasoning through service designs, catching subtle edge cases during code review, drafting migration plans, and speeding up the boilerplate-heavy parts of Go so I can spend more time on the interesting constraints.
Beyond personal use, I've been working on cross-team adoption: sharing patterns that work, running demos, and building shared conventions so the whole team can get consistent value out of AI-assisted development without each person reinventing the wheel.
Reviewing AI-generated code: what I check before I trust it
AI code fails differently than human code: it's plausibly wrong, not obviously wrong. It reads clean, the tests are green, and the bug is in the seam it couldn't see. Here's the checklist I run before I trust a diff I didn't type.
Picking a model: stop defaulting to the biggest one
The instinct is that the biggest model is the safe choice. But for classification, extraction, and routing, the cheap tier is usually indistinguishable on accuracy and far faster — and when accuracy is short, the fix is often a better prompt, not a bigger model.
The day AI nearly shipped a bug to prod — and what I changed
A clean AI diff, a green test suite, a confident explanation — three green lights, and I almost approved a double-charge bug. The lesson wasn't 'don't use AI.' It was that the code, the tests, and the explanation all came from one model, so they never corroborated each other.