Diego Pacheco Tech blog

Imagine you are coaching a basketball team. You want to train your team to be good at 2-point shooting from the inside. Now imagine for some weird reason you can't test that, and you need to play a whole 4 quarters basketball game in order to be able to maybe, with a lot of luck, score 2 points. That would suck, right? This actually sounds insane because we all know we can skip the whole game and just train 2 points from inside right? Well, what IF I told you the basketball game is often a people test software, and they cannot train exact scenarios (State Induction), and they actually need to test the whole thing (expensive E2E testing). What if we could write tests in a very different way, so that it would allow us to have massive parallelism, and perhaps multiple people could test the same thing at the same time, and it would work.

From time to time, the industry has a breakthrough, and things change. Sometimes the improvement is incremental, and other times it is very disruptive. Not all change stays forever; actually, new technologies tend to die sooner than old inventions like dishes, forks, knives, spoons, glasses, and many more. I remember web services dominating the corporate universe until rest came and put them to almost extinction. I remember EJB rise and fall like a flash, Netscape, and many others. Those transformations are not new, and they do happen from time to time. Before AI, we had other movements and other breakthroughs like DevOps, Cloud Computing, Agile, Mobile Phones, the Internet, and the Personal computer. AI, perhaps, is the most disruptive force we have seen so far. No other technology or movement has such mystique as AI does. Some call it the Genie; others, the Revolution of the machines (Skynet); others think it's AGI already. One interesting effect we see at this point is that AI b...

For a long time, software engineering had a stable way of doing software. Yes, not all companies had the same level of maturity and properly digested previous movements like Lean, Agile, and DevOps. However, right now we are living in a quite interesting time when we are reconsidering what we know and what worked in the past in favor of perhaps a better way to build software. Fully acknowledge that we don't have the answer to what the winner is yet. Many industries are being disrupted by AI, but no industry is being more disrupted than technology itself. We never saw anything like what we are seeing right now. The only way to go forward right now is to experiment, read, socialize, and reflect on what works and what does not work. 

AI might reshape how engineering works; there might be different workflows and different ways of shipping software. We have good and solid foundations in engineering, which are still relevant and can still guide us even in AI agentic times. If we go back more than 30-20 years, the traditional way of building software was highly influenced by RUP . From RUP come phases, roles, responsibilities, and structure. However, there was also waste, handoffs, a lack of focus on coding, and even a waterfall approach. After the agile movement, we learned that software could be built more effectively. Before we even start talking about AI and agents, we need to understand that companies have different levels of maturity and might not be all up to date with previous waves of innovation, such as Lean, Agile, DevOps, Lean Startup, and now AI Agentic Engineering. IF we look at the last almost 30 years of software engineering, we can notice a time called shift left. The idea is to pay more attention to q...

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...