కోడింగ్ ఏజెంట్లను (coding agents) అంచనా వేసే ఇంజనీరింగ్ బృందాలు సాధారణంగా తప్పుడు ప్రశ్నతో ప్రారంభిస్తాయి. ఆ ఏజెంట్ ఎంత స్వయంప్రతిపత్తిని (autonomy) కలిగి ఉండగలదో వారు తెలుసుకోవాలని అనుకుంటారు. అది పైప్‌లైన్‌లో ఎంత వరకు బాధ్యత వహించగలదు? ఎవరినీ ఇబ్బంది పెట్టకుండా అది స్పెసిఫికేషన్‌ను (spec) వ్రాయగలదా, రిపోజిటరీని (repository) ఎడిట్ చేయగలదా మరియు ప్రొడక్షన్‌కు పుష్ చేయగలదా? డెమోలు ఈ వ్యామోహాన్ని పెంచుతాయి. ఒకే ప్రాంప్ట్ (prompt) ద్వారా వరుస ఎడిట్‌లు మరియు డిప్లాయ్‌మెంట్‌లు జరిగే అద్భుతమైన వర్క్‌ఫ్లోను మీరు చూసినప్పుడు, మీ సంస్థలో కూడా అదే సామర్థ్యాన్ని సాధించాలని మీ సహజ ప్రేరణ మారుతుంది. కానీ ఆకర్షణ అనేది ఒక చెత్త డిజైన్ సూత్రం. మెరుగైన ప్రశ్నలు అంత ఉత్సాహంగా ఉండవు: దీనికి అధికారం ఎవరు ఇచ్చారు, ఇది నిజంగా ఏ వ్యవస్థలను తాకగలదు, మరియు ఇది తప్పనిసరిగా ఏదైనా తప్పు చేసినప్పుడు ఏమవుతుంది?

స్వయంప్రతిపత్తి ఉచ్చు (The Autonomy Trap)

ఉత్సాహపరిచే స్వయంప్రతిపత్తి ఒక ఉచ్చు. స్పెసిఫికేషన్‌లను రూపొందించే, రిపోజిటరీలను సవరించే మరియు కోడ్‌ను డిప్లాయ్ చేసే బాట్‌లను, పని పూర్తయిందని ప్రశాంతంగా చెబుతున్నప్పుడు మనం వేడుకలు చేసుకోవాలని ఇది మనల్ని అలవాటు చేస్తుంది. అది ఇంజనీరింగ్ కాదు. అది షెల్ యాక్సెస్ (shell access) తో కూడిన నమ్మకంతో కూడిన ప్రమాదం. పనిని చేయడం చాలా సులభం అయిపోతుంది. ఏ మోడల్ అయినా సెకన్లలో కోడ్, డాక్యుమెంటేషన్ లేదా ఆర్కిటెక్చర్ ప్లాన్‌లను సిద్ధం చేయగలదు. కానీ సాఫ్ట్‌వేర్ డెవలప్‌మెంట్‌లో అసలైన ఖర్చు టైపింగ్ వేగం కాదు. అది ఎప్పుడూ వాలిడేషన్ (validation), రివ్యూ (review), మరియు "అవును, ఇది సరైనది మరియు షిప్ చేయడానికి సురక్షితం" అని చెప్పే జాగ్రత్తతో కూడిన నిర్ణయమే. జనరేట్ చేయబడిన పని చౌకైనది. ఆమోదం (Approval) ఖరీదైనది. ఆమోదాన్ని స్పష్టంగా మరియు స్థిరంగా ఎలా నిర్వహించాలో తెలుసుకునే కంపెనీలే నిజమైన నమ్మకమైన వ్యవస్థలను రూపొందిస్తాయి.

సెల్ఫ్-రివ్యూ (Self-Review) ఎందుకు విఫలమవుతుంది

ప్రమాదాలు ఊహించదగిన పద్ధతుల్లో కనిపిస్తాయి. ఒక మోడల్ ప్లాన్‌ను రూపొందిస్తుంది మరియు ఆ ప్లాన్ ఎంతవరకు బాగుందో స్వయంగా అంచనా వేస్తుంది. ఒక ఏజెంట్ మీ కోడ్‌బేస్‌ను ఎడిట్ చేసి, దాని మార్పులు ఎందుకు సురక్షితమో మీకు వివరిస్తుంది. ఒక టూల్ అనుమతి కోరడానికి బదులుగా కమాండ్‌ను అమలు చేసి, తప్పు జరిగితే క్షమించమని అడుగుతుంది. ఇవన్నీ ఒకే ప్రధాన వైఫల్యానికి సంకేతాలు. ఒక ఏజెంట్ స్పెసిఫికేషన్‌ను రూపొందిస్తే, అది నిజం కావడానికి ముందు ఆ ఏజెంట్ వెలుపల ఉన్న ఎవరో ఒకరు దానిని ఆమోదించాలి. ఒక ఏజెంట్ కోడ్‌ను సవరిస్తే, ఒక ప్రత్యేక ప్రక్రియ ఆ మార్పులను (diff) తనిఖీ చేయాలి. జనరేటర్ తనను తాను వాలిడేటర్‌గా వ్యవహరించనివ్వడం అనేది షార్ట్‌కట్ కాదు. అది సౌకర్యం పేరుతో ముసుగు వేసుకున్న ఒక స్ట్రక్చరల్ బగ్ (structural bug).

ప్రాంప్ట్‌లు (Prompts) అనుమతి వ్యవస్థలు కావు

తెలివైన పదజాలంతో మీరు ఏజెంట్‌ను సురక్షితం చేయలేరు. మోడల్‌కు జాగ్రత్తగా ఉండమని లేదా ఏదైనా తొలగించే ముందు అడగమని చెప్పడం వల్ల సరిహద్దులు ఏర్పడవు. ప్రాంప్ట్‌లు అనుమతి వ్యవస్థలు కావు. ఏజెంట్‌ను ప్రొడక్షన్‌కు దగ్గరగా అనుమతించే ముందు, దాని సామర్థ్యాల గురించి మీకు స్పష్టమైన అవగాహన ఉండాలి. అది మొత్తం రిపోజిటరీని చదవగలదా? షెల్ కమాండ్‌లను (shell commands) అమలు చేయగలదా? బ్రౌజర్‌ను తెరవగలదా? కస్టమర్ డేటాను దాని కాంటెక్స్ట్ విండోలోకి (context window) తీసుకోవచ్చా? చాలా బృందాలకు పూర్తి సమాధానాలు తెలియవు. ఆ టూల్ కేవలం శాండ్‌బాక్స్ (sandbox) లోనే పరిమితమైందని వారు అనుకుంటారు, కానీ వాస్తవానికి దానికి కీలకమైన మార్గాలకు (critical paths) రైట్ యాక్సెస్ (write access) ఉంటుంది. మొదట దాని ప్రభావిత ప్రాంతాన్ని (surface area) గుర్తించండి. ఆ తర్వాత రక్షణ గోడలను నిర్మించండి.

స్థాయిల వారీగా నియంత్రణ వ్యవస్థను నిర్మించండి (Build a Tiered Control System)

ఏజెంట్ ఏమి చేయగలదో మీరు అర్థం చేసుకున్న తర్వాత, రిస్క్‌కు అనుగుణంగా నియంత్రణ వ్యవస్థను రూపొందించండి. అంతర్గత డాక్యుమెంటేషన్‌ను అప్‌డేట్ చేయడం లేదా కోడ్‌ను ఫార్మాట్ చేయడం వంటి తక్కువ రిస్క్ ఉన్న పనులను ఆటోమేటిక్‌గా చేయవచ్చు. ఒక మాడ్యూల్‌ను రీఫ్యాక్టరింగ్ (refactoring) చేయడం లేదా కొత్త డిపెండెన్సీని (dependency) జోడించడం వంటి మధ్యస్థ రిస్క్ ఉన్న పనుల కోసం, ఒక మనిషి లేదా ధృవీకరించబడిన టెస్ట్ సూట్ (test suite) ఆ నిర్ణయాన్ని ధృవీకరించేలా ఒక చెక్‌పాయింట్‌ను ఏర్పాటు చేయాలి. ప్రొడక్షన్‌కు డిప్లాయ్ చేయడం, ఇన్‌ఫ్రాస్ట్రక్చర్‌ను మార్చడం లేదా సున్నితమైన డేటాను యాక్సెస్ చేయడం వంటి అధిక రిస్క్ ఉన్న పనుల కోసం, ఆ పనిని రూపొందించడంలో పాల్గొనని వేరొక ఆమోదకర్త అవసరం. ప్రతి చర్య కూడా ఒక ఆడిట్ ట్రైల్‌ను (audit trail) వదిలి వెళ్లాలి. ఏ ఫైల్‌లు చదవబడ్డాయి, ఏ టూల్స్ ఉపయోగించబడ్డాయి మరియు ఏ నిర్ణయాలు తీసుకోబడ్డాయి అనేవి మీరు ఖచ్చితంగా తెలుసుకోగలిగేలా ఉండాలి. ఏజెంటిక్ డెవలప్‌మెంట్ (Agentic development) అంటే రివ్యూలను వదిలివేయడానికి అనుమతి కాదు. విసుగు పుట్టించే నియంత్రణ (friction) అనేది ఒక ఫీచర్. పరిస్థితులు తప్పుదారి పడుతున్నప్పుడు, సరైన ఆమోద గేట్ (approval gate) ఒక సర్క్యూట్ బ్రేకర్ (circuit breaker) లాగా పనిచేస్తుంది.

సరిహద్దులను రిస్క్‌కు అనుగుణంగా ఉంచండి

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

ఆర్టిఫాక్ట్‌లను (Artifacts) చిన్నవిగా మరియు గమనించదగినవిగా ఉంచండి

అత్యంత ఉపయోగకరమైన ఏజెంట్ సిస్టమ్స్ భారీ స్వయంప్రతిపత్తి (autonomous) రన్‌లతో మిమ్మల్ని ఆశ్చర్యపరచడానికి ప్రయత్నించవు. అవి చిన్నవి మరియు సమీక్షించదగిన (reviewable) ఆర్టిఫాక్ట్‌లను ఉత్పత్తి చేస్తాయి. ఒక ఖచ్చితమైన ప్రణాళిక. ఒక ఫోకస్డ్ డిఫ్ (diff). ఒక చదవగలిగే లాగ్ (log). భారీ స్వయంప్రతిపత్తి కార్యకలాపాలను డీబగ్ చేయడం ఒక పీడకల వంటిది. యాజెంట్ యాభై ఫైళ్ల సెషన్ తర్వాత ఏదైనా విఫలమైనప్పుడు, మీరు ఉద్దేశ్యం (intent), అమలు (execution) మరియు సైడ్ ఎఫెక్ట్స్ (side effects) అన్నింటినీ ఒకేసారి విడదీయాల్సి ఉంటుంది. ప్రభావితమయ్యే పరిధిని (blast radius) తక్కువగా ఉంచండి. ఏజెంట్ ఏ ఫైళ్లను చదివింది మరియు ఏ టూల్స్‌ను ఉపయోగించిందో తెలుసుకోవాలని పట్టుబట్టండి. గమనించదగిన (Observable) సిస్టమ్స్ సులభంగా నిర్వహించదగిన (maintainable) సిస్టమ్స్. బ్లాక్-బాక్స్ స్వయంప్రతిపత్తి అనేది కేవలం మెరుగైన మార్కెటింగ్‌తో కూడిన టెక్నికల్ డెట్ (technical debt) మాత్రమే.

యాక్సెస్ ఇచ్చే ముందు అడగవలసిన ఆరు ప్రశ్నలు

మీరు ఏజెంట్‌కు ఏదైనా నిజమైన బాధ్యతను అప్పగించే ముందు, ఈ ఆరు కఠినమైన ప్రశ్నలతో మీ సెటప్‌ను పరీక్షించండి.

  • సిస్టమ్‌కు వాస్తవంగా ఏ సామర్థ్యాలు ఉన్నాయి?
  • ఏ చర్యలు డిఫాల్ట్‌గా నిరాకరించబడ్డాయి, అంటే సిస్టమ్ ప్రాంప్ట్‌లో మర్యాదపూర్వక వాక్యం ద్వారా నిరోధించబడకుండా, ఇన్‌ఫ్రాస్ట్రక్చర్ స్థాయిలో బ్లాక్ చేయబడ్డాయా?
  • ఏ చర్యలకు స్పష్టమైన ఆమోదం (explicit approval) అవసరం?
  • ఏజెంట్ వాటిని ఉపయోగించే ముందు ఏ ఆర్టిఫాక్ట్‌లను ఫ్రీజ్ చేస్తారు, తద్వారా అది తన స్వంత ఇన్‌పుట్‌లను రహస్యంగా మార్చలేకపోతుంది?
  • జనరేటర్ నుండి పూర్తిగా వేరుగా ఉన్న ఏ వ్యాలిడేటర్ (validator) తుది అవుట్‌పుట్‌ను నిర్ణయిస్తుంది?
  • వాస్తవానికి ఏమి జరిగిందో ఏ లాగ్ ఎటువంటి సందేహం లేకుండా నిరూపిస్తుంది?

ఇది ప్రాథమిక ఇంజనీరింగ్ పరిశుభ్రత (hygiene). జనరేటర్‌ను వ్యాలిడేటర్ నుండి వేరు చేయండి. మానవ అధికారాన్ని (human authority) సరిహద్దులో ఉంచండి.

అసలైన పరీక్ష

అక్కడ