Code is a means,
not the end.
I help engineers and teams make better technical decisions in production.
Especially now that AI makes code cheaper, faster, and easier to generate.
The challenge isn't writing more — it's deciding well and keeping shared judgment across the team.
I've mentored engineers from
Over 100 engineers from these conferences and companies have worked with me to level up their careers
What I fight against
These are the enemies that hold back engineers and teams
Technical purism that paralyzes
The one that tells you that you need the perfect architecture before writing a single line of code. The one that turns every technical decision into a three-week philosophical debate.
Over-engineering that adds no value
Microservices for an MVP. Kafka for 100 users. Seven-layer abstractions for a CRUD. The complexity that impresses at conferences but sinks teams in production.
The "that's not my job" mentality
The developer who hides behind code and refuses to understand the business. The one who believes their responsibility ends when the PR is approved.
Managers who turn engineers into feature factories
Those who turn talented engineers into feature factories. Those who measure productivity in lines of code and closed tickets.
I help engineering teams build software that lasts.
I've designed systems that move real trucks, manage physical inventory, and serve millions of daily customers at Spain's largest retailer. I don't talk about architecture in the abstract: I talk about architecture that moves lettuce.
I've seen what breaks at scale. What keeps teams productive. What separates maintainable systems from technical debt. And most importantly: I've seen that most software problems aren't technical problems — they're process and team problems.
I actively research development methodologies because I'm obsessed with one question: What do teams that consistently build great software do differently?
Staff Engineer
Leading software architecture for Spain's largest retailer
Research
Software Engineering Methodologies
Researching how great software is built and maintained
International Speaker
Software Engineering Conferences
Sharing knowledge about software design and team leadership
The truths nobody tells you
What I've learned building real-scale systems
The best code doesn't need a translator
If your code requires a 200-page manual to understand, you've failed. Clarity is not optional: it's what separates code that evolves from code that gets rewritten. A team that understands the code is a team that delivers with confidence.
Product-oriented seniors fix systems, not just bugs
Anyone can put out a fire. Senior engineers redesign the system so that fire never happens again. They don't obsess over isolated features: they think about complete flows, sustainability, and long-term impact.
Most "technical debt" is team debt
Lack of agreements. Bad habits. Diffuse ownership. Broken communication. Code is just the symptom. An aligned team improves the codebase without needing heroes or complete rewrites.
Software in production is the only useful truth
Perfect diagrams and six-month plans don't survive contact with real users. I prefer shipping and learning over planning indefinitely. Resilient systems grow with short cycles and reversible decisions.
If change is scary, the problem is the design
When modifying the system requires three weeks of planning and a prayer, something is wrong. Good software is built to evolve. Change shouldn't be a threat: it should be part of everyday life.
Learn to think about product, not just code
No React tutorials. Strategy, product vision, and soft skills for tough engineers.
Every week I share practical ideas about architecture, system design, and technical leadership.
Latest reflections
View allThe seven unwritten engineering laws AI is making more expensive
This week I watched a teammate ship nine PRs in a single day. Solid work, AI-assisted. Speed is what we celebrate, but the unwritten rules of engineering, the ones you only learn by breaking them, now charge you sooner and bigger. The seven laws, and how AI changes the math on every one of them.
The DNA of software wasn't a concept. It was 24 files.
Three weeks ago I argued that code was going to become disposable, and what would matter is the DNA of the software. I locked myself in to check whether that idea was actually writable. What came out: 24 files, two regenerations for less than a euro each, a public repo, and a lot of clarity about what harness engineering still doesn't solve.
Your LLM passes the benchmark and fails in production
Generic metrics tell you if your LLM is wrong, not if it's wrong for your business. Why evaluating LLMs is a domain problem and how to tackle it with LLM-as-a-Judge.
Tools for senior engineers
These aren't tutorials. They're practical tools that solve real communication, documentation, and technical strategy problems.
Code is cheaper than ever. Bad technical decisions are not.
I work with engineering teams that want to improve how they review, verify, document, and make technical decisions in the AI era — without turning software delivery into chaos or slowing everyone down with process.
- AI-assisted PR review
- Technical decision-making
- Invisible technical debt
- Architecture, ownership and shared context
Want your team to think differently?
I run private workshops for engineering teams that want to improve technical decision-making, AI-assisted review, and shared engineering judgment. No generic AI training. No prompt tricks. Practical work on how teams build, review, and operate software in production.