உங்கள் Repo ஒருபோதும் முழுக் கதையல்ல

ஒரு feature வெளியான ஆறு மாதங்கள் கழித்து ஒரு repository-ஐத் திறந்தால், அதிலிருந்து பல விஷயங்களை மீண்டும் புரிந்துகொள்ள முடியும். architecture-ஐப் பின்தொடரலாம், schema-ஐ ஆய்வு செய்யலாம், tests-ஐப் படிக்கலாம், மேலும் எந்த வரிகள் மாறின என்பதையும் துல்லியமாகக் காணலாம்.

ஆனால் பொதுவாக மீண்டும் கட்டியெழுப்ப முடியாதது, அந்த வரிகள் ஏன் அவசியமானவை ஆனது என்பதை உருவாக்கிய உரையாடல்தான்.

ஒரு validation rule ஏன் உள்ளது என்பதை code உங்களுக்குச் சொல்லாது; அது ஒரு customer தவறான exports-ஐ அனுப்புவதாலாக இருக்கலாம். ஒரு விசித்திரமான retry policy, downstream system-இல் duplicate transactions-ஐத் தடுக்கிறது என்பதையும் அது விளக்காது. accessibility test-க்கு பிறகு சுத்தமான interface நிராகரிக்கப்பட்டது என்பதையோ, ஒரு service boundary என்பது engineering விருப்பத்தை விட contractual restriction-ஐ பிரதிபலிக்கிறது என்பதையோ அது காட்டாது.

Git, code history-ஐ பாதுகாப்பதில் சிறந்தது. ஆனால் intent-ஐ பாதுகாப்பது, ஒரு team அதை திட்டமிட்டு எழுதிப் பதிந்து, implementation-உடன் இணைத்துப் பராமரிக்கும் போது மட்டுமே நடக்கும்.

அந்த இடைவெளி எப்போதும் software engineering-இன் ஒரு பகுதியாகவே இருந்தது. AI coding tools அதை இன்னும் தெளிவாகக் காட்டுகின்றன. ஒரு system repository-இல் உள்ள ஒவ்வொரு file-ஐயும் வாசித்து, ஒவ்வொரு symbol-ஐயும் பின்தொடர்ந்து, தொழில்நுட்ப ரீதியாக நம்பத்தகுந்த patch-ஐ உருவாக்கலாம் — இருந்தாலும் அது தவறான பிரச்சினையையே தீர்த்துக் கொண்டிருக்கலாம்.

பிரச்சினை code தவறாக வழிநடத்துகிறது என்பதல்ல. code ஒரு குறுகிய கேள்விக்கே பதில் அளிக்கிறது.

பொறியியல் உண்மையின் ஐந்து அடுக்குகள்

அர்த்தமுள்ள பெரும்பாலான software மாற்றங்கள், ஐந்து வேறுபட்ட ஆதார அடுக்குகளின் மீது சார்ந்திருக்கின்றன.

1. Intent — user, customer, அல்லது business எந்த முடிவை கேட்கிறது? இது specification, ticket, support conversation, அல்லது meeting note-இல் இருக்கலாம்.
2. Constraints — எது உடையக் கூடாது? compatibility promises, security boundaries, regulations, contracts, budgets, மற்றும் deadlines பெரும்பாலும் repository-க்கு வெளியே இருக்கும்.
3. Implementation — இன்று system எப்படி செயல்படுகிறது? code, tests, schemas, dependencies, மற்றும் deployment configuration இந்த அடுக்கை வழங்குகின்றன.
4. Runtime evidence — உண்மையான system-இல் என்ன நடக்கிறது? logs, traces, metrics, production data, மற்றும் incident reports, code-இல் நியாயமாகத் தோன்றும் கருதுகோள்களுக்கே முரணாக இருக்கலாம்.
5. Decision history — தற்போதைய அணுகுமுறை ஏன் தேர்ந்தெடுக்கப்பட்டது? pull requests, design discussions, நிராகரிக்கப்பட்ட alternatives, மற்றும் முந்தைய incidents இதற்கான பதிலை வைத்திருக்கின்றன.

மூன்றாவது அடுக்கில் repository மிகவும் வலிமையானது. மற்ற அடுக்குகளின் சில பகுதிகள் அதில் இருக்கலாம், ஆனால் அவற்றை முழுமையாக பிரதிநிதித்துவப்படுத்தும் அளவுக்கு அரிதாகவே இருக்கும்.

இது முக்கியம், ஏனெனில் software தோல்விகள் பெரும்பாலும் இந்த அடுக்குகளுக்கிடையிலான எல்லைகளில்தான் தோன்றுகின்றன. implementation, காலாவதியான specification-ஐப் பொருந்துகிறது. fix, ticket-ஐ பூர்த்தி செய்கிறது, ஆனால் operational constraint-ஐ மீறுகிறது. tests pass ஆகின்றன, ஏனெனில் அவை நேற்று இருந்த கருதுகோள்களையே encode செய்கின்றன. code உள்மையாக ஒழுங்காக இருந்தாலும், production data யாரும் ஆவணப்படுத்தாத ஒரு pattern-ஐப் பின்பற்றுகிறது.

உள்ளூர் அளவில் சரியான patch கூட, இன்னும் தவறான மாற்றமாக இருக்கலாம்.

களஞ்சியம் தனியாக பதிலளிக்க முடியாதவை

ஒரு பயனர் ஒரு ஆவணத்தைத் திருத்தி, பின்னர் புதுப்பிக்கப்பட்ட வாக்கியத்தைத் தேடுகிறார்; ஆனால் முடிவுகளில் பழைய பதிப்பே தோன்றுகிறது என்று நினைத்துப் பாருங்கள். “தேடலை உடனடியாகப் புதுப்பிக்கவும்” என்பது தெளிவான கோரிக்கையாகத் தோன்றலாம். எங்கு தொடங்கலாம் என்பதற்கான பல சாத்தியமான இடங்களை களஞ்சியம் காட்டும், ஆனால் சரியான தீர்வை அது தனியாக வரையறுக்க முடியாது.

தேடல் குறியீடு முடிவுகள் எவ்வாறு திருப்பி வழங்கப்படுகின்றன என்பதை விளக்கக்கூடும். ஆனால் உண்மையான கோளாறு ஒத்திசைவு தாமதமா, பழைய extraction-ஆ, cache invalidation-ஆ, permission propagation-ஆ, அல்லது தயாரிப்பு ஒருபோதும் வரையறுக்காத ஒரு எதிர்பார்ப்பா என்பதை அது சொல்ல முடியாது.

முதிர்ந்த அமைப்புகளில் இந்த வேறுபாடு இன்னும் முக்கியமாகிறது. காலாவதியானதாகத் தோன்றும் ஒரு புலம் இன்னும் ஒரு legacy client-ஐ ஆதரித்துக் கொண்டிருக்கலாம். நகலாகத் தோன்றும் ஒரு சேவை, வேறுபட்ட அனுமதி தேவைகளுள்ள தரவைப் பிரித்திருக்கலாம். அளவுக்கு மீறியதாகத் தோன்றும் ஒரு சரிபார்ப்பு, தற்போதைய குழு ஒருபோதும் காணாத ஒரு production incident-இன் code-level சுவடாக மட்டுமே இருக்கலாம்.

சிக்கலை நீக்குவது மதிப்புடையது. ஆனால் சிக்கலாக மறைந்திருக்கும் வரலாற்றை நீக்குவது செலவானது.

கூடுதல் சூழலும் தவறான பதிலைத் தரலாம்

தெளிவாகத் தோன்றும் தீர்வு, AI-க்கு இன்னும் அதிகப் பொருள்களை வழங்குவதுதான்: முழு களஞ்சியம், ஒவ்வொரு ticket-மும், ஒவ்வொரு ஆவணமும், ஒவ்வொரு செய்தியும், ஒவ்வொரு log-மும்.

அது அணுகலை உருவாக்கும்; புரிதலை அல்ல.

மூலங்கள் காலாவதியானவையாகவும், ஒன்றுக்கொன்று முரண்படுபவையாகவும், ஊகத்தன்மையுடையவையாகவும், அல்லது வேறு வேறு வாசகர்களுக்காக எழுதப்பட்டவையாகவும் இருக்கலாம். ஒரு brainstorm, அங்கீகரிக்கப்பட்ட specification-ஐ விட மேலிடத்தில் இருக்கக் கூடாது. ஆறு மாதம் பழைய requirement, நேற்று எடுக்கப்பட்ட தயாரிப்பு முடிவை அமைதியாக மீறக் கூடாது. ஒரு production log, அதை உருவாக்கிய release, environment, மற்றும் code path-உடன் இணைக்கப்பட்டிருக்க வேண்டும். ஒரு வாடிக்கையாளர் கோரிக்கையை, அதன் வரம்பைச் சரிபார்க்காமல், பொதுவான requirement-ஆகக் கருதக் கூடாது.

எனவே, ஒரு தீவிரமான context system-க்கு retrieval மட்டும் போதாது. அது பின்வருவன குறித்து காரணப்பூர்வமாக சிந்திக்கும் ஒரு வழியையும் தேவைப்படுத்துகிறது:

• Authority: requirement-ஐ வரையறுக்க எந்த மூலம் அனுமதிக்கப்பட்டுள்ளது?
• Recency: எந்த தகவல் தற்போதையது, எது மாற்றப்பட்டுவிட்டது?
• Provenance: ஒவ்வொரு கூற்று, கட்டுப்பாடு, அல்லது முடிவு எங்கிருந்து வந்தது?
• Relationships: எந்த issue, release, customer, dataset, மற்றும் code path ஒன்றோடொன்று தொடர்புடையவை?
• Permissions: இந்த பணிக்காக எந்த மூலங்களைப் பயன்படுத்தலாம், மேலும் இந்த நபருக்கு எவற்றைக் காட்டலாம்?

Context என்பது tokens-ன் ஒரு குவியல் அல்ல. அது காலம், அதிகாரம், மற்றும் எல்லைகளைக் கொண்ட ஒரு graph.

மேலும் context கிடைப்பது, மேலும் ஆதாரங்களை உருவாக்க வேண்டும்; ஆதாரமில்லாத மேலும் நம்பிக்கையை அல்ல.

உண்மையான பணியலகு மாற்றமே

Editors மற்றும் coding tools, நாம் மாற்றுவது files என்பதால் files-ஐ மையமாகக் கொண்டு ஒழுங்குபடுத்தப்பட்டுள்ளன. Engineering teams, மாற்றங்களை மையமாகக் கொண்டு ஒழுங்குபடுத்தப்பட்டுள்ளன.

ஒரு மாற்றம் ஒரு காரணத்துடன் தொடங்குகிறது. அது ஒரு requirement-ஆக மாறுகிறது, code மற்றும் data-வைத் தொடுகிறது, review-ஐ கடக்கிறது, production-ஐ அடைகிறது, மேலும் புதிய ஆதாரங்களை உருவாக்குகிறது. அந்த நிலைகள் ஒன்றோடொன்று இணைக்கப்படாமல் இருந்தால், எதிர்காலத்தில் வரும் ஒவ்வொரு பணியும் மீண்டும் ஒரு archaeology சுற்றுடன் தொடங்கும்.

உண்மையான software-இல் வேலை செய்யும் ஒரு AI system, அந்த lifecycle-ஐப் பின்பற்ற வேண்டும்.

Implementation-க்கு முன், அது கோரிக்கையை, தொடர்புடைய கட்டுப்பாடுகளை, மற்றும் முரண்படும் மூலங்களை அடையாளம் காண வேண்டும். அது ஒரு defect-ஐ சரிசெய்கிறதா, எதிர்பார்க்கப்பட்ட நடத்தை மாற்றுகிறதா, அல்லது ஒரு புதிய contract-ஐ அறிமுகப்படுத்துகிறதா என்பதை அறிந்திருக்க வேண்டும்.

Implementation நடக்கும் போது, ஒவ்வொரு அர்த்தமுள்ள தேர்வையும் அது ஆதாரத்துடன் இணைக்க வேண்டும். ஏன் இந்த module? ஏன் இந்த migration strategy? ஏன் இந்த branch-ஐ பாதுகாக்க வேண்டும்? அந்த விளக்கம், code-ஐ உருவாக்கிய chat-ஐத் தாண்டியும் நிலைத்திருக்க வேண்டும்.

செயல்படுத்திய பிறகு, அது சரிபார்ப்பு முடிவுகள், மதிப்பாய்வு தீர்மானங்கள், மற்றும் புதிதாக கண்டறியப்பட்ட கட்டுப்பாடுகளை அந்த மாற்றத்துடன் இணைக்க வேண்டும். இல்லையெனில் அடுத்த நபர்—அல்லது அடுத்த AI அமர்வு—அவற்றை மீண்டும் கண்டுபிடிக்க வேண்டியிருக்கும்.

இதுவே ஒரு repository-ஐத் திருத்தக்கூடிய கருவிக்கும், பொறியியல் பணியில் பங்கேற்கக்கூடிய ஒரு அமைப்புக்கும் இடையிலான வித்தியாசம்.

AI தீர்மானத்தை நீக்காமல், மறுகட்டமைப்பை குறைக்க வேண்டும்

மேம்பட்ட context சில நேரங்களில் தன்னாட்சி மென்பொருள் உருவாக்கத்திற்கான பாதையாகக் காட்டப்படுகிறது. ஆனால் அதன் உடனடி மதிப்பு அதைவிட குறைவாக நாடகமயமானதும், அதிகம் பயனுள்ளதுமானதும் ஆகும்: ஒரு மாற்றம் செய்வதற்கு முன் நிஜ நிலையை மறுகட்டமைப்பதற்கான செலவை குறைப்பது.

AI, ஆரம்ப தேவையை தொடர்புடைய code-க்கு அருகில் கொண்டு வர முடியும். ஒரு விசித்திரமான பாதுகாப்பு ஏற்பாட்டை விளக்கும் incident-ஐ வெளிக்கொணர முடியும். தோல்வியுறும் ஒரு metric-ஐ அதை மாற்றிய release-உடன் இணைக்க முடியும். செயல்படுத்தல் தொடங்குவதற்கு முன்பே, அதிகாரப்பூர்வமான இரண்டு ஆதாரங்கள் ஒன்றுக்கொன்று முரண்படுகின்றன என்பதை காட்ட முடியும்.

அந்த திறன்கள் பொறியியல் தீர்மானத்தை நீக்குவதில்லை. அவை அந்தத் தீர்மானம் மேலும் தகவலறிந்ததாக இருக்க உதவுகின்றன.

எந்த tradeoff ஏற்றுக்கொள்ளத்தக்கது, ஒரு requirement முழுமையானதா, மற்றும் ஒரு release எவ்வளவு ஆபத்தை சுமக்க முடியும் என்பதைக் குறித்து இன்னும் ஒரு நபரே முடிவு செய்ய வேண்டும். அமைப்பு ஆதாரங்களை தெளிவாகக் காட்டவும், காரணப்பூர்வ சிந்தனையை ஆய்வு செய்யக்கூடியதாகவும் மாற்ற வேண்டும். மெருகூட்டப்பட்ட patch-ன் பின்னால் அது நிச்சயமின்மையை மறைக்கக் கூடாது.

அளவுகோல் “அது code உருவாக்க முடியுமா?” என்பதல்ல.

அளவுகோல் “இப்போது இதுவே சரியான மாற்றம் என்பதைக் அது விளக்க முடியுமா?” என்பதாகும்.

Repository-aware இலிருந்து work-aware நோக்கி

டெவலப்பரின் முன் இருக்கும் file-ஐப் புரிந்துகொள்வதன் மூலம் coding assistants முதலில் பயனுள்ளதாக ஆனது. Repository awareness அடுத்த பெரிய படியாக இருந்தது: தொடர்புடைய code-ஐ கண்டுபிடித்தல், symbols-ஐப் பின்தொடர்தல், மற்றும் ஒரு project முழுவதும் மாற்றங்களைப் பயன்படுத்துதல்.

அடுத்த படி repository-ஐச் சுற்றியுள்ள பணியைப் பற்றிய விழிப்புணர்வு ஆகும்.

அதாவது, code-ஐ அதை கோரிய specification-உடன், அதைத் தெளிவுபடுத்திய conversation-உடன், அதைச் சவாலிட்ட production evidence-உடன், மற்றும் பின்னர் நினைவில் வைத்திருக்க வேண்டிய decision-உடன் இணைப்பது. அதே நேரத்தில், தொடர்பில்லாத, காலாவதியான, அல்லது பயனரின் அனுமதிகளுக்கு வெளியேயுள்ள context-ஐ விலக்குவதையும் அது குறிக்கிறது.

Dvina-ஐ உருவாக்கும் போது, நாங்கள் மீண்டும் மீண்டும் திரும்பிச் செல்லும் கருத்துகளில் இதுவும் ஒன்று. பணி என்பது ஒரு file, application, அல்லது conversation-க்குள் மட்டும் நடைபெறுவதில்லை. அர்த்தம் அவற்றுக்கிடையிலான இணைப்புகளில் வாழ்கிறது; மேலும் அந்த இணைப்புகள் காலப்போக்கில் எப்படி மாறுகின்றன என்பதிலும் அது இருக்கிறது.

Repository இன்னும் அத்தியாவசியமானதே. அது அமைப்பின் நடத்தைக்கான செயல்படுத்தக்கூடிய உண்மையின் மூலமாகும். ஆனால் தயாரிப்பு நோக்கம், செயல்பாட்டு நிஜம், அல்லது நிறுவன நினைவகம் ஆகியவற்றுக்கான முழுமையான உண்மையின் மூலம் அது அல்ல.

முழுக் கதை என்ன உருவாக்கப்படுகிறது என்பதை மாற்றுகிறது

code மட்டும் இருந்தால், இயல்பான கேள்வி இதுதான்:

இந்த அமைப்புக்கு ஏற்ற மாற்றம் எது?

விரிவான context உடன், கேள்வி இவ்வாறு மாறுகிறது:

இந்த அமைப்புக்கும், இந்த requirement-க்கும், இந்த வரலாற்றுக்கும், இந்த தருணத்துக்கும் ஏற்ற மாற்றம் எது?

அந்த இரண்டாவது கேள்வி, கட்டுப்பாடுகள் பின்னடைவு பிரச்சினைகளாக மாறுவதற்கு முன்பே அவற்றைக் கண்டுபிடிக்கிறது. அது செயலாக்கத்தின் பின்னுள்ள காரணத்தை மதிப்பாய்வாளர்களுக்கு விளக்குகிறது. அமைப்பு ஏன் இவ்வாறு இருக்கிறது என்பதை புதிய குழு உறுப்பினர்கள் புரிந்துகொள்ள அது உதவுகிறது. அது AI-க்கு நிலைநிறுத்தப்பட்ட ஒரு பங்கைக் கொடுக்கிறது: எடிட்டருக்குள் இருக்கும் ஒரு oracle ஆக அல்ல, வேலை முழுவதும் உள்ள ஆதாரங்களை ஒன்றுசேர்க்கக்கூடிய ஒரு பங்கேற்பாளராக.

உங்கள் repo ஒருபோதும் முழுக் கதையாக இருந்ததில்லை.

மீதமுள்ள அனைத்தையும் வாசிக்கக்கூடிய—மேலும் தன் பணியை வெளிப்படையாகக் காட்டக்கூடிய—அமைப்புகளை உருவாக்குவதில்தான் வாய்ப்பு இருக்கிறது.