ప్రతి AI కోడింగ్ ఏజెంట్ ఒక diffను అందించగలదు. అసలు సమస్య ఏమిటంటే, ఆ diff ఒక ఏకాగ్రతతో కూడిన, ఉద్దేశపూర్వక ప్రక్రియ ద్వారా వచ్చిందా—లేదా మీ రిపోజిటరీ అంతటా గందరగోళంగా వెతికి, అనుకోకుండా సరైన ఫలితాన్ని సాధించిందా అనేది తెలుసుకోవడం. ప్రస్తుతం, చాలా బృందాలు ఈ రెండింటి మధ్య తేడాను గుర్తించలేకపోతున్నాయి.
ఇది సాంకేతిక పరిమితి కాదు. ఇది ఒక విజిబిలిటీ (visibility) సమస్య.
ఒక ఏజెంట్ మూడు లైన్ల ప్రొడక్షన్ కోడ్ను రాసినప్పుడు, అది మూడు ఫైళ్లను చదివి, టెస్ట్లను రన్ చేసి ఉండవచ్చు. లేదా అది సంబంధం లేని నలభై ఫైళ్లను తాకి, డజన్ల కొద్దీ విఫలమైన కమాండ్లను అమలు చేసి, డిపెండెన్సీ ఇన్స్టాల్ విఫలమైనందున మీ టెస్ట్ సూట్ను స్కిప్ చేసి, ఆ ప్రాసెస్కు మీకు ఛార్జ్ చేసి ఉండవచ్చు. ఏ సందర్భంలోనైనా diff ఒకేలా కనిపిస్తుంది. ఆ ప్రయాణానికి సంబంధించిన రికార్డు లేకపోతే, ఫలితం యొక్క నాణ్యత గురించి మీరు ఊహించడమే తప్ప వేరే మార్గం ఉండదు.
చాట్ లాగ్లు (Chat Logs) ఎందుకు రసీదులు (Receipts) కావు
అనేక సాధనాలు పనికి నిరూపణగా చాట్ ట్రాన్స్క్రిప్ట్ను అందిస్తాయి. ట్రాన్స్క్రిప్ట్ అనేది రసీదు కాదు. అది మీ డెస్క్పై పడేసిన విడిభాగాల పెట్టె వంటిది. అందులో ప్రతి ఆలోచనా చక్రం (thought loop), ప్రతి విఫల ప్రయత్నం, ప్రతి సిస్టమ్ ప్రాంప్ట్ మరియు ప్రతి అనవసరమైన టూల్ కాల్ ఉంటాయి. మూడు లైన్ల ప్యాచ్ను ధృవీకరించడానికి మీరు వెయ్యి లైన్ల సంభాషణను చదవాల్సి వస్తే, మీ రివ్యూ వర్క్ఫ్లో ఇప్పటికే దెబ్బతిన్నట్లే.
మానవ ఏకాగ్రత పరిమితమైనది. ఏజెంట్ యొక్క ఉద్దేశ్యం మానసిక శ్రమను తగ్గించడం, హోంవర్క్ ఇవ్వడం కాదు. ట్రాన్స్క్రిప్ట్ రివ్యూవర్ను ఒక డిటెక్టివ్గా మారమని కోరుతుంది. రసీదు మాత్రం ఒక చూపులోనే సమాధానాన్ని అందిస్తుంది.
ఉపయోగకరమైన రసీదు అనేది ఒక ఆచరణాత్మక సారాంశం (practical summary). ఏజెంట్ను ఏమి చేయమని అడిగారు, అది వాస్తవానికి ఏమి చేసింది మరియు అది ఎలా తన ముగింపుకు చేరుకుంది అనే విషయాలను అది మీకు చెబుతుంది. అది వైఫల్యాన్ని దాచదు, దానిని స్పష్టంగా చూపుతుంది.
ఒక మంచి రసీదు ఎలా ఉండాలి
రివ్యూ చేయదగిన రసీదు లోతుగా వెతకకుండానే ఈ క్రింది నిర్దిష్ట ప్రశ్నలకు సమాధానం ఇవ్వాలి:
- టాస్క్ ఏమిటి? ఉద్దేశించిన మార్పు యొక్క స్పష్టమైన వివరణ ఉండాలి, కేవలం ప్రాంప్ట్ను తిరిగి చెప్పడం కాకూడదు.
- ఏ ఫైళ్లను చదివారు? ఏజెంట్ సరైన మూలాల నుండి సందర్భాన్ని (context) సేకరించిందో మీరు అంచనా వేయడానికి ఇది ఉపయోగపడుతుంది.
- ఏ ఫైళ్లను ఎడిట్ చేశారు? మార్పు యొక్క తుది ముద్ర (footprint).
- ఏ కమాండ్లను రన్ చేశారు? ఏజెంట్ అమలు చేసిన బిల్డ్ స్టెప్స్, లీంటర్లు (linters), ఫార్మాటర్లు లేదా కస్టమ్ స్క్రిప్ట్లు.
- ఏ కమాండ్లు విఫలమయ్యాయి? కేవలం విజయవంతమైనవి మాత్రమే కాదు. వైఫల్యాలు ఏజెంట్ ఎక్కడ సర్దుబాటు చేసుకోవాల్సి వచ్చిందో లేదా ఎక్కడ ప్రయత్నాన్ని వదిలేసిందో తెలియజేస్తాయి.
- ఏ టెస్ట్లు పాస్ అయ్యాయి లేదా స్కిప్ చేయబడ్డాయి? స్కిప్ చేయబడిన టెస్ట్లు ఒక హెచ్చరిక (red flag). అవి ఎందుకు స్కిప్ చేయబడ్డాయో రసీదులో ఉండాలి.
- మొత్తం ఖర్చు ఎంత? టోకెన్లు, API కాల్స్ మరియు కంప్యూట్ సమయం. ఇందులో కేవలం మోడల్ ధర మాత్రమే కాకుండా, మీ ఆర్కిటెక్చర్ ఖర్చు కూడా ఉండాలి.
ఈ ఫార్మాట్ రివ్యూను ఒక పురావస్తు తవ్వకంలా కాకుండా, ఒక వేగవంతమైన శానిటీ చెక్ (sanity check) లా మారుస్తుంది. ఒక సీనియర్ ఇంజనీర్ రసీదును స్కాన్ చేసి, ఒక నిమిషం లోపే "ఇది సరిగ్గా ఉంది" లేదా "ఇది అనుమానాస్పదంగా ఉంది" అని చెప్పగలిగేలా ఉండాలి.
కేవలం చరిత్రను మాత్రమే కాదు, ఫుట్ప్రింట్ను (Footprint) కూడా చదవండి
ఏజెంట్ రన్ యొక్క ఫుట్ప్రింట్ పని యొక్క రూపాన్ని చూపుతుంది. ఏజెంట్ టికెట్ పరిధిలోనే ఉందా? లేదా సంబంధం లేని మాడ్యూల్స్లోకి వెళ్లి ఎవరూ అడగని మార్పులు చేసిందా? "Files Read" తో పాటు "Files Edited"ను జాబితా చేసే రసీదు దీనిని స్పష్టంగా చూపుతుంది.
ఫుట్ప్రింట్ పునరావృతతను (repetition) కూడా వెల్లడిస్తుంది. ఒకే గమ్యం లేని మార్గంలో తిరుగుతూ—ఒకే కాన్ఫిగరేషన్ ఫైల్ను మూడుసార్లు చదవడం లేదా విఫలమయ్యే టెస్ట్ను పదే పదే రన్ చేయడం వంటివి చేసే ఏజెంట్, కంప్యూట్ మరియు కాంటెక్స్ట్ విండోను వృథా చేస్తోంది. ఆ విధానం స్పష్టంగా కనిపించాలి. ఒక మైగ్రేషన్ స్క్రిప్ట్ను రన్ చేయడానికి ఏజెంట్కు తొమ్మిది ప్రయత్నాలు పడితే, రసీదులో అది తెలియజేయాలి. ఆ సమాచారం మీరు అవుట్పుట్ను ఎలా అంచనా వేస్తారో మారుస్తుంది. గందరగోళంగా, బలవంతంగా (brute-force) సృష్టించబడిన "సరైన" diff, పద్ధతిగా సృష్టించబడిన సరైన diffతో సమానం కాదు.
చెత్త డిజైన్ వల్ల కలిగే దాగి ఉన్న ఖర్చు
ఖర్చు అంటే కేవలం టోకెన్ ధర మాత్రమే కాదు. సరిగ్గా డిజైన్ చేయని వర్క్ఫ్లో, ఏజెంట్ ఒక్క అక్షరాన్ని సృష్టించకముందే దానిని ఖరీదైనదిగా మారుస్తుంది. అనవసరమైన టూల్ స్కీమాలు, అవసరం లేని ఫైల్ ఇండెక్సింగ్ మరియు అతిగా విస్తరించిన సిస్టమ్ ప్రాంప్ట్లు అన్నీ కాంటెక్స్ట్ విండోను పెంచుతాయి. రసీదు ఈ అదనపు భారాన్ని (overhead) బయటపెట్టాలి.
జనరేషన్ (generation) చౌకగా మారి, రివ్యూ కష్టతరమైతే, మీకు ఏమీ లాభం లేదు. మీరు కేవలం సమస్యను ఒక చోటు నుండి మరో చోటుకు మార్చారు అంతే. ఒక బృందంలో ఇంజనీర్ సమయం అనేది అత్యంత విలువైన వనరు. ప్రతి పుల్ రిక్వెస్ట్ (pull request) కు ముప్పై నిమిషాల రివ్యూ సమయాన్ని పెంచుతూ, API ఖర్చులో ఐదు డాలర్లు ఆదా చేయడం అనేది చాలా చెడ్డ లావాదేవీ. ఈ లావాదేవీని నేరుగా ఆడిట్ చేయడానికి రసీదు మీకు సహాయపడుతుంది.
నిజాయితీ అనేది ఒక ఫీచర్
ఉపయోగకరమైన రసీదు అవసరమైనప్పుడు అసౌకర్యంగా ఉండాలి. ఏజెంట్ అసమర్థంగా ఉన్నట్లు కనిపించే వాస్తవాలను అది నివేదించాలి, ఎందుకంటే ఆ నిజాయితీ తదుపరి మానవ నిర్ణయాన్ని వేగంగా మరియు మెరుగ్గా చేస్తుంది.
ఉదాహరణలు ముఖ్యం:
- "ఒక లైన్ మార్పు కోసం 37 ఫైళ్లను చదివింది."
- "
npm installపీర్ డిపెండెన్సీ కాన్ఫ్లిక్ట్ (peer dependency conflict) కారణంగా విఫలమవడంతో టెస్ట్లను స్కిప్ చేసింది." - "ఏజెంట్ పరిచయం చేసిన ఒక ఇంపోర్ట్ను సరిచేయడానికి, కోరిన పరిధి (scope) వెలుపల
utils.pyని ఎడిట్ చేసింది." - "లించర్ను (linter) 4 సార్లు రన్ చేసింది; మొదటి మూడు పాత్ మిస్ కాన్ఫిగరేషన్ (path misconfiguration) కారణంగా విఫలమయ్యాయి."
ఇవి రసీదులోని (receipt) బగ్స్ కావు. ఇవి సంకేతాలు. రివ్యూయర్ ఎక్కడ అనుమానించాలో ఇవి చెబుతాయి. వర్క్ఫ్లోను ఎక్కడ కఠినతరం చేయాలో ఇవి ప్లాట్ఫారమ్ టీమ్కు తెలియజేస్తాయి.
చిన్న రన్లు, స్పష్టమైన పర్యవేక్షణ
ఏజెంట్లను పెద్ద విస్తృతిలో (large surfaces) స్వేచ్ఛగా వదిలేయాలనే సహజమైన కోరిక ఉంటుంది. ఒకే పెద్ద ప్రాంప్ట్తో మొత్తం సర్వీస్ను రీఫ్యాక్టర్ (refactor) చేయడం వేగంగా అనిపించవచ్చు. కానీ అది కాదు. అది రివ్యూ చేయలేనంత పెద్ద పనిని సృష్టిస్తుంది. మార్చబడిన ఎనభై ఫైళ్లలో ఏవి ఉద్దేశపూర్వకంగా చేయబడ్డాయో తెలుసుకోవడానికే మీ సాయంత్రం అంతా అయిపోతుంది.
చిన్నవి, తనిఖీ చేయగలిగే రన్లు మెరుగైనవి. టాస్క్ కోసం స్పష్టమైన సరిహద్దులను నిర్వచించండి. ఏజెంట్ చదవగలిగే ఫైళ్ల జాబితాను, అది వ్రాయగలిగే ఫైళ్ల జాబితా నుండి వేరు చేయండి. విఫలమైన కమాండ్ల చరిత్రను (history) నమోదు చేయండి, తద్వారా ఎక్కడ ఆగిపోయాయో స్పష్టంగా తెలుస్తుంది. స్కిప్ చేసిన వెరిఫికేషన్లను స్పష్టంగా గుర్తించండి. సెర్చ్ APIల నుండి టెస్ట్ రన్నర్ల వరకు ప్రతి బాహ్య సాధనం (external tool) వినియోగాన్ని నోట్ చేయండి.
లక్ష్యం సంపూర్ణ స్వయంప్రతిపత్తి (total autonomy) కాదు. మనుషులు ధృవీకరించలేనంత సంపూర్ణ స్వయంప్రతిపత్తి అనేది కేవలం బాధ్యతతో కూడిన ఆటోమేషన్ మాత్రమే. అసలు లక్ష్యం రివ్యూ చేయదగిన సామర్థ్యం (reviewability). ప్రతి ఏజెంట్ అవుట్పుట్ను సులభంగా ఆమోదించడానికి లేదా తిరస్కరించడానికి వీలుగా ఉండాలి. విచారణ చేయడానికి అలసిపోయినందున మీరు కోడ్ను అంగీకరించేలా ఎటువంటి అస్పష్టమైన మధ్యస్థ స్థితి ఉండకూడదు.
ఏ కోడింగ్ ఏజెంట్కైనా పరీక్ష
ఏదైనా ఏజెంట్ లేదా ప్లాట్ఫారమ్ను స్వీకరించే ముందు, ఒక ప్రశ్న అడగండి: మనిషి తదుపరి దశను నమ్మకంగా ఆమోదించడానికి తగినంత ఆధారాలను అది వదిలిపెడుతుందా?
సమాధానం 'అవును' అయితే, ఆ సాధనం ప్రొఫెషనల్ వర్క్ఫ్లోకు సరిపోతుంది. సమాధానం 'కాదు' అయితే, మీరు ఉత్పాదకతను (productivity) కొనడం లేదు. అప్పుడప్పుడు కంపైల్ అయ్యే ఒక రహస్యాన్ని కొంటున్నారు. ఇది వీకెండ్ సైడ్ ప్రాజెక్ట్కు పర్వాలేదు, కానీ ప్రొడక్షన్ ఇంజనీరింగ్కు అంగీకరించలేము.
ఏజెంట్ అవుట్పుట్లను పరీక్షించకుండా బహుమతులుగా భావించే టీమ్లు, చివరకు గుర్తించబడని స్కోప్ క్రీప్ (scope creep) వల్ల కలిగే సూక్ష్మమైన బగ్లను విడుదల చేస్తాయి. ఆ డిఫ్ (diff) అమాయకంగా కనిపిస్తుంది. కానీ రసీదు (receipt) నిజం చెప్పేది.
రసీదులను (receipts) తప్పనిసరి చేయండి. రివ్యూ కోసం డిజైన్ చేయండి. నమ్మకం అనేది వ్యూహం కాదు. ఆధారాలే వ్యూహం.
AI టూలింగ్ మరియు డెవలపర్ వర్క్ఫ్లోల గురించి మరింత ప్రత్యక్ష చర్చల కోసం, మీరు GyaanSetu on Telegram లో కమ్యూనిటీలో చేరవచ్చు.