QEMU - "AI code generators के उपयोग पर प्रतिबंध" नीति परिभाषित

• QEMU समुदाय ने हाल ही में अपनी नीति में संशोधन किया। AI code generators (जैसे Copilot, ChatGPT आदि) के उपयोग और उन टूल्स के माध्यम से code submission पर प्रतिबंध लगाया गया है

define policy forbidding use of AI code generators

• हाल के दिनों में AI code generators के उपयोग में रुचि तेज़ी से बढ़ी है, लेकिन इन टूल्स के output की license interpretation को उद्योग में व्यापक रूप से स्वीकार नहीं किया गया है
• प्रमुख vendors का दावा है कि कोई समस्या नहीं है और license का स्वतंत्र रूप से चयन किया जा सकता है, लेकिन इनमें हितों का टकराव मौजूद है
• चूँकि AI code generators विभिन्न licenses के तहत प्रशिक्षित data पर आधारित होते हैं, इसलिए output के license issues पर उद्योग-स्तरीय सहमति अभी मौजूद नहीं है
• QEMU, DCO (Developer Certificate of Origin) में यह अपेक्षा करता है कि contributor के पास project license के तहत code contribute करने का स्पष्ट अधिकार हो
  • यह भी स्पष्ट रूप से कहा गया है कि AI code generator से बने code के मामले में DCO की b/c clauses के अनुपालन को साबित करना कठिन है
  • इसलिए यदि AI code generator का उपयोग स्पष्ट रूप से हुआ हो या उस पर संदेह हो, तो QEMU project में code contribution की अनुमति नहीं देने की नीति लागू की गई है

नीति की लचीलापन और अपवाद प्रबंधन

• AI-सहायित software development अभी शुरुआती चरण में है, इसलिए भविष्य में कानूनी मुद्दों के सुलझने की संभावना अधिक है
• टूल्स के विकसित होने के साथ भविष्य में कुछ टूल्स open source projects में सुरक्षित रूप से उपयोग योग्य हो सकते हैं
• फिलहाल सख्त और सुरक्षित नीति को प्राथमिकता दी गई है, और आवश्यकता पड़ने पर भविष्य में इसे नरम किया जा सकता है
• अपवाद अनुरोधों की समीक्षा अलग-अलग मामलों के आधार पर की जाएगी और उसी के अनुसार अनुमति का निर्णय होगा

[GN⁺]

Hacker News की राय

• open source और free software खास तौर पर असुरक्षित महसूस कर रहे हैं अगर AI से जनरेट किया गया code उल्लंघनकारी copyrighted work माना जाए या public domain घोषित कर दिया जाए। अगर AI edits और human edits को अलग करना जरूरी हो जाए, तो projects सालों तक कानूनी समस्याओं में फंस सकते हैं और मुकदमेबाजी का खर्च भी नहीं उठा पाएंगे। अगर AI द्वारा बनाया गया code बाद में इंसानों द्वारा संशोधित किया जाए या मौजूदा codebase में मिलाया जाए, तो यह भी सवाल है कि क्या बाद की human edits fair use से बाहर निकलकर derivative work मानी जाएंगी। अगर AI-generated code को public domain मान लिया जाए, तो ऐसे projects जिनके source code के केवल कुछ हिस्सों पर open source/free software license लागू होता है, license का दुरुपयोग करने वाली कंपनियों के खिलाफ सख्ती से कार्रवाई करने की क्षमता तेजी से घट जाएगी। तब license उल्लंघन करने वाले ने specifically इंसानों द्वारा लिखा गया, यानी licensed code इस्तेमाल किया है, यह साबित करना बहुत बड़ा बोझ बन जाएगा। दूसरी ओर, proprietary software पर इसका असर तुलनात्मक रूप से कम होगा। क्योंकि अगर यह दावा करना हो कि AI-generated code unauthorized quotation है, तो किसी को binary reverse engineer करके original code से तुलना करनी होगी, और proprietary software में पहले से ही public domain code के मिले-जुले होने के मामले आम हैं
  • मेरा मानना है कि MIT license के लिए यह स्थिति उलटे फायदेमंद हो सकती है
  • एक अनुभवी developer के नज़रिये से, मैं पूरी तरह समझ सकता हूँ कि बहुत से लोग नहीं चाहते कि बिना समझ वाले "developers" यूँ ही random AI code contribute करें। AI code की हर line को इंसान से manually review करवाना, कानूनी मुद्दों से अलग भी, सालों तक manpower बांध सकता है। पहला, भविष्य में यह verify करने का कोई व्यावहारिक तरीका शायद ही हो कि code AI से बना है या नहीं। दूसरा, जो software सच में 100% सिर्फ इंसानों द्वारा विकसित होगा, वह आगे चलकर AI-assisted या AI-authored projects के मुकाबले कम competitive होगा। इसका अकेला counterargument बस apocalypse-level collapse जैसा होगा, जहाँ इंसान semiconductor या electricity का mass production ही न कर पाएं। तीसरा, अगर कोई project AI code contributions को पूरी तरह बाहर रख भी ले, (भले यह कैसे संभव होगा साफ न हो, या AI-विरोधी एक छोटा समूह ही क्यों न contribute करे) अंत में कोई न कोई उस code को copy करके कानूनी जोखिम वाले हिस्से हटाएगा और नए project पर चला जाएगा। अगर license forks की अनुमति देता है, तो सीधा fork भी हो सकता है, लेकिन copy करके cleanup करना और भी पसंद किया जा सकता है। open source projects के आगे अभी लंबा रास्ता है, और भविष्य का software मात्रा के हिसाब से विस्फोटक रूप से बढ़ेगा; उनमें 99% भले घटिया हो, लेकिन सच में मूल्यवान software की संख्या भी बढ़ेगी
  • AI copyright मुद्दे के संदर्भ में US Copyright Office के AI art पर रुख बताने वाले news.artnet.com के ताज़ा लेख और Monkey selfie case wiki का लिंक साझा करते हुए कहा गया कि यह चर्चा अब ऐसी राह पर पहुँच चुकी है जहाँ से वापसी मुश्किल है
  • अगर कोई software सच में ऐसा wide-open source है जिसका मतलब है "इस code के साथ जो चाहो करो, हमें कोई फर्क नहीं पड़ता", तो AI के कारण चिंता की कोई बात नहीं है
• यह LLVM policy की तुलना में निश्चित रूप से अधिक कड़ा रुख लगता है। विस्तार से LLVM developer policy में देखा जा सकता है। मैं एक पुराने ज़माने का developer हूँ, और मैं ऐसी स्थिति बिल्कुल नहीं चाहता जहाँ मुझे ऐसा code review करना पड़े जिसे author भी नहीं समझता और मैं भी नहीं
  • जब author अपने code को ही नहीं समझता और मुझे उसे review करना पड़े, यह सच में बहुत अप्रिय है। सचमुच लोग मुझसे कोई काम करने को कहते हैं और खुद AI से मिली explanation आगे बढ़ाकर कहते हैं, “ऐसे करना है।” मुझे तो सीधा “यह कर दीजिए” कहना कहीं बेहतर लगता है। वरना यह अपमानजनक लगता है
  • मैंने अपने manage किए जाने वाले सभी open source projects में DCO(Developer Certificate of Origin) जोड़ना शुरू किया है, और CONTRIBUTING.md में LLM code contribution policy के रूप में यह डालने वाला हूँ

  ---

  LLM-Generated Contribution Policy
  Color library एक ऐसी library है जिसमें complex math और सूक्ष्म decision-making भरा हुआ है। हर issue या PR submitter की अपनी गहरी समझ के आधार पर लिखा जाना चाहिए, और खासकर PR के मामले में developer को हर commit के लिए DCO certify करना होगा। अगर PR लिखने में LLM की मदद ली गई है, तो commit message और PR में इसे स्पष्ट रूप से बताना होगा। बिना सबूत के LLM सहायता detect होने पर PR reject होगा। LLM द्वारा बनाए गए content को बिना review submit करना हर हाल में reject किया जाएगा

  SECURITY.md में भी LLM-Generated Security Report Policy डालकर, LLM द्वारा जनरेट की गई security reports को हर हाल में स्वीकार न करने की योजना है

  अकेले project की जिम्मेदारी उठाने वाले व्यक्ति के रूप में मैं संतुलन बनाने की कोशिश करता हूँ, लेकिन व्यक्तिगत रूप से LLM code contributions पसंद नहीं करता
  • मैं personal projects में GitHub Copilot इस्तेमाल करता हूँ। लेकिन इसे “smart autocomplete” से आगे के तरीके में इस्तेमाल नहीं करता। जब यह उस code के काफी करीब होता है जिसे मैं खुद टाइप करने वाला था, तभी मैं इसे स्वीकार करता हूँ। इससे मेरा code 100% मेरी समझ में रहता है, और accidental bugs या copyright विवादों से भी बचाव होता है। Copilot को इस तरह इस्तेमाल करने से development तेज़ होता है। सच तो यह है कि typing slow होने की वजह से नहीं, बल्कि इसलिए कि ध्यान अक्सर भटक जाता है या बोरियत होती है। Copilot की मदद से मैं जल्दी अगले thinking या debugging phase में पहुँच जाता हूँ.
    यह कल्पना करना भी मुश्किल है कि कोई व्यक्ति अपना ही code समझे बिना PR submit कर सकता है। ऐसे लोगों की वजह से policies बनें और फिर मुझे autocomplete स्तर पर LLM इस्तेमाल करने पर भी रोक लगे, यह थोड़ी खटकती है।
    मैं Copilot से automated refactoring जैसे काम करवाना चाहता हूँ, लेकिन प्रयोगों में अक्सर यह बुरी तरह चीजें बिगाड़ देता है, और पूरे block नए सिरे से generate करने की प्रवृत्ति के कारण मेरे हाथ से करने से भी धीमा साबित होता है।
    दिलचस्प बात यह है कि अगर मैं typing के दौरान कोई bug लिख रहा हूँ, तो Copilot अक्सर उसी bug को भी पूरा कर देता है। variable name की typo जैसी साफ़ context-based गलतियाँ भी यह वैसे की वैसे autocomplete कर देता है
  • coding काम में LLM का इस्तेमाल मैं जैसे इस तरह करता हूँ: “इस YAML content को structs में बदल दो और repetitive patterns को variables में extract कर दो।” यह deterministic tools से भी किया जा सकता है, लेकिन AI इसे 30 सेकंड में साफ़-सुथरे ढंग से कर देता है, और यह test करना भी आसान होता है कि result input के बराबर है
    जो high-level काम मैं करता हूँ, वह मैं कभी AI को नहीं सौंप सकता, लेकिन repetitive और कम-गंभीर काम AI लेकर speed बढ़ा देता है। उदाहरण के लिए, अगर Claude Code को database benchmark results की CSV files देकर कहा जाए कि तरह-तरह के graphs और outlier analysis जोड़ दे, तो conceptually आसान लेकिन libraries ढूँढने और setup में समय लेने वाला काम यह जल्दी पूरा कर देता है
  • यह भावना कि अगर author अपने code को नहीं समझता तो मैं review नहीं करूँगा, पूरी तरह समझ में आती है। लेकिन अगर किसी skilled human से सही guidance मिले, तो AI tools भी काफी advanced code बना सकते हैं। पिछले कुछ महीनों में वे और शक्तिशाली हुए हैं, और कई बार सिर्फ natural language instructions से भी output बना देते हैं
    मैं code “समझने” के मतलब पर सोच रहा हूँ। मेरा एक project मौजूदा VM orchestration system में पूरी तरह नया storage backend जोड़ने का है। मौजूदा code को न जानने की स्थिति में, implementation खुद लिखने का समय निकालना मुश्किल है, लेकिन test cluster बनाकर और कई scenarios चलाकर, design और testing के नज़रिये से बड़ी तस्वीर को मैं पर्याप्त रूप से समझ रहा हूँ
    मैं भी एक open source maintainer हूँ, इसलिए यह कल्पना कर सकता हूँ कि कम-गुणवत्ता वाले LLM “slop” PRs आना कितना तनावपूर्ण होता होगा। आखिरकार author code समझता हो या नहीं, maintainer को तो हर हाल में code review करना ही पड़ता है।
    आगे चलकर हमें इन tools का सही उपयोग और submit किए गए code की गुणवत्ता का स्तर दूसरे developers को signal करने के तरीके तलाशने होंगे। शुरुआती Linux ZFS port में मिले सूक्ष्म bugs से मैंने यह सीखा कि इंसानों द्वारा line-by-line review और authorship जितनी महत्वपूर्ण है, उतनी ही thorough testing भी है
• मेरे ब्लॉग “yes i will judge you for using AI” में जिस नतीजे की भविष्यवाणी की थी, वह सच हो गई। open source परंपरागत रूप से contributors की क्षमता के छिपे संकेतों (competency markers) पर काफी निर्भर रहा है, लेकिन LLM ऐसे लोगों को भी सक्षम दिखने वाला code निकालने देता है जिनके पास कोई अनुभव नहीं है। अनुभवी लोगों के लिए यह सच में भ्रमित कर देने वाला झटका है। आगे चलकर बड़े projects में प्रवेश के लिए actual PR से असंबंधित social proof (virtual या in-person meetings आदि) की ज़रूरत और बढ़ सकती है
  • कंपनी में भी यही हो रहा है। सहकर्मी LLM से code review comments बनाते हैं और वे इतने high-level लगते हैं कि कुछ देर के लिए हम धोखा खा जाते हैं। फिर comment सही है या नहीं यह verify करने में बहुत समय लगता है, और असल में copy-paste करने वाले ने जितनी मेहनत नहीं की होती, उससे कहीं ज़्यादा energy मुझे खर्च करनी पड़ती है
  • ब्लॉग का लिंक माँगा गया
• यह policy मुख्यतः RedHat-केंद्रित हस्ताक्षरों के साथ आई है। RedHat काफी गंभीर और enterprise-oriented है। शायद RedHat की चिंता यह कम है कि “AI-generated output का copyright किसके पास होगा,” और अधिक यह है कि training के दौरान खींचा गया दूसरे projects का source code अनजाने में बाहर आ जाए। ज़्यादातर hypervisors closed source होते हैं, और मुकदमेबाजी पसंद करने वाली कंपनियाँ भी बहुत हैं
  • अगर जोखिम यह है कि AI training data से "दूसरे project का code" ज्यों का त्यों उगल दे, तो मुझे लगता है यह समस्या AI द्वारा बनाए गए लगभग हर code पर लागू होती है
  • language models अक्सर सूक्ष्म logical errors पैदा करने का ज्यादा जोखिम रखते हैं, और वे hypervisor की security boundary तक को प्रभावित कर सकते हैं। AI सहायता पर बहुत निर्भर users ऐसी गलतियाँ पकड़ने के लिए कम तैयार होते हैं, इसलिए यह और खतरनाक है
• ध्यान गया कि IBM द्वारा अधिग्रहित RedHat के लोग मुख्यतः इस policy पर हस्ताक्षर कर रहे हैं। IBM ने Watson बनाया था और 2011 में Jeopardy भी जीता था। इसलिए यह सवाल उठता है कि AI software development पर “यह तो अभी बस शुरुआत है” वाला विमर्श सच है, या IBM-शैली की acquisition destruction का एक और दृश्य है।
  Dotnet Runtime AI को सक्रिय रूप से अपना रहा है। बाहर वाले भले इसका मज़ाक उड़ाएँ, लेकिन Stephen Toub और David Fowler जैसे बेहतरीन engineers इसके समर्थक हैं, यह ध्यान देने की बात है।
  कंपनियों को सलाह है कि अगली बार जब IBM AI services बेचने आए, तो वे कोई सच में future-oriented partner तलाशें।
  North Carolina का होने के नाते, मैं बस चाहता हूँ कि IBM और RedHat सही दिशा पकड़ें
• सोच रहा हूँ कि क्या प्रेरणा सच में कानूनी है। कुछ projects तो शायद सिर्फ AI से बने घटिया code reviews से थक चुके हैं
  • QEMU industry में बेहद critical software है। desktop VM, cloud, build servers, security sandboxes, cross-platform environments—यह सचमुच हर जगह इस्तेमाल होता है। बहुत छोटा legal risk भी industry पर गंभीर असर डाल सकता है
  • policy साफ़ और सीमित है। यह शायद इस बात पर ज़ोर देती है कि algorithmically generated code का copyright ownership सुरक्षित रूप से तय नहीं किया जा सकता। “algorithmically” शब्द जानबूझकर इस्तेमाल किया गया लगता है। मौजूदा policy भी इसी दिशा की लगती है, और “हम आज सबसे सख्त और सुरक्षित रुख से शुरू करेंगे, और बाद में नरमी ला सकते हैं” जैसी पंक्ति के कारण शुरुआत से ही तर्कसंगत लगती है। कथित ‘mass slop’ को रोकना भी मकसद होगा, लेकिन प्राथमिक रणनीति legal risk और ownership को पहले साफ़ करना है। यह curl की policy से काफी बेहतर लगती है
  • Monsanto द्वारा seeds rights को आक्रामक तरीके से लागू करने के उदाहरण से सावधानी बरतने की बात कही गई
  • AI मध्यम-स्तर के code की गुणवत्ता को कैसे बदलेगा, इस पर मुझे ईमानदारी से भरोसा नहीं है, लेकिन इंसान भी ज़्यादातर बेकार code ही लिखते हैं। अगर commits बहुत ज़्यादा हों और उन्हें manage करना मुश्किल हो, तो क्या projects को अलग triage teams की ज़रूरत पड़ेगी? मुझे लगता है ज़्यादातर contributions अच्छी नीयत से होती हैं।
    legal risk के कारण AI से बचने वालों को मैं समझता हूँ, लेकिन ज़रूरत से ज़्यादा डरना भी सही है या नहीं, यह सवाल है। जो सच में मानता है कि उसने किसी संभावना को 0 कर दिया है, उसने शायद अभी पर्याप्त नहीं सोचा
  • अगर यही रुझान जारी रहा तो open source टूट सकता है। copy-paste code निकालना बहुत आसान हो जाएगा, और उसे review व reject करने में बहुत समय लगेगा। आगे और projects शायद Android-जैसे model में बदलेंगे, जहाँ source code कोई भी download कर सकता है लेकिन बाहरी व्यक्ति के लिए वास्तव में contribute करना लगभग असंभव होगा
• उम्मीद है कि IDE में LLM को smart autocomplete tool की तरह इस्तेमाल करने और high-level निर्देश देकर बड़े पैमाने पर पूरा code generate करवाने के बीच फर्क किया जाना चाहिए। माना कि grey area है, लेकिन Copilot-जैसी autocomplete को copyright risk के बिना इस्तेमाल करने देना चाहिए। उदाहरण के लिए, case statements की series लिखते समय Copilot patterns पहचानकर typing काफी कम कर देता है
  • आगे चलकर मैं ऐसे भविष्य की कल्पना करता हूँ जहाँ AI चश्मा मेरी सोच और शरीर का हिस्सा जैसा हो। जैसे साधारण चश्मा नज़र सुधारता है, वैसे ही smart glasses सोच में भी सहायक हो सकते हैं।
    मेरा दिमाग भी असल में बहुत सा closed source code सीख चुका है, इसलिए AI copyright debate को पश्चिमी शैली के NIMBY रवैये के रूप में भी देखा गया। चिंता यह है कि अगर ऐसे कानूनी “क्या पता” के बहाने शानदार tech को ठुकराया गया, तो पश्चिमी सभ्यता खुद कमजोर पड़ सकती है
• मैं समझता हूँ कि ऐसी policy क्यों आई, लेकिन मुझे यह गलती लगती है। AI और copyright मुद्दों पर legal judgment अभी अस्पष्ट है और legislation भी लगभग नहीं के बराबर है।
  AI contributions पर रोक से अलग, यह भी ज़रूरी है कि स्पष्ट रूप से बताया जाए कि “इन हिस्सों में AI का उपयोग किया जा सकता है।” उदाहरण के लिए, QEMU का CI setup कोई core security-critical क्षेत्र नहीं है। दिलचस्प और नए test cases या environments के लिए contributions को कुछ शर्तों के तहत AI के साथ अनुमति देना पूरी तरह संभव लगता है
  • अगर यह policy लागू न की जाए तो क्या risk होगा, इस पर विचार हुआ। code शायद थोड़ा धीमे आए, लेकिन बेहतर आएगा, और QEMU जैसे महत्वपूर्ण project के लिए speed sacrifice करके भी इतना risk लेना उचित माना गया। लगता नहीं कि authors GenAI के अपने-आप में विरोधी हैं; बल्कि एक बार अंदर आने के बाद वापस न लौट पाने वाली स्थिति से बचने के लिए वे सावधानी बरत रहे हैं
  • सीधी बात यह है कि “कानूनी स्थिति साफ़ होने तक इंतज़ार करो” सबसे आसान समाधान है। QEMU का ज़्यादातर code GPL 2.0 है, और अगर गलती से GenAI code शामिल हो जाए, फिर बाद में कानूनी मिसाल यह कहे कि “आपको original code का license मानना ही होगा”, तो संबंधित code rollback करने और पूरे downstream ecosystem पर भारी बोझ आ जाएगा। शुरू में “यह हिस्सा AI है, reuse मत करो” जैसा label भी लगा दिया जाए, तब भी बाद में full rewrite का मुद्दा बना रहेगा।
    इसलिए “फिलहाल स्वीकार न करना” सभी के लिए कम जटिल और कम नाटकीय विकल्प है
    संदर्भ के लिए QEMU license और non-free licenses list के लिंक जोड़े गए
  • यह कोई ऐसा कानूनी विवाद नहीं है जो दशकों चले; इस विषय पर पहले ही दर्जनों मुकदमे अदालतों में हैं और कुछ सालों में नज़ीरें आने की उम्मीद है। QEMU बिना AI के 22 साल से शानदार तरीके से बढ़ा है, इसलिए कुछ साल और इंतज़ार करना बिल्कुल बुरा नहीं होगा
  • सलाह दी गई कि इस policy की surface और subtext दोनों पढ़ो। हर काम में legal risk होता है, लेकिन global corporations ऐसे risks भी उठा लेते हैं। बात यह नहीं कि QEMU असामान्य है, बल्कि यह पढ़ा जा रहा है कि वे वास्तव में LLM code इस्तेमाल ही नहीं करना चाहते। “lawyer से पूछो → legal risk है → इस्तेमाल नहीं कर सकते” वाला तर्क देकर बहस खत्म करने की रणनीति जैसा लगता है। कंपनियों में भी यही pattern दिखता है
  • computing industry में “code plagiarize नहीं करते” की पुरानी परंपरा है। बहुत छोटा code snippet भी हो, और कानूनी रूप से fair use में आए, तब भी मूल code को copy न करने की संस्कृति रही है
• “सख्ती और सुरक्षा से शुरू करो, फिर धीरे-धीरे ढील दो” यह तर्क सच में समझदारी भरा लगता है
  लेकिन यह सवाल है कि AI-generated code और कहीं से नकल किए गए human-written code के बीच व्यावहारिक अंतर कैसे पहचाना जाएगा। open source में तो कोई भी contribute कर सकता है, इसलिए इंसान भी code में बाहरी प्रभाव लेकर आते ही हैं
  मौजूदा नज़रिये से, AI-generated code अपने-आप में कोई स्वतंत्र पहचान नहीं रखता; वह अधिकतर इंसान के हाथ का tool लगता है
  • “AI-generated code इंसान के हाथ में पकड़ी power saw जैसा है” यह उपमा दी गई। यह इतना ताकतवर tool है कि इंसान के बाद सबसे ज़्यादा खतरनाक भी हो सकता है।
    और अब यह महसूस हुआ कि यह उपमा भी शायद ज़रूरत से ज़्यादा खिंच चुकी है
• ऐसी policy व्यवहार में बिल्कुल लागू करने योग्य नहीं लगती। Zed, Cursor, VS Code—लगभग हर editor AI-based autocomplete देता है, और मैंने जो खुद type किया और AI hint से जो आया, दोनों के बीच अंतर करना नामुमकिन है।
  यह कुछ वैसा है जैसे मैंने stick figure बनाई हो और कोई कहे, “शायद यह किसी और की stick figure की नकल है, इसलिए तुम्हें इसे submit करने का अधिकार नहीं।”
  policy का असली मकसद शायद बस यह है कि जब कभी भविष्य में कोई AI code और non-AI code का मिला-जुला patch भेज दे, तब वे कह सकें, “हम क्या कर सकते थे।” policy बनाने वालों को भी शायद पता है कि यह अंततः अर्थहीन है
  • ऐसी policy का चरित्र यही लगता है कि “अगर policy के हिसाब से संदिग्ध code submit हुआ तो हमने पहले ही मना किया था,” यानी जिम्मेदारी से बचने का आधार तैयार हो जाए। commit messages या patches में यह रुख भी शामिल है कि “code generators की licensing समस्या अभी कानूनी रूप से स्थापित नहीं हुई है।”
    legal issues के अलावा भी AI code इस्तेमाल करने पर कई दूसरी समस्याएँ स्पष्ट रूप से मौजूद हैं
  • Neovim AI को force नहीं करता। इसे काम करने के लिए user को खुद setup करना पड़ता है। अगर कोई editor AI बंद ही न करने दे, तो समस्या editor में ही गंभीर है