Reflections on software engineering, technical leadership, and how to build systems that truly matter.
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.
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.
Join other engineers who receive reflections on career, leadership, and technology every week.
This newsletter is written in Spanish.
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.
If regenerating is cheaper than maintaining, the rational strategy isn't to care for the code. It's to make it disposable by design and invest in what isn't disposable. The future of the engineer is writing DNA, not code.
AI agents are expanding the capacity to ship software faster than organizations can generate and validate ideas. The bottleneck is shifting from engineering to ideation and validation. The answer isn't to slow down or speed up recklessly — it's to redirect surplus capacity to where it creates value.
My personal manifesto on the future of software engineering. Not an analysis. A direction.
Individual discipline as a quality system is a fragile design. Tests scaled because they became infrastructure. Verification needs to do the same.
Anthropic separated the agent that generates from the one that evaluates, and quality skyrocketed. That pattern describes the future of software engineering: generation is commodity. Verification is craft.
AI multiplies your analytical capacity, but it can atrophy your thinking if you don't use it with intention. Three scientific studies and real-world experience from a Staff Engineer who uses it every day.
During Fallas I built València Respira: a real-time visual installation with eleven layers of live data. This article covers the technical and design decisions behind the piece, and what I learned building something that doesn't fit into any category.
Teams getting real value from agents don't have magical models. They have verification loops that catch failures fast and force correction with external signals.
When a senior hoards knowledge in their head, the team is left without a safety net. With AI accelerating code creation, sharing context is no longer a nice-to-have -- it's a critical responsibility.
Dario Amodei says AI will replace engineers in 6-12 months. Jensen Huang says we shouldn't learn to code. I've been thinking about this for months. I don't have all the answers, but I do have a stance.
Senior engineers resolve incidents faster, but they can't explain how they do it. Gary Klein discovered the same thing with firefighters in 1984: tacit knowledge is built through experience and can't be easily articulated. This matters now more than ever.
AI writes code faster than ever. But there's a trade-off almost nobody talks about: we're exchanging development speed for operational opacity. And that exchange isn't free.
The classic senior engineer -- extreme depth in one stack, focused on implementation -- is becoming obsolete. The natural evolution is becoming an expert generalist: real technical depth with the breadth of judgment to connect technology with business.
Integrating AI without a rigorous business case can turn a great feature into a cost nightmare. Here's how to estimate better and optimize tokens without sacrificing quality.
Almost everyone uses AI to code, but very few always verify the code these tools generate. This creates a verification debt that could get very expensive.
Technical purism doesn't pay the bills. Learn when to prioritize speed, when to invest in architecture, and how to use technical debt strategically.
There's a phrase that appears with unsettling regularity in multinational companies: "We sell the same products in multiple countries. We should have a single catalog."
The Knight Capital story and the 7 unmistakable signs (like the Bus Factor or Friday deployments) that your service is on the verge of collapse.
Software that doesn't solve the problem it was created for is worthless. Discover why tests are the only guarantee of value.
"It worked on my machine." Ownership is what separates just another developer from someone who actually builds product.
Is technical debt bad? Spoiler: No. But there's a catch. Learn how to manage it using the kitchen and in-laws metaphor.