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

మనం Intent-Driven Development వైపు మళ్లుతున్నాము. మీరు లూప్‌లు (loops) మరియు కండిషనల్స్ (conditionals) టైప్ చేయడం ఆపేస్తారు. దానికి బదులుగా, మీకు కావాల్సిన ఫలితాన్ని మీరు వివరిస్తారు. ఒక ఏజెంట్ ఆ లక్ష్యాన్ని గ్రహించి, దశలను ప్లాన్ చేస్తుంది, కోడ్‌ను రాస్తుంది, టెస్ట్‌లను రన్ చేస్తుంది మరియు మీరు ఫలితాన్ని చూడకముందే తన స్వంత లోపాలను సరిచేస్తుంది. కీబోర్డ్ ఇకపై ప్రాథమిక సాధనం కాదు. స్పష్టమైన ఆలోచనే అసలైన సాధనం.

లైన్-బై-లైన్ కోడింగ్ ముగింపు

పాత వర్క్‌ఫ్లోలో, మీ ప్రతి ఉద్దేశ్యాన్ని కంపైలర్‌కు అర్థమయ్యే ఒక నిర్దిష్ట భాషలోకి అనువదించాల్సి వచ్చేది. మీరు బిజినెస్ రిక్వైర్మెంట్‌ను మీ మనస్సులో ఉంచుకుని, దానిని మాన్యువల్‌గా ఫంక్షన్‌లు, ఇంపోర్ట్‌లు, ఎర్రర్ హ్యాండ్లింగ్ మరియు టెస్ట్ కేసులుగా విభజించేవారు. Intent-Driven Development ఆ అనువాద పొరను (translation layer) తొలగిస్తుంది.

ఉదాహరణకు, మీరు ఒక పేమెంట్ వెబ్‌హుక్ (payment webhook) ఇంటిగ్రేట్ చేయాలనుకుంటున్నారనుకోండి. గతంలో, మీరు రూట్ హ్యాండ్లర్‌ను రాసి, పేలోడ్‌ను పార్స్ చేసి, సిగ్నేచర్‌ను వాలిడేట్ చేసి, ట్రాన్సాక్షన్ లోపల డేటాబేస్‌ను అప్‌డేట్ చేసి, రసీదు ఇమెయిల్‌ను క్యూ (queue) చేయాల్సి వచ్చేది. ఇప్పుడు మీరు కేవలం అవసరాన్ని వివరిస్తే చాలు: “వచ్చే Stripe webhookను వాలిడేట్ చేయండి, ఈవెంట్‌ను idempotently రికార్డ్ చేయండి మరియు రసీదు ప్రక్రియను ప్రారంభించండి. డేటాబేస్ రైట్ విఫలమైతే రోల్ బ్యాక్ చేయండి.” ఏజెంట్ హ్యాండ్లర్‌ను రాస్తుంది, పార్సింగ్ స్ట్రాటజీని ఎంచుకుంటుంది, రీట్రై లాజిక్‌ను రూపొందిస్తుంది మరియు టెస్ట్‌లను జనరేట్ చేస్తుంది. మీ పాత్ర రచయిత నుండి దర్శకుడిగా మారుతుంది.

ఏజెంట్ కేవలం కోడ్ జనరేషన్ దగ్గరే ఆగిపోదు కాబట్టే ఇది సాధ్యమవుతుంది. అది ఒక లూప్‌లోకి ప్రవేశిస్తుంది.

ఏజెంట్ లూప్ లోపల

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

ఆ లూప్ విఫలమైనప్పుడు మాత్రమే మీరు జోక్యం చేసుకుంటారు. బహుశా ఏజెంట్ రెండు డిపెండెన్సీల (dependencies) మధ్య ఉన్న సంఘర్షణను పరిష్కరించలేకపోవచ్చు, లేదా యూనిట్ టెస్ట్‌లను పాస్ అయ్యేలా కోడ్‌ను రాస్తూనే, ఉన్నత స్థాయి బిజినెస్ రూల్‌ను ఉల్లంఘించవచ్చు. అటువంటి సరిహద్దుల వద్దే మానవ విచక్షణ (human judgment) అవసరమవుతుంది.

మీ అసలైన పని: Constraint Designer మరియు Edge-Case Hunter

యంత్రమే ఫంక్షన్‌లను రాస్తే, మీకు ఏముంటుంది? రెండు పనులు ఉంటాయి, అవి సింటాక్స్ టైప్ చేయడం కంటే కష్టమైనవి.

మొదటిది, ఏజెంట్‌ను సరైన మార్గంలో ఉంచే కన్‌స్ట్రైంట్‌లను (constraints) మీరు రాస్తారు. ఏజెంట్‌కు విస్తృతమైన జ్ఞానం ఉంటుంది కానీ మీ నిర్దిష్ట ఎన్విరాన్‌మెంట్ (environment) గురించి అవగాహన ఉండదు. మీరు దానికి ఇలా చెప్పాలి: “అంతర్గత billing APIని మాత్రమే ఉపయోగించండి, కార్డ్ టోకెన్‌లను ఎప్పుడూ లాగ్ చేయవద్దు మరియు రెస్పాన్స్ లాటెన్సీని రెండు వందల మిల్లీసెకన్ల కంటే తక్కువగా ఉంచండి.” ఆ సరిహద్దులు కేవలం ప్రాంప్ట్‌లు మాత్రమే కాదు. అవి విజయం లేదా వైఫల్యాన్ని నిర్ణయించే స్పెసిఫికేషన్లు.

రెండవది, ఏజెంట్ విఫలమయ్యే పది శాతం కేసులను మీరు గుర్తించాలి. ఏజెంట్లు సాధారణ మార్గాలను (common paths) బాగా హ్యాండిల్ చేస్తాయి. కానీ సూక్ష్మమైన రేస్ కండిషన్స్ (race conditions), అస్పష్టమైన బిజినెస్ లాజిక్ ఎడ్జ్ కేసులు (edge cases), మరియు వాటి ట్రైనింగ్ డేటాలో ఉన్న సెక్యూరిటీ అంచనాల వద్ద అవి తడబడతాయి. వెబ్‌హుక్ హ్యాండ్లర్ మరియు రీఫండ్ క్రోన్ జాబ్ (cron job) మధ్య జరిగే రేస్‌ను గుర్తించడం లేదా జనరేట్ చేయబడిన రీట్రై లాజిక్ డూప్లికేట్ ఛార్జీలకు దారితీస్తుందని గ్రహించడం వంటి అంశాల్లో మీ నైపుణ్యం కనిపిస్తుంది. యంత్రం సాధారణ సమస్యను పరిష్కరిస్తుంది. మీరు ప్రమాదకరమైన ఎక్సెప్షన్‌ను (exception) పట్టుకుంటారు.

కోడ్ రివ్యూ స్థానంలో వెరిఫికేషన్ హార్నెస్ (Verification Harness)

ఒక ఏజెంట్ రాత్రికి రాత్రే యాభై ఫైళ్లను ఉత్పత్తి చేయగలిగినప్పుడు, అవి "సరైనవిగా ఉన్నాయా" అని కేవలం డిఫ్స్ (diffs) చూసి మీరు రివ్యూ చేయలేరు. ఆ పరిమాణం వల్ల మనుషులు కళ్లతో చూసి సరిచూడటం అసాధ్యం. కోడ్ మీ వద్దకు చేరకముందే లోపాలను పట్టుకునే ఒక హార్నెస్ (harness) మీకు అవసరం.

ఈ హార్నెస్ మూడు స్తంభాలపై ఆధారపడి ఉంటుంది.

Durable execution. ఏజెంట్ టాస్క్‌లు తరచుగా ఒకే రిక్వెస్ట్ టైమ్-అవుట్ కంటే ఎక్కువ సమయం నడుస్తాయి. తాత్కాలిక నెట్‌వర్క్ సమస్య వల్ల ఏదైనా దశ విఫలమైతే, హార్నెస్ స్టేట్‌ను (state) దెబ్బతీయకుండా ఆగిపోయి, మళ్ళీ ప్రయత్నించి, తిరిగి ప్రారంభమవుతుంది. పని మధ్యలో ఆగిపోయినా డేటా సురక్షితంగా ఉంటుంది.

Structured outputs. ఏజెంట్ ఒక చక్కని కాన్ఫిగరేషన్ ఫైల్‌ను తిరిగి ఇస్తుందని ఆశించే బదులు, మీరు ముందే నిబంధనలను (contract) అమలు చేస్తారు. JSON Schema వంటి సాధనాలు అవుట్‌పుట్‌ను వెంటనే వాలిడేట్ చేస్తాయి. ఏజెంట్ ఏదైనా అవసరమైన ఫీల్డ్‌ను వదిలేసినా లేదా తప్పు డేటా టైప్‌ను ఉపయోగించినా, కోడ్ మీ రిపోజిటరీకి చేరకముందే హార్నెస్ దానిని తిరస్కరిస్తుంది.

Dynamic guardrails. సీక్రెట్‌లను (secrets) చదవడానికి లేదా ప్రొడక్షన్ డేటాబేస్‌లలో రాయడానికి ఏజెంట్‌కు పూర్తి స్వేచ్ఛ ఉండకూడదు. హార్నెస్ పర్మిషన్లను డైనమిక్‌గా నియంత్రిస్తుంది, ఏజెంట్‌ను సాండ్‌బాక్స్ (sandboxing) చేయడం ద్వారా అది కేవలం కేటాయించిన టెస్ట్ డేటాబేస్‌లు మరియు అంతర్గత ఎండ్‌పాయింట్‌లను మాత్రమే తాకేలా చేస్తుంది. మీరు ప్రతి లైన్‌ను రివ్యూ చేయడం లేదు. మీరు ఏజెంట్ చుట్టూ ఉన్న రక్షణ కవచాన్ని (fence) ఆడిట్ చేస్తున్నారు.

కోడ్ పనిచేసినా ఉత్పత్తి విఫలమైనప్పుడు

ఇక్కడే ఒక వైరుధ్యం ఉంది. హార్నెస్ (harness) తప్పు కోడ్‌ను పట్టుకోగలదు. కానీ తప్పు ఉద్దేశ్యాన్ని (bad intent) పట్టుకోలేదు.

మీ స్పెసిఫికేషన్ (specification) "ప్రతి కొత్త వినియోగదారునికి స్వాగత ఈమెయిల్ పంపండి" అని చెబితే, ఏజెంట్ ఆ ఈమెయిల్‌ను పంపేలా క్లీన్ మరియు టెస్ట్ చేయబడిన కోడ్‌ను రాస్తుంది. కానీ మీరు "వినియోగదారుడు తన చిరునామాను ధృవీకరించినప్పుడు, మార్కెటింగ్ కోసం ఆప్ట్ అయినప్పుడు మరియు వారి స్థానిక టైమ్‌జోన్‌లో పని వేళల్లో సైన్ అప్ చేసినప్పుడు మాత్రమే స్వాగత ఈమెయిల్ పంపండి" అని అర్థం చేసుకున్నారని దానికి తెలియదు. ఆ కోడ్ సాంకేతికంగా లోపరహితంగా ఉండవచ్చు, కానీ వాణిజ్యపరంగా ప్రమాదకరమైనది.

Intent-Driven Developmentలో అసలైన రిస్క్ ఏమిటంటే అస్పష్టమైన స్పెసిఫికేషన్. అస్పష్టమైన ఉద్దేశ్యం వల్ల, తప్పు సమస్యను అత్యంత చక్కని పద్ధతిలో పరిష్కరించే సాఫ్ట్‌వేర్ తయారవుతుంది. అందుకే మీరు మీ స్పెసిఫికేషన్లను నిజమైన ఆస్తులుగా పరిగణించాలి. వాటికి వెర్షన్లు ఇవ్వండి. స్టేక్‌హోల్డర్లతో (stakeholders) కలిసి వాటిని సమీక్షించండి. ఏజెంట్ బిల్డింగ్ ప్రారంభించకముందే వాటిని అసలు వర్క్‌ఫ్లోలతో సరిచూసుకోండి. చాట్ బాక్స్‌లో రాసిన ఒక ప్రాంప్ట్ (prompt) స్పెసిఫికేషన్ కాదు. అది ఒక రిస్క్ (liability).

ఇంజనీరింగ్ జడ్జిమెంట్ (Engineering Judgment) పైభాగానికి మారుతోంది

ఇంజనీరింగ్ జడ్జిమెంట్ మాయమైపోవడం లేదు. అది మరింత ఉన్నత స్థాయికి మారుతోంది.

మీరు ఇకపై ఒక మ్యాప్‌ను ఎలా ఇటరేట్ చేయాలి లేదా క్లాస్ హైరార్కీని ఎలా నిర్మించాలి అనే దానిపై మానసిక శక్తిని ఖర్చు చేయరు. దానికి బదులుగా, సిస్టమ్ విఫలమైనప్పుడు ఏమి చేయాలి, ఏ డేటాను ఎప్పుడూ బయటపెట్టకూడదు మరియు డిస్ట్రిబ్యూటెడ్ సర్వీసుల అంతటా ఏ ఇన్‌వేరియంట్స్ (invariants) పాటించాలి అనే అంశాలపై దృష్టి పెడతారు. కోడింగ్ అనే నైపుణ్యం, రిక్వైర్మెంట్స్ (requirements) అనే నైపుణ్యంగా మారుతోంది.

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

మీ క్వాలిటీ బార్‌ను (quality bar) పుల్ రిక్వెస్ట్ (pull request) నుండి ప్రాంప్ట్ (prompt) స్థాయికి మార్చండి. మొదట హార్నెస్‌ను నిర్మించండి. రెండవది స్పెసిఫికేషన్‌ను రాయండి. ఆ తర్వాత, సమస్యను సరిగ్గా నిర్వచించారా మరియు బౌండరీలను సురక్షితంగా గీశారా అనే దానిపై మీరు దృష్టి పెడుతుంటే, సింటాక్స్‌ను (syntax) మెషిన్ చూసుకోనివ్వండి.

ఈ మార్పు వెనుక ఉన్న ఆలోచనలను మరింత లోతుగా తెలుసుకోవాలనుకుంటే, Intent-Driven Development పై అసలైన చర్చ ఇక్కడ అందుబాటులో ఉంది. AI-native ఇంజనీరింగ్ గురించి జరుగుతున్న చర్చల కోసం, మీరు GyaanSetu కమ్యూనిటీని కూడా చేరవచ్చు.