The fun in agentic development

Like many others, I was interested in software and technology from an early age. When the PSP came out, I was all over the modding scene and even became a moderator of a PSP hacking website when I was 13. This tech savviness lead to me being the appointed fixer of the PCs and other technology around the house. At first this was only within our family, but then it became something I’d go around the neighbourhood for. At a certain point I remember even colleagues of my father giving him their Windows Mobile phones to take home for me (the old ones, that had a menu bar and were terribly slow) and me doing some sort of software modifications to them.

Now, after a decade in software, of which the last years have been quite turbulent with the whole AI boom, I’ve been thinking back on what makes it fun for me. Now that there are many tasks for which we don’t need to write code ourselves, is working in software still as much fun as it was when I started?

I’m still not sure. We don’t know how the workflow of the average engineer will evolve and what it will look like in a few years. But when reflecting, I figured there has always been the common theme of solving problems and optimization that I’ve been interested in. When dissecting anything you do in software, there is always a problem and an expected situation. And you need to figure out the best way to get from the as-is to the to-be. Whether that is some random (at the time already archaic) Windows Mobile phone that needs some obscure modification done to it, a PSP that needs to be jailbroken, or a feature that needs to be delivered to the enterprise application you’re working on. The question is then:

Does agentic development still offer the same problem solving and efficiency improvement mindset?

And so far for me the answer has been yes. Even though the introduction of LLMs has made the world a lot less deterministic for a software engineer, I still enjoy the optimizations I can implement. And in the end, there is still a to-be which we want to reach. The day-to-day tasks we perform however have changed a bit.

Whenever you do anything, be it with agents or when writing the code yourself, you always need a proper understanding of the end goal and what’s needed to reach it. Instead of going directly to the code to try and implement the to-be directly like I used to, I now often start off with a grill-me-with-docs planning session. Before, the complete understanding of the issue I was working on often came during my implementation. Today however, this has shifted more to the start where the grill-me session uncovers many unclarities beforehand.

In terms of optimization, in my workflow I’ve now set it up so that the context that is injected at the start of this session only includes general information and pointers about the application. There is also a more extensive context available that the general info points to, which the LLM can use if it needs more info. For most tasks the general info is sufficient and provides enough pointers for the agent to perform its tasks, which reduces context size and reduces token burn. I enjoy optimizing this workflow to ensure the agent has enough context to properly perform their actions, without it becoming too big and becoming less useful ¹. These are just two of the most recent things I’ve been working on. I have experimented a lot with skills and agents but haven’t yet found a complete workflow I’m satisfied with.

There are however things that have been lost along the way. I used to enjoy really digging into a subject to get a proper understanding of all the details, but that has become a bit harder recently. Easy access to the flawed oracle of LLMs has made it more difficult to just read documentation, search online, and come up with your own solution that you think is best. I still try to go that route for the subjects I have no clue about to get some context and understand the details. But still I reach for the LLM to verify my implementation and see if I’m not hallucinating. I would assume this pattern of having AI verify your work before you share it with others is quite prevalent in professions where imposter syndrome is as common as in SWE.

This is still one of the best ways to learn for me, thinking about something, doing investigation, implementation, and then having others comment on it. But that was always very vulnerable since you could have completely missed the mark that way. Having an LLM available that just checks your work first removes this vulnerability, but in turn also makes the review have less of a lasting impression on you. Whenever someone knowledgeable would check your work and have negative feedback about it, it would really have an impact on me. And that is lost by having an oracle reviewer like we have now. This is one of the reasons I write these articles without any AI. But I did however let it proofread this.

Even though I still like the problem solving and the efficiency improvement part of the job, I have noticed that I’m missing the human reviewer part more than I’d like to admit. Sure, it would open my reasoning up to criticism of others without knowing beforehand if I missed the mark or not, but at the same time having an LLM tell me I could do better has far from the same lasting impression on me as the knowledgeable colleague doing the same.