Above a function or class in the editor small hint buttons appear - code lenses - and they are easy to take for one general "AI magic". The temptation is to press without working out which one launches what: the result comes into the same editor anyway. But behind three buttons stand two different mechanisms, and confusing them means not knowing where the task went or how to verify it.
Code Lenses in Devin Desktop appear above suitable symbols - functions and classes - and offer three actions. Explain describes what the symbol does and how it works, and for this it turns to the agent. Refactor opens a list of ready-made instructions with the option to write your own and performs the edit through Command. Docstring, through Command, generates a documentation comment above the function header, and in Python below it.
Hence a useful fork that the lenses impose by their very design: first understand, then change. Explain is reading: it passes the code to the agent and returns an explanation, touching nothing. Refactor and Docstring are already a local diff through Command. The reasonable order repeats this boundary: an unfamiliar symbol is explained first, and refactored or documented only once it is clear what exactly is changing and why.
The naive trust breaks on the docstring. The generated comment looks authoritative and sits exactly where documentation is expected - and it is accepted as truth about the code. But the model describes what it sees in the function's text, not the business meaning that is not written there. A docstring should record observable behavior, the exceptions thrown and the units of measurement, not a guess about why the function exists.
The professional technique is to treat a generated docstring as a draft that you certify with your own knowledge. Read it next to the function body and strike out everything the code does not confirm: invented guarantees, wrong units, a missing mention of an error. What remains and is verified is documentation; what the model added on its own is a hypothesis that has no place above working code.
A separate boundary the documentation states directly: code lenses do not yet trigger Devin Local. So behind a button stands either the agent (Explain) or Command (Refactor, Docstring), but not the full local agent with its permissions and sandbox. The practical conclusion: if you expected a lens to behave like Devin Local - diff review, permission decisions, a test run - you expected it from the wrong mechanism and will see the behavior of Command or chat, not of the agent.
Why the lenses are built as quick buttons rather than an entry into the agent. Their job is to remove friction on the most frequent small actions: understand someone's function, tidy it up, add a comment. This needs no cycle with permissions and review; it needs one click and an immediate result. Separating Explain as reading by the agent from Refactor and Docstring as an edit through Command means keeping the cheap cheap, without pretending each button is project work.
The cost of mixing is not a breakage but wrong expectations. Accepting a docstring without looking, you leave in the code a plausible untruth that the next reader will take as verified. Expecting Refactor to work at Devin Local's scale, you get an edit within the symbol and are surprised the neighboring calls are not aligned. Both troubles are cheap on their own, but they accumulate precisely because they look like finished work.
You should verify a lens's result by which mechanism you launched. After Explain, make sure you understood the symbol rather than just read a coherent paragraph: the agent's explanation is an entry into the task, not the task itself. After Refactor and Docstring, read the diff like any Command diff: signature, behavior, boundaries. And remember that none of the lenses will verify the code for you the way Devin Local would - that verification simply is not here.
Refactor has a handy detail worth using deliberately: it offers a list of ready-made instructions and lets you write your own, and in essence this is the same as selecting code and invoking Command. A ready item saves the wording on a typical edit - extract a function, simplify a condition - but your own instruction with named boundaries is almost always more precise than a template when it matters what exactly not to touch. Docstring, in turn, places the comment above the function header, and in Python below it, which is worth keeping in mind so you do not look for the result in the wrong place.
The typical failures grow from mixing layers. A docstring accepted as fact - and a confident description of what the function does not do settles into the codebase. Project-wide consistency expected from Refactor - and you get a neat edit of one place among misaligned others. A decision that the lens "launched Devin Local" - and you look for a permission card that was never there. The sign is the same: the button was pressed without naming whether it is the agent, Command or reading. Name the mechanism before the click, and the explanation is almost always right there.