Live data from Hacker News

If AI writes code, should the session be part of the commit?

github.com

401–410 of 410 posts

Re: If AI writes code, should the session be part of the commit?

#401

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".…

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?

#402

Earlier 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.

Optimizing and over-engineering to soon has gone out the window

Re: If AI writes code, should the session be part of the commit?

#403
In the past months, I've been building a SaaS using Claude Code. I haven't written a single line of code.

This 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?

#405

Earlier 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?

Claude Sonnet 4.6. With some brief experimentation with Gemini 3 Pro and GPT 5.3 Codex (both of which seem excellent so far). Perversely, I'm more comfortable at the moment with Claude Sonnet 4.6, just because I have a ballpark sense of how far it can be pushed before it loses it, and haven't yet developed the corresponding bat-sense for Gemini 3 Pro and GPT 5.3 Codex.

Re: If AI writes code, should the session be part of the commit?

#406

Earlier quoted context omitted.

yeah lets commit all your thoughts too, and your personal journal. please also include a picture of your children and wife in the commit

This is an extremely ugly response and you should feel shame.

your response brings me great pride

Re: If AI writes code, should the session be part of the commit?

#407
post #75

I’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.

> The developer that committed won’t know because they didn’t write it…

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?

#408
post #273

The 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.

"In principle" - sure, but in practice, even if you pin the seed, your float32 calculations are going to drift due to non-deterministic CUDA kernels during parallel execution. You'll never get bit-for-bit identical tensors across different GPUs or even different driver versions, it's a fundamental property of parallel computing

Re: If AI writes code, should the session be part of the commit?

#409

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".…

Did you review all the code-gen code that might have been created in your projects pre-AI? Scaffolding, boilerplate, extended autocomplete, etc?

No, but that's not a fair comparison. LLM's are inherently non-deterministic. Boilerplate generation is.

Re: If AI writes code, should the session be part of the commit?

#410

Earlier 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).

Some of my sessions are over 1GB at this point. I just don't think this scales usefully or meaningfully. Those things should live as summarized artifacts within issue tracking IMHO
Post reply on HN