---
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.

### Even the failures are useful

Of course, it's not as though LLMs are a magic bullet for debugging. I've had plenty of experiences where the LLM confidently asserted that it had "found the issue," and sometimes even that it had "confirmed" its findings, when in fact the problem was completely different.

But even when this happens, it's not a total loss. A failed approach when debugging is still one possibility you don't have to investigate yourself, by hand. Not to mention that triumphantly explaining to the LLM how _wrong_ it is can sometimes cause me to realize what the problem _actually_ is, like a bank shot in pool. Or even (this has happened to me more than once) the very process of composing an explanation of the problem reveals the solution to me before I've even hit Send.

Also, when it comes to debugging, Fable is just better. I know that size isn't everything, as the other AI labs are quick to point out, but it seems that it still counts for something. Several times I've thrown a problem at a lesser model, watched it go around in circles for a while, then switched to Fable and gotten the solution on the first try.

## UI Mockups

I'm absolute trash at coming up with a UI from scratch. It's funny because I usually have a pretty good idea about the abstract, high-level premises of a design, like what information should be presented and what actions should be available. But for whatever reason, when it comes time to sit down and bang out some HTML or whatever, I'm just _useless_. I can easily sit there in front of a blank page for an hour or more, trying one thing, getting annoyed and deleting it all, trying something else, before (frequently) getting annoyed and going off to work on something else for a while.

So it's possible that my perception of an LLM's utility in this area is somewhat exaggerated. But I don't think that's the only factor. Consider: what's the biggest problem that most people have encountered with using LLMs? Their tendency to make stuff up out of whole cloth. What is _exactly_ what you want when you say "build me a mockup of such-and-such"? You want something that's made up of whole cloth. So really, you're just asking the LLM to do what it does best.

In fact, you might want several somethings made up out of whole cloth, which is something for which LLMs can also be extremely useful. I don't know about you, but I have a strong tendency to become myopic once I've started building out a particular solution to a problem. Other solutions are less apparent to me the more time I've spent focusing on the one at hand. So taking a step back and asking an LLM to reimagine it from the ground up can help to break me out of the rut. Or I can start out by trying several different models on the same design, and pick the best.<Sidenote>Admittedly I haven't actually tried this yet, so I don't know for sure that it would work. It's possible that their training is broadly similar enough that they will all end up with roughly similar solutions. Still, it seems worth a shot. Plus there's that "temperature" parameter that you can play with, if things seem too boring.</Sidenote>

## 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.