గత నెలలో, ఒక AI అసిస్టెంట్ ప్రొడక్షన్ ప్రాజెక్ట్ కోసం ఒక Python స్క్రిప్ట్ను రూపొందించింది. ఆ అవుట్పుట్ ఎటువంటి లోపాలు లేకుండా నడిచింది. డేటా కూడా సరిగ్గా ఉంది. కానీ మాన్యువల్ రివ్యూ చేసినప్పుడు, డేటాబేస్ కాల్స్లో ఒక N+1 క్వెరీ ప్యాటర్న్ దాగి ఉన్నట్లు తెలిసింది. చిన్న డేటాసెట్కు ఆ కోడ్ బాగానే పనిచేసింది. కానీ వేల సంఖ్యలో రికార్డులను పెంచితే, అప్లికేషన్ పేరెంట్ ఆబ్జెక్ట్ల కోసం ఒక క్వెరీని, ఆపై సంబంధిత డేటా కోసం వేల సంఖ్యలో ఫాలో-అప్ క్వెరీలను జారీ చేస్తుంది. దీని ఫలితంగా ఒక భారీ పెర్ఫార్మెన్స్ సమస్య (performance cliff) ఎదురవుతుంది, దీనిని ఏ యూనిట్ టెస్ట్ కూడా గుర్తించలేదు.
ఆధునిక సాఫ్ట్వేర్ డెవలప్మెంట్లో ఇదే వాస్తవం. AI టూల్స్ ఇప్పుడు మనుషులు చేయలేనంత వేగంతో కోడింగ్, డీబగ్గింగ్ మరియు ఆర్కిటెక్చరల్ సూచనలను అందిస్తున్నాయి. ఆ వేగం నిజమే. కానీ ఇది మీ ఉద్యోగ స్వభావాన్ని పూర్తిగా మారుస్తుంది. మీరు కేవలం సింటాక్స్ (syntax) టైప్ చేయడానికి మాత్రమే జీతం పొందడం లేదు. మీరు ఆడిట్ చేయడానికి, ఆర్కిటెక్ట్ చేయడానికి మరియు ఇటువంటి అదృశ్యమైన చిక్కులను (invisible traps) పట్టుకోవడానికి జీతం పొందుతున్నారు.
"లాజికల్గా ఉన్నా, తప్పు" అనే నిశ్శబ్ద ప్రమాదం
AI రూపొందించిన కోడ్ తరచుగా సరిగ్గా ఉన్నట్లు కనిపిస్తుంది, ఎందుకంటే అది కంపైల్ అవుతుంది, రన్ అవుతుంది మరియు ఆశించిన విలువను ఇస్తుంది. పైకి చూస్తే లాజిక్ అంతా సరిగ్గా ఉన్నట్లు అనిపిస్తుంది. కానీ లోపల అది నిశ్శబ్దంగా విఫలమై ఉండవచ్చు.
రెగ్యులర్ ఎక్స్ప్రెషన్స్ (regular expressions) తీసుకుంటే, ఒక AI ఇంగ్లీష్లో ఈమెయిల్ అడ్రస్లు లేదా ఐడెంటిఫైయర్లను ఖచ్చితంగా సరిపోల్చే ప్యాటర్న్ను మీకు ఇవ్వవచ్చు. అదే ఎక్స్ప్రెషన్ను జర్మన్ అమ్లాట్స్ (umlauts), అరబిక్ స్క్రిప్ట్లు లేదా యూనికోడ్ నార్మలైజేషన్ ఎడ్జ్ కేస్లపై రన్ చేస్తే, అది నిశ్శబ్దంగా విఫలమవుతుంది. కోడ్ ఎర్రర్ను చూపించే విధంగా తప్పుగా ఉండదు. అది కేవలం వాస్తవ ప్రపంచంలోని చెల్లుబాటు అయ్యే డేటాను మినహాయించివేస్తుంది.
డేటాబేస్ క్వెరీల విషయంలో కూడా ఇలాంటి రిస్క్ ఉంటుంది. ఒక AI టెస్టింగ్ సమయంలో సరైన రోస్ (rows) రిటర్న్ చేసే PostgreSQL క్వెరీని రాయగలదు, కానీ అదే క్వెరీ మీ టేబుల్స్ను డెడ్ టపుల్స్తో (dead tuples) నింపవచ్చు, ఇండెక్స్ వినియోగాన్ని వదిలేయవచ్చు లేదా ప్రొడక్షన్ వర్క్లోడ్లను దెబ్బతీసే సీక్వెన్షియల్ స్కాన్లను (sequential scans) బలవంతం చేయవచ్చు. డెమో డేటాసెట్లో పనిచేసేది మరియు నిజమైన లోడ్ ఉన్నప్పుడు పనిచేసేది అనేవి రెండు వేర్వేరు విషయాలు. మెషిన్కు లేటెన్సీ (latency) తెలియదు. అది క్లౌడ్ బిల్లును చెల్లించదు.
రాయడం నుండి వెరిఫై చేయడం వరకు
ముఖ్యమైన మార్పు ఏమిటంటే "నేను దీన్ని ఎలా రాయాలి?" నుండి "నేను దీన్ని ఎలా వెరిఫై చేయాలి?" అనే వైపుకు మళ్లడం. AI మొదటి డ్రాఫ్ట్ను సిద్ధం చేసినప్పుడు, మీ మానసిక శ్రమ (cognitive load) తదుపరి దశల వైపు మళ్లాలి. ఒక అలసిపోయిన రచయిత తన పనిని పైపైన చదివినట్లు కాకుండా, ఒక సెక్యూరిటీ ఆడిటర్ కోడ్ను ఎలా చదువుతారో మీరు కూడా అలా చదవాలి.
దీనికి ఒక రకమైన క్రమశిక్షణ అవసరం. ఆటోమేషన్ బయాస్ (Automation bias) అనేది నిజమైన సమస్య. ఒక టూల్ ఫ్లూయెంట్గా, సింటాక్టికల్గా పర్ఫెక్ట్ అవుట్పుట్ను ఇచ్చినప్పుడు, మానవ మెదడు రిలాక్స్ అవుతుంది. ప్రెజెంటేషన్ పాలిష్డ్గా ఉండటం వల్ల అది కరెక్ట్ అని మీరు అనుకుంటారు. ఆ ప్రేరణను (impulse) అదుపు చేయడమే ఇప్పుడు ప్రధాన నైపుణ్యం. ప్రతి సూచనను అది నిరూపించబడే వరకు ఒక హైపోథెసిస్గా మాత్రమే మీరు పరిగణించాలి.
మెషిన్తో కలిసి పనిచేయడం
AI కోడింగ్ అసిస్టెంట్ నుండి ఉపయోగకరమైన అవుట్పుట్ను పొందడం అంటే వేగంగా టైప్ చేయడం కాదు. మెషిన్ యొక్క ట్రైనింగ్ డేటాకు మరియు మీ నిర్దిష్ట వాస్తవికతకు మధ్య ఉన్న దూరాన్ని తగ్గించడం గురించి ఇది. కొన్ని నిర్దిష్ట పద్ధతుల ద్వారా మీరు ఆ దూరాన్ని తగ్గించవచ్చు.
మీ ప్రాంప్ట్లలో ఖచ్చితంగా ఉండండి. ఇక్కడ అస్పష్టత కవిత్వాన్ని సృష్టించదు; అది బగ్లను (bugs) సృష్టిస్తుంది. "ఈ ఫంక్షన్ను ఆప్టిమైజ్ చేయండి" వంటి ప్రాంప్ట్ సాధారణ సలహాలకే దారితీస్తుంది. దానికి బదులుగా, "ఇటరేటెడ్ సేవ్స్ (iterated saves) కు బదులుగా ఒకేసారి బల్క్ డేటాబేస్ అప్డేట్ను ఉపయోగించడానికి ఈ Python లూప్ను రీఫ్యాక్టర్ చేయండి" అని రాయండి. ఖచ్చితత్వం అనేది సాధ్యమయ్యే పరిధిని తగ్గిస్తుంది.
నిజమైన కాంటెక్స్ట్ను అందించండి. మీరు ఒక Kubernetes క్లస్టర్లో, కఠినమైన 30-సెకన్ల రిక్వెస్ట్ టైమ్అవుట్తో, PostgreSQL 15 పై Django 4.2ని నడుపుతున్నారని మీరు చెప్పనంత వరకు AIకి తెలియదు. మీ డిపెండెన్సీ వెర్షన్లు, మీ ఇంటర్నల్ లైబ్రరీలు మరియు మీ మార్చలేని పరిమితులను (non-negotiable constraints) దానికి అందించండి. కాంటెక్స్ట్ అనేది కేవలం అలంకారం కాదు; అది ఒక రక్షణ కవచం (guardrails).
మీ స్వంత డాక్యుమెంట్లతో సమాధానాలను ధృవీకరించండి. రిట్రీవల్-ఆగ్మెంటెడ్ జనరేషన్ (Retrieval-Augmented Generation) లేదా RAG అనేది కేవలం చాట్బాట్ల కోసం వాడే బజ్ వర్డ్ మాత్రమే కాదు. మీ అసలు API స్పెసిఫికేషన్లు, మీ ఆర్కిటెక్చర్ డెసిషన్ రికార్డులు మరియు మీ కోడ్బేస్ కన్వెన్షన్ల వైపు మీ అసిస్టెంట్ను మళ్లించండి. మోడల్ ట్రైనింగ్ డేటా నుండి ఊహించే బదులు మీ డాక్యుమెంటేషన్ నుండి వాస్తవాలను సేకరించినప్పుడు, సాధారణ సలహాలకు మరియు ఉపయోగకరమైన కోడ్కు మధ్య ఉన్న అంతరం గణనీయంగా తగ్గుతుంది.
సంక్లిష్టమైన పనిని చిన్న చిన్న పనులుగా విభజించండి. ప్రతి దశకు ఒక పరిమిత పరిధి ఉన్నప్పుడు ఏజెంట్ ప్యాటర్న్స్ (Agent patterns) బాగా పనిచేస్తాయి. ఒకేసారి పూర్తి మైక్రోసర్వీస్ రీఫ్యాక్టరింగ్ను అడగవద్దు. మొదట డేటా స్కీమాను అడగండి. దానిని ధృవీకరించండి. ఆపై మైగ్రేషన్ స్క్రిప్ట్ను అడగండి. దానిని ధృవీకరించండి. ఆ తర్వాత సర్వీస్ లేయర్కు వెళ్లండి.