I disagree, requiring code review for docs changes sounds great but in my experience it's extremely hard to get a human to review docs changes. Either you get a rubber stamp with no real review (zero added value, adds useless friction) or you spend days bugging people to actually review your changes. All for docs!
The counter-argument i envision is: "update your docs and code at the same time in the same PR!" That works great, until you want to document something that isn't precisely tied to a single piece of code. In fact I think the most useful docs describe high level systems rather than being associated with specific pieces of code. Use comments for that; in contrast, docs should be easily editable by anyone at all times, otherwise they never get updated (an evergreen problem in any scenario).
This is one of the arguments for polyrepo: different sources have different sensitivities. Code ending up in production needs to be reviewed, so enforce reviews.
Docs do not.
So what results is either allowing developers to push (but not force push) directly to main (you can always push revert commits if needed), or a PR process that exists to enforce linters and build-ability, but if those pass, allow the developer to merge independently, without human review.
Agreed, but I think the review & CI system should ideally be able to ignore markdown changes. Easier said than done.
But I think the biggest benefit, which we shouldn’t overstate, is that agents will just update docs as they find them. Including for big picture systems. Keeping docs updated is a PITA.
Writing style of AI often sucks. But I’ve found it pretty easy to rectify. And having some correct context is better than nothing or outdated docs in a lot of cases.
This'll be a controversial answer, but this sounds like exactly the sort of thing an LLM should be able to do reasonably well, whether by the human writing the docs and the LLM updating the code accordingly or by the human writing the code and the LLM updating the docs accordingly.
The Palmer Raids involved mass detention and deportation without trial. These raids were significant because they happened under Federal authority. US repression certainly involved torture and mass murder previously but mostly done locally (and sure, respond, "that was 'just' done to slaves and indians").
"The individuals captured during the Palmer raids were held in abysmal conditions: at Deer Island, six hundred prisoners were placed in barracks intended to house three hundred, with no heat and dwindling food; many were marched through Boston in chains and handcuffs, showered with the spit and trash of bystanders. In Detroit, eight hundred prisoners were crammed into a windowless corridor with only one working bathroom and no beds. At Ellis Island, hundreds of men were forced to sleep on steel slabs without mattresses."
Edit: Down voted without comment after being upvoted. I seldom reply but this is an exception - cowards!
There's some sort of browser automation software that defaults to this resolution and it's used by bots a lot. I used to work for a company that built a bot filter for form submissions largely based around this one data point.
> If it were possible to have such a simple pre-process step why wouldn’t the AI Labs upstream the optimizations themselves?
Not defending these tools, but one reason these might not be upstreamed is because it would negatively impact vendor margins, and they have no incentive to save their users money
Judging by the leaks, OpenAI and Anthropic already train reasoning traces to use fewer tokens (they deliberately omit articles and prepositions, use very short sentences, etc.), even though you pay per token. So it wouldn't make sense to do that if the only incentive was "make them pay for as many tokens as possible per task."
It's more subtle than that. If a user has to wait longer for a solution/pay more, they'll be less satisfied and may switch to a competitor. More unnecessary tokens also means more unnecessary compute. Longer sessions are increasingly more expensive to serve than shorter sessions.
And there's always the Jevons effect: as a resource becomes cheaper, demand often increases, and so does net resource consumption.
So, imho, frontier labs have every incentive to reduce token usage per task (while also making you use AI for more and more tasks in your daily life)
> Researchers estimate roughly half of human crashes go unreported, and up to one-third of injury accidents, because drivers hope to avoid insurance price hikes. That potentially skews safety numbers in favor of human drivers.
I am not understanding the phrasing of this section. If humans under-report crashes, and autonomous vehicles accurately report crashes, then that would mean the rates are more favorable towards autonomous vehicles rather than humans, right?
Your interpretation is correct and not at odds with their phrasing. They mean that reported safety numbers for humans are skewed towards appearing more safe than they actually are.
I'm not sure i see it as an ad. "Sent from my iPhone" is an ad because the iPhone is not a meaningful part of sending the email. Claude is a meaningful part of the commit though if you're using it, so to me it's more like clarity or transparency than an advertisement.
You don't see how a link to "https://claude.ai/.." in the Git log is an ad for Cluade/Anthropic? It feels exactly like "Sent from an iPhone" to me, and has exactly the same value to people reviewing the Git log later (i.e. none).
Keep in mind that if you run across someone else's spam in the Git logs:
- You need a Claude account.
- You need permission to view the session.
The only people who can just follow that link and look at how Claude was used, is Anthropic themselves. Therefore, they can also use it as an additional mechanism to tie sessions back to other IDs/identities. For everyone else this is "Sent from an iPhone" but longer.
But presumably everyone in your company/team is using Jira, so it's not an "ad" because it's a product already used internally. Claude is appending these links to all commits by default, whether or not others on the team use Claude. Those are very different things.
Good counterpoint. We link to GitHub from JIRA, and the reverse. Linking to the Claude session that generated the code seems reasonable...it's a related artifact.
One thing I'm not sure about: what is the utility of linking to the session? What are folks expected to do with that data?
You're missing the pattern of behavior from Anthropic. They constantly market like this: the session link, the Co-Authored by Claude, the unwillingness to adopt AGENTS.md. Hell, on workflows on 2.1.246 Claude's been ignoring the "attribution" block in settings.json and gone right back to coauthoring every commit.
What's the odds on them fixing that bug anytime soon.
The part after "https://claude.ai/" is a UID, that's useful to have to tie together multiple possibly unrelated commits and changes authored in a given session.
The way I see it, the conversation transcript is the important part. The specific link to claude.ai nor the model itself is important to me. Otherwise we'll all just be linking out to 10 different AI model providers websites to see history. I'd rather it be some open solution.
Models change so much that I don't really see why anybody cares what model was used to generate the code after the fact. It changes every few months and they're non-deterministic so its not like you'll ever "recreate" the same conversation yourself anyways.
UID itself is what is useful, regardless of whether or not you have access to the actual session transcript.
One could argue that "https://claude.ai/<uid>" is slightly more verbose over "CLAUDE_UID=<uid>", but the former is also slightly more convenient for those with access to the transcript, and both have word "claude" in them, because you need to be able to tell which UID in the commit message is for what.
If my tree kept a log of all the activities that led to it being a tree, I wouldn't mind if that log included "Spear and Jackson". To me the closer analogy with software would be if the final web app interface was stamped with "built with Claude".
There has been more than I project where I literally didn’t even look at the code.
I prompted what amounts to verbose “I want X” and then did QA. I’m perfectly happy with an LLM being credited with that code and there being no copyright existing for that code.
For some people that is their life’s work and they want to clutch pearls. Their sole contribution was a half baked idea and they shipped QA out to their “users” but they want to be credited with any rights.
There is definitely a continuum in LLM usage for code, do I agree with an AI blindly stamping every commit, not really.
Do I see LLM generated code as equivalent to me digging a hole with a shovel, it depends. Sometimes there was very little shovelling, other times there was no me involved and you may as well credit the entire hole to the shovel.
Where this will come in is when it comes to copyright and licensing.
If your entire product is LLM generated you sure as hell have no right to place any license on there other than potentially a MIT equivalent license, even that is dubious though but from an organisational standpoint MIT probably will be more widely accepted than saying it is uncopyrightable.
My argument being I would rather know that you didn’t even look at the code, which is what this will achieve, whether I agree with it or not at the very least it will make it easier to sift through the garbage.
This is a problem with copyright in general. There's no longer any requirement to provide information about copyright status, so there's no way for the public to know whether something is copyrighted (no doubt the uncertainty is intentional as an additional way to undermine the public domain). This is just as true for expired copyrights, or material placed in the public domain intentionally.
The solution isn't to add notices to non-copyrighted things; it's to require notice for copyrighted things, including date.
Individually, of course, one should simply assume things are not copyrighted if you have no way to know, and do whatever you want. If the author can't be bothered to tell you, you have no moral responsibility to care.
Yes it’s the same as using a stock drum pattern in a drum machine, it is not copyrightable because no human was involved in any part of it.
If you have an idea and want rights to it then do it the old fashion way and pay a developer to do a commissioned work and you can have your copyright, heres the catch, that will cost a hell of a lot more than 100usd a month
And when that developer copies and pastes useful code snippets from the internet into this product you’ve commissioned them to create? Also not copyrightable?
If you allowed that in your contract when doing the commissioning that's on you.
I wouldn't be surprised that if you asked an AI to weite said contract it would add a clause regarding copyright ownership of all codr and will put the onus on the developer to prove ownership of all of it.
Effectively you could sue them if you ever get sued.
When it comes to copyright and licensing it's complicated and it's best to write the code by hand.
I agree. But I think I would also like the OS to put a fingerprint (I.e committed on macOSX in /usr/marc/… while he was watching porn on xxx). This way we can get the full context by default and better understand the PRs.
How would it know for certain it was used for a given commit? What if there was no code? What if the approach was different, but some lines were the same?
I think some folks think that using an LLM is a shameful act and this is somehow shaming it and others believe that it ties back to the conversation. These conversations don't have any guarantee of being accessible over the long haul. If there was value in the conversation, the conversation should be somehow captured as well, not just some URLs.
Related to the form of the article rather than the content: what purpose do pull quotes serve in an online publication? Especially on phones they are so goofy, you read the pull quote and then one or two lines later you read it again. I get it for scanability in newspapers but I think it should be deprecated in online publishing.
The counter-argument i envision is: "update your docs and code at the same time in the same PR!" That works great, until you want to document something that isn't precisely tied to a single piece of code. In fact I think the most useful docs describe high level systems rather than being associated with specific pieces of code. Use comments for that; in contrast, docs should be easily editable by anyone at all times, otherwise they never get updated (an evergreen problem in any scenario).
reply