Diego Pacheco Tech blog

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

In the summer of 2024, I wrote 300+ AI POCs; in 2 years, I have 550+ AI pocs. Before I cover the lessons learned, we need to address somethings. I've been learning technology for the past 23 years since I started working professionally with software; I never stopped. I always learned multiple languages every year and always liked to explore , even before AI. For 19 years(since 2007), I have blogged about technology. Before AI, I always believed that in the software profession, you need to know what you are doing in order to do it right. I learned languages that I would probably never use in production, just for the fun and sake of learning. I always believed that when you're too narrow in your current needs, you would miss the big picture and opportunities. YES, I always learn and research problems I was solving, but never confined myself to only short-term features. So I was doing POCs before AI, and I will do them after AI. Now we need to understand why POC are getting a bad ...

More tokens are not more intelligence. Still, it is easy to get hooked on token usage. Is it learning, experimentation, or just FOMO? Subscription models trained us to extract as much as possible from a fixed monthly payment. But when more usage creates more code to review, why do we need to max everything out? Are we getting more from AI? Or are we repeating an old consumption habit with a new resource? I was reading and watching Gergely Orosz’s conversation with Dex Horthy, “Context engineering with Dex Horthy” , and it made me think about fast loops, slow loops, token harder, and token smarter. Faster loops do not necessarily accelerate value delivery. Unless the lead time decreases and the value increases, we may be trapped in local optimization.

Ambiguity is not simply having a difficult problem. It is not knowing exactly what the problem is, what matters most, or which direction will create value. It appears during requirements, scoping, analysis, and design—across the whole solution space. It also appears across teams: product, design, engineering, and the business. Ambiguity has always been one of the hardest parts of engineering. Agentic AI makes it worse at scale. A human engineer receiving an ambiguous request may push back, ask questions, make assumptions, or stall. An agent immediately produces something: code, commits, documentation, and a confident summary. The output looks like progress. It may have little to do with the outcome anyone wanted.  We always had this problem, but now agents are a huge employer.

AI coding Agents like Claude Code , OpenAI Codex , and Gemini CLI have disrupted how software engineering is done. IMHO, the most disruptive agents are Claude code and Codex. However, a lot of things already happened, some progress has been made, and there is some evolution in the space. We saw the birth of custom and subagents to avoid passing the whole context window down, custom commands  to have more control over a workflow, or when a specific task is executed. Hooks  add more determinism and make sure tests and linters are executed as part of the guardrails. From the explosion of MCPs to Multi-Agent Systems. There are many interesting changes and evolutions happened, we learned somethings while some things are still to be learned. For this blog post, I will cover some of the evolution in AI coding agents (mainly around Claude code). I did a lot of POC with agents, 74 Agent-related POCs at the moment. One thing I keep saying is that POCs are getting expensive, now not ...

The One does not simply use AI Agents in production. Before using AI agents in production, we need to understand that LLMs are token prediction machines and by nature are non-deterministic . No matter how good you specs are, AI will drop packages and make mistakes. Lack of determinism is just one aspect we need to keep in mind. We also need to keep in mind that it's very easy to jailbreak the models . Adding a chatbot directly to customers has dangers and not only in a security sense, but also for misuse and potentially legal problems. Even if that is all somehow managed and risk is minimized with proper guarantees, one still does not just use agents in production. 20-15 years ago, we would not just deploy APIs to production; we would use an API Gateway. Considering agents and LLMs, we need the same: an AI gateway infrastructure. What happens if your API provider (Anthropic, Google, or OpenAI, for instance) is down? Is your business down? 

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

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

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.

Previously, I was blogging about AI Abstractions and the various levels of abstraction. Now, I want to delve deeper into some patterns we can leverage while writing software using LLMs/APIs and building AI Agents. Many people still question the value of Gen AI, and I understand that, scams, delusional objectives and expectations, FUD, and many other incidents . However, for engineering, it's clear that there is value, and engineering as we know it may never be the same again. Agents are interesting because we can tweak how much autonomy we give to them; they could be bound to a straightforward and repetitive task like bumping the minor version of log4j, or could be used for complex tasks like booking a complete week of vacation with car, hotel, plane tickets, experiences, and plans. So imagine there is a dial that we can tune up or down, and how much autonomy we want to give to agents. Besides open-source models like DeepSeek or Llama , the cost remains complicated. However, clou...

 Java Agents are an interesting capability of the JVM. Agents can either be Static(Load when the java app starts with a special flag) or they can be Dynamic(using the dynamic API from java we can dynamically bind to a specific JVM PID. Agents can be used to run any code before the app starts or even to change the bytecode. The cool thing about agents is the fact that is a runtime thing and we do not need to change the source code of the target app. Agents are similar to Aspects but IMHO much better. Mockito uses mocks in order to test difficult scenarios, pretty much all observability solutions for logs and metrics also have agents. Today I want to share 2 pocs, one using a vanilla java app and doing bytecode manipulation, The second using Spring Boot 2.x and running code forever in a background thread as the app also runs. So Let's get started!