The Architecture page
Architecture…, in the browser's Project menu (/architecture in the browser or the terminal), draws
what your app is made of and how its parts connect, read from the repository's own files. Use it to learn a
codebase, or to check what a change touches. In the terminal it lists each part, its technology and where it
lives, then how the parts connect; /architecture fresh reads the repository again.
What you see
Three columns:
| Column | Holds |
|---|---|
| People use | Front ends and web pages |
| It runs | API servers and background jobs |
| It relies on | Databases, caches, sign-in, queues, file storage and outside services such as payments or email |
Each part says what it is built with, where it lives, and how many routes, pages and data models it has; How it was found opens to the files that put it on the map. Under the parts, How they connect lists each connection and what shows it, and the last line says how many files were read and from which manifests. Read it again reads the repository afresh.
On the classic page, select a part to see those files, what it connects to, and its routes, pages and data models, each with its file and line; click any file to open it in the side panel, beside the map.
Nothing is guessed
Every box comes from a file that declares it, and a line is drawn only where a file shows the connection:
| Read from | For |
|---|---|
package.json, pyproject.toml, requirements*.txt, go.mod |
The parts: frameworks, database drivers, sign-in libraries, job queues and outside services |
docker-compose.yml |
The databases, caches and queues that run beside the app; depends_on draws lines |
.env.example |
The outside services the app is set up for (names only; a real .env is never read) |
| The code | API routes (Express, Fastify, FastAPI, Flask, Django, Next.js route handlers), pages (Next.js, React Router) and data models (Prisma, SQLAlchemy, Django, SQLModel, Mongoose, Drizzle) |
Lines need evidence too: the front end calls the API where its code fetches from it; the back end uses a database, a sign-in library or a service where the same manifest declares both.
A route on a FastAPI router or a Flask blueprint carries the router's prefix, so the list a router
serves at "" is found where it is:
router = APIRouter(prefix="/api/shipments")
@router.get("") # GET /api/shipments
@router.get("/{ref}") # GET /api/shipments/{ref}A library that signs and checks tokens (PyJWT, jose, jsonwebtoken) is how the code reaches the sign-in provider it also has, such as Okta, and is shown inside that box. Without a provider it is the app's own sign-in, a box of its own.
A framework it does not recognise is listed as found in a manifest, not guessed at.
Only the folder as it is now
The page reads only what the open folder holds now:
- at most 8,000 files, shallowest first;
- never what Git ignores, dependencies (
node_modules,.venv,vendor…), build output (dist,build,.next,target…), caches, test reports, another checkout kept inside the folder (.git,.worktrees), or an editor's saved history (.history,.idea…); - never old copies such as
file.py~,.orig,.bakor.swp.
The map is reused only while every file it read is unchanged, so it follows your edits by itself. Read again reads every file afresh.
Examples
Learning a new codebase. Open the folder, then Architecture. Select the API to see its routes;
click a route to open its handler. Then ask in the chat: "Walk me through what happens on
POST /orders."
Before a change. Select the database to see which parts use it, then ask Albert for the change knowing what it touches.
From docs/architecture.md in huynvic/albertcode-swe-agent at a8cef99 (15 Oct 2026), shown unchanged except for links. AlbertCode SWE Agent documentation, CC BY 4.0. Latest on GitHub.