Not really - there's a difference between having the docstring of a function available for you to read, and a model which has learned from thousands of examples how to use a particular API and integrate it into a larger set of instructions. The latter is vastly faster and takes much less human work than the former.
Except when it consistently gets said particular API wrong. I was using it to do basic graphql-yoga setup with R1 and then Claude Sonnet 3.5 and they both output incorrect usage, and got stuck in a loop trying to fix it.
If it can’t do something that basic and that common using a language and toolset with that much training data, then I’m pessimistic personally.
I’m yet to see Copilot be useful for any of my juniors when we pair, it gets in the way far more than it helps and it is ruining their deeper understanding, it seems.
I’ll continue trying to use these tools, but I swear you’re overselling their abilities even still.
At this point with Cursor you can have it index the online docs by giving it a base URL and have it automatically RAG the relevant content into the chat (using the @ symbol to reference the docs). Both Windsurf and Cursor also support reading from URLs (iirc Aider does too).
I’ve had better luck with manually including the page but including the indexed docs is usually enough to fix API mistakes.
Begs the question again: if you need to go out of your way to find an example of correct usage of the api to paste into the prompt, why are you even bothering?
I find copilot useful when I already know what I want and start typing it out, at a certain point the scope of the problem is narrowed sufficiently for the LLM to fill the rest in. Of course this is more in line of “glorified autocomplete” than “replacing junior devs” that a keep hearing claims of.
That's an entirely client-side web page you can use to open a PDF which then converts every page to an image (using PDF.js), then runs each image through the Tesseract.js OCR program and lets you copy out the resulting text.
That's a nice little self contained example. I have yet to see this approach work for the day job: a larger codebase with complex inter-dependencies, where the solution isn't so easily worded (make the text box pink) and where the resulting code is reviewed and tested by one's peers.
We actually had to make a rule at work that if you use an LLM to create an PR and can't explain the changes without using more LLMs, you can't submit the PR. I've seen it almost work - code that looks right but does a bunch of unnecessary stuff, and then it required a real person (me) to clean it up and ends up taking just as much time as if it were just written correctly the first time.
It's faster if all you're concerned with can fit in a static html file but what about for more complex projects?
I've struggled with getting any productivity benefits beyond single-file contexts. I've started playing with aider in an attempt to handle more complex workflows and multi-file editing but keep running into snags and end up spinning my wheels fighting my tools instead of making forward progress...
Yeah thats the trick I've been using too, but by that point I get a better result by implementing it myself... of course, I've had two decades of practice and I don't have to communicate what I want lossily to myself, so it's an unfair comparison, but perhaps I've just not found the right use-case yet. I'm sure it exists, I've just not had much luck over the past couple years yet (including just this past weekend).
That is far more likely to happen when it is relying on compressed knowledge of documentation and usage for an API it would have seen (comparatively) only a few times in training. That is where the various types of memory, tool calling and supplementary materials being fed in can make them significantly more situationally useful.
The LLMs you mention are first and foremost a “general knowledge” machine rather than a domain expert. In my opinion, Junior developers are the least likely to benefit from their use because they have neither the foundational understanding to know when the approach is wrong, nor the practical experience to correct any mistakes. An LLM can replace a junior dev because we expect the mistakes and potentially poor quality, but you don’t really want a junior developer doing code reviews for another junior developer before pushing code.
The expectation for junior devs will probably change as well and they’d do a lot more shadowing while learning the product. Experience is gained in time.