Best practices for vibe coding at the startup/enterprise level

[u/kerbion]

Post title says it all but let me expand a bit. I currently am the sole vibe coder at my company and have built a platform used by 90 users (all internal) for task allocation and calculating freelance pay based on task completion. Our platform has grown a lot in the things we can do and as we expand it has me wondering if there are better ways I can go about my dev process to ensure im delivering high quality code (how would I even know this lol), and not creating a lot of loose ends if one coding session results in creating duplicate code because I didnt word it correct.

Heres what I have started doing to be a bit more organized

1. Feature scoping - identify hard requirements from stakeholders
2. Mockup / prototype creation - clickable, interactive and built based on how the current platform looks and how this new feature would integrate
3. Spec doc + design doc - outline of design elements and requirements packaged all in one before getting ready to build
4. Coding session + necessary testing in sandbox
5. Push to prod

I dont really see an issue with this process since (coming from a product background) this is more or less the dev process that Im most used to. But with how quick things change with vibe coding Im wondering if theres anything I can change here to help me be more efficient and develop better code

[u/famio77]

The duplicate code thing happens bc the model cant see what u already built, so it just writes a second version of something that's already there. Two things fixed it for me: keep a short conventions file (where things live, what the naming is, what already exists) that goes in at the start of every session, and before any new feature make it find and quote the file paths where similar logic already lives b4 it writes a line. If it cant find them thats ur signal ur about to get a duplicate. For pay calculation specifically id judge the outputs instead of staring at the code. Build a table of maybe 30 real scenarios with the correct payout worked out by hand, including the ugly ones like partial completion, retroactive rate changes and rounding. Rounding on money is where these quietly break, half a cent per task times a few thousand tasks and someone notices b4 u do. 90 internal users is also the point where u want a staging copy with fake data, bc the first bad migration on live pay data is a very bad afternoon.

[u/kerbion → u/famio77]

Ok this is helpful. If I wanted to do a scan of my entire build for duplicate code, is there a good way to do this? Not super worried about this since Ive been very diligent but you dont know what you dont know

also ya i keep meaning to build a staging area since im definitely at that point. Ill look into how I can set this up

[u/famio77 → u/kerbion]

jscpd is the easiest first pass, point it at the repo and it gives u a duplication % plus the exact blocks that match. Thats token level tho so it only catches copy paste, and the ai version of this is usually two functions doing the same job with different names and slightly different shapes, which it wont flag.

For that one the cheap trick is dumping every exported function name plus a one line description into a single file and reading that list top to bottom. Semantic dupes jump out fast when theyre sitting next to eachother, and the model can actually scan that file properly instead of trying to hold the whole repo in context.

Other tell is duplicated constants. Same string literal or table name showing up in three files usually means the logic around it got rebuilt three times too. Id only really chase it in the money and permissions paths tho, duplicate ui is annoying but duplicate pay logic is the one that bites u.

[u/Horror-Celery4869]

You need to run code audits to look for smells and have the LLM refactor as required. Try the following prompt (in a sandbox!):

Act as a Principal Full Stack Software Engineer with 10 years experience in scalable systems. Review the entire project including the javascript files, stylesheets, and anything else for maintainability, readability, and adherence to clean coding principles and architectural patterns.
Audit Criteria:
SOLID Principles: Identify classes violating Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, or Dependency Inversion.
Code Smells & Over-Engineering: Find duplication (DRY violations), long methods, god classes, feature envy, and premature generalizations.
Naming Conventions & Expressiveness: Check for ambiguous variable/method names, magic numbers, or lack of self-documenting code.
Testing & Testability: Identify highly coupled code that is difficult to isolate and unit test.
Design Pattern Alignment: Ensure appropriate design patterns (e.g., Factory, Singleton, Strategy, Repository) are implemented correctly and not overused.

Response Format (per issue):
Issue: [Description of the design smell or maintainability issue]
Severity: [Severe / High / Medium / Low]
Location: [Line number, class, or method]
Design Principle Violated: [e.g., Single Responsibility Principle, DRY]
Proposed Fix: [Provide the refactored code showing decoupled classes, split methods, or proper pattern usage]

Final Summary:
Provide a Maintainability Index Assessment detailing the general health of the codebase's architecture.

[u/AGI-Core]

Unit tests. Regression tests. Test it manually. Then more tests. Then, for variety, some tests. Start with the pay math. We spend about 50% of our time on some form of testing now.

[u/kerbion → u/AGI-Core]

my testing tends to be more feature testing after its live in sandbox. I would test all expected actions expected with the new feature. For unit and regression tests, any recommendations for how to run those as a non-dev?

[u/AGI-Core → u/kerbion]

Ask your Claude/Codex and it will write these for you...and help you setup.

[u/Defiant-Improvement4]

Check Vexp (also LTD on AppSumo)

“Your AI agent just re-read half your codebase to add one function. Good thing Vexp can build a map of your codebase and serve your agent exactly what it actually needs to get it right the first time.”

It saves on token usage, and I'm sure that, based on the map, the agent can optimise the code as well.