ஒவ்வொரு AI கோடிங் ஏஜென்ட்டும் ஒரு diff-ஐ வழங்க முடியும். ஆனால் உண்மையான சிக்கல் என்னவென்றால், அந்த diff ஒரு தெளிவான, திட்டமிட்ட செயல்முறையிலிருந்து வந்ததா அல்லது உங்கள் ரெபாசிட்டரி (repository) முழுவதும் அவசரமாகத் தேடித் தற்செயலாகச் சரியான முடிவுக்கு வந்ததா என்பதைக் கண்டறிவதில்தான் உள்ளது. தற்போது, பெரும்பாலான குழுக்களால் இந்த வித்தியாசத்தைக் கண்டறிய முடிவதில்லை.

இது ஒரு தொழில்நுட்பக் குறைபாடு அல்ல. இது ஒரு வெளிப்படைத்தன்மை (visibility) சார்ந்த சிக்கல்.

ஒரு ஏஜென்ட் மூன்று வரிகள் புரொடக்ஷன் கோடை (production code) எழுதும்போது, அது மூன்று கோப்புகளைப் படித்துவிட்டு சோதனைகளை (tests) செய்திருக்கலாம். அல்லது அது தொடர்பில்லாத நாற்பது கோப்புகளைத் தொட்டுவிட்டு, ஒரு டஜன் தோல்வியடைந்த கட்டளைகளை இயக்கிவிட்டு, டிபென்டென்சி இன்ஸ்டால் (dependency install) முறிந்ததால் உங்கள் டெஸ்ட் சூட்டைத் தவிர்த்துவிட்டு, அதற்காக உங்களிடம் கட்டணம் வசூலித்திருக்கலாம். இரண்டு நிலைகளிலும் diff பார்ப்பதற்கு ஒரே மாதிரியாகத்தான் இருக்கும். அந்தப் பயணத்தைப் பற்றிய பதிவு இல்லையென்றால், அதன் முடிவின் தரத்தைப் பற்றி நீங்கள் ஊகிக்க வேண்டியிருக்கும்.

ஏன் சாட் லாக்ஸ்கள் (Chat Logs) ரசீதுகள் (Receipts) அல்ல

பல கருவிகள் வேலையின் சான்றாக ஒரு சாட் டிரான்ஸ்கிரிப்டை (chat transcript) வழங்குகின்றன. ஒரு டிரான்ஸ்கிரிப்ட் என்பது ரசீது அல்ல. அது உங்கள் மேஜையில் கொட்டப்பட்ட பாகங்களின் பெட்டி போன்றது. அதில் ஒவ்வொரு சிந்தனைச் சுழற்சியும், ஒவ்வொரு தோல்வியடைந்த முயற்சியும், ஒவ்வொரு சிஸ்டம் பிராம்ட்டும் (system prompt) மற்றும் ஒவ்வொரு தேவையற்ற டூல் கால்களும் (tool call) அடங்கியிருக்கும். மூன்று வரிகள் கொண்ட ஒரு திருத்தத்தை (patch) சரிபார்க்க நீங்கள் ஆயிரம் வரிகள் உரையாடலைப் படிக்க வேண்டியிருந்தால், உங்கள் ரிவ்யூ பணிப்பாய்வு (review workflow) ஏற்கனவே முறிந்துவிட்டது என்று அர்த்தம்.

மனிதனின் கவனம் வரையறுக்கப்பட்டது. ஒரு ஏஜென்ட்டின் நோக்கம் அறிவுசார் முயற்சியைச் சேமிப்பதே தவிர, கூடுதல் வீட்டுப்பாடங்களை உருவாக்குவதல்ல. ஒரு டிரான்ஸ்கிரிப்ட், ரிவ்யூவரை ஒரு துப்பறியும் நிபுணராக மாற்றச் சொல்கிறது. ஆனால் ஒரு ரசீது, அவர்களுக்குத் தேவையான பதிலை ஒரு பார்வையில் அளிக்கிறது.

ஒரு பயனுள்ள ரசீது என்பது ஒரு நடைமுறைச் சுருக்கமாகும். ஏஜென்ட்டிடம் என்ன செய்யச் சொல்லப்பட்டது, அது உண்மையில் என்ன செய்தது மற்றும் அது எவ்வாறு தனது முடிவுக்கு வந்தது என்பதை அது உங்களுக்குத் தெரிவிக்கும். அது தோல்வியைத் மறைப்பதில்லை; மாறாக அதைத் தெளிவாகக் காட்டுகிறது.

ஒரு நல்ல ரசீது எப்படி இருக்கும்

ஒரு ரிவ்யூ செய்யக்கூடிய ரசீது, ஆழமாகத் தேடாமலேயே குறிப்பிட்ட கேள்விகளுக்குப் பதிலளிக்க வேண்டும்:

  • பணி என்ன? தெளிவான மாற்றத்திற்கான விளக்கம், வெறும் பிராம்ட்டின் எதிரொலியாக இல்லாமல் இருக்க வேண்டும்.
  • எந்தக் கோப்புகள் படிக்கப்பட்டன? ஏஜென்ட் சரியான ஆதாரங்களிலிருந்து சூழலை (context) உருவாக்கினானா என்பதை நீங்கள் தீர்மானிக்க இது உதவும்.
  • எந்தக் கோப்புகள் திருத்தப்பட்டன? மாற்றத்தின் இறுதித் தடம் (footprint).
  • எந்தக் கட்டளைகள் இயக்கப்பட்டன? பில்ட் ஸ்டெப்ஸ் (build steps), லின்டர்கள் (linters), ஃபார்மேட்டர்கள் (formatters) அல்லது ஏஜென்ட் பயன்படுத்திய தனிப்பயன் ஸ்கிரிப்ட்கள் (custom scripts).
  • எந்தக் கட்டளைகள் தோல்வியடைந்தன? வெற்றிகள் மட்டுமல்ல, தோல்விகளும் முக்கியம். ஏஜென்ட் எங்கே மாற்றங்களைச் செய்ய வேண்டியிருந்தது அல்லது எங்கே முயற்சியைக் கைவிட்டது என்பதைத் தோல்விகள் வெளிப்படுத்தும்.
  • எந்தச் சோதனைகள் வெற்றி பெற்றன அல்லது தவிர்க்கப்பட்டன? தவிர்க்கப்பட்ட சோதனைகள் ஒரு எச்சரிக்கை அறிகுறி (red flag). அவை ஏன் தவிர்க்கப்பட்டன என்பதை ரசீது கூற வேண்டும்.
  • மொத்தச் செலவு என்ன? டோக்கன்கள் (tokens), API அழைப்புகள் மற்றும் கணினி நேரம் (compute time). இதில் மாடலின் விலை மட்டுமல்லாமல், உங்கள் கட்டமைப்பின் (architecture) விலையும் அடங்கும்.

இந்த வடிவம், ரிவ்யூ செய்வதை ஒரு தொல்லியல் அகழ்வாராய்ச்சியாக இல்லாமல், ஒரு விரைவான சரிபார்ப்பாக (sanity check) மாற்றுகிறது. ஒரு சீனியர் இன்ஜினியர் ரசீதைப் பார்த்து, ஒரு நிமிடத்திற்குள்ளேயே "இது சரியாகத் தெரிகிறது" அல்லது "இது சந்தேகத்திற்குரியதாக உள்ளது" என்று சொல்ல முடிவிருக்க வேண்டும்.

வரலாற்றை மட்டுமல்ல, தடத்தையும் (Footprint) வாசியுங்கள்

ஒரு ஏஜென்ட் இயங்கியதன் தடம் (footprint), அந்த வேலையின் வடிவத்தைக் காட்டுகிறது. ஏஜென்ட் கொடுக்கப்பட்ட டிக்கெட்டின் (ticket) எல்லைக்குள் செயல்பட்டதா? அல்லது தொடர்பில்லாத மாட்யூல்களுக்குள் (modules) சென்று யாரும் கேட்காத விஷயங்களை மாற்றியதா? "திருத்தப்பட்ட கோப்புகள்" (Files Edited) மற்றும் "படிக்கப்பட்ட கோப்புகள்" (Files Read) ஆகியவற்றை அருகருகே பட்டியலிடும் ஒரு ரசீது இதைத் தெளிவாகக் காட்டும்.

தடம் என்பது மீண்டும் மீண்டும் நிகழும் செயல்களையும் வெளிப்படுத்தும். ஒரே கான்ஃபிக் ஃபைலை (config file) மூன்று முறை படிப்பது அல்லது தோல்வியடைந்த சோதனையைத் திரும்பத் திரும்ப இயக்குவது போன்ற முட்டுக்கட்டைகளைச் சந்திக்கும் ஒரு ஏஜென்ட், கணினித் திறன் (compute) மற்றும் கான்டெக்ஸ்ட் விண்டோவை (context window) வீணாக்குகிறது. அந்தப் போக்குத் தெளிவாகத் தெரிய வேண்டும். ஒரு மைக்ரேஷன் ஸ்கிரிப்டை (migration script) இயக்க ஒரு ஏஜென்ட் ஒன்பது முயற்சிகளை எடுத்திருந்தால், ரசீது அதைச் சொல்ல வேண்டும். அந்தத் தகவல் நீங்கள் வெளியீட்டை எவ்வாறு மதிப்பிடுகிறீர்கள் என்பதை மாற்றும். கட்டுப்பாடற்ற குழப்பத்தின் மூலம் பெறப்பட்ட ஒரு "சரியான" diff, நேர்த்தியாகப் பெறப்பட்ட ஒரு சரியான diff-க்குச் சமமானது அல்ல.

மோசமான வடிவமைப்பின் மறைமுகச் செலவு

செலவு என்பது ஒரு டோக்கனுக்கான விலை மட்டுமல்ல. மோசமாக வடிவமைக்கப்பட்ட பணிப்பாய்வு, ஒரு ஏஜென்ட் ஒரு எழுத்தைக் கூட உருவாக்கத் தொடங்கும் முன்பே அதை விலை உயர்ந்ததாக மாற்றிவிடும். வீக்கமடைந்த டூல் ஸ்கீமாக்கள் (tool schemas), தேவையற்ற ஃபைல் இன்டெக்ஸிங் (file indexing) மற்றும் மிக விரிவான சிஸ்டம் பிராம்ட்கள் (system prompts) ஆகியவை கான்டெக்ஸ்ட் விண்டோவை (context window) அதிகப்படுத்துகின்றன. ரசீது இந்த கூடுதல் சுமையைத் (overhead) வெளிப்படுத்த வேண்டும்.

உருவாக்கம் (generation) மலிவாகி, ஆனால் ரிவ்யூ செய்வது கடினமாகிவிட்டால், நீங்கள் எதையும் பெறவில்லை என்று அர்த்தம். நீங்கள் ஒரு தடைப் புள்ளியை (bottleneck) ஒரு இடத்திலிருந்து இன்னொரு இடத்திற்கு மாற்றியுள்ளீர்கள். ஒரு குழுவில் இன்ஜினியரின் நேரமே பொதுவாக மிகவும் அரிதான வளமாகும். ஒரு புல் ரிக்வெஸ்டிற்கு (pull request) முப்பது நிமிட கூடுதல் ரிவ்யூ நேரத்தைச் சேர்க்கும்போது, API செலவில் ஐந்து டாலர்களைச் சேமிப்பது ஒரு மோசமான வர்த்தகம். இந்த வர்த்தகத்தைத் நேரடியாகத் தணிக்கை செய்ய ரசீது உதவுகிறது.

நேர்மை என்பது ஒரு அம்சம் (Feature)

ஒரு பயனுள்ள ரசீது தேவைப்படும்போது சௌகரியமற்றதாக இருக்க வேண்டும். ஏஜென்ட் திறமையற்றது போலத் தோன்றும் உண்மைகளை அது தெரிவிக்க வேண்டும், ஏனெனில் அந்த நேர்மை அடுத்த மனித முடிவை வேகமாகவும் சிறப்பாகவும் எடுக்க உதவும்.

உதாரணங்கள் முக்கியம்:

  • "Read 37 files for a one-line change."
  • "Skipped tests because npm install failed with a peer dependency conflict."
  • "Edited utils.py outside the requested scope to fix an import the agent introduced."
  • "Ran the linter 4 times; first three failed due to path misconfiguration."

These are not bugs in the receipt. They are signals. They tell the reviewer where to focus skepticism. They also tell the platform team where the workflow itself needs tightening.

Smaller Runs, Clearer Oversight

There is a natural temptation to let agents run wild across large surfaces. One giant prompt to refactor an entire service feels fast. It is not. It creates an unreviewable lump of work. Your afternoon disappears into tracing which of eighty changed files were intentional.

Small, inspectable runs are better. Define clear boundaries for the task. Separate the list of files the agent may read from the list it may write. Capture a history of failed commands so the dead ends are visible. Flag skipped verifications explicitly. Note every external tool use, from search APIs to test runners.

The goal is not total autonomy. Total autonomy that no human can verify is just automation with liability. The real goal is reviewability. Every agent output should be easy to approve or easy to reject. There should be no ambiguous middle ground where you accept code because you are too tired to investigate.

The Test for Any Coding Agent

Before adopting any agent or platform, ask one question: Can it leave enough evidence for a human to approve the next step confidently?

If the answer is yes, the tool fits into a professional workflow. If the answer is no, you are not buying productivity. You are buying a mystery that occasionally compiles. That is fine for a weekend side project. It is unacceptable for production engineering.

Teams that treat agent outputs as unexamined gifts will eventually ship a subtle bug introduced by an undetected scope creep. The diff will look innocent. The receipt would have told the truth.

Require receipts. Design for review. Trust is not a strategy. Evidence is.

For more hands-on discussions around AI tooling and developer workflows, you can join the community at GyaanSetu on Telegram.