Dragan Stepanović
@dstepanovic
Trying hard not to think about small batches, bottlenecks, and systems. In the meantime: XP, ToC, Lean, Systems Thinking.
Even if the rate of generating customer value increases with more code generated per unit of time, but at a comparably lower rate, you're still increasingly bloating your codebase with useless inventory faster than the value you're able to extract and driving up carrying costs.
Preparing a talk "Agentic coding - A Systems Perspective", and along the way realized that cognitive/comprehension debt didn't arrive with the advent of agentic coding. Most teams doing work in isolation (individually), already heavily experienced it.
Let's not forget that LLMs got fed with an ever decreasing quality of work our industry has been producing over the last 15 years as a result of cheap money with ever decreasing central bank interest rates. And both of these reinforcing loops are accelerating with LLMs dogfooding.
So, here's the thing. If this, someone would say, embarrassing level of availability came as a result of "90% of our code is written by agents, and we (mostly) don't review the code they generate"- fine.
I can guarantee you that addressing an actual bottleneck in the system definitely shouldn't look like pushing elephant-sized inventory through the boa constrictor (coding → review → integration → deployment → etc.). And you can tell by the elephant rolling its eyes.
I feel this slide from Jez Humble's talks has become more relevant than ever. It's not about generating bigger batches faster, but thinner slices validated sooner.
I was trying to find an image for the change in the dynamics that will likely happen as a result of plummeting of the cost of generating more code with AI, and "elephant travelling through a boa constrictor" nails it. Essentially, the elephant just got bigger.
As long as LLM pricing is based on how much/how often you're allowed to converse with the model, Spec-Driven Development and big(ger) batches will be a normal response to that. Scarcity drives batch transaction costs up, which drives the average batch size up to compensate for it.
Wait time variance goes up as the size of PR increases. The bigger the PR, the more uncertain when it's going to be merged. What does that mean? If you want higher predictability, you need smaller batches. Period.
Sorry, it was a response to this LinkedIn post, which provides more context.
Or... Or... the team has mechanisms and practices in place to keep the cost of change low, so they are able to change code and adapt design just-in-time (emergent design), rather than trying to predict it when they have the least information about the code (design up front crystal ball gazing).
The problem with the code that is not expressive, i.e. implicit, is not only readability per se. It's that it's missing important domain concepts communicated in the code.
Just a regular reminder that predictability (and accuracy of estimates) goes down the drain as you overload the system with too much WIP? How much WIP is too much WIP?