Vibe Coding என்றால் உண்மையில் என்ன?

"Vibe coding" என்ற சொல் 2024-2025 இல் வேகமாகப் பரவியது, ஏனெனில் பலரும் ஏற்கனவே조용히செய்துகொண்டிருந்த ஒன்றுக்கு பெயர் சூட்டியது: GPT-4, Claude, அல்லது Cursor அல்லது GitHub Copilot போன்ற கருவிக்கு வெற்று ஆங்கிலத்தில் தங்கள் விருப்பத்தை விவரித்து, அதை அधिकாংश உண்மையான குறியீட்டை உருவாக்க அனுமதிப்பது. நிரல்லாசிரியர் வளையத்தில் இருக்கிறார், ஆனால் வளையம் பாரம்பரிய குறியீட்டிலிருந்து வேறுபட்டுக் காணப்படுகிறது.

உண்மையான வரையறை

Andrej Karpathy இந்த சொற்றொடரை உருவாக்கினார், "முழுமையாக vibes க்குள் கொடுத்துவிடு" என்ற workflow ஐ விவரிக்கிறார் — நீ prompt செய்கிறாய், பரிந்துரைகளை ஏற்றுக்கொள்கிறாய், குறியீடை இயக்குகிறாய், எது உடைந்துவிட்டது என்று பார்க்கிறாய், மறுபடியும் prompt செய்கிறாய். நீ ஒவ்வொரு diff வரியையும் வரிதோறும் படிக்கவில்லை. நீ ผลவிளைவு மூலம் திசைதிருப்புகிறாய்: பயன்பாடு விஷயத்தை செய்கிறதா, சோதனை பயன்பட்டதா, பக்கம் சரியாக render ஆகிறதா. திறமை syntax எழுதுவது மற்றும் நோக்கத்தை தெளிவாக விவரிப்பது மற்றும் வெளியீடு தவறு என்று அறிந்துகொள்ளுவதற்கு மாற்றம் செய்கிறது.

இது autocomplete ஐ பயன்படுத்துவதற்கு வேறுபட்டது. Copilot-style inline பரிந்துரைகள் இன்னும் நீ செயல்பாட்டை நিজே எழுதுகிறாய் என்ற கருத்தை நிலைநிறுத்துகின்றன, சில வரிகளை முடிக்க சாহாய்யம் உண்டு. Vibe coding என்பது மாதிரி செயல்பாட்டை, கோப்பை, சில சமயம் முழு feature ஐயும் எழுதுகிறது, மற்றும் நீ ஆரம்பத்தில் இருந்து লেখுவதற்கு பதிலாக மதிப்பாய்வு செய்யும் மற்றும் வழிமாற்றும் கொண்டிருக்கிறாய்.

உண்மையான session ஐ என்ன போல் தெரிகிறது

Cursor அல்லது Replit இன் Agent mode போன்ற கருவி கொண்ட ஒரு பொதுவான vibe-coding loop இப்படி போக்கிறது:

1. Prompt: "இந்த Express API க்கு rate limiter சேர்க்கவும், IP க்கு 15 நிமிடங்களுக்கு 100 requests, JSON error body கொண்ட 429 ஐ return செய்யவும்."
2. மாதிரி middleware/rateLimit.js ஐ edit செய்கிறது, அதை app.js க்குள் wire செய்கிறது, பலவேளை express-rate-limit ஐ pull செய்கிறது.
3. நீ npm test இயக்குகிறாய் அல்லது loop இல் curl உடன் endpoint ஐ hit செய்து 429 உண்மையாக fire ஆகிறதா என்று சோதிக்கிறாய்.
4. ஏதோ தவறுக்கு போய்விட்டது — limiter ஒவ்வொரு deploy இலும் reset ஆகிறது, ஏனெனில் அது in-memory இல் உள்ளது. நீ அதை சொல்கிறாய்.
5. மாதிரி Redis-backed store இல் மாற்றுகிறது, ioredis dependency ஐ சேர்க்கிறது, docker-compose கோப்பை update செய்கிறது.
6. நீ மறுபடியும் சோதிக்கிறாய், அது வேலை செய்கிறது, நீ commit செய்கிறாய்.

அந்த middleware இன் எந்த வரியும் கையால் தட்டச்சு செய்யப்படவில்லை. ஆனால் ஆறு அல்லது ஏழு판断 calls ஐ ஒரு மனிதர் செய்தார்: limit என்ன இருக்க வேண்டும், in-memory storage production க்கு தவறு என்பது, docker-compose கோப்பு உம் update ஆக வேண்டும்.

இது நன்றாக வேலை செய்யும் இடம்

Vibe coding என்பது boilerplate-heavy வேலையின் பலமாக உள்ளது: CRUD endpoints, form validation, test scaffolding, config files, நீ ஏற்கனவே புரிந்துக் கொள்ளும் இரண்டு APIs க்கு இடையே glue code. இது prototyping க்கு நன்றாக உள்ளது — ஒரு ধারணার ஒரு வேலை செய்ய கூடிய demo ஐ ஒரு மணிநேரத்தில் spin செய்வது, பின்னர் அதை சரியாக கட்ட வேண்டுமா என்பதை முடிவு செய்வது.

இது solo devs மற்றும் small teams க்கு genuinely வேகமாக உள்ளது, அவர்கள் internal tools அல்லது MVPs ஐ ship செய்கிறார்கள் இங்கு bug இன் செலவு குறைவாக உள்ளது மற்றும் iteration speed architectural purity விட மிக முக்கியம்.

இது தடைபட்ட இடம்

Failure mode மக்கள்충분히பேச மாட்டார்கள்: models வேலை செய்யும் குறியீட்டை உருவாக்குகிறது ஆனால் பின்னர் வராத வழிகளில் subtly தவறாக உள்ளது. ஒரு generated SQL query happy path க்கு வேலை செய்யக்கூடும் ஆனால் string concatenation மாதிரிக்கு நன்றாக தெரிந்தது என்ற காரணத்தாக injection க்கு பாதிக்கப்படக்கூடும். ஒரு generated auth check சோதனைகளை pass கூடும் ஆனால் ஒரு route இல் role check skip கூடும். நீ குறியீட்டை படிக்கவில்லை என்றால், நீ அதை catch செய்ய மாட்டாய் — நீ சோதனைகளை pass செய்தது பார்க்கிறாய் மற்றும் ship செய்வாய்.

இது கிட்டத்தட்ட வேறு எந்த இடத்திலும் விட security-sensitive code இல் மிக্கவும் முக்கியம். Simon Willison மற்றும் மற்றவர்கள் உண்மையான user data உண்டுள்ள vibe-coded projects க்கு வேறு code போல் same review rigor ஐ தேவை பற்றி சுட்டிக்காட்டியுள்ளார்கள், மேலும் probable ஆக, ஏனெனில் அதை "எழுதிய" நபர் அதை வரியை வரியாக என்ன செய்கிறது என்ற விளக்கம் அளிக்க முடியாமல் இருக்கக்கூடும்.

நிறைய implicit state உண்டுள்ள சிக்கல் சிஸ்டம்கள் — concurrency, distributed transactions, நுட்பமான timing bugs உண்டுள்ள anything — மூவும் பொருத்தமற்ற. Models இந்த cases க்கு plausible-looking குறியீட்டை உருவாக்குகிறது, அது நாம் ஆரம்பத்தில் edge cases ஐ முழுமையாக மாதிரி செய்யாய் என்ற தகராறின் வழியாக debug செய்ய கடினம் என்ற வழிகளில் தর்க்கம் செய்கிறது.

இப்போது மூலம் முக்கியமான திறமை

நீ vibe coding செய்தால், மূல்யமான திறமை typing speed, இது specification ஆகும். Vague prompts vague, buggy குறியீட்டை பெறுகிறது. Specific prompts — exact library names, error-handling expectations, மற்றும் edge cases called out உடன் — மிக்கவும் நன்றாய்ת வெளியீட்டை பெறுகிறது. இரண்டாவது மிக்கவும் மூல्यवान திறமை வேகமாக குறியீட்டை படிப்பது, என்ன தவறாக உள்ளது என்பதை catch செய்ய வேண்டும், இது நீ இன்னும் மொழியைப் புரிந்து கொள்ள வேண்டும் மற்றும் domain ஆனாலும் நீ ஒவ்வொரு character ஐ type செய்கிறாய் உங்களை இல்லாமல்.

AI-generated குறியீட்டை நீ ஒரு junior dev இலிருந்து ஒரு pull request ஐ நடத்துவாய் என்ற வழிக்கு நடத்து வேண்டும் வேகமாக ஆனால் occasionally overconfident: பயனுள்ள, பொதுவாக சரி, ஆனால் அது production ஐ தொடுவதற்கு முன் அற்ப உண்மையான review மூலம் மூல்யம்।

AI tools உடன் குறியீட்டை எழுதுவது பற்றி quality இன் control ஐ இழப்பாமல் மிக்கவும் ஆழமாக போக வேண்டுமா? Korra Studio இன் AI மற்றும் Python segments ஐ hands-on walkthroughs க்கு check செய்யவும்.