Researchers seeing little evidence of benefit from co pilots
cio.com
cio.com
The best I can say is that the implementation in Jetbrains IntelliJ IDEA is pretty good. It's basically only useful for some repetitive Java boilerplate, but actually that's perfect, it's mindless enough yet easy to validate. It makes me dislike programming in Java a little bit less.
Allow me an anecdote - I was recently doing some HTML/CSS to update the public website for a client. This is not where I typically operate, though I obviously have some exposure over the years. Using Supermaven I was able to very quickly perform website surgery that would have ultimately taken me much more time reading Tailwind documentation and loading my RAM with details that would be mostly superfluous to 99% of my professional workload. It's in contexts like this where I think these tools shine.
'Game changer' is clickbait phrasing for these tools in their current incarnations, but they can certainly save time while producing acceptable results when used appropriately.
But what I reall like is using stuff like edge copilot and other chat-like ai tools to just ask questions and get some, mosty really well, summarized answers. Usually about tech I never used before, haven't used in ages or need to be migrated to much newee versions with breaking changes.
It saves me a lot of reading the docs, fiddling with it, reading the docs again, reading quite a few posts about it e.g. on stack overflow and than finally getting to work on the actual project.
I just ask my questions, try the suggested approach, fact check the docs and get to work
Open up a new code base, ask it to analyze the code and summarize the different main parts of it.
I was making a json schema for a typescript type and as soon as I typed the name of the json schmea, cursor offered to auto complete the schema.
"I think there is a concurrency bug in this file, can you find it for me?" that alone saved me potentially hours of debugging.
When working with APIs I don't often touch, such as Canvas, AI saves me hours to days of effort.
Using a LLM as an autocomplete (typescript, kotlin) I found it'd be right about 10% of the time, very obviously wrong ~30% of the time, but mostly (~60%) *plausible*. Plausible is the worst, because if I don't spot the error immediately it'll come back to bite me in the coming hours/weeks and it takes me much longer to fully comprehend existing code than it does to write new code myself.
Asking questions fares better, but I never have easy questions and for difficult ones it'll usually be wrong. Like, if I'm asking an LLM a question I'm usually at a point where I've read the docs and there's something I don't understand - so it's not that surprising that the LLM won't understand it either. Occasionally pointing out the flaw will get a better answer, but more often it just leads to a circle of flawed answers. I feel like people who say this is some sort of revolution are perhaps people who weren't very good at finding information themselves.
The only places where this stuff seems to be an unqualified success so far is for jobs where the quality of the output is not very important.
Urgh. I can't wait to retire.
I can’t say if the bug count is higher or not. Maybe it is higher in terms of total number of bugs I write throughout my coding session. But if bug count goes up 10% then the speed with which I fix those bugs and get to a final edit of my code is 30% or 40% faster, so the bug count is not the right metric.
Maybe the differentiator is that I am a solo-dev for all this work, and so the negative effects of the copilot are only experienced by me. If I were in a 10 person team, the bugs and the weird out of context code snippets would be magnified by the 9 other people, and the negative effects would be strong. But I don’t know.
> Like the Uplevel study, Gekht also sees AI assistants introducing errors in code. Each new iteration of the AI-generated code ends up being less consistent when different parts of the code are developed using different prompts.
> “It becomes increasingly more challenging to understand and debug the AI-generated code, and troubleshooting becomes so resource-intensive that it is easier to rewrite the code from scratch than fix it,” he says.
In particular if there's little standardization in prompting styles across the team, I could see things getting confusing.
But there are also bad incentives on teams that don't exist for solo devs: e.g. presumably you aren't shipping code solely because your manager is getting on to you about missed deadlines, without any business justifications for the hurry. AI codegen that effectively optimizes to the manager / user story seems bad for business.
Additionally, I find the copilot code suggestions during code reviews / pull requests sometimes useful. At times, it can offer some insightful bits about a code segment, such as potential exception handling fixes, etc.
I'd like to explore having copilot write unit tests, including representative test data, that can execute edge code paths. I haven't done this yet, but this seems exactly the type of thing that a "copilot" would do for me (not too unlike paired-programming, maybe).
Having a copilot completely write my code base, that's another thing entirely. There would be too much going back and verifying that it got it right. And additionally, I've seen it completely conjure up bogus solutions as well. For example, I've had copilot offer a configuration change that was completely fabricated; it looked legitimate enough that a senior systems engineer attempted to install/deliver the "fix" it offered when the suggestion was completely made up.
Overall, I guess my experience with copilot is not much different than working with any human. Trust but verify.
Much like how a nailgun won't just magically build you a house, it'll just let you build one quicker.
Need to sort a heap of data into x y z or convert it from x to y? Llm will show me the way, now I don't need to hire someone to do it for me.
But alas, so many seem to think a language interpretation tool is actually a do it all one stop shop of production. Pebkac, your using the tool wrong.
No it does not. Does an assistant have to be as qualified as their boss?
> “The LLM does not possess critical thinking, self-awareness, or the ability to think.”
This is completely irrelevant. The LLM can understand your instructions and it can type 30,000 times faster than you.
Doubly so when the content is at the same time plausible, seemingly valid, but horribly wrong. It is the worst possible combination, one that normally takes more time to find out what is wrong and fix it then it would have been to not use the assistant in the first place.
But I can read faster than I can type.
The delusion that LLMs or so-called "AI" must be equals to their human overseers is laughable. If these tools are to transcend their current role as mere comic relief, it's crucial to recognize that in any functional hierarchy, the "supervisors" are the true senior figures. This nonsense about management being a separate entity might apply in the tech bubble, but in the real economy, it's a fantasy—one that any serious adult left the cradle believing.
> This is completely irrelevant. The LLM can understand your instructions and it can type 30,000 times faster than you.
I suppose this sounds like some sort of achievement—though why anyone would be impressed is beyond me. It reveals an ignorance so profound that it fails even to reach the bar of a lackluster undergraduate's grasp of what non-deterministic polynomial time entails.
I say this with all honesty and with good faith: you should reflect on what motivated you to write that sentence and reassess why you thought it would be appropriate or clever. By writing such a thing you are embarrassing yourself and revealing a deep insecurity. It is also poorly phrased and sounds contrived. Do better.
Let's cut through the nonsense: the speed at which an LLM processes text is neither remarkable nor revolutionary—it's a brute-force algorithm churning through data with all the grace of a sledgehammer. By current standards, it's laughably inefficient, and your fixation on it reveals a stunning lack of depth. If you attempted to peddle these claims in a serious computer science department, you’d be met with the kind of laughter reserved for first-year undergraduates who haven’t yet grasped the basics.
And as for your response—how utterly pathetic. If my comparison of LLM efficiency to non-deterministic polynomial time were truly as off-base as you'd like to pretend, you'd have taken the time to refute it properly, to demonstrate where I’ve gone wrong. But instead, you've chosen the coward's path: declaring your supposed superiority while sidestepping any actual argument. You didn't refute my point because you couldn't, and now you resort to some vague, self-righteous posturing, suggesting that I should feel embarrassed. The only embarrassment here is yours—for thinking such a shallow tactic could pass for a real rebuttal.
It's also come to my attention that all this ridiculous AI hype marketing is having a far more sinister effect—it's causing some of the brightest young minds to give up before they even start. This is something I refuse to accept. If crushing the ignorant morons who perpetuate nonsense means I come across as mean, then so be it. I'll gladly take that role if it means clearing the path for those who actually have the potential to contribute something real to tech, rather than getting lost in the hype-fueled fog of delusion.
And if you think this is some grand breakthrough, let me assure you, those who actually know what they're talking about predicted ChatGPT's emergence just over a year before it became a buzzword to the public. These same experts, the ones who haven't overdosed on AI hype, would be the first to tell you that you’ve been duped—hook, line, and sinker.