Verification-Conditioned Use: A Qualitative Study on How Generative AI Reshapes Learning, Autonomy, and Market Entry for Junior Software Developers

ABSTRACT Objective: to investigate how the use of generative Artificial Intelligence (AI) tools affects the early stages of a career in software development, from the perspective of the newcomers themselves. Method: thirteen interns and junior developers were interviewed individually, by videoconference. Interviews were analyzed using the six phases of Braun and Clarke’s thematic analysis, with inductive coding and a semantic approach. Results: sixteen themes emerged, organized around a central concept: verification-conditioned use. Across the study’s four research questions (usage patterns, learning, autonomy, and market entry), the criterion that most often decides between AI and manual work is not deadline or task complexity, but the ability to check the result. Two themes expose tensions in newcomers’ self-perception: the autonomy paradox (feeling more capable yet less in ownership of the result) and the first-person denial of dependence. Together, these findings point to a theoretical contribution, the formative paradox: the shallow learning that AI induces makes it harder to build the very critical-judgment competence that, according to participants, the market has begun to demand. Conclusion: what makes AI use sustainable, from participants’ own point of view, is not the tool itself but the individual practice of reviewing before accepting, refusing to use AI without understanding it, asking the tool for explanations, and keeping deliberate practice outside of AI-assisted work.

Keywords Generative Artificial Intelligence · Junior Developers · Software Engineering Education · Thematic Analysis · Human-AI Interaction

Introduction. Generative AI has entered the daily routine of software development in a few short years. Tools such as GitHub Copilot, Cursor, ChatGPT, Claude Code, and Codex are now part of the everyday practice of programmers. Tasks that once required searching documentation, browsing forums, or manual prototyping are now supported by assistants that generate code, explain concepts, and propose solutions from the context of a question [Mahmoud et al., 2025, Hibi, 2025].

This shift does not affect every profile equally. Interns and junior developers are still building their technical repertoire and looking for a place in the job market, and for this group AI use has become close to compulsory: in some teams, deadlines and delivery expectations already assume that AI is used, which can lead newcomers to adopt it before they have enough of a knowledge base to critically evaluate what it produces. Prior work reports productivity and perceived performance gains from AI use [Szolderits, 2025], alongside preliminary evidence of side effects such as shallower learning, possible skill-retention loss, and passive usage patterns, particularly requests for a “direct solution” [Mahmoud et al., 2025, Hibi, 2025]. This study investigates these effects specifically among newcomers to the market, rather than among established professionals.

1.1 Research Problem Existing evidence already indicates that AI helps newcomers gain immediate productivity. This study addresses a less obvious question: in which aspects, and in what ways, does early AI adoption reconfigure the start of a career in software development. Three tensions structure the problem. First, immediate productivity versus depth of learning: AI substantially reduces the time to complete tasks, but there are indications that this acceleration may compromise the depth with which newcomers build technical knowledge, with consequences for retention and the ability to solve complex problems unassisted [Mahmoud et al., 2025]. Second, perceived autonomy versus actual dependence: having a tool at hand that answers questions, generates code, and explains concepts at any moment increases the newcomer’s sense of autonomy, but may also create dependence; when the tool is unavailable, or when the professional must act outside the scenarios where AI is effective, confidence and performance may falter [Hibi, 2025]. Third, reconfiguration of market-expected competencies: activities traditionally assigned to juniors, such as CRUD operations, scripts, and small refactors, are now efficiently handled by AI itself, which may raise the entry barrier and shift the expected skill set of a newcomer toward architecture, business-rule translation, and critical review of tool output.

Building on these tensions, the study investigates, from the professionals’ own perspective, how AI affects entry into the software job market. The main research question is:

How does the adoption of generative AI tools by interns and junior developers impact their day-today work, learning process, task execution, and professional perception when entering the software development job market?

This question unfolds into four sub-questions, each defining a thematic axis that guided coding and theme aggregation:

These four research questions are not independent hypotheses to be individually confirmed or rejected. Following the logic of thematic analysis [Braun and Clarke, 2006], they define the analytical lenses used during theme development: each sub-question delimits a thematic axis around which codes were grouped into candidate themes (analysis phase 3) and later consolidated into final themes (phase 5). A single interview excerpt can therefore inform more than one axis, and the themes that emerge under one research question are expected, and in fact turn out, to interact with themes under the others, which is precisely what the integrated synthesis in Section 4.5 makes explicit.

Related work. 2.1 Generative AI in Software Development Large language models have changed the way software is written. Tools such as GitHub Copilot, Cursor, ChatGPT, Claude Code, and Codex have become part of developers’ routines within a few years, with rapid, global-scale adoption [Dohmke et al., 2023, Szolderits, 2025]. The literature describes this as a shift in role: AI stops being a one-off tool and starts acting as a co-producing agent alongside the developer [Dohmke et al., 2023, Szolderits, 2025], suggesting code contextually, completing functions, and proposing project scaffolding from natural-language prompts. The novelty of this generation of tools is not raw speed but the capacity to answer in a personalized way, tailoring the explanation to the specific doubt of whoever is asking [Hibi, 2025, Mahmoud et al., 2025], which is what makes these assistants compete directly with traditional learning sources such as documentation and Stack Overflow.

This matters disproportionately for interns and junior developers. Unlike established professionals, newcomers are simultaneously using AI to produce work and to build the technical repertoire they do not yet have; every AI-mediated shortcut is, for them, also a possible shortcut around a learning opportunity. Established developers can treat AI primarily as a productivity multiplier over an existing skill base, while for someone still forming that base the same interaction doubles as a (potentially compromised) training signal. This is the reason this study isolates newcomers analytically rather than treating them as a subset of “developers in general,” as most prior work does.

2.2 AI-Mediated Learning and Why Judgment Becomes Central 2.3 Market Reconfiguration and the Rise of Critical Judgment AI assistants have also been described as reconfiguring the competencies expected of software developers. Dohmke et al. [2023] characterize the phenomenon as a sea change in the developer lifecycle, with effects on productivity, team shape, and hiring profiles; Szolderits [2025] describes an analogous shift while studying Copilot, framing it as a reorganization of valued competencies toward judgment, architecture, and technical communication, and away from raw code-writing. This has a direct implication for entry-level profiles: tasks historically associated with internship and junior roles, CRUD operations, scripts, small refactors, are among the tasks most frequently delegated to AI [Szolderits, 2025]. As a consequence, the entry barrier tends to rise, and the skill set expected of a newcomer shifts toward competencies previously associated with more senior levels, such as critical code review, architectural decisions, and translating business rules [Dohmke et al., 2023, Hibi, 2025].

Method. 3.1 Research Design This is a qualitative, descriptive, and exploratory study, following an inductive approach. Data were collected through semi-structured interviews and analyzed with the six-phase Thematic Analysis method proposed by Braun and Clarke [2006]. Thematic analysis was preferred over alternative qualitative approaches (e.g., grounded theory or content analysis) for two reasons specific to this study’s aims. First, it does not require, and in fact discourages, committing to an a priori theoretical framework before coding, which suits an exploratory question with no established model of how AI reshapes early-career software work. Second, it is explicitly designed to surface patterns of shared meaning across a moderate-sized interview set without requiring the kind of large, continuously-sampled corpus that grounded theory’s saturation criteria typically demand, which matches the scope of an undergraduate research project constrained in time and access to participants.

3.2 Participants Participants were selected by intentional and convenience sampling, contacted through the researcher’s personal network and, complementarily, through LinkedIn. The target profile comprised interns and junior developers working at software companies in Brazil. No minimum professional tenure was required, and AI tool use was not an explicit inclusion criterion, although all thirteen participants who took part turned out to use such tools in their daily work. The study reached thirteen interviews. This number was not fixed in advance; interviewing continued until new transcripts stopped introducing codes not already present in the codebook and instead repeated patterns already seen in prior interviews, a practical proxy for thematic saturation given the project’s resource constraints. By the last two or three interviews, coding was producing near-exclusively re-applications of existing codes rather than new ones, which was taken as the stopping signal; this also means the sample size reflects saturation for the depth of analysis pursued here, not a target number chosen up front. Nine interviews were conducted by the first author; the remaining four were conducted by a second interviewer working on a related master’s research topic, with participants’ explicit authorization for data use in this study. Table 2 summarizes participant profiles; names were replaced with codes E01–E13 to preserve anonymity, and companies are described only by industry sector.

3.3 Data Collection Semi-structured interviews were conducted individually via videoconference (Google Meet, Microsoft Teams, or Zoom) and fully transcribed. The interview guide was organized into thematic blocks aligned with the four sub-questions, favoring open questions that encouraged participants to report concrete situations from their daily work. Verbal consent for recording and for research use was obtained at the start of each interview, after the researcher explained the study’s purpose, procedure, and confidentiality policy.

3.4 Thematic Analysis Procedure Analysis followed the six phases proposed by Braun and Clarke [2006]: (1) familiarization with the data through full transcription and repeated reading; (2) inductive generation of initial codes; (3) search for themes, grouping codes into candidate themes with the aid of concept maps; (4) review of themes at both the coded-extract and full-dataset levels; (5) definition and naming of final themes; and (6) report production, presented in Section 4.

3.5 Ethical Considerations The study followed standard ethical principles for research with human subjects. Participation was voluntary, without financial compensation, and no sensitive personal data (as defined by Brazil’s General Data Protection Law) were collected. Participant identity was preserved through the use of codes (E01–E13) in analysis and reporting, and details that could enable direct identification (proper names, company, project, and product names in sensitive contexts) were suppressed or replaced in transcripts and quotations.

Discussion. Verification-conditioned use. Across the thirteen interviews, the main criterion participants use to decide between using and not using AI was neither deadline nor task complexity, but the possibility of checking the result. They turn to AI for what they know how to review, and avoid it where they cannot judge whether the answer is correct. E10 states the criterion at both ends: “I only use AI for things I already know how to do, because then I’m able to judge the result. I’ll never use it for something I’ve never done in my life, because then it will produce whatever, and I won’t know if it’s right or wrong” (E10). E06 names the same rule as the explicit decision factor: “what makes me decide to use it or not is how much command I have over what I need to do” (E06). E01 anchors it in a concrete example: “I don’t trust anything I can’t validate [...]. If I don’t know how to work with Terraform, don’t know how to configure AWS, I’m not going to trust it blindly” (E01).

This criterion inverts a common expectation: it is not the newcomer with the smallest repertoire who relies most on AI to cover knowledge gaps. In the reports, the opposite happens, since without the repertoire to judge the result, the task falls on the side where AI is avoided. Two cases test the rule: E11 used AI to integrate the Google Maps API without mastering the topic, asked a colleague to review it, and still felt uneasy; E07 let AI implement a business rule in a financial project without mastering the rule, the client noticed the error, and the team had to roll back operations. These cases do not weaken the criterion; they show what happens when it is ignored.

What is delegated to AI and what is kept. A recurring split separates tasks where AI is used from tasks where it is avoided (Table 3). The left column groups tasks with a known right answer or standard pattern; the right column groups tasks that depend on project context and history. E02 frames the split: “I prefer to avoid it for tasks related to business rules, because I want to stay familiar with what the project is doing” (E02). E07 evades from the opposite end of the same rule, familiarity: “if it’s a library I already know, I won’t hand it to AI”, adding that “when the system is multi-repo, AI fails, it doesn’t have the full context” (E07). The one participant who departs from this map, E13, simply does not use AI at work, justifying the refusal because “AI has a way of writing that you can identify” (E13); even so, the same typology appears in negative form.

AI as an accessible senior. In every interview that touched this point, AI appears as a partial substitute for the senior colleague, covering two roles: explaining concepts on demand and helping to think before implementing. E08 states this preference directly: “in most cases, I’d rather ask artificial intelligence for help than ask someone” (E08). The most consistent effect, however, was not reducing conversation with seniors but changing the type of question taken to them. E01 describes the shift: “the question goes from ‘how do I implement this?’ to ‘is what I implemented right according to the company’s rule?’” (E01). E03 confirms from another angle: “the questions I used to bring before AI were more about code. The questions I bring today are usually about design, about architecture” (E03). The divergent case is E08, who reports asking seniors the same kinds of questions as before, showing that the shift depends on how much each professional integrates AI into their routine; it is not automatic.

Conclusion. This study investigated how generative AI use by interns and junior developers impacts their day-to-day work, learning process, task execution, and professional perception when entering the software job market, through thirteen semistructured interviews analyzed with Braun and Clarke’s six-phase thematic analysis [Braun and Clarke, 2006]. Across the four research questions, the main decision criterion for AI use is not deadline or complexity but the ability to check the result (verification-conditioned use), materialized in a clear task split (CRUD, front-end, syntax, and testing delegated; architecture, business rules, and broad context retained). AI reconfigures learning by replacing documentation and forums as the first route, reducing depth, and removing the cognitive friction that sustained retention, while shifting senior consultations from “how do I do this” to “is this correct?” It increases perceived autonomy in mastered tasks while generating doubt about how much of that autonomy is one’s own; trust comes from post-use review rather than from the output; and dependence is acknowledged collectively but denied in the first person, an arrangement sustained by four self-regulation strategies: reviewing before accepting, refusing to use AI without understanding it, asking the tool for explanations, and maintaining parallel unassisted practice. Finally, the entry barrier has risen as typical junior tasks migrate to AI, the professional differentiator has moved from writing to evaluating code, and the professional pyramid is reorganizing, with three coexisting postures toward the future: optimistic, concerned, and pragmatic.

The study’s main theoretical contribution is the formative paradox: the same shallow, low-friction learning that AI induces undermines the critical-judgment competence the market has begun to demand as a differentiator. This reframes over-reliance not only as an individual, cognitive problem but as a tension between the newcomer and a market that defines what counts as valuable skill.

Limitations. Following Runeson and Höst [2008]’s framework for software engineering case studies, four categories of threats apply.

Construct validity. Concepts such as “autonomy” or “shallow learning” could be interpreted differently by participants. This was mitigated by avoiding theoretical terms in the interview guide and by semantic-level inductive coding close to participants’ own words.