Comment by fhd2

15 hours ago

Nice analysis! I would perhaps add that LLMs are pretty helpful at (2) in my experience, as long as you don't turn your brain off. (As a Google/SO replacement, mainly.)

I have about three modes, working with LLMs:

A) Just use them for (2), do (3) and (4) myself.

B) Just use them for (2) and (3), but with very fine grained instructions - to the point where it barely saves me time.

C) Use them for (2), (3) and (4), but with this workflow, it quickly degrades into slop for me.

I still get the best results with (A), but for a quick PoC, (C) is hard to beat.

What's hilarious (or sad) is that I see a lot of people throw them at (1) as well, which seems to have a high chance of inducing AI psychosis and creating software nobody understands, let alone needs.

I agree. If you use the AI for (4), it's pretty much guaranteed to hallucinate whatever it wants and then approve it. For small projects, it might be good enough. For anything serious, it's not.

I find I get the best results when I just use it for (3), and sometimes a bit for (2). Going in with at least an idea of how to make it work has the best chance of ending up with a good changeset. And if you already know how to make it work, don't leave it to chance. Tell the LLM what to do, then let it do it.

Regarding (2) figuring out how to do things at a higher level (e.g. the general architecture of an application) is pretty different from figuring out things at a lower level (e.g. how to fill text with a certain gradient in CSS - the stuff where years ago you would have spent hours reading documentation or browsing StackOverflow until you figured it out, if you weren't familiar with the topic). So you could use an LLM just for (2b) and (3) and do the rest yourself.

  • > the stuff where years ago you would have spent hours reading documentation or browsing StackOverflow until you figured it out, if you weren't familiar with the topic

    Why is it always hours to consult docs? I find most answers within minutes (including if I have to read code) and it’s only take a bit longer when I want to understand the why’s.

    The key is to make sure you have the right questions. I see people struggle with that where they only know something wrong but they can’t put it in words.

    • Ok, maybe you're one of the fortunate ones. With "if you weren't familiar with the topic", I meant the situation where you know what you want to do, but have no idea how exactly to accomplish it. Especially with frameworks, which generally have a quite rigid way to do things, if you're unfamiliar with that, it can take a while until you get anything done, despite good documentation.