कुछ साल पहले 15 software projects को एक साथ गंभीरता से review करने का विचार मुझे अवास्तविक लगता। मेरा मतलब 15 repositories खोलकर ऊपर-ऊपर देखना नहीं है। मेरा मतलब real projects को बार-बार bugs, गलत assumptions, SEO issues, translation mistakes, localization inconsistencies, missing tests, regressions और ऐसे पुराने code के लिए जांचना है जो अब system के बाकी हिस्से से match नहीं करता।
सीमा कभी typing speed नहीं थी। सीमा attention थी। हर project की अपनी history, conventions, edge cases और ऐसा code होता है जो गलत दिखता है लेकिन जानबूझकर वैसा ही रखा गया है। Careful review में पढ़ना, search करना, compare करना, checks चलाना और फिर तय करना शामिल है कि वास्तव में क्या बदलना चाहिए।
Codex ने मेरे लिए इस repetitive work की economics बदल दी। यह repository पर first pass कर सकता है, references follow कर सकता है, related files inspect कर सकता है, suspicious patterns surface कर सकता है, tests suggest कर सकता है और उन areas की जांच में मदद कर सकता है जिन्हें मैं पहले manually एक-एक करके खोलता। Final decision automatic नहीं होती। Decision से पहले वाली expensive investigation बहुत तेज हो जाती है।
मेरी सबसे महत्वपूर्ण rule सरल है: मैं Codex का उपयोग खुद को review loop से हटाने के लिए नहीं करता। मैं अपने review loop का scope बढ़ाने के लिए करता हूँ।
असल bottleneck coding नहीं, repetition है
एक project maintain करते समय आप बहुत context याद रख सकते हैं। कई projects के साथ यह scale नहीं करता। वही प्रकार के काम बार-बार आते हैं:
- अलग components में similar bugs ढूंढना;
- देखना कि refactor के बाद पुराना call site बचा तो नहीं;
- behavior changes के बाद tests review करना;
- metadata, language logic, headings या internal links में inconsistencies ढूंढना;
- localization keys और translated content compare करना;
- missing error handling और edge cases ढूंढना;
- देखना कि “small” change ने अपेक्षा से ज्यादा files तो नहीं छुए;
- ऐसे diffs पढ़ना जो individually simple हैं लेकिन कुल मिलाकर बहुत समय लेते हैं।
इनमें कुछ glamorous नहीं है। सब महत्वपूर्ण हैं। और जब यही review कई codebases पर repeat करना पड़े तो cost बहुत बढ़ जाती है।
यहीं AI coding agent मेरे लिए सबसे उपयोगी है। यह search space के repetitive हिस्से को consume करता है ताकि मैं judgment पर ज्यादा attention दे सकूँ।
मैं inspection से शुरू करता हूँ, सब कुछ rewrite करने की permission से नहीं
खराब result पाने का आसान तरीका है कहना: “पूरे project को review करो और सब ठीक कर दो।” यह efficient लगता है, लेकिन discovery, prioritization, architecture, implementation और validation को एक uncontrolled task में मिला देता है।
Stages अलग करने पर result काफी बेहतर होता है।
inspect → explain findings → prioritize → change → validate → review diffपहले मैं चाहता हूँ agent relevant area समझे और बताए कि उसने क्या पाया। मुझे concrete file paths, affected code, suspicious होने का कारण और likely impact चाहिए। Changes उसके बाद आते हैं।
यह महत्वपूर्ण है क्योंकि AI बहुत confidence के साथ गलत हो सकता है। Redundant दिखने वाला code पुराने browser, payment edge case, migration path या ऐसे business rule के लिए हो सकता है जो एक file से समझ नहीं आता। Inspection गलत assumption को giant diff बनने से पहले रोक देती है।
मैं findings को verdict नहीं, leads मानता हूँ
अच्छा Codex review “17 problems मिले” पर खत्म नहीं होता। Number अकेला लगभग बेकार है। मुझे evidence चाहिए।
Actionable finding के लिए मैं जानना चाहता हूँ:
- problem कहाँ है;
- क्यों problem है;
- कौन सा behavior fail हो सकता है;
- conclusion पर कितना confidence होना चाहिए;
- कौन सा check इसे confirm या reject कर सकता है;
- सबसे छोटा safe fix क्या है।
यह security, SEO और business logic में खास तौर पर महत्वपूर्ण है। Agent investigation के लायक जगह दिखा सकता है, लेकिन security जैसी भाषा vulnerability prove नहीं करती। SEO warning automatic ranking problem नहीं है। Strange condition automatic dead code नहीं है।
AI candidate ढूंढने की cost घटाता है। Reality verification तय करती है।
Validation loop workflow को trustworthy बनाता है
Code generation AI-assisted development का visible हिस्सा है, लेकिन production में usefulness validation से आती है।
Change के बाद मैं चाहता हूँ codebase जवाब दे। Project के हिसाब से इसमें शामिल हो सकता है:
- TypeScript या दूसरा compiler/type checker;
- lint;
- unit और integration tests;
- build checks;
- पुराने names या call sites के लिए targeted search;
- final diff की manual review;
- user-facing behavior की manual verification.
Exact commands से ज्यादा loop महत्वपूर्ण है। Agent assumption बनाता है, repository evidence लौटाता है, अगला decision evidence पर होता है।
इसीलिए AI-assisted work में strongly typed projects मुझे पसंद हैं। मैंने अलग article में बताया है कि TypeScript real software delivery में Codex के साथ इतना अच्छा क्यों काम करता है: types कई गलत assumptions को तुरंत machine-readable feedback में बदल देते हैं।
कुछ review categories AI के लिए खास तौर पर अच्छी हैं
Bugs और regressions
Agent value को files के across follow कर सकता है, callers inspect कर सकता है, similar implementations compare कर सकता है और inconsistent branches ढूंढ सकता है। इससे symptom की source narrow करना आसान होता है। Conclusion accept करने से पहले मैं behavior reproduce या verify करता हूँ।
Tests
AI changed behavior without matching test coverage ढूंढने, edge cases suggest करने और existing test क्या protect करता है समझाने में useful है। यह उन tests को भी surface कर सकता है जो real behavior की जगह implementation detail test करते हैं।
SEO
Technical SEO में consistency work बहुत है: metadata, language alternates, indexability, internal links, templates, sitemap generation, redirects और page-level conventions. Agent बड़े codebase में ये rules हर route manually खोलने से तेज compare कर सकता है। लेकिन technical correctness और content खुद rank करने लायक है या नहीं — ये अलग सवाल हैं।
Localization और translations
Multilingual product में यह सबसे repetitive areas में से एक है। AI keys compare कर सकता है, missing values ढूंढ सकता है, wrong language detect कर सकता है, placeholders check कर सकता है और locale structure drift highlight कर सकता है। बड़े translation objects manually scan करने से बहुत तेज है, हालांकि important copy को human judgment चाहिए।
Refactoring के बाद consistency
Large refactors boring तरीकों से fail होते हैं: पुराना import बच जाता है, एक route पुराने field name पर रहती है, test fixture old shape use करता है। Repository-wide search और change intent समझने वाला agent यहाँ बहुत useful है।
Parallel work तभी मदद करता है जब tasks independent हों
बहुत agents start करके सबको एक साथ changes करने देना tempting है। Throughput बढ़ सकता है, लेकिन conflicts और inconsistent assumptions भी multiply हो सकते हैं।
मैं parallelism को coordination problem मानता हूँ। Independent audits अच्छे candidates हैं: एक project localization के लिए check हो सकता है जबकि दूसरा tests के लिए review हो, या अलग repositories साथ inspect हों। Shared plan के बिना एक architecture दो agents से rewrite कराना अलग चीज है।
जितना parallel work, उतनी boundaries important: clear project, clear task, clear definition of done और separately reviewable result.
Goal maximum agents चलाना नहीं है। Goal useful, verifiable progress maximize करना है।
क्या मैं blindly delegate नहीं करता
- Architecture decisions: model options दे सकता है, लेकिन long-term trade-offs repo के बाहर के context पर depend कर सकते हैं।
- Security conclusions: findings को verification, threat context और अक्सर specialized tooling चाहिए।
- Business rules: code internally consistent होकर भी गलत product behavior implement कर सकता है।
- Large destructive refactors: huge diff समझना कठिन और careless approve करना आसान है।
- Production deployment: passing tests operational risk खत्म नहीं करते।
- Final review: अपने नाम से change ship करने से पहले मैं जानना चाहता हूँ क्या बदला।
इसलिए नहीं कि AI इन क्षेत्रों में useless है, बल्कि इसलिए कि plausible गलत answer यहाँ बहुत expensive हो सकता है।
AI review static analysis का replacement नहीं है
मैं Codex को compiler, linter, test, scanner या monitoring का replacement नहीं मानता। इन tools का फायदा है जो AI के पास नहीं: narrow, deterministic, repeatable.
Strongest workflow इन्हें combine करता है। Codex context पर reason करके बताता है कहाँ देखना चाहिए। Static tools precise rules enforce करते हैं। Tests behavior verify करते हैं। Logs और monitoring reality दिखाते हैं। Human review इन signals को product intent से जोड़ता है।
इन feedback systems के बिना मैं AI पर ज्यादा नहीं, कम trust करूँगा।
सबसे बड़ा productivity gain attention का बेहतर allocation है
“Codex time save करता है” कहना आसान है, लेकिन मेरे लिए यह change को कम करके बताता है।
Software development में scarce resource keystroke नहीं, high-quality attention है। AI coding agents से पहले बहुत attention repetitive discovery में जाता था: वही patterns search करना, similar files पढ़ना, references follow करना, change हर जगह पहुँचा या नहीं check करना और दूसरे repository में वही audit repeat करना।
अब मैं ज्यादा first-pass work delegate कर सकता हूँ और attention difficult decisions के लिए रख सकता हूँ: finding important है? fix architecture में fit करता है? UX improve होती है? risk acceptable है? क्या मैं सच में इसे ship करना चाहता हूँ?
इसीलिए कई projects maintain और review करना अब अलग लगता है। मैं कम review नहीं करता। कई cases में ज्यादा कर पाता हूँ क्योंकि mechanical part पूरा budget consume नहीं करता।
Workflow जिस पर मुझे भरोसा है
- Narrow review goal define करें. Bugs, tests, SEO, localization, refactor या कोई specific concern.
- Edit से पहले agent को inspect करने दें. पहले evidence और affected locations चाहिए.
- Findings prioritize करें. हर theoretical issue code change deserve नहीं करता.
- Changes bounded रखें. छोटे coherent diffs validate करना आसान है.
- Machine checks चलाएँ. Typecheck, lint, tests, build, search या project-specific validation.
- Diff manually पढ़ें. Unnecessary rewrites, wrong assumptions, missing edge cases और scope से बाहर changes ढूंढें.
- Important behavior verify करें. खासकर users, money, security, SEO और production infrastructure.
- फिर next project पर जाएँ. Parallelism useful है लेकिन unresolved uncertainty फैलनी नहीं चाहिए.
15 projects अब 15 गुना review work जैसे नहीं लगते
Codex ने 15 projects simple नहीं किए और responsibility नहीं हटाई। उसने scale और repetitive effort के बीच relationship बदला।
मैं deeper first pass, broader consistency checks, ज्यादा test ideas और systematic audits कर सकता हूँ बिना हर file में हर minute खुद search किए। बचा attention उन decisions में जाता है जिन्हें अभी भी developer चाहिए।
यही AI-assisted development मुझे valuable लगता है: autopilot नहीं, blind trust नहीं और “कुछ pass होने तक code generate करो” नहीं। Machine-scale inspection और human-scale judgment के बीच tighter loop.
मेरे लिए यही Codex का real leverage है। यह review खत्म नहीं करता। यह serious review को उस scale पर possible बनाता है जिसे पहले maintain करना बहुत कठिन था।