कर्सर नियम लिखना जो एआई को पुराने कोडबेस में व्यवहार करने योग्य बनाता है
एआई कोडिंग सहायक विरासत परियोजनाओं में गलत व्यवहार करते हैं क्योंकि वे आपकी बाधाओं को नहीं जानते हैं। एक छोटी नियम फ़ाइल ने मेरे आधे बुरे अंतर को ठीक कर दिया।
हमारे चार-वर्षीय कोडबेस में एजेंट-संचालित विकास के मेरे पहले सप्ताह ने सुंदर कोड का उत्पादन किया जिसने तीन टीम सम्मेलनों और एक वास्तुशिल्प निर्णय का उल्लंघन किया जिसके बारे में हमने महीनों तक संघर्ष किया था। सुधार बेहतर संकेत नहीं दे रहा था; यह संविधान लिख रहा था।
एक अच्छी नियम फ़ाइल छोटी और नकारात्मक होती है। मेरा सूचीबद्ध करता है कि कोडबेस को कभी भी क्या नहीं करना चाहिए: कोई नई राज्य प्रबंधन लाइब्रेरी नहीं, तिथियां दिनांक नहीं हैं, प्रत्येक एपीआई मार्ग मौजूदा ज़ोड स्कीमा के साथ मान्य होता है, और विरासत के तहत/बिना पूछे फ़ाइलों को कभी नहीं छूता है। बाधाएँ, आकांक्षाएँ नहीं, वे हैं जो मॉडल व्यवहार को बदलती हैं।
अप्रत्याशित जीत प्रत्येक नियम के लिए एक खंड में क्यों का दस्तावेजीकरण कर रही थी। जिस मॉडल को पता है कि पिछली तिमाही में माइग्रेशन में कमी आई है, वह केवल सावधान रहने के लिए कहे गए माइग्रेशन कोड की तुलना में अधिक सतर्क माइग्रेशन कोड लिखता है। संदर्भ नियमों को पालन किए गए से समझे गए में परिवर्तित करता है, और समझे गए नियम उन मामलों के लिए सामान्यीकृत होते हैं जिन्हें आपने सूचीबद्ध नहीं किया है।
स्थानीय सम्मेलनों के लिए प्रति निर्देशिका एक दूसरी नियम फ़ाइल रखें, मेरे घटक फ़ोल्डर का अपना है, और वैश्विक को ब्लॉट करने की इच्छा का विरोध करें। मैंने अपना पहला ड्राफ्ट चालीस पंक्तियों से घटाकर बारह कर दिया और अंतर बेहतर हो गया, क्योंकि आपके द्वारा जोड़ी गई प्रत्येक पंक्ति उन पंक्तियों को कम कर देती है जो मायने रखती हैं।
छह सप्ताह में, मापने योग्य परिणाम: सम्मेलन-उल्लंघन का अंतर तीन में से एक से घटकर शायद ही कभी रह गया, और कोड समीक्षा टिप्पणियाँ शैली से वापस तर्क में स्थानांतरित हो गईं। नियम फ़ाइल सबसे सस्ता वरिष्ठ इंजीनियर है जिसे मैंने कभी काम पर रखा है।