You’re catching some downvotes, but I agree with your perspective. I’m feeling very productive with LLMs and C# specifically. There’s definitely some LLM outputs that I don’t even bother checking, but very often the code is visibly correct and ready for use. Ensuring that the LLM output conforms to your preferred style (e.g. functional-like with static functions) helps a lot. I usually do a quick formatting/refactoring pass with the double purpose of also understanding and checking the code. In case there’s doubts about correctness (usually in just one or two spots), they can be cleared up very quickly. I’m sure this workflow isn’t a great fit for every language, program type and skill level (there’s experts out there that make me embarrassed!), but reading some people I feel like a lot of my peers are missing out.
I think the reason for this gap are the differences in scope and novelty between codebases. When you need an LLM to write a piece of code that's been written a million times before (e.g. "find the normal vector to this plane", "find the highest scoring user") it generally produces decent code.
But on the flip side, this type of code is intrinsically less valuable than novel stuff ("convert this signed distance field to a mesh") which an LLM will choke on.
Not sure that vector normalization and “MaxBy” count as a piece of code. It’s a building block, less than a line of code. Usually more compact to just type it out than to describe it in natural language.
It really depends - a recent example I had was trying to implement the DPMO paper (a signed distance field to mesh algorithm), and one of the steps is "compute the plane of best fit with these points and project this other point onto it." Not a particularly long piece of code, but long enough that my local DeepSeek model was able to meaningfully save time for me.
