No. Even further than that, maintaining AGENTS.md and the like in your company repo, you basically train your own replacement. Which replacement will not be as capable as you in the long run, but few businesses will care. Anyway having some representation of an employee's thinking definitely lowers cost of firing that employee.
That is a cynical take and not very different from an advice to never write any documentation, or never help your teammates. Only that resemblance is superficial. In any organization you shouldn't help people stealing you time for their benefit (Sean Goedecke calls them predators https://www.seangoedecke.com/predators/).
On the other hand, it may be beneficial to privately save CLAUDE.md and other parts of persistent context. You may gitignore them (but that will be conspicuous unless you also gitignore .gitignore) or just load them from ~/.claude
I expect an enterprise version of Claude Code that will save any human input to the org servers for later use.
In hindsight, that would've been a real utility use case for NFTs. A decentralized cryptographic prove that some content existed in a particular form at a particular moment.
Some clarification. Since 2024 Yandex NV split into Nebius (NL-registred NASDAQ-listed company, no longer a search engine) and russian-based Yandex. The latter is fully controlled by russian investors.
The author (if there was any) stops short of admitting that it is yet another product that was heavily promoted via so-called influencers and failed to reach escape velocity and sell on itself. Like, nobody remembered Clubhouse already in 2021.
We've been using mongodb for the past 8 years. What we like:
- schema-less: we don't have to think about DDL statements at any point.
- oplog and change streams as built-in change data capture.
- it's dead simple to setup a whole new cluster (replica set).
- IMO you don't need a designated DBA to manage tens of replica sets.
- Query language is rather low-level and that makes performance choices explicit.
But I have to admit that our requirements and architecture play to the strength of mongodb. Our domain model is neatly described in a strongly typed language. And we use a sort of event sourcing.
Having dealt with similar architectures, I have a hypothesis on how this library (Hollow) emerged and evolved.
In the beginning there was a need for a low-latency Java in-process database (or near cache).
Soon intolerable GC pauses pushed them off the Java heap.
Next they saw the memory consumption balloon: the object graph is gone and each object has to hold copies of referenced objects, all those Strings, Dates etc.
Then the authors came up with ordinals, which are... I mean why not call them pointers? (https://hollow.how/advanced-topics/#in-memory-data-layout)
That is wild speculation ofc. And I don't mean to belittle the authors' effort: the really complex part is making the whole thing perform outside of simple use cases.
Unfortunately, the choice of license likely won't matter in the nearest future (if not already so). If a tech giant wants you open-source library, they will just point their agent to it and ask "to rewrite in the style of War and Peace". And more unscrupulous players won't even bother with a rewrite, as we've seen recently in the case of Cheatingdaddy/Pickle.
The flip side is that if they can technically pull that off then the cost of writing the library has dropped so low that an OSS maintainer probably wouldn't have to work too hard to write it anyway.
Being able to rewrite existing working code sufficient to copyright-launder it isn't the same as being able to write it from scratch, unfortunately, especially since LLMs seem to be allowed to ignore quite a bit of copyright law with complete impunity.
Imo it's totally plausible that something will be expensive & time consuming to create, even with LLMs, but still easy to fork outside current licensing restrictions with LLMs.
Rewriting it with a guarantee of not introducing any errors is still beyond current LLM capabilities, and there might be a certain correlation between that capability and the capability of writing it from scratch.
>If a tech giant wants you open-source library, they will just point their agent to it and ask "to rewrite in the style of War and Peace"
Is there any evidence of this happening? And any legal theory behind how it might have the intended effect? Training being fair use does not make AI a magical copyright-removal box.
AI is already "too big to fail" in every conceivable way. If there is a conflict between AI and the law, then the law will inevitably be rewritten, reinterpreted or repealed in the way most beneficial to the service of AI.
I expect a lot of leniency when it's something actually important to making AI work.
Training on most of the data in the world is important. Rewriting a document you don't own is not important. Or depending on what level the objection is made at, stealing some random library is not important.
Exactly zero, if answering your question as stated. But that is not the point. LLMs struggle with things that require tacit knowledge or are not found in the training set (i.e. haven't been done before). They excel at tasks that are described in the most verbose and explicit way, to the point that it looks humiliating from human POV. And what is more explicit than an existing codebase, especially with tests, comments and documentation lovingly put there by the proud author (remember, those github stars).
> business analysts don't get access to code or repositories at all for example or support people don't get access to the repositories and code.
Yes, but isn't it insane? What is the benefit from treating your own product as a black box? Yet that's mainstream. Sometimes I have the analyst (not on my team, but from a team we share a monorepo with) asking me questions that can be answered literally with a line of code. And she's a technical kind, knows SQL and such. And we write very idiomatic, high level code. But still, culture cannot change itself until it dies due to inherent inefficiency.
I think you underestimate inefficiency of requiring all business analysts and employees to learn GIT. If not all employees than more employees. I can pick put up job ad for BA saying knows JIRA and I have dozens of applicants.
We had a technical guy once where I worked that wanted to force sales guys to use LaTex to write documentation and requirements in and store it in GIT. I feel bad for the guy as he was laughed out by sales guys and he did not understood why because those are such a great tools…
OTH the inefficiency of an analyst who cannot answer even basic questions about the current state of the product without developers' help. Distracting them, or even worse - blocking until a dev is available.
I think it boils down to the power of balance in the org. Likewise I've met developers who cannot book a meeting. Some people have privilege to choose what to learn and what to laugh at. Actually, I'm surprised your sales guys wrote any documentation at all:)
That is a cynical take and not very different from an advice to never write any documentation, or never help your teammates. Only that resemblance is superficial. In any organization you shouldn't help people stealing you time for their benefit (Sean Goedecke calls them predators https://www.seangoedecke.com/predators/).
On the other hand, it may be beneficial to privately save CLAUDE.md and other parts of persistent context. You may gitignore them (but that will be conspicuous unless you also gitignore .gitignore) or just load them from ~/.claude
I expect an enterprise version of Claude Code that will save any human input to the org servers for later use.
reply