In the year since I first wrote about AI assistance, I’ve been using LLMs increasingly for my job, personal projects, and writing. They fill several roles for me:
Beyond these specific uses, I see much potential in the malleability of the tool. As it continues to improve, I can see myself building more sophisticated workflows and personal applications3; using voice instructions while pair programming; having agents run commands in the shell and integrating applications; building local knowledge bases from code, text, and every little note I can scribble in the margin of my editor: a second brain to query and look at from all angles.
If I filter all the noise—which is loud—and try to be objective, I admit that even in their present flawed incarnation, LLMs may well be the most powerful human augmentation tool in the history of computing4. But for all its current and future power, I’m still convinced that they are a mediocre human replacement for intellectual and creative work5.
∗
I keep reading enthusiasts, both technical and non-technical, insisting that software development has already changed, that the future is now and programmers still typing code will soon be left behind. We should instead be running agent fleets, our work now consisting of feeding them prompts, reviewing their outputs, and getting them unstuck.
But even in that imagined future where LLMs are flawless and inexpensive, I would have objections about letting the machines do all the work:
The hardest part of software building is not writing code but figuring out what needs to be built: talking with colleagues, fleshing out and disambiguating product requirements, analyzing data, reading code and documentation, weighing alternatives, making a myriad of little decisions. Most of which can be enhanced by but not completely delegated to LLMs: by the time a sufficiently precise prompt can be written, most of the work would already be done. Unless your line of business is building throw-away prototypes, automating code generation is optimizing the wrong part of the process.
∗
As a software engineer, I see a lot of potential in embracing AI as a human augmentation tool. Not a silver bullet, not an order of magnitude increase in productivity, but more efficacy, more reach and engagement in our work. A bicycle of the mind, with E.T. sitting in the basket.
Companies that push today for AI to replace engineers will only get faster at producing bad software. They’ll hit a dead end when trying to turn prototypes into products, and won’t have sufficient organizational knowledge to backtrack.
So while we may be on the verge of dramatic changes in the way we go about our work, rather than trying to predict the future, let’s do what software development has taught us to do: understand what is the most effective way to solve the problems of today with resources available today; keeping things lean and simple, ready to execute when most are shifting gears.
…but that operates on stale data and is somewhat inaccurate.
…that is also a lying psychopath.
The fact that I’m an Emacs user helps here: I’m already used to paying attention to my habits, and my editor works like an almost limitless canvas to try any feature that I can imagine. As Simon Willison often puts it, AI can provide that extra boost of ambition to experiment with things that otherwise wouldn’t be worth the time investment. This is why, as the industry seems to push for uniformity, I’m encouraged to double down on personalized tools.
I’m less impressed by the models and their underlying technology than by the collective knowledge-building effort that enabled their training.
It’s not that I don’t think capitalists will attempt to replace knowledge workers—or that they won’t succeed. It’s just that when they do, the proportion of bullshit jobs will increase, and the average quality of the work will get worse. That’s not a future I look forward to and not something I can call progress.