The Human in the Loop  🔗 **Source:** [The Human in the Loop](https://pento.net/2026/04/07/the-human-in-the-loop/) > [!note]+ Document Notes > tags: [AI, software-engineering, code-review] > author: [MISSING] > source: Adventures in Nodeland > reference: [https://adventures.nodeland.dev/archive/the-human-in-the-loop/?ref=dailydev] > date created: 2026-01-18 12:00 > > # 🏷️ Title: The Human in the Loop > <!-- 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) ### 🔗 References - Include links cited in or relevant to the article. --- ## 📝 Summary - What happened: The author explains how AI now writes most of their code, while they focus on reviewing, judging, and taking responsibility for what ships. - Why it matters: The bottleneck in software moves from typing to judgment and review, changing roles, practices, and risk profiles. - Key stakeholders: Software engineers, architects, maintainers, orgs adopting AI coding tools, and users of AI-built systems. - Risks and tradeoffs: Speed and volume of AI-generated code amplify security, reliability, and accountability risks if review culture weakens. - Bottom line: AI is a powerful contributor, but the “human in the loop” providing judgment, context, and accountability is not a bug to remove—it’s the core feature. --- ## 📖 Main Content - Core argument: AI has transformed development by handling routine implementation, but professional responsibility now centers on reviewing AI output, understanding systems, and owning consequences. - Bottleneck shift: The author contrasts “two hours, zero lines reviewed” demos with their own practice, where every AI change is inspected for security, architecture fit, and behavior. - Value of expertise: Expensive, high-stakes products (e.g., Bloomberg Terminal) cost money not because code is hard to type, but because experts stand behind it with deep domain and failure-mode knowledge. - Practices in flux: Traditional processes—code review for human-written code, sprint estimates tied to typing speed, “more devs → more output”—must be rethought for AI-produced code. - Role evolution: “Jira task doer” programmers fade; software engineers and architects who design systems, provide judgment, and review contributions (including AI’s) become central. - Open source analogy: Maintainers already act mainly as reviewers, assessing code from many contributors; AI is framed as just another contributor whose work must be understood before merging. - Responsibility: The author emphasizes “my name is on it” and rejects “the AI wrote it” as an excuse for bugs or vulnerabilities. - Societal parallel: Like the Industrial Revolution, AI makes production abundant but also introduces new, scaled failure modes; we need safety practices and culture around industrial-scale code generation. - Key claim: In 2026, the critical skill is judgment—pattern recognition, mental models of failure, and effective verification—not just prompting or building complex agent setups. --- ### 🗒️ Notes - AI now writes most of the author’s fixes and features, but they “review every single change. Every behavior modification. Every line that ships.” - The bottleneck has moved from coding speed to review skill: the ability to detect edge cases, security holes, and architectural mismatches. - Building complex tools without reviewing code is critiqued: the real question is who understands it, who debugs it at 3 AM, and who owns errors. - Expensive systems derive value from embedded expertise and responsibility, not just from code complexity. - Forty years of “best practices” built around human-written code, sprint velocity, and headcount scaling are obsolete in an AI-first world. - The “Jira task doer” role is effectively automated; enduring roles emphasize design, architecture, and judgment. - Open source maintainers already operate in a review-first mode, evaluating contributions from many unknown authors; AI fits naturally into this model. - Shipping code you don’t understand leads to harder bugs, opaque behavior, and compounded technical debt; AI can magnify this via speed. - Some developers underestimate AI (assuming jobs are safe because AI errs); others overestimate it (assuming humans in the loop are temporary). - The author insists the human in the loop is the whole point: accountability for vulnerabilities and bugs cannot be outsourced. - Main fear: a culture where “I didn’t review it, the AI wrote it” becomes acceptable, enabling large-scale, AI-speed failures. - Industrial Revolution analogy: abundance plus new accident types and pollution; we similarly need norms, regulations, and safety practices for AI code. - Path forward: embrace AI, but invest heavily in review capabilities—faster pattern recognition, better failure-mode models, and efficient verification. - 2026’s key competency is judgment, not just prompting skills or agent infrastructure wizardry. --- ## 📚 References - [The Human in the Loop](https://adventures.nodeland.dev/archive/the-human-in-the-loop/?ref=dailydev) - Background on Bloomberg Terminal pricing and value proposition (for context, not cited directly in the article). - Literature on AI-assisted programming tools (e.g., GitHub Copilot, code LLMs) and their impact on developer workflows. --- ## 🗣️ Paraphrase - Paragraph A: The author uses AI extensively for coding tasks but insists on manually reviewing every AI-produced change, framing review and responsibility as central to their role. - Paragraph B: They argue that AI changes which skills matter: understanding systems, anticipating failures, and making responsible decisions about what to ship now define professional software engineering. --- ## 📰 Newsletter In this week’s WordPress-adjacent read, “The Human in the Loop” dives into how AI is reshaping what it means to be a developer. The author treats AI as a prolific contributor while doubling down on human review, architectural judgment, and accountability—skills that matter just as much in the WordPress ecosystem as in Node. If you’re experimenting with AI-assisted plugin or theme development, this is a timely reminder: fast code generation is only half the story. The other half is robust review—security, performance, backward compatibility, and UX. Looking to sharpen those skills? - Explore WordPress developer docs for best practices on [plugin security](https://developer.wordpress.org/plugins/security/) and [performance](https://make.wordpress.org/core/tag/performance/). - Try pairing AI-generated patches with automated tests in tools like [WordPress Playground](https://developer.wordpress.org/playground/) for quick, safe experimentation. - Join community discussions in [Make WordPress Slack](https://make.wordpress.org/chat/) to share patterns for safely reviewing AI-generated code. As AI gets better at writing PHP, JS, and block code, our job is to get better at deciding what should ship—and standing behind it. --- ## ✅ Action Items #### DevRel - Develop talks and blog posts on “AI as contributor, humans as reviewers” tailored to plugin/theme authors and enterprise WordPress teams. - Create workshops and office hours on reviewing AI-generated pull requests, with hands-on exercises in GitHub/GitLab. - Improve developer experience by adding example repos that show safe AI-assisted workflows (tests first, review checklists, rollback strategies). - Run targeted campaigns highlighting success stories where AI sped delivery but human review prevented serious regressions. - Survey community contributors about current AI use and pain points, feeding insights back into docs, tooling, and talks. - Align internal teams on clear guidance for acceptable AI use in code contributions and support responses. #### OSPO - Update contribution policies to clarify expectations for AI-generated patches, including required attribution and review depth. - Integrate license scanning and AI-content flags into existing compliance pipelines and training. - Extend security processes to explicitly handle AI-generated code, including triage for systemic AI-introduced vulnerabilities. - Track AI-assisted code in SBOMs where possible and maintain ownership for high-risk components. - Offer office hours on AI safety, licensing, and contribution norms for maintainers and contributors. - Coordinate with upstream projects on shared AI-governance patterns and disclosure expectations. - Report to leadership on AI’s impact on throughput, risk, and maintenance load. #### Community - Help maintainers adopt review-first workflows, with governance templates that address AI-generated contributions. - Provide “first AI-assisted issue” paths and pairing sessions for contributors to learn safe patterns. - Give sponsors visibility into how AI is used in funded work, including risk management and review practices. - Run cross-project incident drills focused on AI-induced bugs and coordinated disclosures. #### WordPress - Core: Incorporate AI-related considerations into issue triage and release criteria (e.g., extra scrutiny for large code drops). - Core Performance: Benchmark performance of AI-generated patches and track regressions introduced through automated changes. - Core AI: Define responsible AI guidelines, evaluation sets, and review gates for any AI features in core. - Core Program Team: Add recurring check-ins on AI tooling, contributor education, and cross-team dependencies. - Mobile: Evaluate AI-assisted code changes in apps with extra attention to offline behavior and data handling. - Playground: Provide labs demonstrating good patterns for testing AI-generated code safely in-browser. - Community: Include AI topics in meetup kits and WordCamp content, with emphasis on responsibility and review. - Training: Build learning paths on AI-assisted development, including “how to review AI code.” - Marketing: Frame AI content around empowerment plus accountability, avoiding hype that downplays review. - Support: Document safe responses when users mention AI-created snippets that break sites. - Design: Add UX guidelines for AI-driven features to ensure transparency and control. - Documentation: Add examples showing how to document AI-generated behavior and known limitations. - Photos/TV/Openverse: Clarify AI policy in submission guides and moderation workflows where relevant. - Polyglots: Coordinate messaging around AI translation tools and the need for human review. - Accessibility: Audit any AI-generated UI or content flows for WCAG alignment. - Meta/CLI/Hosting/Tide/Themes/Plugins: Integrate AI-awareness into checklists, scoring, review queues, and tooling, especially around provenance and security. #### The WPOCC - Programs: Offer fellowships or stipends for maintainers experimenting responsibly with AI in their projects. - Projects: Host documentation sprints focused on adding AI-usage and review policies. - Funding experiments: Pilot grants for AI-safety tooling (linters, test harnesses, review dashboards) in the WordPress ecosystem. ### FAIR - Promote technical independence by ensuring local analysis of AI-generated code provenance and signatures where possible. - Encourage transparent AI-funding disclosures and sunset clauses around experimental AI infrastructure. - Package governance artifacts—AI usage policies, review scorecards, incident templates—as reusable resources for projects. --- ## 🧪 Hypotheses - H1: Teams that treat AI as a contributor and invest in stronger review practices will experience fewer severe production incidents than teams that minimize human review. - H2: The adoption of AI coding tools will reduce time spent on routine implementation but increase time spent on design and code review. - H3: Developers who have strong mental models of failure modes derive more benefit from AI-assisted coding than those who do not. - H4: Organizations that fail to define accountability for AI-generated code will see higher rates of security and compliance issues. - H5: Explicit cultural norms against “the AI wrote it” excuses will correlate with better long-term code quality. --- ### 📊 Methodology - Study design: Mixed-methods; compare teams with different AI and review policies over 6–12 months. - Data sources: Version control history, incident reports, postmortems, time tracking, survey responses, and static analysis metrics. - Analyses: - Quantitative: Regression analysis of incident frequency/severity vs. review depth and AI usage intensity. - Qualitative: Thematic analysis of postmortems and interviews to identify patterns in judgment, responsibility, and failure modes. - Case studies: In-depth reviews of major AI-related incidents and near-misses. --- ### ❓ Questions - How much human review is “enough” for AI-generated code in different risk domains? - Which specific review skills (security, architecture, testing) benefit most from targeted training in an AI-heavy workflow? - How should accountability be assigned when AI tools are deeply integrated into standard development pipelines? - What organizational incentives encourage or discourage thorough review of AI-generated changes? - How can we detect and mitigate systemic errors introduced by AI models across many codebases? --- ### 🔮 Future Research - Develop standardized metrics for AI-review adequacy and their correlation with real-world outcomes. - Explore tooling that helps reviewers quickly understand AI-generated code (explanations, provenance, risk flags). - Investigate how open source governance models can best incorporate AI contributors. - Study long-term effects of AI on skill development for junior engineers. - Examine regulatory frameworks for accountability in AI-generated software used in critical industries. --- ### 💡 Implications - Practice: Teams should reorient processes around code review and architectural judgment rather than raw coding throughput. - Policy: Organizations need explicit AI usage and accountability policies; regulators may require audit trails of AI involvement. - Security: Threat models must incorporate AI-generated vulnerabilities and the speed at which they can spread. - Education: Curricula should emphasize systems thinking, failure modes, and review techniques alongside coding. - Funding models: Investment in safety tooling, review training, and governance may become as important as investment in AI capabilities. --- ### 🧠 Learning Styles Assessment - Reading level estimate: Approximately upper high school / early college (Flesch-Kincaid around grade 11–12; conversational but conceptually dense). #### 👀 Visual learners - Present: Mostly text; conceptual contrasts (bottleneck shift, Industrial Revolution analogy) but no visuals. - Improve: Add diagrams showing old vs. new workflows, responsibility chains, and failure-mode trees. #### 🔊 Aural learners - Present: No audio version indicated. - Improve: Provide a short audio narration or podcast-style discussion summarizing the argument. #### 🗣️ Verbal learners - Present: Clear explanations, analogies (Bloomberg Terminal, Industrial Revolution), direct statements of thesis. - Improve: Add a short glossary of terms like “human in the loop” and “failure modes.” #### 🧩 Kinesthetic learners - Present: Implicit suggestions (review practices) but no interactive elements. - Improve: Provide step-by-step exercises where readers review AI-generated code examples. #### 🧠 Logical learners - Present: Causal reasoning (AI → new bottlenecks → new risks), structured contrasts between roles. - Improve: Include explicit decision trees for when AI output is safe to ship. #### 🧑‍🤝‍🧑 Social learners - Present: References to community practices (open source maintainers, teams). - Improve: Add discussion prompts or suggested team workshops on AI review norms. #### 🧘‍♀️ Solitary learners - Present: Reflective tone that invites personal consideration of one’s own workflow. - Improve: Include reflection questions about current AI use and accountability. #### 🌿 Naturalistic learners - Present: Industrial Revolution analogy hints at systemic impacts. - Improve: Extend analogies to ecosystems and lifecycle thinking (e.g., long-term maintenance, “pollution” as technical debt). --- ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Article likely uses basic headings and paragraphs. - Improve: Ensure clear heading structure and descriptive link text; add language attributes. #### Keyboard navigation - Present: Standard web article should be keyboard-navigable. - Improve: Confirm visible focus states and skip links for content-heavy pages. #### Contrast and readability - Present: Depends on site theme, but text-first layout is generally favorable. - Improve: Verify sufficient contrast, line height, and font size; avoid long, unbroken paragraphs. #### Text resizing and reflow - Present: Modern blog themes usually reflow text. - Improve: Test at 200%+ zoom and on mobile; respect prefers-reduced-motion. #### Media and captions - Present: Primarily text; minimal media. - Improve: If any diagrams are added, ensure alt text and captions. #### Forms and interactions - Present: Likely minimal (maybe comments or newsletter sign-up). - Improve: Ensure labels, error messaging, and large-enough click targets. #### Standards reference - Map improvements to WCAG 2.2 AA criteria, particularly for perceivable (1.4.x), operable (2.1.x, 2.4.x), and understandable (3.1.x, 3.2.x). --- ### 🌍 DEIB Assessment #### Cultural breadth - Present: Focuses on software development culture; largely Western/industry-specific context. - Improve: Include examples from diverse regions and types of software work. #### Inclusive language - Present: Generally neutral and professional. - Improve: Further define jargon for readers from non-traditional or cross-disciplinary backgrounds. #### Neurodiversity support - Present: Clear structure but dense conceptual jumps. - Improve: More frequent headings, summaries, and bullet lists to break up concepts. #### Representation - Present: Single-author perspective; no explicit representation in imagery. - Improve: Use examples and anecdotes that reflect a broader range of roles and experiences. #### Psychological safety - Present: Emphasizes responsibility but could be heavy for juniors worried about mistakes. - Improve: Frame learning from errors and provide guidance for building skills safely. --- ### ✅ Logical Validity #### Strong reasoning - The bottleneck shift argument is a strong causal claim: as AI speeds coding, review and judgment become the limiting factors, supported by the author’s workflow experience. - The Industrial Revolution analogy effectively highlights that new production capabilities create both abundance and new categories of risk, motivating the need for new safety norms. #### Fallacies - Some generalizations about “the role of the programmer who takes a task from Jira” being gone may overstate current reality; this could be softened by specifying domains or time horizons. - The critique of “zero-code review” demos may verge on a straw man if not all such demos claim production readiness; clarifying scope would strengthen the argument. #### Tone of voice - Tone is confident, pragmatic, and cautionary: it embraces AI’s benefits while firmly insisting on human responsibility and judgment. --- ### 🛡️ DARVO Analysis - Deny: The article does not deny harms; it explicitly acknowledges increased risk from AI-scale production. - Attack: It critiques ideas (e.g., unreviewed AI tooling) rather than attacking individuals; no strong personal attacks. - Reverse victim/offender: The author does not present developers as victims of AI; instead, they emphasize ongoing responsibility. - Overall: No significant DARVO patterns; the piece argues for accountability and stronger safety culture. --- ## 🎯 Conclusion The article contends that while AI now writes much of the code, the crucial, non-automatable work is human judgment: reviewing, understanding, and owning what ships. Software practices and roles must adapt to this new bottleneck. For readers, the practical next steps are to embrace AI as a powerful assistant while investing seriously in review skills, safety practices, and clear accountability for AI-generated code. --- ## 🧱 Refactor Appendix ### 📚 Literature Split Pad - Purpose: Stage Konik CEE units that become per-source Literature notes. - Split level: H3. - Include verbatim quotes under 25 words and a [view highlight] link. ### [H1] 5–10-word present-tense claim > [!quote] [The Human in the Loop](https://adventures.nodeland.dev/archive/the-human-in-the-loop/?ref=dailydev) by an unnamed author via [[Adventures in Nodeland]]. Published 2026-01-18. Accessed 2026-01-18. > “AI has changed my coding process, but I stand by my role in analyzing each AI-generated output.” Two lines: context and use. Cite data if relevant. [view highlight](https://adventures.nodeland.dev/archive/the-human-in-the-loop/?ref=dailydev#H1) #xref #articleseed ID:rw_[MISSING] ### [H2] 5–10-word present-tense claim > [!quote] [The Human in the Loop](https://adventures.nodeland.dev/archive/the-human-in-the-loop/?ref=dailydev) > “The human in the loop isn’t a limitation. It’s the point.” Two lines: context and use. [view highlight](https://adventures.nodeland.dev/archive/the-human-in-the-loop/?ref=dailydev#H2) #xref ID:rw_[MISSING] --- ### 🔖 Atomic Split Pad (Zettel Candidates) - Purpose: Promote reusable claims into Atomic notes. - Split level: H4. - Each item: one idea, present tense, specific, testable. #### [Z1] Human review remains core software bottleneck - Scope/condition in one line. - Pointer to page/time or dataset. - Links: [[AI-Development]] [[Code-Review]] #### [Z2] AI amplifies both productivity and risk - Scope/condition in one line. - Pointer to page/time or dataset. - Links: [[AI-Development]] [[Risk-Management]] --- ### ✏️ Fleeting Queue (Extract by Selection) - Purpose: Capture quick actions or sparks for Fleeting notes. - Extraction: Select one line → “Refactor: Extract selection to new note (content only).” - Keep each line short and self-contained. - [F1] Draft a checklist for reviewing AI-generated code — context/https://adventures.nodeland.dev/archive/the-human-in-the-loop/?ref=dailydev #fleeting #inbox - [F2] Map Industrial Revolution safety analogies to software practices — context/https://adventures.nodeland.dev/archive/the-human-in-the-loop/?ref=dailydev #fleeting #inbox - [F3] Design a workshop on “AI as contributor, you as maintainer” — context/https://adventures.nodeland.dev/archive/the-human-in-the-loop/?ref=dailydev #fleeting #inbox --- <!-- deep-read:sections end --> 📄 **Full text:** ![[Full Document Contents/Articles/The Human in the Loop|The Human in the Loop, pento.net]] ## Highlights - If I want you to read this post, and seriously consider the arguments I’m making, the least I can do is write it myself. It goes beyond that, however. LLMs can write functional code, but they can’t write beautiful software. When the text *is* the creative act, there’s no way for the LLM to write the text without compromising your creativity. If you’re the Human in the Loop for a blog post, you’re not injecting your voice, your perspective, or your personality into the post: you’re rubber stamping whatever feels good enough, and that’s a very low bar to clear. ([View Highlight](https://read.readwise.io/read/01knwvarj0nmkqs2vty1fbypqq)) - Tags: 👻 ai highlighted