Comment by Sparkyte
8 days ago
Definitely squeezed.
They say AI, but AI isn't eliminating programming. I've wrote a few applications with AI assistance. It probably would've been faster if I wrote it myself. The problem is that it doesn't have context and wildly assumes what your intentions are and cheats outcomes.
It will replace juniors for that one liner, it won't replace a senior developer who knows how to write code.
> The problem is that it doesn't have context
You are supposed to give it context, if you dont provide it context how will it know what its supposed to do?
I really wish that was the case. You can give it only so much context before it starts to go down a path where the context doesn't even make sense to it, and yet if you explained it to a colleague they would instantly understand.
Context has layers and really 1st or 2nd layers ever get reached by AI but it can't dive further because it is too focused on the final output rather than the continuation of the output.
For example you write code and then tell it what the final expect output is, it some how always divorces itself from rudimentary implementations and poops out something that cut a lot holes out or shortcuts all of your work. Removes modularity in favor of that immediate outcome. AI is just not good enough to understand the complex relationship of maintainable code and deliverable code. So it poops out what is easily made to meet the deliverable.
I felt this way with Github Copilot but I started using Cursor this week and it genuinely feels like a competent pair programmer.
What work are you doing the last few days? My experience is for a very narrow range of tasks, like getting the basics of a common but new to me API working, they are moderately useful. But the overwhelming majority of the time they are useless.
This has been my experience as well.
Cursor Chat and autocomplete are near useless, and generate all sorts of errors, which on the whole cost more time.
However, using composer, passing in the related files explicitly in the context, and prompting small changes incrementally has been a game changer for me. It also helps if you describe the intended behaviour in excruciating detail, including how you want all the edge cases/errors handled.
I recently tried Cursor for about a week and I was disappointed. It was useful for generating code that someone else has definitely written before (boilerplate etc), but any time I tried to do something nontrivial, it failed no matter how much poking, prodding, and thoughtful prompting I tried.
Even when I tried to ask it for stuff like refactoring a relatively simple rust file to be more idiomatic or organized, it consistently generated code that did not compile and was unable to fix the compile errors on 5 or 6 repromptings.
For what it's worth, a lot of SWE work technically trivial -- it makes this much quicker so there's obviously some value there, but if we're comparing it to a pair programmer, I would definitely fire a dev who had this sort of extremely limited complexity ceiling.
It really feels to me (just vibes, obviously not scientific) like it is good at interpolating between things in its training set, but is not really able to do anything more than that. Presumably this will get better over time.
If you asked a junior developer to refactor a rust program to be more idiomatic, how long would you expect that to take? Would you expect the work to compile on the first try?
I love Cline and Copilot. If you carefully specify your task, provide context for uncommon APIs, and keep the scope limited, then the results are often very good. It’s code completion for whole classes and methods or whole utility scripts for common use cases.
Refactoring to taste may be under specified.
8 replies →