विस्तृत विश्लेषण · लगभग 7 मिनट पढ़ना
तीन Java Champions के अनुभव: AI से लिखे कोड की जाँच कैसे करें
GitHub के साक्षात्कार बताते हैं कि संदर्भ, सही प्लेटफ़ॉर्म पर पुनरुत्पादन और स्पष्ट परीक्षण Copilot के काम को समीक्षा योग्य कैसे बनाते हैं।
- यहाँ प्रकाशित
- स्रोत की तारीख
- स्रोत जाँचा गया
GitHub ने 20 अक्टूबर को Vlad Mihalcea, Patrick Baumgartner और Frank Delporte के साक्षात्कार प्रकाशित किए। उदाहरणों में नई सुविधाएँ, शिक्षण सामग्री का स्थानांतरण और बिना त्रुटि संदेश वाला हार्डवेयर इनपुट दोष शामिल हैं। साझा बात सत्यापन है: डेवलपर समस्या तय करते हैं, प्रमाण देखते हैं और जिम्मेदारी रखते हैं। ये उपकरण विक्रेता द्वारा प्रकाशित अनुभव हैं, नियंत्रित उत्पादकता अध्ययन नहीं।
समाचार सुनें
यह लेख सुनें या समाचार लगातार चलाएँ।
पढ़ने की तैयारी हो रही है…
डिवाइस की आवाज़
वाक् प्रक्रिया आपके ब्राउज़र या डिवाइस में होती है। AISubHub पाठ किसी ऑडियो API को नहीं भेजता। आवाज़ों और लॉक स्क्रीन पर चलने की सुविधा डिवाइस पर निर्भर है।
जारी करने पर छोटा वाक्यांश दोहराया जा सकता है।
मुख्य बातें
- Baumgartner के अनुसार लगभग 900 स्लाइड वाली 15 प्रस्तुतियों का स्थानांतरण आठ से दस घंटे में हुआ; स्क्रीनशॉट, एनिमेशन और PDF की तुलना से जाँच की गई।
- Delporte ने Pi4J V4 का दोष बताया: वर्णित Raspberry Pi विन्यास में नेटिव पोलिंग ने चार कैरियर थ्रेड घेर लिए, जिससे पाँचवाँ इनपुट वॉचर चल ही नहीं पाया।
सहायक को परियोजना के पुराने मानक समझाएँ
Mihalcea जाँच-पड़ताल, डिबगिंग और प्रोटोटाइप के लिए IntelliJ IDEA में Copilot चलाते हैं। उनके अनुसार Optimizer इवेंट इतिहास वाला वेब ऐप, जिसे कई सप्ताह लगने की आशंका में टालते रहे थे, दो दिन में बना और Hypersistence Optimizer के अगले संस्करण के लिए नियोजित है। तुलना अनुमानित मेहनत से है, दो अलग कार्यान्वयनों के मापे समय से नहीं। गलत उत्तर होने पर वे हस्तक्षेप करते हैं और योजना तथा बनाए गए बदलावों की समीक्षा जारी रखते हैं।
उनके बनाए skills प्रकाशित 65 लेखों और 12 वर्ष के ब्लॉग से लेखन शैली लेते हैं तथा स्पष्ट, परीक्षण योग्य, सरल और पुराने नियमों से संगत कोड पर जोर देते हैं। कठिन काम के लिए वे दस लाख टोकन संदर्भ वाला Opus तथा Extra High या Max reasoning बताते हैं; रिपोर्ट और दस्तावेज जाँच में हल्के मॉडल लेते हैं। यह उनका कार्यप्रवाह है, सभी Copilot योजनाओं में इन सेटिंग की उपलब्धता का प्रमाण नहीं। हमारे अनुसार मॉडल के साथ परियोजना के नियम और काम का आकार भी मायने रखते हैं।
स्थानांतरण में अर्थ बचने का प्रमाण चाहिए
Baumgartner के Reveal.js से Marp स्थानांतरण में लगभग 900 स्लाइड और 15 प्रस्तुतियाँ थीं, जिनमें कोड, एनिमेशन और कक्षा में बदले जाने वाले JavaScript उदाहरण थे। निष्पादन से पहले सामग्री, लक्ष्य, सीमाएँ, उदाहरण और सुरक्षित रखने योग्य बातें तय कीं, फिर बड़ी संरचना से छोटे विवरण तक गए। वे आठ से दस घंटे बताते हैं; हाथ से एक सप्ताह या अधिक लगना उनका अनुमान था।
स्वीकृति केवल फाइल बदलने से नहीं मिली। स्क्रीनशॉट की दृश्य और एल्गोरिद्मिक तुलना हुई, दोनों प्रस्तुतियाँ साथ चलाकर एनिमेशन हाथ से देखे गए और बने PDF मिलाए गए। टाइप की गलती अपने आप ठीक हो सकती थी, पर अर्थ, सामग्री, संस्करण या तारीख बदलने पर चर्चा जरूरी थी। AISubHub के अनुसार जब जरूरत शिक्षण क्रम बचाना हो, सभी फाइलों का मौजूद होना और सफल रूपांतरण पर्याप्त प्रमाण नहीं हैं।
सुधार घोषित करने से पहले उपयोगकर्ता का प्लेटफ़ॉर्म दोहराएँ
Tamboui से बना टर्मिनल ऐप WSL के Linux में सही चलता था, लेकिन एक उपयोगकर्ता ने पाया कि नेटिव Windows CMD या PowerShell में कुछ फॉर्म Enter को अनदेखा करते हैं। Baumgartner ने इसे UI परीक्षणों में बदला, Linux में tmux इस्तेमाल किया और समान PowerShell प्रवाह के लिए psmux जाना। उन्होंने व्यवहार दोहराया, स्थानीय सुधार बनाया, असली कारण Tamboui में खोजा और ऊपर के प्रोजेक्ट में भेजा गया बदलाव स्वीकार हुआ।
जब परीक्षण विवरण उपलब्ध संदर्भ से बड़े हुए, दोहराव वाली तालिकाओं की जगह संक्षिप्त चरण संकेत लिए और जरूरी जानकारी रखी। इसका अर्थ assertions हटाना नहीं है। हमारे विश्लेषण में प्रस्तुति को क्रिया, इनपुट और अपेक्षित व्यवहार सुरक्षित रखना चाहिए; Linux पर पास होना Windows की शिकायत का उत्तर नहीं। साक्षात्कार सार्वभौमिक संगतता सूची या रनटाइम के सटीक संस्करण नहीं देता।
निष्पादन तेज करने से पहले आवश्यकताएँ साफ करें
शिक्षण ऐप में सीखने के तरीकों और असली पाठ्यक्रम की चर्चा ने दिशा बदली: तुरंत सभी देशों के बजाय Baumgartner ने स्विट्जरलैंड की कक्षा एक से चार के अंकगणित पर ध्यान दिया। जर्मन, फ्रेंच, इतालवी और अंग्रेजी, गलती के बाद समझाना और दोहराया अभ्यास, तथा दो खिलाड़ियों के मोड उपलब्ध हैं। उन्होंने बैकएंड नहीं रखा, बच्चों का डेटा उपकरण पर रखा और GitHub Pages पर ऐप होस्ट किया। यह बताया गया डिजाइन है, सुरक्षा ऑडिट नहीं।
लगभग चार घंटे की यात्रा में उन्होंने फोन से Spring Boot ऑटो-कॉन्फिगरेशन के Maven प्लगइन का काम भी निर्देशित किया, CI, नमूना ऐप के प्रदर्शन परीक्षण और रिपोर्ट देखीं। पहले Spring Boot 3.5 और 4.x दोनों माँगने से वास्तु अंतर के कारण दो रास्ते बने; बाद में अनावश्यक 3.5 रास्ता हटाना महँगा पड़ा। ये उदाहरण छोटे निर्णय और शुरुआती स्पष्टता का समर्थन करते हैं, किसी भी प्लगइन को चार घंटे में बनाकर सत्यापित करने की गारंटी नहीं।
पाँचवाँ बटन चुप क्यों रह सकता था
Delporte का मामला फरवरी 2026 में Foreign Function & Memory API प्लगइन के साथ आए Pi4J V4 का है। चार इनपुट बटन चलते थे, पाँचवाँ न इवेंट देता, न exception, न warning। पुराने gpiod प्लगइन में वही हार्डवेयर और ऐप सही थे। उन्होंने provider class और FFMDigitalInput के दो शुरुआती फाइल पथ दिए और लगभग आधे घंटे बाद प्रस्तावित pull request मिलने की बात कही।
बताए गए निदान में हर वॉचर GPIO बदलाव के इंतजार में नेटिव poll() में ब्लॉक होता था। उस कॉल में अटका virtual thread अपने carrier से अलग नहीं हो सकता था। चार कोर वाले Raspberry Pi 4 के चारों carrier चार वॉचर ने घेर लिए और पाँचवाँ schedule नहीं हुआ। यह घटनाएँ अस्थिर कहने से अधिक उपयोगी कारण है। फिर भी यह साक्षात्कार का निदान है, हर Java संस्करण या virtual-thread ऑपरेशन का नियम नहीं। बदलाव maintainers की समीक्षा और मंजूरी के बाद ही merge हुए।
सीख को जाँच में बदलें, बिना समीक्षा का वादा न बनाएँ
Baumgartner maintainer-audit जैसे दोबारा इस्तेमाल होने वाले skills रखते हैं और स्पष्ट पूर्णता कसौटियों के उदाहरण के तौर पर unlazy बताते हैं। उनका गुणवत्ता ढाँचा Checkstyle, PMD और Spring Modulith की वास्तु जाँच जोड़ता है, ताकि एजेंट बदलाव करे, जाँच चलाए, निष्कर्ष पढ़े और सुधारे। दृश्य फीडबैक के लिए VS Code, बड़े काम के लिए terminal या coding agent और जरूरत होने पर ही MCP चुनते हैं; अच्छी CLI बेहतर हो सकती है। AISubHub ने ये skills चलाकर नहीं परखे।
Delporte एक उपयोगी निदान कसौटी जोड़ते हैं: regression test पुराने कोड पर असफल हो और सुधार के बाद पास हो। समझ आने वाला स्पष्टीकरण भी परिणाम है; दोहराए कोड और रखरखाव की समीक्षा जरूरी है। हमारी सलाह है कि प्रमाण पहले तय करें, स्वतंत्र जाँच करें और इंसान को अंतिम स्वीकृति दें। केवल स्थैतिक जाँच एनिमेशन, नेटिव प्लेटफ़ॉर्म का व्यवहार या शिक्षा की उपयुक्तता सिद्ध नहीं करती; मूल अनुभवों में भी लोग सॉफ्टवेयर चलाते और परखते हैं।
यह क्यों अहम है
AISubHub का विश्लेषण: दोहराने योग्य चीज पूरा फीडबैक चक्र है, जिसमें गलत धारणाएँ और जाँच भी हों। टीम एक प्रतिनिधि काम आजमा सकती है, वातावरण दर्ज कर सकती है और अधिक काम सौंपने से पहले देख सकती है कि प्रस्तावित प्रमाण गलत उत्तर पकड़ पाएँगे या नहीं।
सीमाएँ और उपलब्धता
समय और नतीजे साक्षात्कार देने वालों के दावे हैं। हमने कोड नहीं चलाया, हार्डवेयर दोष नहीं दोहराया, जुड़े pull requests नहीं जाँचे और skills का ऑडिट नहीं किया। लेख नियंत्रित आधाररेखा, सामान्य गति लाभ या सभी योजनाओं में समान मॉडल अधिकार नहीं देता; हर परियोजना के संस्करण और प्लेटफ़ॉर्म अलग जाँचने होंगे।
स्रोत और प्रमाण
स्रोत की तारीख: · स्रोत जाँचा गया:
AI की सहायता से लिखे लेखों को दिए गए प्राथमिक स्रोतों से जाँचा जाता है। प्रदाता के दावों का श्रेय स्पष्ट है; सूची में होना समर्थन नहीं है।