71–80 of 123 posts
The velocity problem is real. AI makes it easy to add things faster than you can understand what you added. The intentionality has to come before you prompt, not after you review.
You can ask the agent to make 10 different solutions in the time it takes you to make 0.5.
Then you review them based on whatever criteria you feel is right and either throw them all away and do it yourself (maybe with inspiration from the other solutions) or pick one to progress further.
Earlier quoted context omitted.
I don't think testing the product alone is good enough, because when you give it tests it has to pass it prioritizes passing them at the expense of everything else — including code quality. I've seen it pull in random variables, break semantic functions, etc.
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.
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.
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.
All that time it's people arguing with people and wasting time on pure feels. People will get offended and angry and defensive, nothing good ever comes from it.
But when you pick a style and enforce it with a tool like gofmt or black both locally and in the CI, the arguments go away. That's the style all code merged to the codebase must look like and you will deal with it like a professional.
Go proverb: "Gofmt's style is no one's favorite, yet gofmt is everyone's favorite."
Earlier quoted context omitted.
> 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.
And there is the problem. Then you start arguing about brace positions and function names and whether simple data classes should have docstrings on properties or not. All that time it's people arguing with people and wasting time on pure feels. People will get offended and angry and defensive, nothing good ever comes from it. But when you pick a style and enforce it with a tool like gofmt or black both locally and in…
Earlier quoted context omitted.
Are there any good systems that somehow enforce consistency between documentation and code? Maybe the problem is fundamentally ill-posed.
Simon Willison had this idea of "Documentation unit tests" in 2018: https://simonwillison.net/2018/Jul/28/documentation-unit-tes... It's not a massively complex AI monstrosity (it's from 2018 after all) or a perfect solution, but it's a good jumping off point. With a slight sprinkling of LLM this could be improved quite a bit. Not by having the agent write the documentation necessarily, but for checking the parity an…
It allows you to write simple unit tests directly in your doc strings, by essentially copying the repl output so it doubles as an example.
combined with something like sphinx that is almost exactly what you’re looking for.
doctest kind of sucks for anything where you need to set up state, but if you’re writing functional code it is often a quick and easy way to document and test your code/documentation at the same time.
Earlier quoted context omitted.
> 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.
And there is the problem. Then you start arguing about brace positions and function names and whether simple data classes should have docstrings on properties or not. All that time it's people arguing with people and wasting time on pure feels. People will get offended and angry and defensive, nothing good ever comes from it. But when you pick a style and enforce it with a tool like gofmt or black both locally and in…
Code quality is about how well a piece of code expresses what it intends to do. It’s like quality writing.
Holy fuck Batman
Earlier quoted context omitted.
And there is the problem. Then you start arguing about brace positions and function names and whether simple data classes should have docstrings on properties or not. All that time it's people arguing with people and wasting time on pure feels. People will get offended and angry and defensive, nothing good ever comes from it. But when you pick a style and enforce it with a tool like gofmt or black both locally and in…
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.
I’m generally of the opinion that LLM-supplied code is “prolix,” but works well. I don’t intend to be personally maintaining the code, and plan to have an LLM do that, so I ask the LLM to document the code, with the constraint being, that an LLM will be reading the code.
It tends to write somewhat wordy documentation, but quite human-understandable.
In fact, it does such a good job, that I plan on having an LLM rewrite a lot of my docs (and I have a lot of code documentation. My cloc says that it’s about 50/50, between code and documentation).
Personally, I wish Apple would turn an LLM loose on the header docs for their SwiftUI codebase. It would drastically improve their docs (which are clearly DocC).
[EDITED TO ADD] By the way, it warms my heart to see actual discussion threads on code Quality, on HN.
The velocity problem is real. AI makes it easy to add things faster than you can understand what you added. The intentionality has to come before you prompt, not after you review.
Why? You can ask the agent to make 10 different solutions in the time it takes you to make 0.5. Then you review them based on whatever criteria you feel is right and either throw them all away and do it yourself (maybe with inspiration from the other solutions) or pick one to progress further.