Hacker News new | ask | show | jobs
by CafeRacer 307 days ago
Im heavily using claude code right now... because i need something now. But it's a huge pile of technical debt.

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.
2 comments
hakanderyal 307 days ago
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".

link
zarzavat 307 days ago
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.

link
hakanderyal 307 days ago
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.

link
CafeRacer 307 days ago
Yes, but claude forgets things
link
rich_sasha 307 days ago
> But it's a huge pile of technical 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.

link