Diego Pacheco Tech blog

Almost 3 years ago, in 2023, I wrote a blog post about the death of code review . It hasn't been that long, but software engineering has changed a lot in the last 2 years, and there is a tendency to change even more in 2026. Back in 2023, I was not even talking about AI being the "killer" of code review; it was a series of things: people not paying attention, LGTM without any effort, and a lack of prioritization. So we need to understand that code review was always an important practice, but even without AI, it was already in decline, and people were doing it wrong. Back in 2026, there were even stronger forces pushing code review to die or to change significantly. Most engineers dislike doing code review. I do like code reviews. I found code review useful and an important tool to enforce consistency. However, the disruption with code reviews is inevitable... 

IF you talk with engineers, software architects, managers, pretty much everyone, the answer will be the same: they are not happy with shared environments. We can narrow down shared environments to common envs like dev, test, stage, demo, etc Pretty much all non-prod environments suck. That is the reality in our technology industry. I don't think I ever liked any env in any company, so think about this: did you ever see a non-prod env that you liked? Now the answer for this problem is very weird because if you talk to people, what do they say you you? IF we could have one more environment them we would get it right. So my question is, why can't we get it right in the environment that we have in the first place? Why do we need a new one? In fact, we don't need it. 

PMI has a whole discipline about risk management. The DevOps movement has several principles to reduce operational risk, such as continuous deployment, infrastructure-as-code, progressive rollout patterns, traffic splitting, and more. Financial institutions might terminate or restrict business relationships with clients and even categories of clients to eliminate risk, hence derisking. Risk management was very popular in the 90s and even 2000s, but it's not dead, IMHO. Nobody talks about risks, nobody even monitors risks. I don't know why that happened or even if it's true for other industries besides technology.  The DevOps movement teaches us many things, one of which is post-mortem or blameless incident reviews. However, incident reviews are great practices if done right, meaning having engineers on the call and actually driving lessons learned for real.  Besides that, the problem is that we are having after the fact, which only prevents feature problems if we do our hom...

Distributed Monoliths are a significant source of technical debt and a major anti-pattern. Distributed monoliths have the worst of both monoliths and Microservices . It's very easy to create distributed monoliths because often people don't learn proper principles, and mistakes keep happening over and over again. Distributed Monoliths are everywhere: on DevOps solutions , on the Frontend , even in Data . Why? Because we still don't add proper isolation in systems. Now Distributed monoliths will happen with AI and Agents or "Agentic" solutions. Let's understand what's going on and how we can protect ourselves from another disaster.

Rainy Days Some places have more rain than others. Some cities or regions have rainy seasons; one way or another, rain will happen. Either because it is in the season or because the players are traveling to play, and there is rain where they are right now. 

I wrote my 5th book! The Art of Sense: A Philosophy of Modern AI - take a look here . This book is free; it's me giving back. I hope you like it. It's my second git book; the first git book was SAL . AI is one of my new passions; this book will help you in your journey. If you are not a data scientist, this could be a good starting point. If you are already a scientist, it could be a chance to learn something new from someone with an architecture/engineering background. You don't need to be a data scientist to do AI, especially in engineering nowadays. So even if you are a scientist or a researcher, this book might give you food for thought. This book is Free.

Many people think that today, Gen AI is the revolution of the machines. That AI will make an engineer 3-5x more productive. Well, that’s not true and not even close to being true. Let’s pretend it’s true for one moment, then we can apply some scale economics to Generative AI, especially with AI coding agents like Claude Code or OpenAI Codex.   Let me be honest: I don’t think that using AI you can get 3-5x the productivity from engineers right now. There are so many things I need to debunk here; it’s even hard to choose one to start with. But for a moment, just. For the sake of argument, let’s believe it's true(just for a moment). That will help you to understand why AI has suddenly become so appealing to companies.