From Vibe Coding to Clarity: Auditing My Own Backend Project

I built a student internship management system in 3 days, despite an injured hand. It worked. It got me through my defense. But here's the truth: I didn't fully understand every line I wrote. So today, I'm auditing my own code.

Why I'm Doing This

I am auditing code I already wrote because this project was written under pressure and in a bid to meet the deadline. I vibe-coded some parts, and now, weeks later, my code is difficult to understand. A code I wrote myself…and still struggled to understand? Wow!

I’m doing this audit so I can confidently explain and maintain my own code.

What is "vibe-coding"? To me, it means developing a project that functions well but is not understood by the programmers themselves.

Understanding my own code matters beyond confidence. It affects how well I can debug issues, explain my decisions in interviews, and confidently build on top of the system without breaking things.

What I Audited Today

I audited the node_modules, controllers, routes, src, middleware, and views folders.

The Auth Middleware: The auth middleware was one of the biggest things that clicked for me today. Middleware contains functions that run between the request (route) and the actual request handler (controller).

Before now, I used JWT authentication because it “worked,” but I didn’t fully understand the flow.

During this audit, I finally traced it properly:

• The token is created at login using jwt.sign()
• It contains user data like userId, email, and role.
• On each request, the middleware verifies the token using jwt.verify()
• If valid, the decoded data is attached to the req.user

That single line — req.user = decoded — went from something I ignored to something I now fully understand.

It’s what allows every protected route in my app to know who the user is without querying the database again.

The .env file: This contains all the data and details that are critical to the project and should not be exposed publicly.

The package.json file: It contains information about the project and all the dependencies my project needs to run. When someone clones the project from GitHub, using the command npm install, every dependency in this file is automatically installed without the need to install them one by one.

What surprised me

Realising the true usefulness of the package-lock.json file surprised me. Before the audit, I thought it contained dependencies both used and unused by the project. But during the audit, I learned it locks the exact versions of all dependencies (and their dependencies) to ensure consistent installs. It basically contains dependencies of dependencies, which are dependencies required by those packages. For instance, in my project, I used a version of Express. Just "express" will be shown in my package.json file. But the version of my Express needs some other dependencies to run properly, like bytes, and these other dependencies are what are contained in the package-lock.json file.

Despite the progress, the use of the config file is not yet understood, as well as the server.js file. They will take a good chunk of my time tomorrow as I dive deep into auditing and understanding my own project's codebase.

What I Learned

For other developers, vibe-coding under pressure: I'd advise having a good foundation on whatever tech stack you've decided to build with. That can help with easy and minor code understanding and debugging, too. If it's urgent, then you can go all in and come back to it later. But if you need to defend this project before people like recruiters, a good understanding of the codebase is essential.

This audit is not to encourage vibe-coding but to thoroughly understand what a developer is building. With this audit, I now have a better understanding of how my project works, especially around authentication and project structure, even though there are still parts like the config folder and server setup that I’m yet to fully grasp.

What's Next

Next, I’ll be auditing the config folder and server setup to fully understand how my application is initialized and configured. After that, I plan to refine the project, add more features, and redeploy it on Render.