Human coders are still better than LLMs

Re:Human coders are still better than LLMs by materiallie on Friday May 30, 2025 @02:08AM (#44133391)

This is my experience, too. As a concrete example, I'll need to write a mapper function to convert between a protobuf type and Go type. The types are mirror reflections of each other, and I feed the complete APIs of both in my prompt.

I've yet to find an LLM that can reliability generate mapping code between proto.Foo{ID string} to gomodel.Foo{ID string}.

It still saves me time, because even 50% accuracy is still half that I don't have to write myself.

But it makes me feel like I'm taking crazy pills whenever I read about AI hype. I'm open to the idea that I'm prompting wrong, need a better workflow, etc. But I'm not a luddite, I've "reached up and put in the work" and am always trying to learn new tools.

[ Parent | on HN ]

Re:Human coders are still better than LLMs by lazyasciiart on Friday May 30, 2025 @04:08AM (#44134042)

An LLM ability to do a task is roughly correlated to the number of times that task has been done on the internet before. If you want to see the hype version, you need to write a todo web app in typescript or similar. So it's probably not something you can fix with prompts, but having a model with more focus on relevant training data might help.

[ Parent | on HN ]

Re:Human coders are still better than LLMs by KTibow on Friday May 30, 2025 @06:24PM (#44140380)

These days, they'll sometimes also RL on a task if it's easy to validate outputs and if it seems worth the effort.

[ Parent | on HN ]

Re:Human coders are still better than LLMs by akoboldfrying on Friday May 30, 2025 @04:25AM (#44134134)

This honestly seems like something that could be better handled with pre-LLM technology, like a 15-line Perl script that reads one on stdin, applies some crufty regexes, and writes the other to stdout. Are there complexities I'm not seeing?

[ Parent | on HN ]