5 ms·

My feeling that as it becomes a better coder it becomes a worse communicater. It's overfitting for coding benchmarks, while communication style is harder to qua

My feeling that as it becomes a better coder it becomes a worse communicater. It's overfitting for coding benchmarks, while communication style is harder to quantify during training. And no matter how often I tell it to stop adding comments it just can't help itself.

iFire 1mo ago
My prompt of asking it match the comment density of the last release of an exemplar project (Let's say sqlite) seems to work.
- swe_dima 1mo ago
  my prompt (doesn't help): > Go easy on the comments, only add comments if there's a big gotcha that is not clear from the code itself, or if something in another place is going to cause a side effect. Code should be self-documenting. When in doubt, don't add a comment at all. If you do have to add a comment, make it short and on point. Comments should show history of code changes or functionality, only comment on the current state (or not at all).
  - deleted 1mo ago
    [deleted]
  - iFire 1mo ago
    Your prompt is so similar to my prompt. > Go easy on the comments. > If you do have to add a comment, make it short and on point. I defined what easy meant numerically. <claude> Match the comment density of FoundationDB, which is 12 to 14 percent of non-blank lines in `fdbserver`, `fdbclient` and `flow` at 7.3. </claude> > only add comments if there's a big gotcha that is not clear from the code itself <claude> Comment why the code does a thing, not what it does. </claude> > Comments should show history of code changes or functionality, only comment on the current state (or not at all) I call this the tenseless continuous-present voice. <claude> Each sentence states what is currently true of the system. </claude> <claude> This rules out past-tense edit narration, future or imperative planning, and aging temporal qualifiers such as “now” or “previously”. </claude> <claude> A sentence that states a present truth stays correct as long as the code stays the same, and goes stale visibly the moment the code changes. </claude>

iFire 1mo ago

My prompt of asking it match the comment density of the last release of an exemplar project (Let's say sqlite) seems to work.

swe_dima 1mo ago
my prompt (doesn't help): > Go easy on the comments, only add comments if there's a big gotcha that is not clear from the code itself, or if something in another place is going to cause a side effect. Code should be self-documenting. When in doubt, don't add a comment at all. If you do have to add a comment, make it short and on point. Comments should show history of code changes or functionality, only comment on the current state (or not at all).
- deleted 1mo ago
  [deleted]
- iFire 1mo ago
  Your prompt is so similar to my prompt. > Go easy on the comments. > If you do have to add a comment, make it short and on point. I defined what easy meant numerically. <claude> Match the comment density of FoundationDB, which is 12 to 14 percent of non-blank lines in `fdbserver`, `fdbclient` and `flow` at 7.3. </claude> > only add comments if there's a big gotcha that is not clear from the code itself <claude> Comment why the code does a thing, not what it does. </claude> > Comments should show history of code changes or functionality, only comment on the current state (or not at all) I call this the tenseless continuous-present voice. <claude> Each sentence states what is currently true of the system. </claude> <claude> This rules out past-tense edit narration, future or imperative planning, and aging temporal qualifiers such as “now” or “previously”. </claude> <claude> A sentence that states a present truth stays correct as long as the code stays the same, and goes stale visibly the moment the code changes. </claude>