The Prototype Was Working. The Engineering Had Just Begun.

Sometimes the hardest part of building software isn't writing the code. It's understanding what you've already built.

In Part 1, I wrote about the fun part. The prototype phase. The “wait, this actually works” phase. The phase where Replit helped me get BreakCore from idea to playable mobile game without first requiring me to sacrifice a weekend to the gods of local tooling. That was real. That was useful. I stand by it.

But Part 1 ended with a warning: the prototype glow eventually fades, and when it does, the project starts asking harder questions.

BreakCore did not gently ask those questions.

It cleared its throat, opened a terminal window, and started yelling.

The first clue came when I moved the project into a more traditional local development workflow. I wanted GitHub to become the source of truth, VS Code to become my primary development environment, and Claude Code to become part of the day-to-day workflow. Replit was still useful, but I wanted to see what BreakCore looked like outside the comfortable environment where it had been born.

In my head, this was going to be an afternoon project.

Future Maryanne, armed with several weeks of migration notes and a growing collection of “well, that’s interesting” moments, would very much like a word with Past Maryanne.

The first real conversation started with lint.

If you have never watched a terminal window keep scrolling long after you expected it to stop, congratulations. I envy your life choices.

At first, I assumed something had gone wrong with the migration. Maybe VS Code was configured differently. Maybe I had installed the wrong package. Maybe there was some mismatch between my local machine and the cloud environment.

Then I started reading the output.

Some of the issues pointed to folders I did not even recognize. Others referenced files that clearly were not part of the game I had been working on. There were mockups, prototype artifacts, odd encoding characters, and enough noise that it became genuinely difficult to tell where the real problems ended and the false alarms began.

My first thought was, “What did Replit do to my project?”

It was a reasonable first reaction.

It was also wrong.

As I dug deeper, I realized lint was not telling me the game was broken. It was showing me the history of the project. Every experiment, abandoned idea, generated artifact, and “I’ll clean that up later” moment had quietly accumulated while I was focused on getting the game working.

That was uncomfortable. It was also useful.

The first real lesson of the migration was not “run lint earlier,” although, yes, future me would like that embroidered on a pillow. The lesson was that before I could fix anything, I had to understand what actually belonged in the project and the software behind it had to grow up.

Once the repository was in better shape and the lint warnings no longer resembled a Christmas tree, I briefly convinced myself the migration was behind me.

That optimism lasted about a day. The next challenge was not hiding in a forgotten folder. It was waiting for me every time I played the game.

The sound.

On the surface, it did not seem like a particularly dramatic problem. Some sound effects failed to play. Others overlapped when they should not. Sometimes the game behaved perfectly for several rounds, which was just long enough to lure me into thinking I had fixed it. Then it would misbehave again, because software has a flair for timing.

My first instinct was to fix the symptom.

Actually, if I am being honest, my first instinct was to let Claude fix the symptom.

Claude did exactly what I asked it to do. It analyzed the code, suggested a likely cause, generated a fix, and explained why the fix should work. We applied it, tested the game, and things looked better.

Until they did not.

Another audio issue appeared. Different symptom. Different explanation. Different fix.

At first, I did not think much of it. Debugging is iterative, and software rarely gives up its secrets on the first attempt. But after several rounds of fixing one symptom only to uncover another, I started to notice the pattern. Every solution was reasonable. Every explanation made sense. Yet I was no closer to understanding why the sound system felt so fragile.

That was when I stopped the debugging session.

Stop.

I do not want another patch.

I want to understand why we keep needing patches.

That simple shift changed everything.

Until that moment, Claude had been doing exactly what I asked it to do. I pointed at a symptom, and it suggested a fix. The problem was not the AI. The problem was the question. I was asking it to solve individual bugs when what I really needed was help understanding the design flaw.

Looking back, I had not outgrown the tool. I had outgrown the conversation I was having with it.

So we stopped chasing symptoms and started mapping the audio system. What we found was not one catastrophic bug. It was an architecture that had quietly evolved over weeks of development. Every feature had solved a real problem at the time. Every workaround made sense in the moment. Together, though, they had created a sound manager with too many responsibilities and too many paths through the code.

I have seen that happen on enterprise systems more times than I can count.

I just did not expect to find it in my own mobile game! (#humbled)

The easy thing would have been to keep patching it. We probably could have made each symptom disappear one at a time. Instead, we made the harder decision to stop preserving the existing design and rebuild the audio subsystem with a simpler architecture. The goal was not to make it clever. The goal was to make it understandable and stable.

That was the moment the project changed for me.

Not because the sound worked better, although thankfully it did.

It changed because I stopped treating AI like a vending machine for code and started treating it more like another engineer in the room. A very fast engineer. A sometimes overconfident engineer. An engineer who could be incredibly useful, as long as I remembered that someone still had to decide whether we were solving the right problem.

That distinction mattered again when I hit the Android authentication issue.

Native Google Sign-In failed locally with a developer error. The tempting thing was to rewrite the sign-in flow, adjust environment variables, or start changing code until something looked different. We checked the runtime logs. We verified the app was reading the expected web client ID. We confirmed the configuration was loading correctly.

The code was not the problem.

The missing piece was the local Android debug SHA-1 certificate. Once the correct Android OAuth client was registered for the local debug build, sign-in worked. No dramatic rewrite. No heroic refactor. Just the right root cause. My notes from the migration captured that lesson pretty clearly: when native Android sign-in fails with that kind of developer error, check package name, signing certificate, and OAuth client before rewriting code.

The project did not need me to type faster.

It needed me to slow down at the right moments.

AI made it easier to generate answers. Engineering judgment was still required to decide whether the answer belonged anywhere near the codebase.

By the end of this phase, BreakCore was not just cleaner. I was working differently. I was asking better questions, pushing back more often, and using AI less like a magic wand and more like a fast, capable teammate who still needed context, constraints, and the occasional firm “no, we are not doing that.”

That is the part of AI-assisted development I think we need to talk about more.

The value is not just that AI can write code.

The value is that, used well, it can help you investigate software. It can help you trace behavior, compare options, challenge assumptions, and explore a design. But it will only do that if you ask it to. If you ask for patches, you will get patches. If you ask for understanding, you have a much better chance of getting somewhere useful.

The prototype was working.

The game was real.

But the engineering had just begun.

In Part 3, I will talk about where the workflow landed: GitHub as the source of truth, VS Code as the primary development environment, Claude Code with actual project rules, CI checks, local validation, and Replit in a new role that made a lot more sense.

Because eventually, future me stopped leaving notes.

She wrote a workflow.