4 ms·
I think this is a rather pertinent showcase of the danger of outsourcing your thinking to LLMs. This article strongly indicates to me that it is LLM-written, an
by applfanboysbgon 8mo ago
I think this is a rather pertinent showcase of the danger of outsourcing your thinking to LLMs. This article strongly indicates to me that it is LLM-written, and it's likely the LLM diagnosed the issue as being a C# issue. When you don't understand the systems you're building with, all you can do is take the plausible-sounding generated text about what went wrong for granted, and then I suppose regurgitate it on your LLM-generated portfolio website in an ostensible show of your profound architectural knowledge.
- cosmez 8mo agoThis is a common issue, and most developers I worked with are not aware of it until they see the performance issues. Most people are not aware of how Dapper maps types under the hood; once you know, you start being careful about it. Nothing to do with LLMs, just plain old learning through mistakes.
- keithnz 8mo agoactually, LLMs do way better, with dapper the LLM generates code to specify types for strings
- ziml77 8mo agoThis is not at all just an LLM thing. I've been working with C# and MS SQL Server for many years and never even considered this could be happening when I use Dapper. There's likely code I have deployed running suboptimally because of this. And it's not like I don't care about performance. If I see a small query taking more than a fraction of a second when testing in SSMS or If I see a larger query taking more than a few seconds I will dig into the query plan and try to make changes to improve it. For code that I took from testing in SSMS and moved into a Dapper query, I wouldn't have noticed performance issues from that move if the slowdown was never particularly large.