What happens when it's all streamlined?
One of my son’s favorite songs these days is (oddly, and thanks to recommendation algorithms) “The Worker’s Song”, as performed by The Longest Johns. My son calls it the “Pie in the Sky Song”, because of the line, “We’re the first ones in line for that pie in the sky.”
There’s an interesting verse in the song:
For our skills are not needed.
They’ve streamlined the job.
With slide rule and stopwatch,
Our pride they have robbed.
It’s hard to avoid talking about ChatGPT or Bard these days. In conversation, essays, and papers, many programmers are excited to find new applications, and worried that jobs like programming will become more about proofreading than engineering.
In one conversation I let my optimist out of his cage. I worked with the assumption that the capabilities of these tools would grow even modestly beyond what they can do now. And I thought about what tools might be realized in that near future. Nothing outlandish.
One idea was a tool to help me navigate an unfamiliar codebase. Wouldn’t it be nice if you could give a large language model a link to a GitHub repo, and it would summarize the file organization, data structures, and system architecture? Or better, prompt it with the text of a bug you’d like to fix or feature you’d like to add, and it would give options for how to add the feature in accordance with the style of the codebase?
It would even be useful just for studying. Recently I was looking at the
codebase for the ABC circuit optimizer
and thought, where exactly are the core optimization routines? There’s a
directory called
src/opt, but short
of reading through every header and digging around to figure out what the terse
comments mean (e.g., PackageName [Cut sweeping.]), it will take a
conversation with a maintainer to really get a handle on it.
Another idea was to summarize the development history of a repository, given
all the activity in a GitHub project, such as the commits and messages, issues,
release notes, etc. It could even be smart enough to discover transitive
updates. As my friend pointed out, when project A upgrades the version of
dependency B, A could silently pull in new features of B, and so these
new features are omitted from the release notes. The example he gave was an
image library adding support to export to png based on the requested filename
you save an image as. The maintainers of A might not know to include this in
release notes, but the tool could.
Tools like these would drastically lower the barrier to entry for contributing to and fixing bugs in upstream systems. When I’m working with a dependency and it doesn’t work the way I need, the effort required to fix or improve it upstream often drives me to find a workaround. There’s no way I could convince the maintainer (if there even is one) to change their code, and it’s too much of a rabbit hole to fix it myself, mainly because understanding the codebase is too steep of a prerequisite.
A friend of mine and I considered doing a livestream where we “speedrun” learning an unfamiliar codebase, by some measure like adding a new feature or fixing a bug. And then interspersing speedruns with an analysis of our methods. It would be interesting to see what sorts of tools you could build to streamline that process.
And that’s what this all boils down to. Like the Worker’s Song, as a field we programmers are always about “streamlining” our jobs. We’re the first ones in line to build the pie-in-the-sky tool. My fantasy about large language models is that they might help me streamline the ramp up process. It would make me feel very smart and powerful.
But I also stopped to wonder, what would happen if that dream came true? Surely not only I would be a ramp-up wizard. Anyone could be. My familiarity with the codebase, my experience with outages and bugs, my contextual knowledge about tech debt, would all become cheap, especially given how much I tend to write in bug reports and issue threads/design docs. One of my strongest skills, clear communication, fuels the engine that ushers in my obsolescence.
It’s not the first time someone has pointed out these effects. The modern form of the slide rule, after all, was invented by a French artillery lieutenant, the same folk who, in the Worker’s Song, are “given a gun and pushed to the fore.” Programmers today talk about passing the bus test: would your team/system be crippled by your absence due to being hit by a bus? Passing it necessarily makes you replaceable. Engineering management at large companies strives to make individual engineers replaceable. To a significant extent, this infroms why tech companies invest in building frameworks, infrastructure, and evangelism. These attitudes have already conquered management of data centers. At Google there’s a saying, “machines are cattle, not pets.” When one machine goes down, the scheduler restarts the occupying jobs on other machines. Will this saying evolve into, “software is commodity, not craft”? “Programmers are fungible, not critical”?
When employees are disposable, they will be disposed of. But somehow I downplayed this thought because, at least I had the benefit of being very good at ramping up to productivity quickly, and synthesizing knowledge well, and understanding hard things and making them easier to understand for others. I value and invest in mentorship of my team, and in building shared mental models of a system. But how much of that investment could large language models automate away? And how eager are we, collectively, to build that future?
I still want that tool.