Anthropic বলেছে, আগস্টের দুই সপ্তাহের sprint-এ claude.ai ও Claude desktop app-এর মূল কাজগুলো প্রায় তিন গুণ দ্রুত হয়েছে। তাদের ২৩ সেপ্টেম্বর প্রকাশিত প্রকৌশল-দলের বিবরণে শুধু শিরোনামের অঙ্কের চেয়ে বেশি তথ্য আছে: কোন কাজ দ্রুত হয়েছে, দল কীভাবে মাপ যাচাই করেছে এবং সিদ্ধান্ত ও release-এর দায় প্রকৌশলীরা কোথায় রেখেছেন—তা এতে দেখা যায়।

বড় পরিবর্তন

  • কী বদলেছে: Anthropic জানিয়েছে, ওয়েব ও desktop-এ ১৩টি সাধারণ কাজের মাপে অপেক্ষার সময় কমেছে। ৩.১ গুণের অঙ্কটি এসব উন্নতির geometric mean; ১৩ ও ২৭ আগস্ট ৭৫তম percentile-এ মাপা হয়েছে। এটি বেছে নেওয়া ব্যবহার-পথগুলোর বিষয়ে কোম্পানির ফল।
  • কেন গুরুত্বপূর্ণ: Claude ব্যবহারকারীর ক্ষেত্রে নতুন web page ৩,০৮৫ মিলিসেকেন্ডের বদলে ৫৫০ মিলিসেকেন্ডে টাইপ করার উপযোগী হওয়া—বারবার ব্যবহৃত একটি ধাপে—পার্থক্য গড়ে। প্রকৌশল দলের জন্য এ উদাহরণ দেখায়, AI সহকারী মাপা performance সমস্যা সমাধানে কাজ করতে পারে, আর মানুষ অগ্রাধিকার বেছে ও পরিবর্তন অনুমোদন করে।
  • কী লক্ষ করবেন: Anthropic বলেছে, ৯৫তম percentile, অন্য ব্যবহার-পথ এবং অনেক দীর্ঘ কথোপকথনে এখনও কাজ বাকি। এসব মাপ থেকে বোঝা যাবে, তাদের জানানো উন্নতি বেছে নেওয়া কাজ ও আগস্টের তুলনার বাইরেও পৌঁছায় কি না।

ব্যবহারকারীরা যা পেয়েছেন

Anthropic চারটি ব্যবহার-পথ চিহ্নিত করেছে, যেগুলো তাদের হিসাবে ব্যবহারকারীর কাজের ৯৫ শতাংশ: app চালু করা, কথোপকথন শুরু করা, কথোপকথন খোলা এবং বার্তা পাঠানো। ওয়েব, desktop ও তাদের product জুড়ে এগুলোকে ১৩টি মাপে ভাগ করা হয়। প্রতিটি মাপ ব্যবহারকারীর একটি কাজ থেকে শুরু করে ফল render হওয়া পর্যন্ত; client ও server-এর কাজ আলাদা করে দেখা হয়েছে।

claude.ai-তে নতুন web page লোডের ক্ষেত্রে ৭৫তম percentile-এ টাইপ করার উপযোগী পাতা পেতে সময় ৩,০৮৫ থেকে কমে ৫৫০ মিলিসেকেন্ড হয়েছে, অর্থাৎ ৫.৬ গুণ দ্রুত। desktop app ঠান্ডা অবস্থা থেকে চালু হতে ৬,৩১০-এর বদলে ৩,৩২৮ মিলিসেকেন্ড লেগেছে, বা ১.৯ গুণ দ্রুত। desktop-এ Claude Cowork cloud session খুলতে ২,৫৬৬-এর বদলে ৭২৮ মিলিসেকেন্ড লেগেছে, বা ৩.৫ গুণ দ্রুত। web chat-এ বার্তা পাঠানোর client-side অংশ ১৮০ থেকে কমে ৫৯ মিলিসেকেন্ড হয়েছে, বা ৩.১ গুণ দ্রুত। এগুলো আলাদা কাজ ও platform-এর মাপ; সামগ্রিক ৩.১ গুণ ১৩টি অনুপাতের geometric mean, কোনো একক কাজের ফল নয়।

তুলনায় Anthropic-এর ১৩ ও ২৭ আগস্টের ৭৫তম percentile-এর real-user monitoring ব্যবহার করা হয়েছে। পোস্টে স্বাধীন audit, এই পথগুলোর ৯৫তম percentile-এর ফল বা Claude-এর সহায়তায় উন্নতির কতটা এসেছে—তার নিয়ন্ত্রিত হিসাব নেই। Anthropic-এর অনুমান, দ্রুত হওয়া কাজগুলোতে প্রতিদিন অপেক্ষার কয়েক দশ হাজার user-hour বাঁচে; তবে হিসাবটি কীভাবে করেছে, তা দেখায়নি।

পরিবর্তনের পেছনের মাপজোখ

প্রকৌশলীরা বেছে নেওয়া প্রায় ২০টি project দিয়ে শুরু করেন। Anthropic জানিয়েছে, bottleneck খুঁজতে, benchmark তৈরি করতে ও পরিবর্তনের প্রস্তাব দিতে তারা Claude Tag ব্যবহার করে—এটি Opus 5.5-এর কাছাকাছি মানের internal research model-এ চালানো beta agent। দলের ভাষ্য, তৃতীয় দিনের মধ্যে প্রথম ১৩টি লক্ষ্যের ১২টিতে পৌঁছায়; এরপর নতুন লক্ষ্য ঠিক করে এবং আগে থাকা monitor-এ ধরা পড়েনি এমন সমস্যা খোঁজে।

একটি উদাহরণে page লোড হওয়ার পর sidebar-এর row সরে যেতে দেখা যায়। আগের Cumulative Layout Shift মাপটি সমস্যাকে স্পষ্ট করে তুলতে পারেনি। এক প্রকৌশলী অন্তর্নিহিত Layout Instability API ব্যবহার করার প্রস্তাব দেন। পরে Claude প্রভাবিত page-এর অংশ চিহ্নিত করার telemetry এবং sidebar data দেরিতে আসার integration test যোগ করে। Anthropic জানায়, মূল code-এ test ২০টির ২০ বার ব্যর্থ এবং প্রস্তাবিত fix-এ ২০টির ২০ বার সফল হয়। telemetry চালু করার পর company বলে, ওয়েব page-এর ৩১ শতাংশ load-এ ব্যবহারযোগ্য হওয়ার পরও নড়াচড়া পাওয়া গেছে। এটি Anthropic-এর sprint-এর নথিবদ্ধ উদাহরণ; BIG CHANGE মাপটি পুনরায় তৈরি করেনি।

release-এর ফাঁকে দ্রুত এগোতে দল lab measurement-ও ব্যবহার করে। দুটি JavaScript hot path-এ একই benchmark-এ deterministic instruction count ও কেটে যাওয়া সময়ের তুলনা করা হয়। Anthropic জানায়, instruction count ৪৮ ও ৩১ শতাংশ কমার সঙ্গে wall-clock সময় যথাক্রমে ৭৮ ও ৪৪ শতাংশ কমেছিল। এরপর continuous integration-এ instruction count-এর সীমা বসানো হয়; performance উন্নত হলে সীমাও কমানো হয়। অবিশ্বস্ত বা ব্যবহারকারীর latency-র সঙ্গে না-মেলা benchmark বাদ দিয়েছে বলে দলটি জানায়। এই পার্থক্য গুরুত্বপূর্ণ: lab-এর counter পরিবর্তন চালাতে সাহায্য করেছে, আর বাস্তব ব্যবহারকারীর মাপ যাচাই করেছে, প্রকাশিত কাজ কাজে লেগেছে কি না।

নিয়ন্ত্রণ ছিল মানুষের হাতে

Anthropic এমন এক Slack channel-এর বর্ণনা দিয়েছে, যেখানে প্রতিটি journey বা benchmark-কে ঘিরে অনেক ছোট thread ছিল। Claude সমস্যা অনুসরণ করেছে, benchmark ও pull request-এর প্রস্তাব দিয়েছে, deployment দেখেছে এবং মাঠপর্যায়ের data পড়েছে। প্রকৌশলীরা লক্ষ্য ঠিক করেছেন, ব্যবহারকারীর কাছে দৃশ্যমান কোন trade-off গ্রহণযোগ্য তা বেছেছেন এবং প্রতিটি পরিবর্তন অনুমোদন করেছেন। প্রতিটি thread-এর একজন নির্দিষ্ট মানব-দায়িত্বপ্রাপ্ত ছিলেন। বার্তা পাঠাতে দুই মিলিসেকেন্ড সাশ্রয়ের জন্য প্রস্তাব করা ৯০০ লাইনের একটি পরিবর্তন প্রকৌশলীরা রক্ষণাবেক্ষণের খরচের তুলনায় বেশি মনে করে নাকচ করেন।

release প্রক্রিয়ায় একাধিক যাচাই ছিল। Anthropic-এর ভাষ্য, প্রতিটি pull request-এ স্বয়ংক্রিয় পর্যালোচনা ও অন্তত একজন মানুষের অনুমোদন ছিল; optimization-এর আগে unit test চালানো হয়। ব্যবহারকারীর কাছে দৃশ্যমান পরিবর্তন অল্প সময়ের feature flag-এর আড়ালে রাখা হয়। উচ্চ-ঝুঁকির পরিবর্তন আগে কর্মীদের কাছে, তারপর ১ শতাংশ ব্যবহারকারীর কাছে, শেষে সবার জন্য যায়। sprint-এ প্রায় ২০০টি flag যোগ করা হয়; শেষ হওয়ার আগে অর্ধেকেরও বেশি সরানো হয়েছে বলে দলটি জানায়। গ্রাহকের সামনে কোনো incident বা rollback ছাড়াই ৩,০০০-এর বেশি পরিবর্তন merge করার কথাও Anthropic জানিয়েছে। এটি ওই sprint নিয়ে কোম্পানির বিবরণ; অন্য দল বা codebase-এ একই ফল হবে, তা প্রমাণ করে না।

static composer দেখায় কেন এসব নিয়ন্ত্রণ জরুরি ছিল। React লোড হওয়ার সময় Anthropic প্রাথমিক HTML-এই টাইপ করা যায় এমন composer রেখেছিল। হস্তান্তর ঠিকমতো হচ্ছে কি না দেখতে test-গুলো ১৪টি viewport size-এ static ও React সংস্করণ মিলিয়েছে, alignment এক pixel-এর মধ্যে আছে কি না দেখেছে এবং transition-এর মধ্যে টাইপ করে key হারায় বা ক্রম বদলায় কি না পরীক্ষা করেছে। field telemetry handoff চলার সময় নড়াচড়া মেপেছে। পরে একজন কর্মী নতুন tab-এ এমন layout shift দেখেন, যা এসব মাপে ধরা পড়েনি; speculative loading-এর সময় browser resize হওয়াকে Anthropic কারণ হিসেবে চিহ্নিত করে এবং ওই পরিস্থিতির জন্য test যোগ করে।

Anthropic-এর প্রতিবেদন থেকে নির্দিষ্ট একটি সিদ্ধান্তে পৌঁছানো যায়: মানুষের নির্দেশনায় release প্রক্রিয়ার মধ্যে প্রকৌশলীরা bottleneck খুঁজতে ও উন্নত করতে Claude ব্যবহার করেছেন, এবং আগস্টের শেষে বেছে নেওয়া user journey দ্রুত হয়েছে। ধীরতম অংশে product কেমন চলে, উন্নতি কত দিন টিকবে এবং ফলের কতটা agent-এর বদলে দলের instrumentation, প্রকৌশল ও release সিদ্ধান্তের অবদান—এসব প্রশ্ন খোলা থাকে।