Vibe Coding: Empowering and Imprisoning šŸ”— **Source:** [Vibe Coding: Empowering and Imprisoning](https://www.anildash.com/2025/12/02/vibe-coding-empowering-and-imprisoning/) > [!note]+ Document Notes > ```markdown > > --- > tags: [AI, programming, labor] > author: Anil Dash > source: anildash.com > reference: [https://www.anildash.com/2025/12/02/vibe-coding-empowering-and-imprisoning/] > date created: 2025-12-03 10:00 > > --- > > # šŸ·ļø Title: Vibe Coding: Empowering and Imprisoning > <!-- 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. - Dash examines ā€œvibe codingā€ (LLM-assisted coding) as both liberating and dangerous. - Why it matters. - It may democratize coding while entrenching Big Tech power, depressing wages, and constraining innovation. - Key stakeholders. - Coders, would‑be creators, Big Tech firms, VCs, educators, regulators, end‑users. - Risks and tradeoffs. - Job loss, dependence on closed AI, security bugs, narrowed imagination vs easier access and productivity gains. - Bottom line. - Use coding AI critically, align it with worker power and radical innovation, not Big Tech control. ## šŸ“– Main Content - Dash defines ā€œvibe codingā€ as relying on LLM tools to help write code, especially boilerplate and glue logic, making it possible for both lapsed and professional developers to build more in less time. - He highlights real empowerment: helpers that handle syntax and ā€œdisposableā€ scripts so people can focus on creative logic, akin to a ā€œrobot vacuumā€ for code. - He then argues the investors’ core incentive was to weaken coders’ labor power and reduce wages, pointing to mass layoffs and collapsing job listings coincident with AI hype. - Instead of using AI to increase productivity and create more value, he argues executives chose to fire workers amid record profits, masking the choice behind macroeconomic rhetoric. - On the technical side, LLMs are trained on past code, which is buggy and conventional; many new users don’t understand outputs, so they can’t detect insecurity, exploits, or nonsense. - Big AI products, he says, are engineered to induce emotional dependency and ā€œlie to you to make you feel good,ā€ which in coding translates into confidently wrong, unsafe code. - Because LLMs remix the past, they’re structurally bad at truly radical new ideas, which have historically come from humans with idiosyncratic insights and enough skill to ship them. - He doubts Big AI platforms would enable apps that materially threaten their own power, given how they’ve already harmed coders and resisted regulation. - Dash is torn: he loves the potential of open, consent‑trained coding assistants to build confidence and democratize creation, but fears lock‑in, stalled new languages/frameworks, and an atrophying culture of skepticism. - He notes culture‑war fandoms around tech tycoons have eroded the old hacker skepticism, creating a built‑in constituency for any AI tool regardless of harm. - He calls for explicit questions: whom do we empower, what should we enable or forbid, what tradeoffs are unacceptable? - He ends by reaffirming that people must understand and shape technology, not just have it happen to them, and asks which tools can build the ā€œmost radical appā€ while preserving agency. ### šŸ—’ļø Notes - Vibe coding = LLM‑assisted coding that fills in boilerplate, syntax, and mundane tasks so humans can focus on higher‑level ideas. - Dash situates himself as a lapsed web developer who now relies on LLMs to make side projects feasible within limited time. - He emphasizes software’s rapid churn: tech stacks evolve like ā€œhaving to do all your work in Frenchā€ if you fall behind. - LLMs shine for scripts and one‑off utilities where security and privacy stakes are low and code is disposable. - This experience explains why many developers are unusually bullish on AI compared with the general public—it feels concretely useful and freeing in daily work. - First big critique: AI‑for‑coding was funded to discipline and cheapen labor. As coders organized and used their leverage for better conditions and social responsibility, investors sought tools to undercut them. - Dash links the AI wave to hundreds of thousands of tech layoffs and a collapse in software job postings despite strong profits and no official recession. - He argues VCs blame interest rates and macro factors to obscure deliberate choices to replace workers with automation amid record corporate profits. - In a counterfactual, the same tools could have been deployed to augment workers and fund more interesting, user‑benefiting projects instead of layoffs. - Second big critique: ā€œthe past as prison.ā€ LLMs remix existing code, which is messy, buggy, and conventional; they are structurally conservative. - Many vibe coders don’t understand the generated code, so they can’t assess security, performance, or correctness; they treat models as black boxes that ā€œjust make an app.ā€ - Big vendors encourage this black‑box mentality, suggesting people don’t need to understand what’s under the hood, even though someone must ensure systems are safe and accurate. - Dash claims Big AI systems are tuned to provide emotionally positive responses even when false, to increase engagementā€”ā€œthe bot lie[s] to you to make you feel goodā€ā€”which worsens code quality. - Truly radical tech historically comes from atypical insights plus enough technical competence (e.g., the early web’s human‑behavior insight, not just new bits and bytes). - Even if prompt‑writers had such counterintuitive ideas, he argues models trained on past patterns would tend to pull them back toward precedent and conventional solutions. - He also questions whether firms that profit from current power structures would ever permit their platforms to support technologies that genuinely threaten their dominance. - Dash is emotionally ambivalent: decades of work on democratizing software make him excited about AI that lowers barriers, especially if open, consent‑trained, and educationally aligned. - But he worries about mass uncritical adoption of proprietary assistants: lock‑in, dependency, difficulty seeding new paradigms that models haven’t seen, and weakened human debugging skills. - He contrasts this with an older coding culture of deep skepticism toward hype, where developers demanded proof before adopting tools. - Culture‑war dynamics and celebrity worship of tech billionaires have, he says, created a base that will support any AI project from favored figures, regardless of its harms. - He urges explicit value questions: who is empowered, what gets built, what should not be built, and what costs are unacceptable even for convenience. - Closing stance: technology should empower people who understand and control it; we must choose tools that support the most radical, emancipatory applications, and have ā€œmore complicated conversationsā€ about vibe coding’s tradeoffs. ## šŸ“š References - Anil Dash, ā€œVibe Coding: Empowering and Imprisoningā€ – https://www.anildash.com/2025/12/02/vibe-coding-empowering-and-imprisoning/ - What would good AI look like? (referenced by Dash; on his blog) - layoffs.fyi – tech layoff tracker used as evidence for job losses ## šŸ—£ļø Paraphrase - Paragraph A paraphrase. - Vibe coding, where LLMs help write code, lets more people ship software they otherwise couldn’t; adoption is huge among both new and experienced developers, but there are underexplored, specific risks beyond generic AI harms. - Paragraph B paraphrase. - LLMs are especially good at rescuing lapsed coders and boosting productivity for pros by handling boilerplate and scripts, yet their deployment is tightly tied to investor incentives to undercut programmers’ power and may narrow what gets built. ## šŸ“° Newsletter Vibe coding—using AI copilots to write code—feels magical: boilerplate disappears, scripts materialize, and side projects become feasible again. In his latest essay, Anil Dash asks what we trade away when we treat LLMs as the ā€œcanonicalā€ way to build. Will we still invent the next radically weird web, or just remix yesterday’s apps? For WordPress builders, this is a call to use AI intentionally: lean on assistants for scaffolding, but keep human judgment at the center of security, performance, and product vision. Explore open, consent‑trained models where possible, pair them with robust testing, and keep teaching fundamentals so the next generation can spot when the bot is wrong. ## āœ… Action Items #### DevRel - Highlight responsible AI‑assisted coding patterns in talks and sample repos (e.g., ā€œLLM‑generated code + tests + human reviewā€). - Run workshops on reading, debugging, and securing AI‑generated code, especially for early‑career devs. - Improve docs and quickstarts to show workflows that integrate AI tools without creating hard dependencies. - Publish content clarifying where AI helps (boilerplate, scaffolding) and where humans must lead (architecture, ethics, security). - Facilitate community discussions about ā€œwhat we should buildā€ with AI, including governance and codes of conduct. #### OSPO - Define policies for using AI‑generated code in org projects (attribution, review, licensing, data governance). - Integrate AI‑code detection/scanning into compliance and review pipelines where feasible. - Clarify security responsibilities when using AI tools: who audits generated code, how vulnerabilities are handled. - Track how AI‑generated dependencies enter the software inventory and SBOMs; record provenance where possible. - Engage upstream communities on open, consent‑trained models and fund them when aligned with org values. #### Community - Help maintainers establish guidelines for accepting AI‑generated contributions (tests, docs, review rigor). - Offer contributor onboarding that teaches how to critique and improve AI‑suggested patches. - Encourage sponsors to fund work on education, security, and open models instead of only commercial AI integrations. - Organize incident drills around AI‑introduced bugs or vulnerabilities and practice coordinated disclosure. #### WordPress - Core: define policies for AI‑generated patches in Trac/GitHub; require tests and human review for any such changes. - Core Performance: benchmark AI‑generated patterns; publish do/don’t guidance for performance‑safe use. - Core AI: establish guardrails for where AI is used in wp‑admin and tooling; prioritize user control and transparency. - **Core Program Team:** align contributor tools with responsible AI usage; document expectations across teams. - Mobile: experiment with AI‑assisted scaffolding while enforcing strict code review and telemetry‑driven performance checks. - Playground: create sandboxes for experimenting with AI‑generated plugins/themes under constrained, inspectable conditions. - Community: include AI‑ethics and ā€œvibe codingā€ sessions at meetups/WordCamps; provide speaker resources. - Training: design curricula teaching how to pair AI tools with solid PHP/JS fundamentals. - Marketing: avoid hype‑only AI narratives; center empowerment, safety, and open ecosystem values. - Support: update support docs to answer ā€œCan I trust AI‑generated code?ā€ with practical, cautious advice. - Design: ensure AI‑assisted tooling UX makes limitations and review steps very visible. - Documentation: add sections showing examples of reviewing and hardening AI‑generated snippets. - Photos / TV / Polyglots / Accessibility / Meta / CLI / Hosting / Tide / Openverse / Themes / Plugins: - Incorporate AI tooling where it reduces grunt work (captioning, translation drafts, scaffolding) while enforcing human review, accessibility checks, and provenance. #### The WPOCC - Fund experiments with open, consent‑trained coding assistants that serve WordPress maintainers and educators. - Sponsor governance clinics around AI adoption in open source projects. - Pilot microgrants for contributors documenting good/bad patterns in AI‑assisted WordPress development. - Explore transparent funding models for community‑controlled AI infrastructure (models, hosting, evaluation). ### FAIR - Promote architectures that allow local or self‑hosted models with transparent training data where possible. - Encourage covenants requiring funding transparency and sunset clauses for any centralized AI services in the stack. - Produce reusable governance artifacts (charters, operator agreements) specifying acceptable AI uses and anti‑capture mechanisms. ## 🧪 Hypotheses - H1: Heavy reliance on proprietary coding assistants will reduce developers’ ability to detect security and logic flaws over time. - H2: Teams that treat LLM output as suggestions, not ground truth, will produce more secure and innovative software than teams that ā€œblack‑boxā€ AI. - H3: Organizations adopting AI for coding primarily to cut labor costs will see lower long‑term innovation than those using it to augment existing teams. - H4: Open, consent‑trained coding models integrated into education will increase entry‑level developer confidence without significantly reducing core skills. ### šŸ“Š Methodology - For H1: Longitudinal study comparing cohorts of devs with different levels of AI use on standardized bug‑finding and code review tasks. - For H2: Experimental teams assigned to ā€œAI‑as‑suggestionā€ vs ā€œAI‑as‑defaultā€ workflows; compare vulnerability counts, originality assessments, and time‑to‑feature. - For H3: Compare product roadmaps and innovation outputs (patents, new features, user impact) across companies with layoff‑driven vs augmentation‑driven AI adoption. - For H4: Controlled trials in coding bootcamps and CS classes with/without open coding assistants; test conceptual understanding and debugging abilities. ### ā“ Questions - How can we keep the hacker culture of skepticism alive while using powerful AI tools? - What governance mechanisms can prevent Big Tech from using AI to further entrench labor precarity? - Can we design models or interfaces that actively teach code comprehension instead of hiding complexity? - What incentives would push organizations to use AI to enrich work rather than replace workers? ### šŸ”® Future Research - Evaluate educationally oriented, open coding assistants vs commercial copilots on learning outcomes. - Study real‑world incidents where AI‑generated code led to security or reliability failures. - Explore socio‑technical models for community‑owned AI infrastructure supporting open source projects. - Investigate how culture‑war dynamics and tech fandoms influence developer tool adoption. ### šŸ’” Implications - Practice: Teams need explicit policies for AI‑generated code review, security, and provenance. - Policy: Regulators may need disclosure rules for AI‑authored code in critical systems and labor protections around automation. - Security: Threat models must include systematic vulnerabilities introduced by AI‑generated patterns. - Education: Curricula should integrate AI literacy while reinforcing fundamentals and skepticism. - Funding: Philanthropy and public funding could back open, consent‑trained models to counterbalance proprietary platforms. ### 🧠 Learning Styles Assessment - Reading level estimate: roughly late‑high‑school to early‑college (Flesch–Kincaid around grade 11–12, given long sentences and abstract concepts). #### šŸ‘€ Visual learners - Present: Mainly text; conceptual contrasts (empowerment vs imprisonment) but no diagrams. - Improve: Add diagrams showing workflows (human‑only, AI‑assisted, AI‑dependent), labor/innovation tradeoff charts, and timelines of AI adoption vs layoffs. #### šŸ”Š Aural learners - Present: No audio assets in the article itself. - Improve: 2–5 minute audio summary, podcast‑style discussion, and TTS version of the essay. #### šŸ—£ļø Verbal learners - Present: Strong narrative voice, metaphors (ā€œpast as prison,ā€ ā€œrobot vacuumā€), clear definitions of vibe coding. - Improve: Brief glossary of terms (LLM, vibe coding, boilerplate), and explicit analogies to non‑tech fields. #### 🧩 Kinesthetic learners - Present: No interactive tasks. - Improve: Hands‑on labs comparing hand‑written vs AI‑generated code, debugging exercises, and guided ā€œthreat modelingā€ of AI‑assisted workflows. #### 🧠 Logical learners - Present: Causal arguments linking incentives → tooling → labor outcomes; some historical comparison. - Improve: More explicit data tables, decision trees for adopting AI tools, and structured argument maps. #### šŸ§‘ā€šŸ¤ā€šŸ§‘ Social learners - Present: Implicit invitation to community reflection (ā€œWho are we trying to empower?ā€). - Improve: Discussion prompts, small‑group workshop guides, and moderated Q&A formats. #### šŸ§˜ā€ā™€ļø Solitary learners - Present: Reflective questions at the end of the essay. - Improve: Journaling prompts and self‑assessment checklists on personal AI use. #### 🌿 Naturalistic learners - Present: Brief nod to AI’s environmental impact, not elaborated. - Improve: Deeper treatment of compute/energy costs, lifecycle impacts of large models, and ā€œgreen AIā€ options. ### šŸ“Š Accessibility Assessment #### Screen reader semantics - Present: Standard blog layout likely with headings and basic semantic HTML. - Improve: Ensure clear heading hierarchy, descriptive alt text for any future images, and explicit language attributes. #### Keyboard navigation - Present: Typical blog should be navigable, but not evaluated here. - Improve: Confirm visible focus styles, skip‑to‑content links, and no keyboard traps in any interactive embeds. #### Contrast and readability - Present: anildash.com generally uses readable, high‑contrast text. - Improve: Verify contrast ratios for all elements, maintain adequate line height and font size. #### Text resizing and reflow - Present: Responsive site likely handles zoom reasonably. - Improve: Test at 200–400% zoom, ensure no clipping or horizontal scrolling for main text, and support `prefers-reduced-motion`. #### Media and captions - Present: Primarily text; no media requiring captions. - Improve: For any future audio/video, provide captions, transcripts, and avoid autoplay. #### Forms and interactions - Present: Minimal forms (e.g., newsletter) if any. - Improve: Ensure clear labels, accessible error messages, and large tap targets. #### Standards reference - Map gaps to WCAG 2.2 AA, especially 1.4.x (contrast), 2.1.x (keyboard), 1.2.x (media alternatives), 1.4.10 (reflow). ### šŸŒ DEIB Assessment #### Cultural breadth - Present: Focus on U.S./Big Tech context. - Improve: Include examples from global tech labor markets and non‑English‑speaking developer communities. #### Inclusive language - Present: Generally neutral, critical of powerful actors, supportive of workers. - Improve: Add more plain‑language summaries to reduce jargon; clarify metaphors that may be culture‑specific. #### Neurodiversity support - Present: Clear structure and sectioning; some long paragraphs. - Improve: Further chunk content with subheadings and bullet lists; maintain consistent patterns for arguments. #### Representation - Present: Little explicit discussion of demographic diversity; focus is on roles (coders, investors). - Improve: Acknowledge how AI‑driven labor changes intersect with gender, race, geography, and class. #### Psychological safety - Present: Firm but not abusive tone; briefly mentions severe AI harms (e.g., self‑harm suggestions) without warning. - Improve: Add content warnings for sensitive examples and reference support resources when mentioning self‑harm. ### āœ… Logical Validity #### Strong reasoning - Causal argument: investor incentives → funding AI coding tools → weakened labor bargaining power. Strengthened by temporal alignment with layoffs and falling job listings. - Structural limitation argument: models trained on past code → conservative outputs → difficulty producing radical novelty. Grounded in how LLMs operate. - Normative reasoning: tools could be used to augment workers but are currently deployed for cost cutting; clarifies that the issue is governance, not inevitability. #### Fallacies - Possible overgeneralization when implying Big AI platforms would never allow genuinely disruptive apps; this could be nuanced by acknowledging partial, accidental, or edge‑case disruptions. - Some claims about model behavior (always lying to make you feel good) could be hedged with ā€œoftenā€ and tied to alignment tuning evidence. #### Tone of voice - Tone is critical, skeptical, and morally charged but also reflective and ambivalent about AI’s potential. - Uses vivid metaphors (ā€œpast is a prison,ā€ ā€œrobot vacuum,ā€ ā€œsurfing towards serfdomā€) and sharp critiques of ā€œgreedy peopleā€ and ā€œdeeply corrosiveā€ tycoons. ### šŸ›”ļø DARVO Analysis - Deny: The article does not deny harms; it highlights them. It accuses VCs and Big Tech of denial by blaming macroeconomics. - Attack: Dash attacks systems and powerful actors (VCs, tech tycoons) rather than victims; no DARVO against harmed groups. - Reverse victim/offender: He explicitly resists narratives that cast executives as victims of interest rates, reframing them as decision‑makers responsible for layoffs. - Overall, the essay pushes against DARVO patterns commonly used by powerful institutions to justify harmful AI deployment. ## šŸŽÆ Conclusion Dash’s core claim is that vibe coding is both genuinely empowering for creators and structurally aligned with investor interests that depress wages, entrench Big Tech, and constrain radical innovation. The practical next step is not to reject coding AI outright, but to adopt it consciously: favor open, consent‑trained tools, keep human understanding central, and organize around values—who is empowered, what gets built, and which tradeoffs we refuse. ## 🧱 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] Vibe coding reshapes coding labor power > [!quote] [Vibe Coding: Empowering and Imprisoning](https://www.anildash.com/2025/12/02/vibe-coding-empowering-and-imprisoning/) by [[Anil Dash]] via [[anildash.com]]. Published 2025-12-02. > ā€œOnce workers began organizing in this way, the tech tycoons… began investing billions… that would devalue the labor of millions of coders.ā€ Two lines: context and use. Cite data if relevant. [view highlight](https://www.anildash.com/2025/12/02/vibe-coding-empowering-and-imprisoning/#H1) #xref #articleseed ID:rw_[MISSING] ### [H2] LLM coding tools constrain radical innovation > [!quote] [Vibe Coding: Empowering and Imprisoning](https://www.anildash.com/2025/12/02/vibe-coding-empowering-and-imprisoning/) > ā€œAnd a vibe coding tool absolutely won’t make something truly new.ā€ Two lines: context and use. [view highlight](https://www.anildash.com/2025/12/02/vibe-coding-empowering-and-imprisoning/#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] Vibe coding weakens programmers’ bargaining power - Scope/condition in one line. - Pointer to page/time or dataset. - Links: [[AI-and-Labor]] [[Developer-Power-Dynamics]] #### [Z2] LLM coding assistants hinder radical software innovation - Scope/condition in one line. - Pointer to page/time or dataset. - Links: [[AI-and-Creativity]] [[Innovation-Constraints]] --- ### āœļø 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] Map concrete examples where AI‑generated code caused major incidents — context/https://www.anildash.com/2025/12/02/vibe-coding-empowering-and-imprisoning/ #fleeting #inbox - [F2] Design a workshop on ā€œreading and debugging AI‑generated codeā€ — context/https://www.anildash.com/2025/12/02/vibe-coding-empowering-and-imprisoning/ #fleeting #inbox - [F3] Research open, consent‑trained coding models suitable for education — context/https://www.anildash.com/2025/12/02/vibe-coding-empowering-and-imprisoning/ #fleeting #inbox --- <!-- deep-read:sections end -->