Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

241–250 of 410 posts

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

#241

Post by jumploops »

zknill wrote: post #234
jedberg wrote: post #219

Earlier quoted context omitted.

> At this point, I either jump back to new design/plan files, or dive into the debug flow. Similar to the plan prompting, debug is instructed to review the current implementation, and outline N-M hypotheses for what could be wrong. I'm biased because my company makes a durable execution library, but I'm super excited about the debug workflow we recently enabled when we launched both a skill and MCP server. You can us…

Why an MCP? dbos already ships a cli that appears to have the same features. Why an MCP over a skill that gives context on using the cli? https://docs.dbos.dev/python/reference/cli

> we launched both a skill and MCP server.

My guess is that the MCP was easy enough to add, and some tools only support MCP.

Personal opinion: MCP is just codified context pollution.

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

#242

Post by malloryerik »

frank00001 wrote: post #185
jedberg wrote: post #173

The way I write code with AI is that I start with a project.md file, where I describe what I want done. I then ask it to make a plan.md file from that project.md to describe the changes it will make (or what it will create if Greenfield). I then iterate on that plan.md with the AI until it's what I want. I then ask it to make a detailed todo list from the plan.md and attach it to the end of plan.md. Once I'm fully sa…

Sounds like the spec driven approach. You should take a look at this https://github.com/github/spec-kit

Have you tried this? Review?

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

#243

Post by staticassertion »

arppacket wrote: post #169
827a wrote: post #94

IMO: This might be a contrarian opinion, but I don't think so. Its much the same problem as asking, for example, if every single line you write, or every function, becomes a commit. The answer to this granularity is, much like anything, you have to think of the audience: Who is served by persisting these sessions? I would suspect that there is little reason why future engineers, or future LLMs, would need access to t…

While it's noisy and complicated for humans to read through, this session info is primarily for future AI to read and use as additional input for their tasks. We could have LLMs ingest all these historical sessions, and use them as context for the current session. Basically treat the current session as an extension of a much, much longer previous session. Plus, future models might be able to "understand" the limitati…

TBH I don't think it's worth the context space to do this. I'm skeptical that this would have any meaningful benefits vs just investing in targeted docs, skills, etc.

I already keep a "benchmarks.md" file to track commits and benchmark results + what did/ did not work. I think that's far more concise and helpful than the massive context that was used to get there. And it's useful for a human to read, which I think is good. I prefer things remain maximally beneficial to both humans and AI - disconnects seem to be problematic.

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

#244

Post by whywhywhywhy »

insin wrote: post #199
solarkraft wrote: post #134

Earlier quoted context omitted.

I agree that probably not everything should be stored - it’s too noisy. But the reason the session is so interesting is precisely the later part of the conversation - all the corrections in the details, where the actual , more precise requirements crystallize.

AKA the code. You're all talking about the code.

People are trying to retain value as their value is being evaporated.

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

#245

Post by miki123211 »

jumploops wrote: post #205
jedberg wrote: post #173

The way I write code with AI is that I start with a project.md file, where I describe what I want done. I then ask it to make a plan.md file from that project.md to describe the changes it will make (or what it will create if Greenfield). I then iterate on that plan.md with the AI until it's what I want. I then ask it to make a detailed todo list from the plan.md and attach it to the end of plan.md. Once I'm fully sa…

I do something similar, but across three doc types: design, plan, and debug Design works similar to your project.md file, but on a per feature request. I also explicitly ask it to outline open questions/unknowns. Once the design doc (i.e. design/[feature].md) has been sufficiently iterated on, we move to the plan doc(s). The plan docs are structured like `plan/[feature]/phase-N-[description].md` From here, the agent…

My "heavy" workflow for large changes is basically as follows:

0. create a .gitignored directory where agents can keep docs. Every project deserves one of these, not just for LLMs, but also for logs, random JSON responses you captured to a file etc.

1. Ask the agent to create a file for the change, rephrase the prompt in its own words. My prompts are super sloppy, full of typos, with 0 emphasis put on good grammar, so it's a good first step to make sure the agent understands what I want it to do. It also helps preserve the prompt across sessions.

2. Ask the agent to do research on the relevant subsystems and dump it to the change doc. This is to confirm that the agent correctly understands what the code is doing and isn't missing any assumptions. If something goes wrong here, it's a good opportunity to refactor or add comments to make future mistakes less likely.

3. Spec out behavior (UI, CLI etc). The agent is allowed to ask for decisions here.

4. Given the functional spec, figure out the technical architecture, same workflow as above.

5. High-level plan.

6. Detailed plan for the first incomplete high-level step.

7. Implement, manually review code until satisfied.

8. Go to 6.

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

#246

Post by claud_ia »

The raw session noise — repeated clarifications, trial-and-error prompting, hallucinated APIs — probably isn't worth preserving. But AI sessions contain one category of signal that almost never makes it into code or commit messages: the counterfactual space — what approaches were tried and rejected, which constraints emerged mid-session, why the chosen implementation looks the way it does.

That's what architectural decision records (ADRs) are designed to capture, and it's where the workflow naturally lands. Not committing the full transcript, but having the agent synthesize a brief ADR at the close of each session: here's what was attempted, what was discarded and why, what the resulting code assumes. Future maintainers — human or AI — need exactly that, and it's compact enough that git handles it fine.

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

#247

Post by handfuloflight »

lionkor wrote: post #196

Sone of the best engineers I've seen use commit messages to explain their intent, sometimes even in many sentences, below the message. I bet, without trying to be snarky, that most AI users don't even know you can commit with an editor instead of -m "message" and write more detail. It's good that AI fans are finding out that commits are important, now don't reinvent the wheel and just spend a couple minutes writing e…

This gave me a good chuckle. Anyone doing "good" engineering with coding agents are having them write detailed, high signal, low noise git commits... it's table stakes.

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

#249

Post by PeterStuer »

The session might contain many artifacts that are not suited for open sourcing. The additional fine grained curation effort required might be more of an obstacle to open sourcing than the perceived benefits.

That said preserved private session records might be of great personal benefit.

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

#250

Post by ZoomZoomZoom »

If by AI you mean the LLM-based tools common now, then I don't want the commits in PRs I'm going to review to bring any more noise than they already do. The human operator is responsible for every line, like they always were.

If by AI you mean non-supervised, autonomous conscience (as I believe the term has to be reserved for), then the answer is again no, as it's as responsible for the quality of its PRs as humans.

If the thing writing code is the former, but there's no human or responsible representative of the latter in the loop, then the code shouldn't be even suggested for consideration in a project where any people do participate. In such case there's no point in storing any additional information as the code itself doesn't have any value (besides electricity wasted to create it) and can be substituted on demand.

Commit comments are generally underused, though, as a result of how forges work, but that's another discussion.

Post reply on HN