I think this is a lot of "kicking can down the road" of not understanding what code the ai is writing. Once you give up understanding the code that is written there is no going back. You can add all the helper commit messages, architecture designs, plans, but then you introduce the problem of having to read all of those once you run into an issue. We've left readability on the wayside to the alter of "writeability".…
If AI writes code, should the session be part of the commit?
401–410 of 410 posts
Re: If AI writes code, should the session be part of the commit?
#402Earlier quoted context omitted.
Might not be worth it now, but might be in future. Not just for future LLMs, but future AI architectures. I don't think the current transformers architecture is the final stop in the architectural breakthroughs we need for "AGI" that mimics human thought process. We've gone through RNN, LSTM, Mamba, Transformers, with an exponentially increasing amounts of data over the years. If we want to use similar "copy human se…
I just don't really see the point in hedging like that tbh. I think you could justify almost anything on "it could be useful", but why pay the cost now? Eh.
Re: If AI writes code, should the session be part of the commit?
#403This is the breakdown of my process - I use tons of .md files serving as a shared brain between Claude and me:
- CLAUDE.md is in the root of the repo, and it's the foundation - it describes the project vision, structure, features, architecture decisions, tech, and others. It then goes even more granular and talks about file sizes, method sizes, problem-solving methodologies (do not reinvent the wheel if a well-known library is already out there), coding practices, constraints, and other aspects like instructions for integration tests. It's basically the manual for the project vision and plan, and also for code writing. Claude reads it every session.
- Every feature has its own .md file, which is maintained. That file describes implementation details, decisions, challenges, and anything that is relevant when starting to code on the feature, and also when it's picked up by a new session.
- At a higher level, above features, I create pairs of roadmap.md and handoff.md. Those pairs are the crucial part of my process. They cover wider modules (e.g., licensing + payments + emailing features) and serve as a bridge between sessions. Roadmap.md is basically a huge checklist, based on CLAUDE.md and features .md docs, and is maintained. The handoff.md contains the current state, session notes, and knowledge. A session would start by getting up to speed with Claude.md and the specific roadmap.md + handoff.md that you plan to work on now and would end by updating the handoff, roadmap, and the impacted features.
This structure greatly helps preserve crucial context and also makes it very easy to use multi-agent.
Of course the commits and PRs are also very descriptive, however the engine is in the .md files.
Re: If AI writes code, should the session be part of the commit?
#404Re: If AI writes code, should the session be part of the commit?
#405Earlier quoted context omitted.
Except it doesn't capture the majority of uses of AI, in my experience. In my current practice, the the vast majority of AI use is autocompletions, or small inline prompts. ("Fix this error."; "Open an ALSA midi connection" (things that avoid a to trip into awful documentation); "if (one of the query parameters is "gear='ir') ..." (things that break flow by forcing a trip into excellent but overly verbose Javascript…
What coding agent are you using at your workplace?
Re: If AI writes code, should the session be part of the commit?
#406Re: If AI writes code, should the session be part of the commit?
#407I’ve had the same thought, but after playing around with it, it just seems like adding noise. I never find myself looking at generated code and wondering “what prompt lead to that?” There’s no point, I won’t get any kind of useful response - I’m better off talking to the developer who committed it, that’s how code review works.
The developer that committed won’t know because they didn’t write it… You can avoid the noise with git notes. Add the session as a note on the commit. No one has to read them if they’re not interested.
But they did commit it. I don’t really care who wrote it, if your account is on the commit, then you’re on the hook for the contents. If you can’t explain your own work, then I’m not really interested in collaborating with you.
Re: If AI writes code, should the session be part of the commit?
#408The idea of "saving prompts for reproducibility" is dead on arrival. LLMs are non-deterministic by nature. In a year, they'll deprecate this model's API, and the new version will spit out completely different code with entirely new bugs for the exact same prompt. A prompt isn't source code, it's just a temporary crutch for stochastic generation. And if I have to read 50 pages of schizophrenic dialogue with an LLM jus…
This is something that should be possible in principle, since the machines underneath are deterministic, it’s just a limitation of the implementation.
Re: If AI writes code, should the session be part of the commit?
#409I think this is a lot of "kicking can down the road" of not understanding what code the ai is writing. Once you give up understanding the code that is written there is no going back. You can add all the helper commit messages, architecture designs, plans, but then you introduce the problem of having to read all of those once you run into an issue. We've left readability on the wayside to the alter of "writeability".…
Did you review all the code-gen code that might have been created in your projects pre-AI? Scaffolding, boilerplate, extended autocomplete, etc?
Re: If AI writes code, should the session be part of the commit?
#410Earlier quoted context omitted.
There is no "why." It will give reasons but they are bullshit too. Even with the prompt you may not get it to produce the bug more than once. If you sell a coding agent, it makes sense to capture all that stuff because you have (hopefully) test harnesses where you can statistically tease out what prompt changes caused bugs. Most projects wont have those and anyway you don't control the whole context if you are using…
If I have a session history or histories, I can (and have!) mine them to pinpoint where an agent either did not implement what it was supposed to, or understand who asked for a certain feature an why, etc. It complements commits, sessions are more like a court transcript of what was said / claimed (session) and then you can compare that to what was actually done (commits).