Diego Pacheco Tech blog

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.

Software engineering keeps changing names for the same old problems. Before 2023, changes were introduced with some level os stability; now, changes happen much faster, to the point that we do not really understand the problems. We had those problems in the past, considering things like (agile/scrum, microservices,  devops), but never has it been a fast loop like this. First, we had scripting. Then automation. Then CI/CD. Then DevOps. Then Platform Engineering. Then AI Agents. Now we have Loop Engineering. However, companies have barely functional CI/CD due to a lack of incentives, poor vision, poor management, and other dysfunctions.  Loop engineering, the name is new. The problem is not. The problem is: how do you make a machine do useful engineering work without babysitting every step? That’s it. But "solution" and "waste" manifest in the same way, using the same tools. Loop Engineering is not just about prompting with a fancy jacket. It is not “write a bette...

Harness Engineering is pretty trendy at the moment. Harness engineering is a way to better drive or operationalize an LLM model. The idea is that you are renting an LLM model as a service, but you own the harness. The harness is a way to be less dependent on the model (LLM). LLMs are not deterministic at all, and they are not general intelligence; they are pretty limited to their training data. Inference cost is very expensive, and the era of subsidizing is over .  AI was sold as a promise to solve engineering and elevate us to a new level of abstraction, and so far thats far from being a reality. I keep hearing people say "wait two years" every year. More and more engineers spend more time trying to drive LLMs to produce the right code. When that is well executed, we can see 10-30 % productivity gains across our industry. Such good execution results from proper testing, robust CI/CD, great automation, amazing observability, and attention to technical excellence. When that is...

AI everywhere, agents everywhere. We just finished the first quarter of 2026, and a lot happened in those first 3 months. It feels like 3 years have passed, not three months. Opus 4.6 really changed the game, but software engineering and distributed systems are not solved by agents; we saw hype at the top of the hype, with huge,  unrealistic expectations that need to be dialed back and properly adapted. The less you know about AI and Agents, the more impressed you are, and no, you cannot get rid of all engineers. AI Alone does nothing and cannot self-verify to the point that systems of systems can be completely automated and run hands-off. Maybe we will get there one day, but we are not there, and no matter what people say, no one can predict when this will happen. Could be 30 years or even more. Karparthy already said that: Zero to Demo is easy . Demos are not impressive anymore. Zero to production is still a very different story. Multi-Agent Systems: Process as Agents Pad...

Engineers never liked doing code reviews. Especially if there were lots of files, you got fewer reviews. That was so 2023. Today, in 2026, AI Coding agents generate most of the code, and the code review problem is much worse than it ever was. Paddo captures very well the disaster that is Amazon Kiro and Spect Driven Development. Everybody believe that code review is a bottleneck; let's be honest with the anti-pattern of vibe-coding, and when speed beats safety, bad things happen. Many companies are seeing twice as many incidents, including Microsoft GitHub and many others. Safety needs to come first and speed next, not the other way around. Industrial logic got that decades ago with Modern Agile . Modern agile was a second take on the agile movement with the addition of modern concepts. That is not new; in fact, Modern Agile was created back in 2016. One of the principles was "Make safety a prerequisite".  More AI: Means more things to review Many companies and people b...

People building agents today are mostly doing one-shot. Meaning they write one and that's it. Yesterday, I was watching the YC Lightcone podcast: "Inside Claude Code With Its Creator Boris Cherny" and one of the things Boris, creator of Claude Code and head of Claude Code in anthropic, said is that they delete the CLAUD.MD a lot because they want the new models to take over. That insight tells us a lot that we cannot just settle for whatever prompts we have. Besides that, depending on how we write the prompt, we might use more or fewer tokens; there are ways to better structure agents, workflows, and skills. For this blog post, I will cover some lessons learned while building and improving agents, workflows, and skills. I did a bunch of experiments; in fact, I wrote 7 incarnations of my agent skill. To test the agent's skill, I asked the agent to build a Twitter-like application so I could evaluate the quality of the code and solution as a proxy for the agent's s...