In an age of agentic engineering we in the Samman Society continue to find that human engineering expertise is needed to achieve high-quality software.
– Emily Bache, “Samman Society statement on Agentic AI”
Last week, on 12 October 2026, Emily Bache published the “Samman Society statement on Agentic AI”. You should read it: It’s short and interesting. Here are some additional thoughts from me…
I still think generative AI is a net negative for humanity, but I won’t rant about it again here. If you are interested in my opinion on why, check out Even if AI doesn’t Kill Us, That’s not Good News
Some Things Don’t Work Anymore
The statement describes things that don’t work anymore, like Code Katas that are too small when agents are involved, among others.
I have experienced that myself: In a code retreat, one of the constraints was “Use an AI, then review the code thoroughly”. As always, the Kata was “Game of Life”.
The problem was: It spat out a perfect solution. Maybe because the problem is too small and too well-defined to produce something interesting—or, even more likely because there are already a gazillion good solutions in the training material.
We had nothing to do for the rest of the session, so we watched another group that made the AI wreak havoc by asking it to “add fluffy bunnies” to Game of Life, which was at least fun.
Adapting Training
The AI statement continues:
Many coaches are now teaching various new technical practices for AI tools based on their own experience and their own beliefs about what works. That is a great starting point since we are all excellent engineers in our own right. In the longer term we expect a body of knowledge to emerge which we will agree on.
– Emily Bache, “Samman Society statement on Agentic AI”
In one of my TDD trainings, we first tried test-driven development by hand, then watched an AI do it. It didn’t do “real” TDD with the simple prompt the group came up with, but we still ended up with a good result and a good test. We were not sure whether this was because the solutions were in the training data, so we tried to come up with a problem where hopefully only a few Java solutions exist—if any.
Together, we defined the task as: “Write a program that gets a time on Earth as input and prints whether it’s night, dawn, day or dusk at Olympus Mons on Mars using TDD”.
That was fun to watch! We still found some issues with how it did TDD, but again, the code and tests were quite good.
And the solution was just a few lines of code, so I turned the exercise on its head for a conference workshop: You write the code, the AI is only allowed to advise. I found that even more fun and got great feedback from the attendees. You can try it out yourself here: Sunlight on Olympus Mons: an AI-Mentored Kata.
Wasn’t Possible Before
And AI allows us to create new things that were not possible before. I always wanted a legacy code exercise that is bigger than a Kata, to train things like:
- Do a refactoring without knowing the whole system
- Find the discrepancies between the docs and the code
- Fix a bug without introducing side effects in an entangled system
- Find at least N design problems that will prevent refactoring
- Design a new bounded context that interacts with the existing system
- …
I never had time to do that by hand, but I got pretty far by doing it with AI: Legacy Code Exercise: DragonKeep. It has all the design problems mentioned above (and more) and a license statement I love in the first-implementation branch. (*)
Where Does That Leave Us?
Maybe it is harder to teach / coach skills now: We don’t really know what skills will be needed, and when we use an AI during coaching / training, some of the techniques we used in the past don’t work anymore.
But I still think that our best bet right now (October 2026) is to keep (most of) our technical skills sharp, while we also learn about as many ways to work with AI as possible. But for me that means writing code by hand too and turning the AI off from time to time. Or at least only using it as a guide and mentor, like in the Mars time Kata.
(*) I should probably move that project away from Codeberg. Some time.
Read / watch all parts of this series here: