Over time, one thing has become clear to me when working with AI-assisted coding using tools like Cursor or GitHub Copilot: 👉 Vibe coding without context rarely delivers meaningful results. Sure, it might produce an initial version that’s good enough for a POC. But the architecture usually isn’t production-ready. Keep building on top of it, and the tech debt piles up so fast that you eventually need to rebuild from scratch. It feels fast in the moment, but more often than not, you end up with: 1. Messy code 2. Inconsistencies 3. Endless back-and-forth iterations with the agent What works far better? Treating yourself like a Software Architect and treating your agent as a Junior Developer: - Write down requirements as if you were drafting specs - Document the architecture before diving in - Sketch an architecture diagram Once that foundation is in place, the coding flows smoothly - and the results are far more reliable. Frameworks like the BMAD method (https://lnkd.in/dyzNEBRx) or GitHub’s Spec Kit (https://lnkd.in/dtrRQEEb) help here, but at the core it’s simple: ✅ The more architecture and requirement based context you give the system (and yourself), the better the outcome in terms of Production ready code. Curious: do you follow a spec-first approach when coding with AI? Or do you prefer to start with vibes and refine later? #VibeCoding #SpecDrivenDevelopment #AI
I would also create a steering file with coding standards and naming conventions. 😛
Content | Branding | Strategy | Planning | Marketing | Product
1wAs a non coder, I would use my writing skills to create a requirements document. Maybe some sketches to show some relationships. But at the end of the day, it'll be a POC at best, and will need a proper dev to hammer it out. My other question is about IP - if you 'code' the next unicorn using a vibe coding platform, do you still own 100% of what you've created?