I prefer to start where I am, or where we are, and figure things out from there. That requires Situational Awareness, being able to make sense, together, of what we are facing, where we want to go and what we have at our disposal.
This is contextual. Which is annoying, because it makes communicating online about our lived experience difficult when there are new-ish tools (like coding agents with LLMs) are available. What works in one context for one team, may not work for another, for reasons that may become clear in hindsight, or not.
One of the things I didn't like around the early Software Craft movement (especially the american instatiation of it) was what I now call "moralistic programming". "You are not a good developer if <you don't use my pet favourite practice>".
I'm seeing some of the same tendencies that were around in the early software craft movement repeated in agentic engineering. Instead of "you're not a professional software developer if you don't write tests" we have "you're not a professional software developer if you write code by hand".
I enjoy both writing tests and wrangling (and developing) coding agents, and am always looking for better ways. When I briefly had a job in 1999, in the job interview Danny Greefhorst, and the late Gert Florijn, who would become my mentor, asked what I thought about Object Orientation. I remember saying something like "I like it, and use it, until something better comes along". They hired me anyway.
I like to put "knobs to 11" and figure out the extremes. So that I know where the limits of my tools and my thinking are. Preferably together with other people.
This brief post is the adaptation of a comment on a LinkedIn post by Machiel Keizer-Groeneveld
Machiel:
Because nothing is categorically solved, we don't need new words for software development, AI does not 'change everything' even though we are discovering where and how LLMs can assist our software dev practice. The downsides are also showing themselves clearly: LLMs have the wrong built-in intent, they either lack domain knowledge or context rot ignores it, causality is an obvious weakness, they do not evolve their understanding, ask too few questions, they are too confident and apt design requires real intelligence, not plausibility at scale.
LLM or not, we need software that is reliable, transparent, extensible and capturing domain intent
As ever, we are finding better ways of delivering value (often, but not necessarily, with software) by doing it, and helping others do it.
Looking for something in my notes, I found John Cutler quoting Cat Hicks:
What would it look like if we could ask, "how do I make this the absolute best environment for complex problem-solving" instead of "how do I take away all these annoying hard problems." The stuff we want to accomplish in the world is hard. But can be joyful to accomplish.
Further reading
Gojko Adzic recent post on how to use Commanders' Intent for feature development.
I like to combine Commanders Intent with Backbriefing, which is well described in the late Stephen Bungay's The Art of Action
Afterword
I haven't written about this, but I have once shipped a system with very few tests (and no, this was not written in an "if it compiles it works" language, but PHP). It wasn't the optimal way to do it, but we managed to deliver value faster in other ways that were visible and achievable for the team. Focus and zero-defects worked without tests, but slower. Automating other manual work shrunk the release cycle more than tests would have - they would have added value after that, but then the project was over. Did I miss tests? Yes. Did I tell anyone about it? Well, maybe Rob and Marc at QWAN. And I told you now.
Everyone I worked with wanted to achieve a good outcome, and that is what counts. We can always find better ways.