Never Submit Code You Don't Understand  🔗 **Source:** [Never Submit Code You Don't Understand](https://dri.es/never-submit-code-you-do-not-understand) > [!note]+ Document Notes > tags: #drupal #open-source #code-review #ai-development #best-practices > author: Dries Buytaert > source: dri.es > reference: https://dri.es/never-submit-code-you-do-not-understand > date created: 2024-12-19 15:30 > > # 🏷️ Title: Never submit code you don't understand > <!-- deep-read:sections start --> ## 🧰 Action Inbox - [H1] Establish code understanding requirements for AI-assisted contributions — project maintainer guidelines #drupal - [H2] Create educational resources about responsible AI-assisted development — community documentation #open-source - [H3] Review current contribution guidelines to address AI tool usage — governance update #code-review ## 🧭 Table of Contents - [[#📝 Summary]] - [[#📖 Main Content]] - [[#🗒️ Notes]] - [[#📚 References]] - [[#🗣️ Paraphrase]] - [[#📰 Newsletter]] - [[#✅ Action Items]] - [[#🧪 Hypotheses]] - [[#📊 Methodology]] - [[#❓ Questions]] - [[#🔮 Future Research]] - [[#💡 Implications]] - [[#🧠 Learning Styles Assessment]] - [[#📊 Accessibility Assessment]] - [[#🌍 DEIB Assessment]] - [[#✅ Logical Validity]] - [[#🛡️ DARVO Analysis]] - [[#🎯 Conclusion]] ### 🔗 References - [Never submit code you don't understand](https://dri.es/never-submit-code-you-do-not-understand) - [LinkedIn Discussion](https://linkedin.com) ## 📝 Summary - Dries Buytaert proposes a new mantra for the AI era: "Never submit code you don't understand" - This parallels Drupal's historical "Don't hack core" principle that successfully changed community behavior - AI tools are changing code development but don't eliminate the responsibility to understand contributions - Contributors must be able to explain their code's function, reasoning, and interactions - The principle protects both maintainers from review burden and contributors' learning opportunities ## 📖 Main Content Dries Buytaert, founder of Drupal, argues that the open-source community needs a new guiding principle as AI transforms software development. Drawing from Drupal's successful "Don't hack core" campaign that discouraged improper core modifications, he proposes "Never submit code you don't understand" as the new essential mantra. The historical context shows how simple, memorable phrases can drive lasting behavioral change in technical communities. The "Don't hack core" message appeared across multiple channels and successfully shifted developer practices over time. With AI-generated code becoming common, the fundamental responsibility of understanding contributions before submission remains unchanged. In open-source projects, ununderstood code becomes a burden on maintainers during review processes, creating bottlenecks that affect the entire contributor community. The principle emphasizes personal responsibility regardless of development tools used. Contributors should demonstrate comprehension of their code's functionality, underlying logic, and system interactions. This standard maintains code quality while preserving learning opportunities for developers at all skill levels. ## 🗒️ Notes #### ⏱️ [00:00](https://dri.es/never-submit-code-you-do-not-understand) — [H1] Historical Success of "Don't Hack Core" - Key idea: Simple mantras can successfully change community behavior over time - Evidence: "It showed up in issue queues, conference talks, support channels, stickers, and even on T-shirts" #### ⏱️ [00:30](https://dri.es/never-submit-code-you-do-not-understand) — [H2] AI Changes Tools, Not Responsibilities - Key idea: AI transforms development methods but maintains core contributor accountability - Evidence: "AI is changing how code gets written, but it does not change that responsibility" #### ⏱️ [01:00](https://dri.es/never-submit-code-you-do-not-understand) — [H2] Maintainer Burden Problem - Key idea: Unclear code submissions create systemic review bottlenecks - Evidence: "Code you don't understand becomes someone else's problem. In Open Source, that someone is often the maintainer" #### ⏱️ [01:30](https://dri.es/never-submit-code-you-do-not-understand) — [H3] Learning Opportunity Loss - Key idea: Contributors miss skill development when submitting ununderstood code - Evidence: "Plus, you miss the chance to learn from the code and grow as a developer" #### ⏱️ [02:00](https://dri.es/never-submit-code-you-do-not-understand) — [H1] Understanding Requirements - Key idea: Contributors must demonstrate comprehensive code comprehension - Evidence: "You should be able to explain what it does, why it works, and how it interacts with the rest of the code" #### ⏱️ [02:30](https://dri.es/never-submit-code-you-do-not-understand) — [H3] Inclusive Standards - Key idea: The principle welcomes all contributors while maintaining quality expectations - Evidence: "You are welcome here, with or without AI tools. Perfection isn't required, but understanding your code is" #### ⏱️ [03:00](https://dri.es/never-submit-code-you-do-not-understand) — [H2] New Mantra Proposal - Key idea: Community needs updated guidance for AI-assisted development era - Evidence: "Maybe it's time for some new stickers and T-shirts. Never submit code you don't understand" ## 📚 References - [Never submit code you don't understand](https://dri.es/never-submit-code-you-do-not-understand) - [Dries Buytaert Blog](https://dri.es/) - [Drupal Community](https://drupal.org/community) ## 🗣️ Paraphrase - Open-source communities can use memorable phrases to drive positive behavioral changes, as demonstrated by Drupal's successful "Don't hack core" campaign - AI development tools don't eliminate the fundamental requirement that contributors understand their code before submission to maintain project quality - Submitting incomprehensible code burdens maintainers with additional review work while depriving contributors of valuable learning experiences ## 📰 Newsletter The Drupal community is considering a powerful new principle for the AI era. Dries Buytaert's proposed "Never submit code you don't understand" mantra builds on the successful legacy of "Don't hack core" to address modern development challenges. As AI tools become standard in WordPress development workflows, this principle ensures code quality while protecting learning opportunities. Whether you're using GitHub Copilot, ChatGPT, or traditional methods, the expectation remains: understand your contributions completely. For WordPress contributors, this translates to being able to explain your patches' functionality, security implications, and performance characteristics. It's about taking ownership and reducing review burden on core maintainers. The principle welcomes developers at every level while maintaining professional standards essential for project sustainability. Resources: [Learn WordPress](https://learn.wordpress.org/), [Developer Docs](https://developer.wordpress.org/), [WP-CLI](https://wp-cli.org/) ## ✅ Action Items #### Community - Contributors: Implement code comprehension checklists before patch submission - Maintainers: Develop guidelines for evaluating AI-assisted contributions - Sponsors: Fund educational resources about responsible AI-assisted development #### WordPress - Core: Integrate understanding requirements into contribution documentation - Community: Create workshops on responsible AI tool usage for developers - Training: Develop curriculum covering code comprehension and explanation skills - Documentation: Update contributor guides with AI-era best practices ## 🧪 Hypotheses - Simple, memorable mantras drive lasting behavioral change in technical communities more effectively than complex guidelines - AI-assisted contributions without proper understanding create measurable increases in maintainer review time and rejection rates - Communities that establish clear code comprehension standards maintain higher long-term code quality despite AI tool proliferation - Educational approaches emphasizing understanding over tool restriction produce better contributor development outcomes ### 📊 Methodology - Survey maintainers across projects to measure review time differences for understood vs. ununderstood submissions - Track contribution acceptance rates and revision cycles for AI-assisted vs. traditional patches - Analyze community discourse sentiment before and after implementing understanding-focused guidelines ### ❓ Questions - How can projects efficiently assess contributor code comprehension during review processes? - What educational approaches best prepare developers to explain AI-assisted code contributions? - Which community messaging strategies most effectively promote responsible AI tool adoption? ### 🔮 Future Research - Long-term impact of understanding requirements on contributor skill development and retention - Comparative effectiveness of different community mantras in driving technical behavioral change - Best practices for balancing AI tool benefits with code quality maintenance ### 💡 Implications - Practice: Developers need new workflows integrating AI tools with comprehension validation steps - Policy: Open-source projects should update contribution guidelines addressing AI-assisted development - Security: Understanding requirements help prevent introduction of vulnerabilities through unvetted AI-generated code - Education: Developer training programs must emphasize code comprehension alongside tool proficiency - Funding: Resources needed for creating educational materials about responsible AI-assisted development ### 🧠 Learning Styles Assessment Reading level estimate: 8th Grade #### 👀 Visual learners - Present: Clear article structure with logical progression - Improve: Add flowcharts showing contribution review process, infographics comparing mantras #### 🔊 Aural learners - Present: Conversational writing style with memorable phrases - Improve: Audio version of article, podcast discussion format #### 🗣️ Verbal learners - Present: Strong use of analogies, clear definitions of "understanding" - Improve: More examples of good vs. poor code explanations #### 🧩 Kinesthetic learners - Present: Practical focus on actionable behaviors - Improve: Checklists for self-assessment, hands-on comprehension exercises #### 🧠 Logical learners - Present: Clear cause-effect relationships, historical precedent - Improve: Metrics on review burden, decision tree for code understanding #### 🧑‍🤝‍🧑 Social learners - Present: Community focus, collaborative review emphasis - Improve: Discussion prompts, peer review exercises #### 🧘‍♀️ Solitary learners - Present: Self-reflection opportunities, personal responsibility theme - Improve: Individual assessment tools, journaling prompts #### 🌿 Naturalistic learners - Present: Ecosystem thinking about community health - Improve: Analogies to natural systems, sustainability connections ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Good heading structure, clear article flow - Improve: Add skip navigation, enhance semantic markup #### Keyboard navigation - Present: Standard blog navigation - Improve: Ensure all interactive elements are keyboard accessible #### Contrast and readability - Present: Clean design with good text contrast - Improve: Verify 4.5:1 minimum contrast ratios throughout #### Text resizing and reflow - Present: Responsive design supports text scaling - Improve: Test at 200% zoom for content clipping #### Media and captions - Present: Text-only article format - Improve: Not applicable for current content #### Forms and interactions - Present: Simple subscription form - Improve: Ensure form labels and error handling meet standards #### Standards reference - Review against WCAG 2.2 AA success criteria for any identified gaps ### 🌍 DEIB Assessment #### Cultural breadth - Present: Universal principles applicable across development cultures - Improve: Examples from multiple open-source communities beyond Drupal #### Inclusive language - Present: Welcoming tone for developers at all levels - Improve: Define technical jargon, avoid cultural idioms #### Neurodiversity support - Present: Clear structure with consistent formatting - Improve: Bullet points for complex concepts, visual breaks #### Representation - Present: Acknowledges contributors at different experience levels - Improve: Include diverse contributor perspectives and use cases #### Psychological safety - Present: Emphasizes learning over perfection - Improve: Add explicit encouragement for questions and gradual learning ### ✅ Logical Validity #### Strong reasoning - Deductive strength: Historical success of "Don't hack core" provides valid precedent for new mantra effectiveness - Inductive strength: Pattern recognition from past community behavioral changes supports proposed approach - Causal reasoning: Clear connection between code understanding and review quality/contributor learning - Analogical strength: Parallel between core hacking problem and AI comprehension issue is well-established #### Fallacies - Appeal to tradition: Assumes past mantra success guarantees future effectiveness - minor weakness, historical precedent is relevant - False dichotomy: Presents understanding as binary rather than spectrum - could acknowledge degrees of comprehension #### Tone of voice - Overall tone: Authoritative but inclusive, drawing on community leadership experience while welcoming newcomers ### 🛡️ DARVO Analysis - Deny: No denial patterns present - Attack: No attacks on any groups or individuals - Reverse victim/offender: No victim/offender dynamics present - Emotional cues and rhetoric: Positive, constructive framing focused on community benefit and individual growth ## 🎯 Conclusion Dries Buytaert's proposed "Never submit code you don't understand" represents a timely evolution of open-source community standards for the AI era. By building on the proven success of simple, memorable mantras like "Don't hack core," this principle addresses the fundamental challenge of maintaining code quality and contributor learning in an age of AI-assisted development. The principle's strength lies in its tool-agnostic approach, focusing on outcomes rather than methods. For WordPress and other open-source communities, adopting similar understanding requirements can help preserve the balance between innovation and responsibility that makes these projects successful. The next steps involve translating this principle into practical contribution guidelines, educational resources, and community messaging that can drive the same positive behavioral change that transformed Drupal's development culture years ago. ## 🧱 Refactor Appendix ### 📚 Literature Split Pad Purpose: Stage CEE units that become Literature notes. Split level: H3 ### [H1] Simple mantras drive lasting community behavioral change > [!quote] [Never submit code you don't understand](https://dri.es/never-submit-code-you-do-not-understand) by [[Dries Buytaert]] via [[dri.es]]. Published 2026-03-16. Accessed 2024-12-19. > "It showed up everywhere and was short and memorable, and it solved a real problem." Historical example demonstrates how memorable phrases can successfully shift developer practices across entire communities. [view highlight](https://dri.es/never-submit-code-you-do-not-understand#H1) #xref #articleseed ID:rw_001 ### [H2] AI tools don't eliminate code comprehension responsibility > [!quote] [Never submit code you don't understand](https://dri.es/never-submit-code-you-do-not-understand) > "AI is changing how code gets written, but it does not change that responsibility." Development tool evolution maintains fundamental accountability requirements for open-source contributors. [view highlight](https://dri.es/never-submit-code-you-do-not-understand#H2) #xref ID:rw_002 ### [H3] Ununderstood code creates maintainer burden > [!quote] [Never submit code you don't understand](https://dri.es/never-submit-code-you-do-not-understand) > "Code you don't understand becomes someone else's problem." Contribution quality directly impacts review processes and community sustainability in open-source projects. [view highlight](https://dri.es/never-submit-code-you-do-not-understand#H3) #xref ID:rw_003 --- ### 🔖 Atomic Split Pad (Zettel Candidates) Purpose: Promote reusable claims into Atomic notes. Split level: H4 #### [Z1] Community mantras require memorable simplicity for adoption - Must be short, repeatable, and address specific problems - Reference to historical "Don't hack core" success - Links: [[Community-Governance]] [[Behavioral-Change]] #### [Z2] Code understanding enables contributor skill development - Contributors miss learning when submitting incomprehensible code - Reference to growth opportunity discussion - Links: [[Developer-Education]] [[Open-Source-Learning]] #### [Z3] Review burden scales with contribution comprehension quality - Maintainer workload increases with unclear submissions - Reference to review process impact - Links: [[Project-Sustainability]] [[Maintainer-Burnout]] --- ### ✏️ Fleeting Queue Purpose: Capture quick actions for Fleeting notes. - [F1] Research other successful open-source community mantras — historical analysis #fleeting #inbox - [F2] Create WordPress-specific code comprehension checklist — contribution guidelines #fleeting #inbox - [F3] Survey maintainers <!-- deep-read:sections end --> 📄 **Full text:** ![[Full Document Contents/Articles/Never Submit Code You Don't Understand|Never Submit Code You Don't Understand, dri.es]] ## Highlights - Code you don't understand becomes someone else's problem. In Open Source, that someone is often [the maintainer reviewing your patch](https://dri.es/ai-creates-asymmetric-pressure-on-open-source). And AI makes it easier than ever to create that problem for others. ([View Highlight](https://read.readwise.io/read/01kkw08s8byv75gbf4mpaae438)) - Tags: 👻 ai highlighted