Ask HN: How do solo devs protect their work in the age of vibe coding?
21–30 of 33 posts
[dead]
Re: Ask HN: How do solo devs protect their work in the age of vibe coding?
#22[flagged]
Re: Ask HN: How do solo devs protect their work in the age of vibe coding?
#23[flagged]
Re: Ask HN: How do solo devs protect their work in the age of vibe coding?
#24[dead]
Re: Ask HN: How do solo devs protect their work in the age of vibe coding?
#25The moat was never really the code....it was always the understanding that produced it. All those failed experiments and design iterations that led to the algorithm... that knowledge lives in your head, not the repo. Someone can clone the implementation, but they can't clone the reasoning behind every decision you made.
The audience problem is separate from the IP problem and worth solving on its own, start writing about the problem you're solving before you open-source anything.
Re: Ask HN: How do solo devs protect their work in the age of vibe coding?
#26[dead]
Re: Ask HN: How do solo devs protect their work in the age of vibe coding?
#27[dead]
Re: Ask HN: How do solo devs protect their work in the age of vibe coding?
#28[dead]
Re: Ask HN: How do solo devs protect their work in the age of vibe coding?
#29[dead]
Re: Ask HN: How do solo devs protect their work in the age of vibe coding?
#30I prefer to write in TypeScript. The "moat" for any TypeScript artifacts is training/experience. Most people who write in this language, or especially JavaScript, cannot confidently write original code. They cannot architect, struggle to plan, and cannot navigate multi-dimensional data structures. So if you want to be safe from other humans just write in vanilla code without use of frameworks, dependencies, or code agents. The code can be exceptionally well organized, well commented with explicit instructions, and amazing clear to read and even still the idea of deviating away from a small collection of finite memorized patterns will be unforgivably emotionally traumatizing to most people who write in this language professionally.
That has down stream consequences as well. If developers feed logic they do not understand to an LLM and then use that output as though they wrote it themselves they own the consequences of those changes. Open source licenses frequently include a no warranty clause, but at the very least you can reach out to the authors and ask for guidance/assistance. No original author is going to spend their time decoding your AI slop when you haven't spent the time to understand the code in the first place.