AI उत्पादों को वैसे न बनाइए जैसे बाकी सभी बना रहे हैं
LLM APIs ने “AI products” को ship करना आसान बना दिया है, लेकिन कई commenters का तर्क है कि बिना unique data, workflow, या domain insight के ChatGPT पर बनी thin wrappers एक dead end हैं। वे real user problems और traditional software design से शुरुआत करने, फिर केवल वहीं narrow, specialized models जोड़ने की सलाह देते हैं जहाँ AI सचमुच ज़रूरी हो, साथ ही platform risk, latency, cost, और बहुत जल्दी custom toolchains को over-engineer करने के temptation से सावधान रहने को कहते हैं। दूसरे counter करते हैं कि तेज़, यहाँ तक कि derivative prototypes भी limits सीखने, users आकर्षित करने, और सचमुच उपयोगी AI-augmented features की ओर iterate करने के लिए क़ीमती हैं।
AI एक टूल के रूप में बनाम AI व्यवसाय के रूप में
- कई लोगों का तर्क है कि “असली रहस्य” पहले एक व्यवहार्य व्यवसाय होना है, और फिर AI का उपयोग करके उसे बेहतर बनाना है (जैसे, किसी मौजूदा ईमेल उत्पाद में सारांश जोड़ना)।
- कुछ लोगों का मानना है कि कुछ मॉडल केवल AI-चालित लागत में कमी के कारण ही व्यवहार्य होते हैं, इसलिए AI-केंद्रित व्यवसाय समझ में आ सकते हैं, लेकिन वे ज़्यादा जोखिम भरे हैं।
- कई टिप्पणियाँ सामान्य “AI startups” का मज़ाक उड़ाती हैं, जैसे कहना “हम एक Python startup हैं” या “web3 startup” हैं, लेकिन कोई स्पष्ट समस्या नहीं बताई जाती।
प्लेटफ़ॉर्म जोखिम और OpenAI पर रैपिंग
- OpenAI के ऊपर पतली wrappers बनाने को लेकर कड़ा डर है कि इनका कोई moat नहीं होता और इन्हें OpenAI खुद या प्रतिस्पर्धी आसानी से कमज़ोर कर सकते हैं या कॉपी कर सकते हैं।
- कुछ लोग शुरुआती “API wrappers” को सीखने के एक स्वीकार्य चरण और अनुभव व उपयोगकर्ता हासिल करने का तरीका मानते हैं, भले ही पहला उत्पाद बाद में बाधित हो जाए।
- इस बात पर ज़ोर दिया गया है कि अगर आप API और customer दोनों के मालिक नहीं हैं, तो आप मूलतः किराये पर काम कर रहे हैं और “निकाले” जा सकते हैं।
Toolchains, Fine-tuning, और Model Choices
- विशेषीकृत models और “normal code” बनाने की लेख की सलाह को व्यापक रूप से पसंद किया गया, लेकिन कुछ लोगों का मानना है कि कई टीमों के लिए compilers/toolchains बनाना ज़रूरत से ज़्यादा है।
- fine-tuning पर असहमति है: कुछ इसे आवश्यक differentiation मानते हैं; अन्य इसे messy data के कारण अव्यावहारिक मानते हैं और few-shot prompting, function calling, और RAG को प्राथमिकता देते हैं।
- इस पर संदेह है कि छोटी टीमें custom models बनाए रख सकती हैं, क्योंकि frontier models तेज़ी से सुधर रही हैं और अंदरूनी काम को अप्रासंगिक बना सकती हैं।
Product Strategy: Problem-First बनाम Tech-First
- user needs, workflows, और UX से शुरू करने के लिए मज़बूत समर्थन है, न कि “AI product” को एक category मानकर।
- “solutions in search of a problem” बनाने के ख़िलाफ़ बार-बार चेतावनी दी गई है, जिसकी तुलना पहले की blockchain/web3 लहरों से की गई।
- कुछ लोगों का तर्क है कि ढेर सारे तेज़ MVPs बनाना (भले ही tech-driven हों) technologists के लिए असली समस्याएँ खोजने का एक वैध तरीका हो सकता है।
Chatbots और User Experience
- कई लोग support chatbots को नापसंद करते हैं, उन्हें ऐसे filters मानते हैं जो सशक्त humans तक पहुँच रोकते हैं।
- अन्य लोगों ने कुछ bots के साथ अच्छे अनुभव बताए हैं (जैसे e-commerce refunds, internal triage) और उम्मीद करते हैं कि LLMs chat UX को काफ़ी बेहतर बनाएँगे।
- व्यापक सहमति है कि bots तभी मूल्यवान हैं जब वे वास्तव में कुछ कर सकें (plans बदलना, refunds जारी करना), सिर्फ़ FAQs दोहराना नहीं—लेकिन यह security और prompt-injection चिंताओं से टकराता है।
Latency, Performance, और MVP Trade-offs
- इस पर बहस है कि multi-minute LLM runs स्वीकार्य हैं या नहीं: background या handoff workflows के लिए ठीक, लेकिन tight interactive loops के लिए बहुत धीमे।
- कुछ लोग भारी upfront engineering (custom compilers, toolchains) को premature optimization मानते हैं जो उपयोगकर्ताओं से सीखने में देरी करता है; अन्य इसे commodity “boring ChatGPT wrappers” से बचने के लिए आवश्यक मानते हैं।
Data, Privacy, और Self-Hosting
- कुछ enterprises reportedly OpenAI-based products को मना करते हैं, लेकिन बेहतर control या on-prem deployment का वादा करने वाले startups के साथ काम करने को तैयार होते हैं।
- अन्य लोग तर्क देते हैं कि privacy की चिंताएँ अत्यधिक हैं, क्योंकि प्रमुख cloud SaaS का enterprise उपयोग व्यापक है, और custom hosting बहुत उच्च scale पर ही लागत में OpenAI से बेहतर होती है।
Hype Cycles और Differentiation
- AI की तुलना अक्सर Kubernetes या blockchain जैसी पिछली hype waves से की जाती है; पोस्ट करने वाले इस बात पर असहमत हैं कि अंततः इसका प्रभाव कितना परिवर्तनकारी होगा।
- इस पर सहमति है कि differentiation किसी ऐसी चीज़ से आनी चाहिए जिसे कॉपी करना कठिन हो—गहरी workflow समझ, data, UX, या integration—not सिर्फ़ “we use LLMs”.