This post contains Amazon affiliate links. If you make a purchase through these links, I may earn a small commission at no extra cost to you. See Privacy Policy for details.
The moment I opened the Rust code of my own app, my mind went blank. I couldn’t read a single line.
Just recently, I had written a triumphant post about building 5 apps with vibe coding. I’d concluded with: “In this era, if you can put your problems into words, they become products.” I still believe that. But what I faced after writing that post was a far more fundamental problem.
I couldn’t read my own app’s code.
I Couldn’t Read a Single Line of Rust
Tannin Techo is the most sophisticated app I’ve built — a classroom management tool for homeroom teachers, built with Tauri 2.0 (React frontend, Rust backend).
One day, I got curious and opened the src-tauri/src/ directory.
pub fn encrypt_data(data: &[u8], password: &str) -> Result<Vec<u8>> {What’s &[u8]? What’s Result<Vec<u8>>? I couldn’t parse even the first line of a function.
Scrolling further revealed an endless stream of unfamiliar symbols: 'a, &mut, Option<T>. Fourteen Tauri commands, encryption logic, database operations — all written by AI. All part of “my app.” But I couldn’t explain a single line on my own.
It was a strange feeling. Like owning a house but not being able to read the floor plans. Like driving a car but having no idea what’s under the hood.
The Security Audit That Revealed My Limits
The real fear came during the security audit.
Tannin Techo handles student data — names, attendance, grade notes. It’s all personal information. So before release, I ran a security check. Several issues were flagged:
- Insufficient CSP (Content Security Policy) configuration
- Missing database transaction handling
- Inadequate file path validation (path traversal risk)
- Password requirements needed strengthening
AI could fix all of these when I said “fix it.” And it did. But I didn’t understand any of it.
“What is CSP?” “What’s a path traversal attack?” “What happens without transactions?”
I compared the code before and after the fixes but couldn’t tell what had changed. AI said “done,” and I said “thanks.” That’s all I could do.
I’m building an app that handles students’ personal information, yet I can’t judge its security on my own. As a teacher, isn’t that irresponsible? The moment that thought hit me, a chill ran down my spine.
The Reversal: Building Before Learning
Yet this experience was also a turning point.
The Traditional Path: Learn, Then Build
The standard way to learn programming:
- Buy a textbook
- Learn basic syntax
- Solve practice problems
- Build a small project
- Gradually scale up
Orthodox. Well-trodden. But I’ve dropped out of this path multiple times. When I tried C in university, I lost sight of “what’s the point?” and quit. I’d lose my purpose during the fundamentals stage.
My Path: Build, Struggle, Learn
My path was completely reversed:
- Build apps with vibe coding
- Have working products in hand
- Realize I can’t read the code or judge security
- A concrete motivation to learn is born
- Know exactly what I need to study
As a teacher with over a decade of experience, this “reversal” felt familiar. It’s the same in the classroom. When students experiment first and then explore “why did that happen?”, their eyes light up differently than when you teach theory before the experiment. When experience comes first, theory becomes confirmation. The depth of understanding is incomparable.
I’m in that exact state right now. “I can’t read my own app’s Rust code” has become the most powerful motivation to learn Rust.
I Bought Three Books
So I went to the bookstore and bought three books.
The Art of Readable Code — What Makes Code Readable
The first is a classic on writing clean, readable code — practical techniques for making code easier to understand.
“But you don’t even write code,” you might think. Fair point. I don’t write code. But I need the ability to judge whether AI-generated code is good or bad.
Are the variable names appropriate? Are the functions too long? Are the comments helpful? Even when telling AI to “make it more readable,” I can’t give that instruction without knowing what “readable” means.
The Elements of Computing Systems (Nand2Tetris) — Understanding the Magic
The second starts from NAND gates — the simplest logic circuits — and builds up to a complete computer that can run Tetris.
I chose this because computers are still a “magic box” to me. I write code (or have AI write it), press a button, and things work. But I don’t understand why they work.
My inability to understand the security audit traces back to this. Without knowing what memory is, what processes are, how data is stored — I can’t truly grasp why certain code patterns are dangerous.
Programming Rust, 2nd Edition — Understanding My App’s Language
The third is a Rust textbook. This had the most direct motivation: my app’s backend is written in Rust.
Rust’s defining feature is “ownership” — ensuring memory safety at the language level by making data ownership explicit. This connects directly to the security issues flagged in the audit.
Why is Rust considered safe? Why are & and &mut necessary? Why is the compiler so strict? To “read” my own app’s code, this book was unavoidable.
What’s Already Changing
Honestly, I’ve barely started all three books. I’m far from mastering anything. But I already feel a difference.
The Resolution of “Aha” Moments Is Completely Different
Reading The Art of Readable Code, I encountered a chapter about using meaningful names instead of abbreviations. A typical beginner might think, “Sure, makes sense,” and move on.
But I’ve seen variables like enc_data and tmp_val throughout my own app’s code. They actually exist in the AI-generated code. So it clicks immediately: “That’s exactly what’s happening in my code!” It’s not a textbook example — I can feel it in my own project.
The same happened with Rust’s ownership chapter. “Every value has exactly one owner.” Abstract on its own, but when I look at the code that encrypts and stores student data in Tannin Techo, it clicks: “Ah, that’s why it’s written this way.”
When experience comes first, theory becomes knowledge with a pulse.
I’m Not Rejecting Vibe Coding
Some might think, “So vibe coding doesn’t work after all.” Not at all. I have zero intention of retracting my previous post.
Without vibe coding, I couldn’t have built five apps. I’d still be doing seating arrangements by hand, wasting energy on travel expense calculations, and worrying about student data management. Vibe coding genuinely changed my work.
But vibe coding has a next stage.
Stage one is “the power to articulate.” Putting your problems into words and communicating them to AI. This alone lets you build working apps.
Stage two is “the power to understand.” Reading AI-generated code, judging its quality, evaluating its security. This lets you take responsibility for what you’ve built.
I’m currently transitioning from one to two. My previous post was “a report from reaching stage one.” This post is “a departure report for stage two.” Not rejection — evolution.
Conclusion: When You Have a Reason, You Can Learn
If I had to sum up why I bought three books: “Because I have my own apps.”
The biggest barrier to learning programming is not seeing what you’re learning it for. Memorizing syntax is pointless if you can’t see where it leads. That’s exactly what happened when I gave up on C in university.
But now I have reasons:
- I want to read the Rust code of Tannin Techo
- I want to judge security on my own
- I want to evaluate AI-generated code quality
Every motivation was born from building apps. Learning while thinking “maybe I’ll use this someday” versus “I need this right now” — the absorption rate is worlds apart.
Building is planting seeds. Learning is watering them. Without seeds, there’s nothing to water. But without water, seeds won’t sprout.
I planted seeds with vibe coding. And now, I’ve started watering.
I don’t know how far they’ll grow. But at least I know clearly what I want to grow. That alone makes learning enjoyable.
See ya!