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 لازماً اچھا تھا۔ البتہ graph میرے working pattern میں حقیقی تبدیلی دکھاتا ہے: میں پہلے کے مقابلے میں زیادہ مستقل طور پر build، iterate اور working versions ship کر رہا تھا۔
اصل bottleneck experiment شروع کرنے کی energy تھی
Side projects میں ایک ہی مسئلہ بار بار سامنے آیا: پہلی useful version اکثر routine کام کی دیوار کے پیچھے ہوتی ہے۔ Routing، validation، scripts، tests، configuration اور cleanup idea کو واقعی test کرنے سے پہلے momentum ختم کر سکتے ہیں۔
پہلے اگر first working version کئی شاموں کے setup جیسی لگتی تو میں experiment مؤخر کر دیتا۔ 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 کو محدود 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: بڑے change کو چھوٹے reviewable diffs میں تقسیم کرنا.
- Debugging: logs سے کئی hypotheses بنانا.
- Verification: happy path کے بعد edge cases اور regression tests تلاش کرنا.
Inputs، outputs، constraints اور existing conventions جتنے واضح ہوں، 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 میں بار بار استعمال کے لیے practical تھا۔ میں first pass لے سکتا تھا، کچھ حصہ reject کر سکتا تھا، real error واپس دے سکتا تھا، scope کم کر کے تیزی سے iterate کر سکتا تھا۔
میں اسے benchmark نہیں کہتا۔ میں نے ہر competing model کے خلاف controlled study نہیں کی اور model lineups تیزی سے بدلتے ہیں۔ درست دعویٰ اتنا ہے: 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 ہو گئی ہے۔” اصل فرق یہ تھا کہ بہت سے چھوٹے حصے اتنے cheap ہو گئے کہ انہیں try کرنا مناسب لگنے لگا۔ side-project feature جو پہلے بہت زیادہ setup محسوس ہوتا تھا، اب اس وقت prototype بن سکتا تھا جب idea میں میری دلچسپی ابھی باقی تھی۔
یہ فرق اہم ہے۔ 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 کو حقیقت بننے سے پہلے ختم کر دیا تھا۔
2026 میں میری توجہ equation کے کم glamorous حصے پر ہے: workflow کو refine کرنا، quality کو زیادہ سنجیدگی سے measure کرنا، اور یہ یقینی بنانا کہ faster development صرف زیادہ commits نہیں بلکہ بہتر software پیدا کرے۔