నా ఏజెంట్ ఒకే సాయంత్రం రోజులో 3 PRలను పంపింది. నా సందేశాలలో 40% సవరణలే.
నా AI-ఆధారిత కోడింగ్ ఏజెంట్ ఒకే సాయంత్రం రోజులో మూడు pull requestsలను పంపింది, కానీ నేను పంపిన 30 సందేశాలలో 40% సవరణలే.
ఆ సెషన్లో ఒక MCP client, ఒక Azure AI Agent, మరియు ఒక M365 Copilot Agent రూపొందించబడ్డాయి. ఆటోమేటెడ్ చెక్స్ ద్వారా మూడు PRలు క్లియర్ అయ్యాయి, నేను ఒక్క లైన్ కోడ్ కూడా ఎడిట్ చేయలేదు. అయినప్పటికీ, ట్రాన్స్క్రిప్ట్ వేరే కథ చెబుతోంది: మొత్తం 710 సందేశాలలో, నేను 30 సందేశాలు టైప్ చేశాను, వాటిలో 12 సందేశాలు ఏజెంట్ను సరైన మార్గంలోకి మళ్లించాయి. "steering rate" – అంటే నా సందేశాలలో సవరణల వాటా – 40% వద్ద ఉంది.
పైప్లైన్ ఎలా రూపొందించబడింది
- Claude ఒక హై-లెవల్ ఇంప్లిమెంటేషన్ ప్లాన్ను సిద్ధం చేసింది.
- DeepSeek V4-Flash ఆర్కెస్ట్రేటర్గా వ్యవహరిస్తూ, ఆ ప్లాన్ను సమీక్షించింది.
- Codex అసలు కోడ్ను రూపొందించింది.
- ఆర్కెస్ట్రేటర్ కోడ్ను తనిఖీ చేసి, pull requestsలను ఓపెన్ చేసింది.
ఆర్కెస్ట్రేటర్ యొక్క ఉద్దేశిత పాత్ర కేవలం అనుసంధానకర్తగా మాత్రమే – అది భాగాల మధ్య వైరుధ్యాలను (conflicts) పరిష్కరించాలి తప్ప, స్వయంగా కోడ్ రాయకూడదు. వాస్తవానికి, ఏజెంట్ సుమారు 40 నిమిషాల్లో మూడు PRల ద్వారా 3,500 లైన్ల కోడ్ను రూపొందించింది, కానీ రెండు రకాల పునరావృత లోపాలను (error classes) కూడా చేసింది.
రెండు రకాల లోపాలు
- Workflow violations – ఆర్కెస్ట్రేటర్ అప్పుడప్పుడు తన "glue" పాత్రను విస్మరించి, కోడింగ్ దశను తన చేతుల్లోకి తీసుకుని, ఇంప్లిమెంటేషన్ వివరాలను స్వయంగా రాసింది.
- Context-retrieval failures – స్పష్టమైన సూచనలు ఉన్నప్పటికీ, ఏజెంట్ తప్పు SDK లేదా వెర్షన్ను ఎంచుకుంది. సరైన సమాచారం ప్రాంప్ట్ కాంటెక్స్ట్లో ఉన్నప్పటికీ, మోడల్ దానిని సరైన సమయంలో బయటకు తీసుకురావడంలో విఫలమైంది.
ఇవి ఆలోచనా సామర్థ్యంలో లోపాలు కావు; వర్క్ఫ్లోను ఎలా నియంత్రించాలో తెలియక వచ్చిన ఇంజనీరింగ్ బగ్స్. మరింత సామర్థ్యం ఉన్న లాంగ్వేజ్ మోడల్ కూడా, ఆర్కెస్ట్రేటర్ను కోడింగ్ కాని పనులకే పరిమితం చేస్తూ మరియు సరైన SDK ఎంపికను నిర్ధారిస్తూ ఒక కఠినమైన, తప్పనిసరి నియమాన్ని కలిగి ఉండాలి.
ఏజెంట్ను నియంత్రించడానికి నేను చేసిన మార్పులు
సిస్టమ్ తన పాత్రను స్టెప్ లిస్ట్ నుండి అర్థం చేసుకుంటుందని నేను ఊహించడం మానేశాను. నేను ఒక ప్రత్యక్ష ప్రకటనను జోడించాను: “You are an orchestrator. You do not implement.” ఆ సూచనను ఏజెంట్ పాటించేలా చేయడానికి ఐదు సవరణ సందేశాలు పంపాల్సి వచ్చింది, ఆ తర్వాత ఏజెంట్ ఆ పరిమితిని గౌరవించింది.
నేను కాంటెక్స్ట్-రిట్రీవల్ లాజిక్ను కూడా మరింత పటిష్టం చేశాను. తప్పు టూల్ కనిపించినప్పుడు, నేను దానిని హాలూసినేషన్ (hallucination) గా కాకుండా రిట్రీవల్ పైప్లైన్లో ఒక బగ్గా పరిగణించాను, మరియు సరైన వెర్షన్ను తప్పకుండా గుర్తించేలా SDK వివరాలను అందించే ప్రాంప్ట్ను తిరిగి రాశాను.
AI-ఆధారిత డెవలప్మెంట్ కోసం ఆచరణాత్మక అంశాలు
- మీ సందేశాలను లెక్కించండి. ఎక్కువ సంఖ్యలో అంగీకరించబడిన PRలు లోపభూయిష్టమైన ప్రక్రియను కప్పిపుచ్చవచ్చు. మీ సవరణల సంఖ్య, వ్యవస్థ ఎక్కడ లోపిస్తుందో తెలిపే ముందస్తు సూచిక.
- పాత్రను స్పష్టంగా పేర్కొనండి. ఏజెంట్లు కేవలం చెక్లిస్ట్ ద్వారా తమ గుర్తింపును ఊహించుకోలేవు; వారు ఎవరు మరియు ఏమి చేయవచ్చు అనే దాని గురించి వారికి స్పష్టమైన, స్థిరమైన సూచన అవసరం.
- టూల్-చాయిస్ లోపాలను ఇంజనీరింగ్ బగ్స్గా పరిగణించండి. ఏజెంట్ నిర్దేశించిన SDKని విస్మరిస్తే, ఆ తప్పు మోడల్ యొక్క "జ్ఞానం"లో లేదు, కాంటెక్స్ట్-డెలివరీ మెకానిజంలో ఉంది.
- తప్పులను తిరిగి ఉపయోగించదగిన నైపుణ్యాలుగా మార్చండి. ఏజెంట్ తన స్వంత లోపాల నుండి ఒక వాలిడేషన్ రూటీన్ను రూపొందించేలా నేను చేశాను, తద్వారా ఒక వైఫల్యాన్ని భవిష్యత్తు రక్షణ కవచంగా మార్చాను.
