AI Makes Critical Thinking Harder to Build ![rw-book-cover](https://res.cloudinary.com/leaddev/image/upload/f_auto/q_auto/dpr_auto/c_limit,w_1920,h_1080/next/2026/06/Staying-technical.jpg) 🔗 **Source:** [AI Makes Critical Thinking Harder to Build](https://leaddev.com/leadership/ai-makes-critical-thinking-harder-to-build-in-junior-engineers) > [!note]+ Document Notes > tags: [critical-thinking, junior-engineers, ai-assisted-development, engineering-leadership, mentoring] > author: LeadDev > source: LeadDev > reference: https://leaddev.com/leadership/ai-makes-critical-thinking-harder-to-build-in-junior-engineers > date created: 2026-09-29 10:29 > > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > > # 🏷️ Title: AI makes critical thinking harder to build in junior engineers > <!-- deep-read:sections start --> ## 🧭 Table of contents - [📝 Summary](#-summary) - [📖 Main content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning styles assessment](#-learning-styles-assessment) - [📊 Accessibility assessment](#-accessibility-assessment) - [🌍 DEIB assessment](#-deib-assessment) - [✅ Logical validity](#-logical-validity) - [🛡️ DARVO analysis](#️-darvo-analysis) - [🎯 Conclusion](#-conclusion) - [🔄 Refactor appendix](#-refactor-appendix--ai-makes-critical-thinking-harder-to-build-in-junior-engineers) ## 📝 Summary - **What happened.** LeadDev published a leadership opinion piece on 2026-09-29 in its Leadership section (Reader shows the title as "AI makes critical thinking harder to build"). The captured text has no named byline, so this analysis credits the site. The narrator is an unnamed engineering leader who opens with a first-person story about leading a project early in a career (¶1). This is commentary and advocacy, not a study. - **The claim.** AI coding tools remove friction that used to teach junior engineers to reason about tradeoffs. Some of that friction was "formative" (¶13), so leaders have to build critical-thinking practice back into team routines on purpose. - **The mechanism.** A feedback loop (¶14): the less confidence a junior has in their own judgment, the more they defer to generated answers, and the more they defer, the fewer chances they get to build judgment. - **The prescription.** Five moves: name critical thinking as part of the job (¶18-¶19), protect psychological safety when AI was used (¶20-¶21), use existing rituals like code review, RFCs, incident response and debugging (¶22-¶24), prompt AI to question the engineer instead of answering (¶26-¶27), and write critical thinking into career frameworks with observable behaviors (¶28-¶31). - **Why it matters.** The piece argues that output volume no longer proxies for learning (¶15). A junior can ship passing tests and a plausible implementation while skipping the reasoning about what to build. - **Key stakeholders.** Junior and AI-native engineers, engineering managers and leads, senior engineers who mentor, and AI tool vendors whose defaults shape how juniors work. - **Risks and tradeoffs.** The sourcing is thin. The captured text contains 35 paragraphs of assertion and anecdote and no cited study, survey number or dataset. The only data-shaped link is an anchor on "Engineering leaders" that points to a LeadDev "engineering leadership report 2026" page (¶15); the captured text doesn't say what figures in it support the claim. LeadDev is a publisher of leadership content and sells events and membership, and the link list shows the piece cross-linking heavily to its own pages. The captured text carries no explicit disclosure statement either way. - **Capture gaps.** The "Key takeaways" block (¶0) has a heading and no bullets in the captured text. ¶11 introduces a junior's typical day ("might have looked like this:") and the list or graphic that follows did not survive capture, so that specific comparison can't be assessed here. - **Bottom line.** The mechanism (deferring to output starves judgment) is plausible and the remedies are cheap. The "AI-native juniors are worse" premise rests on the author's experience, not on evidence in this source. ## 📖 Main content **The core argument.** Critical thinking is the invisible load-bearing skill in software work: architecture under competing requirements, translating vague requests into code, debugging in production (¶4). It shows up mainly when it's missing, in the author's three pairs: plausible implementation but wrong problem, passing tests but unintended behavior, functionally correct but unhappy users (¶5). With code cheaper to produce, the author says the human contribution shifts to what to build, why this way, and how to judge whether AI output is right (¶7). **The learning-by-doing premise.** The author uses a bike analogy (¶9-¶10): you can write down balance and steering, and none of it replaces riding. Frameworks for breaking down problems and evaluating tradeoffs are teachable, but the skill develops through practice. Historic junior work supplied that practice through trial and error (¶12), and AI-assisted work can skip it. **The loop and the evidence offered.** The feedback loop in ¶14 is a causal claim about confidence and deference. The supporting evidence in ¶15 is that "plausible implementations are hitting production with unvalidated assumptions." That sentence describes what leaders "may already be feeling," and the captured text gives no incident count, survey or example. **Five remedies.** - Define and name critical thinking as a working norm, then reuse the definition in onboarding, feedback and reviews (¶19). - Treat psychological safety as covering AI use, so an engineer can say "I don’t understand what the AI generated" (¶21). - Protect existing rituals (¶22-¶24) and say which PRs merit real discussion (¶23). - Configure AI as a coach that challenges assumptions, argues alternatives or interviews the engineer before it answers (¶26-¶27). - Add observable behaviors to career frameworks, with a worked pair from "requires significant guidance to identify assumptions" to "independently validates assumptions before implementation" (¶29-¶30). **Terms.** "Human in the loop" (¶26) means a person approves AI suggestions. The author wants "cognitive work in the loop" instead: the person does the reasoning. "AI-native" (¶3) means engineers who entered the workforce with AI tools as the default. **Contested or unverified.** (1) That today's juniors have less critical thinking than earlier cohorts: asserted at ¶15 and ¶33, with no comparison group. (2) That the friction AI removes is the friction that builds judgment: the author separates "drag" from "education" in ¶35 but offers no test for which is which. (3) That prompting AI to challenge assumptions produces the same learning as struggling alone: an untested claim. (4) The article treats AI use as a possible source of "undue shame and stigma" (¶21); the captured text gives no data on how common that is. ## 🗒️ Notes #### 📄 ¶0-¶3 The opening anecdote and the framing - ¶0 is the "Key takeaways" heading with no bullets in the capture. - The author led a project early on, hit unknown unknowns, unruly scope and cache invalidation, and calls the slog "gold" (¶1). - The learning arrived "as a natural consequence of how software is made" (¶2), which AI has changed. - Thesis (¶3): AI-native juniors enter a different learning environment, so leaders must look at a skill they took for granted. #### 📄 ¶4-¶8 Why critical thinking is the job - Critical thinking spans the development lifecycle: architecture, translation of requests into code, production debugging (¶4). - Failure signatures (¶5): right code for the wrong problem, tests that pass on the wrong behavior, correct function with unhappy users. - The claim in ¶6: cheaper code raises the value of judgment, because code is "a byproduct of critical thinking." - The human contribution becomes what to build, why this way, and how to verify AI output (¶7). - Experienced engineers hold years of accumulated judgment that juniors haven't had time to build (¶8). #### 📄 ¶9-¶12 The bike analogy and the old junior day - Teaching bike riding by explaining balance doesn't replace being on the bike (¶9). - Frameworks are teachable, and the skill still develops through practice (¶10). - ¶11 promises a description of a junior's typical day. The list did not survive capture. - Trial and error "consolidated into the foundations of critical thinking" (¶12). #### 📄 ¶13-¶16 Friction and the feedback loop - AI removes unproductive friction and speeds access to knowledge, which the author calls "a huge advantage" (¶13). - Some obstacles are opportunities: "Some friction is formative" (¶13). - Feedback loop (¶14): low confidence leads to deference, deference leads to fewer practice chances, which keeps confidence low. - Early consequences cited (¶15): plausible implementations hit production with unvalidated assumptions. Output can't stand in for thinking or learning. - The learning environment has changed, so leaders must adapt on purpose (¶16). #### 📄 ¶17-¶21 Team norms and psychological safety - Juniors aren't expected to arrive with the skill or own its development alone. The team and systems supply safe, visible practice (¶17). - Say explicitly that reasoning is part of the job, because recent grads may optimize for task completion (¶18). - Define critical thinking as a shared team norm, cite it in onboarding, feedback and reviews, and "make it coachable" (¶19). - Learning requires exposing unfinished thinking, asking naive questions and changing your mind (¶20). - Safety has to hold when AI was involved. The test question is whether engineers can say they don't understand generated code (¶21). #### 📄 ¶22-¶27 Rituals and AI as a thinking partner - Code reviews, RFCs, incident response and debugging are the "bike riding" of the trade (¶22). - These are old practices. The new element is the pressure to automate around them (¶23). - Not every PR needs a long debate. Leaders pick interesting ones and make room (¶23). - Don't add process. Protect moments where the team already thinks together (¶24). - Personal anecdote: a senior engineer's "what would happen if…" habit became a self-quiz before review (¶25). - Prompt AI to challenge an assumption, argue an alternative, or interview the engineer before proposing a solution (¶26). - Good mentors draw answers out. A supportive-learning-partner AI configuration reduces the dilution risk (¶27). #### 📄 ¶28-¶31 Visibility and career frameworks - Ticket volume no longer tracks growth. Leaders need concrete signals for thriving, stuck or overreliant (¶28). - Put critical thinking into career frameworks, 1-1s and reviews as explicit stage-based behaviors (¶29). - Example progression: from "requires significant guidance to identify assumptions" to "independently validates assumptions before implementation" (¶30). - Progress may look like advocating not to ship a ticket (¶31). #### 📄 ¶32-¶35 Closing - The author credits the early-project grind with building blocks used ever since (¶32). - AI-native juniors face an environment where some formative experiences are eroded (¶33). - Bypassing critical thinking widens the gap between functional code and a well-considered feature (¶34). - Close (¶35): don't recreate the pain, account for what was lost. "Some friction was drag. Some friction was education." ## 📚 References The captured link list has 19 entries. All point to leaddev.com pages. None points to an external study, dataset or survey. Anchors and URLs below come from that list. What each page says isn't checked here because nothing was fetched. **Sources tied to a claim in the text** - [Engineering leaders](https://leaddev.com/the-engineering-leadership-report-2026/) is the anchor on the "Engineering leaders may already be feeling the early consequences" sentence (¶15). It points to a LeadDev report page. The captured text doesn't state which figures, if any, support the claim, so treat the report as the possible source and read it before citing the claim. - [Code was never the whole job](https://leaddev.com/velocity/writing-code-was-never-the-bottleneck) anchors the code-as-byproduct argument (¶6). - [AI-assisted development](https://leaddev.com/ai/as-ai-helps-us-write-more-code-whos-catching-the-bugs) anchors the friction-removal sentence (¶13). - [productivity](https://leaddev.com/velocity/productivity-isnt-always-fast) anchors the "thinking is traded off for productivity" sentence (¶14). - [engineers frameworks](https://leaddev.com/management/level-frameworks-developing-developers) anchors the sentence on teaching problem-breakdown frameworks (¶10). - [judgment](https://leaddev.com/hiring/how-to-hire-engineers-for-strong-judgment-and-taste) anchors the judgment and taste phrase (¶2). - [Experienced engineers](https://leaddev.com/career-development/the-reality-of-being-a-senior-engineer) anchors ¶8. - [Psychological safety](https://leaddev.com/culture/safety-and-belonging-a-ritual-to-jumpstart-psychological-safety) anchors ¶21. - [Code reviews](https://leaddev.com/culture/build-a-productive-code-review-culture) and [incident response](https://leaddev.com/ai/your-incident-response-wasnt-built-for-ai) anchor the rituals list (¶22). - [Coach](https://leaddev.com/leadership/leader-coach) and [A good mentor](https://leaddev.com/management/how-be-effective-mentor) anchor ¶26-¶27. - [career frameworks](https://leaddev.com/career-development/taking-charge-your-career-growth) anchors ¶29. - [junior engineer](https://leaddev.com/management/be-catalyst-junior-engineers-career) and two "junior engineers" anchors ([mentoring](https://leaddev.com/career-development/mentoring-your-junior-engineers), [reward growth](https://leaddev.com/management/reward-growing-junior-engineers)) attach to the phrase in the running text. The list doesn't say which paragraph each anchor sits in. **Navigation or promotional links** - Two "AI" anchors point to [best AI coding assistants](https://leaddev.com/ai/best-ai-coding-assistants) and an [AI coding tools buying checklist](https://leaddev.com/ai/your-ai-coding-tools-buying-checklist-for-2026). They read as site navigation or recommended reading, and the checklist page is commercially adjacent to the topic. - "Staying technical" points back to the article's own URL, and an empty anchor does the same. Both read as breadcrumb or tag markup. **Claims with no matching link in the captured markup** - That junior engineers are less able to reason critically than earlier cohorts (¶15, ¶33). - That "plausible implementations" reach production with unvalidated assumptions at any stated rate (¶15). - That AI-generated code carries stigma for juniors who ask for help (¶21). - The career-framework example wording (¶30), which reads as an illustration, not a quoted standard. **Also relevant** - [Article URL](https://leaddev.com/leadership/ai-makes-critical-thinking-harder-to-build-in-junior-engineers), published 2026-09-29. - No byline appears in the captured text, so no author profile is available. ## 🗣️ Paraphrase The author says software skill used to come from painful projects: scope creep, unknown unknowns, cache bugs. Those experiences built judgment and taste as a side effect of shipping. AI now handles a lot of that grind, and juniors who start with AI tools may skip the struggle that teaches them to question requirements and check their own reasoning. The author frames critical thinking as the skill that separates code that runs from a feature that serves users. The fix the author proposes isn't banning AI or restoring old pain. Leaders should say out loud that reasoning is part of the job, define what it looks like at each level, and make it safe to admit "I don't understand what the AI generated." Code review, design docs, incident response and debugging already put people in situations where they have to think, so protect those. Configure AI to ask questions and challenge assumptions instead of just answering. Then measure growth by observable reasoning behaviors, not tickets shipped. The piece ends with a line that friction has two kinds: some was drag, some was education. ## 📰 Newsletter **Some friction is drag, some is education.** LeadDev's new leadership piece argues that AI coding tools may be sanding off the rough spots that used to turn juniors into engineers with judgment. The argument is opinion, and it's grounded in the author's own early-career story, not in a study. It still gives you five cheap moves for your own team: name critical thinking as part of the job, make it safe to say you don't understand the AI's output, protect code review and incident response as learning time, prompt AI to question you instead of just answering, and add stage-based reasoning behaviors to your career ladder. For WordPress mentors, the fit is direct. Core contributors already get this practice through Trac review, patch feedback and release triage. Mentoring programs can ask new contributors to explain a patch's assumptions before they ask an AI or a reviewer about it. Link: [the article](https://leaddev.com/leadership/ai-makes-critical-thinking-harder-to-build-in-junior-engineers). ## ✅ Action items #### DevRel - Developer advocacy: draft a talk outline on "prompt AI to question you," with three sample prompts (challenge an assumption, argue an alternative, interview me) and a comparison of learner outcomes. - Education: add a "explain the assumptions before you ask AI" step to any workshop that uses AI-assisted exercises. - Developer experience: in quickstarts that show AI-generated code, add a short "what would break this?" checklist so readers practice reasoning, not just running. - Developer marketing: don't cite this article as evidence that AI harms junior skill. Cite it as a practitioner opinion, and cite the linked LeadDev report only after reading it. - Community management: add a norm to help channels that "I don't understand what the AI generated" is an acceptable question, and link the article's ¶21 framing. - Internal/external: agree with docs and support on one shared definition of "critical thinking" for onboarding language. #### OSPO - Policy and governance: add a short AI-assisted-contribution clause requiring the contributor to explain the change, not only submit it. - License compliance: no direct action from this source. Nearest relevance: reviewing whether AI-generated contributions get the same license review as hand-written ones. - Security management: unvalidated assumptions in AI-written code (¶15) map to review-depth expectations for security-sensitive patches. - Software inventory: no direct action from this source. - Developer support: offer office hours framed around reviewing AI output, not generating it. - Community engagement: no direct action from this source. Nearest relevance: mentoring partnerships with bootcamps that train AI-native juniors. - Strategic alignment: track a mentoring KPI that isn't ticket volume, per ¶28, such as reviewer-rated reasoning quality on merged patches. #### Community - Maintainers: for interesting PRs, ask the author what they considered and rejected (¶23), and record the answer in the PR. - Contributors: publish a first-issue guide that asks for a one-paragraph reasoning note with each first patch. - Sponsors: when funding mentorship, request outcome measures other than merged PR counts. - Ecosystem: no direct action from this source. Nearest relevance: a cross-project session on AI-assisted review practices. #### WordPress - Core: no direct action from this source. Nearest relevance: reviewers can ask AI-assisted patch authors to state assumptions in the ticket. - Core Performance: no direct action from this source. - Core AI: for any guidance on AI-assisted core contribution, include a "keep the cognitive work in the loop" pattern (¶26) alongside the accuracy guardrails. - **Core Program Team:** no direct action from this source. Nearest relevance: retrospectives could ask whether AI use changed how new contributors learn. - Mobile: no direct action from this source. - Playground: build a debugging exercise where the AI-suggested fix is subtly wrong, so learners have to catch it. - Community: meetup and WordCamp mentor sessions on "questioning AI output" fit the format. - Training: add a critical-thinking rubric with stage behaviors modeled on ¶30 to contributor learning paths. - Marketing: no direct action from this source. - Support: coach support volunteers to check AI-drafted answers against reality before posting. - Design: no direct action from this source. - Documentation: add a handbook page on reviewing AI-generated code, with the assumption-check questions from ¶26. - Photos: no direct action from this source. - TV: no direct action from this source. Nearest relevance: a short talk on mentoring in the AI era. - Polyglots: no direct action from this source. - Accessibility: no direct action from this source. Nearest relevance: accessibility review is a critical-thinking ritual where juniors see real user impact. - Meta: no direct action from this source. - CLI: no direct action from this source. - Hosting: no direct action from this source. - Tide: no direct action from this source. Nearest relevance: scan-result triage is a judgment-building task for new volunteers. - Openverse: no direct action from this source. - Themes: review is a mentoring surface. Ask new reviewers to state what they checked and why. - Plugins: same as Themes, with extra depth expected on security-adjacent patches. #### The WPOCC - Programs: if The WP Open Community Collective funds mentoring, define a reasoning-behavior outcome instead of a hours-logged one. - Projects: no direct action from this source. - Funding experiments: no direct action from this source. Nearest relevance: a small grant to publish a contributor critical-thinking rubric. ### FAIR - Technical independence: no direct action from this source. - Policies and covenants: no direct action from this source. Nearest relevance: a covenant line that contributors can disclose AI use without penalty, echoing ¶21. - Productized governance artifacts: add a "reasoning expectations by level" row to any contributor-ladder scorecard. ## 🧪 Hypotheses 1. Juniors who get AI answers before attempting a solution score lower on a blind assumption-identification task than juniors who attempt first, after 8 weeks. 2. Configuring the AI assistant to ask questions before answering raises assumption-identification scores versus default AI use by at least 15% on the same task. 3. Teams that state "I don't understand what the AI generated" is acceptable report a higher rate of junior-initiated review questions within one quarter. 4. Defects tagged "wrong problem solved" per merged junior PR are higher in AI-heavy weeks than in AI-light weeks for the same engineers. 5. Adding stage-based reasoning behaviors to a career framework raises manager-reported specificity of feedback within two review cycles. 6. Reviewers rate a junior's explanation of a PR's assumptions as more accurate when the PR came from a protected discussion ritual than from asynchronous rubber-stamp review. ## 📊 Methodology - **H1 and H2.** Randomize 60 juniors into three arms: attempt-first, AI-first, coach-configured AI. Give a fixed set of 10 bug-and-feature tasks. Blind graders score assumption identification with a written rubric. Pre-register the score threshold. - **H3.** Run a two-quarter survey and PR-comment analysis across 20 teams. Count junior-initiated questions per PR, before and after a stated norm, using a control set of teams with no norm change. - **H4.** Pull defect tickets and label them by root cause. Join to AI-usage telemetry per engineer-week. Control for task type and seniority of the reviewer. Two labelers, with agreement reported. - **H5.** Compare feedback text before and after a framework change. Score specificity by counting named behaviors per review. Use teams that didn't adopt the framework as a comparison. - **H6.** Sample 100 merged PRs. Ask authors to write assumptions, then have reviewers who didn't see the discussion rate accuracy. - **Controls throughout.** Stratify by tenure, record tool versions, and report effect sizes with confidence intervals. ## ❓ Questions - What evidence supports the claim that plausible implementations reaching production is rising (¶15), and does the linked LeadDev engineering leadership report contain it? - What did the junior's day in ¶11 contain, and how would it compare with a typical AI-assisted day? - Which friction is "drag" and which is "education" (¶35), and who decides? - If AI is configured as a questioner (¶26), does the learning transfer when the engineer later works without it? - How would a manager distinguish healthy reliance from overreliance (¶28) with concrete signals? - Does the diagnosis hold for career changers or senior engineers new to a stack? - What is the cost in review time of protecting rituals (¶23-¶24) at a team with a large PR volume? - Do AI tool vendors have an incentive to ship coach modes by default? ## 🔮 Future research - **Longitudinal cohorts.** No cohort data appears in the source. A multi-year study of juniors hired before and after broad AI-tool adoption would test the core premise. - **Instrumented coach modes.** Compare default AI, question-first AI and no AI on transfer tasks. - **Measurement of judgment.** Standardized, low-cost instruments for assumption-checking and tradeoff reasoning don't appear in the source and would make ¶29-¶30 testable. - **Stigma and disclosure.** Surveys on whether engineers hide AI use, and what that does to learning in public (¶21). - **Mentor load.** How much senior time the recommended rituals cost, since seniors are also adopting AI. ## 💡 Implications - **Practice.** Reviews and design docs become the training ground, so review quality is a learning-quality issue as well as a code-quality issue. - **Policy.** Team norms and career frameworks should name reasoning behaviors and how AI use is disclosed. - **Security.** Unvalidated assumptions in generated code are a review-depth issue, especially in security-sensitive areas. - **Education.** Curricula that teach frameworks without practice repeat the bike-riding gap in ¶9. Assignments need to include AI-output critique. - **Funding.** Mentoring grants and programs need outcome measures beyond output counts, per ¶28. - **Vendor design.** Coach-mode defaults in AI assistants would shape learning at scale, and the article doesn't discuss vendor accountability. ## 🧠 Learning styles assessment - **Reading level estimate.** Flesch-Kincaid Grade Level 10.5 and Flesch Reading Ease 48.9 on the captured text (1,403 words, 86 sentences, computed with a simple syllable heuristic, so treat it as an estimate). That's college-entry level, plain in vocabulary but long in sentence structure. #### 👀 Visual learners - Present: the captured text has no diagram. ¶11 suggests a list or graphic of a junior's day that was not captured. - Improve: a before/after map of a junior's learning loop with and without AI, and a table of the ¶30 behavior progression by level. #### 🔊 Aural learners - Present: no audio version appears in the captured text. - Improve: a 3-minute audio summary and a discussion prompt a mentor pair can talk through. #### 🗣️ Verbal learners - Present: the bike analogy (¶9-¶10), the "drag versus education" contrast (¶35), and the mentoring analogy (¶27) explain the idea in words. - Improve: define "human in the loop" and "cognitive work in the loop" side by side, since ¶26 leans on the contrast. #### 🧩 Kinesthetic learners - Present: the AI prompts in ¶26 (challenge an assumption, argue an alternative, interview me) are directly testable. - Improve: a worked exercise with a flawed AI-generated PR and an assumption checklist. #### 🧠 Logical learners - Present: the feedback loop in ¶14 is an explicit causal chain, and ¶5 lists paired failure modes. - Improve: show how to measure each link in the loop, and a decision tree for when to let a junior struggle versus intervene. #### 🧑‍🤝‍🧑 Social learners - Present: the piece centers mentoring, shared definitions and team norms. - Improve: discussion prompts for a team retro, such as "when did AI answer before I thought?" #### 🧘‍♀️ Solitary learners - Present: the self-quiz habit from ¶25 is a solo practice a junior can copy. - Improve: a weekly reflection template for a junior logging one assumption they checked and one they didn't. #### 🌿 Naturalistic learners - Present: the bike-riding and mentor-as-guide analogies use embodied, natural framing. - Improve: a growth-over-seasons framing of a junior's development with observable milestones. ## 📊 Accessibility assessment Judged from the captured text and link list only. The rendered page, alt text and styles weren't inspected. #### Screen reader semantics - Present: the text arrives as paragraphs with a "Key takeaways" heading at the start (¶0). Headings elsewhere in the article body aren't visible in the capture, so their level and order can't be judged. - Improve: 19 links are captured. Several anchors are single generic words ("AI" twice, "Coach", "productivity", "judgment") and two anchors are empty or self-referential. That risks WCAG 2.2 AA 2.4.4 (Link Purpose, In Context) and 2.4.9 as a best practice. Empty anchors would fail 4.1.2 if they're actual links. #### Keyboard navigation - Present: unknowable from captured text. - Improve: verify focus order, skip link and visible focus (2.4.1, 2.4.3, 2.4.7) on the live page. #### Contrast and readability - Present: contrast can't be seen from text. Paragraphs are short, typically 1-3 sentences. - Improve: check body text at 4.5:1 (1.4.3). Reading level is around grade 10, so a plain-language summary would help. #### Text resizing and reflow - Present: unknowable from captured text. - Improve: test at 200% zoom and 320 CSS px (1.4.4, 1.4.10). #### Media and captions - Present: no media referenced in the captured text. The text mentions no audio, video, captions or transcript. - Improve: ¶11 points to a list or graphic that didn't capture. If that's an image, it needs alt text or a text equivalent (1.1.1). If the "Key takeaways" block is a collapsed or graphical element, confirm it is exposed as text (1.3.1). #### Forms and interactions - Present: no forms in the captured text. - Improve: check any newsletter signup or membership prompts on the live page for labels and error handling (3.3.2, 3.3.1). #### Standards reference - Gaps visible from the capture: 2.4.4 (generic and empty link text), 1.1.1 and 1.3.1 (¶11 content not captured, ¶0 bullets missing). Everything else needs the rendered page. ## 🌍 DEIB assessment #### Cultural breadth - Present: the framing is workplace-generic and doesn't name a country. - Improve: the examples are one author's experience. Add cases from different regions, company sizes and bootcamp or self-taught paths. #### Inclusive language - Present: "engineers" and "juniors" are used without gendered terms. Terms like "AI-native" and "human in the loop" are used with brief context. - Improve: "naive questions" (¶20) is used approvingly but could read as belittling. "Pretend you already have it" (¶20) is a helpful phrase, and a plain restatement would help non-native readers. Idioms ("gold," "bike riding," "on that bike") add load for translators. #### Neurodiversity support - Present: short paragraphs, a consistent problem-then-remedy structure, and an explicit call for defined expectations (¶18-¶19), which helps engineers who need unwritten rules made explicit. - Improve: the remedies aren't summarized as a list in the captured text (the "Key takeaways" block is empty there), which makes the five moves harder to find. #### Representation - Present: one first-person narrator, unnamed, plus a senior engineer mentioned in ¶25. - Improve: no other voices appear. Juniors, the audience the piece is about, aren't quoted, so their perspective is inferred, not reported. #### Psychological safety - Present: ¶20-¶21 make safety a central lever and name the stigma around asking for help when AI wrote the code. - Improve: give leaders a concrete script or a rule of thumb for a first response when a junior admits they don't understand generated code. ## ✅ Logical validity This is an opinion and advocacy piece, so the assessment weights internal coherence and how far the claims exceed the evidence offered. #### Strong reasoning - **Causal loop, ¶14.** The confidence-deference-fewer-practice-chances chain is coherent, and each link is plausible. To strengthen it, name a way to measure each link. - **Analogy, ¶9-¶10.** Knowing steps versus riding the bike fits a real distinction between declarative and procedural knowledge, and it supports the narrow claim that frameworks alone don't build the skill. - **Distinction, ¶6-¶7.** Code as a byproduct of judgment explains why cheaper code raises the value of judgment. It follows without needing outside data. - **Practical inference, ¶22-¶24.** If review, RFCs and incident work already force reasoning, protecting them costs little. This holds as a low-cost recommendation, whatever the size of the underlying problem. - **Balanced framing, ¶13 and ¶35.** The author concedes that AI removes unproductive friction and that "we don’t need to recreate the pain." That limits overreach. #### Fallacies - **Anecdotal evidence, ¶1 and ¶32.** The author's early project supplies the model for how skill develops, and the closing anecdote at ¶32 reuses it. One person's path isn't a sample. Fix: cite the linked LeadDev report or a study, or state the limit. - **Unsupported empirical claim, ¶15.** "Plausible implementations are hitting production with unvalidated assumptions that crumble under real user pressure." No rate, count or example appears in the captured text, and the linked report's contents aren't visible here. Fix: quote a figure from the report or drop the claim to "in my experience." - **Nostalgia or golden-age framing, ¶2 and ¶12.** The past learning environment is described as producing judgment through natural friction. That ignores juniors who never got good mentoring before AI. Fix: acknowledge that the old system had uneven outcomes. - **False dilemma risk, ¶13-¶14.** The piece frames the outcome as friction traded for productivity. AI can also free time for harder problems, and the author doesn't test that alternative. Fix: state what evidence would show freed time going to higher-level work. - **Untested remedy, ¶26-¶27.** The claim that a coaching-configured AI preserves learning has no cited support. Fix: label it a hypothesis and propose a test. - **Conflict of interest, not stated.** LeadDev's link list points to several commercially adjacent pages, including a coding assistants comparison and a buying checklist. The captured text has no disclosure statement. Fix: a one-line note on relationships, if any. #### Tone of voice - Reflective and advisory. First person for anecdote (¶1, ¶25, ¶32) and second person for instruction (¶19, ¶21, ¶24: "Make sure juniors have the chance to get on that bike!"). Aphoristic closers ("Some friction was drag. Some friction was education.") land the message with rhythm instead of data. It reads as a mentor addressing peers. ## 🛡️ DARVO analysis Not applicable to this source. DARVO describes a defensive response to an accusation, and this is a leadership opinion piece with no accuser, no accusation and no defensive posture. For completeness: **Deny.** Nothing is denied, and the author concedes AI's benefits (¶13). **Attack.** No critics or groups are attacked, and juniors are framed as products of a changed environment, not as at fault (¶17). **Reverse victim/offender.** No such move appears. The nearest edge is the framing of juniors as needing protection from an environment, which recasts a skills concern as a structural one, and the text does so explicitly and without blame. ## 🎯 Conclusion The article's durable point is a mechanism: when AI supplies answers before an engineer has tried, the engineer gets fewer chances to build judgment, and confidence and deference then reinforce each other (¶14). The five remedies are cheap and don't depend on the premise being proven: define critical thinking, keep it safe to say "I don’t understand what the AI generated" (¶21), protect review and incident work, configure AI to question, and write reasoning behaviors into career frameworks. The evidence is thin. The captured text is opinion built on the author's anecdote, and the only data-shaped link is an anchor on ¶15 to a LeadDev leadership report whose contents aren't in the capture. Two parts of the capture are missing: the "Key takeaways" bullets (¶0) and the junior's-day content (¶11). **Next steps for readers:** try the ¶26 prompts on your own workflow for one week and note what you'd have missed. If you manage juniors, draft three observable reasoning behaviors per level using ¶30 as the pattern. Before citing the article's claim about production impact, read the linked engineering leadership report yourself. ## 🔄 Refactor Appendix — AI makes critical thinking harder to build in junior engineers > Density: 2–5 Literature atoms (H3 pad), 0–3 Permanent candidates (H4 pad). > Emitted: 5 Literature, 2 Permanent. Resonance filter applied: the anecdote atoms > (¶1, ¶25, ¶32) were dropped as single-source experience. > > Konik claim-header rules: present tense, declarative, ≤10 words, searchable, unique. > > Atomicity: one declarative sentence per atom. "and"/"also" → split. > > Tag pool: #bmf · #addendum · #xref · #articleseed · #storystem · #share · #aphorisms ### 📚 Literature Split Pad #### [H1] Deference to AI starves judgment > [!quote] [¶14] > the less confidence an engineer has in their own judgment, the easier it is to defer to generated answers. **Context & use**: - ¶14, the center of the article's causal argument. - The loop is plausible but untested in the captured text. Keep the claim paired with a note that no data accompanies it. **Tags**: #xref #articleseed <!-- atomicity: 1 idea ✓ --> #### [H2] Code is a byproduct of critical thinking > [!quote] [¶6] > Code was never the whole job. It is just one artifact left behind by countless acts of creativity and discernment. **Context & use**: - ¶6, explaining why cheaper code raises the value of judgment. - Useful as a short framing in mentoring and docs about AI-assisted work. **Tags**: #xref #aphorisms <!-- atomicity: 1 idea ✓ --> #### [H3] Existing rituals already teach critical thinking > [!quote] [¶22] > The best opportunities to build critical thinking are already embedded in standard engineering rituals. **Context & use**: - ¶22, leading into the code review, RFC, incident response and debugging list. - Supports a low-cost recommendation: protect what exists before adding process (¶24). **Tags**: #xref #share <!-- atomicity: 1 idea ✓ --> #### [H4] Keep the cognitive work in the loop > [!quote] [¶26] > Instead, keep the cognitive work in the loop. **Context & use**: - ¶26, contrasting a "human in the loop" who approves suggestions with an engineer who does the reasoning. - The remedy is untested in the source, so treat it as a hypothesis to try. **Tags**: #xref #addendum <!-- atomicity: 1 idea ✓ --> #### [H5] AI use must not raise the stakes of asking > [!quote] [¶21] > Don’t let the use of AI change the stakes for learning in public. **Context & use**: - ¶21, in the psychological safety passage about admitting "I don’t understand what the AI generated." - Directly usable as a team-norm line. **Tags**: #xref #share <!-- atomicity: 1 idea ✓ --> ### 🧠 Atomic Split Pad #### [P1] Practice, not explanation, builds judgment **Claim** (one sentence, Courtney's voice): A junior builds judgment by making and correcting calls on real work, so any tool that removes the calls removes the learning. **Evidence pointer**: [[#H1]] · [[#H2]] **Scope & conditions**: Holds for skills learned by doing, like tradeoff reasoning and debugging. It weakens when the removed work was pure rote with no decision in it, and the source gives no way to tell the two apart in advance. **Links**: - [[Deliberate practice]] — because extends - [[Human in the loop versus cognitive work in the loop]] — because contrasts on who does the reasoning - [[Mentoring junior contributors]] — because applies-in WordPress contributor onboarding <!-- atomicity: 1 idea ✓ --> #### [P2] Safety covers AI-assisted work **Claim** (one sentence, Courtney's voice): A team that punishes "I don't understand this generated code" teaches juniors to hide gaps instead of closing them. **Evidence pointer**: [[#H5]] · [[#H3]] **Scope & conditions**: Applies where juniors face review or performance pressure. It doesn't cover cases where the admission is used against the person, which needs a policy fix outside the team norm. **Links**: - [[Psychological safety]] — because extends - [[Code review culture]] — because applies-in review comments on AI-authored changes - [[AI-assisted contribution policy]] — because evidence-for disclosure norms <!-- atomicity: 1 idea ✓ --> ### ✏️ Fleeting Queue - [F1] Read the LeadDev engineering leadership report 2026 linked at ¶15 to see whether it supports the production-impact claim, https://leaddev.com/the-engineering-leadership-report-2026/ #fleeting #inbox - [F2] Recover the "Key takeaways" bullets (¶0) and the junior's-day content (¶11) from the live page, since both dropped out of capture #fleeting #inbox - [F3] Try the ¶26 prompts (challenge an assumption, argue an alternative, interview me) on one week of my own AI-assisted work and log what I'd have missed #fleeting #inbox - [F4] Article seed: "Some friction is drag, some is education." How to tell which is which in a contributor workflow #fleeting #inbox #articleseed - [F5] Draft three observable reasoning behaviors per level for a contributor ladder, using the ¶30 pair as the pattern #fleeting #inbox ### → Things 3 (max 2 actions) - [ ] Read the linked LeadDev engineering leadership report and note which figures support the ¶15 claim, reading, 20 min #things - [ ] Try the three AI questioning prompts from the article for a week and log results, AI workflow practice #things <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/AI Makes Critical Thinking Harder to Build.md|AI Makes Critical Thinking Harder to Build by LeadDev]] ## Highlights - AI makes lines of code quicker and cheaper than ever, meaning the importance of critical thinking is growing too. Code was never the whole job. It is just one artifact left behind by countless acts of creativity and discernment. A byproduct of critical thinking. ([View Highlight](https://read.readwise.io/read/01m3psd99jet547k3jw0x90ge1)) - Note: [H2] Code is a byproduct of critical thinking - Tags: atom/literature/h2 - Over time, there is a risk that thinking is traded off for productivity, and a troublesome feedback loop emerges: the less confidence an engineer has in their own judgment, the easier it is to defer to generated answers. The more cognitive work they defer, the fewer occasions they have to build judgment. ([View Highlight](https://read.readwise.io/read/01m3psd6kyt86p8gvh18g514fh)) - Note: [H1] Deference to AI starves judgment - Tags: atom/literature/h1 - Psychological safety should mean you feel supported to try, and to fail, even if you used AI along the way. When AI can create a full implementation in seconds, there can be undue shame and stigma in admitting you need help. Ask yourself, can engineers on my team openly say “I don’t understand what the AI generated.” Don’t let the use of AI change the stakes for learning in public. ([View Highlight](https://read.readwise.io/read/01m3psdgtp498c0y3tq58x2d9y)) - Note: [H5] AI use must not raise the stakes of asking - Tags: atom/literature/h3 - The best opportunities to build critical thinking are already embedded in standard engineering rituals. Code reviews, RFCs, incident response, and debugging are not just mechanisms for improving the quality of software – they are the “bike riding” of software development. ([View Highlight](https://read.readwise.io/read/01m3psdc0hbg6tfb5kdabb7r6b)) - Note: [H3] Existing rituals already teach critical thinking - Tags: atom/literature/h3 - AI can play a similar role if we use it to prompt thinking rather than replace it. Coach junior engineers to use AI for more than being a “human in the loop” – accepting suggestions and approving actions. Instead, keep the cognitive work in the loop. Ask an AI assistant to challenge an assumption, argue an alternative, or interview the engineer about their approach before offering a solution. ([View Highlight](https://read.readwise.io/read/01m3psden71j4nx6jcgc2ee697)) - Note: [H4] Keep the cognitive work in the loop - Tags: atom/literature/h3