Tensegrity

Unsurprisingly, like any Individual Contributor, I have accumulated a lot of theories of management. Given my now 4+ decades of doing this stuff, I’ve also managed to run ad hoc experiments on my hypotheses and always made a point to observe and collect data where I could. It’s been a useful distraction and, as I always say, having a theory about why a system acts the way it does is the first step to working with it, changing it, or understanding how to avoid it.

And it probably will not surprise you to find that I haven’t really come up with anything original. I do think I have come up with explanatory theories that seem to work well for the circumstances I tend to inhabit, but certainly nothing mind blowing or particularly insightful I’d wager. And I don’t suspect that will change. It’s not my wheelhouse. But it does drastically affect my wheelhouse(s).

Fair warning: this post is foundation laying. I want to get the effects I’ll be leaning on down first – cycle time, information logistics, signal to noise – because the part I’m actually driving at is what all of this does to the systems software development is embedded in. That’s something to really dig into once I’ve at least somewhat set the stage.

Faster Cycling Times

Over the past year, this hobby of mine has produced some fascinating observations. These run the spectrum, given the… interesting… work environment that I was a part of. Sometimes drawing extremes improves contrast; things can become very obvious when outlined in bold and the other background mitigating noise is muted or eliminated. And one tool that we have at our disposal for clarifying is the faster cycling time available with agentic programming.

My hero Dan Davies had a post a while back that really clarified the effects that faster cycling times have on analytical clarity:

And the other lesson of the algorithmic social media age is that industrialisation matters – the speeding up of the cycle doesn’t just clarify things analytically, it actually intensifies the damaging effects.

And while the cultists and other true believers will never agree, I think one of the unarguable effects of Generative AI (the term I use, GAI for short) is that it intensifies damage. Not limited to, but largely because of the massive speedup in cycle time.

It’s not as widespread as it should be yet, but it’s pretty clear that once programmers figure out Agentic Coding, you see massive improvements in cycle time, etc. And this massive improvement in the software development cycle has been quite instructive on where and how the system we have developed over the years breaks, bends and is otherwise spindled and mutilated.

Tea Leaves

Certainly a lot of digital ink and pointless social commentary has been spent on the things that impact the developer or are developer centric. It’s largely no surprise because, well, until really recently, it’s only been programming where the real successes have been. And certainly that’s something I’ve been fully participating in. But it’s not really the observations I want to point to.

Rather, what I’d like to point to are the effects on the system that software development is embedded in. I’m a general systems theorist and so this is my natural mode of analysis and it’s obviously a series of shells – the only system not contained in larger systems is… the Universe. Thus, general systems theory is somewhat about defining boundaries of systems and how they interact. As an aside, there’s a wonderful book, Signals and Boundaries: Building Blocks for Complex Adaptive Systems you should at least peruse if you’re interested in such things and how we can leverage these principles in real engineering, understanding how they work and their pathologies.

Anyways, from almost the moment I started agentic programming I started looking at how the system I was embedded in – and the systems beyond that – and how the hell they were going to get impacted by what I was seeing in real time now. Thanks to the Massive Decrease In Cycle Time.

Logistics of Zero

This is obvious to folks who study such things for a living, but I was finally getting concrete observations on the effects in real time. My working hypothesis from decades in this industry is that the actual development of Software has largely not been an issue. Rather, my hypothesis now focused on everything else that affects the product delivery. Assuming for the moment that the marginal cost of software goes to zero and the lower bound of cycle time of software development approaches zero… Big assumptions, but useful (to me at least) because of the contrast enhancements it allows.

And so one of my first falsifiable tests (trivial extrapolation, of course) is that the immediate effect of agentic programming would simply be that the delivered and working software would pile up on the places in the system where you just can’t push things. Like the silly picture above, you can see how this can cause classic problems.

Managing Agents Is Much Like Managing People

Not surprising at all, but it is refreshing to see the clarity of this statement. I am not one of those who anthropomorphize GAI and agents in particular. Humans acquire tools and we give them names. We gift them personalities. But those are constructs of our wonderful mind that is part of our tool acquisition that is one of the hallmarks of our species. It can be really confusing, of course, and that is part of the problem.

Regardless of the psychological landmines in doing so, I believe it is instructive to look at what the process of development has morphed into (over the last year!) and use this as kind of a laboratory view of how the human equivalents act and see if we can get any insight into these larger systems by watching analogs.

Information Logistics

One thing that becomes quite clear in agentic programming is the notion of the logistics of information. Within about 2 ms of beginning agentic programming it becomes immediately obvious that the problem is getting the right information to the right place for the right decision at the right time. Just like it is in human systems.

This is why you saw “Prompt Engineering” as the first foray into managing agentic programming. It’s something that has a precise analogy in human systems. It’s the age-old observation that folks you’re dealing with need to be told a lot of information to carry out their work and to coordinate with others doing related and perhaps sequenced or joined work. And when the “person” is an LLM, the limitations on how much context they can hold became an immediately obvious problem. Thus prompt engineering became the “One Weird Thing” trend.

And it’s not like it didn’t work! It turned out that, exactly like people, the quality and quantity of the information really matters.

And like all things useful, prompt engineering didn’t really ever go away. It morphed into the human equivalent of clarity of thought. Because we’re dealing with things – “agents” – though, we can precisely see the limitations of the “other party”.

Through a Lens, Darkly

The clarity here, despite the perhaps low resolution of the simulation of humans by agents, is that almost all the responsibility lies on the person giving requirements. Giving instructions. The information gap is trivially proven real and when the other side is literally a stochastic parrot, it clarifies where the problems are. And granted, the other party has to be able to carry these instructions and that’s where the stochastic parrot part comes in, of course. Turns out these things are probabilistic – by design! – and don’t have 100% accuracy in whatever task they are trying to complete. And while there’s a lot of serious criticism of this, it is something getting better, but I would argue is simply never going to go away. If a task is perfectly executable, it’s probably not even worth the time of a GAI system. My contention is that issues like these are systemic.

And so I, as many others, started to work on context engineering rather than prompt engineering. The problem with prompt engineering is isomorphic to the problem of giving requirements or instructions to someone: the continuity matters much more than any one particular instruction or sequence. The human analogy is easy to see: Jira, Google Docs, and a host of other content oriented tools around maintaining continuity throughout the coordination of many agents.

Even today, what most folks seem to do is desperately try to conserve their working LLM context (anywhere from 200,000 to 1 million tokens, these days). Each and every time they begin, they have to reteach the LLM what to do. I could go on at length about this, but the important point is that there is no context big enough. Information is exponential. The number of connections between nodes grows quadratically, not linearly, and these connections between things become what we primarily care about – not the nodes themselves.

Signal to Noise

And it’s pretty clear to me, at least, that the problem was maximizing the use of this context. As we discovered empirically, the quality of the context matters a lot (unsurprisingly, of course) and this is where these large contexts often are counter productive.

The reason why, imo, is that what counts more than almost anything else in agentic programming is the Signal to Noise ratio. It’s an incredibly difficult problem, naturally. And while smaller contexts don’t necessarily guarantee a higher Signal to Noise ratio, there simply is no alternative in a small context to produce something with a high S/N ratio. It won’t work otherwise.

Thus, imo, one simply can’t afford to rely on a context perhaps five times as large. It’s not a universal solution and has its own biting tradeoffs. As with most things in life, if you give an inch they’ll take a mile, and humans who have no constraints to their actions are just sloppy as hell. Larger contexts, in general, lead to poorer information quality in those contexts. As the saying goes, it’s what you do with it, not how big it is. I think this is also the reason for the findings that smaller prompts lead to better results. It’s all about information density.

Small Wrap Up

I think there’s enormous value in using these agentic systems and the challenges we face with them as a kind of a simulation of human systems (note that agent simulation has been going on for decades, and so not even close to a new idea here). And the cycle time on these experiments is drastically falling – close to zero in many circumstances. And it’s the number of iterations – generations – in your work that counts in this area, not the quality of any resulting iteration.

And what I think we’re seeing is quite the revelation. Not for those who understand and have been studying these things for generations, but rather for the rest of us and many ICs, in particular, I feel like these will be very interesting results to see and experiment with.

Building Agentic Coding toolsets, harnesses, and systems can teach us a lot about how we humans work, too. But the map is not the territory! Sadly, that won’t stop those from inferring in an unsupported direction, but such is life.

Anyways, something for y’all to think ’bout. I’ll try to see if I can stay focused and discuss the effects of all this on the surrounding systems.