Skip to content

Build in Public · 5 min read

ChatGPT changed the rewrite, but not the taste

In 2025, ChatGPT helped me turn rough C++ and early Rust into better Rust. The real advantage was not speed. It was finally having leverage without losing taste.

In 2025, ChatGPT changed the way I worked on the audio engine.

I do not mean it took over the work. It did not suddenly know my taste as a mixer, or why one pass felt right while another felt too aggressive. It did not have thirty years of dialogue, music, rooms, compression, loudness, damaged recordings, platform weirdness, and client notes in its ears.

What it gave me was useful for a solo technical founder: leverage on the parts of the rewrite that were difficult enough to stall on and boring enough to avoid.

By then, years of code were sitting behind the project. Python notebooks. Python GUI tools. C++ conversions. Early Rust experiments. Some of it was solid. Some of it was written by a person solving the problem in front of him and promising to clean it up later. I am that person. Later does eventually arrive!

The C++ and Rust code had useful thinking in it, but was rough. Responsibilities were mixed together in some places. A function would know too much about file naming or workflow order. Error handling that worked for me was not enough for a real product. Other pieces had the right audio idea underneath, even if the implementation was not something I wanted to carry forward.

That is where ChatGPT saved the day.

Conversion is not the same as judgment

The headline version is simple: I was able to convert a lot of my poorly written C++ and Rust into high quality Rust.

The real version is more specific. ChatGPT helped me look at rough code and ask good questions:

  • What is this function actually doing?
  • Where does the boundary belong?
  • Which type should own this responsibility?
  • Which errors need to be explicit?
  • What has to be tested before I trust this?

That is not the same as outsourcing the product. I still had to know when the answer was wrong. I still had to listen. I still had to understand the audio goal well enough to reject clean-looking code that changed the behavior in a bad way.

A lot of AI coding talk skips over that part. A model can produce plausible code very quickly. Plausible is not enough for audio. The processed file has to come back feeling right and survive the edge cases. It also has to respect the recording, and I need to be able to explain what happened when it fails.

For me, ChatGPT did not replace taste. It cleared away enough of the syntax, boilerplate, and refactor fatigue that I could put more of that taste into the code.

The solo founder problem

There is a particular kind of drag that happens when you are building alone around a deep craft background.

I know audio. I know what a polished mix should feel like. I know the difference between loud and useful. I know why a creator thinks the problem is volume when the real problem is dynamics, noise, tone, or what a platform will do to the file after upload.

But knowing the domain does not automatically give you a clean software product. You still have to build the engine, the interface, the accounts, the billing, the presets, the onboarding, the tests, the copy, and the hundred little pieces that turn private capability into something someone else can use.

That is a lot for one person.

In earlier years, I could move fast when I was exploring. The cost showed up later. The tool worked because I knew where all the seams were. The product needed a different standard. In 2025, AI helped close part of that gap. Not all of it. It feels crazy to say, but the AI code quality was not quite there yet, but it was close enough for me to bring it over the finish line.

I could paste in an ugly chunk of older code and explain what I thought it was doing. I could ask for a Rust shape that separated parsing from processing, processing from export, and export from user workflow. It could draft tests that I could argue with. If it explained tradeoffs in a way that sounded too generic, I could ignore that part. That loop made the rewrite fun and productive.

What actually changed

The biggest change was momentum.

Before, a messy section of C++ could sit there because I knew fixing it would mean reopening too many decisions at once. With AI in the loop, I could start smaller. Translate this piece. Name the types. Separate this concern. Write a failing test. Compare behavior. Keep moving.

That changed how the project felt. It was less like a private archive of every technical decision I had ever made and more like a system I could keep improving.

I am still cautious. AI can sound certain when it is wrong and turn a specific domain problem into generic advice. It can also make code look cleaner while breaking the reason the code existed. Audio tools are especially risky there because listening decides the final answer, not a unit test by itself. At the end of the day, AI writes what it has seen, and many aspects of Level Rebel are not widely available in the training data, so that AI can regurgitate it.

But I would be lying if I said it did not change the project. It did.

It let me turn years of rough but valuable work into better code faster than I could have done alone. More importantly, it let me stay close to the part I actually understand best: the sound. The code got cleaner, but the taste still had to come from somewhere. That part is still mine.

Comments (0)

Please log in to leave a comment.

No comments yet. Be the first to comment!