2025 का मेरा GitHub contribution graph ऐसा दिखता है जैसे वह दो अलग developers का हो। साल का पहला आधा हिस्सा लगभग खाली है। दूसरे हिस्से में 4,000 से ज़्यादा commits हैं।
मुझे अचानक ज़्यादा खाली समय नहीं मिला था। मैं अब भी full-time job के साथ side projects संभाल रहा था। बदला था idea और working version के बीच का friction: मैंने AI coding tools को कहीं ज़्यादा गंभीरता से इस्तेमाल करना शुरू किया।
उस संख्या को सही संदर्भ में रखना जरूरी है। Commit count अपने आप में productivity metric नहीं है। चार हज़ार commits यह साबित नहीं करते कि मैंने चार हज़ार उपयोगी improvements किए या code की quality अच्छी थी। लेकिन graph एक असली बदलाव दिखाता है: मैं पहले की तुलना में कहीं ज़्यादा लगातार build, iterate और working versions ship कर रहा था।
असली bottleneck experiment शुरू करने की energy थी
Side projects में एक ही समस्या बार-बार दिखी: पहली useful version अक्सर routine काम की दीवार के पीछे होती है। Routing, validation, scripts, tests, configuration और cleanup idea को test करने से पहले ही momentum खा सकते हैं।
पहले मैं ऐसे experiments टाल देता था जिनका पहला working version कई शामों के setup जैसा लगता था। AI coding tools ने काम खत्म नहीं किया, लेकिन first pass की cost कम कर दी और testable version तक जल्दी पहुँचने दिया।
इसलिए सबसे बड़ा फायदा faster typing नहीं था। असली फायदा कम activation energy था: ज्यादा ideas उस stage तक पहुँचे जहाँ मैं असली evidence इकट्ठा कर सकता था।
मेरा Node.js workflow कैसे बदला
मैंने development process को chat window से replace नहीं किया। Node.js side-project work में DeepSeek को narrowly scoped tasks के लिए second pair of hands की तरह इस्तेमाल किया: first implementation draft करना, unfamiliar code पढ़ना, tests सुझाना, stack trace समझना, बड़े refactor को छोटे steps में बाँटना और deployment assumptions review करना।
- Scaffolding: handlers, validation, scripts या tests की boring first version.
- Code reading: edit से पहले request या value का path trace करना.
- Refactoring: बड़े बदलाव को छोटे reviewable diffs में तोड़ना.
- Debugging: logs से कई hypotheses बनाना.
- Verification: happy path के बाद edge cases और regression tests ढूँढना.
Inputs, outputs, constraints और existing conventions जितने clear होते, result उतना आसान verify होता। Vague task ज्यादा बार plausible लेकिन गलत abstraction बनाती थी।
इसलिए AI output मेरे लिए final answer नहीं, candidate patch था। Type checking, tests, build और real flow evidence थे; confident explanation नहीं।
DeepSeek ने कहाँ सबसे ज्यादा मदद की — और कहाँ नहीं
DeepSeek concrete programming tasks में repeated use के लिए practical था। मैं first pass ले सकता था, एक हिस्सा reject कर सकता था, real error वापस दे सकता था, scope छोटा कर सकता था और जल्दी iterate कर सकता था।
मैं इसे benchmark नहीं कहता। मैंने हर competing model के खिलाफ controlled study नहीं की और model lineups तेजी से बदलते हैं। Defensible claim इतना है: DeepSeek मेरे workflow में इतना अच्छा fit हुआ कि मैंने AI assistance कहीं ज्यादा frequently इस्तेमाल करना शुरू किया।
Function, tests और real error होने पर यह सबसे मजबूत था। Unstated product context या subtle architecture trade-offs पर यह कमजोर था। ऐसे मामलों में fluent answer गलत assumption को finished solution जैसा दिखा सकता है।
AI ने experimentation की cost बदल दी
सबसे बड़ा सुधार “AI code लिखता है, इसलिए development automatic हो गया” नहीं था। कई छोटे हिस्से बस इतने सस्ते हो गए कि उन्हें try करना संभव लगने लगा। side-project feature जो पहले बहुत ज्यादा setup जैसा लगता था, अब idea में interest रहते हुए prototype बन सकता था।
यह फर्क महत्वपूर्ण है। AI ने testable version तक पहुँचने की cost कम की। उसने architecture, product judgment, deployment या correctness को गायब नहीं किया। generated implementation गलत हो सकती है; successful build runtime में fail कर सकता है; deployed prototype फिर भी खराब product हो सकता है।
मेरे लिए practical फायदा momentum था। एक बार पूरा system काम करता दिख जाता, तो उसे refine करते रहना बहुत आसान हो जाता।
एक मजबूत benchmark को क्या चाहिए
Reproducible benchmark के लिए exact model versions, fixed programming tasks, repository snapshots, prompts, raw outputs, elapsed time, accepted/rejected patches, review time, test results और rework record करना होगा।
Commits के अलावा idea से verified version तक का समय, defects, rollbacks और rewritten work भी मापना चाहिए। इस context के बिना 4,000 commits activity और behavior change का evidence हैं, software quality का proof नहीं।
मेरे लिए क्या बदला
2025 वह साल था जब मैंने हर side project को setup का ऐसा पहाड़ मानना बंद किया जिसे मुझे पूरी तरह हाथ से चढ़ना है। AI ने पहली working version को इतना cheap बना दिया कि मैं ज्यादा बार उस stage तक पहुँच सका जहाँ असली product decisions महत्वपूर्ण होते हैं।
इसीलिए मेरे GitHub graph का दूसरा हिस्सा इतना अलग दिखता है। इसलिए नहीं कि AI ने दिन में और घंटे जोड़ दिए, और न इसलिए कि हर generated line अच्छी थी। उसने उस friction को कम किया जिसने पहले ideas को real बनने से पहले खत्म कर दिया था।
2026 में मेरा focus equation के कम glamorous हिस्से पर है: workflow refine करना, quality को ज्यादा गंभीरता से measure करना और यह सुनिश्चित करना कि faster development सिर्फ ज्यादा commits नहीं, बल्कि बेहतर software पैदा करे।