For five years, I've been walking the spiritual path with my guru. I've done the processes, sat through the practices, and experienced real transformation in my life. But here's what drove me crazy: finding authentic spiritual guidance online is nearly impossible.
You either get:
- YouTube videos with hyped-up content that teaches you nothing
- Blogs gatekeeping everything behind "contact this number for guru guidance"
- Random people claiming to be masters when they have no idea what they're doing
I'd found the real thing—a legitimate guru, authentic processes that actually work—and I wanted other seekers to have access to the same structured path I had. So five months ago, I decided to build an app.
A hub for authentic meditations, mantras, and saadhnas (deity practices). Gamified with streaks and leaderboards. Progressive unlocking—certain processes only available when you reach specific levels. Discipline meets fun.
I had a vision. I had a full-time job. And I had AI to help me code after work.
What could go wrong?
The Honeymoon Phase: Shipping at Light Speed
Every evening after work, I'd open my IDE with two options:
- Write everything from scratch
- Prompt AI and ship features instantly
I chose speed.
I laid out the architecture myself—Android app, admin dashboard, backend, deployment flows—but then I let AI write the actual code. And honestly? It felt amazing.
Features shipped fast. Users loved it. Fellow spiritual seekers were finally finding something authentic and engaging. I told myself I was "focusing on the bigger picture"—what to build and when to ship it. The details? AI handled those.
The human mind is built for comfort. And I got very comfortable.
So comfortable that I stopped reviewing the logic entirely. I didn't know what was actually running in production. I just knew that features worked and users were happy.
Until they weren't.
The Collapse: When 50 People Stop Trusting You
One day, the complaints started flooding in.
"My streak isn't updating."
"The app freezes when I try to do my chanting practice."
"My meditation stats are completely wrong."
I watched my daily active user count plummet. All 50 of them—people who had finally found an authentic spiritual tool—were leaving.
And I sat there, staring at a codebase I'd "written," realizing I had no idea how any of it actually worked.
Bug #1: The Streak Calculation Nightmare
The streak logic was mixing UTC time and local time haphazardly in the backend. Users' meditation stats were a complete mess. I opened the backend code and thought: I've literally never seen this logic before.
It had my name on it. I'd shipped it. But I didn't own it.
Bug #2: The Audio Player That Killed Phones
I was using a deprecated method to play audio in Flutter. For smaller rep counts (108, 324 mantras), it worked fine. But when I added a practice that required 1,080 repetitions, users' phones started lagging and becoming completely unresponsive.
The classic developer tragedy: "It works on my system."
And it did! It ran perfectly on simulators and my Android 11 device. Meanwhile, production users were experiencing phone freezes.
The Gut Punch
Fifty people relied on me to support their spiritual practice. And I was sitting there saying "I built this" while having absolutely no idea what the code was doing.
I'd been lazy. I'd delegated my responsibility as an engineer to a chatbot.
And now I had to fix it.
The Debug Nightmare: When AI Becomes a Maze
I did what felt natural: I asked AI to fix it.
Attempt 1: "Your logic to rely on playbackStreamSubscription is wrong. Count the reps manually in a loop."
❌ Didn't work.
Attempt 2: "Actually, no—playbackStreamSubscription was right."
The AI literally contradicted itself.
❌ Still broken.
Attempt 3: "The package itself is causing the error. Install audio_service instead."
❌ Still stuck.
Attempt 4: "Move the logic to pure Dart. Use current timestamp, add number of reps × duration of one chant, adjust by playback speed..."
❌ Useless.
Attempt 5: "Add background permission."
❌ Failed.
Two whole days of this. Passing APKs back and forth with users. Opening new chat windows, getting confident answers that led nowhere. Finding bugs in the code AI had just provided with absolute certainty.
I was prompting desperately, hoping one magical change would fix everything.
It didn't.
The Breakthrough: Pen, Paper, and the Docs
Finally, I did what I should've done from the start.
I grabbed a pen and paper. I mapped out how the component was supposed to work. I read the actual documentation. I debugged the root cause instead of brute-forcing solutions.
And that's when it hit me:
This codebase has my name on it, but I don't own it.
I used to enjoy coding logic. I used to love learning how to write robust, clean code. Now it was just: prompt, ship, repeat.
All speed. But at what cost?
What I Learned: The Muscle You're Losing
Here's the truth no one wants to say out loud:
AI is letting you write code without thinking. But debugging requires thinking.
An engineer doesn't become senior because they shipped features that worked. They become senior because they debugged what didn't work. They researched root causes. And in that research, they gained knowledge that tutorials and prompts could never teach.
AI gave me speed. But it took away my ability to understand my own system.
And when production broke, I was helpless.
My New Workflow: The 3-Layer System
I'm not saying don't use AI. The reality is that every organization will expect you to leverage it. But here's what I do now:
1. Architecture Layer (Me)
I design the logic myself. I write it out. I understand the flow before a single line of code is written.
2. Boilerplate Layer (AI)
AI generates UI scaffolding, repetitive code, and placeholder methods. The boring stuff.
3. Ownership Layer (Me)
I fill in the critical logic manually. I review every AI-generated line. And I don't ship anything I can't explain to someone else without looking at the code.
The One Rule:
If you can't explain the logic without looking at code, you don't understand it enough to ship it.
The Uncomfortable Truth
In five years, there will be two types of engineers:
- Those who use AI to move faster on problems they understand
- Those who use AI to avoid understanding problems at all
Only one of these survives when production breaks at 3 AM.
AI is a tool. But if you're not careful, it becomes a crutch. And when that crutch is taken away, you realize you never learned to walk.
Where I Am Now
I'm still debugging the audio issue. But this time, I'm doing it right—manually coding it, understanding it, owning it.
The app ships slower now. But when it breaks, I know exactly where to look.
And that's worth everything.
Because building with prompts will get your work done. But you won't grow as an engineer.
The speed is tempting. But speed is worthless if you're sprinting in the wrong direction.
Final thought: Don't just ship features. Own your logic. Understand your system. Because the moment production breaks and AI can't save you, the only thing standing between you and disaster is whether you actually know what your code does.
Choose wisely.
PS: Enjoy a screenshot of my claude convo
Top comments (0)