We’re accumulating code faster than we are accumulating trust.” Sometimes a phrase just hits. Yes, we can create code faster now, but software is bipedal—code & trust go together. One without the other just hops along awkwardly.

Trust is as tricky as code. Both are asymmetrical. Code works or it doesn’t. One mistake in a long string of good decisions is the same as just a mistake. Trust accumulates slowly & evaporates in an instant. The difference is that in software sometimes you can repair the mistake in time proportional to the time it took to make the mistake. Trust is irreversible. Once gone it’s hard-to-impossible to get it back.

XP offered faster accumulation of functionality than folks were used to, but it didn’t suffer from the lack of trust we see among genie pioneers. I never thought of it this way before but XP manufactured trust. But how? What is a trust factory? We’ll go from practices to principles to values.

For this online event, we will have the opportunity to receive Dragan Stepanović as a speaker.

After a brief introduction of our community, Dragan will explain the Systems Perspective of the LLM-assisted coding.

Abstract

This will not be your usual "all roses" talk on GenAI nor one that hijacks your amygdala with claims such as "Most developers are going to be replaced by coding agents in 9-12 months!" or "If you don't jump on the train, you're going to be left out!".

For product development teams, organizations, and their customers, every technology they want to adopt, however innovative it is or may seem, doesn't operate in isolation, but as part of a broader system. Ignoring this fact is likely to make things worse instead of achieving the promised huge productivity boost, because any change in a system affects its dynamics in a way that feeds back to affect that change in turn. Some parts of the dynamics accelerate, some start pushing back. It's becoming increasingly important to take a systems perspective on attempts to adopt a technology and understand what desired, but even more importantly, unintended consequences it's likely to cause.

I'll be diving into topics that are likely to stir the pot with uncomfortable, but important questions that a growing number of teams and organizations are facing on this journey. Great, we have this heavy machinery that can produce so much more code in a unit of time, but what do we do with all the piled-up inventory of unreviewed code? What about comprehension debt? How do we keep the ability to reason about the system? Can we replace the process of creating and evolving a product with its output (code)? LLM-assisted vs agentic coding, and which makes sense in which context?

This technology and its adoption are still in their infancy and we're operating in an uncharted territory, so no one really knows yet all the effects that will play out, but looking at it through Systems Thinking, Lean, Theory of Constraints, and XP lenses can provide a useful level of foresight into the distribution of outcomes that might play out.

About Dragan

Dragan is based in Berlin and as a principal engineer helps companies evolve their engineering culture, tame their bottlenecks, and maximize their throughput of the value.

Typically, in search of better ways of working, exploring ends of the spectrum, and helping teams and organizations try out counter-intuitive ideas that initially don't make a lot of sense, but surprisingly end up as completely opposite of that.

He enjoys endless discussions connecting XP, Theory of Constraints, Systems Thinking and Lean.