మీ రిపో ఎప్పుడూ పూర్తి కథ కాదు

ఒక ఫీచర్ విడుదలై ఆరు నెలలు గడిచిన తర్వాత రిపోజిటరీని తెరిస్తే, చాలా విషయాలను మళ్లీ నిర్మించుకోవచ్చు. ఆర్కిటెక్చర్‌ను అనుసరించవచ్చు, స్కీమాను పరిశీలించవచ్చు, టెస్టులను చదవవచ్చు, ఏ లైన్లు మారాయో కచ్చితంగా చూడవచ్చు.

కానీ సాధారణంగా మళ్లీ నిర్మించలేనిది, ఆ లైన్లు ఎందుకు అవసరమయ్యాయో నిర్ణయించిన సంభాషణే.

ఒక కస్టమర్ తప్పుగా రూపొందించిన ఎక్స్‌పోర్ట్‌లను పంపుతుండటంతో ఒక వాలిడేషన్ నియమం ఉందని కోడ్ మీకు చెప్పదు. డౌన్‌స్ట్రీమ్ సిస్టమ్‌లో డూప్లికేట్ ట్రాన్సాక్షన్‌లను నివారించడానికి ఒక విచిత్రమైన రీట్రై పాలసీ ఉందని అది వివరించదు. యాక్సెసిబిలిటీ టెస్ట్ తర్వాత మరింత శుభ్రమైన ఇంటర్‌ఫేస్‌ను తిరస్కరించారని, లేదా ఒక సర్వీస్ బౌండరీ ఇంజినీరింగ్ అభిరుచికన్నా ఒప్పంద పరిమితిని ప్రతిబింబిస్తోందని కూడా అది చూపదు.

కోడ్ చరిత్రను నిల్వ చేయడంలో Git అద్భుతంగా పనిచేస్తుంది. కానీ ఒక టీమ్ ఉద్దేశాన్ని ఉద్దేశపూర్వకంగా రాసి, అమలుతో అనుసంధానంగా ఉంచినప్పుడే అది ఆ ఉద్దేశాన్ని కూడా నిల్వ చేస్తుంది.

ఆ ఖాళీ ఎప్పటినుంచో సాఫ్ట్‌వేర్ ఇంజినీరింగ్‌లో భాగమే. AI కోడింగ్ టూల్స్ దాన్ని మరింత స్పష్టంగా కనిపించేలా చేస్తున్నాయి. ఒక సిస్టమ్ రిపోజిటరీలోని ప్రతి ఫైల్‌ను చదవగలదు, ప్రతి సింబల్‌ను అనుసరించగలదు, సాంకేతికంగా నమ్మదగిన ప్యాచ్‌ను సృష్టించగలదు — అయినప్పటికీ తప్పు సమస్యనే పరిష్కరిస్తూ ఉండవచ్చు.

సమస్య కోడ్ తప్పుదారి పట్టిస్తోందనేది కాదు. కోడ్ కేవలం మరింత సంకుచితమైన ప్రశ్నకు సమాధానం ఇస్తోంది.

ఇంజినీరింగ్ సత్యం యొక్క ఐదు స్థరాలు

అర్థవంతమైన చాలా సాఫ్ట్‌వేర్ మార్పులు ఐదు వేర్వేరు స్థాయిల ఆధారాలపై ఆధారపడుతాయి.

1. ఉద్దేశం — యూజర్, కస్టమర్, లేదా వ్యాపారం ఏ ఫలితాన్ని కోరుతోంది? ఇది ఒక స్పెసిఫికేషన్, టికెట్, సపోర్ట్ సంభాషణ, లేదా మీటింగ్ నోట్‌లో ఉండవచ్చు.
2. పరిమితులు — ఏమి దెబ్బతినకూడదు? కంపాటిబిలిటీ హామీలు, సెక్యూరిటీ సరిహద్దులు, నియమాలు, ఒప్పందాలు, బడ్జెట్లు, డెడ్‌లైన్‌లు తరచుగా రిపోజిటరీకి బయట ఉంటాయి.
3. అమలు — ఈరోజు సిస్టమ్ ఎలా పనిచేస్తోంది? కోడ్, టెస్టులు, స్కీమాలు, డిపెండెన్సీలు, డిప్లాయ్‌మెంట్ కాన్ఫిగరేషన్ ఈ స్థాయిని అందిస్తాయి.
4. రన్‌టైమ్ ఆధారాలు — నిజమైన సిస్టమ్‌లో ఏమి జరుగుతోంది? లాగ్‌లు, ట్రేస్‌లు, మెట్రిక్స్, ప్రొడక్షన్ డేటా, ఇన్సిడెంట్ రిపోర్ట్‌లు కోడ్‌లో సమంజసంగా కనిపించే ఊహలను ఖండించవచ్చు.
5. నిర్ణయ చరిత్ర — ప్రస్తుత విధానాన్ని ఎందుకు ఎంచుకున్నారు? పుల్ రిక్వెస్ట్‌లు, డిజైన్ చర్చలు, తిరస్కరించిన ప్రత్యామ్నాయాలు, గత ఇన్సిడెంట్లు దీనికి సమాధానం ఇస్తాయి.

రిపోజిటరీ మూడో స్థాయిలోనే అత్యంత బలంగా ఉంటుంది. మిగతా స్థాయిలలోని కొన్ని భాగాలు అందులో ఉంటాయి, కానీ వాటిని పూర్తిగా ప్రతినిధ్యం చేయడానికి సాధారణంగా సరిపోవు.

ఇది ముఖ్యమైనది, ఎందుకంటే సాఫ్ట్‌వేర్ వైఫల్యాలు తరచుగా ఈ స్థాయిల మధ్య సరిహద్దుల్లోనే కనిపిస్తాయి. అమలు పాతబడిన స్పెసిఫికేషన్‌కు సరిపోతుంది. పరిష్కారం టికెట్‌ను తీరుస్తుంది కానీ ఆపరేషనల్ పరిమితిని ఉల్లంఘిస్తుంది. టెస్టులు పాస్ అవుతాయి, ఎందుకంటే అవి నిన్నటి ఊహలను కోడ్ చేశాయి. కోడ్ అంతర్గతంగా సుసంగతంగా ఉంటుంది, కానీ ప్రొడక్షన్ డేటా మాత్రం ఎవరూ డాక్యుమెంట్ చేయని ఒక నమూనాను అనుసరిస్తుంది.

లోకల్‌గా సరైన ప్యాచ్ అయినా, అది తప్పు మార్పే కావచ్చు.

రిపోజిటరీ ఒక్కటే సమాధానం ఇవ్వలేని విషయాలు

ఒక వినియోగదారు డాక్యుమెంట్‌ను సవరించి, తర్వాత నవీకరించిన వాక్యాన్ని వెతికితే, ఫలితాల్లో మాత్రం పాత వెర్షన్ కనిపిస్తోందని ఊహించండి. “శోధన వెంటనే నవీకరించాలి” అనేది స్పష్టమైన అభ్యర్థనలా అనిపిస్తుంది. ఎక్కడి నుంచి ప్రారంభించాలో రిపోజిటరీ కొన్ని సాధ్యమైన చోట్లను చూపిస్తుంది, కానీ సరైన పరిష్కారాన్ని అది ఒక్కటే నిర్వచించలేడు.

శోధన కోడ్ ఫలితాలు ఎలా తిరిగి వస్తాయో వివరించవచ్చు. కానీ అసలు లోపం సమకాలీకరణ ఆలస్యం, పాతబడిన ఎక్స్‌ట్రాక్షన్, క్యాష్ ఇన్‌వాలిడేషన్, అనుమతుల ప్రసారం, లేదా ఉత్పత్తి ఎప్పుడూ నిర్వచించని ఒక అంచనా — వీటిలో ఏదో ఒకటేనని అది చెప్పలేడు.

పరిపక్వమైన వ్యవస్థల్లో ఈ తేడా ఇంకా ముఖ్యమవుతుంది. పాతబడిపోయినట్టుగా కనిపించే ఒక ఫీల్డ్ ఇంకా ఒక లెగసీ క్లయింట్‌కు మద్దతు ఇస్తుండవచ్చు. నకిలీలా కనిపించే ఒక సర్వీస్, వేర్వేరు అనుమతి అవసరాలున్న డేటాను వేరు చేస్తుండవచ్చు. అతిగా అనిపించే ఒక చెక్, ప్రస్తుత బృందం ఎప్పుడూ చూడని ఒక ప్రొడక్షన్ ఘటనకు కోడ్-స్థాయి ఆనవాళ్లలో ఏకైకదై ఉండవచ్చు.

సంక్లిష్టతను తొలగించడం విలువైనది. కానీ సంక్లిష్టతలా కనిపించే చరిత్రను తొలగించడం ఖరీదైనది.

మరింత సందర్భం ఉన్నా కూడా తప్పు సమాధానం రావచ్చు

స్పష్టంగా కనిపించే పరిష్కారం AIకి మరింత సమాచారం ఇవ్వడమే: మొత్తం రిపోజిటరీ, ప్రతి టికెట్, ప్రతి డాక్యుమెంట్, ప్రతి సందేశం, ప్రతి లాగ్.

అది ప్రాప్యతను సృష్టిస్తుంది, అవగాహనను కాదు.

మూలాలు పాతబడిపోయి ఉండవచ్చు, పరస్పర విరుద్ధంగా ఉండవచ్చు, ఊహాపోహలపై ఆధారపడి ఉండవచ్చు, లేదా వేర్వేరు ప్రేక్షకుల కోసం రాయబడి ఉండవచ్చు. ఒక బ్రెయిన్‌స్టార్మ్ ఆమోదించబడిన స్పెసిఫికేషన్ కంటే పైచేయి సాధించకూడదు. ఆరు నెలల పాత అవసరం నిన్నటి ఉత్పత్తి నిర్ణయాన్ని నిశ్శబ్దంగా అధిగమించకూడదు. ఒక ప్రొడక్షన్ లాగ్ దాన్ని ఉత్పత్తి చేసిన విడుదల, పరిసరాలు, మరియు కోడ్ పాత్‌తో అనుసంధానించబడాలి. ఒక కస్టమర్ అభ్యర్థనను దాని పరిధిని తనిఖీ చేయకుండా సార్వత్రిక అవసరంగా పరిగణించకూడదు.

అందువల్ల, ఒక గంభీరమైన సందర్భ వ్యవస్థకు కేవలం retrieval కంటే ఎక్కువ అవసరం. ఇది ఈ విషయాలపై తర్కించగల మార్గాన్ని అవసరం పడుతుంది:

• అధికారిత్వం: అవసరాన్ని నిర్వచించడానికి ఏ మూలానికి అనుమతి ఉంది?
• తాజాదనం: ప్రస్తుతం ఏ సమాచారం చెల్లుబాటులో ఉంది, ఏది భర్తీ చేయబడింది?
• మూలాధారం: ప్రతి వాదన, పరిమితి, లేదా నిర్ధారణ ఎక్కడి నుంచి వచ్చింది?
• సంబంధాలు: ఏ issue, release, customer, dataset, మరియు code path పరస్పరం అనుసంధానంగా ఉన్నాయి?
• అనుమతులు: ఈ పనికి ఏ మూలాలను ఉపయోగించవచ్చు, మరియు ఈ వ్యక్తికి ఏవి చూపించవచ్చు?

సందర్భం అనేది టోకెన్ల గుట్ట కాదు. అది కాలం, అధికారిత్వం, మరియు సరిహద్దులతో కూడిన ఒక గ్రాఫ్.

మరింత సందర్భం మరింత సాక్ష్యాన్ని ఇవ్వాలి; సాక్ష్యం లేకుండా మరింత నమ్మకాన్ని కాదు.

అసలు పని యూనిట్ మార్పే

ఎడిటర్లు మరియు కోడింగ్ టూల్స్ ఫైళ్ల చుట్టూ వ్యవస్థీకరించబడ్డాయి, ఎందుకంటే మనం మార్చేది ఫైళ్లనే. ఇంజినీరింగ్ బృందాలు మార్పుల చుట్టూ వ్యవస్థీకరించబడతాయి.

ఒక మార్పు ఒక కారణంతో ప్రారంభమవుతుంది. అది ఒక అవసరంగా మారుతుంది, కోడ్ మరియు డేటాను తాకుతుంది, సమీక్షను దాటుతుంది, ప్రొడక్షన్‌కు చేరుతుంది, మరియు కొత్త సాక్ష్యాన్ని సృష్టిస్తుంది. ఆ దశలు పరస్పరం అనుసంధానం లేకుండా మిగిలితే, ప్రతి భవిష్యత్ పని మరోసారి పురావస్తు తవ్వకాలతోనే ప్రారంభమవుతుంది.

నిజమైన సాఫ్ట్‌వేర్‌పై పనిచేసే ఒక AI వ్యవస్థ ఆ జీవచక్రాన్ని అనుసరించాలి.

అమలు చేయడానికి ముందు, అది అభ్యర్థనను, సంబంధిత పరిమితులను, మరియు ఏవైనా పరస్పర విరుద్ధ మూలాలను గుర్తించాలి. అది ఒక లోపాన్ని సరిచేస్తోందా, ఆశించిన ప్రవర్తనను మార్చుతోందా, లేదా కొత్త ఒప్పందాన్ని ప్రవేశపెడుతోందా అన్నది దానికి తెలిసి ఉండాలి.

అమలు జరుగుతున్నప్పుడు, ప్రతి అర్థవంతమైన ఎంపికను సాక్ష్యంతో అనుసంధానించాలి. ఎందుకు ఈ మాడ్యూల్? ఎందుకు ఈ మైగ్రేషన్ వ్యూహం? ఎందుకు ఈ బ్రాంచ్‌ను అలాగే ఉంచాలి? కోడ్‌ను ఉత్పత్తి చేసిన చాట్ ముగిసిన తర్వాత కూడా ఆ వివరణ నిలిచి ఉండాలి.

అమలు చేసిన తర్వాత, అది ధృవీకరణ ఫలితాలు, సమీక్ష నిర్ణయాలు, అలాగే కొత్తగా గుర్తించిన పరిమితులను ఆ మార్పుకు జత చేయాలి. లేకపోతే తదుపరి వ్యక్తి—లేదా తదుపరి AI సెషన్—వాటిని మళ్లీ కనుగొనాల్సి వస్తుంది.

ఇదే, repositoryని సవరించగల ఒక సాధనం మరియు ఇంజినీరింగ్ పనిలో భాగస్వామ్యం చేయగల ఒక వ్యవస్థ మధ్య ఉన్న తేడా.

AI తీర్పును తొలగించకూడదు, పునర్నిర్మాణాన్ని తగ్గించాలి

మెరుగైన context‌ను కొన్నిసార్లు స్వయంచాలక software development‌కు దారిగా చూపిస్తారు. కానీ దాని తక్షణ విలువ అంత నాటకీయంగా ఉండదు; మరింత ఉపయోగకరంగా ఉంటుంది: మార్పు చేసే ముందు వాస్తవ పరిస్థితిని మళ్లీ నిర్మించాల్సిన ఖర్చును తగ్గించడం.

AI అసలు requirement‌ను సంబంధిత code పక్కనే తీసుకురాగలదు. అసాధారణ safeguard‌ను వివరించే incident‌ను వెలికి తీయగలదు. విఫలమవుతున్న metric‌ను దాన్ని మార్చిన release‌తో అనుసంధానించగలదు. అమలు ప్రారంభమయ్యే ముందే రెండు authoritative sources పరస్పరం విభేదిస్తున్నాయని చూపగలదు.

ఆ సామర్థ్యాలు ఇంజినీరింగ్ తీర్పును తొలగించవు. అవి తీర్పు మరింత సమాచారం ఆధారంగా ఉండేలా చేస్తాయి.

ఏ 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 ఇంకా అత్యవసరంగానే ఉంటుంది. అది వ్యవస్థ ప్రవర్తనకు అమలు చేయగల source of truth. కానీ product intent, operational reality, లేదా organizational memory కోసం అది సంపూర్ణ source of truth మాత్రం కాదు.

పూర్తి కథనం ఏమి నిర్మించబడుతుందో మార్చేస్తుంది

కేవలం code మాత్రమే ఉంటే, సహజమైన ప్రశ్న ఇది:

ఈ వ్యవస్థకు సరిపోయే మార్పు ఏది?

విస్తృతమైన context‌తో, ప్రశ్న ఇలా మారుతుంది:

ఈ వ్యవస్థకు, ఈ requirement‌కు, ఈ చరిత్రకు, మరియు ఈ క్షణానికి సరిపోయే మార్పు ఏది?

ఆ రెండో ప్రశ్న పరిమితులు రిగ్రెషన్‌లుగా మారేలోపే వాటిని పట్టుకుంటుంది. అది అమలు వెనుక ఉన్న తర్కాన్ని సమీక్షకులకు అందిస్తుంది. సిస్టమ్ ఎందుకు ఇలా ఉందో కొత్త టీమ్ సభ్యులు అర్థం చేసుకోవడానికి అది సహాయపడుతుంది. ఇది AIకి ఒక స్థిరమైన పాత్రను ఇస్తుంది: ఎడిటర్‌లోని ఓరాకిల్‌గా కాదు, పనంతటా ఆధారాలను సమీకరించగల భాగస్వామిగా.

మీ రిపో ఎప్పుడూ మొత్తం కథను చెప్పలేదు.

అవకాశం ఏమిటంటే, మిగతా భాగాన్నీ చదవగలిగే—మరియు తమ పని ఎలా చేశాయో చూపగలిగే—వ్యవస్థలను నిర్మించడం.