The family diary I wouldn't want to have AI written. For the family encyclopedia I might be okay to be described as a biographer would about me.
A family diary would be most valuable to me. Knowing what family members did last week, adventures they had, and written down from the horse's mouth. And shared family events, where members make the diary notes together, add quotes on things that were said, etc.
I can also imagine an encyclopedia to be valuable, but it is a different use case entirely. Many people are keen to keep track of their family tree, and record the 'official history' of the family for generations after them. I might consult it before going to a family party to re-remember what university that niece went to again. But it is a more business-like use, less fun, less valuable. Here AI is perfect to do the boring chores of keeping stuff up to date.
I used Cursor for the second half of last year. If you’re hand-editing code, its autocomplete is super nice, basically like reading your mind.
But it turns out the people who say we’re moving to a world where programming is automated are pretty much right.
I switched to Claude Code about three weeks ago and haven’t looked back. Being CLI-first is just so much more powerful than IDE-first, because tons of work that isn’t just coding happens there. I use the VSCode extension in maybe 10% of my sessions when I want targeted edits.
So having a good autocomplete story like Cursor is either not useful, or anti-useful because it keeps you from getting your hands off the code.
When your hardware is in the physical custody of the attacker, the threat model changes significantly. Designing a console that takes years for attackers to crack is an impressive feat of engineering.
First, recognize that, for the first time ever, having good docs actually pays dividends. LLMs love reading docs and they're fantastic at keeping them up to date. Just don't go overboard, and don't duplicate anything that can be easily grepped from the codebase.
Second, for #3, it's a new hire's job to make sure the docs are useful for new hires. Whenever they hit friction because the docs are missing or wrong, they go find the info, and then update the docs. No one else remembers what it's like to not know the things they know. And new hires don't yet know that "nobody writes anything" at your company.
In general, like another poster said, docs must live as close as possible to the code. LLMs are fantastic at keeping docs up to date, but only if they're in a place that they'll look. If you have a monorepo, put the docs in a docs/ folder and mention it in CLAUDE.md.
ADRs (architecture decision records) aren't meant to be maintained, are they? They're basically RFCs, a tool for communication of a proposal and a discussion. If someone writes a nontrivial proposal in a slack thread, say "I won't read this until it's in an ADR."
IMHO, PRs and commits are a pretty terrible place to bury this stuff. How would you search through them, dump all commit descriptions longer than 10 words into a giant .md and ask an LLM? No, you shouldn't rely on commits to tell you the "why" for anything larger in scope than that particular commit.
It's not magic, but I maintain a rude Q&A document that basically has answers to all the big questions. Often the questions were asked by someone else at the company, but sometimes they're to remind myself ("Why Kafka?" is one I keep revisiting because I want to ditch Kafka so badly, but it's not easy to replace for our use case). But I enjoy writing. I'm not sure this process scales.
The Q&A doc you're maintaining is fascinating you've essentially hand-built the thing I'm trying to automate. The 'Why Kafka?' entry is exactly the kind of decision that disappears when you leave.
The search problem you raised is the core of what I'm solving — not dumping commits into a .md, but extracting structured decisions from the conversation that surrounded the commit: the Slack debate, the PR review, the ticket context. Then making it queryable by the code it relates to.
You said you're not sure your process scales what happens to that Q&A doc if you leave tomorrow?
If I leave, the Q&A doc probably never gets updated again.
We're in the process of trying to get as much stuff as possible into source control (we use google docs a lot, so we'll set up one way replication for our ADRs and stuff from there to git). That way, as LLM models get better, whatever doc gets materialized from those bits and pieces will also automatically get better.
I’ve been following that post too since I started using Claude (about two weeks now) and it’s great. Sometimes for small changes I shorten research+plan into one step but I always tell it to stop and wait before it writes the code.
One thing I’ve learned: if you notice the agent spinning its wheels, then throw the work away, identify a fix (usually to Claude.md) and start over. Context rot is real.
Eh, they're still keeping the impending switch to PDT, just ditching the future switch back to PST (and all future changes). That should give around 7-8 months for a new timezone file update to percolate.
Not sure why you're getting downvoted. When I read the headline, my first thought was "how are they going to update the tz database on all Linuxes in the world in time?" I expect some confusion on November 1.
reply