যারা প্রেক্ষাপট বাজেটকে গুরুত্ব দেয়, তারা অন্যদের তুলনায় অক্ষমভাবে স্কিল জমা করার চেয়ে ভালো এআই-সহায়তা অভিজ্ঞতা পায়।

লেখক, উৎস: 0x9999in1, ME News

TL;DR

• বর্তমানে প্রধান এআই প্রোগ্রামিং সহায়কগুলির স্কিল/প্লাগইন ইকোসিস্টেম একটি "অসংগঠিত বৃদ্ধির পরের পাচার" অনুভব করছে—পুনরাবৃত্তি, অপ্রয়োজনীয়, জম্বু স্কিলের সঞ্চয়, যা মূল্যবান কনটেক্সট উইন্ডো সম্পদকে গুরুতরভাবে ক্ষতি করছে।
• লবস্টার ড্যাড একটি মেটা-স্কিল ওপেন-সোর্স করেছেন যা স্কিলের জন্য একটি "ফুল বডি চেক" প্রদান করে, যা পাঁচটি কোর ফাংশন কভার করে: বাজেট অডিট, রিপিট ডিটেকশন, ইডল স্ক্রিনিং, রুট ডিরেক্টরি অডিট, ডেসক্রিপশন রিডাকশন।
• কনটেক্সট উইন্ডো হল এআই বড় মডেলের সবচেয়ে দুর্লভ সম্পদগুলির মধ্যে একটি, প্রতিটি অপ্রয়োজনীয় স্কিলের উপস্থিতি আপনার প্রকৃত যুক্তিসঙ্গত স্থান দখল করে নেয় অর্থহীন টোকেন ব্যবহার করে।
• এই টুলের মূল মূল্য হল "আরও একটি স্কিল যোগ করা" নয়, বরং একটি স্কিল দিয়ে সব স্কিলকে পরিচালনা করা—এটি অবকাঠামো-স্তরের।
• স্কিল ইকোসিস্টেমের বিশৃঙ্খলা একটি ব্যক্তিগত ঘটনা নয়, বরং একটি কাঠামোগত সমস্যা। অডিট মেকানিজম ছাড়া প্লাগইন সিস্টেম চূড়ান্তভাবে এনট্রপি বৃদ্ধির দিকে এগিয়ে যাবে।
• ওপেন সোর্স মানে সম্প্রদায় এটির উপর ভিত্তি করে ইটারেশন করতে পারে, যা স্কিল গভর্ন্যান্সের স্ট্যান্ডার্ডাইজেশনের শুরু হতে পারে।

প্রথমে বর্তমান অবস্থা বলি: আপনার স্কিল রিপোজিটরি হয়তো এখন একটি কুঁজো হয়ে গেছে

এটা কঠিন কথা। কিন্তু আপনি আপনার এআই সহায়ক কনফিগারেশন খুলুন, কয়টা স্কিল ইনস্টল করেছেন গুনুন, এবং শেষবার কোনগুলো ব্যবহার করেছেন তা ভাবুন।

উত্তরটি সম্ভবত মৌন করে দেবে।

2025 এর দ্বিতীয় অর্ধেক থেকে, Cursor, Windsurf, Codex, Claude Code ইত্যাদি AI প্রোগ্রামিং টুলগুলি একসাথে "দক্ষতা অস্ত্রাগার প্রতিযোগিতায়" প্রবেশ করে। সম্প্রদায়ের অবদানকারীরা পাগলের মতো কন্ট্রিবিউট করছে, অফিসিয়াল ইনবিল্ট লাইব্রেরি ধারাবাহিকভাবে বড় হচ্ছে, এবং ব্যক্তিগত কনফিগারেশনগুলি স্তরে স্তরে জমা হচ্ছে।

ফলাফল কী?

একজন সাধারণ অতিমাত্রায় ব্যবহারকারীর দক্ষতার সংখ্যা সহজেই 50টির বেশি হয়ে যায়। যেগুলো দৈনন্দিনভাবে ট্রিগার হয়, সেগুলোর সংখ্যা হয়তো 10টির কম। বাকি 40টি নীরবে সেখানে শুয়ে থাকে, প্রতিবার কথোপকথন শুরু হলে এগুলোকে কনটেক্সটে লোড করা হয়, টোকেন বাজেট নিঃশব্দে খরচ করে, এবং—কিছুই করে না।

এটি ব্যয় নয়। এটি অপরাধ।

এটি কেন বলা হচ্ছে? কারণ কনটেক্সট উইন্ডো অসীম নয়। ২০২৬ সাল পর্যন্ত, প্রধান মডেলগুলির কার্যকর কনটেক্সট দৈর্ঘ্য ১২৮K থেকে ২০০K টোকেনের মধ্যে থাকবে, যা অনেক বেশি মনে হচ্ছে তাই না? কিন্তু গণনা করুন: সিস্টেম প্রম্পট, ডায়ালগ হিস্ট্রি, কোড স্নিপেট, ফাইল কনটেন্ট, টুল ডিফিনিশন, স্কিল বর্ণনা... "চিন্তা"-এর জন্য প্রকৃতপক্ষে যে জায়গা বাকি থাকে, তা আপনার কল্পনার চেয়ে অনেক কম।

প্রতিটি অপ্রয়োজনীয় স্কিলের বর্ণনা ২০০ টোকেন দখল করে, ৫০টি হলে ১০,০০০ টোকেন। এক হাজার টোকেনে মডেলটি ৪০০ লাইন কোড আরও পড়তে পারে।

এটি কেবল তাত্ত্বিক প্রস্তাবনা নয়। এটি প্রতিদিন ঘটছে।

কেন কেউ কিছু করছে না? কারণ "যোগ" করা "বিয়োগ" করার চেয়ে এক হাজার গুণ সহজ।

মানুষের মনে একটি গভীরভাবে বহন করা মানসিক বাস্তবতা রয়েছে: যোগ করার পক্ষপাত (Addition Bias)।

সমস্যার মুখোমুখি হলে, আমরা সাধারণত "কিছু যোগ করা" এর দিকে ঝুঁকি, যদিও "কিছু বাদ দেওয়া" বেশি কার্যকর হতে পারে। ২০২১ সালে ন্যাচারে প্রকাশিত একটি গবেষণা স্পষ্টভাবে দেখিয়েছে যে, মানুষ বস্তুগুলি উন্নত করার সময় সামগ্রিকভাবে "বিয়োগের সমাধান" উপেক্ষা করে, যদিও বিয়োগই বেশি কার্যকর।

স্কিল ইকোসিস্টেম এই বিষয়টি পুরোপুরি পুনরাবৃত্তি করেছে।

সম্প্রদায়ের অবদানকারী একটি নতুন স্কিল লিখেছেন, প্রকাশ করেছেন। ব্যবহারকারী মনে করলেন "হয়তো কাজে লাগবে", ইনস্টল করলেন। অফিসিয়ালরা মনে করলেন "ফাংশনের পরিধি ব্যাপক", বিল্ট-ইন করলেন।

কে মুছবে? কে অডিট করবে? কে বলবে "এই স্কিলটি ওইটির সাথে পুনরাবৃত্তি হয়েছে, একটি বাদ দিন"?

কেউ নেই।

কারণ কোনো প্রেরণা নেই মুছে ফেলার। একটি নতুন স্কিল লিখুন, যার জন্য স্টার পাবেন, কমিউনিটি দ্বারা স্বীকৃতি পাবেন, এবং আপনার রেজিউমেতে যোগ করতে পারবেন। একটি পুরনো স্কিল পরিষ্কার করুন? কিছুই পাবেন না।

এটি একটি গঠনগত দুর্বলতা। এটি প্রযুক্তিগত সমস্যা নয়, উদ্দীপনা ব্যবস্থার সমস্যা।

যতদিন না কেউ সিদ্ধান্ত নেয়: আমি ইনসেন্টিভ নিয়ে চিন্তা করছি না, এই কাজটি আমি করব।

লবস্টার ফাদার হাতে নেন: একটি স্কিল দিয়ে সব স্কিল নিয়ন্ত্রণ করুন

লবস্টার ফাদার কে? যদি আপনি AI প্রোগ্রামিং টুলস কমিউনিটির সদস্য হন, তাহলে এই আইডি আপনার জন্য অপরিচিত হবে না। কোডেক্স এবং ক্লোড ইকোসিস্টেমে দীর্ঘদিন সক্রিয় গভীর প্লেয়ার, যিনি সিস্টেমেটিক চিন্তা এবং ইঞ্জিনিয়ারিং-এর প্রতি নিখুঁততার জন্য পরিচিত। "লবস্টার ফাদার" এই উপাধিটি নিজেই কমিউনিটির স্বীকৃতি বহন করে—যেহেতু "ফাদার" উপাধি দেওয়া হয়েছে, এটি বোঝায় যে একটি নির্দিষ্ট বিশেষায়িত ক্ষেত্রে, তিনিই সেই অতিক্রমযোগ্য ব্যক্তি।

এবার তিনি যা ওপেন সোর্স করেছেন, তা মূলত একটি মেটা-স্কিল।

মেটা স্কিল বলতে কী বোঝায়? এটি "স্কিল পরিচালনার স্কিল"। এটি আপনাকে কোড লিখতে সাহায্য করে না, API ঠিক করতে সাহায্য করে না, ডকুমেন্টেশন তৈরি করতে সাহায্য করে না। এটি শুধুমাত্র একটি কাজ করে: আপনার বর্তমান সমস্ত স্কিলের জন্য একটি সম্পূর্ণ, পরিমাপযোগ্য এবং বাস্তবায়নযোগ্য চেকআপ করে।

পাঁচটি ফিচার, প্রতিটি বিশ্লেষণ করা হয়েছে।

এটি সবচেয়ে কঠোরতম।

এটি খুব সরাসরি কাজ করে: প্রতিটি Skill-এর জন্য ব্যবহৃত কনটেক্সট টোকেন স্পেস গণনা করে, প্রতিটির মোট বাজেটের শতাংশ নির্ণয় করে, এবং তারপর অপ্টিমাইজেশনের পরামর্শ দেয়।

এটি কেন গুরুত্বপূর্ণ? কারণ বেশিরভাগ ব্যবহারকারী "স্কিল কতটা সংস্থান খেয়েছে" তা সম্পূর্ণভাবে অনুভব করে না।

আপনি ভাবছেন একটি স্কিল ইনস্টল করলে শুধু একটি অতিরিক্ত ফাংশন যোগ হয়। বাস্তবে, প্রতিটি স্কিলের বর্ণনা টেক্সট, প্যারামিটার ডিফাইনিশন, উদাহরণ কোড, এবং ট্রিগার রুলস—সবকিছুই সিস্টেম প্রম্পটে যোগ করতে হয়। মডেলটি প্রতিবার রিজনিং করার সময় এই সবকিছু "পড়ে" নেয়, তারপরই সিদ্ধান্ত নেয় যে এটি কল করা উচিত কিনা।

এটা ঠিক তেমনই, যেন আপনি একটি পর্বত আরোহণের ব্যাগে ৫০টি টুল বহন করছেন। আপনি ভাবছেন "নিয়ে যাওয়া ভালো", কিন্তু প্রতিটি কিলোগ্রাম বাড়ার সাথে সাথে আপনার শারীরিক শক্তির খরচও বাড়ছে। যখন আপনি প্রকৃতপক্ষে দ্রুত দৌড়ানোর প্রয়োজন হবে, তখন আপনার কোনো শক্তি থাকবে না।

বাজেট অডিটের কাজ হলো ব্যাগটি খুলে আপনাকে বলা: "এই সুইস আর্মি কাইফটি 3 কেজি ওজন করে, কিন্তু আপনি কখনও ব্যবহার করেননি, এটি ফেলে দিন।"

এই ফিচারটি যে সমস্যার সমাধান করে, তা আপনার কল্পনার চেয়ে বেশি গুরুতর হতে পারে।

এটির স্ক্যানিং পরিধি চারটি স্তরকে কভার করে:

• কোডেক বিল্ট-ইন লাইব্রেরি
• প্লাগইন ক্যাশ
• কোড রিপোজিটরি
• ব্যক্তিগত দক্ষতা রুট

একই নাম, সদৃশ বর্ণনা এবং অতিব্যাপ্ত কার্যকারিতা সহ দক্ষতা স্তরগুলি স্ক্যান করুন এবং পুনরাবৃত্তি আইটেমগুলি চিহ্নিত করুন।

কেন পুনরাবৃত্তি হচ্ছে? অনেক কারণ আছে।

অফিসিয়ালভাবে একটি "কোড ফরম্যাটিং" স্কিল অন্তর্ভুক্ত রয়েছে, আপনি তা জানেন না, কিন্তু কমিউনিটি থেকে প্রায় একই ফাংশন সহ একটি স্কিল ইনস্টল করেছেন। দুটি স্কিল, একই কাজ করছে, দুটি বাজেট ব্যয় করছে।

অথবা আরও গোপনভাবে: আপনি ছয় মাস আগে JSON পার্সিংয়ের জন্য একটি কাস্টম স্কিল লিখেছিলেন, পরে অফিসিয়াল আপডেটে একটি ভালো সংস্করণ অন্তর্ভুক্ত করা হয়েছে। আপনার পুরনো সংস্করণটি এখনও বিদ্যমান, কিন্তু কেউ আপনাকে এটি মুছে ফেলার কথা বলেননি।

পুনরাবৃত্তি শনাক্তকরণ শুধু নাম দেখে না। নাম ভিন্ন হলেও যদি বর্ণনা অত্যন্ত সদৃশ হয়, তবে তা চিহ্নিত হবে। এটিই প্রকৃতপক্ষে প্রযুক্তিগতভাবে জটিল অংশ—এটি শুধুমাত্র স্ট্রিং মিলের চেয়ে বেশি, অর্থগত সদৃশতা তুলনা করে।

ঐতিহাসিক লগ ভিত্তিতে, দীর্ঘকাল ধরে ব্যবহার হয়নি এমন "জাম্বি স্কিল" চিহ্নিত করুন।

এই যুক্তি খুব পরিষ্কার: যদি একটি স্কিল গত ৩০ দিন, ৬০ দিন, ৯০ দিনের মধ্যে কখনও ট্রিগার না হয়ে থাকে, তাহলে সম্ভাবনা বেশি যে দুটি কিছু ঘটছে—এটি আপনার ওয়ার্কফ্লোর প্রয়োজন নয়, অথবা এর ট্রিগার শর্তগুলির ডিজাইনে সমস্যা আছে যার কারণে মডেলটি কখনও এটিকে বেছে নেয় না।

যেকোনো ক্ষেত্রে, সিদ্ধান্ত একই: এটি বাজেট বৃথা ব্যয় করছে।

এই ফিচারটি একটি "পরিষ্কারের জন্য প্রস্তাবিত তালিকা" আউটপুট দেয়। মনে রাখবেন, এটি "প্রস্তাবিত", সরাসরি মুছে ফেলা নয়। চূড়ান্ত সিদ্ধান্ত ব্যবহারকারীর হাতে। এই ডিজাইনটি খুবই সংযমী এবং বুদ্ধিমান—এটি জানে এর সীমানা কোথায়।

কিছু দক্ষতা প্রকৃতপক্ষে কম কাজে লাগে কিন্তু অত্যন্ত গুরুত্বপূর্ণ। যেমন "ডাটাবেস মাইগ্রেশন সহায়তা", আপনি সম্ভবত তিন মাসে একবার ব্যবহার করেন, কিন্তু যখন ব্যবহার করেন তখন এটি জীবনরক্ষা করে। তাই স্ক্রিনিং ফলাফলগুলি একটি রেফারেন্স, কিন্তু বিচার নয়।

এই ফিচারটি প্রায় "অপারেশনাল মেইনটেনেন্স"-এর সাথে সম্পর্কিত, কিন্তু অত্যন্ত কার্যকর।

এটি সমস্ত স্কিলের সোর্স ডিরেক্টরি গণনা করে, সক্রিয়/অক্রিয় অবস্থা চিহ্নিত করে এবং লোডিং চেইন ব্যবস্থায় রাখে।

এটি কেন প্রয়োজন? কারণ স্কিলের উৎস বিভিন্ন। কিছু গ্লোবাল কনফিগারেশন থেকে, কিছু প্রজেক্ট-লেভেল কনফিগারেশন থেকে, কিছু প্লাগইন দ্বারা অটোমেটিকভাবে ইনজেক্ট করা হয়, আবার কিছু ব্যবহারকারী দ্বারা ম্যানুয়ালি তৈরি করা হয়।

যখন দক্ষতার সংখ্যা কম থাকে, তখন আপনি জানেন। যখন এটি কয়েক দশটিতে বৃদ্ধি পায়, তখন আপনি বুঝতে পারছেন না যে "এই দক্ষতাটি কোথা থেকে এলো", "আমি কি নিরাপদে এটি মুছে ফেলতে পারি", "এটি মুছে ফেললে অন্য কিছুর উপর প্রভাব পড়বে কি না।"

রুট ডিরেক্টরি অডিট হল আপনাকে একটি মানচিত্র আঁকা। এটি আপনাকে বলবে প্রতিটি Skill কোথায় থাকে, এটিকে কে লোড করেছে, এবং এটি এখন সক্রিয় নাকি নিষ্ক্রিয়।

এই মানচিত্রটি থাকার কারণে আপনি নিরাপদে অপারেশন করতে পারবেন।

শেষ ফিচারটি সবচেয়ে ছোট মনে হলেও, প্রকৃতপক্ষে এর লিভারেজ অত্যন্ত বেশি।

এটি যা করে: অত্যধিক দীর্ঘ বর্ণনাসহ দক্ষতা চিহ্নিত করে, সংক্ষিপ্তকরণের প্রস্তাব দেয়।

কেন বর্ণনার দৈর্ঘ্য এত গুরুত্বপূর্ণ? আগের কথায় ফিরে যাই: স্কিল বর্ণনাটি সিস্টেম প্রম্পটে যোগ করা হয়। প্রতিটি শব্দই একটি টোকেন। একটি স্কিলের বর্ণনাকে ২০০ টোকেন থেকে ৮০ টোকেনে কমানো যায়, এবং স্কিলের সংখ্যা দিয়ে সেই সঞ্চয়কে গুণ করলে মোট সঞ্চয় অনেক বড় হয়ে যায়।

অনেক সম্প্রদায় অবদানকারীর দক্ষতা বর্ণনা প্রবন্ধের সারাংশের মতো—পটভূমি, উদ্দেশ্য, প্রয়োগের পরিসর, সতর্কতা, উদাহরণ ইনপুট আউটপুট, অসংখ্য। লেখক খুব ভালোভাবে চিন্তা করেছেন, কিন্তু প্রকৌশলের দৃষ্টিকোণ থেকে এটি অতিরিক্ত ডিজাইন।

মডেলের প্রয়োজনীয় বর্ণনা: সঠিক, অনন্য, পার্থক্যযোগ্য। কমপক্ষে শব্দে মডেলকে বুঝতে হবে যে "এই স্কিলটি কী করে, কখন এটি কল করা উচিত"। অতিরিক্ত প্রতিটি শব্দ হল কনটেক্সট বাজেটের বর্জ্য।

এই ফিচারটির সংক্ষিপ্ত বর্ণনা হলো যে, এটি মূলত "প্রম্পট ইঞ্জিনিয়ারিংয়ের বিপরীত অপ্টিমাইজেশন" করছে—অর্থাৎ ভালো প্রম্পট লেখার বদলে বিদ্যমান প্রম্পটগুলোকে আরও সংক্ষিপ্ত করা হচ্ছে, যাতে তথ্যের পরিমাণ কমে না।

যে কারণে এটি মূল্যবান? ফাংশন নয়, চিন্তার পদ্ধতি।

পাঁচটি ফিচার বিশ্লেষণ করা হয়েছে। প্রতিটি ফিচার আলাদাভাবে দেখলে মনে হতে পারে এগুলো "বিপ্লবী" নয়। কিন্তু এগুলো একসাথে যখন কাজ করে, তখন এটি একটি চিন্তার প্যারাডাইমের পরিবর্তনকে প্রতিনিধিত্ব করে:

"অধিক স্কিল তৈরি করা" থেকে "বিদ্যমান স্কিলগুলির পরিচালনা"।

এই বিষয়টির মূল্য কোডের পরিমাণে বা অ্যালগরিদমের জটিলতায় নয়, বরং—এখন পর্যন্ত কেউ এই সমস্যাকে "প্রথম শ্রেণীর নাগরিক" হিসাবে বিবেচনা করেনি।

গত দুই বছরে, এআই টুল ইকোসিস্টেমের মনোযোগ শুধুমাত্র "যোগ করার" দিকে ছিল। আরও বেশি মডেল, আরও বেশি ফিচার, আরও বেশি প্লাগইন, আরও বেশি স্কিল। দ্রুত দৌড়ানো, প্রচণ্ডভাবে দৌড়ানো, কেউ পিছনে ফিরে তাকায়নি।

কিন্তু যে কেউ যার ইঞ্জিনিয়ারিং অভিজ্ঞতা আছে, তারা জানেন: সিস্টেমের জটিলতা একটি নির্দিষ্ট সীমার বাইরে বাড়লে, যদি প্রাসঙ্গিক গভর্ন্যান্স মেকানিজম না থাকে, তবে এটি ধ্বংস হয়ে যাবে।

সম্ভব নয়। নিশ্চিত।

সফটওয়্যার ইঞ্জিনিয়ারিংয়ে একটি ধারণা আছে যাকে "টেকনোলজি ডেব্ট" বলা হয়। প্রতিটি অস্থায়ী সমাধান, প্রতিটি "এখন এভাবেই চলুক", প্রতিটি অপ্রয়োজনীয় কোডের অবশিষ্টাংশ ঋণ নেওয়ার মতো। যত বেশি ঋণ নেবেন, তত বেশি সুদ জমা হবে, এবং একদিন আপনি দেখবেন যে আপনার সমস্ত শক্তি ঋণ শোধ করার জন্য ব্যয় হচ্ছে, নতুন কিছু করার জন্য কোনো শক্তি বাকি নেই।

স্কিল ইকোসিস্টেমের প্রযুক্তিগত ঋণ এখন মোকাবেলা করার সময়।

লবস্টার ফাদার টুলটি মূলত একটি ঋণ অডিটর। এটি আপনার ঋণ পরিশোধে সাহায্য করে না, কিন্তু আপনাকে জানায়: আপনি কতটা ঋণ করেছেন, কোথায় ঋণ করেছেন, এবং কোন ঋণগুলি প্রথমে পরিশোধ করা উচিত।

এটি "একটি উপযোগী স্কিল আবার লেখা" এর চেয়ে অনেক বেশি মূল্যবান।

ওপেন সোর্সের অর্থ: ব্যক্তিগত টুল থেকে সম্প্রদায়ের মানদণ্ড

লবস্টার ফাদার ওপেন সোর্স করার সিদ্ধান্ত নিয়েছেন, এই সিদ্ধান্তটিই আলোচনার বিষয়।

তিনি এই টুলটিকে পেইড প্লাগইন হিসেবে তৈরি করতে পারতেন। বাজারের চাহিদা পরিষ্কার, সমস্যাগুলি বাস্তবিক, এবং পেইড ব্যবহারকারীদের সংখ্যা কম হবে না। কিন্তু তিনি ওপেন-সোর্স করার সিদ্ধান্ত নিয়েছেন।

কেন?

আমি ধারণা করি দুটি স্তরের বিবেচনা রয়েছে।

প্রথম স্তর: এই টুলটি প্রকৃতপক্ষে মূল্য তৈরি করতে, সম্প্রদায়ের সহযোগিতা প্রয়োজন। বিভিন্ন এআই প্ল্যাটফর্মের স্কিল লোডিং মেকানিজম, লগ ফরম্যাট এবং ডিরেক্টরি স্ট্রাকচার ভিন্ন। একজন ব্যক্তি এটি অ্যাডাপ্ট করতে পারবেন না, কিন্তু একশোজন অবদানকারী পারবেন।

দ্বিতীয় স্তর: তিনি শুধু একটি টুল নয়, একটি মানদণ্ড প্রচার করতে চাইতে পারেন। স্কিল গভর্নেন্স কীভাবে করা উচিত? অডিটের মাপকাঠি কী কী? বাজেট বণ্টনের সেরা অনুশীলনগুলি কী? এই প্রশ্নগুলির উত্তর গঠনের জন্য সম্প্রদায়ের সমঝোতা প্রয়োজন।

ওপেন সোর্স হল কনসেনসাস গঠনের সেরা উপায়।

সফটওয়্যার ইঞ্জিনিয়ারিংয়ের ইতিহাসের প্রতিফলনে, ESLint জাভাস্ক্রিপ্ট কোড স্টাইলের জন্য, Black পাইথন ফরম্যাটিংয়ের জন্য, Prettier ফ্রন্টএন্ড কোড স্টাইলের জন্য—এই টুলগুলি কারণেই ফ্যাক্টো স্ট্যান্ডার্ড হয়েছে যে ওপেন-সোর্স কমিউনিটির মাধ্যমে নিয়মগুলি তৈরি হয়েছে।

লবস্টার ফাদারের এই মেটা-স্কিলটি কি Skill গভর্নেন্সের জন্য ESLint হতে পারে?

এখন বিচার করা অতি শীঘ্র। কিন্তু দিশটি সঠিক।

একটি গভীরতর প্রশ্ন: স্কিল সিস্টেমটি নিজেই পুনর্ডিজাইন করা উচিত কি?

অডিট টুলগুলি "স্টক সমস্যা" সমাধান করে। কিন্তু যদি আমরা দৃষ্টিভঙ্গি এক স্তর উপরে তুলে নেই, তবে আমরা একটি আরও মৌলিক সমস্যা দেখতে পাই:

কেন স্কিল নিয়ন্ত্রণ হারাবে?

উত্তরটি হল: বর্তমান স্কিল সিস্টেমে লাইফসাইকেল ম্যানেজমেন্টের অভাব রয়েছে।

একটি স্কিল তৈরি হওয়ার পর এটি চিরকাল বিদ্যমান থাকে। কোনো মেয়াদ শেষ হওয়ার মেকানিজম নেই, কোনো ভার্সন পুরনো হওয়ার মেকানিজম নেই, কোনো সক্রিয়তা হ্রাস নেই। এটি একটি অমর প্রক্রিয়ার মতো, যা কেউ হাতে এটিকে kill না করা পর্যন্ত সংস্থান দখল করে থাকে।

অপারেটিং সিস্টেমের প্রক্রিয়া ব্যবস্থাপনা তুলনা করুন: তৈরি, শিডিউল, ঘুম এবং শেষ হওয়া সহ। জীবনচক্র সম্পূর্ণ বন্দর।

প্যাকেজ ম্যানেজারের ডিপেন্ডেন্সি ম্যানেজমেন্টের তুলনা করুন:npm auditসিকিউরিটি ভালনারেবিলিটি চেক করুন, npm outdatedপুরনো ডিপেন্ডেন্সি চেক করুন, npm pruneঅপ্রয়োজনীয় প্যাকেজ পরিষ্কার করুন। গভর্নেন্স টুলস ইকোসিস্টেমের একটি অংশ।

স্কিল সিস্টেমটি কোথায়? তৈরি করুন → ব্যবহার করুন → …… শেষ। মধ্যে অসংখ্য ধাপ অনুপস্থিত।

লবস্টার ফাদারের টুলটি মূলত সিস্টেম ডিজাইনের অভাব পূরণের জন্য বাহ্যিক টুল ব্যবহার করে। এটি খুব কার্যকর, কিন্তু এটি একটি সত্যকেও প্রকাশ করে: AI টুল প্ল্যাটফর্মগুলিতে Skill গভর্ন্যান্সের জন্য অবকাঠামো এখনও প্রাথমিক পর্যায়ে।

এটি সমালোচনা নয়। এটি বিকাশের পর্যায়ের অপরিহার্য অংশ। ২০২৪ থেকে ২০২৫ সালের মধ্যে, প্ল্যাটফর্মের প্রাথমিক লক্ষ্য হল "ইকোসিস্টেমকে চালু করা", গভর্ন্যান্স পরে নিয়ে আসা যাবে। কিন্তু ২০২৬ সালের মধ্যভাগে, ইকোসিস্টেমটি ইতিমধ্যে চালু হয়ে গেছে। এখন সময় পিছনের পাঠগুলি পূরণের।

শেষে লিখুন

আসল প্রশ্নে ফিরে যাই: আপনার এআই সহায়কে কতগুলি স্কিল সক্রিয়?

যদি তুমি উত্তর দিতে না পারো, তাহলে তোমাকে একটি শারীরিক পরীক্ষা করানো দরকার।

লবস্টার ফাদার টুল দিয়েছেন। বিনামূল্যে। ওপেন সোর্স। পাঁচটি মাত্রা, সম্পূর্ণ কভারেজ।

এটা তোমার বিষয়।

কিন্তু আমি একটা জিনিস নিশ্চিতভাবে বলতে পারি: যারা কনটেক্সট বাজেটকে গুরুত্ব দেয়, তারা যারা অন্ধভাবে স্কিল জমায়, তাদের চেয়ে ভালো এআই-সহায়তা অভিজ্ঞতা পায়।

কারণ এআই সবকিছুর জন্য সক্ষম নয়। এর মনোযোগ সীমিত, এর স্মৃতি সীমিত, এর যুক্তিসঙ্গত সংস্থান সীমিত। আপনি যত বেশি সঠিক এবং পরিষ্কার তথ্য দেবেন, এটি আপনাকে তত ভালো আউটপুট ফিরিয়ে দেবে।

এটি জাদু নয়। এটি তথ্য তত্ত্ব।

শ্যানন 1948 সালেই আমাদের বলেছিলেন: চ্যানেলের ক্ষমতা সীমিত, যত বেশি শব্দ থাকবে, তত কম কার্যকর তথ্য প্রেরণের হার হবে।

আপনার স্কিল তালিকায় যে সব জম্বি স্কিল আছে, সেগুলো শুধু শব্দ।

তাদের নিঃশেষে ধ্বংস করুন।

রেফারেন্স

1. অ্যাডামস, জি. এস., কনভার্স, বি. এ., হেলস, এ. এইচ., এবং ক্লটজ, এল. ই. (2021). মানুষ পদ্ধতিগতভাবে বিয়োগধর্মী পরিবর্তনগুলি উপেক্ষা করে।Nature, 592(7853), 258–261.
2. শ্যানন, সি. ই. (1948). এ ম্যাথেমেটিক্যাল থিওরি অফ কমিউনিকেশন। বেল সিস্টেম টেকনিক্যাল জার্নাল, 27(3), 379–423.
3. OpenAI. (2024). GPT-4 Turbo কনটেক্সট উইন্ডো এবং টোকেন সীমা ডকুমেন্টেশন। https://platform.openai.com/docs/models
4. অ্যানথ্রোপিক। (2025)। ক্লড মডেল কার্ড: কনটেক্সট উইন্ডো ব্যবহার এবং সিস্টেম প্রম্পট ওভারহেড। https://docs.anthropic.com/en/docs/about-claude/models
5. কার্সর টিম। (2025)। নিয়ম এবং দক্ষতা: কাস্টম নির্দেশাবলী কিভাবে কনটেক্সটে লোড করা হয়। কার্সর ডকুমেন্টেশন।
6. npm ডকুমেন্টেশন। (2025)। npm-audit, npm-prune: প্যাকেজ লাইফসাইকেল পরিচালনা। https://docs.npmjs.com/cli
7. লবস্টার ফাদার। (2026)। স্কিল হেলথ চেক মেটা-স্কিল [ওপেন সোর্স প্রজেক্ট]। GitHub রিপোজিটরি।
8. Sculley, D., ইত্যাদি। (2015)। মেশিন লার্নিং সিস্টেমে লুকানো টেকনিক্যাল ডেব্ট। Advances in Neural Information Processing Systems (NeurIPS), 28.