Remix.run Logo
Animats 18 hours ago

Including the AI, which generated it once and forgot.

This is going to be a big problem. How do people using Claude-like code generation systems do this? What artifacts other than the generated code are left behind for reuse when modifications are needed? Comments in the code? The entire history of the inputs and outputs to the LLM? Is there any record of the design?

maxbond 17 hours ago | parent | next [-]

I have experimented with telling Claude Code to keep a historical record of the work it is performing. It did work (though I didn't assess the accuracy of the record) but I decided it was a waste of tokens and now direct it to analyze the history in ~/.claude when necessary. The real problem I was solving was making sure it didn't leave work unfinished between autocompacts (eg crucial parts of the work weren't performed and instead there are only TODO comments). But I ended up solving that with better instructions about how to break down the plan into bite-sized units that are more friendly to the todo list tool.

I have prompting in AGENTS.md that instructs the agent to update the relevant parts of the project documentation for a given change. The project has a spec, and as features get added or reworked the spec gets updated. If you commit after each session then the git history of the spec captures how the design evolves. I do read the spec, and the errors I've seen so far are pretty minor.

skeptic_ai 17 hours ago | parent | prev | next [-]

I for one I save all conversations in the codebase. Includes both human prompts and outputs. But I’m using a modified codex to do so. Not sure why it’s not default as it’s useful to have this info.

luckydata 17 hours ago | parent | prev [-]

Is this an actual problem? Takes minutes for an AI to explore and document a codebase. Sounds like a non problem.

shevy-java 16 hours ago | parent | next [-]

Is that documentation useful? I haven't seen a well-documented codebase by AI so far.

To be fair - humans also fail at that. Just look at the GTK documentation as an example. When you point that out, ebassi may ignore you because criticism is unwanted; and the documentation will never improve, meaning they don't want new developers.

ahnick 16 hours ago | parent | prev [-]

Yes, exactly my point as well. It cuts both ways.