stopthe · HackerTrans

At $JOB we have an "AI adoption" dashboard, the more ai commits the better. I asked for the sources: the deterministic classifier, that decides whether a commit was ai-assisted, assigns the highest weight to the commits co-authored-by one of the known agents/models.

stopthe

4 mesi fadiscuss

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.

stopthe

7 mesi fadiscuss

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.

stopthe

7 mesi fadiscuss

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.

stopthe

8 mesi fadiscuss

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.

stopthe

8 mesi fadiscuss

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.

stopthe

8 mesi fadiscuss

Available in community edition 8.2+

https://www.mongodb.com/company/blog/product-release-announc...

stopthe

anno scorsodiscuss

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:)

stopthe

anno scorsodiscuss

> 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.

comments