Best coding practices for programmers / vibe coders?

I am a big time vibe coder and have been building vibe coded apps for a while. Currently working towards a big project and wanted to know what is the best coding practices that I can implement in my AI, that it takes care of the code and doesn't make many big mistakes. I have never had problems in my vibe coded projects and production has always worked quite well for me.

I am looking to learn the best coding practices that applies to all projects, that I can implement in my projects.

xSERPICOx said:

@Captaintj if you are moving to bigger projects you need to force the AI to keep files small and modular. once a file gets over a couple hundred lines the LLMs start losing context and making dumb mistakes.

using typescript instead of plain javascript helps a lot too because strict typing catches hallucinations before you even run the code. also look into setting up a .cursorrules file if you use cursor, or just a solid system prompt to enforce these constraints automatically so you dont have to keep repeating your setup.

Click to expand...

I am currently using Claude code. And yes I am using Typescript. Could you suggest how can I make sure AI doesnt make those dumb mistakes? We enforce max 600 lines per file.

the biggest upgrade is making your ai work in small, testable steps instead of letting it rewrite huge parts of the app. keep the code modular, use version control, add automated tests, and always review database, auth, and edge-case changes manually.

xSERPICOx said:

@Captaintj if you are moving to bigger projects you need to force the AI to keep files small and modular. once a file gets over a couple hundred lines the LLMs start losing context and making dumb mistakes.

Click to expand...

This was sound advice last year but it's no longer the case anymore.

Andrew Scherer said:

This was sound advice last year but it's no longer the case anymore.

Click to expand...

ok, then what is the correct advice for this year in your eyes?

Write good tests and keep updating and passing them, test in production also, try and break things as often as possible. Its difficult for people to offer you the best advice for your setup, as we are all scattered in the approaches and languages we use since ai came out.

for example I don't use local agents, i use in web copy and paste only. So my advice to me, is always have a good 7-8 sentence prompt that covers the mission ready to remind the ai every so often. Works well for me, but i don't know if you get to type something like that into ai locally, and really how it gets stored to access as regular as what a manual copy and paste would do. So i'm happily working in AI, but i don't think my advice to you is relevant, thats what i mean, everyone using different ides, languages, testing stacks everything is so fragmented now, there is no real common approach.

Just keep building, this probably won't be your first iteration, you might feel its easier to start again on the same project in a week! lol thats what happened to me, i made like 3 crappy pre versions to the one i have now as i can't remember what i done but i goosed up badly. Now i'm clued up with my setup, my current version is defiantly the final.

Test are your best friend though. Good luck.

Panther28 said:

Write good tests and keep updating and passing them, test in production also, try and break things as often as possible. Its difficult for people to offer you the best advice for your setup, as we are all scattered in the approaches and languages we use since ai came out.

for example I don't use local agents, i use in web copy and paste only. So my advice to me, is always have a good 7-8 sentence prompt that covers the mission ready to remind the ai every so often. Works well for me, but i don't know if you get to type something like that into ai locally, and really how it gets stored to access as regular as what a manual copy and paste would do. So i'm happily working in AI, but i don't think my advice to you is relevant, thats what i mean, everyone using different ides, languages, testing stacks everything is so fragmented now, there is no real common approach.

Just keep building, this probably won't be your first iteration, you might feel its easier to start again on the same project in a week! lol thats what happened to me, i made like 3 crappy pre versions to the one i have now as i can't remember what i done but i goosed up badly. Now i'm clued up with my setup, my current version is defiantly the final.

Test are your best friend though. Good luck.

Click to expand...

thanks, We are running 9600 tests currently, but I need a bit more indepth ways to improve

As vibecoder it is also important to SOMEWHAT understand the architecture yourself. You don't have to SPEAK the language, but kind of understand the language.

Captaintj said:

thanks, We are running 9600 tests currently, but I need a bit more indepth ways to improve

Click to expand...

since you’re on Claude Code, maybe you can put the important architecture rules, conventions and your build/typecheck/lint commands into CLAUDE.md so it gets that context every session. you can also use hooks to automatically run lint/typecheck after edits instead of trusting Claude to remember

Captaintj said:

I am a big time vibe coder and have been building vibe coded apps for a while. Currently working towards a big project and wanted to know what is the best coding practices that I can implement in my AI, that it takes care of the code and doesn't make many big mistakes. I have never had problems in my vibe coded projects and production has always worked quite well for me.

I am looking to learn the best coding practices that applies to all projects, that I can implement in my projects.

Click to expand...

Before practicing you need to learn few basics of code and the programming language you uses often and after that you would need to master the skill of prompting. I also did some projects using vibe coding but I also know that language very well.

Docstrings are important and type EVERYTHING. Avoid comments, in fact, add a hook to block all comments that are more lines than the code it is describing. Comments belong at top of file & as docstrings for functions & classes. the code isn't Claude's personal diary, the comments shouldn't reflect that. If you aren't paying attention to the comments, you'll probably find that it's leaving breadcrumbs for future hallucinations, adding rules you never intended, etc.
Do not do lazy typing. `any` `var` `auto` `table`, gone. Gotta be explicit.
Push back, it can do a better job. Give line limits for functions, not files. Usually I try to keep my files around 1000 lines, that's what I write by hand... But some files, yeah, they get to 3k+ (that's how I write by hand anyways... Some files just be like that)
Do not repeat code. Using a dependency injection pattern has simplified this a ton. This allows me to share state across all modules without creating circular dependencies.
Claude is a big fan of wrapping wrapper functions that are already simple wrapper functions. Add a hook banning wrapper functions.
Create a file or folder declaring coding standards. Point to it every time it breaks coding standards (it will).
My focus is usually on performance. Nothing irritates me more than slow code. In the SEO, and overall website niche, performance is often disregarded... That mentality is a mistake. If you can write it/prompt it easily, then don't add a dependency. I've not had issues with this in a while with Claude, but when I used copilot, it would add an npm package to center a div.
Hope this helps, kinda just started rambling but yeah, this is how I solved a lot of the slop code problems that is have run into when vibing up a project.

You really need to learn architecture and system design. I don't mean for one-shot tasks, but for serious projects.

Right now, everything is dirt cheap and simple. If an agent picks the wrong foundation, project structure, or tech stack, and you only catch it later when the codebase has already grown, you just crank reasoning to extra high, enable bypass, throw it in a container, and tell it to make it right.
It churns for 1 to 3 hours, rewrites 70% of the codebase, and you're good to go (assuming it doesn't mess up again).

But when token subsidies end, and they definitely will, rewriting an app is going to cost a whole different kind of money.
So, besides the fact that writing clean code is just good practice and good taste, it will ultimately pay off in both performance and money.