The problem that started everything
A close friend in medical school was drowning in revision schedules. He'd tried Notion, Google Calendar, Anki, nothing clicked. He needed something offline, fast, and built specifically around spaced repetition for studying.
I'm technical enough to understand code, but I'd never built a desktop app. Learning Electron, React, TypeScript, and SQLite from scratch would take months — time I didn't have.
So I made a bet: could I build this entire app using AI coding assistants?
Three months later, MaestrOS exists. It's a fully functional cross-platform study scheduler with 2,500+ lines of production code, and my friend uses it every day.
Here's what actually happened when a non-expert tried to build software with AI.
What I built
MaestrOS is a desktop app (Windows/Mac/Linux) that helps students organize study sessions using spaced repetition — the technique where you review material at increasing intervals (1 day, 3 days, 7 days, etc.) to maximize retention.
Core features:
Spaced repetition scheduling algorithm
5-level mastery system (tracks what you know vs. need to review)
Offline-first (your data stays local, no cloud required)
Optional Google Calendar sync
Gamification (streaks, achievements, progress tracking)
Tech stack:
Electron 38 + React 18 + TypeScript
SQLite (via better-sqlite3) for local database
Tailwind CSS for styling
electron-builder for cross-platform packaging
GitHub: https://github.com/0xLysandre/MaestrOS
My AI-assisted workflow
I used Claude throughout the entire project — primarily Claude Opus 4.5 for complex architecture and logic, and Claude Sonnet 4.5 when I needed faster iterations on simpler tasks.
Here's my actual process for each feature:
Step 1: Describe what I want (in plain language)
Me: "I need a React component that displays a weekly calendar view.
Each day should show tasks scheduled for that day. Tasks should be
color-coded by mastery level (1-5). Clicking a task should open
a modal to mark it complete."
Step 2: Claude generates the code
Claude would give me:
The React component structure
State management logic
CSS styling (Tailwind classes)
Event handlers
Step 3: I read the code (even when I don't fully understand)
This was critical. I'd ask follow-up questions:
Me: "Why did you use useCallback here?"
Claude: "Because the function is passed as a prop to child components..."
Even if I didn't get it 100%, I'd learn something.
Step 4: Test in the app
Copy, paste, run. Most of the time it worked. Sometimes it didn't.
Step 5: Debug with Claude when it breaks
Me: [pastes error message]
TypeError: Cannot read property 'map' of undefined at Calendar.jsx:47
Claude: "The issue is that 'tasks' is undefined when the component
first renders. You need to add a conditional check..."
This cycle repeated hundreds of times over three months.
What worked incredibly well
- Generating boilerplate and setup The initial Electron + React + TypeScript setup is painful if you've never done it. Claude did it in minutes. I would've spent days googling Webpack configs and build scripts.
- Learning by doing (faster than tutorials) Instead of watching 10 hours of Electron tutorials, I just started building. When I hit a wall, I asked Claude to explain. I learned React hooks, SQLite schemas, and IPC communication through real problems, not abstract examples.
- Debugging cryptic error messages Electron errors are notoriously obscure. Claude was brilliant at this: Error: Electron Security Warning (Insecure Content-Security-Policy) I had no idea what this meant. Claude explained it, gave me the fix, and taught me why it mattered for security.
- Implementing algorithms I barely understood The spaced repetition algorithm is based on SM-2 (SuperMemo 2). I read the Wikipedia page and understood maybe 40% of it. I described what I wanted to Claude, it generated the logic, and I tested it until it worked correctly. Did I fully understand the math? No. Did it work? Yes.
What didn't work (and frustrated me)
- Even Claude makes mistakes with rapidly-evolving frameworks Claude would occasionally suggest Electron patterns that worked in version 32 but had changed by version 38. The framework moves fast, and even the best AI can lag behind the latest updates. Lesson: Always cross-reference with the official docs when something feels off, especially for version-specific APIs.
- Security suggestions were sometimes dangerous Claude once suggested a configuration that would've made IPC communication easier but created a security hole. I only caught it because I'd read Electron's security checklist. Lesson: Never trust AI on security. Read the framework's security guide yourself.
- AI doesn't understand architecture Claude is great at "build this component" but terrible at "how should I structure this entire app?" I had to figure out:
Should state live in the main process or renderer?
How do I organize the database schema?
What belongs in a service vs. a component?
Claude gave me options, but I had to decide.
- Performance issues took real debugging The app worked but was slow (2-second load time, laggy calendar). Claude suggested fixes that didn't help. I had to profile the app myself, read about lazy loading, and implement optimizations manually. Lesson: AI writes code that works, not code that's fast.
What I actually learned
Here's the thing: I didn't become an expert. But I'm no longer completely lost.
What I understand about Electron (sort of)
I can now:
Explain the difference between main process and renderer process (even if I still mix them up sometimes)
Follow the security checklist without breaking things
Package the app for different platforms (though I still don't understand half the electron-builder config)
Navigate the docs when something breaks
Do I really understand Electron? Not deeply. But I understand it enough to fix bugs and add features.
What I understand about React
I can:
Build components that work
Use hooks without completely breaking things
Debug when the UI doesn't update
Copy patterns from the codebase and adapt them
Could I architect a React app from scratch? Probably not. Can I maintain this one? Yes.
What I understand about SQLite
I know:
How to write basic queries
When to add an index (when things get slow)
Why better-sqlite3 worked when sqlite3 didn't
How to not corrupt the database
Am I a database expert? Hell no. But the data persists and queries are fast enough.
The honest truth
I didn't master these technologies. I learned just enough to be dangerous.
But here's what matters: the app works. My friend uses it daily. Other students are using it too.
I can add features. I can fix bugs. I can read error messages and figure out what broke.
Is that "real knowledge"? Maybe not by traditional standards. But it's useful knowledge.
And I got there in 3 months instead of never starting because the learning curve felt too steep.
The uncomfortable truth
Some people will say "you didn't really build it, the AI did."
Here's my response: Claude wrote the code. I built the product.
I decided:
What features to build (and which to cut)
How the UI should work
What data to store
When something was "good enough" vs. needed refinement
How to prioritize based on real user feedback
Claude was my typing assistant, not my brain.
It's like saying an architect "didn't really design the building" because they used CAD software instead of drawing by hand.
If you want to try this yourself
Here's my advice:
- Pick a real problem Don't build a todo app. Build something that solves an actual problem for someone you know. You'll stay motivated, and you'll get real feedback.
- Start small, iterate I didn't build all of MaestrOS at once. I started with "display a list of tasks." Then "add a task." Then "mark complete." Each feature built on the last.
- Read the code AI generates Don't just copy-paste blindly. Skim it. Ask "why did it do this?" Even if you only understand 60%, that's better than 0%.
- Master the conversation with your AI I learned that Claude responds better when you:
Give context upfront ("I'm building an Electron app with React...")
Ask it to explain WHY, not just HOW
Show it error messages in full
Ask for alternatives when the first solution doesn't work
The quality of your output depends on the quality of your prompts.
- Embrace the gaps in your knowledge I still don't fully understand TypeScript generics. I still mess up async/await sometimes. That's okay. You don't need to be an expert to ship.
- Keep a "things that work" doc When you solve a tricky problem, save the solution. I have a Notion doc with ~50 snippets I reused throughout the project.
The result
My friend uses MaestrOS every day. It helped him pass his exams. Other medical students have started using it too.
I didn't become a "real developer" (whatever that means). But I built something real, learned a ton, and proved you don't need to spend years mastering a tech stack before you ship.
If you're hesitating to use AI because it feels like cheating — stop. It's just a tool. A very powerful one.
The code is open source: https://github.com/0xLysandre/MaestrOS
And if you want to see the detailed process of how I did this (with actual prompts, architecture decisions, and lessons learned), I'm documenting everything in a course. Drop a comment if you're interested.
Questions I expect in the comments
"How long did it actually take?"
~3 months, working 5-10 hours per week. Probably 120-150 hours total.
"Could you have done this without AI?"
Technically yes, but it would've taken 6-12 months and I probably would've quit.
"What's the hardest part AI couldn't help with?"
Deciding what to build. Claude can't tell you what features matter or what your users actually need.
"Why only Claude? What about ChatGPT/Cursor/Copilot?"
I tried others early on but found Claude better at understanding context over long conversations. For a months-long project, that continuity mattered.
"Do you feel like a 'fake' developer?"
No. I shipped a real product that solves a real problem. That's more than most developers do.
What do you think? Is using AI to build software "real development" or not? I'm genuinely curious to hear different perspectives.
PS: Shoutout to Anthropic for building Claude. This project literally wouldn't exist without it.
Top comments (0)