Agentic Engineering increases variance. Teams with strong engineering practices compound their advantage, while others can fall behind as missing tools, inefficient workflows, and bottlenecks slow them down. If we want broad adoption, we need to usage of tools and new practices deliberately. While Agentic Platforms expected to provide higher level abstractions are still evolving, we must look after our talent, continuously upskilling people, regardless of the size and shape of our organizations.

The sprawl of tooling and practices along with viral content circulating through social media makes many people uncomfortable. Many look for direction, best practices, or clear instructions on what the state of the art is. The reality is that nobody has it all figured out yet and many of the shiny things shown on social media are demos showing the happy path. Mario Zechner, the creator of pi.dev (the harness used by OpenClaw), poured cold water on the hype, asking for more discipline and reason when using agents. Martin Fowler said recently that in XP and agile terms we’re at the stage comparable to the early 90s full of experimentation and new ideas. Thus, it’s too early for a manifesto.

Because it’s still early days, authors of tools have not yet figured out how to build their products with consistently high quality. We see this in the regressions in new versions of Claude Code. Non-determinism adds another layer of difficulty with new failure modes that need to be learned and mitigated. For example, compaction can result in lost instructions, which is non-intuitive to users. It takes time to build the intuition and mechanisms that help mitigate problems end-to-end. Early days of SRE were similar, though we were at a stage where companies with sufficient scale had a time advantage as they hit the limits quicker. This gave time to build up and codify some of the knowledge in articles or books.

Learning journey for Agentic Engineering

A pragmatic way of building organizational know-how is through guided experimentation where a small group of power users defines the set of experiments or practices to try out. They take on the risk of trying out something that won’t work out, but they also guide participants throughout the learning journey with existing knowledge they have. Oftentimes, their time advantage in using the tools or practices is measured in days. The guided experiments can be time-boxed (e.g. 4 hours) and done in pairs to facilitate peer learning, ideally across teams.

What is important when considering teaching agentic engineering is that everyone’s journey is different. Those who jumped on LLMs early on and kept following the evolution of models, coding assistants, and similar tools have a vastly different intuition about the capabilities than folks who have been resistant to trying them (or who could not make prior generations of tools work). Thus, the early adopters are also those who are most likely to thrive in the experimentation setup mentioned.

Looking for more structured approaches to learning, we find models with 8 levels of agentic engineering. A mental model that worked for me is slightly simpler, directly rooted in the level of autonomy and size of changes delegated to agents:

  • Suggestion mode, aka. Tab Autocomplete where engineers get familiar with whole chunks of code being suggested instead of just function names and arguments.
  • Interactive mode with Agents in IDEs allowing to interact with the codebase through prompting, asking simple questions and progressively requesting more and more complex code transformations of features.
  • Supervised execution with Agents in CLIs with engineers starting to scope larger tasks and acceptance criteria leveraging the planning mode, but accepting every single command from the agent.
  • Delegated, autonomous Agent Loops in CLIs where building up on the prompting skills, engineers build verification methods and safety nets allowing them to diligently plan large tasks and let the agent crunch through them autonomously.
  • Autonomous Background Agents that run in the background and react to defined changes in the system, e.g. commits, pushes, or periodically scan the codebase or running software deciding when to activate and what procedure to run.

Meet users where they are on their learning journey

When teaching agentic tooling or practices, it helps to understand where a person is in their learning journey. This helps to present ideas new to them in ways that stay close to their current comfort zone. Seeing is believing, so make sure to add a healthy dose of live demos where people present what worked for them using real-life examples, not just fancy demos. When designing trainings, these levels also need to be accounted for, either in expressing clear preconditions for entry or in making sure that no single approach is favored.

The above list represents a spectrum of working modes rather than a strict maturity model. This means that there is no single right way, though there are many wrong ones. Certainly, the outcomes and token usage differs between them. However, it’s important that engineers find their own mix that feels right for them, their level of tolerance for risk and for their team/product as well as budget. This will challenge existing team structures, likely leading to some reshuffling to bring colleagues with similar development styles together (temporarily or permanently), so that they continue to raise the bar and to facilitate peer learning. In order to avoid teams getting stuck in local minima, the big question is how one can coach whole teams?

Teaching teams

Teaching teams used to be a task for the engineering managers who could rely on their past hands-on know-how and credibly advise their teams. Now, they’re faced with a situation where time for hands-on coding is limited and where they may need to learn new tools first, before they’re able to teach their team. They will need to be more intentional about their own learning, leveraging power users to acquire skills or hints on what to look at. Waiting for EMs to learn before they can coach their team is of course too slow.

Power users can help coach teams effectively. The key is to break down the agentic engineering cycles that experts do in one go into meaningful phases, adding inspections along the way. Inspections can be done individually (pairing, code review) or as a group (like in swarming). Let’s say we want to teach a team to author implementation plans in plan mode. While an experienced engineer would do plan and execute in one go, we can break this into two steps. First, the plan is prepared and checked in. Next, it’s reviewed along with the prompt used. This helps transfer the intuition that comes with experience and potentially capture some recommended practices (or constraints in agent instructions). Afterwards, the plan is implemented and results are reviewed. Similarly, one can teach prompting patterns, e.g. focusing on reviewing code for certain types of defects.

Scaling beyond teams

To scale further, we can learn from the OpenClaw moment in China where companies set up events that offered hands-on support for setting up the tool. The key is to meet users where they gather anyway to spark their initial interest or incentivizing them to stop at easy to access places. Setting up booths near office entrances, kitchen spaces or in cafeterias comes to mind here. Same goes for workshops and demo sessions at internal conferences or town hall meetings. While these formats can spark interest and drive attention, lasting effects depend on curiosity of the attendees and structure of workshops delivered.

When setting up formats for cross-team knowledge exchange, it’s important to provide a platform for early adopters to share and showcase their wins, enabling them to earn some peer credibility as experts and ensuring they get connected with other experts. To balance out the focus on experts, formats where leaders can discuss friction adoption friction are needed as a safe space to discuss organizational change and gaps for enablement. For further scaling, one would usually seek champions per organization who would be acting as multipliers. Forming a network of champions, they support each other in sharing lessons learned. Whether champions are chosen among early adopters who earned some visibility by sharing their knowledge or by role is highly dependent on the organizational culture and the seniority required for the change management process. Key to success is organizational backing by sponsors from leadership who can help remove organizational blockers.