நீங்கள் ஒரு காபி குடிப்பதை முடிக்கும் நேரத்திற்குள் ஒரு AI agent ஒரு முழுமையான feature branch-ஐ உருவாக்கிவிடும். ஒரு நன்கு எழுதப்பட்ட prompt-க்கு பிறகு ஆயிரக்கணக்கான வரிகள் தோன்றுகின்றன. அந்த வேகம் ஒரு அடிப்படை உண்மையை மாற்றாது: உங்கள் repository-க்குள் நுழையும் code இன்னும் மனிதத் தீர்ப்பை (human judgment) எதிர்பார்க்கிறது. Review என்பது ஒரு மெருகூட்டும் படிநிலை அல்ல. அது இயங்கும் மென்பொருளுக்கும், அமைதியாகத் திரளும் technical debt-க்கும் இடையிலான ஒரு சுவர்.
வேலையின் தன்மை மாறிவிட்டது. முன்பு நாம் ஒரு editor-இல் வரி வரியாக logic-ஐத் தட்டச்சு செய்வதற்கே மன ஆற்றலைச் செலவிட்டோம். இப்போது அந்த அறிவுசார் சுமை (cognitive load) மாறியுள்ளது. Code எழுதுவது இனி கடினமான காரியம் அல்ல. அதை வாசிப்பதும், கேள்வி கேட்பதும், அது உண்மையில் உங்கள் சிஸ்டத்திற்குத் தேவையா என்று தீர்மானிப்பதும் தான் கடினமான விஷயம்.
இந்த மாற்றம் code review-விற்கு ஒரு மாறுபட்ட அணுகுமுறையைக் கோருகிறது. குழுக்கள் எவ்வாறு மாற்றிக்கொள்ள வேண்டும் என்பது இதோ.
மற்றவர்கள் பார்ப்பதற்கு முன்பே Code-ன் பொறுப்பை ஏற்றுக் கொள்ளுங்கள்
ஒரு அந்நியர் உங்கள் branch-இல் code-ஐச் சேர்த்தது போல நீங்கள் AI-ஆல் உருவாக்கப்பட்ட code-ஐ ஆய்வு செய்ய வேண்டும். அந்த வித்தியாசம் முக்கியமானது. ஒவ்வொரு வரியையும் நீங்களே கையால் எழுதும்போது, அதன் சூழல் (context) உங்களுக்கு இயல்பாகவே தெரியும். அந்த loop ஏன் பூஜ்ஜியத்திற்குப் பதிலாக ஒன்றில் தொடங்குகிறது என்பது உங்களுக்குத் தெரியும். இப்போது நீங்கள், மனிதரால் முடியாத வேகத்தில் வேலை செய்யும், ஆனால் தெளிவுபடுத்தும் கேள்விகளைக் கேட்காத ஒரு ஆர்வமுள்ள ஒப்பந்ததாரரை (contractor) வழிநடத்தும் ஒரு tech lead போல இருக்கிறீர்கள்.
இதுவே உங்கள் செயல்முறையில் self-review-ஐ மிக முக்கியமான நுழைவாயிலாக மாற்றுகிறது. நீங்கள் ஒரு pull request-ஐ உருவாக்குவதற்கு முன்பே, சற்று பின்வாங்கி கடினமான கேள்விகளைக் கேளுங்கள்.
குறியீடு உங்கள் architecture-ஐ மதிக்கிறதா? உருவாக்கப்பட்ட code பெரும்பாலும் உங்கள் நடைமுறைகளுக்கு (conventions) பொருந்தாத, பயிற்சித் தரவுகளிலிருந்து (training data) பெறப்பட்ட முறைகளை இறக்குமதி (import) செய்கின்றன. உங்கள் குழு monolith-இல் logic-ஐ வைத்திருக்க ஒப்புக்கொண்டபோது, அது ஒரு புதிய service-ஐ உருவாக்கலாம், அல்லது உங்கள் உள் logging தரநிலையைத் தவிர்த்துவிட்டு சாதாரண print statements-களைப் பயன்படுத்தலாம்.
அது சரியான சிக்கலைத் தீர்க்கிறதா? AI மாதிரிகள் prompt-ஐ முடிப்பதற்கே முன்னுரிமை அளிக்கின்றன, ticket-இன் edge cases-களைப் புரிந்துகொள்வதற்கு அல்ல. உங்கள் issue ஒரு பகுதி ரீஃபண்ட் (partial refund) கையாளுதலைப் பற்றி விவரித்தால், உருவாக்கப்பட்ட code எளிதான பாதையை (happy path) மட்டும் கையாண்டுவிட்டு, reconciliation தோல்வியைத் பயனருக்கே விட்டுவிடலாம்.
அதே வேலையைக் குறைந்த code-உடன் செய்ய முடியுமா? AI அதிகப்படியான விவரங்களை (verbosity) எழுதுகிறது. அது உண்மையான logic-ஐ மறைக்கும் வகையில் defensive wrappers, தேவையற்ற comments மற்றும் சிக்கலான error handling ஆகியவற்றை எழுதுகிறது. மீண்டும் மீண்டும் வரும் அமைப்புகள் (structure), எந்தப் பயனும் இல்லாத imports அல்லது மாறாத (never mutate) variables ஆகியவற்றைக் கவனியுங்கள். தேவையற்றவற்றை நீக்குங்கள். ஏஜென்ட்டை எளிமைப்படுத்தவும் (simplify) மற்றும் refactor செய்யவும் நீங்கள் prompt செய்தால், அதை எவ்வாறு வழிநடத்துவது என்பதையும் நீங்கள் கற்றுக்கொள்வீர்கள். எந்தக் கட்டுப்பாடுகள் தேவையற்ற விஷயங்களை நீக்குகின்றன என்பதைக் கண்டறிவீர்கள். இந்தத் தொடர்ச்சியான செம்மைப்படுத்துதல் இப்போது உங்கள் வேலையின் ஒரு பகுதியாகும். Pull request-இல் உங்கள் பெயர் உள்ளது. ஒவ்வொரு வரியிற்கும் நீங்களே பொறுப்பு.
இயந்திரங்களை ஸ்கேன் செய்ய விடுங்கள், ஆனால் உங்கள் மூளையைச் செயல்பாட்டில் வைத்திருங்கள்
Automated review கருவிகள் உங்கள் CI pipeline-இல் இருக்க வேண்டும். நவீன AI-ஆல் இயங்கும் reviewers, injection vulnerabilities போன்ற பாதுகாப்பு அபாயங்களைக் கண்டறியலாம், கையாளப்படாத edge cases-களைச் சுட்டிக்காட்டலாம் மற்றும் production-க்குச் செல்லும் முன் காலாவதியான dependencies-களைப் பிடிக்கலாம். அவை சிறப்பாகச் செயல்படும் மற்றும் அவை சோர்வடையாது.
அவற்றைப் பயன்படுத்துங்கள். ஆனால் அவற்றைப் போற்றாதீர்கள்.
இந்தத் கருவிகளுக்கு வணிகச் சூழல் (business context) தெரியாது. ஒரு automated reviewer, உங்கள் middleware ஏற்கனவே ஒரு வேறு நிலையில் sanitization-ஐக் கையாண்டு வருகிறது என்பதை அறியாமல், string concatenation பயன்படுத்துவதால் ஒரு database query-ஐ ஆபத்தானது என்று சுட்டிக்காட்டலாம். நீங்கள் பயன்படுத்தும் library version-இல் ஒரு breaking change உள்ளது என்பதை அறியாமல், ஒரு custom algorithm-ஐ library call-ஆக மாற்றப் பரிந்துரைக்கலாம். இந்தப் பரிந்துரைகள் வடிவங்களின் (patterns) அடிப்படையில் எடுக்கப்பட்ட யூகங்களே தவிர, உங்கள் தயாரிப்பைப் பற்றிய ஆழமான அறிவு அல்ல.
எப்போதும் பின்னூட்டங்களை (feedback) கவனமாகப் படித்துவிட்டு, பிறகு முடிவெடுங்கள். Automated comments-களை சிக்னல்களாகக் கருதுங்கள், கட்டளைகளாக அல்ல.
மேலும் ஒரு நடைமுறை
