Learnings

Before touching code, confirm what works and what is broken. In a small team with a loose process, assume overlooked bugs already exist.

Context

A small audio technology company with fewer than 10 people. Small team, tests are checked by everyone during the morning meeting. I had been at the company for about 3 months.

What happened

I removed an unnecessary infinite loop in a core audio thread. That exposed other failures, and I chased them in parallel. Morning test runs kept failing, taking up everyone’s time. Each fix skipped proper checks and triggered more latent bugs, creating an endless loop of debugging.

What I did

I reverted the codebase back to its original state. Then I checked functionality from a clean slate.

As a result, all the regressions that had been found were existing bugs. They were not caused by my changes.

Since my changes were not the cause, they could not have been fixed by me.

What went wrong

I didn’t check for existing bugs before changing code. I rushed to fix things with Claude’s help and juggled multiple issues at once, which compounded the confusion.

Audio data processing is inherently complex. Because the system involves both mobile app + Virtual Room simultaneous connections, it is affected not only by audio data processing itself, but also by state changes from external actions (e.g., recording + playback, or user mute state while only playing audio).

Lessons learned

Thoroughly cover test cases and verify behavior before edits. Core audio paths touch many scenarios—microphone on/off, device changes, and different STT providers—so the odds of preexisting bugs are high.

You must also understand whether a bug is caused by your change or is pre-existing. Even if it was an existing bug, I was touching core logic that could easily be mistaken as being caused by my changes.

Follow-up

Successfully improved CPU and memory usage. I've tested for 1 hour speech-to-text usage on our app.

Before

• 400%-500% CPU usage
• Memory leaks

After

CPU now averages 100%-200% with peaks around 300%, using roughly half the CPU time and no longer leaking memory.