Trusting your developer would save you a lot. Here’s how.
A week ago, I got introduced to a project. On the frontend, it looked fine. But the moment I started interacting with it, things got weird. Click a button, works fine. Try again a minute later you’ll get an internal server error. Random blurbs appearing. Stuff breaking in ways that made no sense at first.
Crazy things were happening behind the scenes.
Now here’s where trust comes in. Someone had to say, “This isn’t working. The structure needs to change.” And someone had to listen.
Looking at the backend, I didn’t need anyone to tell me what happened. The folder structure was a mess. Routes doing everything, logic scattered everywhere. It was clear the backend was cooked up by AI, piece by piece, with no one steering the ship. The project was probably on a tight budget. Someone decided to cut corners instead of listening to their frontend devs, who had apparently been pushing to bring in a backend engineer. They were ignored.
So I stepped in and reorganized everything around a layered architecture. Before, routes were doing business logic, database calls, validation; all tangled together. That’s why the app was unpredictable. One file changes, something breaks three folders away, nobody knows why.
Now? Controllers handle requests. Services hold the logic. Repositories talk to the database. Routes are thin, just mapping endpoints and composing middlewares. Clean separation. The TypeScript compiler passes with zero errors, and that button? Same result every single time you click it.
The code works now because the structure makes sense.
Here’s what I’ve learned: you can generate code with AI all day. But knowing when a codebase needs rethinking, not just more code, that’s a human call. And making that call means nothing if nobody trusts you enough to act on it.
Those frontend devs saw the problem coming. They just needed someone to believe them.
답글 남기기