Reflections: 6 months of Agentic Engineering

As many developers today, I'm using agents on a daily basis for software development. At work, we went all-in Agentic Engineering in early 2026 and for me it has worked well.

Not perfect, not 10x, but well and the shift was surprisingly easy. I quickly found that good coding practices are still applicable and relevant. I’m not into that vibe coding stuff, I care too much about the output. What has been occasionally overwhelming is the uncertainty about The Next Step - just like many developers out there I have thought about how we, the Humans, will keep up with the speed of the Agents?

Here's some reflections after about six months of developing software according to Agentic Engineering.

Human reviews have not become the bottleneck. From my experience, human reviews was a bigger bottleneck before Agentic Engineering. We have made efforts in our Team to improve the review flow, to avoid the need of constantly reminding people to review and approve changes. We have made the review process itself more efficient than before.

For me, the ratio of Development time vs Planning and Reviewing is about the same as before. I find myself designing and developing solutions the same amount of time as before the agentic era. In the beginning, I thought it would be the opposite!

I haven't run into the problem of having my agents produce hundreds of pull requests on a daily basis. I know there are people out there doing amazing stuff over the weekends with agents, but I'm not one of them. I haven't yet found a need to rebuild an existing SaaS tool from scratch with AI.

Quality is important. I think it is even more important than before, because an agent will be confused by complex code. Not only that, it will likely produce code that is equally complex (there's research about this available). This will be a downward spiral. Here's where Agentic Engineering is different from Vibe coding. A vibe coder treats the code, the output, as a black box. The risk with that is software that is very difficult to maintain. An agentic engineer keeps their eyes on the incremental result, and steer the agent during the process. The Human decides what Quality is, what is Readable code and what is Simple code (just like before).

Static analysis tools are a great to have in the agentic toolkit. Linters and Unit Tests are as important as before. I have added tooling that reports on complexity and readability issues, and use the Code Health MCP for that. Without the need of human interaction, the agent will verify its result while working and adjust it until the score is healthy before it reaches my eyes. Having static analysis tools doing this kind of work instead of an AI will reduce token spend. Reducing spend will be important in the future as the cost of tokens likely will increase.

Always bet on Open Source. Back in the days, as a .NET developer (when it was closed source and Windows only), developers were heavily dependent on Microsoft. Not only for the framework, but also for most of the tooling. I don't want to go back to that era, and see the same kind of vendor lock-in pattern with the AI providers of today. My tooling of choice is Emacs and the provider-agnostic tool Eca. When Anthropic has its downtime issues, I just switch to Gemini and can seamlessly continue while my colleagues at work are frustrated and post Claude is Down memes.

After six months, I still have a skeptic view on agents and LLMs in general. I simply don't trust the output. But at the same time, Agentic Engineering has made my workflow more efficient and I can more confidently step in to developing things outside of my comfort zone.

Related posts

• Agile and Agentic Engineering
• The tools of an Agentic Engineer
• A workflow for Agentic Engineering
• An Agent- and Human-friendly Architecture

^{Top Photo by me from Hoburgen, Gotland in Sweden.}

A workflow for Agentic Engineering

"- Claude, build the entire Platform from scratch. Make no mistakes."

In the agentic engineering community, some think that 100% test coverage will guarantee the quality of generated code. I think that relying too much on automated tests is problematic, because testing is difficult. I'd rather review the actual source code. More importantly, having an active part in the development of it by steering the agent(s) in real time.

I usually develop a feature step by step, to not focus too much on upfront planning. I used to do this before the agents joined the development process, and have found that it works well today too. When beginning with a new task, I often have some clear ideas and some vague ideas about how to solve the problem. By starting with the things that are clear, I can postpone thinking about the implementation details of the more vague parts of the overall feature. I can worry about that later, when I have learned more. During the development, the how and what to implement will likely change. This is a natural thing, as you learn more along the way and understand more about the actual problem to solve. I guess this is the basic idea behind Embrace Change (from the Agile Manifesto).

I haven't yet felt any need to set up larger Agent Orchestrations for the kind of problems that I solve. It mostly seems like overdoing it, doesn't it? I don't know about you, but we are not building or reinventing an entire E-Commerce or Social Media platform every day. The things we do is on a much smaller and human-friendly scale. I think the idea about 100% test coverage might be about scaling up fast and the assumption that agents will produce so much code, that it becomes impossible for humans to grasp.

An Example

I recently developed a new feature that involved several repos, a combination of Python backends and Next.js apps. I decided to do this in smaller steps and began with the most straightforward step, which in this case was one of the backend services that I already know well. I had a pretty clear idea on what needed to be changed in there and added a simple Solution Design into the ticket.

For context: I used the same ticket for all the development of this particular feature. Each plan an agent produced was submitted as a comment to the ticket. I have automated this with an MCP server connected to the issue system that we currently use at work. It seems like having the relevant data collected in the ticket made the upcoming tasks clearer for the agent(s). Each task begun with a new context, but I instructed the agent to read the ticket that contained the problem to solve, the solution design, previous plans and linked pull requests before planning how to implement things.

It felt like things went pretty smooth. However, the very first task needed several iterations. I realize now that even if the basic setup of that particular repo was straightforward, the service has evolved over time and the structure of it has diverged. I think this is quite common in long-lived repos. This confused the agent, so I practiced the stop-the-line principle by rejecting generated code, correcting and steering the agent in real time. I did this when I noticed that the implementation (the code) went into a direction I didn't like. My agentic tool of choice, Eca, recently added support for a new steer command that is very useful for this kind of workflow. You can change the direction, or steer, while the agents are working. It is not always necessary to halt all ongoing work, sometimes a friendly nudge in the right direction is enough.

Sometimes, unexpected things happen: the other day, the main model I use was unreachable about half the day (again). Oh no. But I just switched to a different provider and continued the work! This is another thing where an Open Source and Provider-agnostic tool like Eca shines.

Another thing that I noticed was that the short summary the agent produced for each Pull Request covered the whole feature and the particular details pretty well. The data in the actual ticket was probably helpful for this kind of task too.

I've been advocating Test Driven Development (TDD) and the sibling REPL Driven Development for many years. The real-time steering, the stop-the-line principle with origins from The Toyota Way could be an Agentic Engineering version of the Test Driven approach. It's about fast feedback loops. What do you think?

^{Top Photo: that's me pretending to do something important on the cell phone, taken at Åreskutan, Jämtland, Sweden.}

The tools of an Agentic Engineer

A lot of great things have origins from the 1970s: Hip Hop redefining music and street culture, Bruce Lee was taking Martial Arts to the next level and the initial development of something called editor macros (also known as Emacs) was happening. I was born in that decade, but that's purely coincidence.

My choice of primary development tool since a couple of years back is that editor from the seventies. It is my choice of development for Python, JavaScript, TypeScript and Lisp dialects such as Clojure and elisp. And today, as an agentic engineer, it turned out to be a great choice for this kind of software development too. With the rise of various CLI, TUI & Desktop based tools for AI development, it would be reasonable to think that this ancient code editor would become obsolete - right?

Not if you knew about the innovative Emacs community. It is driven by passion, support from the community itself and Open Source. These components are usually more resilient and reliable long term than the VC driven startup culture. Emacs is part of the greater Lisp community, where a lot of innovations in general take place. The Clojure community is cutting edge in many aspects of software development including AI.

More Agents

One thing that I have noticed lately is that the more I get into Agentic Engineering, the more I use Emacs. When the focus has shifted from typing code to instruct and review, I have found use of Emacs powers I haven't really needed until now. Tools like Magit (git) and I'm also learning more about the powerful Org Mode. I didn't care that much about Markdown before, but now it is an important part of the development itself. So I just configured my Emacs to have a nice-looking, simple and readable markdown experience.

"More Agentic Engineering, More Emacs"

With Emacs, I use a great AI-tool called Eca and with it I am not limited to any specific vendor for agentic development. Vendor lock-in is something I really want to avoid. The combination of Eca and the power tools mentioned before, makes a very nice Agentic Engineering toolset. Eca is actively developed and has a lot of useful features and a very nice developer experience. It supports standards like AGENTS.md, commands, skills, hooks, sub-agents and use a client-server setup in the same way as the language server protocol. It is Open Source and not only for Emacs. Have a look at the website for support of your favorite editor or IDE. By the way, Eca is developed in Lisp (Clojure).

I have my Eca-setup shared at GitHub, and have also some contributions to the Eca plugins repository.

Human Driven Development

With this setup, the human reviewing can happen in real time, and doesn't have to wait until the end where the amount of code too often is quite overwhelming. The human developer (that's me) can quickly act when noticing that things takes a different route than expected, in a similar way as the stop-the-line principle from the Toyota Way. This is a lean way to reach the end goal quickly: deploying code that is good enough for production and adds value.

I have found that many Agile practices in combination with developer friendly tools fits well with the ideas of Agentic Engineering. Even though I've seen worrying signs of a return of the Waterfall movement.

To summarize: the result of my new Agentic Engineering development-style is that I haven't put my IDE to the side - it's at the very Center of the agentic workflow.

^{Top Photo by me, taken at Åreskutan, Jämtland, Sweden.}