How Do We Find Best Practices for Agentic Software Engineering?

It has never been easier to feel completely lost as a software engineer.

Last night, I watched two episodes of Kent Beck’s podcast “Still Burning,” and this thought stuck with me.

Before Claude Code or Codex, we had a rough idea of how to write good software. Not every team followed best practices, but (almost) everyone knew how to get the fundamentals right. Today, we no longer do. Kent Beck says it again and again: “Nobody has the answers.”

When I was starting out and wanted to know how I could do something better, the answer was often: “It depends…” (A phrase that apparently about half of all professions claim for themselves.) Today, the answer is still “It depends…” But the profound changes brought about by AI mean that even the factors behind it are no longer clearly defined and we lack a shared understanding.

A few example questions that show what I mean:

• How long can an agent work effectively in one session?
• When should we start a new session or clear the context?
• How do we know when an agent has taken a wrong turn?
• How large should a task for an agent be?
• Are long sessions in which many tasks are delegated to subagents worth it? How do we determine that?
• How much does the quality of the results differ depending on whether we use a structured prompt or a few bullet points?

The list is endless.

Now you could say: “It’s your own fault! You can just stop using AI. Then you won’t have these problems.” I am convinced that this will not be the solution in the long run. So we ask these exact questions and look for answers.

If I ask three experienced engineers, I get five different answers. If I ask the same people again two weeks later, I get five new answers. On top of that, even if it sounds like two of them agree because they use roughly the same words, that does not mean they mean the same thing.

Over the past few weeks, I have often wondered how we can solve this. Among the people I work with, what works best is listening more, asking more questions, and following up more often. We have to try to learn from each other and build common ground where we can experiment and improve.

One example: If a popular Claude skill does not work for me the way the community consensus would lead me to expect, the problem might be me. Suddenly, I have several new variables I could adjust, and perhaps should; after all, everyone praises this skill! But if peers I respect have similar problems with the same skill, it probably just does not fit the way we work. Then I know I can drop it and move on.

That is how we can move forward step by step and perhaps keep up with the rapid pace of development.