I am the 0.1x developer (if not less)
I was in the middle of writing yet another job application (#internship-grind) when one of friends messaged me telling I should just use an LLM to write it for me. My immediate response, as it is to most LLM related things, was “AAAAAAAA ughhhhhh I have feelings™️”1, prompting the reply “That’s not very 10x mindset of you” along with a link to an article from where he’s doing an internship. I jokingly replied “yeah I’m a 0.1x developer” (prompting the idea for this post), and then spent the rest of the day making a working compiler from scratch.
The 10x developer
As far as I can tell, the idea of the 10x developer originated in a 1968 study, which found that speed differences in various programming related tasks varied by 10x or more between individual programmers. The term then came to describe the kind of programmer who would plug away in isolation, suddenly creating some amazing project that was seemingly impossible for one person to do on their own.
At least for solo work, this sounds like something to strive towards. So why did I instantly have such a negative reaction to it?
With the rise of LLMs and “vibe coding”, at least to me, it feels like the meaning has instead shifted towards a programmer who prioritises rate of code production over every other possible attribute. And this just doesn’t sit right with me. I’m not writing code just for the sake of churning out code. I’m writing code because I enjoy the process of writing it. I enjoy puzzling out a nice clean solution. I enjoy learning new approaches to problems, or how common tools work. Maybe this is different because I’m only working for myself rather than professionally and this’ll come across as old guy yelling at clouds, but oh well.
Slowing it down by 100
Going back to the pre-LLM definition, the 10x developer feels like something that you could probably apply to my projects. Going back through my solo projects over the past 5-ish years, you end up with the usual assortment of Advent of Code, university coursework, and random scripts, and then come to compiler (twice), operating system (three times), along with 3 or 4 motorsport mechatronic projects that I juggled in parallel on top of full time schooling. Would these have been sped up if I got some agentic AI2 to do it for me? Probably. Would I have preferred to do it that way? Hell fucking no.
The vast majority of code I write is because I’m interested in the process of getting to the result. I want to make the typical pitfalls. I want to get stuck and give up for 9 months. I want to tear my hair out at compiler errors and segfaults. Because all of those make me a better programmer - they give me a better understanding of every step. No amount of thoughtless prompting would have taught me about memory safety as much as all the fuckups I made in C++. Nothing could’ve explained how an OS works at every level than just sitting down to write one. But maybe the most important factor, is that all those problems forced me to slow down and actually think.
All the big discoveries that I can think of off the top of my head were made because someone sat down and actually thought. Now I’m not suggesting that I’m going to suddenly formulate special relativity from a thought experiment in the middle of programming session, but any amount of human thinking is bound to generate more interesting novel ideas than prompting could. And this pays off in better code. I could write the shittiestly designed codebase, then point an agent at it and ask it to add some extra feature. It would probably attempt it, maybe actually do it, the agent wouldn’t care the codebase is shit, and I’d never realise.
Contrast this with if I’m doing the entire process myself. I start tediously fighting whatever godforsaken API past me came up with, realise there must be a better solution, sit down and have a think, and end up with a more elegant and maintainable codebase. And then I’m happy, because I got to solve a problem, I got to spend time working on my project, and because my code is nice. Because what’s the point of doing a side-project if you don’t care about doing the project well? (And arguably, having a codebase that’s easy to work with in future provides substantially more productivity than any amount of spaghetti created by vibe coding could achieve).
LLMs are stupid?
It’s not like I’ve never tried using LLMs for anything. I first started toying with them back in 2020, when doing final tuning of GPT-2 was still something achievable by yourself. I dumped two years of chat history into a file, passed that into code I found from a tutorial somewhere, and after some training, ended up with something that could scarily accurately impersonate me and my then-boyfriend. Then about 1.5 years later, wanting to see what the hype was about, I got access to the GitHub Copilot preview. Quickly it became the most irritating aspect of any project I was working on, and I had to constantly hit the escape key because every completion it came up with was absolute nonsense that half the time wouldn’t have even compiled. I think after about 6 months of irritation, I uninstalled it and didn’t touch LLMs for programming until around 2023.
This new product had just come onto the market, and it was all the hype - ChatGPT - and I decided to have a little play with it to see how it compared to GPT-2 by getting it to do some silly tasks and test its knowledge. Then at some point of 3am desperation of LLVM’s build system refusing to comply with whatever horrifying configuration I was trying to achieve, having failed to find any useful documentation and getting tired of reading through 50 CMakeLists.txt files I decided to try out this newfangled LLM thing for programming. And wow was that a bad decision - my only lasting memory is getting increasingly frustrated at ChatGPT going round in circles, constantly hallucinating new config flags and getting nowhere, refusing to admit that it didn’t what it was talking about.
And that’s what I conclude every time I try to use an LLM for writing code for any of my real projects. If there’s not enough information in the training data (and I can’t imagine undocumented aspects of LLVM build systems are in there much) it can’t output anything factual (and therefore can’t provide anything useful). But instead of admitting a lack of knowledge, it ends up going round in circles contradicting itself and frustrating me.
A reflection on how I use LLMs for programming
Do I use LLMs as part of my programming projects? Yes. But I see them as a tool, and like any tool, they have uses they work well for, and uses they’ll maybe half-work but won’t work well.
For me, I’ve found two main uses that work well.
Firstly, one-off throwaway scripts that I don’t care about: if I need to quickly automate something, won’t learn anything in the process of writing it, and see no need for future extensions to it, then there’s literally no point in me spending the time writing it.
Secondly, the rubber duck. Rubber duck debugging has been around long before LLMs were commonplace, and it’s worked amazingly for me and many other people I know. But it relies on having the knowledge internalised somewhere to be able to solve the problem without external ideas. Swapping out the duck for an LLM (in the right situations) I’ve found can be great when trying to figure out a solution for something relatively simple, doesn’t require figuring out how to move large amounts of context from my brain into the LLM, and most importantly, when there’s enough information already published that the LLM actually has something in its training data to base a sane response on.
So, in the end, I’m not saying don’t try to be the original 10x developer. Just to slow down the process. Spend more time thinking and trying out different ideas. LLMs can definitely have their uses in the process, but just thoughtlessly prompting until something vaguely works won’t make a good programmer, nor will it make for good code. It’s all just situational.