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

Agile & Agentic Engineering

"Don't fall into a waterfall-style of software development."

Our industry is quickly adapting to the new ways of working and we are redefining what it means to be a software developer: Agentic Engineering.

It's not the same thing as Vibe Coding, and probably why I have had such a surprisingly smooth transition recently. As I see it, vibe coding is about treating code as a black box: it doesn't really matter how things are put together. The only thing important for a vibe coder is the output. As a passionate TDD and REPL driven programmer, this doesn't feel right for me today. Tomorrow, I don't know. Right now, I care about how things are constructed. More importantly, I need to have some understanding about the code itself to get ideas on how to change and improve the output.

This is where Agentic Engineering fits in: a structured way of developing software, where the human developer takes an active part in the process. It is not only about high level architecture or designing the solution, it's also about having the possibility to direct the agents into producing actual code that the human can understand and approve. For me, this is about keeping things simple and concise. Functional. Doing things in small steps, i.e. solve a problem by breaking it down into smaller parts. Experiment and learn along the way, step by step, rather than making big plans upfront. This is the core of the Agile movement.

It's well known that LLMs can produce verbose chunks of code and forget about important things. But it is possible to take control of that part as an agentic engineer. Similar to the stop-the-line principle (from the Toyota Way) where you can halt the production if you identify an issue. Take action (clarify or give new instructions) and then proceed. With these skills, agents can produce chunks of code that are just right. And functional.

From what I've picked up in the developer community lately, there's an increased need for structured work in the new AI landscape. This makes a lot of sense. What surprises me is the conclusion that we should start doing more planning upfront, writing detailed specifications before any code is written. This is what the Plan, Execute, Test sounds to me. I am just misunderstanding, or is this a Modern Waterfall movement?

Plan, execute, test might be the correct workflow for an agent, but not for a human. Planning in the beginning is difficult, because in the beginning we have very little knowledge about the thing to develop. Instead, we could learn what and how to develop something along the way. We can also pick up bits of why along the way too, but it's good to have some understanding about that specific part early in the process.

If the Plan was incorrect we will be 10x, but with 10x waste. Agents produce code fast, and it might not be that big of an issue as before if we need to throw away the result and start over. This is new. The difficult part is throwing away our plan, our design that we've invested in, and start all over again. This drains human energy. Once a plan is set, it can be a too big mental effort to break free from it because things have been decided already. Big planning upfront might sound right, but it is a trap. A vague Jira ticket description to begin with is not necessarily a bad thing.

The challenge as agentic engineers is to 10x the value, and not end up in 10x waste. Essentially making us more product and value focused than before. In short: build the thing right, also build the right thing.

How can we do that? Explore, learn and adapt are words I would like to see as part of the Agentic Engineering definition. Plan a little bit upfront, just enough to get started, but no more than that. Continue exploring, planning and adjust as the work proceeds. Get things out fast so you can collect feedback (logs, errors, usage) and learn what to adjust. That's Agile & Agentic, a Lean and Agentic Engineering workflow.

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

Gäst-bloggare på Swaine's World - Guest post at Swaine's World

(English version below)
Idag debuterar jag som gäst-bloggare på Swaine's World - en blogg av Michael Swaine, redaktör för PragPub och fd chefredaktör för Dr Dobb's, två populära IT-tidningar.


Här kan du läsa min artikel om The Agile Family | Swaine's World.


(English version)
Guest post at Swaine's World
Check out my guest post at Swaine's World by Michael Swaine, editor of PragPub Magazine and former EIC of Dr Dobb's.


Here's the article The Agile Family | Swaine's World.

Familjen Agile - The Agile Family

(please scroll down for the English version of this blog post)


Vem är egentligen den där “Agile” och hur ser familjesituationen ut? Och har Japan något med det här att göra? Jag har släktforskat och resultatet av mitt arbete kan du läsa om här.

Vi börjar med vår stora kändis i släkten. Idolvinnaren och den alla snackar om: Scrum. Efter framträdandet i Allsång på Skansen är han nu också riktigt folklig och dyker upp i alla möjliga sammanhang. Scrum har en lillasyster, som kanske inte är lika känd (ännu). Hon heter Kanban, är lite modernare än storebrorsan (som ärligt talat börjar komma upp i åren). Säg inte det till Scrum, han är lite känslig för sådant! Många uppskattar lillasyrrans Rock n’Roll-attityd, enkelhet och innovativa idéer.

Scrum och Kanban har faktiskt ett till syskon, som hamnat lite i skymundan. Han kallas för XP av sin familj och vänner. Egentligen heter han eXtreme Programming, men blev mobbad för det i plugget. Han fick skägg tidigt i puberteten också. Efter ett tag tuffade han till sig, bytte namn till XP och sågs gå omkring i t-tröjor med budskap som I Unit Test on the First Date. Han började umgås mer med brorsan Scrum och de har idag en mycket fin relation.

Scrum och Kanban är väldigt utåtriktade, XP är mer eftertänksam. Han är en riktig programmerarsjäl med stor passion för sitt yrke. Lär känna honom och ni blir vänner livet ut, sägs det. Han är mest lik sin pappa och är en förebild för sina syskon (utan att han egentligen vet om det).


Vem är pappa? Han heter Agile och är en sådan där far som vi alla önskar att vi hade. Lugn, klok och lyssnande. Han ger goda råd och arbetar ständigt för en bättre värld, präglad av öppenhet, förtroende och ansvar. Han är mycket stolt över sina barn och följer alltid med på turnéer och tv-framträdanden (håll utkik på första bänkraden efter en aningen gråhårig leende man i sina bästa år).

Men pappa Agile har också varit en liten pojke en gång i tiden. Han är en sk “sladdis” och har en några år äldre storasyster. Hon heter Lean och är respekterad och beundrad i hela världen för sin känsla för kvalitet, respekt för människor och långsiktigt tänkande. Agile fick ofta vara med när storasystern och hennes vänner spelade video-spel och sjöng till populärmusik på radio i det japanskt inredda hemmet. Han minns:
- Hennes tjejkompisar var så smarta och snygga! Jag var kär.


Storasyster Lean har lärt Agile allt han kan och är fortfarande en stor inspirationskälla för honom och speciellt yngsta dottern Kanban (som hälsar på och bor hos henne varje sommar).

Lean har också en dotter – kusinen till syskonen Scrum, XP och Kanban. Kusinen, som heter Lean Software Development, spås en lysande framtid och har inte fått strålkastarljuset riktat mot sig ännu. För den stora massan är hon okänd. Scrum berättar:
- När kusinen hälsade på var det alltid spännande. Vi skröt ofta om henne för våra vänner och hon hade alltid med sig de senaste grejerna från Japan. Våra Game&Watch-spel blev så omoderna och tråkiga när Lean Software Development visade sin spelkonsoll med både färgskärm och stereoljud. Det var fantastiskt, som att se in i framtiden!


Syskonen Agile och Lean Software Development har sedan länge daglig kontakt via Skype och planerar att samarbeta mycket mer i framtiden.

Vi har kommit till toppen av vårt släktträd. Här hittar vi: en japansk bil. Ja, det är sant. Syskonen Lean och Agile har sina rötter i ett nästan kliniskt rent verkstadsgolv i Japan. Historiens vingslag har tagit oss till landet med det vackra skriftspråket, de blomstrande körsbärsträden, sylvassa samurajsvärden och världens största bilmärke: Toyota.


Toyota Production System (TPS) är på god väg att forma en bättre värld med sina idéer om respekt för människor, lagarbete, kunskapsöverföring och ansvar. Ord som Kaizen (ständig förbättring) och Hansei (reflektion) är ett naturligt sätt att arbeta och leva enligt Toyota Production System. Enligt TPS räcker det inte med sk Quick Fixes då problem uppstår. Man går vidare och letar efter orsakerna till att de alls dykt upp, genom att ställa frågan varför? minst fem gånger. Toyotas filosofi är att: Basera besluten på ett långsiktigt tänkande, även om det sker på bekostnad av kortsiktiga ekonomiska mål.

TPS kan tyckas vara svaret på alla frågor, men glöm aldrig att det beror på (vilken fråga det är). Scrum, XP och Kanban är inte heller svaret på alla problem. Finns det ett svar då? Ja, det gör det faktiskt: 42. Vad frågan är får du lista ut själv.


Avslutning
Alldeles nyss fick jag ett meddelande, med avsändaren “TPS”:
- Du har mycket kvar att lära, David-san. Jag ser att du tagit hänsyn till A3-formatet. Men ditt släktträd skall vändas upp och ned.




(the English version)


The Agile Family

Who is that guy “Agile” anyway? Does he come from Japan? Where is his family? We have the right to know. I have done some research and here is the result of my work.


Let’s begin with the Star, winner of American Idol and the one everybody talks about: Scrum. Scrum has a kid sister, not yet as well known as her big brother. Her name is Kanban and is described by many as modern, attentive and a bit more up to date. Let’s be honest, all of us get old some day. So does Scrum. Please don’t tell him that, he is a bit sensitive about aging! The Rock n’ Roll attitude, simplicity and innovative ideas of lil’ sister Kanban are properties appreciated by the constantly increasing fan base.

Scrum and Kanban has another sibling. They call him XP and perhaps he is a bit overlooked. His real name is eXtreme Programming, but he was so bullied in school for it and really had to change his name. Sad, but that’s the real world. He also grew a beard very early in his teens, that didn’t help very much.

As a teenager, XP added some well needed attitude to his personality and he often wore T-shirts with statements like I Unit Test on the First Date. He started to hang out with his brother Scrum and they found out that they actually have a lot in common and complete each other well. Today they are the best of friends.


Scrum and Kanban are both extroverts. XP is very thoughtful and a passionate programmer. People say that when getting to know him, you will have a friend for life. He is the one that resembles his father most and without knowing about it, both his sister and brother see him as a role model.


What about dad? Well, his name is Agile. He is the kind of father all of us wish we had. A man of wisdom, laid back and always giving you attention. He is the one with good advices and has never stopped trying make the world a better place. He is very proud of his children and you will spot him on almost every of his kids TV and live performances. Do you see the bald guy at the front row smiling and cheering? That’s Poppa Agile.

Agile was a little kid once, like all of us. A boy that admired his older sister Lean. Her sense for quality, respect for people and long term thinking has made her well respected and admired all over the world. Agile did spend a lot of time hanging out with big sister and her friends. They played video games, laughed and listened to the radio playing the latest hits all day at home. He reminisces:
- Her girlfriends were so good looking and always knew what was cool and what was not. I was in love.


He continues: – All I know comes from Lean and she is still my biggest inspiration. My youngest daughter Kanban visits here every summer and admires her aunt a lot.

Aunt Lean also has a daughter, called Lean Software Development. She is the not so well known cousin of Scrum, XP and Kanban. I hear people say she is the next big thing.


Scrum says: - When our cousin was about to visit us, we all got so excited! We talked a lot about her, bragging about how cool she was. She always brought the latest stuff from Japan. Our Game&Watch toys was nothing compared to the gaming consoles she had, with the color screen and stereo sound. It was amazing. It felt like seeing into the future!


The Agile siblings and Lean Software Development both agree that they really should work together in the future. Let’s hope they do!

Yes, we have reached the top of the Family Tree. A car? Yep, that’s right. Both Lean and Agile comes from the garage. A very clean garage, I might add. The time travelling journey got us to the land of beautiful calligraphy, blooming cherry trees, razor sharp samurai swords and the best car brand in the world: Toyota.

Respecting people, team work, responsibility and sharing of knowledge is the soul of Toyota Production System (aka TPS). Will TPS make the world a better place? Kaizen (continuous improvement) and Hansei (reflection) must be a part of the daily work flow according to TPS. What about problem solving? Don’t settle with quick fixes. Try find the root cause by asking Why? at least five times. The philosophy of Toyota is: Base your decisions on long term thinking, even when they are in conflict with your short term financial goals.


Is TPS the answer to all your questions? Well, that depends. What about Scrum, XP or Kanban? Probably not. Is there an answer? Actually there is: 42. You go figure out the question yourself.


Final words
Recently I received a message from someone called “TPS”:
- You have still a lot to learn, David-san. I noticed that You have used the A3 format. Good. But your Family Tree should be turned upside down.

...innan det är försent

”Hur gick det? Vad gjorde vi fel? Så här borde vi kanske ha gjort.”

Mötesprotokollet sparas och sorteras in i en pärm, projektet är (äntligen) avslutat. Fyrtioåtta timmar senare har nästan allt glömts bort och vi går vidare till andra uppdrag.

Är det inte bättre att försöka förbättra oss nu (innan det är försent) och ha roligare på jobbet redan idag?

Hur?

Det finns bra idéer från Lean-världen (ständiga förbättringar) och konkreta förslag från Scrum-världen (återkopplings-möten) som man kan ta hjälp av.

Jag vill gärna berätta om hur vi gör idag:
vi planerar in korta team-möten (en timme) varannan vecka. Varje person skriver ner sina idéer och förslag på gula lappar, som sätts upp på en whiteboard-tavla. Vi pratar om idéerna, prioriterar och diskuterar lösningsförslag. Dagen efter - när vi drar igång nästa period (kalla det sprint om du vill) - har vi uppmärksammat saker som varit hinder i vår produktivitet. Vi har troligtvis redan löst en del av dem!

Två veckor senare gör vi samma sak igen och för varje gång blir vi ett bättre och gladare team. Det syns också tydligt i våra leveranser. Det här är en bra grej som jag tror att många ”Scrum-team” hoppar över och kanske en orsak till att så många IT-projekt fortfarande misslyckas.

Boka ett återkopplingsmöte med dina arbetskompisar i laget redan nu, ta med pennor och ”post-it”-block. Det kan bli en väl investerad timme.

Boktips: Agile Retrospectives