{"slug": "levels-of-concern", "title": "Levels of concern", "summary": "A developer argues that not every code change made by a large language model deserves equal scrutiny, urging teams to apply risk-based oversight: low-risk tasks like UI tweaks need only verification, while high-risk work involving authentication, permissions, payments, or destructive operations requires deep comprehension and careful testing.", "body_md": "It's taken me a few years to understand this, but not every change an LLM makes deserves the same level of scrutiny. What got me thinking about this was this tweet by antirez (creator of Redis):\n\nIt caught my attention because while I disagree with what he says at a generalized, blanket level, I agree from a more granular, \"in the trenches\" perspective.\n\nIf the work an LLM is helping you with is changing button copy, relocating a piece of UI, writing a small helper, or doing something with an obvious result, let it work.\n\nReview what changed, run it, and move on. You don't need to inspect every line while it's being written. In those cases, a simple smoke test to verify \"it's doing what I told it to do\" is actually the truth is far more valuable (and likely to surface issues with what was written).\n\nBut concern for whether or not the code is good shouldn't stop there. It should rise with consequence.\n\nA broken layout is annoying, sure. A broken permission check is a security problem and potentially a massive headache. A bad database migration can nuke your data. A subtle billing mistake can sit unnoticed for months, leaking revenue that the business needs to survive.\n\nSo, if the code you're working on touches things like authentication, permissions, payments, user data, infrastructure, destructive operations, or anything difficult to reverse...*slow the fuck down*.\n\nRead the surrounding code, check your assumptions, and test the failure paths you can reason through. Make sure you understand the change well enough to notice when it's wrong (even what is typically a small, seemingly cosmetic change can cause serious damage).\n\nThe mistake is treating every task as equally dangerous or equally harmless. Instead, we should be using LLMs as leverage where it makes sense but a reminder to slow down where it doesn't. Low-risk work needs verification. High-risk work needs *comprehension*.\n\nWhere mistakes are cheap? Let the robot go nuts.\n\nBut when it's work that has serious gravity behind it: pay attention. Don't just assume the LLM will fix it. Dig in, give a shit, and make sure the thing does what it's supposed to, even when \"it's just an edge case, bro.\"", "url": "https://wpnews.pro/news/levels-of-concern", "canonical_source": "https://graybeard.ing/levels-of-concern/", "published_at": "2026-07-20 19:43:00+00:00", "updated_at": "2026-07-20 20:05:35.883131+00:00", "lang": "en", "topics": ["large-language-models", "ai-safety", "developer-tools"], "entities": ["antirez", "Redis"], "alternates": {"html": "https://wpnews.pro/news/levels-of-concern", "markdown": "https://wpnews.pro/news/levels-of-concern.md", "text": "https://wpnews.pro/news/levels-of-concern.txt", "jsonld": "https://wpnews.pro/news/levels-of-concern.jsonld"}}