I'd say that the worst thing that can happen to a developer using Claude etc is detachment from the code.
At some point of time the code starts to be "not yours", you don't recognise it anymore. You don't have the connection to it. It's like your everyday working in another company...
Funny story comes to my mind, I bought my daughter Instax because I was pretty sure it is digital, i.e. has a printer inside. However, I had trouble finding the resolution of the printer there... When we got it, I understood this is real photography paper, not a printer at all!
If you got a recent digital one it actually does print on the photography paper. I'm guessing it works like a line scanner but in reverse, using color LEDs to "print" light dots in high resolution on the paper.
Being completely untainted is the standard many reimplementations set for themselves to completely rule out legal trouble. For example ReactOS won't let you contribute if you have ever seen Windows code. Because if you have never seen it, there can be no allegation that you copied it.
That is however stricter than what's actually legally necessary. It's just that the actual legal standard would require a court ruling to determine if you passed it, and everyone wants to avoid that. As a consequence there also aren't a lot of court cases to draw similarities to
> For example ReactOS won't let you contribute if you have ever seen Windows code. Because if you have never seen it, there can be no allegation that you copied it.
I've heard this called in some circles "The curse of knowledge." The same thing applies to emulator developers, especially N64 developers (and now Nintendo emulator developers in general) after the Oman Archive and later Gigaleaks. There's an informal "If you read this, you can NEVER directly contribute to the development of that emulator, ever."
This comes to a head when a relatively unknown developer starts contributing oddly specific patches to an emulator.
"Taint" requires that the code is demonstratably derivative from the *GPL licensed work.
This is actually harder standard than some people think.
The absolute clean room approaches in USA are there because they help short circuit a long lawsuit where a bigger corp can drag forever until you're broken.
It's harder than some people think, but the author does a lot of the work when he names the resulting artifact "chardet v7.0.0". If I thought I was writing the kind of arms-length reimplementation that's required, I would never put it into the versioning scheme of the original, come on.
Not a lawyer, but that always seemed naively correct to me.
However, the copyright system has always be a sham to protect US capital interests. So I would be very surprised if this is actually ruled/enforced. And in any case american legislators can just change the law.
TBH my kids have limited access to their (Android) phones using family link but I don't see option there to:
- block certain list of sites
- block walls inside YouTube for example
- limit amount of scrolling time Vs amount of learning time (this can be done quite easily)
So just give the tools to parents and stop requiring IDs for adults. What happens if kid gets adult's phone? And what happens when kid gets dad's rifle or car keys? It doesn't mean that all the rifles and car keys should now start to include blood sample based age verification mechanisms
--Edit--
Apple family management is even worse. The best I heard of is implemented in the switch console
1. This California law doesn't require IDs. (Some states like TX do, but mainly for websites "harmful to minors").
2. If I have to think through your examples -- purchasing cars and arms requires strict ID checks that go further than age verification. If a kid drove or use weapons owned by their parents, I'm mostly confident parents are liable in most jurisdictions. But I think I can guess out your concern -- 24x7 online tracking can be much more intrusive and terrifying than a one-time background check -- which I actually agree.
3. In fact, you can think this law exactly require OSes (thinking of as iOS/Android/Windows/macOS) to "give the tools to parents" -- being able to indicate that the user is a minor at OS level and expose that information to apps.
That would be wonderful but cracking proprietary blobs which may be and probably are encrypted, would take massive amount of time, and later rework could take a lot of tokens and broken SoCs. Nowadays electronics are driven by software so one bit off and voltage can get 9V instead of 3V for example
I give my agents read permissions to all repos related to a given repo. Add a bit of context to AGENTS.md or equivalent and they do just fine with understanding service boundaries.
Another concept I like is that we should optimize for next year's AI. Don't migrate to a monorepo if your only motivation is the performance of today's agents, because a year from now this may be a non-issue. Of course other motivations may still be valid.
reply