What we lost the last time code got cheap
121–126 of 126 posts
Re: What we lost the last time code got cheap
#122Earlier quoted context omitted.
I asked Claude to tell me why something was implemented the way it was, and got an excellent response. One data point, would love to hear more examples.
I agree, Claude has been pretty great at explaining code. It even does well at explaining to me old code that I wrote by hand — including both non-intuitive quirks and flaws. Claude in its default configuration has untapped potential for explaining and documenting code because it defaults to writing no comments. I added this to my global CLAUDE.md and so far so good: # Comments Keep existing comments unless they're w…
Re: What we lost the last time code got cheap
#123Earlier quoted context omitted.
Do you disagree with the point made?
Forming a human opinion about slop is like asymmetrical warfare. Or maybe a closer analogy is a Gish Gallop. It can be generated with way less effort than it takes to comprehend it, much less form a coherent opinion on it.
Re: What we lost the last time code got cheap
#124Earlier quoted context omitted.
> then what can we expect from AI steered by the sort of humans that produced poor quality code. Great point, and I think that's my argument: above-average engineers can now produce more above average code. We don't need as many (any?) below-average developers moving forward.
It's possible, but I think unlikely. For one thing, most managers can't really tell who is above or below average. We still in 2026 have "lines of code" as a usual metric for judging the quality of a dev. So how do you think that will play out in reality?
Re: What we lost the last time code got cheap
#125Often is not goo enough. I always carefully review AI generated code and sometimes find and fix bugs.
Apparently (according to a Google survey I think?) AI's produce 1.7 times the number of bugs that a human typically does.
Re: What we lost the last time code got cheap
#126Earlier quoted context omitted.
> a lot of _human_ written code was/is less-than-fine. At least at my work place this is often the case whenever we bring in contractors who will never be tasked with maintaining their code. Middle management rarely ever gives us the time to fix this broken mess, and when they do, it's actually in a neat maintainable state. We recently took 700mb of compiled code and reduced it to under 40mb just by getting rid of us…
If you're at a stage where code doesn't compile and doesn't do what you want, then that's really easy to improve. - let the llm (agent) compile the code and iterate until it does. - state your intent more clearly.