this post was submitted on 09 Aug 2025
557 points (97.3% liked)
Technology
73970 readers
3694 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related news or articles.
- Be excellent to each other!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, this includes using AI responses and summaries. To ask if your bot can be added please contact a mod.
- Check for duplicates before posting, duplicates may be removed
- Accounts 7 days and younger will have their posts automatically removed.
Approved Bots
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Even when it gets it right, you have to then check it carefully. It feels like a net loss of speed most of the time. Reading and checking someone else's code is harder than writing your own
On the code competition, I think it can do like 2 or 3 lines in particular scenarios. You have to have an instinct for "are the next three lines so blatantly obvious it is actually worth reading the suggestion, or just ignore it because I know it's going to screw up without even looking".
Very very very rarely do I find prompt driven coding to be useful, like very boilerplate but also very tedious. Like "show user to specify these three parametets in this cli utility", and poof, you got a reasonable argv handling pretty reliably.
Rule of thumb is if a viable answer could be expected during an interview by a random junior code applicant, it's worth giving the llm a shot. If it's something that a junior developer could get right after learning on the job a bit, then forget it, the LLM will be useless.
have to agree on that, there's the variation, it's faster if you take it's code verbatim, run it, and debug where there's obvious problems... but then you are vulnerable to unobvious problems, when a hacky way of doing it is weak to certain edge cases... and no real way to do it.
Reading it's code, understanding it, finding the problems from the core, sounds as time consuming as writing the code.