SideNote ProSideNote Pro workflows for developers
Developer AI advice is usually about writing code, which is the part editors already handle. These are workflows for the rest of the day: reading unfamiliar code, understanding failures and answering questions about a codebase.
Ask questions about a repository
Index a project folder in Settings, Local folders. Generated and vendor directories such as .git, node_modules, bin, obj, dist and build are excluded automatically, so the index reflects your code rather than your dependencies.
This is most valuable on a codebase you did not write. Questions worth asking on day one:
- *Where is authentication configured, and which files define session expiry?*
- *Which files handle database migrations, and what order do they run in?*
- *Where is the retry logic for outbound HTTP calls?*
- *Which configuration values are read at startup, and where do their defaults live?*
The Sources list is often more useful than the prose answer. It names the four files you should open, which was the real question. Open and Reveal are one click from there.
Retrieval is lexical, so match the codebase's vocabulary. Asking about session expiry finds code that says session expiry. It will not bridge from logout timing. When a search misses, rephrase in the code's own words.
Triage errors without leaving the terminal
Assign a shortcut to Ask SideNote. Select a stack trace or error message anywhere, in a terminal, a log viewer, a browser console, press the shortcut, and type the one thing the trace does not contain.
That last part matters. A stack trace tells the model where it broke. What it cannot tell the model is what you were doing, what changed recently, or what you expected. *This started after we moved the job to run concurrently* turns a generic answer into a useful one.
A custom action worth building: *Explain this error to someone unfamiliar with this codebase, then list the three most likely causes in order of likelihood: {{selection}}*. Bind it to a key and it becomes the reflex for any unfamiliar failure.
Capture what you cannot paste
- A rendering bug. Region capture, then *this layout breaks at this width, which element is most likely overflowing?* Combine with folder context over your source and you get a file rather than general advice.
- A profiler or monitoring graph. *What does this pattern suggest about where time is going?*
- A tool's error dialog that will not let you select its text.
- A diagram in documentation. Region capture beats describing an architecture diagram in prose.
Your model needs image support for any of this. Worth checking on local providers, where many small models are text-only.
Match depth to the problem
Developer questions split cleanly, and the split is worth acting on because the cost difference is large.
| Fast profile | Deep profile |
|---|---|
| *What does this function do?* | *Why does this deadlock only under load?* |
| *What is the syntax for this?* | *Is this migration safe with concurrent writes?* |
| *Write a regex matching this* | *Which of these two designs fails worse under partition?* |
| *Explain this error message* | *Find the race condition in this sequence* |
| *Summarize this changelog* | *What breaks first if we scale this ten times, and why?* |
The left column is the majority of daily use and does not need a heavyweight model. Escalate when a fast answer is visibly shallow rather than starting deep. See a model for each task.
Reading code and reviewing changes
- Select an unfamiliar function and press Explain. Faster than reading it cold, and you still read it afterwards.
- Select a diff and ask for a commit message. A worthwhile custom action.
- Ask *what would a reviewer object to here* on your own change before opening a pull request.
- Ask *what is this code assuming that is not checked* on anything handling input.
- For a design document, index the folder it lives in and ask what it contradicts elsewhere.
Everything here produces leads, not verdicts. An AI reading of concurrency behaviour is a hypothesis to test, and code it suggests is code you own once you merge it. Read it as you would a colleague's suggestion from memory: often useful, never authoritative.