101–110 of 123 posts
Earlier quoted context omitted.
There's nothing specific to AI about this. Humans make the same mistake. To solve this permanently, use a linter and apply a "ratchet" in CI so that the LLM cannot use ignore comments
Is there a Python linter that does this?
Earlier quoted context omitted.
Amateurs are the one who argue about syntax. Code quality is about how well a piece of code expresses what it intends to do. It’s like quality writing.
You start to care about standard syntactic rules and enforced naming conventions when you're the one waking up 4 in the morning on a Saturday to an urgent production issue and you need to fix someone else's code that's written in a completely incoherent style. It "expresses what it intends to do" prefectly well - for the original author. Nobody else can decipher it without spending significant amounts of memory cycle…
It's basically like hiring a new developer for one task and letting them go right after. They don't know your conventions, your history, or why things are the way they are. The only thing they have is what they can see in the code. Your code quality is basically the prompt now.
AI feels less like an autonomous programmer and more like a very capable junior engineer. The useful part is not just asking it to write code, but giving it context: how the codebase got here, what constraints are intentional, where the sharp edges are, and what direction we want to take. With that guidance, it can be excellent. Without it, it tends to produce changes that make sense in isolation but not in the syste…
Fuck off bot
What changed for me isn’t that AI writes bad code by default, but that it lowers the friction to adding code faster than the team can properly absorb it. The dangerous part is not obvious bugs, it’s subtle erosion of consistency.
Well said. I have to review PRs of non-software developers nowadays. The “what is this trying to do?” has never been harder to answer than before. It creates scenarios where 99% is correct, but the most important area is subtly broken. I prefer it to be human, where 60-80% will be correct, and the problematic areas begin to smell more and more gradually. In my experience LLMs, at times, may hide the truth from you in…
Harder to catch because nothing is factually wrong. You have to ask: could this output have been produced without actually reading my codebase?
Code cannot and should not be self documenting at scale. You cannot document "the why" with code. In my experience, that is only ever used as an excuse not to write actual documentation or use comments thoughtfully in the codebase by lazy developers.
this always starts out right but over the years the code changes and its documentation seldom does, even on the best of teams. the amount of code documentation that I have seen that is just plain wrong (it was right at some point) far outnumbers the amount of code documentation that was actually in-sync with the code. 30 years in the industry so large sample size. now I prefer no code documentation in general
Earlier quoted context omitted.
I don't think it will go away, I think there will remain a niche for code where we care about precision. Maybe that niche will get smaller over time, but I think it will be a hold out for quite a while. A loose analogy I've found myself using of late is comparing it to bespoke vs off the shelf suits. For instance, two things I'm currently working on: - A reasonably complicated indie game project I've been doing solo…
I write systems rust on the cutting edge all day. My work is building instant MicroVM sandboxes. I was shocked recently when it helped me diagnose a musl compile issue, fork a sys package, and rebuild large parts of it in 2 hours. Would've taken me atleast 2 weeks to do it without AI. Don't want to reveal the specific task, but it was a far out of training data problem and it was able to help me take what would've no…
This could have been html instead of whatever awful moving pattern it is.
Earlier quoted context omitted.
"Style" is such a small part about what people generally care about when they talk about code quality though, useful/intuitive abstractions, the general design and more tends to be a lot more important and core to the whole code quality debate.
Linters can be set check for cyclomatic complexity, using old/inefficient styles of programming (go fix ftw) etc. Formatting is just an easy and clear example that everyone should understand.
Earlier quoted context omitted.
Code quality can also be codified. If you can't express "code quality" deterministically, then it's all just feels. And if you can define "quality" in a way the agent can check against it, it will follow the instructions.
> then it's all just feels Would that be so bad? "Readability" sure is subjective, so it seems "code quality" is. Ask 10 programmers what quality a snippet of code is, and you'll get 10 different answers.
My team will send me random snippets from OSS libraries and we all go WTF what is that, and my team will also send really clever lines and we'll go wow.
"Good code" is subjective, but good engineers have good taste, and taste is real.