[godelski]

Do you think this is actually faster than reading the docs? Every attempt I've had with LLM pair programming (I do it at least once a month trying to measure performance) ends up taking more time than if I turned to Google out the docs, even with how bad Google has gotten. Though it _feels_ faster because it _feels_ like you're making continual progress where reading docs doesn't have the same feeling. I suspect this is a confounder but I'm open to just being bad at AI programming (though isn't it meant to be universal? I mean I'm a ML researcher and that's what the papers promise).

I'm also curious if you think it helps you improve. Docs tend to give extra information that turns out to be useful now and many times later.

I still like and use LLMs a lot though. I find them useful in a similar way to your last paragraph. My favorite usage is to ask it domain topics where I'm not a domain expert. I never trust the response (it's commonly at best oversimplified/misleading but often wrong), but since it will use similar language to those in the field I can pick out keywords to improve a google search, especially when caught in term collision hell (i.e. Google overfitting and ignoring words/quotes/etc).

I do also find it helpful in validating what I think some code does. But same as above, low trust and use as a launching off point for deeper understanding.

Basically, I'm using LLMs as a fuzzy database optimized towards the data median with a human language interface. That is, after all, what they are.

[jitl]

Often the docs for a library suck or lack suggestions about suggested structure, but LLM has ingested many open-source example uses from Github etc and so can offer code examples or explanations totally absent from the docs. I find this if a library has lots of comments for individual functions or struct types, but little tutorial-style and module-level docs.

Other times the docs are hundreds of pages, "read all the docs" is too much reading for a simple task, and so asking AI for just the code please is the right move to get started.

[godelski]

  > Often the docs for a library suck or lack suggestions about suggested structure

I don't disagree here. I do preach that one should document as you code. This gets a lot of pushback. But tbh, I think the one who benefits the most is yourself. What's the old joke? "What idiot wrote this code? Oh... that idiot was me." Give it a week and there's a good chance I forgot my though process, what I was doing, and why. Depends how many projects I have and how attention must be split.

But there's a lot of ways that documentation happens. One of my favorites is unit tests. Before I turn to reading source code to figure out how something works, I go look at unit tests. That way I prime myself for what to look for when I do need to look at source.

FWIW, even with highly documented things I go look at source pretty regularly. I'm a ML researcher and I'll tell you that I go poking around torch's code at least once a month. If you're using libraries quite frequently, it is probably worth doing this.

I also want to say that I remember the fear of doing this when I was much more junior. That it all looked like gibberish and inparseable. But this is actually the same thing that happens to any fledgling PhD student. Where you're required to read a bunch of papers that don't make sense. The magic is that after reading enough, they do start to make sense. Same is true for code. There is a certain "critical mass" needed to pull all the ideas together. Yes, LLMs can help make this process easier and probably reduces the requisite mass, but I also HIGHLY suggest that you still read source (not for everything! Of course! But anything you use regularly). It is scarier than it seems and you'll honestly be able to parse it before you know it. Learning requires struggling and as humans we like to avoid struggle. But the investment pays off big time and quickly compounds. Were I to go back in time and advise myself, I'd tell myself to do this earlier. I was just fortunate enough that I had a few projects where this ended up being requires and (un)fortunately extremely difficult to parse code (I was in template metaprogramming hell).

There's a bad habit in CS: move fast and break things; or alternatively, just ship. This is great in the learning process. You learn from breaking things and getting your minimal viable product is hard because you don't even know everything you need till you are knee deep into the problem. But the bad habit is to not go back and fix things. Little optimizations also compound quickly. You can never escape tech debt, but boy does it pile on invisibly and quickly. There's a saying that a lot of tradesmen and engineers use: "do it right, or do it twice." (alternatively: "why is there always time to do things twice but never enough to do it right?") I think we could learn from this. Software is so prolific these days that we need to move from living in the wild west. Truth be told, the better LLMs get, the more important this will be for you.

[nzach]

> Do you think this is actually faster than reading the docs?

It depends on your goals, I guess. Do I really need to read the whole D3.js docs just to transform a csv into a pretty map? I'm not arguing against the docs, I genuinely think that by reading the D3.js docs I would become a better professional. But what is the ROI for this effort ?

Nowadays learning about a topic is a choice we can make, we can create things that solve real problems without the need to fully understand the solution. This wasn't feasible a couple years back. And choosing 'not to learn' too many times is a great recipe for disaster, so I understand why a lot of people are worried about giving this option to people.

Besides that the "always read the docs" theory makes an assumption that isn't always true. This assumes you know what are you looking for and where you can find it. When I was younger I was assigned to a task that required me to put a new feature in a jenga tower of custom bash scripts and I've found a bug that completely stumped me, it took me an entire week to figure out I was missing some quotes around $@ when passing arguments from one script to the next. I've spent several hours trowing random combinations of keywords to try finding something relevant to my problem. Now I know this is a bash-related problem, but at the time this wasn't clear. It might have been something in my logic, or something to do with not being an TTY, or something to do with the version of the tools I was using.... Having a LLM would have saved a week of frustration because I could just vaguely describe my problem and ask questions about my issue to point me to right direction faster.

> I never trust the response (it's commonly at best oversimplified/misleading but often wrong)

This reminds me of my middle school. When I was there technology and especially Wikipedia was just starting to get popular and almost every week some teacher would lecture us about the dangers of these new technologies and how you should never trust anything on the internet. As time passed the quality of Wikipedia content increased, but this idea of never blindly trusting something you found on the internet really stuck with me. And now LLMs are just another thing on the internet you should never blindly trust for me. Maybe that is part of the reason why I don't get too angry when the LLM tell me something that is wrong.

> I'm using LLMs as a fuzzy database

That is a really good way of putting it. And I agree this is a great use-case for LMMs. But I think we still have a lot to learn about how to effectively use LLMs. I just hope people don't get too caught up in all the marketing surrounding this AI hype cycle we are living right now.

[godelski]

Sure, I agree.

When in the "move fast and break things" phase, yeah, LLMs can be useful. But do you ever move out to clear the tech debt or do you just always break things and leave a mess behind?

The issue is that it all depends. If something doesn't matter, then yeah, who fucking cares how inefficient or broken it is. But if it does, it's probably better to go the slow way because that knowledge will compound and be important later. You are going to miss lessons. Maybe you don't need them, maybe you don't need them now. It depends and is hard so say. But I would say that for juniors, it is bad to become reliant upon LLMs.

It's dangerous in exactly the same way as having a solution manual. They can be quite useful and make you learn a lot faster. OR they can completely rob you of the learning experience. It all depends how you use it, right? And for what purpose. That's the point I'm trying to get across.

  > it took me an entire week to figure out I was missing some quotes around $@ when passing arguments from one script to the next

This is a common issue, and one I faced too (though not that long). But it also led to more understanding. I learned a lot more about the quotes and variable passing. If someone had just given me the answer, I wouldn't have gotten the rest. Don't undermine the utility of second order effects.