The Problem with Documentation

Every developer knows this story: You find an interesting GitHub repository, excitedly clone it, and then… spend hours trying to understand how it actually works. The documentation, if it exists, is often outdated, incomplete, or buried in scattered README files.

We’ve all been there. We’ve all also been on the other side — promising ourselves we’ll “document it later” (spoiler: we rarely do).

Enter DeepWiki

DeepWiki started as a closed-source project by DevinAI, aiming to solve this universal developer pain point. The idea was simple but powerful: automatically generate comprehensive documentation for any GitHub repository using AI.

But I believed this solution needed to be accessible to everyone. That’s why I created DeepWiki-Open — a completely free, open-source implementation that anyone can run locally.

How DeepWiki Works

Under the hood, DeepWiki uses a sophisticated pipeline combining multiple AI technologies:

1. Smart Repository Analysis: DeepWiki clones your repository and analyzes its structure, identifying key components and their relationships.
2. Context-Aware AI: Using a combination of Google’s Gemini and OpenAI’s embedding models, DeepWiki understands your code in context, not just as isolated files.
3. Intelligent Documentation Generation: The system generates comprehensive documentation that includes:

• Detailed explanations of code functionality
• Architecture diagrams using Mermaid
• Component relationships
• Setup instructions
• Usage examples

1. Visual Understanding: One of DeepWiki’s most powerful features is its ability to automatically generate diagrams that visualize:

• System architecture
• Relationship Diagrams
• Data flow
• Component relationships
• Process workflows
• Class hierarchies

Why Open Source?

The decision to open-source DeepWiki wasn’t just about making it free. It was about:

1. Accessibility: Good documentation tools should be available to everyone, not just those who can afford expensive subscriptions.
2. Privacy: By running locally, your code never leaves your machine. No need to worry about sensitive code being sent to cloud services.
3. Customization: The open-source nature means you can modify and extend DeepWiki to fit your specific needs.
4. Community: Building in public allows others to contribute, improve, and adapt the tool for different use cases.

Technical Deep Dive

DeepWiki is built with modern technologies:

• Frontend: Next.js 15.3 with React 19
• Backend: FastAPI with Python
• AI Models:
• Google’s Gemini for text generation
• OpenAI’s embeddings for code understanding
• LLM Framework: AdalFlow
• Visualization: Mermaid for diagram generation

The architecture is designed to be modular and efficient:

Getting Started

Setting up DeepWiki is straightforward:

1. Clone the repository
2. Set up your API keys for Google and OpenAI
3. Install dependencies
4. Start the backend and frontend servers

That’s it! You’re ready to generate documentation for any GitHub repository.

The Future of Documentation

DeepWiki represents a shift in how we think about documentation. Instead of viewing it as a burden — something we must write manually — we can leverage AI to:

• Generate baseline documentation automatically
• Keep documentation in sync with code changes
• Create visual representations of complex systems
• Make documentation more interactive and engaging

Join the Revolution

DeepWiki-Open is just the beginning. As an open-source project, its potential grows with every contributor. Whether you’re a developer looking to improve your project’s documentation or an enthusiast interested in AI applications, there’s a place for you in the DeepWiki community.

Check out the project on GitHub: https://github.com/AsyncFuncAI/deepwiki-open

We’ve all been there. You open a promising GitHub repository, eager to understand how it works, only to find yourself drowning in a maze of folders, cryptic naming conventions, and documentation that raises more questions than it answers. Sure, existing AI tools can explain what a function does, but they miss the bigger picture? the why, the how, and the “what were they thinking?”

That’s what makes GitHub Chat different. Instead of just parsing code snippets, it understands repositories as living, breathing projects. I first realized this when I asked it about authentication flow in a complex Next.js project. Rather than spitting out a generic explanation about JWT tokens, it walked me through the actual implementation, pointing out the interplay betweenclient-page.tsx, Supabase integration, and the freemium model considerations.

The magic lies in its ability to connect the dots. When you ask about a feature, it doesn’t just search for relevant code. tl;dr; it understands the project’s architecture, its tech decisions, and even points out commented-out code that hints at future plans. It’s like having a senior developer who was there when the architectural decisions were made.

What’s refreshing is how it handles uncertainty. Instead of making things up (we’ve all dealt with that in other AI tools), it tells you when it needs more context or when certain files aren’t available. It’s honest about its limitations, which, ironically, makes it more trustworthy.

The platform is currently in a freemium period, offering unlimited access to all features. After this period, it’ll shift to a tiered model, but even the free tier gives you enough messages to get meaningful insights about any repository.

For those of us who spend hours trying to understand why a project is structured in a certain way, or what implications a particular pattern might have, this tool feels like a breakthrough. It’s not just another code explainer, it’s a repository whisperer.

The next time you’re staring at a GitHub repository at midnight, wondering how all the pieces fit together, remember: you don’t have to figure it out alone anymore. The repository is ready to talk to you.

Try it at https://github-chat.com. Your future self, bleary-eyed at 3 AM, will thank you.

This post is not to convince you why modularizing your code is the best practice you should follow, because it obviously is the best practice, unless you’re working alone or you’re just simply trying to build a Hello World app to show off your first 🚵 commit on Github.

Modularizing code is similar as decluttering your messy closet. Like your’ dirty laundry, it often piled up before you even realized. You might end up getting stressed trying to find where is doSomething method located and then realized it was in line 2356 of getDoSomething.Something.doSomething() . So much fun, right? 🙌

Let’s begin the CodeMari journey…

Hold on, before we get started, let’s begin with the custom of greeting the [Code]. Close your eyes, think of what your ideal code structure look like…

….

….

Thank you.

Step 1 | Discarding by category comes first. (Categorizing)

• Put all your cluttered 10,000 lines of code on VSCode (make sure it is Dark Theme), start categorizing which method should go where. Example: GeneralUtil, HTTPService, ClientSideService, ThirdPartyService, TwitterClientService…etc.
• You will probably find duplicated code in multiple places, code that only been used once….OR worst, commented code that you might feel too ‘sentimental’ to get rid of.

Step 2 |Break code category into subcategories as necessary.

• KISS (Keep it simple stupid), refactor that huge chunk of chained method into single method. Follow the Single Responsibility Principle, doSomething should not execute doOtherThing , doSomething should not do two things. Lookup Singleton or Factory Design Pattern.
• Sometimes, it can be very tempting to migrate most of the stuff to GeneralUtil, that’s not how you should do it. Doing that is as if you were moving the dirty laundry from current laundry basket to another laundry basket. Put some effort in thinking how to modularize individual modules behind a public interface.

Step 3 |Keep only those codes that spark joy.

• If you can’t relate with the word spark joy , I strongly suggest you ask your tech lead or seniors if those lines of code spark joy for them during code review. You will quickly find out the answer, that i can guarantee.
• Sometimes Joy can be very different depending on individual, for example: One of my senior prefer the AirBnB styling guide, whereas others prefer the Google styling guide. Inline Curly Braces vs New Line Curly Braces; 2 Space Indentation vs Tab Indentation..etc. Bring those problems to All-Hands meeting and let everyone’s hand decide which spark more Joy. Period.

Step 4 | After you’ve finished discarding, commit your code thoroughly and completely.

• Rule №1: Always remember to commit your code after you refactor or discard unwanted code. Also, check all the dependencies, NPMs, Nuget packages (.Net), remember to discard those dependencies that are no longer needed.
• Rule №2: Your local machine is not your trash can, store your stuff in S3, Blob Storage, Google Cloud etc. Reorganize your folder structure so it speed up your productivity again. Last but not least, always have a backup.

Step 5 | Do it all in one go.

• Dedicate a day to do this with your team to prevent yourself being sidetracked by other meetings or bug fixes. I strongly suggest using the MOB programming approach for this.
• DO NOT checkpoint your code thinking you will be back to the same line the next day. Commit Often, Perfect Later, Publish Once, stick with this rule.

Happy CodeMari 🎊 🎊, and stay tuned for more awesome stuff on my blog!