A symbol explains one point, but the questions are more often about connections: in what order the request path executes, how a payment event flows, where the server/client boundary runs. Holding this in your head while reading dozens of files is hard, and here a Codemap helps - a hierarchical map of execution flow and relationships between components, where each node leads to a specific file and function.
The naive move is to ask for a map of the whole repository at once, to "see the system as a whole". It seems that the wider the coverage, the fuller the picture. In practice a map of all the code instantly turns into noise: hundreds of nodes in which the very chain the map was built for drowns. Breadth here works against understanding, not for it.
The naive approach breaks twice. First, a map without a question has no focus and is therefore uninformative. Second, a map, like a symbol explanation, is easy to take for a complete and exact model of the system, whereas it is a generated view for a specific slice, not a proven schema of execution. Nodes are an invitation to go into the code and check, not a final truth.
The professional technique is to build the map around one question and to state it before generating. "The request path from route to a database write", "the payment event flow from click to confirmation", "the server and client boundary in this module" - each such wording gives the map a root, boundaries and a criterion for what is extraneous. A narrow map answers; a wide one only enumerates.
The mechanics are worth knowing precisely. A map is created in one of three ways: pick a suggested topic based on recent navigation, enter your own prompt, or generate from a conversation with the agent. Each map opens as a separate editor tab, the nodes are clickable and jump straight to the file and function, and a finished map can be turned into a link and sent to a colleague. Unlike a symbol explanation, a map shows not a single point but the order and direction of connections, so the question put to it is about a route, not about a separate name.
The link has a cost worth knowing in advance. Shared maps are stored on Devin's servers and by default require authentication, and for enterprise access to such sharing is enabled separately, opt-in. That is, "sharing a map" is not a local action but carrying part of the code's structure off the machine; for a sensitive repository this is a decision, not an interface trifle.
Why the map is built as a view for a question rather than an auto-schema of everything. The model builds the hierarchy from retrieved context and your recent navigation, not from exhaustive static analysis; it shows the likely order and connections well but does not guarantee that every path was accounted for. This is the same trade as with DeepWiki: speed and overview instead of completeness. It pays off exactly as long as the map is used as a table of contents to the code, not as a replacement for the code.
The cost of inattention shows in two forms. A map of the whole repository spends generation and attention and gives no answer. A map taken for proof leads to conclusions about execution order that no one checked against the real code - and a mistake in understanding the flow later surfaces in an edit built on it. It is especially frustrating when a wide map is built at the start of work on an unfamiliar module: that is exactly where a precise route is needed, and what you get is a list of everything the module touches.
A dated caveat about versions. At the snapshot two changes are worth remembering: in stable 3.6.21 @-mentions of Codemaps appeared in Devin Local, and in 3.7.16 maps and the MCP config open correctly from a remote machine - over WSL, SSH and a dev container. The availability of a specific capability depends on the version you run, so it is checked against the changelog, not against this page.
A map should be checked by its own nodes: walk the key ones, open the file and function they lead to, and match the claimed order against what you see in the code and the tests. The map passed the check if you can reach every step of the chain through it and it is confirmed. It failed if even one node leads elsewhere or the chain breaks off. Such a check takes minutes and at the same time reveals gaps: if a node has nowhere to jump to or the function behind it does something entirely different, you have found not a flaw in the map but a place where your understanding of the system diverges from the code.
The typical failure is treating the map as an authority rather than as navigation: building a wide map "to understand everything" and then quoting its execution order without opening a single node. The sign is the same as with symbol explanations: a conclusion is justified by a picture rather than a line of code. Narrow the map to a question and walk its nodes - then it does what it is for: it brings you to the right places faster than reading in order.