২০২৫ সালের আমার GitHub contribution graph দেখলে মনে হয় যেন দুইজন আলাদা developer কাজ করেছে। বছরের প্রথমার্ধ প্রায় ফাঁকা। দ্বিতীয়ার্ধে আছে ৪,০০০-এর বেশি commit।
হঠাৎ করে আমার হাতে বেশি সময় চলে আসেনি। full-time job-এর সঙ্গে side project চালানো আগের মতোই ছিল। বদলেছিল idea আর working version-এর মাঝের friction: আমি AI coding tool অনেক বেশি সিরিয়াসভাবে ব্যবহার শুরু করেছিলাম।
তবে সংখ্যাটাকে ঠিকভাবে ব্যাখ্যা করা জরুরি। Commit count নিজে কোনো productivity metric নয়। ৪,০০০ commit মানেই ৪,০০০টা meaningful improvement নয়, আর code ভালো ছিল—সেটাও প্রমাণ করে না। কিন্তু graph একটা সত্যিকারের পরিবর্তন দেখায়: আগের তুলনায় আমি অনেক বেশি নিয়মিতভাবে build, iterate এবং working version ship করছিলাম।
আসল bottleneck ছিল experiment শুরু করার খরচ
Side project-এ একই সমস্যা বারবার দেখেছি: প্রথম useful version-এর আগে অনেক routine কাজ থাকে। Routing, validation, script, test, configuration আর cleanup—এসবই idea-টা আসলে worth it কি না বোঝার আগেই momentum খেয়ে ফেলতে পারে.
আগে setup কয়েকটা evening নেবে মনে হলে অনেক experiment পিছিয়ে দিতাম। AI coding tool কাজটা সরিয়ে দেয়নি, কিন্তু first pass-এর cost কমিয়েছে এবং testable version-এ দ্রুত পৌঁছাতে সাহায্য করেছে.
তাই আমার কাছে সবচেয়ে বড় লাভ faster typing নয়। আসল লাভ ছিল কম activation energy: আরও বেশি idea বাস্তবে test করার পর্যায়ে পৌঁছাতে শুরু করল.
আমার Node.js workflow কীভাবে বদলেছিল
আমি development process-কে chat window দিয়ে replace করিনি। Node.js side-project work-এ DeepSeek-কে narrowly scoped task-এর জন্য second pair of hands হিসেবে ব্যবহার করেছি: first implementation draft করা, unfamiliar code পড়া, test প্রস্তাব করা, stack trace ব্যাখ্যা করা, refactor-কে ছোট step-এ ভাঙা আর deployment assumption review করা.
- Scaffolding: handler, validation, script বা test-এর boring first version.
- Code reading: edit করার আগে request বা value কোথায় transform হচ্ছে তা trace করা.
- Refactoring: review করা সহজ এমন ছোট mechanical change.
- Debugging: log থেকে একাধিক hypothesis তৈরি করা.
- Verification: happy path কাজ করার পরে edge case ও regression test খোঁজা.
Input, output, constraint আর existing convention যত পরিষ্কার ছিল, result তত দ্রুত verify করা যেত। Vague task অনেক বেশি plausible-looking কিন্তু ভুল abstraction তৈরি করত.
তাই AI output-কে final answer নয়, candidate patch হিসেবে দেখেছি। Type check, test, build আর real flow ছিল evidence.
DeepSeek কোথায় সবচেয়ে সাহায্য করেছে — আর কোথায় করেনি
DeepSeek আমার জন্য useful ছিল কারণ concrete programming task-এ বারবার ব্যবহার করা practical ছিল। First pass নেওয়া, error ফেরত দেওয়া, scope ছোট করা এবং iterate করা দ্রুত হয়ে গিয়েছিল.
এটাকে আমি benchmark বলছি না। প্রতিটি competing model-এর বিরুদ্ধে controlled study করিনি, আর model lineup দ্রুত বদলায়। আমি শুধু এতটুকুই বলতে পারি: DeepSeek আমার workflow-এর সঙ্গে যথেষ্ট ভালো fit করেছিল যে আমি AI assistance অনেক বেশি frequently ব্যবহার করতে শুরু করি.
Clear function, test এবং real error থাকলে এটি সবচেয়ে শক্তিশালী ছিল। Unstated product context বা subtle architecture trade-off দরকার হলে এটি দুর্বল ছিল। Fluent answer তখন ভুল assumption-কে finished solution-এর মতো দেখাতে পারে.
AI experimentation-এর cost বদলে দিয়েছে
সবচেয়ে বড় পরিবর্তনটা “AI code লেখে, তাই development automatic” ছিল না। বরং অনেক ছোট কাজ এতটাই সস্তা হয়ে গিয়েছিল যে চেষ্টা করা সম্ভব হচ্ছিল। আগে যে side-project feature-কে অনেক setup মনে হতো, এখন idea-টা নিয়ে আগ্রহ থাকা অবস্থাতেই 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 version, fixed programming task, repository snapshot, prompt, raw output, elapsed time, accepted/rejected patch, review time, test result এবং rework record করতে হবে.
Commit count-এর বাইরে idea থেকে verified version পর্যন্ত সময়, defect, rollback এবং rewritten work-ও মাপতে হবে। এই context ছাড়া ৪,০০০ commit activity ও behavior change-এর evidence, software quality-এর proof নয়.
আমার জন্য কী বদলেছিল
২০২৫ ছিল সেই বছর যখন আমি প্রতিটি side project-কে setup-এর বিশাল পাহাড় হিসেবে দেখা বন্ধ করি, যেটা পুরোপুরি হাতে পার হতে হবে। AI প্রথম working version-কে এতটাই cheap করেছিল যে আমি আরও বেশি বার সেই stage-এ পৌঁছাতে পারতাম যেখানে আসল product decision গুরুত্বপূর্ণ হয়ে ওঠে।
এই কারণেই GitHub graph-এর দ্বিতীয়ার্ধ এত আলাদা দেখায়। AI আমাকে দিনে বেশি ঘণ্টা দেয়নি, এবং প্রতিটি generated line-ও ভালো ছিল না। এটি শুধু সেই friction কমিয়েছে, যেটা আগে idea-কে বাস্তব হওয়ার আগেই মেরে ফেলত।
২০২৬ সালে আমার focus equation-এর কম glamorous অংশে: workflow refine করা, quality আরও সিরিয়াসভাবে measure করা এবং নিশ্চিত হওয়া যে faster development শুধু বেশি commit নয়, আরও ভালো software তৈরি করছে।