DEV Community

John Nguyen
John Nguyen

Posted on

Vibe coding feels great… until debugging

The hidden problem with fast-growing codebases (and why debugging gets harder over time)

Lately, I’ve been doing a lot of “vibe coding” 😄
(build fast, ship fast, iterate fast)

At the beginning, everything feels great:

  • Features ship quickly
  • The app works
  • You feel productive

But as the codebase grows…

Something starts to change.

Not suddenly, but gradually:

  • Code becomes harder to review deeply
  • Bugs take longer to understand
  • Bad performance
  • And most importantly… it becomes harder to trace the root cause

It’s not about bad code

At first, I thought:

“Maybe the code quality isn’t good enough”

But that wasn’t really the problem.

The real issue was:

I was losing the ability to reason about the system


The real pain: losing traceability

When the system is small:

  • You know where state comes from
  • You know what triggers what
  • You can mentally simulate the flow

But when it grows:

  • State updates happen across many places
  • Transitions become implicit
  • Logic is distributed and harder to follow

And then:

You can no longer reconstruct what actually happened


What happens when you lose traceability?

  • Debugging becomes guesswork
  • Fixes feel uncertain
  • Performance issues are treated at the symptom level
  • You lose confidence in the system

A simple idea: what if state had a clear flow?

This led me to a simple question:

What if we could see how state moves through the system?

Instead of scattered updates, think in terms of:

state → action → next state
Enter fullscreen mode Exit fullscreen mode

Where every transition is explicit and traceable.


I built a small experiment

I turned this idea into a small library:

react-state-flow

Demo gif
Demo image


What improved (for me)

After trying this approach:

  • I could trace what happened more easily
  • State changes became predictable
  • Debugging had a clear direction instead of guessing

Open questions

I’d really love feedback from others:

  • Do you face similar issues in large codebases?
  • Does this approach make sense, or is it over-engineering?

If you read this far — thank you 🙏
If you find this useful, feel free to give it a ⭐ on GitHub!
Would love to hear your thoughts.


Top comments (0)