If it's part of the rebase. If commit 3 in the chain doesn't compile and half the tests fail, that's not very useful for someone trying to figure out how an ancient bug nobody noticed for a year got into the code. If commit 4 fixes it, then 3+4 -> 3.

But if you add a function in commit 2, then realize three hours later than you just need to call another function, I don't need to see the function arrive, get used, half the tests written, the whole thing be deleted, and then a couple commits that do it the easy way and only needs 3 tests added.

That fakeout will be in the code tree forever and each new dev who is trying to grok the code will see that the line of whitespace on line 35 came along with a function that doesn't exist anymore and only really ever did on David's machine.

A more charitable case is that the source cannot be disclosed because it's an undercover agent or informant. What the parent describes is indeed evidence laundering.

Audit purposes for sure. How was this code/concept generated, what were the prompts/requirements, what thinking did the model complete, can this be replicated or repeated, etc.

A vendor conference I was at a few weeks ago focused heavily on this, for most of their Agentic workflow items. How can you show the AIs work, prove what it did was within guidelines, then audit the process and result.

Like, if your system has an AI backed federated search for documents and you ask it a question about those documents, you need an audit trail of the ask, what documents were referenced, and what was returned to the user.

Then if wrong information was supplied that can be pinned down and explained in case of lawsuit or other need.

FYI your link 404s.

Seems like you copied the ellipsified version, so what we get is https://github.com/gitsense/gsc-cli/blob/main/internal/cli/r

Yeah I really would not want all my convos synced up like this. I've been working on a personal version of something like this but it keeps all your conversations and notes in a separate Git repo that you control that's totally separate from the project repo - it's entirely designed for personal use:

https://github.com/modulecollective/moe

I would probably only use these data if I had some script I could run in it for analysis, and even then optimizing my AI chats is probably pretty low value.. certainly not enough to justify the cost of analysis, unless there's something that provides actionable insights with almost zero time investment.

Producing code edits itself is such a small fraction of the job I'm really not convinced these are valuable data. Mostly the effort and time goes into reading and understanding code, not producing or transforming it.

No, you are paid to provide solutions for your customers.

Does that... Not imply thinking avout what you are writing???

and you can do that without thinking?

Disagree. This how people best learn from each other. It's also nice to audit your own thought process objectively.

It makes one vulnerable though, that's for sure. Psychologically I mean.

Ugh, let's take a step back and make a distinction:

I don't need your fluff. No one cares how you arrived writing another crud line to save an object to database or sent yet another AJAX call.

If you wrote some genuine great compression algorithm that's a different take on compression, I would like to see step by step reasoning and eventual dead ends.

I personally stumble upon many topics where I only care about the what. In that case all the theory is just a distraction I'm just wading through to get to the point. If it's optional, then looking into the how and why is certainly nice, but it should be part of an appendix or a commentary and not interspersed within the proof unless an uncommented version exists.

"So I was thinking about #####'s Law this morning, and I realized that #######'s Theorem might apply if we do this and ignore that. Then I went up a blind alley and stopped for coffee and realized I was overcomplicating it, we don't care about negative or imaginary solutions."

They don't need to know I was brushing my teeth and thinking of bacon and an argument I had with my spouse right before I thought that though. Or how rude the customer in front of me was to the new barista who was just trying her best.

OTOH polishing up the presentation can really improve the experience of a first-time reader of the work (e.g. your code reviewers). If the polishing is done with good intent and proficiency you can make something that was very convoluted and difficult to arrive at digestible with far less effort. It also aids your own understanding: "If we can reduce it to the freshman level that means we really understand it" (or similar I didn't look up the exact quote, attributed to Feynman). If you're polishing something up to make it understandable that's totally different than polishing it up to make yourself seem smart, right?