Diego Pacheco Tech blog

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

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

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? 

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

 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!