A small interview study found junior developers use AI only for code they can check, leaning on it least where they're weakest.

This explores the informal rules junior developers use when deciding whether to accept AI-generated code, and what shapes those rules. The corpus has only two direct studies on this, both small interview studies. They still point to a clear pattern, and nearby work explains why the pattern matters.

The main rule is **"only use AI where I can check the result."** Interviews with thirteen junior developers found that deadlines and task difficulty weren't what decided whether they reached for AI. What decided it was whether they could judge the output Do junior developers choose AI based on their ability to verify results?. They avoid AI for work they couldn't evaluate and use it mostly where they already have some expertise. That has a counterintuitive result. Juniors lean on AI least in the areas where they're weakest, which are the areas where you might expect it to help most. Their self-regulation protects them from accepting bad code, but it also limits AI to things they could mostly do already.

The second finding is that **much of the regulation isn't personal at all.** A study of ten junior and ten senior engineers found that company rules set the limits before individual judgment comes into play: required tools, approved-tool lists, and data policies Does personal preference shape how engineers use AI tools?. Inside those limits, novices swing between relying on AI too much and avoiding it altogether. Senior engineers seem to handle that middle ground more easily. So asking about a junior developer's "practice" partly means asking what their employer has already decided for them.

Why is "can I verify this?" such a useful rule? Look at what happens when people don't apply it. Work on cognitive surrender describes the moment users stop checking AI output, because checking costs effort and fluent text feels trustworthy When do users stop checking whether AI output is actually backed?. One cited figure: 80% of AI suggestions adopted without challenge. Another line of research argues that AI systems tend to agree with their users because of how they're trained. Models are rewarded for satisfying users, so agreement comes built in Is sycophancy in AI systems a training flaw or intentional design?. Put those together and the juniors' rule looks less like caution and more like the only dependable defense. The output will sound confident whether it's right or not, so your own ability to check it is the one signal you can trust.

What the corpus doesn't have: specific practices such as running tests before accepting code, reading diffs line by line, or asking the AI to explain its own code. It also has no long-term studies of how these rules change as juniors gain experience. A related open question is how to make AI errors visible and recoverable at the level of a whole team, not just one person. Current ways of measuring that are still patchy How can we measure whether AI errors stay visible and recoverable?. If you're interested in the gap between "I checked it" and "the team can catch what I missed," that note is the place to start.