ब्लॉग पर वापस जाएं
2 अप्रैल 2026Sergei Solod3 मिनट पढ़ें

मैं Codex Plus के आखिरी 3–5% को सबसे बड़े इंजीनियरिंग कामों के लिए क्यों बचाकर रखता हूँ

मेरे workflow में एक छोटे बदलाव ने Codex Plus इस्तेमाल करने का तरीका बदल दिया: limit खत्म होने के करीब हो तो मैं छोटे prompt नहीं, बल्कि सबसे भारी technical काम शुरू करता हूँ।

Codex Plusएआई कोडिंग टूलडेवलपर वर्कफ़्लोसॉफ़्टवेयर इंजीनियरिंगTypeScript माइग्रेशनESLint क्लीनअपरिफैक्टरिंगउत्पादकता

Codex Plus के साथ मैंने जो सबसे दिलचस्प workflow pattern देखा है, वह prompt कैसे लिखा जाए उससे कम, और timing से ज़्यादा जुड़ा है।

जब मैं अपने 5-घंटे या साप्ताहिक limit के आखिरी 3–5% पर पहुंचता हूँ, तब मैं उस बचे हुए हिस्से को छोटे requests पर खर्च नहीं करता। मैं ठीक उल्टा करता हूँ। मैं उस बचे हुए budget का इस्तेमाल उन सबसे बड़े engineering tasks को शुरू करने में करता हूँ जिन्हें मैं पहले से तैयार projects पर चला सकता हूँ।

इसका मतलब अक्सर ऐसे काम होते हैं: पूरा TypeScript migration, पूरे repository में ESLint cleanup, पूरी codebase में deep bug review, या बड़े refactor जो सामान्य समय में शुरू करने के लिए बहुत महंगे लगते हैं।

क्या चीज़ मेरे workflow को बदल गई

कारण सीधा है। एक से ज़्यादा बार मैंने देखा है कि visible limit खत्म होती हुई दिखने के बाद भी Codex काम जारी रखता है। बाहर से session खत्म हुई लगती है, लेकिन task आगे बढ़ता रहता है और कभी-कभी पूरा भी हो जाता है।

मैं इसे product की कोई guaranteed rule नहीं कह रहा। मैं बस एक बार-बार दिखे अनुभव का वर्णन कर रहा हूँ, जिसने मेरा behavior बदल दिया। जब से मैंने यह pattern नोटिस किया, तब से आखिरी कुछ प्रतिशत मुझे बचाकर रखने वाली चीज़ नहीं लगे। वे मुझे सबसे high-leverage काम शुरू करने का सही समय लगने लगे।

अब मैं आखिरी हिस्सा कैसे इस्तेमाल करता हूँ

पहले की तरह safe और low-cost prompts पर आखिरी usage खर्च करने के बजाय, अब मैं इसे heavy engineering operations शुरू करने की window मानता हूँ। जैसे:

  • पूरा TypeScript migration
  • repository-wide ESLint cleanup
  • बड़ी codebase में deep bug review
  • बड़े structural refactor

यहाँ सबसे ज़रूरी चीज़ preparation है। यह तरीका तब सबसे उपयोगी होता है जब project पहले से execution के लिए तैयार हो और task साफ़ तौर पर defined हो। उस point पर बचे हुए हिस्से को किसी छोटी चीज़ पर खर्च करना अक्सर बेकार लगता है।

मुझे यह महत्वपूर्ण क्यों लगता है

Codex Plus जैसे tools सिर्फ raw capability के बारे में नहीं हैं। यह भी मायने रखता है कि आप effort को समय के हिसाब से कैसे distribute करते हैं। timing में छोटा सा बदलाव भी उसी limit से मिलने वाली practical value बदल सकता है।

मेरे लिए इसने product की psychology ही बदल दी। आखिरी कुछ प्रतिशत अब session का अंत नहीं लगते। वे उस moment जैसे लगते हैं जब मुझे हिचकिचाना छोड़कर सबसे भारी काम tool को सौंप देना चाहिए।

कभी-कभी सच में ऐसा लगता है कि visible limit खत्म होने के बाद भी Codex मेरे लिए काम करता रहता है। यह कोई intentional edge case है या सिर्फ कुछ tasks के व्यवहारिक रूप से पूरा होने का तरीका, यह मैं नहीं जानता। लेकिन यह इतना उपयोगी रहा है कि अब मैं अपना workflow इसी के आसपास plan करता हूँ।

डेवलपर्स के लिए एक practical takeaway

अगर आप software engineering के लिए Codex Plus इस्तेमाल करते हैं, तो शायद अपने end-of-limit workflow को खुद test करना सही रहेगा। यह मान लेना ज़रूरी नहीं कि आखिरी कुछ प्रतिशत हमेशा बहुत सावधानी से खर्च होने चाहिए। मेरे मामले में इसका उल्टा ज़्यादा असरदार रहा।

मुझे सच में जानने में दिलचस्पी होगी कि क्या दूसरे developers ने भी यही pattern देखा है, खासकर migrations, lint cleanup, बड़े reviews, या कई repositories में फैले refactors के दौरान।