I have been curious about “vibe coding” ever since I heard about the process, even though I hate the name. I started by using Claude Desktop with MCP tools to build a code project from scratch and it felt like magic. That was until I discovered Claude Code and my workflow got so much easier and less chaotic right away.
This post documents my adventure so far, using Claude Code to build an Electron writing app. I made a few mistakes and am still making them, but corrected them and think I am on a better path now. I doubt it’s the right path, but I’ll keep tweaking it until it works for me.
Table of Contents
- Vibe Coding with Claude Desktop and MCP
- Features of Claude Code that Made Me Switch
- Installing and Using Claude Code
- Building a Project from Scratch with Claude Code
- The Pain of Refactoring with Claude Code
-
My Current
CLAUDE.md
file and Coding Process - Lessons I Learned Using Claude Code
- Features of Claude Code I Haven’t Tried Yet
- Claude Code Tips From Others I Plan on Trying
- What Claude Code Built: Screenshots of My app
- My Journey with Claude Code Continues
Vibe Coding with Claude Desktop and MCP
When I was using Claude Desktop to write code, I always felt like I was using workarounds to plan and organize. I started out with a standalone chat, but eventually got cut off and had to start a new chat to continue working on the app. So I switched to using a Claude Project.
Working on the app in a Claude Project made things a little easier by allowing me to upload 50 reference documents, but that was a mess, because the project was always changing and I had to delete and re-upload changes to documentation all the time. I could have also tried connected to the project’s Github repo or simply putting the documentation in a folder in the local project.
But around that time, I ran into Claude Code, read up on it, and figured it would work better for what I needed, so I started a new project with it. I might go back to the first project with a better plan, because I was making progress.
Features of Claude Code that Made Me Switch
I am using to a command-line interface. I use it them all the time. It feels like I am doing work. In chat, I feel like I am getting nagged by a sales bot on an e-commerce site or arguing with customer service. I get it makes no sense, but the command-line interface was a big feature for me.
Another significant feature is the CLAUDE.md
file , which Claude Code which holds your project memory. You can add things to it, like:
- Build/Lint/Test Commands
- Code Style Guidelines
- The SDLC process you want to use
- Reference other documentation on the project
This means I can keep its memory in the project, instead of project files. When I first started working with Claude, I started setting up MCP connections like I did with Desktop. Gut then realized I was wasting my time and adding overhead, because the functionality I was getting by adding MCPs to Claude Desktop was already built into Code.
I could see adding a database connection MCP in the future if I work on a project that has one, but right now I am not using any with Claude Code. Claude Code has a lot more features than the three I listed here and I will get to them later, but these were all the reasons I needed to make the switch.
Installing and Using Claude Code
I have to admit that I basically ran the code to install Claude Code, ran the init command in a new project folder, and starting playing with it. Writing this, I figured I should dig deeper into its documentation to make sure I missed nothing. And I missed a few things that might have made this entire process smoother.
Requirements
- Operating Systems : macOS 10.15+, Ubuntu 20.04+/Debian 10+, or Windows via WSL
- Hardware : 4GB RAM minimum
- Software :
One thing I missed there was installing ripgrep
for advanced search. Maybe that will make things quicker? I did not install it until I started writing this, so maybe that is why things seem to take longer than they needed.
Installing and Initializing
To get started, run this command to install Claude Code globally:
npm install -g @anthropic-ai/claude-code
Then navigate to your project’s folder and run:
claude
After Claude Code started, I ran the following command to generate the CLAUDE.md
file:
/init
Building a Project from Scratch with Claude Code
I wasn’t sure I could do this because all the examples online were working with existing codebases and I wanted to start one from scratch. So I asked Claude, and it said I could.
And I decided I would build an Electron app. A writing app. Yeah, I know. Like we need another one of those. But it was something I had always wanted to do and have been collecting a list of features over the years, which only made the odds I would ever get to it worse.
And, of course, you can’t make a writing app these days without including AI, so I am using AI to write an AI writing app. And with all the middlemen in the AI world, I figured I would make it so you just enter your LLM API keys and get started. The app would be completely self-contained in an Electron desktop app. For now, at least.
But if I were going to start over, I would start with more of a plan. I basically pointed Claude Code to the features of other similar apps and told it I wanted to build an Electron app with similar features.
As I chatted with Claude Code and worked on the app for the first couple of hours, I just let it update CLAUDE.md
with the project details.
The Pain of Refactoring with Claude Code
I was learning my mistakes as I went. The one I learned quickly was to not only plan features, but plan the architecture that the features will work in. Think ahead. By the time I had an app where some features were working enough to be useful, I decided I should have used a plugin architecture.
I realized this architecture would work better for what I was doing when I was adding a context menu for the editor. When you right click in an editor, there are many things you can have it do, but when you add a new action, you are basically just adding another item to that menu that runs a new function when it is clicked.
Now I also think this type of architecture could be useful when using Claude Code to create an app like this. Have it build the core system and add a well-defined interface for plugins to interact with the core. Then build all the features as plugins. I think that this would keep the context lighter because Claude could use the plugin API docs to build the features instead of searching and parsing everything all the time.
But moving toward an architecture like that later in the game is hard. My first attempt to globally change things in the project was successful, but it took quite a while. And I still have a way to go. So, currently I am looking through the code base to see what all has to change for the complete refactor to happen. That way, when I tell it to refactor, I can give it some guidance and know what to expect when it does it right.
My Current CLAUDE.md
file and Coding Process
For the first few hours, I just told Claude Code to build new features and keep track of where it was at in the CLAUDE.md
file. But after a while, I knew I had to rein it in. Here are the sections I have in my CLAUDE.md
file currently, which has changed often and will continue to:
How to Use This File
When I decided to refactor the CLAUDE.md
, I had some ideas, but also asked Claude Code what would work. It suggested this section. Here’s what it has in it:
- This file contains essential project information
- Detailed documentation can be found in referenced files
- Update both this file and referenced files when making changes
Project Overview
EmberText is an AI-powered desktop writing application built with Electron, React, and TypeScript. It combines features from TypingMind, NovelCrafter, SudoWrite, and Scrivener.
Key Requirements
- Projects must be stored as markdown files in a folder structure (similar to Obsidian)
- Each chapter should be saved as an individual markdown file
- Project metadata and structure should be stored in a JSON file within the project directory
- The app should be able to open and edit these files directly, enabling compatibility with other markdown editors
- Help a writer complete a project with AI or other tools from idea to ebook publishing
Important References
I had everything in my CLAUDE.md
file to begin with, but it quickly got huge. So I thought about how to trim it down. I also asked Claude Code what should be in the file versus what it could access on an as-needed basis. There is the concept of imports, but I didn’t want to use that because I would essentially do the same thing, but putting this massive amount of information in multiple files that still got read every time I ran Claude Code.
So I created a project knowledge base folder and put everything that it wouldn’t need every time there and add an “important references” section in CLAUDE.md
. Here’s what I have in this section:
- Code Project Structure: knowledge_base/project/structure.md
- Writing Project Structure: knowledge_base/project/directory-structure.md
- Key Features: knowledge_base/project/key-features.md
- Potential Feature Ideas: knowledge_base/feature-ideas
- Features Ready for Development or Already Developed: knowledge_base/features
Code Style Guidelines
- Formatting : Use 2-space indentation, single quotes, no semicolons
- Imports : Group imports (node builtins, external, internal)
- Types : Use TypeScript with explicit return types on functions
- Naming : camelCase for variables/functions, PascalCase for classes/components
- Components : One component per file, match filename to component name
- Error Handling : Use try/catch blocks with specific error types
- Functions : Prefer pure functions, avoid side effects
- Testing : Write unit tests for all new functionality
Project SDLC
As I was working on the project, I decided to “formalize” the development process, so that Claude Code knew what steps I wanted it to take. Here is what I have in this section:
- New features will be picked from “Key Features” in knowledge_base/project/key-features.md when “Next development steps” is empty. Once those are done, they will be sourced from knowledge_base/feature-ideas.
- I will ask you to think about the features and you will create notes about the feature in a markdown file named after it in knowledge_base/features. This file will be used as reference when we update a feature or fix bugs. The file will be kept updated with the feature changes.
- You will then reference the file next to the feature in “Next development steps” like this: “Add workshop chat: knowledge_base/features/AddWorkShopChat.md”
- I will ask you to do the next task in “Next development steps”. You will work on it and tell me when it is done, asking any necessary questions along the way.
- When that is done, you will move the feature from “Next development steps” to “Current progress” and make sure to move the reference to the note in knowledge_base/features to it.
- You will also update “Key Features” in knowledge_base/project/key-features.md if anything changed there.
- Update the project structure in knowledge_base/project/structure.md and writing project structure in knowledge_base/project/directory-structure.md when necessary.
- You will add testing the feature to “QA Checklist”
Build/Lint/Test Commands
- Install:
npm install
- Start:
npm start
(builds main and renderer processes and starts Electron)- Dev:
npm run dev
(development mode with live reload)- Build Main:
npm run build:main
(TypeScript compilation for main process)- Build Renderer:
npm run build:renderer
(Webpack bundling for renderer)- Test:
npm test
- Lint:
npm run lint
- Format:
npm run format
Development Status
This is a list of features it has already implemented. Just a simple description of the feature and the path to the feature plan file. More details on the feature plan file below.
Next Development Steps
This is a list of features I told it to put here. I usually have 3-4 features in this list. When I tell it to add a feature, I have it “think hard” about how to implement it, create a file in my project knowledge base folder that details how the feature will be implemented, and add it to this list like this:
- Implement scene scaffolding system: knowledge_base/features/SceneScaffolding.md
That gives me a chance to look it over before it implements it. I am also hoping it follows my instructions and only references those files when dealing with that specific feature to keep unnecessary information out of the context. The files it creates are pretty extensive and have the following headings:
- Overview
- Key Requirements
- User Interface Components
- Data Structures
- Components to Create
- AI Integration
- User Experience Flow
- Integration with Existing Features
- Implementation Plan
- Dependency Notes
- Testing Requirements
- Future Enhancements
QA Checklist
Claude Code will add items to this list when it has finished a feature. It’s actually a reminder for me to test new features, so it probably doesn’t need to be in the file. For now, though, it keeps me from forgetting to test things and it doesn’t take that much space.
Lessons I Learned Using Claude Code
I learned most of these lessons after making many mistakes:
- Plan well: This is a lesson I keep learning over and over. But I still jumped right into this project without much of a plan. All I had was Electron and a list of features. I should have thought more about architecture at the beginning instead of refactoring a few hours in.
- Stop and look at the project holistically often: Especially if you don’t plan well. I knew I wanted AI to help write a book at every step, from idea to ebook, but I sort of just let it do what it wanted. And by the time I realized the AI functionality could be a modal used in multiple places, it put AI forms in three or four different places.
- Tell Claude Code to “think harder” when you are planning feature: This is the third lesson that involves “planning.” Notice a pattern. When you tell Claude to “think”, it triggers Claude’s extending thinking and when you tell it to “think harder”, “think a lot”, or “think more”, it triggers deeper thinking.
- Do your own git commits: I didn’t think that Claude Code would commit code without explicitly telling it to do so, but now and then it would. And each time, it was when I wanted to be done for the night and, of course, the code was broken. So I spent more time having it fix the code, so that I could commit working code. I could have reverted, but it had just added a new feature, which I knew was at least partially working.
- QA and review the UI often: Claude will forget things. It will think hard about a feature, create a plan, work on it, tell you it is done, and forget 20% of the features. It was really hard for me to stop adding shiny new things to the app to do mundane testing, but I eventually had to backtrack through a lot of things and fix bugs.
Features of Claude Code I Haven’t Tried Yet
I jumped right into this project without reading 95% of the docs. But I figured I should at least peruse them before I wrote this. Here are some things I ran into, not covered by this article, you might want to check out:
-
Free Claude Code with Claude Max: I may or may not try this in the future. If you pay for the $100/month Claude Max subscription, Claude Code comes along with it. In my estimation, when I am working with Claude Code, it costs me around $5 an hour and with my limited time, I have only used about $50/month so far with the API. Maybe with
ripgrep
installed, the process will go faster and cost me more per hour. - Use Claude Code as an MCP server: Thought this was cool, but then wasn’t sure what I would use it for.
-
Create custom slash commands: You can create a
.claude/commands
folder in your project to hold commands you use over and over. You can also design these commands to accept arguments.
Claude Code Tips From Others I Plan on Trying
I work on projects like this and write articles about them in the evenings when I don’t have freelance writing work and in the last two weeks I haven’t been able to touch this project. But I still looked for tips whenever I could and took notes on them. Here are some things I plan on trying in the future:
- Manage compacting more effectively: I noticed that Claude Code mentioning something about compacting context and providing a percentage. Now, with further research, I’ve learned that Claude Code will compress the conversation history to stay within the context window’s limits. I found this post on Reddit about always doing compacting manually. For example, before you are about to start on a new feature. Because, I guess, auto compacting can really screw you if it happens at the wrong time.
- Leverage other LLMs and repomix or code2prompt: The refactoring process was a pain. Fixing bugs was a pain. Redditor squareboxrox mentioned using these tools to upload your whole project to another LLM when you run into the inevitable bug fix rabbit hole, instead of saying “still not fixed” over and over. Not every bug is like this. Maybe 20%. But I figured I’d give this method a try
What Claude Code Built: Screenshots of My app
Disclaimer: These screenshots showcase the functional aspects of EmberText rather than polished design. As this project focused on testing Claude Code’s capabilities for rapidly building functional features, I prioritized getting core functionality working over UI refinement. Consider these a “developer preview” of what’s possible with AI-assisted coding.
Dashboard
The home screen showing multiple writing projects with their structure and metadata. Claude Code implemented the card-based layout and project metadata tracking.
Settings
Settings panel for connecting to various AI models. This shows how Claude Code implemented form validation and API connection management.
Writing Interface
The main editor with project structure sidebar and formatting tools. Note the line-numbered editor and structure navigation that Claude Code implemented based on my requirements.
Character Relationship Graph
An interactive visualization showing connections between characters. This feature shows Claude Code’s ability to integrate complex visualizations using React.
I’m impressed by how quickly Claude Code could assemble a functional writing application with complex features like relationship graphs and structured document editing. While the UI would benefit from refinement, the core functionality is there and working as intended after just 16 hours of development time.
My Journey with Claude Code Continues
After spending about 16 hours and $80 in API costs, I’ve built a writing application with some functionality. My app currently:
- Connects to Claude and Open API
- Generates text and dialogue
- Creates outline and plot structures
- Has a plot timeline
- Has a character relationship graph
- Adds location, character, and item context to API calls
The refactoring process I described earlier was painful enough that I have temporarily paused development to reorganize my project memory files and carefully plan upcoming features. It has also reinforced the biggest lesson I learned: planning saves significant time and frustration with AI-assisted development.
What I’ve Learned
The most valuable lesson from this experiment is that Claude Code does well when given clear direction and architecture upfront. While it can adapt on the fly, major architectural shifts are still painful, much like traditional development, just faster.
My approach now combines the benefits of AI coding with disciplined software design: I plan thoroughly, create detailed feature specifications, and only then engage Claude Code to implement them.
What’s Next
- Complete my writing app : Once I’ve implemented the remaining AI helpers, I’ll test the application with a real book project. Since I built this tool primarily for myself, this test will be the accurate measure of success.
- Explore smaller projects : The development speed has inspired me to tackle several smaller ideas in parallel. With proper planning, I could potentially complete 2-3 modest apps in the same time it would typically take to build one.
If you’re interested in trying Claude Code yourself, I recommend starting with something small and well-defined. The initial time investment in proper planning and documentation pays dividends in development speed and reduces frustrating rework.
I’ll be documenting more of this journey as I continue exploring AI-assisted development.