[mpalmer]

AI is fantastic for doing stuff you are already qualified to do, but faster. It's great for prompting you with what to do next, and offering different ways to think about the problem in front of you. But you have to be able to describe the problem.

It's very good for learning more about stuff you're unfamiliar with. But you have to want to use it as a tool to learn.

It's terrible for inexperienced people who are uninterested in learning and who want a shortcut to a bigger paycheck. Vibe coding will not save the apprentice developer.

What worries me is how stubbornly younger devs (and really all students/younger professionals) seem to be resisting this rather obvious conclusion. It's Dunning-Kruger on steroids.

A rising tide lifts only seaworthy boats.

[rmholt]

Perhaps there's something wrong with traditional docs, how we write them, when junior devs are so insistent on using AI?

[muzani]

Well, there's AI for reading source now. In fact, a lot of the time I spend arguing with AI now is the implementation of things like replaceAll('{{$value}}').

If value is foo, then the intent here is {{foo}} would be replaced. But sometimes the $ is a regex character. But because it's a string, is it using the string form of replaceAll or regex form?

AI tends to be multilingual and sometimes it's thinking in the wrong language, so this is the vibe code version of 10 + 10 = 1010.

The docs can be ambiguous on this, so ideally read the source. Or heck, tell AI to read it for you, but someone has to read it, and it becomes another gotcha for engineers to understand, vibe code or not.

[mpalmer]

I don't think that's the problem. It's time and effort; junior devs (and more broadly, humans) always want to see how little they can spend; here they incorrectly believe they can lean on LLMs and get a guaranteed increase in quality output. Even if that were true today (and we're nowhere near that), you would still either have to know how to evaluate the output for correctness, or trust that the model has handled it.

Junior devs seem to just trust it now, because they literally don't know better.

[ibash]

Engineers that only rely on docs never reach their full potential. Reading the source is a must.

I think junior devs often don’t realize they should be reading the source of the libraries they use.

[taatparya]

That is an important catalyst aggregating the problem. Juniors are reading less code, mostly generating and then AI code produced dissuades them from reading code even more and the skills take a bit even more.

[skydhash]

Most docs are for experienced people to get valuable, exhaustive, and correct information when they need to. Learning about the same concepts is a different paradigm and you'd be better off with an actual book/tutorial. My most use information repositories are MDN and the likes, Devdocs|Dash, and sometimes library code when the documentation is lacking. But when I'm unfamiliar with a language/platform, I seek a book or a guide to get familiar with it.

LLMs can't help you if you want to skip the learning|training phase. They will present you something that you can't judge because you lack the qualification to do so. You don't learn how to play piano by only listening to it, or painting by viewing pictures.

[Breza]

Very well put. I also read books to learn concepts. I usually only turn to documentation to remember the nitty gritty details that are easy to forget. Consider loading the first 100 rows of a large CSV. About as basic as code can get. Yet as I move between languages and libraries, it's hard to remember all the different syntaxes, so I find myself looking up official documentation.

read.csv("large.csv", nrows = 100)

read_csv("large.csv", n_max = 100)

pd.read_csv("large.csv", nrows=100)

pl.read_csv("large.csv", n_rows=100)

CSV.read("large.csv", DataFrame; limit=100)