i misunderstood "wall of text" (i was thinking about bloating repo with it), my solution to understanding is just to create ad-hoc tools to parse the json
i coded a web ui with simple toggles: show me what user said, what llm said (nice to see what I was thinking about, nice to see how LLM came up with solution X, you get tools calls, maybe it found something i didn't think about or viceversa)
you can search/grep (.ie: did i consider idempotency when i build feature X? open session, search/grep idempotency)
you can, up to some point, resume the conversation (yes i know, cache busting makes some usages of this impractical, but in general resuming and asking "when we did this, did we think about that" tends to work... let's say that research is ok, time travel, meh)
overall, one of the advantages of LLMs is to be able to direct then ad data for insights, via standard CLI tools, via specific prompts, or building some mini tools (yeah vibe coding is fine sometimes)
whatever my question, if i have data i can have an answer
LFS helps with the second aspect (buried bullshit). Unless you smudge, you have a pointer, and that is just 3 lines.
You need to learn some ergonomics, but ok, some of us learnt how to use Jira XD
Taking your position a bit further, yes, committing chat sessions implies that you also need to review them so that bullshit doesn't filter through. Milage varies based on your personal preferences, which project you are working on, and many more heuristics.
Some will find it boring, some will think it's good project maintenance, all should be able to find a way to handle this based on their preference.
It is also nice to pointout that cleaning bullshit doesn't need to happen at merge. LFS blobs being stored separately, you can have side flows helping you out, without clogging yoou CI pipelines.
"no dude"-> rules
you can put down SOME rules
usually this happens to me at PR. I am tired fo saying "you should always check X", so i bolt it down "someplace".
I am running the usual motions i suppose most of us try to adopt: put this down in agents.md, in folder x or y, in path-scoped rules using agents, in memory files (i am exporting/importing those too), in subagents that review code before PRs.
in the end it's an unsolved problem at large, but
1. hopefully it will get better, my feeling is that it's just a cambrian explosion, and the fittest will survive... (also, owning the harness should help, i suppose .. i use claude code :D )
2. in a team, having personal styles surface is valuable. "dude don't do that" is quite often .... design. When rules go in the repo, at least we can find an agreement in person, and at PR is not about linking a document you read at onboarding, but finding out why the agent did not respect the rule. To me, that is more grounded in a tool.
3. rules are ... not static? We change our minds? We get better at things? We want to experiment? I am not advocating for a perfect rule system that replaces me, but for a good enough one that removes cruft from my daily job.
I think my approach is actually helpful when it's time to find root causes (YMMV). Via tools that parse sessions, you can see when that specific portion of code has been written with a better granularity. During that bit of the conversation the user was worried about X and asked AI to do Z and AI read this and that file and "thought" this and that and wrote that piece of code.
Maybe the user was making wrong assumptions, maybe the LLM did not read the correct files or instructions, in any case you have a better tool for investigation.
It's up you to decide wether to use it, wether this lead to just solving the bug or also fixing instructions, etc, i am just saying that it actually helps to have some measure of the context on which this change made sense.
"Fluffy wall of text that looks good but is factually wrong. "
it might be good or bad, right or wrong, but what is in the sessions is the truth of what happened.
PR desc are horrible, i share that feeling with you, but having the story of how that thing happened is just not the same as "final summary of what we did in the past X hours".
As a sideline: LFS doesn't really pollute your repo once you get to learn its ergonomics. Having chats in LFS also lets you approach this
Reproducibility...
To me those conversation are basically the history for decisions taken while implementing. They are documentation.
The real problem with docs was that no-one has ever liked writing them, nor it was easy to implement a standardization around them.
If you just record/log, there';s no extra effort needed, and once there tools and LLMS are pretty good at helping us extract insights.
I am also assuming, there is a correlation between quality in the conversation and in the code. I know, i'm being hand-wavey, but overall i think critical thinking is what makes code better, and being able to see if/which it has been applied can be a good proxy.
I ask for forgivness already: I not going down the rabbit hole of quantifying quality etc. It's a broad statement that should be taken with a grain of salt.
If you want to go abstract, you can think of coding as going from thoughts to 0-1 in bits. We have high(er) level languages that help us organize thoughts to help us so that we can better keep them in our cognitive flow/load.
LLMs are an upper layer, that scrambles the code and make it more difficult to grasp.
But the reasoning behind the code is now available, and quite easy to parse.
I think this is the core point to me.
Code is an intermediate artifact between thinking and bits.
Now we have a second artifact: the conversation/decision that led to that code.
Why are we not storing it?
disclaimer:
I am, of course, mildly in love with my own project and ideas, so possibly i like this too much just because i built it. IKEA effect or whatever.
Haha, OK, we both tend to "text-wall" it seems, so seems we both shouldn't complain about LLMs. Or I guess: now we know how everyone always felt reading our stuff :P
no dude rules
Yes, I have these. That's how when I have it investigate, it outputs files and line numbers for example when the investigation is in our code base. But it still makes up stuff all the time. You need spidey senses that tingle and many people don't have them.
Just very recently, I saw a PR comment on why someone was choosing to do something in that particular way and what the other bad options would've been, i.e. justfying thei choice (at least they did do the "calling out" part. I had to comment about how none of that made any sense to me and why we didn't just do "other thing Y". Well turns out the AI had misled them, they believed it and it went downhill into a rabbit hole from there. I do believe that w/ the right spidey senses, even in an "unknown situation", it's entirely possible to come out the other end. But many if not most people succumb to the AI's nice and "sounds true" type language.
As a sideline: LFS doesn't really pollute your repo
LFS doesn't. Walls of text do, whether you use LFS or not. I.e.
no extra effort needed, and once there tools and LLMS are pretty good at helping us extract insights.
Nobody's really gonna read all that. The only way to get through it is to use LLMs, e.g. through summarization. That doesn't solve anything though. LLM summaries are very often wrong. Depends on the text/conversation and the LLM but have you tried slack summarizing a thread? Ouch! I've also tried Claude making tickets from slack threads. Ouch but less so. Still needs polishing. And more time polishing it than it would've required from myself to just type up the ticket myself. What LLMs are good at is if you put the actual "meat" down and they "fluff it up". But sorry, I'd rather juts have the meat and skip the fluff entirely.
Most LLM assisted bug reports on the other hand are huge walls of text with low signal to noise ratio. I.e. essentially the old
If I Had More Time, I Would Have Written a Shorter Letter
Famously the first known instance in the English language apparently was a sentence translated from a text written by the French mathematician and philosopher Blaise Pascal. The French statement appeared in a letter in a collection called "Lettres Provinciales" in the year 1657. It totally absolutely 150% applies to LLM use ;)
critical thinking is what makes code better,
Absolutely! And the issue with LLMs is that they tend to make it less likely for people to apply critical thinking. Even from people that (I at least thought) applied it in the past. "Does ChatGPT harm critical thinking abilities? A new study from researchers at MIT’s Media Lab has returned some concerning results." https://time.com/7295195/ai-chatgpt-google-learning-school/
Btw, I write all of this as someone that has been coding exclusively w/ the use of Claude Code and Codex for more than 6 months now. On purpose.
I like this chat, if you want we can continue this privately (username Gmail).
You are bringing up valid points, and we have scars from the same battles.
Given all this, what is bad about preserving the conversation that led to the code creation?
It might be wasteful, sure, if it never gets used.
It might be bad, if it’s misused.
But in the right hands (or with the right tools) it holds value.
Presently, we might not have them (agree to disagree to same degree), but given enough time will we not regret not having stored it, if better tools emerge?
There are many more angles.
.ie: you mention damage to critical thinking. And I agree about it.
Yet some conversations are better than others on this aspect.
The conversation doesn’t magically make you develop spidey senses, but if I had to learn a new project/skill, wouldn’t a selection of conversations + code be better training material than code alone?
I tried to stay light so some terms are overloaded and some concepts oversimplified.
Hehe, same, this is fun and enlightening, both because of my own reflections in order to reply to you and in seeing your take on things.
I don't mix identities tho, so HN it must stay.
what is bad about preserving the conversation that led to the code creation
The same thing that I'd find is bad about mixing online identities ;) It's surveillance. The kind that I don't like and will avoid whenever I can. So I can not in good conscience want to make everyone on the team put that in. It's like every single conversation ever being recorded for forever and ever. Youthful sins "staying in Vegas" is a blessing not a sin so to speak. Maybe I'm just too old, who knows.
Now, "point in time" learnings from conversations: Very valuable indeed! Whenever I talk to team members when I catch something that was potentially "just believing the AI", it usually was and yes it would really be valuable to see their actual interaction with the AI. Maybe they still have it around and we dig together. What I also do is to show them how I do prompts to get the results I do get. Sharing and learning, definitely.
But nobody needs to commit my literal "WTF DUDE!" to git ;) Yes, yes I do swear at it and if they ever take over, I'm dead, they're gonna come for me. It's a fun outlet actually. I do not have to "compose myself" and write a very nice message as I would with an actual intern. I can just outright tell it what kind of BS it concocted yet again.
I absolutely understand why you and also Anthropic et. al. would want my actual conversation data for learning and I hope they do honor their pledge to not do so on our corporate accounts. Statistical models live from data like this. I'm not gonna give it up just like that. I'm fine fine-tuning the machine to my likings, making local or company wide shared skills, absolutely.
Surveillance is everywhere you let it. I'm sure you seen Flock posts on HN. Now think "Gallup type thing is set loose on your actual AI conversations to figure out if you should be fired". You swear at AI, you must be part of the next layoff. WTF? Why? Like similarly, one of my besties at work, we always joked around in ways that if someone not familiar with us would overhear, they'd probably think we're fighting. We were having the fun of our lives. But nobody would. It was all in an office or at lunch and nobody would record us. But now translate that to in-writing, always recorded "little outlets". You'd have to self-censor.
That's neither fun nor healthy. It's like the Covid/Remote work vs. in-office difference if you ask me. For many many years, working in offices, I'd come home, after way too much commute both ways usually and I'd be totally drained. Nothing left for the family. I'm an introvert, so just regular office-life is draining. Covid was the best thing that ever happened to me, since we've been remote ever since. I can leave work and I still have "social budget" left. It's so awesome. Why I bring this up: Coz working with the AI intern is so freeing. I literally have it work for me like it was an intern. But I do not have to be "careful", I don't have to be "nice", I don't have to be in "teaching mode and spend 3 hours that I could've done myself in 20 minutes". I can just say "WTF dude! that's BS, adjust the skill so this never happens again" and a minute later it's done. In contrast, I spent 20 minutes talking to a "Senior" someone just to get them to abstract to a higher level and answer the important customer focused question on some problem instead of doing a technical deep dive yet again.
Sorry, tangent </rant> :P
On the spidey senses: Well guess what, this is still an economy where my and their skills matter. They swim in the shark tank or they sink. I'm not gonna do their work or their learning for them. I'll help them along to a point but at some point they gotta learn to outswim the shark (or if you like the lion metaphor better, to run away from the lion faster than the next guy.
Stopped midway through reading it to clarify something.
I don’t want your conversations :)
Anthropic has it and this is beyond me.
My plugin commits to your repo.
When it comes to keeping the WTF DUDE out of conversations, LFS gives you a net trick.
You can edit LFS blobs independently from git repo (different storage), so up to some point you can independently edit them out without touching git history (with caveats, it’s a rabbit hole).
Also, I think the inflection point is making it public. Git helps, just “fork” the repo without LFS to publish code only, or with a “sanitized” LFS (it just needs a touch of tooling to play with it).
I am also shipping a hook that sanitizes secrets by default (because security) and can be used also for keeping parts of the conversations… “tidy”.
I have built the “cleanup swearing feature”. Yes sorry it’s llm-turtles all the way down if you want automated, and extra cruft. But is also ok?!? I have a concern, I want to address it, I need to put some extra work…
I just want to clarify that privacy is my concern too and I have found that it’s not impossible.
I did not started coding until I found out that there is a way to contribute to a repo without participating in the “sharing conversations” game. (Not difficult: it’s your machine)
I am not publishing the repo until I have had enough conversations like this to introduce different opinions in my line of thought, especially around non technical hurdles.
My biggest concern is “why the hell would I teach an LLM that much of me, knowing very well this is how I will automate myself away”.
But even then, it’s either anthropic doing it, or me (coder, not plugin owner) AND anthropic doing it.
I am not advocating to giving away my skills for free.
One feasible variation of this whole record conversation is “commit code to company repo, commit reasoning to MY lfs”.
Why not? It’s my critical reasoning!!!
I understand you may not want my conversations and I might believe you. You seems like a nice dude.
I don't want my conversations to be forever recorded. I need my private corner. As an analogue: I want to be able to talk to some guy at the office without there being listening devices that's recording me. I want to be able to shut a door and nobody else in the office can listen in. I don't want to be forever forced to have every single conversation ever in front of the entire office.
That's what me talking to my intern is. I'm not gonna spend time to "sanitize" a conversation. I won't trust an LLM (or your code/LLM prompts) to sanitize my conversations. Heck me saying "WTF you stupid piece of electrons floating the ether" is literally what made the probability machine take the turn that made it come up with a stroke of genius from its training data. Whatever is valuable: The outcomes, plans, requirements, system invariants etc. I'm entirely fine to put in the repo. But: I am putting them in the repo.
We do that at work w/ the "AI first" projects. There's a lot of documentation to help the LLMs that everyone including PMs and designers now are using be on the same page. Essentially a lot of the stuff that used to be floating around people's heads or in various other places like the ticketing system or wiki, is (supposed to be) kept inside the (or a separate "docs") repo.
Regarding automating away: Totally agreed and models have come a long way in a short time but are still not there. And if "coders automate themselves away" so that "PMs can now code" is the thing, well then I'll be the better PM that knows how to get the LLM to do their bidding better than the PMs that will "vibe themselves into a corner". Like, when we talk to our PMs and designers about how we make the AI know all these things so we can move as fast as we can, they generally are just not comprehending, can't follow, can't replicate.
As for self-recording your own conversations and learning from yourself for yourself, the same way you learned more/better coding techniques for yourself: Yes absolutely and that's what I'm talking about. I do have a CLAUDE.local.md and I'm sure there's stuff in there that isn't just "personal preference" but actually helps me be better w/ Claude than others. I'm not sure I could tell you which parts those were though to be honest. Same way I try to teach some of my techniques to others. I gladly help them troubleshoot and they can learn from seeing me and how I come up w/ the stuff I come up with. Most people don't pick up on it or don't even pick it up when I explicitly tell them. Their loss. I guess some of this is https://news.ycombinator.com/item?id=48109460 ;)
i misunderstood "wall of text" (i was thinking about bloating repo with it), my solution to understanding is just to create ad-hoc tools to parse the json
i coded a web ui with simple toggles: show me what user said, what llm said (nice to see what I was thinking about, nice to see how LLM came up with solution X, you get tools calls, maybe it found something i didn't think about or viceversa) you can search/grep (.ie: did i consider idempotency when i build feature X? open session, search/grep idempotency) you can, up to some point, resume the conversation (yes i know, cache busting makes some usages of this impractical, but in general resuming and asking "when we did this, did we think about that" tends to work... let's say that research is ok, time travel, meh)
overall, one of the advantages of LLMs is to be able to direct then ad data for insights, via standard CLI tools, via specific prompts, or building some mini tools (yeah vibe coding is fine sometimes) whatever my question, if i have data i can have an answer
LFS helps with the second aspect (buried bullshit). Unless you smudge, you have a pointer, and that is just 3 lines. You need to learn some ergonomics, but ok, some of us learnt how to use Jira XD
Taking your position a bit further, yes, committing chat sessions implies that you also need to review them so that bullshit doesn't filter through. Milage varies based on your personal preferences, which project you are working on, and many more heuristics. Some will find it boring, some will think it's good project maintenance, all should be able to find a way to handle this based on their preference.
It is also nice to pointout that cleaning bullshit doesn't need to happen at merge. LFS blobs being stored separately, you can have side flows helping you out, without clogging yoou CI pipelines.
"no dude"-> rules you can put down SOME rules usually this happens to me at PR. I am tired fo saying "you should always check X", so i bolt it down "someplace". I am running the usual motions i suppose most of us try to adopt: put this down in agents.md, in folder x or y, in path-scoped rules using agents, in memory files (i am exporting/importing those too), in subagents that review code before PRs.
in the end it's an unsolved problem at large, but 1. hopefully it will get better, my feeling is that it's just a cambrian explosion, and the fittest will survive... (also, owning the harness should help, i suppose .. i use claude code :D ) 2. in a team, having personal styles surface is valuable. "dude don't do that" is quite often .... design. When rules go in the repo, at least we can find an agreement in person, and at PR is not about linking a document you read at onboarding, but finding out why the agent did not respect the rule. To me, that is more grounded in a tool. 3. rules are ... not static? We change our minds? We get better at things? We want to experiment? I am not advocating for a perfect rule system that replaces me, but for a good enough one that removes cruft from my daily job.
I think my approach is actually helpful when it's time to find root causes (YMMV). Via tools that parse sessions, you can see when that specific portion of code has been written with a better granularity. During that bit of the conversation the user was worried about X and asked AI to do Z and AI read this and that file and "thought" this and that and wrote that piece of code. Maybe the user was making wrong assumptions, maybe the LLM did not read the correct files or instructions, in any case you have a better tool for investigation. It's up you to decide wether to use it, wether this lead to just solving the bug or also fixing instructions, etc, i am just saying that it actually helps to have some measure of the context on which this change made sense.
"Fluffy wall of text that looks good but is factually wrong. "
it might be good or bad, right or wrong, but what is in the sessions is the truth of what happened. PR desc are horrible, i share that feeling with you, but having the story of how that thing happened is just not the same as "final summary of what we did in the past X hours".
As a sideline: LFS doesn't really pollute your repo once you get to learn its ergonomics. Having chats in LFS also lets you approach this
Reproducibility... To me those conversation are basically the history for decisions taken while implementing. They are documentation. The real problem with docs was that no-one has ever liked writing them, nor it was easy to implement a standardization around them. If you just record/log, there';s no extra effort needed, and once there tools and LLMS are pretty good at helping us extract insights.
I am also assuming, there is a correlation between quality in the conversation and in the code. I know, i'm being hand-wavey, but overall i think critical thinking is what makes code better, and being able to see if/which it has been applied can be a good proxy. I ask for forgivness already: I not going down the rabbit hole of quantifying quality etc. It's a broad statement that should be taken with a grain of salt.
If you want to go abstract, you can think of coding as going from thoughts to 0-1 in bits. We have high(er) level languages that help us organize thoughts to help us so that we can better keep them in our cognitive flow/load. LLMs are an upper layer, that scrambles the code and make it more difficult to grasp. But the reasoning behind the code is now available, and quite easy to parse. I think this is the core point to me. Code is an intermediate artifact between thinking and bits. Now we have a second artifact: the conversation/decision that led to that code. Why are we not storing it?
disclaimer: I am, of course, mildly in love with my own project and ideas, so possibly i like this too much just because i built it. IKEA effect or whatever.