काम पर मैं बहुत से vibe coders के साथ काम करता रहा हूँ, और इसी से मैं maintenance के बारे में सोचने लगा। Ship करने के बाद भी software की देखभाल करनी पड़ती है, packages पुराने हो जाते हैं और vulnerabilities मिलती रहती हैं, और जब आप AI से बनाना शुरू ही कर रहे हों तो इन बातों पर ध्यान न जाना आसान है।
फिर मुझे समझ आया कि यही सोच मुझे अपने projects पर भी लागू करनी चाहिए, तो मैंने उनकी git history देखी। मुझे काफ़ी कुछ मिला, हालाँकि वह नहीं जिसकी मुझे उम्मीद थी, और उनमें से एक चीज़ उस दिन भी खुली हुई थी जिस दिन मैंने देखा।
तो अब यह post इस बारे में नहीं है कि दूसरे लोग क्या भूल जाते हैं। यह मेरे बारे में है।
एक advisory, तीन apps
14 अक्टूबर को Next.js ने दो critical और एक high-severity vulnerability के fixes जारी किए। यहाँ "critical" का मतलब है remote code execution, यानी कुछ स्थितियों में internet पर कोई अनजान व्यक्ति बिना login किए आपके server पर अपना code चला सकता था। Fix version 16.4.1 में आया।
मेरे तीन apps Next.js पर चलते हैं, तीनों AI coding tools से बने हैं और तीनों की ज़िम्मेदारी एक ही व्यक्ति पर है, यानी मुझ पर। यह हुआ:
| App | Code कब patched version पर गया | Advisory के कितने दिन बाद | Production में live |
|---|---|---|---|
| chandlernguyen.com | 18 अक्टूबर | 4 दिन | 18 अक्टूबर |
| DIALØGUE | 29 अक्टूबर | 15 दिन | 29 अक्टूबर |
| Prova | 3 नवंबर | 20 दिन | 3 नवंबर |
3 नवंबर को जब मैंने देखा, Prova अब भी Next.js 16.2.6 पर locked था, वही version जिस पर वह मई से था, और production में वही चल रहा था। pnpm audit --prod चलाने पर 5 critical advisories दिखीं, सभी Next.js में।
यह संख्या मुझे मिली असल स्थिति से ज़्यादा बुरी लगती है, इसलिए मैं निष्पक्ष रहना चाहता हूँ। जब मैंने अपने AI tools के साथ एक-एक को जाँचा, तो ज़्यादातर critical advisories Prova पर लागू नहीं होती थीं। उसमें कोई use cache function नहीं है, वह Windows पर नहीं चलता, और मुझे ऐसा कोई attacker-controlled input नहीं मिला जो next/og code तक पहुँचता हो। Image optimization वाली advisories शायद Vercel पर भी लागू नहीं होतीं, हालाँकि यह platform के व्यवहार से निकाला गया अनुमान है, क्योंकि मुझे Vercel का ऐसा कोई बयान नहीं मिला। जो साफ़ तौर पर लागू थी, वह Server Actions में एक high-severity denial of service समस्या थी, यानी कोई app में रुकावट डाल सकता था, और यह patch होने तक बनी रही।
मैंने उसी दिन production को Next.js 16.4.5 पर ले जाया। Audit 5 critical से 0 पर आ गया, और ज़्यादातर high-severity भी हट गईं। जो बचा है वह Next.js के बाहर है और उसे मुझे अभी निपटाना है, तो स्थिति बेहतर है पर साफ़ नहीं।
इसमें से किसी को भी मैं अच्छा maintenance नहीं कह सकता। सबसे बुरी advisories ज़्यादातर इसलिए Prova से बच निकलीं क्योंकि वह संयोग से उस तरह बना है, इसलिए नहीं कि किसी ने जाँचा था। यह किस्मत है, और मुझे इसका पता सिर्फ़ इसलिए है क्योंकि आखिरकार मैंने देखा।
पहली row का भी मैं ज़्यादा श्रेय नहीं ले सकता। मेरी site का 18 अक्टूबर का commit एक सामान्य toolchain upgrade था, Next.js 16.1.6 से, और उसके message में advisory का ज़िक्र नहीं है। हो सकता है यह बस अच्छी timing रही हो।
व्यस्त रहने से मदद क्यों नहीं मिली
आसान व्याख्या यह होगी कि Prova की अनदेखी हुई थी, और इसमें कुछ सच्चाई है। अगस्त और सितंबर में उसके commits के बीच 41 दिन का अंतर था।
लेकिन अक्टूबर में यह व्याख्या टूट जाती है। उस महीने Prova में 175 commits हुए। मैंने iOS, billing, email और translations के fixes ship किए, और Next.js version नहीं हिला। 30 अक्टूबर को तो मैंने उसके लिए dependency maintenance plan भी लिखा। उसकी status line कहती है: "planned; implementation शुरू नहीं हुआ।"
तो activity maintenance नहीं है, और मुझे लगता है AI से बनाने वाले हर व्यक्ति के लिए यही सबसे ज़रूरी बात है। जब आप कोई feature बनाते हैं, तो आपको तुरंत feedback मिलता है। आप button देख सकते हैं, उस पर click कर सकते हैं और उसे चलते देख सकते हैं। जब पाँच महीने पहले install किए package में कोई vulnerability घोषित होती है, तो आपको कुछ नहीं मिलता। App pages serve करता रहता है, tests green रहते हैं और build pass होता है। कुछ टूटा नहीं है, और ठीक इसी वजह से कोई देखता नहीं।
यह ऐसे smoke alarm जैसा है जो तभी बजता है जब आप जाकर उससे पूछें। AI tools घर बनाना बहुत सस्ता कर देते हैं। वे alarm नहीं लगाते।
मेरे साथ यह पहले भी हुआ है। 6 अक्टूबर 2025 से 11 जनवरी 2026 के बीच DIALØGUE में कोई commit नहीं हुआ। React2Shell, Next.js और React की एक critical vulnerability, दिसंबर की शुरुआत में सार्वजनिक हुई। मेरा patch commit 11 जनवरी का है, पाँच हफ़्ते से भी ज़्यादा बाद, और सबसे पुराना production deployment record जो मैं अब भी देख सकता हूँ वह 18 जनवरी का है, इसलिए मैं ठीक-ठीक नहीं बता सकता कि दिसंबर में क्या चल रहा था। शायद सबसे ज़्यादा मदद उस चीज़ से मिली जिसका मुझसे कोई लेना-देना नहीं था: Vercel का कहना है कि उसने अपने सभी customers के लिए firewall rules लागू किए, और साथ ही साफ़ कहा कि patch करने की जगह उन पर भरोसा न करें।
एक बात मैं साफ़ कर देना चाहता हूँ, क्योंकि "vibe coder" शब्द अपमान जैसा लग सकता है। मैंने structured courses से coding सीखी, जिनमें एक cybersecurity certificate भी शामिल है, इन repos में tests और review gates हैं, और फिर भी यह हुआ। इसलिए मुझे नहीं लगता कि यह beginners की समस्या है। मुझे लगता है कि जब software बनाना सस्ता हो जाए और उस पर नज़र रखने की ज़िम्मेदारी किसी को न दी जाए, तो default रूप से यही होता है।
Alarm कैसा दिखता है
अच्छी खबर यह है कि एक बहुत छोटा check इसमें काफ़ी कुछ बदल देता है।
27 अक्टूबर को मैंने अपनी site की CI में pnpm audit --prod जोड़ा, यानी checks का वह automatic set जो code push होने पर चलता है। 28 अक्टूबर को वह fail हो गया, एक email rendering library की advisory की वजह से जिसे मेरी site साथ ला रही थी पर कभी इस्तेमाल नहीं करती थी, और 29 अक्टूबर को मैंने वह library हटा दी। इसमें दो दिन लगे और मुझे कुछ याद नहीं रखना पड़ा।
इसमें कुछ भी चतुराई वाला नहीं था। बस किसी को, या किसी चीज़ को, देखने का काम सौंपना होता है।
Packages update करने से मैं नहीं बचता
अगर यह post यहीं रुक जाता, तो आपको झूठी तसल्ली मिलती, क्योंकि अक्टूबर में मैंने जो कुछ ज़्यादा असहज fixes किए, उनका पुराने packages से कोई लेना-देना नहीं था। वे मेरे अपने product की गलतियाँ थीं।
उदाहरण के लिए, DIALØGUE में:
- Privileged database functions सिर्फ़ public key से call किए जा सकते थे, और logged-in user उन functions तक पहुँच सकता था जो सिर्फ़ मेरे backend के लिए थे।
- Refund हुआ podcast फिर से ज़िंदा होकर दोबारा charge हुए बिना पूरा हो सकता था, और थोड़े-से podcasts के साथ ऐसा हुआ भी।
Prova में, public database roles को ऐसी permissions विरासत में मिली थीं जिन्हें किसी ने नहीं चुना था, जैसे TRUNCATE, क्योंकि वे platform के default से आई थीं। App का कोई path उनका इस्तेमाल नहीं करता था, पर वे मौजूद थीं।
कोई version upgrade इनमें से कुछ ठीक नहीं करता। ये apps इन समस्याओं के साथ चल रहे थे, और यहाँ भी कुछ नहीं टूटा। ये सिर्फ़ इसलिए सामने आईं क्योंकि एक security review इन्हें ढूँढने गया, और मैं इन products पर पहले भी security reviews कर चुका था जो इन सबको नहीं पकड़ पाए।
क्या इनमें से किसी का दुरुपयोग हुआ? मुझे नहीं पता, और मैं पूरी तरह पता भी नहीं लगा सकता। मेरे database logs सिर्फ़ करीब 90 दिन पीछे तक जाते हैं, और इनमें से कुछ समस्याएँ उससे पुरानी हैं। जितनी अवधि मैं देख सकता हूँ, उसमें मुझे उन functions पर बाहर से कोई call नहीं मिला। यह एक सीमित अवधि है और इससे यह साबित नहीं होता कि कुछ नहीं हुआ। मैं यह भी नहीं बता सकता कि उन refunded podcasts को किसने या किस चीज़ ने दोबारा शुरू किया, हालाँकि मेरा सबसे अच्छा अनुमान मेरे अपने code का कोई retry है।
यह सूची भी पूरी नहीं है। मैं अभी कुछ और समस्याओं पर काम कर रहा हूँ, और जब तक वे खुली हैं, मैं उनका वर्णन नहीं करूँगा।
Model का सवाल वह नहीं निकला जो मैंने सोचा था
मुझे लगा था कि मैं लिखूँगा कि पुराने AI models ज़्यादा महँगे पड़ते हैं। मैं इसे साबित नहीं कर सकता। मैंने देखा, और इनमें से किसी repo में पहले और बाद की लागत का हिसाब नहीं है, तो यह बस अंदाज़ा होगा।
मुझे जो मिला वह ज़्यादा अजीब है। DIALØGUE के script-draft और review models 12 अक्टूबर तक gemini-3.5-flash पर set थे। Google के documentation में अब लिखा है कि वह endpoint बंद नहीं हो रहा और requests अपने आप gemini-3.6-flash पर route करता है। मुझे नहीं पता कि यह routing कब शुरू हुई, इसलिए मैं नहीं बता सकता कि कौन सा model कितने समय तक जवाब दे रहा था। आपकी config में लिखा model का नाम उस model को एक ही जगह टिकाकर नहीं रखता।
कीमतें भी बदलती हैं। Gemini 3.8 Flash, जिस पर मैंने अक्टूबर में Prova और DIALØGUE को ले जाया, 31 दिसंबर तक $0.75 प्रति मिलियन input tokens और $3.75 प्रति मिलियन output tokens पर listed है। 1 जनवरी 2027 से यह दोगुना होकर $1.50 और $7.50 हो जाता है। मैं पिछले महीने ही इस पर गया हूँ, और मुझे अभी हिसाब लगाना है कि इससे मेरी लागत पर क्या असर पड़ेगा।
Upgrade करना भी जोखिम से खाली नहीं है, और मैं ऐसा दिखावा नहीं करना चाहता:
- Ask Sydney को DeepSeek Flash पर ले जाने के कुछ ही समय बाद, production में कम से कम एक सवाल fail हुआ क्योंकि model को मेरे code की अनुमति से ज़्यादा search rounds चाहिए थे।
- जब मैंने Prova के embeddings migrate किए, तो knowledge base table खाली होने के बाद शुरुआती runs fail हो गए, इसलिए जब तक मैंने उसे वापस नहीं लाया, retrieval कमज़ोर रहा।
- उसी migration में एक production setting सामने आई जो Google की API को Claude model का नाम भेज देती।
Prova के migration को भरोसेमंद बनाने वाली चीज़ उबाऊ थी। मेरे पास बदलाव से पहले का एक recorded evaluation था, 24 में से 22 sprint review फ़ैसले सही, और बाद में भी मुझे वही score मिला। उसके बिना मैं बस उम्मीद ही कर रहा होता।
क्या आपको इसे maintain करना भी चाहिए?
सबसे मुश्किल सवाल वह है जिसे मैं लगभग छोड़ ही गया था। आपका ship किया हर app एक छोटा subscription है जिसे आपको अपने ध्यान से चुकाते रहना होता है, और AI ने और subscriptions लेना बहुत आसान कर दिया है।
STRAŦUM के साथ मैंने दूसरा रास्ता चुना। मैंने उसे retire किया और v1 को reference implementation के रूप में publish किया। Repository कहती है कि इसे production service के रूप में maintain नहीं किया जाता, और उसकी security file में वे advisories दर्ज हैं जिनकी मुझे जानकारी है, जिनमें build-time dependency की वे समस्याएँ भी हैं जिनका कोई fix उपलब्ध नहीं है और जिन्हें वह कम व्यावहारिक जोखिम मानती है। मुझे लगता है यह पूरी तरह ईमानदार नतीजा है। बेईमान रूप वह app है जो अब भी signups ले रहा है जबकि उस पर कोई नज़र नहीं रख रहा।
मैं सोमवार को क्या करूँगा
अगर आपने AI से कुछ ship किया है और लोग उसे इस्तेमाल कर रहे हैं, तो मैं इस सूची से शुरू करूँगा। इसमें से कुछ भी perfect होना ज़रूरी नहीं।
- Audit एक बार चलाइए, आज ही।
npm audit --omit=devयाpnpm audit --prod, हर उस repo में जो live है। फिर अपने AI tool से पूछिए कि कौन से नतीजे आपके app की बनावट पर लागू होते हैं, क्योंकि सभी नहीं होंगे। - उस check को automatic बनाइए। उसे CI में जोड़िए ताकि वह आपके याद रखे बिना fail हो सके। जिस app को आप कम छूते हैं, उसके लिए scheduled run भी रखिए, क्योंकि सिर्फ़ push पर चलने वाला check शांत महीने में काम नहीं आएगा।
- अपनी permissions पढ़िए, सिर्फ़ packages नहीं। पूछिए कि कोई सिर्फ़ आपकी public key से, बिना account के, क्या कर सकता है। फिर मान लेने के बजाय उसे local copy पर test कीजिए।
- अपनी history में secrets खोजिए। अगर कभी कोई असली key commit हुई थी, तो उसे revoke कीजिए। Line हटाना काफ़ी नहीं है।
- ज़रूरत पड़ने से पहले पता कीजिए कि आपके logs कितने पीछे तक जाते हैं। इसी से तय होता है कि आप कभी इस सवाल का जवाब दे पाएँगे या नहीं कि किसी चीज़ का दुरुपयोग हुआ।
- हर AI feature के लिए एक छोटा evaluation रखिए। अच्छे जवाबों वाले 20 असली उदाहरण भी बता देंगे कि model बदलने से चीज़ें बिगड़ीं या नहीं।
- अपने AI provider के deprecation और pricing pages तय समय पर देखिए। इसे calendar में डालिए। अगर आप Gemini 3.8 Flash इस्तेमाल करते हैं, तो 1 जनवरी शुरुआत के लिए अच्छी तारीख है।
- हर app के लिए तय कीजिए: रखना है या retire करना है। अगर आप उस पर नज़र नहीं रखेंगे, तो उसे हटा दीजिए या साफ़ कह दीजिए।
मैं अभी पता लगा रहा हूँ कि इसमें से कितना किसी agent को schedule पर सौंपा जा सकता है। इतना ज़रूर जानता हूँ कि 30 अक्टूबर को plan लिखने से कुछ patch नहीं हुआ।
अगर आप AI से बना रहे हैं, तो आपने आखिरी बार कब किसी ship की हुई चीज़ की जाँच की, और आपको क्या मिला? मैं सच में जानना चाहूँगा, ख़ासकर अगर आपके पास मुझसे बेहतर alarm है।