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.
Mine doesn't. It mostly adds and keeps referencing previous decisions. Correctly, referring to them as being overridden. Even tweaking the original text or occasionally deleting a part. But text would look differently had it been written from scratch.
Unless a LLM works truly as a compiler, there will be a drift between the code and the spec.
aDyslecticCrow · · focus · HN ↗
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.
jve · · focus · HN ↗
krab · · focus · HN ↗
Unless a LLM works truly as a compiler, there will be a drift between the code and the spec.