Vibe coding: उपयोग और सीमाएँ
पूरा हुआलोगों को AI के साथ विचारों को परखने में मदद करें। बैंकिंग prototype से समझें कि वास्तविक डेटा और API permissions के लिए सुरक्षा प्रमाण क्यों चाहिए।
प्रकाशक Taigaहम कैसे लिखते हैं
अपनी समझ जाँचेंबैंक का dashboard काल्पनिक transactions के साथ काम करता है। एक सहकर्मी वास्तविक खाते को read-only access से जोड़ने का सुझाव देता है। आपको क्या करना चाहिए?अभ्यास करें
आप क्या सीखेंगे
- नए विचार परखने और release का निर्णय लेने का अंतर समझें।
- प्रभावशाली demo में अधूरी जिम्मेदारियाँ पहचानें।
- पहले प्रयोग के लिए सुरक्षित सीमा चुनें।
लोगों को बनाने की जगह दें
किसी enterprise का CTO अधिक लोगों को उनके ज्ञान से software के विचार बनाने में मदद कर सकता है। Finance, operations, sales और engineering के लोगों को आमंत्रित करें। उन्हें समय, synthetic data, sandbox APIs और सहायता दें।
Installation, accounts और स्वीकार्य inputs की स्पष्ट सीमाएँ तय करें। इनके भीतर लोगों को विचार परखने के लिए अलग-अलग tools इस्तेमाल करने दें। Browser builder, coding assistant या local agent से वे अपना विचार परख सकते हैं। Tool चुनने से कंपनी की जानकारी upload करने या वास्तविक system जोड़ने की अनुमति नहीं मिलती।
उपयोगी prototype को engineering या platform team तक पहुँचाने की सरल प्रक्रिया प्रकाशित करें। उसे बनाने वाला व्यक्ति समस्या, workflow का उदाहरण और देखे गए लाभ बताए। उसे सेवा की security और operations team बनने की जरूरत नहीं है।
पहचानें कि आपको क्या सीखना है
Vibe coding आम तौर पर उस software के विवरण से शुरू होती है जिसे आप बनाना चाहते हैं। आप generated code स्वीकार करते हैं और दिखाई देने वाले परिणाम से अगला बदलाव तय करते हैं। इस शब्द के अलग-अलग अर्थ हैं। इस गाइड में काम का निर्देश देने वाला व्यक्ति implementation के हर निर्णय को जरूरी नहीं समझता हो।
इस तरीके से आप सीख सकते हैं। एक सरल interface दिखा सकता है कि approval प्रक्रिया में बहुत अधिक चरण हैं। अस्थायी script से file format का आकलन कर सकते हैं। Prototype लोगों को चर्चा के लिए ठोस design देता है। Code हटाने के बाद भी यह सीख आपके पास रहती है।
पहले ऐसा प्रश्न तय करें जिसका उत्तर परिणाम देखकर जाँचा जा सके। उदाहरण: “क्या team manager इस approval प्रक्रिया को समझ सकता है?” इस प्रश्न का दायरा स्पष्ट है। Expense system बनाने के अनुरोध में data protection, access control, संचालन और जिम्मेदारी भी शामिल हैं।
मंगलवार का बैंकिंग prototype
एक काल्पनिक उदाहरण लें। मंगलवार को finance का एक सहकर्मी मनगढ़ंत bank transactions से Lovable में dashboard बनाता है। वह खर्च को समूहों में बाँटता है और unpaid invoices दिखाता है। अब team एक उपयोगी workflow पर चर्चा कर सकती है।
कोई कंपनी का bank account जोड़ने का सुझाव देता है। इससे परिणामों का असर बदल जाता है, भले ही app पर अब भी “prototype” लिखा हो।
API के अनुसार read access से balance, transaction history, ग्राहकों के नाम या payment references दिख सकते हैं। अगर connection payments की अनुमति भी देता है, तो गलतियों से वास्तविक पैसे भेजे जा सकते हैं। Permissions का वास्तविक दायरा जाँचें। Bank connection में payment access हमेशा शामिल नहीं होता।
Demo यह सिद्ध नहीं करता कि उपयोगकर्ता केवल उन्हीं खातों को देख सकता है जिनकी उसे अनुमति है। Button छिपाने से permission लागू नहीं होती। OWASP बताता है कि account या record की जाँच न होने पर दूसरे उपयोगकर्ता का डेटा कैसे उजागर हो सकता है।
| क्या विफल हो सकता है? | यह क्यों मायने रखता है? | वास्तविक access से पहले प्रमाण |
|---|---|---|
| Private API credential browser code या logs में दिखता है | कोई दूसरा पक्ष उसकी permissions इस्तेमाल कर सकता है | Secrets को सँभालने का तरीका जाँचें; access वापस लेने का test करें |
| Backend अनुरोध भेजने वाले के अधिकार जाँचे बिना account ID स्वीकार करता है | एक उपयोगकर्ता दूसरा खाता पढ़ सकता है | दूसरे उपयोगकर्ताओं और खातों के अनुरोध अस्वीकार होने के tests करें |
| Payment request का timeout होता है और app उसे फिर भेजता है | Retry से दूसरा payment हो सकता है | Retry handling जाँचें और provider के records से परिणाम का मिलान करें |
| App transaction विवरण किसी अस्वीकृत AI service को भेजता है | गोपनीय जानकारी स्वीकृत सीमा से बाहर जाती है | Requests, logs, प्राप्तकर्ताओं और retention को trace करें |
| Launch के बाद किसी dependency में vulnerability मिलती है | बिना बदले app में भी security fix की जरूरत हो सकती है | लगातार scanning, remediation और deployment verification की जिम्मेदारी तय करें |
Payment APIs में idempotency का अर्थ है कि अनुरोध दोहराने से उसका इच्छित प्रभाव दोबारा नहीं होता। Stripe इसके एक implementation का विवरण देता है। वास्तविक provider के व्यवहार, सीमाओं और retry नियमों की जाँच करें। Application rollback से बैंक द्वारा process किया गया payment वापस नहीं होता।
यह उदाहरण Lovable में दोष का प्रमाण नहीं है। Lovable की अपनी security guidance में secrets की सुरक्षा, server-side checks, data policies के tests और लगातार review की जरूरत बताई गई है। किसी भी builder, agent या हाथ से लिखे app पर प्रमाण का यही मानक लागू करें।
वास्तविक systems जोड़ने से पहले access जाँचें
Synthetic data और sandbox accounts के साथ workflow की जाँच जारी रखें। वास्तविक access देने से पहले service, security और platform के जिम्मेदार लोगों से application और उसके operating environment की जाँच कराएँ।
Bank या provider की स्वीकृत connection प्रक्रिया इस्तेमाल करें। केवल जरूरी accounts और permissions दें। Private credentials को स्वीकृत secret storage में रखें, prompts और browser code में नहीं। जहाँ payments जरूरी हों, वहाँ payment approvals और limits तय करें। Access वापस लेने, विफलताओं की जाँच करने और संदिग्ध गतिविधि का जवाब देने के तरीके जाँचें।
ये निर्णय गोपनीय input या वास्तविक credentials के system में आने से पहले लेने चाहिए। औपचारिक production release तक इंतजार करना बहुत देर हो सकता है। आगे डेटा की सीमाएँ और enterprise infrastructure पढ़ें।
उपयोग बढ़ाने से पहले जिम्मेदारियाँ तय करें
मनगढ़ंत डेटा वाला प्रयोग थोड़े समय और कम लोगों के लिए हो सकता है। जब दूसरे लोग app पर निर्भर होने लगें, तो उसके उपयोग की जिम्मेदारियाँ तय करें।
- जिम्मेदार व्यक्ति का नाम तय करें।
- स्वीकार्य उपयोगकर्ताओं और डेटा की पहचान करें।
- विफलता होने पर प्रतिक्रिया तय करें।
- Source code और configuration को repository में रखें।
- जाँचें कि कोई दूसरा व्यक्ति system का निरीक्षण करके उसे दोबारा बना सकता है।
हर script को enterprise platform की जरूरत नहीं होती। संवेदनशील डेटा के बिना चलने वाले व्यक्तिगत formatter को payment approval app से कम controls चाहिए। गलती के परिणामों का आकलन करें। जाँचें कि आप गलती का पता लगा सकते हैं और उसका प्रभाव पलट सकते हैं या नहीं।
Prototype का विस्तार करने से पहले समस्या के बारे में मिली सीख को implementation के प्रमाण से अलग करें। आप interface रखकर अंदर का code बदल सकते हैं। इच्छित उपयोग को सीमित कर सकते हैं। Prototype को अस्थायी प्रयोग भी रहने दे सकते हैं।
Demo के बाद vulnerabilities के लिए योजना बनाएँ
सफल demo रखरखाव की गंभीर कमी छिपा सकता है। आपके code में कोई बदलाव हुए बिना भी dependency के लिए नई vulnerability advisory जारी हो सकती है। Release के समय किया गया scan केवल उस समय की स्थिति बताता है।
अगर app उपयोग में रहता है, तो किसी को vulnerabilities ढूँढ़ने, उनका आकलन करने और उन्हें ठीक करने का काम जारी रखना होगा। सुधार production तक पहुँचना चाहिए और उसकी जाँच सफल होनी चाहिए। इस प्रतिक्रिया प्रक्रिया के बिना scanner जोखिम को अनसुलझा छोड़ता है।
जाँचें कि आपके वास्तविक tool और configuration में क्या मिलता है। आगे लगातार vulnerability management में पूरी प्रक्रिया समझाई गई है, जिसमें scan failures और deployed versions भी शामिल हैं।
अगले बदलाव का review आसान बनाएँ
Agent को स्पष्ट acceptance criteria के साथ एक छोटा बदलाव दें। बताएँ कि agent कौन-से काम कर सकता है। बने हुए diff का निरीक्षण करें। ऐसी जाँच करें जो गलत implementation को अस्वीकार कर सके। Release की जिम्मेदारियाँ स्पष्ट होने तक deployment को अलग निर्णय रखें।
NIST Secure Software Development Framework में सुरक्षित development की व्यापक practices दी गई हैं। छूटे हुए controls का आकलन करते समय इसका संदर्भ लें। Framework याद करना जरूरी नहीं है। Software का असर दूसरे लोगों पर पड़ने से पहले आपको अधूरे प्रमाण पहचानने हैं।
अभ्यास करें
हाल के किसी demo से एक feature चुनें। 1. ऐसा एक परिणाम लिखें जो demo ने सिद्ध किया। 2. तीन प्रश्न लिखें जिनके उत्तर अभी नहीं मिले हैं। 3. हर प्रश्न के लिए एक जिम्मेदार व्यक्ति तय करें। 4. हर संभावित विफलता का पता लगाने वाली एक स्पष्ट जाँच बताएँ। किसी स्पष्ट जाँच की जगह केवल “इसे सुरक्षित बनाएँ” न लिखें।
Worksheet डाउनलोड करें (Markdown)यह चयन हटाने से इस browser में सहेजी गई पूरी प्रगति मिट जाती है।
प्रगति इसी browser में रहती है। कोई account या tracking नहीं।
स्रोत और आगे पढ़ें
- NIST: Secure Software Development Framework 1.1 ↗
- Lovable: Security best practices ↗
- OWASP: Broken Object Level Authorization ↗
- Stripe: Idempotent requests ↗