Over the last week, I’ve been building a Flutter/Android indoor cycling app with Bluetooth heart rate monitor and trainer support.
From March 8 to March 16, 2026, this repo went from first commit to a phone-deployed app in 28 commits, with 103 files changed and roughly 13,865 lines added. The current codebase is already over 10,000 lines across app and test code.
And here’s the important part:
All of the code was written by AI.
That sounds like the future.
But the real lesson from this week is not “AI writes code.” It’s this:
AI should be in the loop after the code is written too.
Because code generation is only half the story. The other half is what happens when reality hits: logs, crashes, flaky device behavior, broken tests, missing context, and the human developer stuck stitching it all together.
That’s exactly what happened in this project.
The commit history tells a familiar story of real software work:
That is not failure. That is software development.
But it also shows why code generation alone is not enough.
If AI can generate the app, it should also be able to:
That is the workflow I want.
We hit a runtime assertion from Firebase Analytics because event parameters included booleans like bluetooth_ready: true.
Firebase Analytics accepts strings and numbers, not raw booleans.
This was not a business-logic failure. The BLE logic was fine. The analytics wrapper was the problem.
An AI system watching logs could have:
Instead of me reading logs, explaining the issue, locating the wrapper, and manually driving the fix.
The more serious issue was a reconnect loop after disconnects.
The app would bounce through states like:
connecting -> disconnected -> reconnecting -> connecting -> disconnected
That is exactly the kind of thing Android BLE stacks do not tolerate well.
The fix was not “retry harder”. It was to impose a proper state machine:
This is a perfect example of where AI can do more than autocomplete code.
If AI had access to the logs from the start, it could have recognized the reconnect pattern, mapped it to known BLE failure modes, inspected the controller and repository layers, and prepared the remediation as a reviewable PR.
The biggest time sink was not implementation.
It was waiting around and gathering context from different places:
The human becomes the integration layer.
That is exactly the part I want AI to remove.
Not the engineering judgment. Not the approval step. Not the accountability.
Just the manual glue work.
For me, this is the right model:
That is the sweet spot.
Not “YOLO autonomous production edits”. Not “chatbot writes snippets when asked”.
Continuous AI triage plus human approval.
When AI writes a lot of code quickly, you get leverage. You also get more surface area, faster.
That means observability and feedback loops matter even more.
If a project is largely AI-generated, then every exception, assertion, and failing test should immediately feed another AI loop that tries to contain it.
That is how you support a zero-bug policy: not by pretending bugs won’t happen, but by treating every bug as an input to an automated repair pipeline.
Based on this project, I’d estimate this kind of workflow would save at least 60-90 minutes per non-trivial issue, sometimes more.
Not because the fix itself takes that long. Because the real cost is switching context, finding the right logs, locating the code path, checking history, writing tests, running the suite, and deploying again.
Multiply that across every exception and regression, and the savings become enormous.
The future is not just AI writing more code.
The future is AI staying on the job after the code is written.
Reading the logs. Watching the tests. Preparing the fix. Opening the PR. Letting a human approve.
That is the workflow I want.