With Claude Code, you need to create the docs beforehand, not after.
For my latest project, I have 20k+ lines of markdown docs to guide it, with great success. Some of them are generic rules, some of them describes how I code, some of them describing the codebase & features. Then I have another 17k+ that are used while coding. Plans, phases, todos, reviews etc.
All of them are written by Claude Code also. I'm calling it "spec-driven development".
Cursor has a much different flow, where you usually pair program with it, which I call "ai-assisted development".
I've tried this approach but at some point you're just coding in a less precise language (English), and with more duplication.
My current approach is to stub out the architecture I want, write the type definitions I want in full, and ask Claude to fill in the blanks. It's good at implementing an interface but bad at devising the interface on its own.
That’s more or less what I do, but in an expanded way.
It’s not coding in English, but giving Claude memory about how the code base works, how it’s structured, what features available, why things are created etc.
This is how we work too, we have all these info in our head when building. But every CC session starts a new with blank slate. These documents helps getting the session “warmed up” enough to get quality output with lesser tech debt.
That's an interesting observation: how will LLM-generated code age?
Maybe we don't care, we just test it and throw more prompts at it.
But already 90% of some jobs is understanding the legacy code someone else wrote. I suppose LLMs can be good at this. Unless their maintenance of legacy code is just throwing more complexity at it until it becomes unmanageably complex.
With every piece of code created i write a doc of what id need to focus on when rewriting chunks.
AI has its usage, it makes some things faster... but spitting out more code does not necessarily make it more productive.
I ride AI train, but i ride my cb650r same way... sometimes wondering why i am still alive.