This is a great breakdown of how many people are already using @DevinAI today.

It combines DeepWiki (a living architecture map auto-generated from your code with diagrams, dependency graphs, and symbol navigation) with Devin Review (automated PR analysis that catches bugs, security issues, and flags affected APIs and tests in every diff).

It runs continuously in the background, auto-reviewing every PR and wiring into services like Datadog and Sentry so that when a crash report or alert fires in production Devin automatically investigates and opens a fix PR. By the time you open a PR to review it Devin has already done the analysis so you’re never looking at unreviewed code.

https://docs.devin.ai/work-with-devin/deepwiki#deepwiki…

DeepWiki - Devin Docs

Source: https://docs.devin.ai/work-with-devin/deepwiki

Overview

Devin now automatically indexes your repos and produces wikis with architecture diagrams, links to sources, and summaries of your codebase.Use it to get up to speed on unfamiliar parts of your codebase - check it outin your sidebar.Ask Devinwill use information in the Wiki to better understand and find the relevant context in your codebase. Ask Devin’s advanced code search capabilities, combined with DeepWiki, produce detailed and accurate answers grounded in your code.

For Public Repos

A free version ofDeepWikiandAsk Devinthat works with public GitHub repositories is now available. It automatically generates architecture diagrams, documentation, and links to source code to help you understand unfamiliar codebases quickly. You can also ask complex questions about the codebase to get context-grounded specific answers.

Visitdeepwiki.comto start exploring popular open-source repositories like React, TensorFlow, LangChain, and many more. You can also submit your own public GitHub repository URL for indexing.Try DeepWiki Now →

Steering DeepWiki

The\.devin/wiki\.jsonfile allows you to steer Devin’s default wiki generation behavior, which is especially important for large repositories that may hit built-in limits.If a\.devin/wiki\.jsonfile is found in your repository’s root directory during wiki generation, we’ll use the providedrepo\_notesandpagesto steer wiki generation. Ifpagesis provided, we’ll bypass the default cluster-based planning and create exactly the pages you specify. This ensures that the important parts of your codebase are documented even when the automatic system would otherwise skip them.

Configuration Format

Create a\.devin/wiki\.jsonfile in your repository root with the following structure:

Configuration Options

repo_notes (Array)

Provides context and guidance to help the documentation system understand your repository better.

• content(string, required): The note content (max 10,000 characters)
• author(string, optional): Who wrote the note

pages (Array, optional)

Specifies exactly which pages should be created in your wiki.This field is optional. If you only include repo_notes, the system will still generate a wiki, using your notes to guide the structure and focus without requiring you to outline every page.When you do provide pages, they are treated as explicit instructions. Only the pages you define in the JSON will be generated, no more, no less.

• title(string, required): The page title (must be unique and non-empty)
• purpose(string, required): What this page should document
• parent(string, optional): Title of the parent page for hierarchical organization
• page_notes(array, optional): Additional notes specific to this page

Validation Limits

• Maximum 30 pages (80 for enterprise)
• Maximum 100 total notes (repo_notes + all page_notes combined)
• Maximum 10,000 characters per note
• Page titles must be unique and non-empty

Practical Examples

Example 1: Repo Notes to Guide Wiki Generation

If you prefer not to define specific pages, you can provide only repo_notes to help guide the wiki generation. This allows Devin to create the documentation structure automatically while still taking into account your priorities and areas of focus. This is useful when you want better coverage and emphasis without having to explicitly outline every page yourself.

Example 2: Ensuring Specific Folders Are Documented

If your large repository has important folders that aren’t being included in the wiki, explicitly specify them:

Example 3: Addressing Missing Components

If you notice certain parts of your codebase aren’t being documented:

Example 4: Hierarchical Documentation Structure

For complex repositories, organize pages hierarchically:

Best Practices

1. Use Repo Notes Strategically

• Provide context about which parts of your codebase are most important
• Mention specific folders or components that should be prioritized
• Explain relationships between different parts of your system

2. Organize Pages Logically

• Start with high-level overview pages
• Use parent-child relationships to create clear hierarchies
• Group related functionality together

3. Be Specific in Page Purposes

• Clearly state what each page should document
• Mention specific directories, files, or concepts to focus on
• Provide enough detail for the system to understand your intent

4. Address Known Gaps

• If you know certain parts of your codebase are being missed, explicitly include them
• Use descriptive titles that make it clear what should be covered

Troubleshooting Common Issues

”Only certain folders are being documented”

This is the classic large repository problem.**Solution:**Use\.devin/wiki\.jsonto explicitly specify which parts of your codebase should be documented.

”Important components are missing from the wiki”

Add specific pages for these components and use repo_notes to emphasize their importance.

Getting Started

1. Create\.devin/wiki\.jsonin your repository root
2. Add repo_notes explaining your codebase structure and priorities
3. If necessary, specifyallpages you want created with clear titles and purposes
4. Commit the file and regenerate your wiki

The system will now create documentation based on your explicit instructions rather than fully automatic analysis, ensuring comprehensive and more accurate coverage of large repositories.

Daniel Steigerwald (@steida): I don’t need a code editor anymore. I need a code observatory.

Something that shows me the structure of the codebase, lets me navigate symbols and references, review diffs and tests, and edit code when I actually need to.

It should continuously review changes in the background,