Two decades in software
I started writing production code in 2005 — well before AI agents, well before cloud-native, well before half the languages I now use existed in their current form. Over those years I've shipped real-time multiplayer games on Node.js + WebSockets, a browser strategy game with around a thousand active players on a LAMP stack, a crypto trading bot in Python, and twenty-five-plus client web projects from 1998 onward.
That long tail of production experience is the lens I bring to every modern problem. Architectural taste isn't a parameter you can crank up; it's a habit built from years of fixing the consequences of bad decisions.
Where I am now
My current focus is production AI systems — from single LLM-in-the-loop apps up through multi-agent architectures, with the data layer, evaluations, and operational discipline around them. The mix shifts with what each engagement actually needs; the through-line is "design what should be built, then ship it well."
Since March 2025 I've been a Senior AI Engineer for a US-based biotech client building autonomous AI systems for scientific research — working across orchestration patterns, tool-use design, memory and state management, security boundaries, and performance trade-offs, plus the implementation that turns the design into working software.
I built a specification-driven AI development methodology that turns a written spec into a working system rapidly and reproducibly. I built the evaluation framework — public benchmarks plus custom internal scenario suites the system never sees during development. I built custom MCP servers (Stdio, SSE, Streamable HTTP) bridging LLMs to proprietary tools and secure execution.
How I actually work day-to-day
I rarely write code by hand day to day anymore — I still can when a problem genuinely needs it, it's just no longer where my time goes. I direct coding agents — Claude Code on Opus — as the implementation layer, while I own architecture, methodology, and quality. This site is itself an example: the entire monorepo, the FastAPI backend with clean-architecture layers and Protocol-based DI, the Next.js frontend with i18n routing and Tailwind v4 design tokens, the Google OAuth flow with signed state and opaque session cookies, the multi-stage Docker builds, the Alembic migrations, the Railway deploys — all of it was directed, not typed.
What does that mean in practice? Two decades of systems judgment go into designing what should be built. Daily agent practice gives the velocity to actually ship it. Spec quality becomes the new bottleneck; the discipline transfers from "write correct code" to "write correct specifications and review correct code."
I solve the business problem, not just the ticket
I’m full of entrepreneurial drive, and it changes what I optimize for. I’m not here to “work the work” — to do tasks or push code for its own sake. I’m here to solve the problem the business actually has. Years of running my own ventures trained me to read any brief in terms of interests, costs, and outcomes rather than a list of tickets — so I can tell which work moves the needle and which only looks busy. And I run independently and systematically: give me the goal and the constraints, and I’ll own the path to it end to end.
Fundamentals first — especially in the age of coding agents
In engineering I default to fundamentals: clean structure, the right abstractions, principles (SOLID, DRY, KISS) that compound over the long run. I save spontaneity for creative work, where it belongs. A throwaway prototype can be fast and loose — that’s fine, for a prototype. But the moment code is meant to live, skipping the principles isn’t a shortcut; it’s debt with interest.
The calculus has shifted, too. With coding agents like Claude and Codex generating code at the speed they now do, shipping sloppy code is simply unjustified — clean principles up front are exactly what let the agents (and me) move faster, because well-structured code is cheaper to read, extend, and hand back to an agent. Good architecture is now a velocity decision, not a purity one.
I trust metrics, not vibes
I have an eval mindset. I don’t ship on a feeling that the code is probably fine — I verify what I build, measure it, and read quality off metrics and tests. If I can’t point to a number that says it works, I don’t call it done. It’s the same instinct my ventures beat into me: the thing that kills you is the number you refused to look at.
Earlier work
Before the biotech engagement I built several LLM-powered SaaS MVPs from zero as the sole engineer: an AI consultation marketplace (Telegram bot + Flutter app) and Contento(an LLM-driven script generator with prompt orchestration) — design, implementation, integration, release. Separately, on contract, I built a Telegram e-commerce app for BOTTEC with payments, logistics, and warehouse integrations. Stack: FastAPI + PostgreSQL + Celery backends, Vue/Nuxt frontends, prompt engineering and LLM integration end-to-end.
I also built an AI-augmented multi-strategy trading system in Python + Docker — backtested across 53 crypto pairs over three years, with walk-forward adaptive strategies and per-asset trend filters.
What I'm looking for
Conversations with founders or CTOs who are putting AI into a production system and want a second pair of eyes on the architecture. Long-form consulting engagements where the work is to design what should be built, not to type lines into a file. Senior AI engineer, senior developer, or AI architect roles at companies where engineering quality is taken seriously and "ship it" is the second sentence, not the first.
Based in Uruguay (UTC−3) with US time-zone overlap. Available remote.