56 lines
6.1 KiB
Plaintext
56 lines
6.1 KiB
Plaintext
---
|
|
title: Slam-dunk No-brainer Uses For LLMs, Today
|
|
date: 2026-04-09
|
|
draft: true
|
|
---
|
|
|
|
import Sidenote from '@components/Sidenote.astro';
|
|
|
|
There's a lot of debate these days on how far and how fast AI will go, will it take over all human endeavor or just some, will it gain sentience<Sidenote>According to some, it already has.</Sidenote> and decide to exterminate humanity, etc. I have lots of thoughts about those questions, but that's not what I'm here to talk about today. Today, I would like to talk about what you can already use LLMs for, productively, with few-to-no downsides. Most of my own experience using LLMs has been for coding, so that's what I'm going to focus on here.
|
|
|
|
None of what I'm saying here is particularly novel, or even very interesting if you're very experienced with using LLMs for coding. Really I'm writing as much to organize my own thoughts as anything else, and to hopefully cement in my mind that "these are the sorts of tasks for which I should use an LLM" so that I don't waste time in the future doing something by hand that really _would_ be better done by an LLM.
|
|
|
|
## Debugging
|
|
|
|
Now, I need to preface this by saying that LLMs are not a magic bullet for debugging, just like for most othe things. But here's the thing about debugging. _A lot_ of the time that I spend debugging is really just spent staring at code and waiting for inspiration to strike. If I don't immediately have a theory for what's wrong upon seeing the bug - or if I do, but my theory turns out to be wrong - I often just get stuck. And I will sit there, poking at random things, bouncing around between the same three pieces of code or whatever, waiting for some unconscious process to click into place and provide me with a new angle of inquiry.<Sidenote>It really is an unconscious process, which is where the advice to "sleep on it" comes from. This often really works! Taking time away from a problem and coming back to it can often provide fresh insight, even though - maybe even _because_ - that time isn't spent consciously thinking about it.</Sidenote>
|
|
|
|
But a lot of the time, the root cause of a bug is really glaringly obvious once you finally figure it out. A coworker and I have a private aphorism that we always quote to each other: "The more baffling and incomprehensible the problem, the more obvious the solution." This isn't _strictly_ true, of course; some bugs really _are_ baffling and incomprehensible, but it's true the vast majority of the time.
|
|
|
|
But what if you could flip that around? Instead of trying to work back from the problem to a possible solution, what if you could be presented with a possible solution and then determine whether it matches your problem? If the solution really _is_ obvious as soon as you see it, then it would be much easier if you could just crank out a dozen possible solutions, then check them each to see if they trigger that "oh, duh" flash of insight.
|
|
|
|
So all you need is something that can barf out a bunch of _plausible_ solutions to your problem, without necessarily having to be right every time. And LLMs are absolutely _great_ at that. They don't even need a very good hit rate. If even 20% of their suggestions are worth pursuing (and in my experience it's usually much better than that), then you're still coming out ahead, because it can come up with 5 suggestions far faster than it takes you to come up with even one.
|
|
|
|
### Especially syntax errors
|
|
|
|
But LLM debugging _really_ gets supercharged when it comes to syntax errors. I don't know if this is a common problem or if it's just me, but I can easily spend upwards of half an hour staring at just a few lines of code, looking for the syntax error that my tooling is complaining about but that I _just can't see_.<Sidenote>SQL is the worst for this. For some reason, databases seem stuck in the stone ages when it comes to reporting synatx errors. If you're _lucky_ they'll give you a character index, but most of the time it's just `Invalid syntax, near AND` or something. Great, thanks. there are 20 ANDs in this query, that's real helpful.</Sidenote>
|
|
|
|
But when I throw these situations at an LLM, it will usually find the syntax error on the first try. I have very rarely observed an LLM failing in this paticular situation. I think it might have to do with the way LLMs process text in tokens: while humans process text visually, so it's easy for us to miss things that are visually less prominent (like dots and commas), LLMs see text as a series of tokens, whose similarity is governed by their _meaning_<Sidenote>Kind of; my understanding is that LLMs ultimately reduce "meaning" to something like "this word's statistical relationship to a bunch of other words, based on analysis of a massive amount of text."</Sidenote>. Moreover, LLMs are fundamentally "next-token predictors", <Sidenote>Not trying to minimize their capabilities here, it's truly incredible that we've gotten so far with such a conceptually simple mechanism.</Sidenote> so something like a missing or extra comma is _glaringly_ obvious to an LLM in a way that it wouldn't be to a human.
|
|
|
|
And thank goodness for that, because tracking down a non-obvious syntax error is one of my least favorite ways to spend time.
|
|
|
|
### But they can still fall flat
|
|
|
|
Not that, again, LLMs are a magic bullet for debugging. In my experience, most bugs fall into one of three categories:
|
|
|
|
1. Obvious bugs, where you know what's wrong as soon as the bug manifests,
|
|
2. Subtle-at-first-but-ultimately-obvious bugs, where the root cause is hard to track down but obvious once you see it, and
|
|
3. _Actually_ subtle bugs, the kind that you write up on your corporate blog after solving to reap those sweet sweet upvotes.
|
|
|
|
## UI Mockups
|
|
|
|
## Brainstorming
|
|
|
|
You can't uncritically accept everything it comes up with, of course, but if you're stuck an LLM can really help to get you unstuck sometimes.
|
|
|
|
## Boilerplate
|
|
|
|
e.g. persistence wrappers
|
|
|
|
## Migrating
|
|
|
|
E.g. Vue options -> composition API. This has to be used with some care, though, since porting something to a sufficiently different paradigm can introduce weirdness. (E.g. Python that looks like it was written by a Java programmer)
|
|
|
|
## Naming Things
|
|
|
|
No joke! One of the two Hard Problems in Computer Science, but they're great for it.
|