आपका AI app builder आपको पहले नकली data क्यों दिखाता है (और यही सही चाल क्यों है)

आप अपने AI app builder को एक app बताते हैं। एक मिनट बाद आप एक चलते हुए interface को देख रहे होते हैं — pages, buttons, “Alex Rivera” और “Priya Shah” जैसे नामों वाले users की एक table, ऐसी कीमतें जिनका कोई तुक नहीं, एक “Pro Plan” जो आपने मांगा ही नहीं था। कुछ भी save नहीं हो रहा। अगर आप refresh करें, तो data फिर भी वहीं है। अगर आप एक नया user जोड़ें, तो वो ग़ायब हो जाता है।

यह एक ऐसे जादू के खेल जैसा लगता है जो बस अभी बिखरने वाला है। है नहीं। यह तो build का अच्छा हिस्सा है। आपकी screen पर वो mock data एक सोची-समझी पहली चाल है, और यही वो वजह है जिससे आगे आने वाला database सचमुच उस app से मेल खाएगा जो आप चाहते थे।

“पहले नकली data” का असल में मतलब क्या है

जब कोई AI app builder आपका brief लेता है, तो वो सीधे database पर नहीं जाता। एक अच्छा builder पहले screens लिखता है, उन्हें भरोसेमंद लगने वाले placeholder data से भरता है, और फिर — और सिर्फ़ तभी — उससे मेल खाता हुआ database design करता है।

वो placeholder data सजावट नहीं है। यह एक करार है। एक बार आपकी app कह दे कि “हर order में एक customer name, तीन line items, एक total और एक status होता है,” तो आगे जो database बनता है उसमें ठीक वही चीज़ें होनी चाहिए, ठीक उन्हीं आकारों में। screens तय करती हैं कि data कैसा दिखता है, उल्टा नहीं।

यह उस तरीके से उल्टा है जैसे एक इंसानी डेवलपर आमतौर पर शुरुआत करता है। एक पारंपरिक डेवलपर पहले database design करता है, फिर उसके हिसाब से screens बनाता है। AI builders ने इसे पलट दिया, और ज़्यादातर लोग ध्यान ही नहीं देते — वो बस नकली users देखते हैं और मान लेते हैं कि builder नाटक कर रहा है।

यह क्रम AI के साथ बेहतर क्यों काम करता है

हमने database और screens को एक साथ बनाकर देखा। यह काम नहीं किया। क्यों, इसका छोटा वर्शन यह रहा।

जब दो AI agents एक app के अलग-अलग हिस्सों पर एक-दूसरे का output देखे बिना काम करते हैं, तो वो ऐसे अंदाज़े लगाते हैं जो आपस में नहीं बैठते। interface agent तय करता है कि users में एक “name” field होता है। database agent तय करता है कि users में एक “fullName” field होता है। दोनों सही दिखते हैं। साथ में, कुछ काम नहीं करता। बेमेल पर पैबंद लगाने के लिए एक तीसरा agent बुलाया जाता है। वो भी अंदाज़ा लगाता है। अब तीन अंदाज़े खुले घूम रहे हैं, और जो app आप preview करते हैं वो उन सबका कोई Frankenstein होता है।

उपाय लगभग शर्मिंदा करने वाला है: पहले एक चीज़ करो, फिर दूसरी। interface बन जाता है। वो लिख देता है कि उसे कौन सा data चाहिए — नकली users, नकली orders, आपकी app जिस बारे में हो उसका नकली कुछ भी — एक ही file के रूप में। database agent वो file पढ़ता है और field-दर-field उससे मेल खाता है। कोई अंदाज़ा नहीं। कोई मोल-तोल नहीं। कोई बेमेल नहीं।

इसीलिए आपका AI app builder आपको एक मिनट में एक तैयार-सी दिखने वाली app दिखा सकता है। उसने build का नाटक नहीं किया है। उसने build का एक-चौथाई हिस्सा कर दिया है — वो हिस्सा जो बाकी सब कुछ तय करता है — और database अगले दस सेकंड का काम है, अगले दस घंटे का नहीं।

जब नकली data screen पर हो तो क्या देखें

यही वो पल है जिसे ज़्यादातर लोग बिना सोचे निकाल देते हैं। वो placeholder data देखते हैं और रंग बदलने को कहना शुरू कर देते हैं। पर placeholder data तो आपसे पूछा गया एक सवाल है। उसे पढ़िए।

किन चीज़ों पर नज़र रखें, इसके कुछ उदाहरण:

• ग़लत शब्दावली। आप जो app चाहते थे वो “shipments” track करती है। placeholder data उन्हें “orders” कहता है। builder को बताइए। अगर आप इसे अभी जाने देते हैं, तो हर screen, हर database field, हर report ग़लत शब्द इस्तेमाल करेगी — और बाद में नाम बदलना किसी भी टूल में एक-क्लिक का काम नहीं है, marketing चाहे जो कहे।
• गुम fields। नकली invoice में एक total और एक date है। आपको एक PO number भी चाहिए। इसे अभी जोड़ना बेहतर है, जब screen पर पांच mock invoices हैं, बजाय इसके कि database बन जाए और असली customer data से भर जाए।
• ग़लत आकार। mock data दिखाता है “1 customer, 1 address”। आपके असल customers के कई addresses होते हैं। builder आपके brief से यह नहीं भांप सकता। इसे अभी बताइए, जब आकार बदलने में कुछ ख़र्च नहीं होता।
• चौंकाने वाली entities। builder ने एक “team” वाला idea गढ़ लिया जो आपने मांगा ही नहीं था, क्योंकि उसने मान लिया कि यह एक multi-user app है। शायद आप यही चाहते थे। शायद नहीं। दोनों सूरतों में, database उसके इर्द-गिर्द बनने से पहले फ़ैसला कर लीजिए।

एक काम का नियम: अगर आपकी app में कोई संज्ञा है जो screen पर के placeholder data में नहीं दिख रही, तो builder को अभी उसके बारे में पता नहीं है। पहले preview पर “save” क्लिक करने से पहले उसका ज़िक्र कर दीजिए।

आगे जो आता है उसके लिए यह क्रम क्यों मायने रखता है

एक बार placeholder data सही हो जाए, तो database का बनना यंत्रवत हो जाता है। builder आपका नकली data पढ़ता है, उससे मेल खाता एक schema जनरेट करता है, वो queries लिखता है जिन्हें screens पहले से call करने की कोशिश कर रही थीं, और आख़िर में placeholder imports को असली से बदल देता है। वही screens जो नकली users दिखा रही थीं, अब वो दिखाती हैं जो आपने सचमुच डाला।

आप आमतौर पर इस अदला-बदली को real time में होते देख सकते हैं। एक page जो फ़ौरन load हो रहा था क्योंकि वो एक local file पढ़ रहा था, अब उसमें आधे सेकंड की loading state है — यही वो screen है जो पहली बार किसी असली database से बात कर रही है। ज़्यादातर लोग इसे चूक जाते हैं और भांप नहीं पाते कि app अभी-अभी “demo” से “ऐसी चीज़ जो असली data रख सकती है” की लकीर पार कर गई है।

यह सब काम करता ही इसलिए है क्योंकि आगे की हर चीज़ — database design, queries, loading states, empty states — placeholder वाले दौर में आपने screen पर जो देखा उसी से तय हुई थी। अगर आपने तीन columns को हां कही, तो आपको तीन columns मिलते हैं। अगर आपने “draft” और “sent” values वाले एक “status” field को हां कही, तो database ठीक वही स्वीकार करता है। कोई दूसरा अनुवाद वाला step नहीं है जहां designer-developer के बीच की अदला-बदली चीज़ों को बिगाड़ दे।

एक छोटा test जो आप चला सकते हैं

अगली बार जब आप कुछ बनाएं, तो यह आज़माइए: जब placeholder data सामने आए, तो कुछ और मांगने से पहले उसके बारे में एक चीज़ बदल दीजिए। एक field का नाम बदलिए। एक column जोड़िए। “users” को “members” से बदलिए। फिर देखिए कि जब database बनता है तो क्या होता है।

आप उस बदलाव को हर जगह दिखते देखेंगे — database design में, queries में, उस seed data में जो builder app के पूरा होने पर डालता है। placeholder वाले दौर में एक शब्द ने पूरी app में लहर पैदा कर दी। यही वो ताकत है जो इस दौर में आपके पास होती है, और यही वजह है कि “पहले नकली data” कोई काट-छांट वाली चाल नहीं है। यही वो जगह है जहां app सचमुच तय होती है।

अगर आप और गहराई में जाना चाहते हैं, तो हमारी पिछली पोस्ट एक AI से बनी app के अंदर असल में क्या होता है उन बाकी चलते-फिरते पुर्ज़ों के बीच से गुज़ारती है जो पहली नज़र में आपको नहीं दिखते। pattern वही है: ज़्यादातर ताकत उन हिस्सों में होती है जो ऐसे दिखते हैं जैसे वो मायने ही नहीं रखते।