Have you ever been asked to help with something, agree to do it, only to find out your job is to just stand there and hold a flashlight while someone else does all the work? Then, when they’re done, they thank you for the help? When you’re a kid and get relegated to flashlight holder, it’s the most depressing feeling in the world. You did literally nothing, and the other person had the gall to thank you. Then you get older, and have to do some job that requires a third (or even fourth) hand, and all of a sudden having someone there to just hold something in place for you actually is a really big help. I get the impression that the whole trend of AI development is a bit struggle to figure out who’s doing the work, and who’s doing the minor, but still very helpful, assisting.
The problem with the “AI all the things hype” is that there’s 2 types of people, and you can see both types in this tweet from development content creator Theo (creator of T3.chat):
It’s worth noting here that while I’m not personally a fan of LLM coding, Theo has been 1 of the best voices in favor of using LLMs throughout the development process that I’ve seen, mostly because he’s very consciously avoided blind hype and done the best job I’ve seen demonstrating work that’s obviously been used LLMs in its creation in addition to having the in-depth knowledge of his software and its dependencies that shows he’s not outsourcing the “knowledge” part of knowledge work.
The problem is that the LLM development conversation is getting drowned out by the Nat Eliasons that he’s quote-tweeting. The kinds of people who think that LLMs will just handle all the software and thinking parts, and the role of people in the process is to type out the prompt and accept the output. That means we’re not getting quality conversations and discussions about LLMs from people that are using them every day, focusing on really defining where it works, where it doesn’t, when you should and shouldn’t rely on LLMs (for instance, from Theo – when you know how to do something inside and out, and don’t want to bother typing it). Instead we’re getting hype from managers or tech bros with a stake in making the “programming is over” predictions come true. That’s quite frankly creating a visceral reaction against LLMs in people, and it certainly seems to be intensifying.
To go back to the “holding the flashlight” analogy from earlier, Theo represents the type of person who saw how an extra set of “hands” would be useful, got some help, and used it to make working easier. It’s an assistant, but 1 that’s appreciated. Eliason views humans as the flashlight holders – necessary, but somehow still more “in the way” than actually contributing.
Being the flashlight holder, absent any other context, is demoralizing. Especially when being pitched by people who think of software and QA engineers as “resources.” If engineering is entirely fungible, then you can easily just sub in an LLM for actual people and have the engineers focus on approving the changes as fast as possible`. These are the same people who are shocked, shocked they say, that consumers don’t want “AI-first” products, and insist on referring to LLM content as “slop.” People who use LLMs for development every day still emphasize the fact that you have to already know how to do the thing you’re asking the LLM to generate (or at least know it well enough that you can recognize what a valid solution should and shouldn’t look like). That leads to people giving details about identifying the edges around where LLMs do and don’t do well.
There are people finding cool uses for LLMs in coding that are fairly uncontroversial – code completion, scaffolding and templating, and common implementations and patterns used throughout your codebase (e.g. “capture metrics around {things_you’re_interested_in} and push them to our observability platform, see how we do it {other place this has already been done} for reference”). There are other, cooler uses that got buried in the pile of “just vibe code it lol” BS, like using LLMs as a code search tool – handy for navigating large codebases – for instance “where do we populate this card on this page” instead of finding something unique to the page and grepping the code for it, or using LLMs to provide code examples specific to your stack.
I don’t use LLMs for coding, but I still want to hear more from the people who use them as the proverbial extra set of hands, and less from people who think LLMs are the what should be doing everything but clicking an “Accept chages” button. There’s probably some good uses for LLMs in development, but we can’t get to those because it’s all getting drowned in the crap from people who think glorified autocompletes are the new software engineers.
I’d be a lot more willing to concede the claim that I don’t understand the value of being the guy who just clicks “Accept changes” the same way I didn’t understand the value of being the kid who held the flashlight if the same people saying “just let the AI deal with the code” weren’t the same people who never hesitated to lay people off, outsource, or hire H1-B’s because they’re cheaper and less capable of moving to better companies. Their argument has nothing to do with the merits of LLM coding, and everything to do with enthusiasm over skimping a few bucks on employees. If we as an industry could get those losers to STFU, we’d be having much more productive discussions on LLMs in software, such as how senior should you be before you start using them, and the best way to use them.
For instance, take this tweet below from the creator of Bun:
This is clearly a senior developer, who knows the application inside and out. He’s listing the files, showing an example for how to implement it, and defines how to test it. In other words, he knows exactly how to do this, describe it clearly, and is simply outsourcing the writing to the LLM. I still stand by the argument that when you get to this point, actually typing the code isn’t typically the bottleneck, but again, it’s a scenario where the developer knows the code, and what they’re doing, and just doesn’t feel like pressing keyboard buttons. 1
There’s lower-scale versions of these tools that seem much more in line with the “sometimes it’s useful to have an extra set of hands doing something simple for you while you deal with business logic, like the Neovim plugin 99 from content creator ThePrimeagen. As someone who writes a lot of Java for a living, I could see myself documenting expected behavior of getters, setters, equals, hashCodes, and toStrings so I can focus on putting together Javadoc that I can reference through tooltips later, and focus on things like actually processing data. But again, that’s using LLMs to effectively hand me useful tools that I could easily step back and get myself. It makes things easier, but it’s not doing the work for me.
There’s a real, and valid, argument to be made that using LLMs can speed up programming, but it’s not automatic nor is it intuitive. In fact, it can seem like these tools are helping, but actually make things worse, so even the real, valid arguments may well just be humans hallucinating. I’d love to actually get real answers to these questions, and I’d love LLMs to conceivably be a tool that makes my life easier. There’s a lot of work that would be easier if something could hold the figurative flashlight so I can see what I’m doing and use 2 hands to do it. But I have no interest in holding the flashlight for something I’m going to be increasingly told doesn’t need me. And as long as the latter people are dominating the conversation, I’m going to rest assured in my long-standing belief that “have the LLM write the code” people don’t know what they’re talking about, and just want an excuse to be the next group of people to lay a bunch of people off and regret it.
- There are a handful of times where implementing something is more time-consuming than actually difficult, but that’s generally where type out a lot of code for a well-known, well-defined problem. It’s why LLM s do such a good job re-creating tutorial apps very quickly or generating greenfield projects. ↩︎