Thread

1. aDyslecticCrow · 1790112556 · focus · HN ↗

   You've seen test-rot, specification rot, and documentation rot; we now introduce; prompt rot!

   Cluttering the repo with out-dated, very wordy and quickly aging prompts will just confuse any agent tasked with looking at the repo in the future. Keeping context windows down is a real limitation to good LLM output, and this workflow may work completely against it.

   - A plan.md describing the project, main abstraction idea, end costumer, and so on is great; but it should be kept minimal and up-to-date with the repo.

   - Block comments on top of source-files and functions are great, and already very useful to coding agents. I don't see a value to anything more than what is already typical best practice.

   1. xg15 · 1790113555 · focus · HN ↗

      I wonder if instead of checking the prompts into the repo as files, a better idea would be to store them inside the commit messages.

      If prompts are specifications for a change of the system's behavior, then it seems natural to manage them as changes and not as resources.

      This would also keep them in the right "historical context" of the repo and avoid the "prompt rot" you were talking about.

      1. aDyslecticCrow · 1790114414 · focus · HN ↗

         Git history is a bit annoying to navigate, but that may just be a tooling issue. I've long been bothered by the loss of the review history when merging a PR. Would actually be pretty cool to click on a row of code and see the commit messages that formed that row of code in a little sidebar, and the technical discussions that were behind it.

         Functional safety development processes often demand code-review, technical design decisions, changes of plans, or intentional compromises; to be linked together with reference IDs in the code they effect. But the workflow for this is usually extremely manual and absolute misery. But a codebase made like this is like magic to read later.

         1. chapterjason · 1790149875 · focus · HN ↗

            You literally described git blame usage in almost every editor which supports git properly.

            1. mschuster91 · 1790157614 · focus · HN ↗

               git blame falls apart on someone running a new linter config across the project or doing some refactoring work.

               1. bulatb · 1790173483 · focus · HN ↗

                  Some tools will automatically ignore commits in a .git-blame-ignore-revs file. Git itself can "blame --ignore-rev <hash>" or "blame --ignore-revs-file <file>" since version 2.23.

                    git commit -m "Autoformat source files"
                    git log --format="# %s%n%H" -1 >> .git-blame-ignore-revs
                    git add .git-blame-ignore-revs
                    git commit -m "Ignore autoformat commit in blames"
                  
                    cat .git-blame-ignore-revs
                    # Autoformat source files
                    0a1b2c3d...
                  
                    git blame --ignore-revs-file .git-blame-ignore-revs code.src
                  

                  Git can use it automatically too:

                    git config blame.ignoreRevsFile .git-blame-ignore-revs
                    git blame code.src
                  

                  Though git-blame may fail or crash if blame.ignoreRevsFile is set but the file is missing (hence "config", not "config --global"). Since version 2.53, a configured ignoreRevsFile can be missing if the value starts with ":(optional)".

Unofficial Hacker News client; not affiliated with Y Combinator.