Diego Pacheco Tech blog

Burning tokens is a double-edged sword. Powerful weapons can either give a lot of leverage or drag you down. It's easy to think that you are not shooting yourself in the foot with unlimited tokens. The thing is, you won't be shooting yourself in the foot; you will be expending a lot of company money and perhaps with lots of amplified waste. But only if you do it wrong or don't know what you are doing, and that's the very tricky part. Big Tech and big companies already have unsustainable token usage, like Uber . The list goes on and on: Microsoft , Walmart , Meta , JPMorgan , AT&T , and many others. For some, tokenmaxxing is over. Is it? Really depends on the cost of inference. Jev is showing that a classifier can be powerful and reliable, at least in the sense of low cost and speed, not saying anything about accuracy, which is not the score. The problem is not using tokens; that is the symptom. The problem is a lack of training; there is a huge AI enablement GAP ...

AI Slop is everywhere. Technical debt always existed, but sure, slop will surpass it; somehow we managed to make things worse: Human-generated, handcrafted tech debt blended with synthetic AI generations. I won't say productivity is up because that's hard to measure; for sure, output is up, but so are bugs and incidents. The less you look at the code, the less you pay attention, the more slop you get. Attention is all we have; it's precious. The catch is, to produce more, you need to look less. It takes 5 minutes for the agent to produce the code and 5 hours for you to validate and understand. Multiply that by several PRs a day, and we have a big attention problem and slop proliferation. AI Slop Definition I think it would be fair to ask frontier LLM models what they define as ai slop. I had to ask to be max 2 lines; otherwise, it would be slop 🙂 GPT has the most interesting definition for me, specially because it mention judgement and quality. IMHO what we are also missin...

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. 

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. 

Have you ever tought about the difference between a Senior and a Junior? IMHO, the best definition is that the Senior can figure out things by himself, deliver his work on time, and even teach others. A junior requires much more help and takes much longer to deliver. It's very common for companies at scale to not hire juniors. Usually, managers expect only to receive senior engineers. That works well until you start hiring juniors, because now, the things that were working just stop working. Have you ever thought about the key thing that would make the junior more productive and start getting more senior? IMHO, it's understanding. In the technology field, we think we can hack things, but in reality, we can only do a decent job when we understand what we are doing. It's impossible to make sense of software if we do not understand what's going on. What about AI and LLMs? They might allow juniors to finish narrow and straightforward tasks, but they will likely not be learn...

Let me remove the obvious issues before I make my point. Ignoring problems is bad; ignoring problems at scale is even worse. If we have a network effect of ignoring things at scale, that's the worst thing we can do. Ignoring problems leads to Ignoring culture . Being aggressive with problems is not being reckless; it's not about moving so fast that we break things by doing it so. When applying for software, we ask some apparent questions but sometimes forget to apply for people. In software, we don't want to discover all the bugs in production; we want to shift left and find as many problems as possible before going to production. We must apply the shift left to people and address the issues immediately. The sooner we find problems, the sooner we fix them, and the sooner things improve. 

July 2024: I wrote the first blog post about The Dark Side of LLMs . During these 7 months, many things have changed; the usage of AI and LLMs in engineering has kept growing. LLMs and AI are cool. However, they are not a free lunch and have consequences. If you have not read the first blog post of this series, go there and read it because it will be relevant to this one. One significant open-source development in LLM was  DeepSeek .DeepSeek is interesting for two factors: one that is considerably cheaper and second that is open source. Deepseek introduced a series of optimizations like parallelism, chain of thought (COT), which step by step so we can fix the model where is wrong and usage of Reinforcement Learning (RL) along side with Destilation. RL is how robots roll and self-driving cars also move in a city.  Deepseek's being open source is great for the community; however, we also see interesting moves from big tech companies like  Meta ,  Microsoft ,  Goog...

I have been doing practical and real software architecture for more than 20+ years. Software architecture is a great passion of mine, close to my heart and even to my identity or just id function if we think about functional programming :-). I have mentored and coached many architects during the last two decades. Today, I want to share some thoughts on something that represents the complexity and duality of the software architect role. Being an architect is not easy, it requires a lot of sound judgment, trade-offs analysis, design skills, research, requirements extraction, trend prediction, futurology, and lots of non-obvious skills. Architects must code, be practical, and make very good calls, resulting in better positioning for the future. Doing such a task is not easy and requires a lot of hard work; it's demanding and requires constant improvement and attention to detail. What is essential to extrapolate an architect's non-obvious antagonistic skill set, which the architect...

I love feedback. I believe in feedback a lot. However, not all feedback is good, not all feedback is applicable, and not all feedback is fair. Feedback is critical for course correction and growth. However feedback can be manifested in a variety of shapes, forms and intentions. I believe in creating several mechanisms for feedback because, eventually, what needs to be found will be found. Feedback is a signal; sometimes, it tells more about who is giving the feedback than the person receiving it. Other times, feedback is just wrong. Whether feedback is written or bad, it's an important signal. I believe in being more effective and in the speed of change and improvements. However, can you go fast if you dont understand what you are doing? That's my issue with feedback. Oftentimes, feedback is poorly constructed and missing essential details. So, dealing with feedback is not so different than handling high-priority, difficult production bugs. Requires deep tought, introspection, ...

Quality often means something different to each person. My definition of quality revolves around technical excellence. To achieve this, we need good architecture, sound design based on strong principles, good code, tests in a wide variety and diversity, and proper observability. To get there, we need refactoring(a lot), and I would also include good troubleshooting and review sessions.  Quality involves not only delivering automated product deployments but also ensuring the software is maintainable. Delivering software on time is not enough, and delivering value to the customer is not enough either because people and software are expensive. We need to do better.  Quality needs to be built-in, a strong, solid lean principle. However, we don't have as many incentives to built-in quality as we do for finishing projects on time. Projects are always associated with direct value to the company, and quality is often optional and mismanaged. Quality does not mean QA, and it's way beyo...

After 7+ months of hard work, my third book is out. Introducing:  Continuous Modernization : The never-ending discipline of improving microservices, monoliths, distributed monoliths, individuals, and teams at scale. Modernization is something I have done over and over in my life. Modernization is something that all companies need and will always need. The need for modernization will never go away, even with LLMs and AI. Technical debt, Anti-patterns, and bad decisions do not take days off. Complexity never shirks and continually grows. Companies do not stop getting bigger and doing more and more software critical to growth, delivering value to customers, and staying competitive and relevant in the market. We need a better way of doing software to drive the best outcomes out of us. Continuous modernization is the counterforce to technical debt and anti-patterns. Continuous modernization is how to continually improve, even when you think it's impossible and nothing can be done. We ca...

IF you did not watch the Netflix show: Downfall the case against boing . Please drop everything, go watch it, then come back to my blog post. You really need to watch it. I've been following the 737-MAX drama closely since 2019. Now if you watch the Netflix show and read this link . You will see why I'm doing this blog post. Because I believe there are valuable lessons we can learn from software engineering. Let's first review the technology industry's state of affairs: Waterfall projects are everywhere, thanks to SAFE. Technical debt is never so high, and the tendency is to get even worse over time. LLMs are great but also a great way to add more technical debt faster into the systems. Now, if you think this is a rant, you are wrong. IF you think I'm overstating that SAFE is evil, go read this about what the Agile co-creators said about SAFE .

Today career frameworks are a thing, they are pretty popular along with culture handbooks. Career frameworks are an interesting compass no not only to grow up on a company ladder but also to understand what the culture is and how to be effective. Of course, the paper accepts anything and you might write down beautiful things and have a completely different culture in reality. Besides that the fact that your writing down helps to achieve clarity and spread the word. Especially in REMOTE times like we live today where we have little to zero physical contact. Today I want to comment on 3 career frameworks and also see some similarities and opportunities for us to learn.

Holacracy is an organization system where authority is distributed with self-organizing groups. I first heard about these ideas back in 2013 through Zappos's book . Culture is delicate and often moves much slower than technology. As generations are changing some values are slowly changing. Even COVID-19 is shaping how we live and do business. Holacracy has interesting properties, IMHO is all about the people, having the right talent might work in almost of forms of management systems, of course, the lots of great engineers don't care about what management systems they are in but others do. Today I want to share a slidecast I made sharing some ideas about Holacracy.

I want to share my cents about the post: " On the Diverse And Fantastical Shapes of Testing ". First of all, I believe this is a very interesting subject and yet still see very few engineers talking about it. People mostly take tests for granted. Secondly, I would like to acknowledge the parts I agree with on this post mainly around the concept of Sociable and Solitary Unit Tests are quite useful and show be widespread. Also with the need for teams to have reliable, fast, Bounded(Isolated) and not Flacky on Justin tweet . Now that I acknowledge that, let me elaborate on what I think we are missing and why IMHO the pyramid is dated and we need a mentality shift. I have 4 points I want to elaborate on and give more context.

Security is the new black. Years ago Tests were not widespread as they are today and the same happened with DevOps where automation, Infra as Code, Versioning become the norm today. However, for security, we are not there yet. I believe this will change in the next years and more and more security is a concern where the teams need to care about and understand more about. Security can be pretty scary but at the same time is not rocket science and you can learn it for sure. Today I made a slidecast which I want to share with you guys and go over the security principles, common vulnerabilities and attack vectors, culture, trends, and much more. So Let's get started!

Every company has a legacy code. Often we confuse legacy with multiple different concepts, and this confusion makes improvements harder to happen. Most engineers don’t like to deal with legacy code-we all like shiny new things. Unfortunately, most of the time, there is no easy way out. It is possible to replace a legacy system with a brand new system because it is easier and faster than fixing all the legacy’s problems. We can’t get out of legacy systems because they have old languages, old databases, and often messy. Is that so? However, there are 2 kinds of old languages. The ones who are dying and dated like Delphi or Clipper and the other ones are old but are perfectly fine to use C++ or Java. I’m not defending legacy systems; however, I believe several essential aspects need to be considered. Old: Mature vs. Dated Commonly, we confuse mature software with dated.  Boring technology  is full of good arguments there. Old technology not necessarily means it is terrible. ...

Every company out there works with teams. There are all sorts of teams such as teams specialized in technology stack like Hadoop or teams which are domain-driven and have cross disciplines( Cross-Functional Team ) inside such as backend, frontend, QA, UX, Architecture, and more. People don't leave companies they leave teams, also it would be accurate to say that people don't join companies and they join teams. So should we have dynamic or static teams? Should teams self-assemble or should we have PMO doing that? Should the teams be stable or should we allow dynamic reteaming? Is work always fitting well in our team's structure? What about Platform vs product teams, which one is best? Should we just pick one model or should we use different models? Should engineers organize around managers or managers organized around engineers? Teams affect Architecture and our perception of ownership. Teams should be a people organization but often is just a grouping of people where everyb...