You approve changes from your phone, and so far nothing has gone wrong. That is a real observation, and it deserves a better answer than a warning.<\/p>\n
Here is the better answer. The phone changed what you are able to check. It left your accountability exactly where it was.<\/p>\n
At a desk you have the change itself, the file it sits in, the checks, the branch history, a terminal, and often the running application in another window. On a phone you have whatever that particular surface chooses to show you \u2014 sometimes the checks, sometimes a rendered preview, sometimes very little beyond the change.<\/p>\n
That is a difference in available evidence, and it varies by tool, by repository and by the change in front of you. What stays fixed is the weight of the approval. The approval still carries your name and your accountability regardless of which screen you used to issue it.<\/p>\n
Coding agents make the question harder to ignore because changes can arrive for review without waiting for someone to be sitting at a desk. The volume may change; the accountability does not.<\/p>\n
One question, asked of the change in front of you.<\/p>\n
Is everything this decision depends on visible and inspectable on the surface I am approving from?<\/strong><\/p>\n Both words carry weight. Visible, so you can see it. Inspectable, so you can check it without assuming. If the answer is yes, approve where you are. If the decision leans on something you would have to open another surface to see, defer it.<\/p>\n That question governs ordinary changes. A team may also place certain classes of change permanently beyond mobile approval because their consequence demands a different review environment. Those are policy boundaries, not evidence failures.<\/p>\n Size is a poor proxy for this. A tiny change can depend on evidence you cannot see, while a larger change can sometimes be self-contained enough to review from the surface you are on. A one-line payment-path change may need evidence outside the diff. A much larger isolated copy change may not.<\/p>\n Write the line down once, as two columns, and the team stops re-deciding it per change and per mood.<\/p>\n Approve where you are, when:<\/p>\n Defer to another surface, when:<\/p>\n The columns belong to your team and your tools, and they are worth revising when either changes. A surface that starts rendering previews moves items across the line, which is the point: the line tracks evidence, so it moves when the evidence moves.<\/p>\n What follows is a composite scenario written for this article. No real repository, no real team.<\/p>\n An agent opens two changes on the same afternoon.<\/p>\n The first is a single line: a rounding change in how an invoice total is calculated. It reads correctly and it looks obviously right, so instinct approves it immediately. But judging the change requires seeing how the calculation behaves across representative invoice cases, and those test results are not available on the phone. The line says defer.<\/p>\n The second runs to well over a hundred lines: replaced onboarding copy across several screens, in two languages. Instinct hesitates at the size. The change touches only text, the surface renders the affected screens, the visible checks cover the affected strings, and the surrounding files show no functional change. Everything needed to judge this change is available on the approval surface. The line says approve.<\/p>\n Instinct was reading size in both cases. The line was reading evidence, and it reversed both answers.<\/p>\n A few approvals sit permanently on the far side of the line. Writing them down removes the argument at the moment it costs most, which is when something is urgent.<\/p>\n Some teams will also define classes that are never eligible for mobile approval: authentication and permissions, payment logic, database migrations, deployment configuration, secrets, or changes to the approval process itself. The exact list belongs to the team. Its purpose is not to say that a phone cannot display enough information; it is to require a fuller review environment for changes the organisation has chosen to treat differently.<\/p>\n Draw the line before the next urgent change arrives. Ask: can I see and inspect, from here, everything this approval depends on? If the answer is no, nothing is wrong with the phone and nothing is wrong with waiting. The decision simply needs a surface that can show the missing evidence.<\/p>\n Before you bolt on another tool, it is worth knowing whether your business runs on systems or on you. I put together a free 2-minute assessment that gives you a straight read on exactly that, and the first thing to fix. Take the free assessment<\/a>.<\/p>\nThe two columns<\/h2>\n
\n
\n
An approval where instinct and the line disagree<\/h2>\n
What waits regardless<\/h2>\n