کافی عرصے تک مجھے یقین نہیں تھا کہ اس ویب سائٹ کو بلاگ کی ضرورت بھی ہے یا نہیں۔
میں پہلے ہی اپنے کام کا زیادہ تر وقت مسائل حل کرنے میں گزارتا ہوں۔ کچھ عام frontend یا backend کے کام ہوتے ہیں۔ کچھ بہت محدود اور مخصوص ہو جاتے ہیں: image encoding، browser behavior، SEO experiments، infrastructure failures، AI-assisted development، media processing، یا کوئی عجیب production مسئلہ جو ایک سادہ سوال سے شروع ہو کر کئی دن کی تحقیق بن جاتا ہے۔
اس سب کے بعد مزید چند ہزار الفاظ لکھنا غیر ضروری محسوس ہو سکتا ہے۔
اسے پڑھے گا کون؟
مجھے اس سے ملے گا کیا؟
مسئلہ حل کر کے آگے کیوں نہ بڑھ جاؤں؟
آخرکار مجھے ایک جواب ملا جو میرے لیے کافی تھا: اس کام کا کچھ حصہ اتنی محنت سے حاصل ہوتا ہے کہ اسے ضائع کرنا مناسب نہیں۔
ایک مشکل مسئلہ میرے احساس ہونے سے پہلے پوری تحریر بن سکتا ہے
میری تحریریں عموماً اس خیال سے شروع نہیں ہوتیں کہ “اس ہفتے مجھے ایک بلاگ پوسٹ لکھنی ہے۔”
وہ ایک مسئلے سے شروع ہوتی ہیں۔
کبھی وہ میرے کام سے آتا ہے۔ کبھی میرے اپنے کسی پروجیکٹ سے۔ اور کبھی کوئی ایسی چیز مجھے دلچسپ لگتی ہے جسے میں سمجھتا نہیں، پھر میں اس وقت تک کھوج کرتا رہتا ہوں جب تک اسے کہیں بہتر نہ سمجھ لوں۔
Image processing میرے لیے ایسے بہت سے گہرے سلسلوں کا ذریعہ رہا ہے۔
شروع میں کام تقریباً مضحکہ خیز حد تک سادہ لگ سکتا ہے:
ان تصاویر کو لے کر چھوٹا کر دو۔
آپ کسی AI model سے اس کے لیے script مانگ سکتے ہیں اور تقریباً فوراً ایک script مل جائے گا۔
اس کا مطلب یہ نہیں کہ آپ کے پاس اچھا image-processing pipeline ہے۔
پہلا ورژن JPEG، PNG، WebP اور animated content کے فرق کو نظر انداز کر سکتا ہے۔ وہ ہر چیز کے لیے ایک ہی quality value استعمال کر سکتا ہے۔ تصاویر کو بلاوجہ upscale کر سکتا ہے۔ transparency غلط سنبھال سکتا ہے۔ وہ metadata برقرار رکھ سکتا ہے جسے آپ ہٹانا چاہتے تھے، یا وہ metadata ختم کر سکتا ہے جسے آپ بچانا چاہتے تھے۔ وہ visual damage کو ناپے بغیر صرف file size کم کرنے پر توجہ دے سکتا ہے۔ دس test files پر بالکل درست کام کر کے کہیں بڑے scale پر بہت مہنگی غلطی ثابت ہو سکتا ہے۔
ایک script کا کامیابی سے چل جانا اور ایک ایسا system جس پر میں بھروسا کرتا ہوں، ایک ہی چیز نہیں۔
میری بہت سی تحریریں اسی فرق سے نکلتی ہیں۔
میرا AI workflow صرف “ChatGPT سے پوچھو اور جواب لے لو” سے کہیں زیادہ سست ہے
اس طرح کے مسائل پر کام کرتے ہوئے میں اپنے paid ChatGPT account کو بہت زیادہ استعمال کرتا ہوں۔
ایک ہی conversation کئی دن یا ہفتوں تک چل سکتی ہے۔ میں سوال پوچھتا ہوں، تجاویز test کرتا ہوں، نتائج واپس دیتا ہوں، assumptions کو challenge کرتا ہوں، code دیکھتا ہوں، کوئی نیا edge case ڈھونڈتا ہوں، implementation بدلتا ہوں، دوبارہ چلاتا ہوں، نتائج کا موازنہ کرتا ہوں اور یہی عمل دہراتا ہوں۔
خاص طور پر گہری investigations میں ایک ہی عمومی مسئلے کے گرد 100 گھنٹے سے زیادہ کام جمع ہو چکا ہے۔
اس کا مطلب یہ نہیں کہ میں 100 گھنٹے کسی AI model کے جادوئی طور پر جواب دریافت کرنے کا انتظار کرتا ہوں۔
یہ عمل iterative ہے۔
ایک عام sequence کچھ یوں ہوتا ہے:
- میں مسئلہ بیان کرتا ہوں۔
- Model ابتدائی حل تجویز کرتا ہے۔
- میں اسے حقیقی data پر چلاتا ہوں۔
- کچھ کمزور، غیر مؤثر یا سیدھا غلط نکلتا ہے۔
- میں evidence واپس conversation میں لاتا ہوں۔
- ہم approach بدلتے ہیں۔
- میں دوبارہ test کرتا ہوں۔
- ایک اور edge case سامنے آتا ہے۔
- پھر یہی عمل۔
یہ cycle کئی بار دہرائی جا سکتی ہے۔
فائدہ مند نتیجہ اکثر پہلا script نہیں ہوتا۔ اصل نتیجہ اس کے گرد جمع ہونے والی failures، measurements، corrections اور decisions کا مجموعہ ہوتا ہے۔
AI نے ابتدائی حل بنانا سستا کر دیا۔ Verification سستی نہیں ہوئی
یہ ایک وجہ ہے کہ میں AI سے لکھی جانے والی technical content کے بارے میں عام بحث کو حد سے زیادہ سادہ سمجھتا ہوں۔
ہاں، AI model بہت تیزی سے ایک بظاہر معقول tutorial بنا سکتا ہے۔
وہ ایسا code بھی بنا سکتا ہے جو دیکھنے میں مکمل طور پر مناسب ہو مگر بالکل انہی حالات میں غلط ہو جہاں درست ہونا سب سے اہم ہے۔
تنگ اور مشکل technical مسائل میں مجھے شاذ و نادر ہی پہلا قابل قبول جواب چاہیے ہوتا ہے۔ میں جاننا چاہتا ہوں کہ اسے حقیقت میں چلانے پر کیا ہوتا ہے۔
اگر میں image pipeline بنا رہا ہوں تو output size اور visual quality دیکھنا چاہتا ہوں۔ مختلف source formats کے ساتھ کیا ہوتا ہے، یہ جاننا چاہتا ہوں۔ غیر معمولی dimensions، alpha، animations اور corrupt inputs کو test کرنا چاہتا ہوں۔ میں یہ سمجھنا چاہتا ہوں کہ implementation کن assumptions پر کھڑا ہے۔
اگر script آخرکار بہت بڑے collection پر چلنا ہے تو یہ کام اور بھی اہم ہو جاتا ہے۔
دس ملین تصاویر جان بوجھ کر ایک انتہائی مثال ہے؛ یہ میرے کسی مخصوص dataset میں دس ملین تصاویر ہونے کا دعویٰ نہیں۔ مگر مسئلہ اچھی طرح واضح ہوتا ہے: ایک چھوٹی systematic mistake اگر دس ملین مرتبہ دہرائی جائے تو پھر وہ چھوٹی نہیں رہتی۔
Code generate کرنے کی لاگت بہت کم ہو گئی ہے۔
یہ طے کرنے کی لاگت کم نہیں ہوئی کہ وہ code scale پر چلانے کے قابل ہے یا نہیں۔
Chat تحقیق کا مواد ہے، مکمل مضمون نہیں
ایسی طویل investigations کے بعد chat history میں غیر معمولی مقدار میں معلومات جمع ہو سکتی ہیں۔
ان میں شامل ہو سکتا ہے:
- ناکام approaches؛
- وہ code جو بعد میں بدل دیا گیا؛
- مفید benchmark results؛
- logs؛
- غلط فہمیاں؛
- corrections؛
- غیر واضح behavior کی explanations؛
- مختلف alternatives کا موازنہ؛
- وہ edge cases جن کے بارے میں ابتدا میں نہیں سوچا تھا؛
- اور آخر میں وہ rules جن پر میں نے اعتماد کرنا شروع کیا۔
یہ سب کچھ ایک private conversation میں چھوڑ دینا مجھے ضیاع لگتا ہے۔
اس لیے میں مفید حصے نکال کر انہیں ایک مضمون میں تبدیل کرتا ہوں۔
مضمون conversation کا transcript نہیں ہے۔ Conversation کا زیادہ تر حصہ کبھی مضمون بننا بھی نہیں چاہیے۔
ایک مفید technical article کو ایک اضافی مرحلہ چاہیے: ایسے dead ends ہٹانا جو کچھ نہیں سکھاتے، ایسے dead ends رکھنا جو کوئی اہم چیز واضح کرتے ہیں، claims verify کرنا، chronology دوبارہ بنانا، observation اور explanation الگ کرنا، اور نتیجے کو ایسا بنانا جسے دوسرا developer حقیقت میں استعمال کر سکے۔
یہ editing step اہم ہے۔
AI اس میں حصہ لے سکتا ہے، مگر evidence پھر بھی اصل کام سے آتا ہے۔
Image processing نے مجھے دکھایا کہ ایک “سادہ” مسئلہ کتنا گہرا ہو سکتا ہے
Image optimization شاید میرے اپنے کام کی سب سے واضح مثال ہے۔
میں نے اس پر اتنا وقت لگایا ہے کہ جو چیز شروع میں صرف چند encoder settings لگتی تھی، رفتہ رفتہ ایک کہیں بڑا systems problem بن گئی۔
سوال بہت جلد بڑھ جاتے ہیں۔
میں کس source format کے ساتھ کام کر رہا ہوں؟
کیا وہ animated ہے؟
کیا dimensions بدلنے چاہئیں؟
Quality کیسے چنوں؟
کون سا metric طے کرے کہ quality loss قابل قبول ہے یا نہیں؟
کیا ایک quality threshold بالکل مختلف تصاویر پر چل سکتا ہے؟
Upscaling سے کیسے بچوں؟
کون سا metadata باقی رہنا چاہیے؟
Transparency کے ساتھ کیا ہوگا؟
Output کو کیسے validate کیا جائے؟
کیا چھوٹی file واقعی اضافی encoding cost کے قابل ہے؟
Input population بدلنے پر کیا ہوگا؟
اسی لیے میں پانچ سطروں والے “ultimate image optimization” scripts پر شک کرتا ہوں۔
وہ یقیناً ایک تصویر process کر سکتے ہیں۔
یہ ایک ایسے pipeline سے مختلف بات ہے جس کے compromises آپ واقعی سمجھتے ہوں۔
میرے موجودہ image-heavy workloads میں AVIF عموماً وہ format ہے جسے میں پہلے آزمانا چاہتا ہوں۔ یہ میرے پروجیکٹس کی نوعیت پر مبنی rule ہے، یہ دعویٰ نہیں کہ دنیا کی ہر website کو کل ہی تمام پرانے formats ختم کر دینے چاہئیں۔ Compatibility requirements، source material، latency، encoder cost اور delivery architecture جواب بدل سکتے ہیں۔
دلچسپ بات کسی ایک format کو فاتح قرار دینا نہیں۔
دلچسپ بات workload کو اتنا سمجھنا ہے کہ فیصلہ جان بوجھ کر کیا جا سکے۔
میں video processing میں بھی اسی گہرائی تک جانا چاہتا ہوں۔ ابھی وہاں نہیں پہنچا۔ یہی ان موضوعات کی دلچسپی کا حصہ ہے: جب بھی لگتا ہے کہ کسی مسئلے کی تہہ تک پہنچ گیا ہوں، ایک اور تہہ سامنے آ جاتی ہے۔
پھر ایک جاپانی سائٹ نے بلاگ ڈھونڈ لیا
میں ان مضامین کو شائع کر کے کسی خاص فائدے کی توقع نہیں کر رہا تھا۔
اس بلاگ سے مجھے کوئی معنی خیز مالی فائدہ نہیں ہوتا۔ میں یہ اس لیے کرتا ہوں کہ مجھے یہ process پسند ہے اور میں نہیں چاہتا کہ مفید کام پرانے chats اور terminal history میں غائب ہو جائے۔
پھر ایک ایسی چیز ہوئی جس کی مجھے واقعی توقع نہیں تھی۔
17 ستمبر 2026 کو جاپانی سائٹ Levtech Freelance نے ایک roundup شائع کیا جس کے عنوان کا مفہوم تقریباً “اپنی مہارت بہتر بنانے کے خواہش مند انجینئرز کے لیے تجویز کردہ بلاگز” تھا۔
Levtech Freelance کا مضمون JSVar کو کئی دوسرے engineering blogs کے ساتھ شامل کرتا ہے۔
Levtech جاپان کے ایک بڑے IT-career ecosystem کا حصہ ہے، جبکہ Levtech Freelance freelance IT engineers کی مدد اور انہیں projects سے match کرنے پر توجہ دیتا ہے۔ میرے لیے دلچسپ بات صرف backlink ملنا نہیں تھی۔ زیادہ دلچسپ یہ دیکھنا تھا کہ ایک بیرونی editorial team نے میرے کام کے کن حصوں کو بیان کرنے کے قابل سمجھا۔
JSVar کے بارے میں ان کے حصے میں خاص طور پر تین مضامین نمایاں کیے گئے۔
ایک مضمون اس بارے میں تھا کہ production development میں مجھے Codex اور TypeScript ایک دوسرے کے ساتھ کیوں مؤثر لگے، خاص طور پر اس لیے کہ TypeScript کے types اور compiler feedback generated code کی غلطیاں جلد سامنے لا سکتے ہیں۔
دوسرا مضمون ChatGPT کے ذریعے بلاگ کو 20 زبانوں میں ترجمہ کرنے اور مختلف ممالک سے search visitors کے براہ راست localized pages پر آنے کے بارے میں تھا۔
تیسرا 10,000 AI-generated SEO pages شائع کرنے کا میرا تجربہ تھا، جو آخرکار آسان growth کے بجائے failure کی کہانی بن گیا۔
یہ selection مجھے دلچسپ لگی کیونکہ یہ تینوں مضامین بہت مختلف ہیں، مگر ان میں ایک چیز مشترک ہے۔
وہ کسی ایسی چیز پر مبنی ہیں جو میں نے حقیقت میں کی۔
مجھے بالکل معلوم نہیں کہ Levtech نے مجھے کیسے ڈھونڈا
یہاں ایک بہت پرکشش اور صاف ستھری کہانی بنائی جا سکتی ہے۔
میں جاپانی نہیں بولتا۔
میری site کا جاپانی version موجود ہے۔
ایک جاپانی engineering publication نے site ڈھونڈ لی۔
لہٰذا بلاگ کو جاپانی میں translate کرنے کی وجہ سے Levtech نے مجھے ڈھونڈا۔
میں یہ ثابت نہیں کر سکتا۔
ممکن ہے جاپانی pages نے مدد کی ہو۔
ممکن ہے search انہیں کسی English article تک لے گئی ہو۔
ممکن ہے کسی نے link share کیا ہو۔
ممکن ہے وہ site تک کسی بالکل مختلف راستے سے پہنچے ہوں۔
میرے پاس اس attribution کا data نہیں، اس لیے میں اس سے ایک صاف SEO case study گھڑنے والا نہیں ہوں۔
جس بات کی میں تصدیق کر سکتا ہوں وہ کہیں سادہ ہے: میں نے بلاگ متعدد زبانوں میں شائع کیا، اور بعد میں ایک جاپانی publication نے اسے اپنی editorial roundup میں شامل کرنے کے قابل سمجھا۔
یہ خود ایک اچھا نتیجہ ہے۔
یہ اس لیے بھی خوش کن ہے کہ localization بھی ایک ایسا experiment تھا جو شروع میں بہت محنت اور غیر یقینی فائدے والا لگتا تھا۔
یہ ذکر میرے لیے اہم تھا کیونکہ یہ ایک آزاد validation تھا
یہاں “validation” سے میرا مطلب یہ نہیں کہ Levtech نے ثابت کر دیا کہ میری لکھی ہوئی ہر بات درست ہے۔
انہوں نے میرے codebase کا audit نہیں کیا اور ہر experiment دوبارہ نہیں چلایا۔
اہم بات اس سے زیادہ محدود تھی۔
دنیا کے دوسرے حصے میں، ایسی زبان کے audience کے لیے لکھنے والے لوگوں نے جس میں میں خود براہ راست بات نہیں کر سکتا، میرے کام میں اتنی قدر دیکھی کہ اسے اپنے قارئین کے لیے summarize کیا۔
میں نے انہیں pitch نہیں کیا تھا۔
میں نے وہ اصل مضامین Levtech کے لیے نہیں لکھے تھے۔
مجھے جاپانی roundup میں شامل ہونے کی توقع نہیں تھی۔
اسی وجہ سے یہ نتیجہ میرے لیے معنی رکھتا ہے۔
اس سے مجھے لگتا ہے کہ ایک بہت narrow technical article کو شائع ہونے کے قابل ہونے کے لیے لازماً بہت بڑی audience کی ضرورت نہیں۔
اسے صحیح قاری کے لیے مفید ہونا چاہیے۔
کیا ایک developer کو 2026 میں بلاگ شروع کرنا چاہیے؟
میرے لیے جواب ہاں ہے — مگر ایک اہم شرط کے ساتھ۔
آپ کے پاس واقعی کچھ ایسا ہونا چاہیے جسے آپ لکھنا چاہتے ہوں۔
میں صرف اس لیے technical blog شروع کرنے کا مشورہ نہیں دوں گا کہ کسی نے کہا ہے ہر developer کو “personal brand” چاہیے۔
میں passive income کی توقع میں بھی شروع نہیں کرتا۔
اور صرف ان technologies کے generic explanations سے بھرنے کے لیے بھی نہیں جن کی documentation پہلے ہی بہتر موجود ہے۔
لیکن اگر آپ کا کام بار بار ایسی معلومات پیدا کرتا ہے جن کے بارے میں آپ سوچتے ہیں کہ کاش شروع کرتے وقت یہ مل جاتیں، تو بات مختلف ہے۔
انہیں لکھیں۔
وہ عجیب production failure لکھیں۔
وہ optimization لکھیں جس میں توقع سے تین دن زیادہ لگ گئے۔
وہ benchmark لکھیں جس نے آپ کی assumption غلط ثابت کر دی۔
وہ approach لکھیں جو خوبصورت لگتی تھی مگر ناکام ہو گئی۔
Final implementation لکھیں، مگر یہ بھی واضح کریں کہ obvious implementation کافی کیوں نہیں تھی۔
یہ وہ حصے ہیں جنہیں generic knowledge سے مصنوعی طور پر بنانا مشکل ہوتا ہے۔
AI مجھے لکھنے کے لیے کم نہیں، زیادہ مواد دیتا ہے
AI نے مجھے یہ نہیں سوچنے پر مجبور کیا کہ technical blogs غیر ضروری ہو گئے ہیں۔
میرے لیے تقریباً اس کے برعکس ہوا ہے۔
میں زیادہ ideas investigate کر سکتا ہوں کیونکہ initial implementation یا explanation پہلے سے کہیں تیزی سے مل جاتی ہے۔
لیکن تیز iteration زیادہ evidence بھی پیدا کرتی ہے: زیادہ variants، زیادہ logs، زیادہ benchmarks، زیادہ failed attempts اور زیادہ چیزیں جنہیں check کرنا پڑتا ہے۔
یہ raw material تبھی valuable بنتا ہے جب کوئی یہ طے کرنے کا کام کرے کہ کیا درست ہے اور کیا اہم۔
500 messages پر مشتمل AI conversation خودبخود knowledge نہیں بن جاتی۔
ایک script جو حقیقی testing کے بعد آخرکار قائم رہتا ہے، اور اس کے ساتھ ان 20 versions کی explanation جو قائم نہیں رہے، knowledge بن سکتی ہے۔
میں اپنے بلاگ میں یہی فرق محفوظ کرنا چاہتا ہوں۔
Publishing وہ طریقہ ہے جس سے میں مفید کام کو غائب ہونے سے روکتا ہوں
Technical work کا بڑا حصہ حیرت انگیز حد تک عارضی ہوتا ہے۔
ایک مشکل bug ٹھیک ہو جاتا ہے۔
Terminal بند ہو جاتا ہے۔
Deployment کامیاب ہو جاتا ہے۔
Chat history میں نیچے چلا جاتا ہے۔
چھ ماہ بعد شاید مجھے بھی یاد نہ رہے کہ final implementation بالکل اسی طرح کیوں بنا تھا۔
لکھنا یہ بدل دیتا ہے۔
یہ مجھے مجبور کرتا ہے کہ evidence موجود ہوتے ہوئے reasoning دوبارہ بناؤں۔
یہ کسی چیز کو searchable بنا دیتا ہے۔
یہ میرے اپنے مستقبل کے کام کے لیے reference بن جاتا ہے۔
اور کبھی کبھار، بظاہر، یہ ایسے شخص تک بھی پہنچ جاتا ہے جس کی مجھے توقع نہیں ہوتی — حتیٰ کہ ایسی زبان کی engineering publication تک جسے میں بولتا بھی نہیں۔
میرے پاس اب بھی اس بلاگ کو جاری رکھنے کی کوئی بہت sophisticated وجہ نہیں۔
مجھے سیکھنا پسند ہے۔
مجھے چیزیں بنانا پسند ہے۔
مجھے ان مسائل میں ضرورت سے زیادہ گہرائی تک جانا پسند ہے جو شروع میں سادہ لگتے ہیں۔
اور جب میں کسی مفید جواب تک پہنچنے میں درجنوں، کبھی 100 گھنٹے سے بھی زیادہ لگا چکا ہوں، تو اب میں نہیں چاہتا کہ وہ جواب کسی chat window کے اندر مر جائے۔
میرے لیے اسے شائع کرنے کی یہی وجہ کافی ہے۔
اگر آپ کا کام بھی اسی طرح کی مشکل سے حاصل شدہ knowledge پیدا کرتا ہے، تو شاید آپ کے لیے بھی یہی وجہ کافی ہو۔