Do you honestly believe that the opt-out by Anthropic and Cursor means your code won't be used for training their models? Seems likely that they would rather just risk taking a massive fine for potentially solving software development than to let some competitor try it instead.
> For API users, we automatically delete inputs and outputs on our backend within 30 days of receipt or generation, except when you and we have agreed otherwise (e.g. zero data retention agreement), if we need to retain them for longer to enforce our Usage Policy (UP), or comply with the law.
If this is due to compliance with law I wonder how they can make the zero-data-retention agreement work... The companies I've seen have this have not mention that they themself retain the data...
>Anthropic spent "many millions of dollars" buying used print books, then stripped off the bindings, cut the pages, and scanned them into digital files.
The judge, Alsup J, ruled that this was lawful.
So they cared at least a bit, enough to spend a lot of money buying books. But they didn't care enough not to acquire online libraries held apparently without proper licensing.
>Alsup wrote that Anthropic preferred to "steal" books to "avoid 'legal/practice/business slog,' as cofounder and CEO Dario Amodei put it."
Aside: using the term steal for copyright infringement is a particularly egregious misuse for a judge who should know that stealing requires denying others of the use of the stolen articles; something which copyright infringement via an online text repository simple could not do.
Using torrented books in a way that possibly (well, almost certainly) violates copyright law is a world of difference from going after your own customers (and revenue) in a way that directly violates the contract that you wrote and had them agree to.
In the spacex subreddit there are comments claiming that key engineers have left the company because of differences with leadership/culture. Not sure how credible those are, but spacex has had suspiciously many failures recently.
It’s not even just a binary state of an engineer being there or not. The morale and general attitude of the environment can cause engineers still there to just not have their hearts in it.
I think about the countless engineering success stories I’ve read where you can tell the people involved were just living and breathing the problem.
It's hard to tell whether key engineers were the differences between success and failure but Comparably lists SpaceX’s Retention Score as an A– grade, placing it in the top 15% of similarly sized companies based on employee feedback. Additionally, SpaceX boasts an Employee Net Promoter Score (eNPS) of +25, placing it in the top 25% among peer companies
comparably.com.
Sounds impressive, sure. Question is how much weight do you put into survey stats like those given Musk's extensive history of things like buying the influence he wants, putting his thumbs on the scales of his truth-bot, getting generous valuations based on hype and stories, knowing about "those vote counting computers" (Trump's own words), ruthlessly firing anyone who disagrees with him, etc etc etc.
Then again, they are launching tons of rockets, and any cult leader has his followers, so what do I know...
Not to say that Musk's been particularly endearing lately - but what would the normal turnover in an engineering-centric company the size of SpaceX be?
Especially with how hot the field is these days. I suspect "key" SpaceX engineers do not lack for lucrative offers.
Where's the actual evidence for the productivity boost though? Wouldn't one expect a huge increase in valuable software products or a dramatic increase in open source contributions if llms provide this kind of productivity increase?
I think you misunderstand that case
"compiled its scores and statistics by employing people to listen or watch the games, then enter the scores on the computer which transmits the scores to STATS' on-line service, to be sent out to anyone using a SportsTrax pager.[1]"
Notice how they watched the game and got the statistics like that. The restrictions are about using the scoreboard and the data displays and reselling/commercialising that data.
It is however legal to watch the game and compile and distribute your own stats due to the game entering public domain.
Due to this many betting companies and data collection companies have to pay people to watch the game vs just scraping the scoreboard (which is the context from which I learnt about this). ironically at venue OCR is a common way to get scoreboard data.
I'm not a lawyer, but my interpretation of the lawsuit based on the Wikipedia article is that game results/scores are public facts and hence not copyrightable data. I don't see how the method by which that public data is collected changes anything materially about that case. Are you saying that inferring the score based on the scoreboard is what makes this illegal (why?)? What if they would infer the score using motion/ball tracking instead?
if you using CV to track the player, the ball etc from a broadcast it is fine, the scoreboard however not so straight forward. fwiw, doing CV from broadcast for accurate scoring of sports is neigh near impossible due to edges, but human in the loop systems exist. there are also numerous in venue CV systems which auto collect game and player information.
In my experience you just don't keep as good a map of the codebase in your head when you have LLMs write a large part of your codebase as when you write everything yourself. Having a really good map of the codebase in your head is what brings you large productivity boosts when maintaining the code. So while LLMs do give me a 20-30% productivity boost for the initial implementation, they bring huge disadvantages after that, and that's why I still mostly write code myself and use LLMs only as a stackoverflow alternative.
I have enough projects that I'm responsible for now (over 200 packages on PyPI, over 800 GitHub repositories) that I gave up on keeping a map of my codebases in my head a long time ago - occasionally I'll stumble across projects I released that I don't even remember existing!
My solution for this is documentation, automated tests and sticking to the same conventions and libraries (like using Click for command line argument parsing) across as many projects as possible. It's essential that I can revisit a project and ramp up my mental model of how it works as quickly as possible.
You're an extreme outlier. Most programmers work with 1-3 codebases probably. Obviously you can't keep 800 codebases in your head, and you have to settle for your approach out of necessity. I find it hard to believe you get anywhere close to the productivity benefits of having a good mental map of a codebase with just good documentation and extensive test coverage. I don't have any data on this, but from experience I'd say that people who really know a codebase can be 10-50x as fast at fixing bugs than those with only a mediocre familiarity.
The evolution of a codebase is an essential missing piece of our development processes. Barring detailed design docs that no one has time to write and then update, understanding that evolution is the key to understanding the design intent (the "why") of the codebase. Without that why, there will be no consistency, and less chance of success.
