From Chunky To Smooth, or… Long is the way, and hard, that out of Hell leads up to light.

Back around 2010, zipping along I-95 South, I spied a roadside billboard from a major defense contractor featuring a CGI soldier clad in Halo-style armor and sporting the tagline “SAIC — now hiring cyber warriors”. “Blergh, there goes the neighborhood”, I thought, a “neighborhood” so reclusive it had until recently stubbornly eschewed so much as an exit ramp sign admitting its mere existence.

Fast-forwarding to a few days ago, I find Facebook’s targeting algorithms showing me the modern-day cyber equivalent of a “Booth Babe”, an influencer who, unsure of how to even pronounce “autonomous”, was nonetheless doing her level best to stoke AI FOMO while hawking Anthropic’s Claude Code to the masses — “if you’re still coding in this century, bruh, I don’t know how to help you”. “What am I even seeing?” I thought, shaking my head in disbelief.

“Get off my lawn!”, you might imagine as the developing theme of today’s essay, but it isn’t really, despite some grumpy corner of my brain wanting with increasing frequency to shout precisely that. Readers of my earlier piece, Farewell To Punchcards, may recall my formulation of the “Gibbs Window”, a concept that explores the range of people who may participate in systems building activities and the consequent range of systems that may thus be built. This concept rests atop the Jevons Paradox which asserts (counter-intuitively) that when the efficiency of a resource’s use increases, so, too, does the demand for it. Whereas the frictions of yesteryear hinged on the height of the barrier to becoming a programmer, today the discussion centers on how quickly that barrier is disappearing.

We stand now on a precipice that must feel familiar to those who witnessed the proliferation of PCs following an era dominated by mainframes. When the bulk, fragility, expense, specialized labor, and scheduling headaches that characterized the hulking beasts living in dedicated server rooms gave way to machines you could sling under an arm and plop on a desk, the transition triggered a Cambrian explosion of software that seems obvious in hindsight but doubtless shocked those living through the moment. As the availability of desktop terminals dramatically reduced the friction to churn out code, so, too, does the rise of LLM-assisted coding tools, and in both cases the problem shifts away from throughput and latency — and toward comprehensibility and reliability.

This pattern repeats — some new technology comes along that improves accessibility, a flurry of innovation and productivity ensues, unforeseen consequences manifest in a snarled mess of half-baked and highly fragmented systems, we struggle mightily to rein in the nascent chaos, and no sooner than we imagine ourselves as having succeeded does the next game changer upend our world. At least that’s how it used to work. Now the successive waves of disruption arrive with such rapidity as to thwart enjoying even the briefest moment of smug satisfaction at a job well done restoring order to the world.

Every time we add new technology to our software development ecosystem we bring along more people for the ride, yet participation remains fundamentally chunky. The advent of the spreadsheet, for instance, particularly ones with rich embedded macro programming languages, empowered practitioners in the accounting domain in ways previously unimaginable, and yet consider the vast gulf between those giddy bean counters high on self-actualization and the software engineers who could navigate the gritty application programming languages of the day. How overwhelming must the required activation energy have felt for accountants bumping into the limits of a macro programming language who dreamed of breaking through to the other side under their own power?

Problems such as this recur fractally — cropping up not only in the world’s tooling generally but further within enterprises and even inside particular products and teams, often evoking Conway’s Law which stipulates that organizations tend to build systems whose architecture recapitulates team boundaries. I thus find myself reflecting in particular on the two platforms I built during my government days.

In the first case, I bootstrapped a flow-based programming system, one wherein an end-user could pop open a web browser to graphically stitch together components that represented data sources and transformations, codifying and hosting processes that previously existed as ad hoc scripts and troves of data sprawling across countless locations. This fostered the discovery and sharing of tradecraft that had been languishing in silos while also encouraging data source owners to develop and hone programmatic interfaces to their systems. And yet, while these developments initially generated a great deal of excitement among analysts, as the requirements backlog swelled and a team of software engineers coalesced, an onerous chunkiness emerged. The script-slinging analysts could explain what they wanted but weren’t well-positioned to write plug-ins for a system bound by a cumbersome formal release process.

Meanwhile, a sister system that emerged around the same time made a different design choice, trading one problem for another. While my platform assumed plug-ins written by professional software engineers and deployed as part of a formal release process, this other system made it easy for analysts to write and ship their own plug-ins to a server environment, a feature that let them rapidly self-actualize while over time creating nightmarish problems around system performance, process isolation, and ecosystem comprehensibility. A small number of over-burdened reviewers found themselves pressured to rubber-stamp submitted code, old plug-ins never got refactored or retired, servers strained under code written by people who didn’t grasp algorithms, and overall the system suffered as does a ship whose hull more resembles over time a mass of barnacles than planks of timber.

The second government system I built, or perhaps more saliently the larger system-of-systems I co-shepherded into being, in many notable ways did better than my first one, owing in large measure to a more rigorously defined set of externally exposed APIs. These interfaces allowed third-party creators of collection and analysis tools to operate with substantial autonomy as long as they adhered to a few simple data contracts, something a shockingly large number of people did as the platform experienced runaway success. This situation quickly transitioned from problems of marketing into ones of governance — integration became so easy and the benefits so valuable that people wouldn’t even bother to mention what they had planned, leaving me to find out only when a new data flow piled onto the existing torrent and servers began to melt. As I so often note, shamelessly stealing from Oscar Wilde, there are only two tragedies in life: not getting what you want, and getting what you want.

And really the surprise-slotting of collection tools upstream of my system represented only half the battle in the end — the API within my system, intended at first only to support my own native UI, drew the attention of others who variously wanted to craft bespoke analytics and automation of their own which they in turn sometimes published to other people still. In the case of the upstream providers, the creators were at least engineers, albeit more applications engineers than systems engineers, but the downstream consumers often weren’t even engineers, per se, more analysts with an itch to scratch and an urgent mission to support, who were slamming out snippets of Python while thinking little of scalability and less of compliance. More than once I had to diagnose, track down, and remediate barnacle explosions of my own that threatened system meltdowns.

I could tell many more similar stories from the intervening nine years since leaving the government, but that risks becoming tedious and repetitive. So let’s jump forward to the present moment, an era characterized by the optimism and chaos of LLM-fueled tooling whose potent promise and looming peril stem to a large degree from the inherent chunkiness of the talent now on the field.

If you haven’t been sleeping through 2025, then you have doubtless noted Vibe Coding‘s appearance in the zeitgeist, an approach that Andrej Karpathy describes as “fully giving in to the vibes, embracing exponentials, and forgetting that the code even exists”, an extreme way of engaging with LLMs that is hard to fully adopt if you grew up writing actual code. As crazy as this may sound on the surface, it does have the potential, at the very least, to serve as a “Figma On Steroids”, and a few companies are making a serious go at productizing this style of app development for the masses. Prepare yourself, then, gentle reader, for the talent and tooling landscapes to get a lot more chunky.

If you have ever shipped real software tasked with handling sensitive data while orchestrating mission-critical workflows, then at some point in the last two years you likely cycled — in relation to clickbait about the one-shot creation of apps with LLMs — through bemusement, indignation, indifference, and finally obliviousness. Setting aside the clear cherry-picking of examples that tended toward some kind of calendaring app which an LLM could more or less copy-paste straight from GitHub, a real application with a user base beyond yourself presents the non-trivial matters of deployment, hardening, monitoring, debugging, tuning, scaling, and revision — which is why software engineering stubbornly persists as a profession despite the recurring claims over the last couple of years that the whole shebang is just a few months away from being entirely automated. Oh, how I wish on many a frustrating day…

And yet we should not denigrate the people striving to find new ways to participate. We should, instead, fashion for them ramps and rails, paired with illuminating telemetry generators, mechanisms that make it easy and safe for people in one tier of technical ability to fashion solutions to their own tactical problems today while feeding executable requirements documents into the next tier of participants who can formalize and maintain them tomorrow. Thus do we innovate sustainably — or fail by tolerating a chunkiness that balkanizes savvy operators and strategic engineers while leaving substantial value on the table and likely accepting undue risks around security and reliability.

The road ahead on this journey will be long, hard, and uncertain, and yet examples abound of componentry that has wrapped potentially complex and treacherous sub-tasks in simple, standard, well-understood interfaces. Consider what Stripe has done for accepting credit card payments, Okta for solving authentication and authorization, GitHub for version control and delivery pipelines, virtual machines and containers for isolation and repeatability, and AWS for scalable hosting. If you are old enough, take a moment to remember how hard getting these things right used to be. If you are young enough, try to imagine.

Now run through your mind all the ways that an LLM-powered code spraying chain gun can make a hot mess — but then think of each of those as an opportunity to create a product that doesn’t yet exist, a component that wraps a powerful faculty in an elegant abstraction and provides it in a responsible manner to application developers. This feels like the hopeful middle ground between a world of slop code and one of human irrelevancy, one where all kinds of people can participate and our growing software biomass does not spiral hopelessly out of control. Perhaps it’s time we got off the hype train and on with building that future.