Do junior developers choose AI based on their ability to verify results?

The paper reports thirteen interns and junior developers, interviewed one at a time by videoconference and analyzed with Braun and Clarke's six-phase thematic analysis, who describe one criterion that outranks the others when they choose between AI and manual work: "the ability to check the result." The authors call this verification-conditioned use. E10 states the rule at both ends: "I only use AI for things I already know how to do, because then I'm able to judge the result." The discussion summarizes the pattern as participants turning "to AI for what they know how to review, and avoid[ing] it where they cannot judge whether the answer is correct."

The mechanism runs against a common expectation. The newcomer with the smallest repertoire does not lean hardest on AI to cover gaps. In the reports, "without the repertoire to judge the result, the task falls on the side where AI is avoided." The two cases offered as tests are cautionary. E11 integrated the Google Maps API without mastering the topic and still felt uneasy. E07 let AI implement a business rule the developer did not understand, the client noticed the error, and the team had to roll back operations. The resulting split delegates CRUD, front-end, syntax and testing, and keeps architecture, business rules and broad context. The paper's theoretical claim, the "formative paradox," is that the shallow learning AI induces makes it harder to build the critical-judgment competence participants say the market now wants.

Against the nearest notes, this excerpt is about the junior's own gate, not the pipeline. Does generative AI prevent juniors from getting entry-level work? asks whether the work reaches juniors at all. These interviews show juniors filtering their own AI use through what they can check, so AI use concentrates where they already hold the skill to judge it. The four self-regulation practices the authors name (reviewing before accepting, asking the tool for explanations, and keeping unassisted practice among them) overlap with the high-engagement patterns in Does AI assistance actually harm the way developers learn?. The difference is evidentiary: the experiment measures learning outcomes, while this paper reports practices participants describe. Its claim that the professional differentiator has moved from writing to evaluating code also parallels Does AI turn freelance work into validation instead of creation?, which is a position paper rather than interview evidence.

The excerpt does not establish how common this criterion is. It rests on thirteen interviews from one country, recruited through the researcher's network and LinkedIn. AI use was not an inclusion criterion, and all thirteen turned out to use AI, so the excerpt cannot show how non-users would answer. The one non-user, E13, appears in the task typology only in negative form. The criterion is self-reported rather than observed in the work, and the formative paradox is a theoretical contribution the study proposes, not an effect it tests. The excerpt also stops partway through its limitations section. The implication is modest: the ability to verify is a plausible lens for deciding where junior training should place checkable work and where it should protect unassisted practice. It is not evidence that AI shallows junior learning in general.