নির্বাহী সংক্ষিপ্ত আমি চার সপ্তাহ পার্ট-টাইম (সম্ভবত মোট 80 ঘন্টা) ব্যয় করেছি 40 টিরও বেশি উপাদান সহ একটি সম্পূর্ণ প্রতিক্রিয়াশীল ইউআই ফ্রেমওয়ার্ক, একটি রুটার এবং কেবলমাত্র এলএলএম জেনারেটেড কোড ব্যবহার করে ইন্টারেক্টিভ ওয়েবসাইট সমর্থন করে, এটি স্পষ্ট। . LLMs can produce quality code—but like human developers, they need the right guidance প্রধান ফলাফল On Code Quality: ভাল নির্ধারিত কাজ পরিষ্কার প্রথম পাস কোড উত্পাদন করে Poorly specified or unique requirements produce sloppy implementations কোড নির্দেশিত পুনর্নির্দেশনা ছাড়াই সময়ের সাথে সাথে নষ্ট হয় LLMs defensively over-engineer when asked to improve reliability On The Development Process: একটি কাজ বড় হলে "সঠিকভাবে নির্ধারিত" হওয়া কঠিন বিস্তৃত ধারণা ("ভাবনা") ভাল ফলাফল উত্পাদন করে, যদিও কখনও কখনও সার্কুলার বা অতিরিক্ত বিস্তৃত যুক্তি হতে পারে Multiple LLM perspectives (switching models) provides valuable architectural review and debug assistance কাঠামোগত ফ্রেমওয়ার্ক ব্যবহার, উদাহরণস্বরূপ Bau.js বা Lightview, সীমাহীন বিকাশের চেয়ে পতন প্রতিরোধ করে আনুষ্ঠানিক মিটারগুলি সুনির্দিষ্টভাবে সনাক্ত করে এবং কোড জটিলতার অপসারণকে নির্দেশ করে নীতিমালা: অনেক উপায়ে, এলএলএমগুলি তাদের প্রশিক্ষিত মানুষের গড় মত আচরণ করে - তারা অনুরূপ ভুল করে, কিন্তু অনেক দ্রুত এবং বৃহত্তর মাত্রায়. সুতরাং, আপনি একটি প্রাথমিক পরিষ্কার কোড বেস জেনারেশন এবং তারপর পরিবর্তনগুলি অনুরোধ করার 6 মিনিট পরে ছয় মাসের রক্ষণাবেক্ষণ এবং উন্নতি "লুপ" পেতে পারেন। চ্যালেঞ্জ চার সপ্তাহ আগে, আমি একটি প্রশ্নের উত্তর দিতে শুরু করেছি যা উন্নয়ন সম্প্রদায়ের মধ্যে গরম বিতর্কিত হয়েছে: কি LLMs মৌলিক, উৎপাদন মানের কোড উত্পাদন করতে পারে? একটি সম্পূর্ণ, আধুনিক প্রতিক্রিয়াশীল ইন্টারফেস ফ্রেমওয়ার্ক, যা অনেকগুলি পূর্বে তৈরি উপাদান, একটি রুটার এবং একটি সমর্থনকারী ওয়েবসাইট সহ: JavaScript, CSS এবং HTML এর হাজার হাজার লাইন মেমরি, পারফরম্যান্স এবং নিরাপত্তা বিবেচনা Professional UX and developer experience I chose to build ( )—একটি প্রতিক্রিয়াশীল ইউআই ফ্রেমওয়ার্ক যা Bau.js, HTMX এবং Juris.js এর সেরা বৈশিষ্ট্যগুলি একত্র করে। Lightview অ্যাপ্লিকেশন.dev প্রশ্ন দিয়ে শুরু করুন, কোড নয় আমি Claude Opus দিয়ে শুরু করেছি: "আমি একটি প্রতিক্রিয়াশীল ইউআই লাইব্রেরি তৈরি করতে চাই যা HTMX, Bau, এবং Juris একত্রিত করে। হাইপারমিডিয়ার জন্য, আমি কোন বিশেষ বৈশিষ্ট্য নামগুলি পছন্দ করি না - শুধুমাত্র উন্নত আচরণ। আমি HTML-এ শিরোনামে শিরোনাম প্রক্রিয়াকরণ, একটি এসপিএ রুটার, স্বয়ংক্রিয় কাস্টমাইজড উপাদান তৈরির সাথে ইউআই উপাদান লাইব্রেরি, কোন অতিরিক্ত কাজ ছাড়া এসইও সক্ষম অ্যাপ্লিকেশন এবং ব্যবহারকারীদের প্রচার এবং শিক্ষার জন্য একটি ওয়েবসাইট চাই। "আমি একটি প্রতিক্রিয়াশীল ইউআই লাইব্রেরি তৈরি করতে চাই যা HTMX, Bau, এবং Juris একত্রিত করে। হাইপারমিডিয়ার জন্য, আমি কোন বিশেষ বৈশিষ্ট্য নামগুলি পছন্দ করি না - শুধুমাত্র উন্নত আচরণ। আমি HTML-এ শিরোনামে শিরোনাম প্রক্রিয়াকরণ, একটি এসপিএ রুটার, স্বয়ংক্রিয় কাস্টমাইজড উপাদান তৈরির সাথে ইউআই উপাদান লাইব্রেরি, কোন অতিরিক্ত কাজ ছাড়া এসইও সক্ষম অ্যাপ্লিকেশন এবং ব্যবহারকারীদের প্রচার এবং শিক্ষার জন্য একটি ওয়েবসাইট চাই। প্রথমে কোহলি কোডে ডুবে যাননি। : dozens of clarifying questions TypeScript নাকি Vanilla JavaScript? স্টাইলিংয়ের জন্য কোন ইউআই উপাদান লাইব্রেরি? (এটি সুবিধা / অসুবিধা সহ বিকল্পগুলি সরবরাহ করে) কোন HTMX বিশেষ করে বৈশিষ্ট্য? Hosting preferences? রুটিং কৌশল? যাইহোক, কখনও কখনও আমি এটি প্রস্তুত হওয়া উচিত মনে হওয়ার আগে এটি কোড লিখতে শুরু করে এবং আমি একটি প্রতিক্রিয়া বাতিল করতে এবং এটি পুনর্নির্দেশ করতে হয়েছিল। খুঁজে বের করুন: এলএলএমগুলি প্রাকৃতিক কোড জেনারেশনের দিকে একটি শক্তিশালী দিকনির্দেশনা রয়েছে। এমনকি যখন কোড করার জন্য মনে করা হয় না, তখনও তারা কয়েকটি ইন্টারেক্টিভেশন পরে ভুলে যায়। এই সমস্ত মডেলগুলির সাথে ঘটে—ক্লোড, জিমনি, জিপিটি। Even when reminded not to code yet, they forget after a few interactions. This happens with all models—Claude, Gemini, GPT. They seem especially triggered to start the generation process when given example code, even when examples are provided alongside questions rather than as implementation requests. Finding: LLMs have a strong bias toward premature code generation. নির্দেশিকা: যদি আপনি প্রস্তুত হওয়ার আগে একটি এলএলএম কোড জেনারেশন শুরু করে তবে অবিলম্বে সম্পন্ন বাতিল করুন এবং পুনরায় পরিচালনা করুন: "কোড এখনও জেনারেশন করবেন না. আপনার কি আরও প্রশ্ন আছে? "আপনি এই বার বার পুনরাবৃত্তি করতে হবে যেহেতু এলএলএম "ভুলে যায়" এবং কোড জেনারেশনের দিকে ফিরে ড্রাইভ করে। অ্যান্টিগ্রাভিটি বা অন্যান্য আইডিই এর অনুরূপ মোডগুলিতে দ্রুত মোডের মধ্যে পরিকল্পনা পরিবর্তন এখানে সাহায্য করা উচিত, কিন্তু এটি বারবার ব্যবহার করা অসুবিধাজনক। একটি ভাল সমাধান হবে: যদি ব্যবহারকারী একটি প্রশ্ন জিজ্ঞাসা করে, তবে এলএলএম তাদের আপনি প্রস্তুত হওয়ার আগে যদি একটি এলএলএম কোড জেনারেশন শুরু করে তবে অবিলম্বে সম্পন্ন বাতিল করুন এবং পুনর্নির্দেশ করুন: "এখনও কোড জেনারেশন করবেন না. আপনার আরো প্রশ্ন আছে? : if the user asks a question, the LLM should assume they want discussion, not code. Only generate/modify code when explicitly requested or after asking permission. Guidance: A better solution would be এক ঘণ্টা পরে, ক্লোড অবশেষে বললেন, "আরো প্রশ্ন নেই. আপনি কি আমাকে একটি বাস্তবায়ন পরিকল্পনা তৈরি করতে চান যেহেতু অনেক পদক্ষেপ থাকবে? ফলিত পরিকল্পনা ব্যাপক ছিল - চেক বক্স, নকশা সিদ্ধান্ত এবং বিবেচনার সাথে একটি বিস্তারিত Markdown ফাইল: Reactive লাইব্রেরি 40+ ইউআই উপাদান রুটিং সিস্টেম A website … though the website got less attention - a gap I'd later address আমি ওয়েবসাইটের আইটেমগুলিতে স্পষ্টকরণ এবং একটি প্রধান বৈশিষ্ট্য যোগ করার ব্যতিক্রম ছাড়া এই পরিকল্পনাটিতে কোনও মৌলিক পরিবর্তন করিনি, বিকাশের শেষে রেজিস্ট্রেশন ইভেন্ট গেট। নির্মাণ শুরু With the plan in place, I hit my token limit on Opus. No problem—I switched to Gemini 3 (High), which had full context from the conversation plus the plan file. কয়েক মিনিটের মধ্যে জেনারেল জেনারেল - কোর প্রতিক্রিয়া ইঞ্জিন - দুই উদাহরণ ফাইলের সাথে: একটি "হ্যালো, বিশ্ব!" ডেমো যা উভয় Bau-যেমন সিন্ট্যাক্স এবং vDOM-যেমন সিন্ট্যাক্স দেখায়। lightview.js Then I made a mistake. "এসপিএ হিসাবে ওয়েবসাইটটি তৈরি করুন," আমি বললাম, লাইটভিউ নিজেই ব্যবহার করার জন্য নির্দিষ্ট না করে। When I returned, there was a beautiful website running in my browser. I looked at the code and my heart sank: . React with Tailwind CSS খুঁজে বের করুন: LLMs সবচেয়ে সাধারণ / জনপ্রিয় সমাধান ব্যবহার করবে যদি আপনি অন্যথায় নির্দিষ্ট না করেন. React + Tailwind SPAs জন্য একটি অত্যন্ত সাধারণ প্যাটার্ন. Lightview ব্যবহার করার জন্য স্পষ্ট নির্দেশনা ছাড়াই - আমি কেবলমাত্র একটি ফ্রেমওয়ার্ক তৈরি করেছি - LLM ডিফল্ট যা এটি প্রশিক্ষণ ডেটা মধ্যে সবচেয়ে প্রায়শই দেখেছিল। React + Tailwind SPAs জন্য একটি অত্যন্ত সাধারণ প্যাটার্ন. Lightview ব্যবহার করার জন্য স্পষ্ট নির্দেশনা ছাড়া - যে ফ্রেমওয়ার্কটি আমি কেবলমাত্র তৈরি করেছিলাম - এলএলএমটি ডিফল্ট করেছিল যা এটি প্রশিক্ষণ ডেটাতে প্রায়ই দেখেছিল। Finding: LLMs will use the most common/popular solution if you don't specify otherwise. আরও খারাপ, যখন আমি Lightview দিয়ে এটি পুনর্গঠন করার জন্য অনুরোধ করেছিলাম, আমি "প্রথমে বিদ্যমান সাইটটি মুছে ফেলুন" বলতে ভুলে গিয়েছিলাম। নির্দেশাবলী: একটি এলএলএম পুনরায় কাজ করার জন্য জিজ্ঞাসা করার সময়, পদ্ধতি সম্পর্কে স্পষ্ট হোন: Delete the existing site and rebuild from scratch using Lightview Lightview ব্যবহার করার জন্য বিদ্যমান সাইটটি সংশোধন করুন নির্দেশাবলী: একটি এলএলএম পুনরায় কাজ করার জন্য জিজ্ঞাসা করার সময়, পদ্ধতি সম্পর্কে স্পষ্ট হোন: Delete the existing site and rebuild from scratch using Lightview Lightview ব্যবহার করার জন্য বিদ্যমান সাইটটি সংশোধন করুন প্রথমটি সাধারণত বড় পরিবর্তনগুলির জন্য আরো টোকেন দক্ষ। দ্বিতীয়টি লক্ষ্যমাত্রা সংশোধনের জন্য ভাল। এলএলএম স্বয়ংক্রিয়ভাবে কার্যকর পথ নির্বাচন করবে না - আপনাকে এটি পরিচালনা করতে হবে। The Tailwind Surprise এক সমস্যা আমাকে আটকে রেখেছিল. ক্লোড লাইটভিউ উপাদান ব্যবহার করে ওয়েবসাইটটি তৈরি করার পরে, আমি লক্ষ্য করেছি যে এটি এখনও Tailwind সিএসএস ক্লাসগুলির সাথে সম্পূর্ণ ছিল। "হ্যাঁ," ক্লোড কার্যকরভাবে ব্যাখ্যা, "আপনি UI উপাদানগুলির জন্য DaisyUI নির্বাচন করেছেন, এবং DaisyUI একটি নির্ভরশীলতা হিসাবে Tailwind প্রয়োজন। আমি সিমেন্টিক সিএসএস ক্লাস পছন্দ করি এবং সাইটটি ক্লাসিক সিএসএস পদ্ধতি ব্যবহার করতে চেয়েছিল। খুঁজে বের করুন: এলএলএমগুলি যুক্তিসঙ্গত কিন্তু কখনও অপ্রয়োজনীয় অনুমান করে। যখন আপনি একটি প্রযুক্তি নির্ধারণ করেন যা নির্ভরশীলতা রয়েছে, এলএলএমগুলি প্রকল্পের সম্পর্কিত অংশগুলিতে সেই পছন্দটি প্রসারিত করবে। খুঁজে বের করুন: এলএলএমগুলি যুক্তিসঙ্গত কিন্তু কখনও অপ্রয়োজনীয় অনুমান করে। যখন আপনি একটি প্রযুক্তি নির্ধারণ করেন যা নির্ভরশীলতা রয়েছে, এলএলএমগুলি প্রকল্পের সম্পর্কিত অংশগুলিতে সেই পছন্দটি প্রসারিত করবে। নির্দেশিকা: আপনি কি চান না সম্পর্কে স্পষ্ট থাকুন, শুধুমাত্র আপনি কি চান না. উদাহরণস্বরূপ "আমি DaisyUI উপাদান চাই, কিন্তু শুধুমাত্র তাদের জন্য Tailwind ব্যবহার করুন অন্য কোথাও না." যদি আপনি আর্কিটেকচারিক পদ্ধতি সম্পর্কে শক্তিশালী পছন্দ আছে, তাদের পূর্বে উল্লেখ করুন। Be explicit about what you don't want, not just what you do want. e.g. "I want DaisyUI components, but only use Tailwind for them not elsewhere." If you have strong preferences about architectural approaches, state them upfront. Guidance: I asked Claude to rewrite the site using classic CSS and semantic classes. I liked the design and did not want to delete the files, so once again I suffered through a refactor that consumed a lot of tokens since it touched so many files. I once again ran out of tokens and tired GPT-OSS bit hit syntax errors and had to switch to another IDE to keep working. গাইড: যখন একটি এলএলএম আপনার কোড বেসের সাথে লড়াই করে, তখন পূর্বে সফল ছিল এমন একটি ফিরে যান। বিভিন্ন মডেলগুলি আপনার প্রকল্পের কাঠামোকে ভিন্নভাবে "প্রজ্ঞা" করে। এবং, যদি আপনি টোকেনগুলি শেষ হওয়ার সময় অ্যান্টিগ্রাভাইট ব্যবহার করছেন তবে আপনি একই ডিরেক্টরিতে এমএস ভিজুয়াল কোডে পরিবর্তন করতে পারেন এবং ক্লোডের সাথে একটি হালকা GitHub Copilot অ্যাকাউন্ট ব্যবহার করতে পারেন। যখন একটি এলএলএম আপনার কোড বেসের সাথে লড়াই করে, তখন পূর্বে সফল ছিল এমন একটি ফিরে যান। বিভিন্ন মডেলগুলি আপনার প্রকল্প পরিবেশের বিভিন্ন "প্রজ্ঞা" করে। এবং, যদি আপনি টোকেনগুলি শেষ হওয়ার সময় অ্যান্টিগ্রাভাইট ব্যবহার করছেন তবে আপনি একই ডিরেক্টরিতে এমএস ভিসুয়াল কোডে পরিবর্তন করতে পারেন এবং ক্লোডের সাথে একটি হালকা GitHub Copilot অ্যাকাউন্ট ব্যবহার করতে পারেন। Guidance: The Iterative Dance পরবর্তী কয়েক সপ্তাহে, আমি ওয়েবসাইটটি তৈরি করার জন্য কাজ করেছি এবং উপাদানগুলিতে পরীক্ষা / ইটেরেট করার জন্য, আমি টোকেন সীমা পুনরুদ্ধার হিসাবে একাধিক এলএলএমগুলিতে কাজ করেছি। Claude আর্কিটেকচারিক প্রশ্নগুলিতে অসাধারণ ছিলেন এবং Lightview উপাদানগুলির সাথে পরিষ্কার ওয়েবসাইট কোড তৈরি করেছিলেন জিমনি প্রো নিয়মিতভাবে তার নিজস্ব কাজ সমর্থন করার জন্য স্থানীয় সরঞ্জাম এবং শেল সাহায্য স্ক্রিপ্ট ব্যবহার করার চেষ্টা করে - গতি এবং টোকেন দক্ষতার জন্য মূল্যবান। দৃষ্টিভঙ্গি পরিবর্তন শক্তিশালী প্রমাণিত হয়েছে: "আপনি একটি ভিন্ন LLM. আপনার চিন্তাগুলি কি? আমি সত্যিকারের বিজয়ী জিমনি ফ্ল্যাশ খুঁজে পেয়েছি. এটি সিনট্যাক্স ত্রুটিগুলি প্রবর্তন না করে কোডটি পুনর্গঠনের একটি আশ্চর্যজনক কাজ করেছিল এবং কোডটি কোথায় রাখা উচিত তা নিয়ে ন্যূনতম নির্দেশনা প্রয়োজন ছিল. কখনও কখনও আমি পরিবর্তন সম্পর্কে সন্দেহভাজন ছিলাম এবং এটি বলতাম। রুটের বিবর্তন এছাড়াও রুটের জন্য কাজের প্রয়োজন ছিল। Claude প্রথমে একটি hash-based router বাস্তবায়ন করেছিলেন ( , , ইত্যাদি)। এটি একটি এসপিএ জন্য সম্পূর্ণরূপে উপযুক্ত - এটি সহজ, নির্ভরযোগ্য এবং সার্ভার কনফিগারেশন প্রয়োজন হয় না। #/about #/docs কিন্তু আমার অতিরিক্ত প্রয়োজনীয়তা ছিল যা আমি স্পষ্টভাবে উল্লেখ করিনি: আমি নিয়মিত পথগুলি চাই ( , ) গভীর লিঙ্কিং এবং এসইও জন্য. সার্চ ইঞ্জিন এখন হ্যাশ রুটগুলি পরিচালনা করতে পারে, কিন্তু পথ ভিত্তিক রুটিং ইনডেক্সিং এবং ভাগ করার জন্য এখনও পরিষ্কার। /about /docs Hash-based routing is easier to implement and works without server-side configuration. Since I did not say I wanted path-based routing, the LLM will choose the simpler approach. Finding: LLMs will sometimes default to the simplest valid solution. Hash-based routing is easier to implement and works without server-side configuration. Since I did not say I wanted path-based routing, the LLM will choose the simpler approach. Finding: LLMs will sometimes default to the simplest valid solution. যখন আমি ক্লোডকে বলেছিলাম যে আমি এসইও এবং গভীর লিঙ্কিংয়ের জন্য ঐতিহ্যগত পথগুলি প্রয়োজন, তখন এটি খুব দ্রুত রুটারটি পুনরায় লিখে এবং আমি একটি বুদ্ধিমান সমাধান হিসাবে বিবেচনা করেছি-একটি হাইব্রিড পদ্ধতি যা এসপি পৃষ্ঠাগুলি উভয় গভীর লিঙ্ক এবং এসইও-ইন্ডেক্সযোগ্য করে তোলে সার্ভার দিক রেন্ডিংয়ের জটিলতা ছাড়া। নির্দেশিকা: আর্কিটেকচারিক প্যাটার্নগুলির জন্য, আপনার প্রয়োজনীয়তা সম্পর্কে প্রথমে স্পষ্ট থাকুন. আইএলএম জানেন না যে আপনি আরও জটিল কিন্তু এসইও-প্রিয় পদ্ধতি চান. নির্দিষ্ট করুন: "আমি এসইও জন্য ইতিহাস API এর সাথে পথ ভিত্তিক রুটিং প্রয়োজন" শুধু "আমি রুটিং প্রয়োজন" এর পরিবর্তে। For architectural patterns, be explicit about your requirements early. Don't assume the LLM knows you want the more complex but SEO-friendly approach. Specify: "I need path-based routing with History API for SEO" rather than just "I need routing." Guidance: নির্দেশিকা: আমি এছাড়াও খুঁজে পেয়েছি যে LLMs প্রতিরক্ষামূলকভাবে পূর্ববর্তী সংস্করণের সাথে সামঞ্জস্যপূর্ণতা নিশ্চিত করার চেষ্টা করে, এটি অত্যন্ত জটিল কোড হতে পারে। Guidance: I also found that LLMs defensively try to ensure compatibility with previous versions, this can lead to overly complex code. If you are writing from scratch you need to remind them that backward compatibility is not required. সংখ্যাগুলির সাথে তুলনা চূড়ান্ত বক্তব্য Project Size: 60 JavaScript ফাইল, 78 HTML ফাইল, 5 CSS ফাইল 41,405 মোট কোড লাইন ( মন্তব্য এবং খালি অন্তর্ভুক্ত) Over 40 custom UI components 70+ ওয়েবসাইট ফাইল এই মুহূর্তে, ফাইলগুলি যুক্তিসঙ্গত মনে হয়েছিল - অতিরিক্ত জটিল নয়. কিন্তু 40 বছরেরও বেশি সফটওয়্যার বিকাশের পরে কোড সম্পর্কে আমার অনুভূতি এবং পার্শ্বপ্রতিক্রিয়াশীল অনুভূতিগুলি যথেষ্ট নয়. আমি কোর ফাইলগুলিতে আনুষ্ঠানিক মেট্রিক্স চালানোর সিদ্ধান্ত নিয়েছি। Core Libraries: File Lines Minified Size lightview.js 603 7.75K lightview-x.js 1,251 20.2K lightview-router.js 182 3K lightview.js 603 7.75K লাইটভিউ-x.js ১,২৫১ ২.২ ক lightview-router.js 182 ৩ ক ওয়েবসাইট শুভেচ্ছা পেয়েছেন সুপার ফোকাসিত অপ্টিমাইজেশন ছাড়া পারফরম্যান্সের জন্য। উপাদান গ্যালারি Lighthouse এরপর আসে জটিলতা মিটার। আবিষ্কার করা হয়েছে স্লিপ I asked Gemini Flash to evaluate the code using three formal metrics: A combined metric where 0 is unmaintainable and 100 is perfectly documented/clean code. The calculation considers: 1. Maintainability Index (MI): Halstead Volume (measure of code size and complexity) Cyclomatic Complexity Lines of code কিভাবে ঘনত্ব 65 এর উপরে পয়েন্টগুলি লাইব্রেরি কোডের জন্য স্বাস্থ্যকর হিসাবে বিবেচিত হয়. এই মেট্রিকটি আপনাকে একটি একক সংখ্যা দেয় যাতে সময়ের মধ্যে কোডের স্বাস্থ্য অনুসরণ করা যায়. একটি পুরাতন কিন্তু এখনও মূল্যবান মেট্রিক যা কোডের মাধ্যমে লাইনীয়ভাবে স্বাধীন পথগুলির সংখ্যা পরিমাপ করে। 2. Cyclomatic Complexity: More potential bugs গভীরভাবে পরীক্ষা করা কঠিন (মেট্রিক আসলে আপনাকে বলতে পারে আপনি কতগুলি লিখতে পারেন) More cognitive load to understand একটি আধুনিক মেট্রিক যা মানসিক প্রচেষ্টা একটি মানুষের কোড বুঝতে প্রয়োজন পরিমাপ করে. সাইক্লোম্যাটিক জটিলতা (যা সমস্ত নিয়ন্ত্রণ প্রবাহ সমানভাবে চিকিত্সা), জ্ঞানীয় জটিলতা শাস্তি: 3. Cognitive Complexity: গভীর গভীরতা (Deeper Nesting = Higher Penalty) Boolean operator chains Recursion Breaks in linear flow The thresholds: 0-15: পরিষ্কার কোড - বোঝা এবং বজায় রাখা সহজ 16-25: উচ্চ প্রস্রাব - প্রযুক্তিগত ঋণ হ্রাস করার জন্য প্রস্তাবিত রিফ্যাক্টরিং 26+: গুরুত্বপূর্ণ - অবিলম্বে মনোযোগ প্রয়োজন, রক্ষণাবেক্ষণ দুঃস্বপ্ন অনুসন্ধান: LLMs বিশ্লেষণ সরঞ্জাম তৈরি করতে অসাধারণ. Gemini ফ্ল্যাশ প্রাথমিকভাবে একটি বিদ্যমান মিটার লাইব্রেরি অনুসন্ধান, একটি খুঁজে পাওয়া যায় না, তারপর নিজের সম্পূর্ণ বিশ্লেষক (metrics-analysis.js) লিখেছিল Acorn JavaScript বিশ্লেষক ব্যবহার করে - অনুমতি জিজ্ঞাসা ছাড়া. এটি উভয়ই আকর্ষণীয় এবং কখনও কখনও সমস্যা। Gemini Flash initially searched for an existing metrics library, couldn't find one, then ( ) using the Acorn JavaScript parser—without asking permission. This is both impressive and occasionally problematic. I cover the problem with this case later. Finding: LLMs excel at creating analysis tools. wrote its own complete analyzer metrics-analysis.js The Verdict Overall health looked good: File Functions Avg Maintainability Avg Cognitive Status lightview.js 58 65.5 3.3 ⚖️ Good lightview-x.js 93 66.5 3.6 ⚖️ Good lightview-router.js 27 68.6 2.1 ⚖️ Good লাইটভিউ.জিস 58 65.5 3.3 ⚖️ Good লাইটভিউ-x.js 93 66.5 3.6 ⚖️ Good lightview-router.js 27 68.6 2.1 ⚖️ Good But drilling into individual functions told a different story. Two functions hit "Critical" status: (lightview-x.js): handleSrcAttribute Cognitive Complexity: 🛑 35 Cyclomatic Complexity: 🛑 22 Maintainability Index: 33.9 (Lightview-x.js এর জন্য) Anonymous Template Processing Cognitive Complexity: 🛑 31 Cyclomatic Complexity: 13 প্রযুক্তিগত ঋণ রক্ষণাবেক্ষণ দুঃস্বপ্ন হয়ে উঠতে অপেক্ষা করে। Can AI Fix Its Own Slop? Here's where it gets interesting. The code was generated by Claude Opus, Claude Sonnet, and Gemini 3 Pro several weeks earlier. Could the newly released clean it up? Gemini 3 Flash I asked Flash to refactor to address its complexity. This seemed to take a little longer than necessary. So I aborted and spent some time reviewing its thinking process. There were obvious places it got side-tracked or even went in circles, but I told it to continue. After it completed, I manually inspected the code and thoroughly tested all website areas that use this feature. No bugs found. handleSrcAttribute Gemini Flash "thinks" extensively. While reviewing all its thought processes would be tedious, important insights flash by in the IDE. When an LLM seems stuck in a loop, aborts and review historical thoughts for possible sidetracks and tell to continue or redirect as needed. Critical Discovery #2: Gemini Flash "thinks" extensively. While reviewing all its thought processes would be tedious, important insights flash by in the IDE. When an LLM seems stuck in a loop, aborts and review historical thoughts for possible sidetracks and tell to continue or redirect as needed. Critical Discovery #2: সংশোধন করার পরে , I asked for revised statistics to see the improvement. handleSrcAttribute Flash's Disappearing Act Unfortunately, Gemini Flash had deleted its ফাইলটি পুরো বিশ্লেষককে পুনর্নির্মাণ করতে হয়েছিল। metrics-analysis.js After Flash uses a script or analysis tool it creates, it often deletes the file assuming it is temporary. This happens even for files that take significant effort to create and that you might want to keep or reuse. Finding: Gemini Flash aggressively deletes temporary files. ফ্ল্যাশ একটি স্ক্রিপ্ট বা বিশ্লেষণ সরঞ্জাম ব্যবহার করার পরে, এটি প্রায়ই ফাইলটি মুছে ফেলবে যখন এটি সাময়িক হয়। Finding: Gemini Flash aggressively deletes temporary files. Tell Gemini to put utility scripts in a specific directory (like or ) and explicitly ask it to keep them. You can say: "Create this in /home/claude/tools/ and keep it for future use." Otherwise, you'll find yourself regenerating the same utilities multiple times. Guidance: /home/claude/tools/ /home/claude/scripts/ Tell Gemini to put utility scripts in a specific directory (like অথবা ) and explicitly ask it to keep them. You can say: "Create this in /home/claude/tools/ and keep it for future use." Otherwise, you'll find yourself regenerating the same utilities multiple times. Guidance: /home/claude/tools/ /home/claude/scripts/ Dev Dependencies সমস্যা When I told Gemini to keep the metrics scripts permanently, another issue surfaced: it failed to officially install dev dependencies like (the JavaScript parser). acorn Flash simply assumed that because it found packages in , it could safely use them. The only reason was available was because I'd already installed a Markdown parser that depended on it. node_modules acorn They'll use whatever's available in without verifying it's officially declared in . This creates fragile builds that break on fresh installs. Finding: LLMs don't always manage dependencies properly. node_modules package.json তারা যা কিছু উপলব্ধ আছে তা ব্যবহার করবে without verifying it's officially declared in এটি দুর্বল নির্মাণ তৈরি করে যা নতুন ইনস্টলেশনের উপর ভেঙে যায়। Finding: LLMs don't always manage dependencies properly. node_modules package.json After an LLM creates utility scripts that use external packages, explicitly ask: "Did you add all required dependencies to package.json? Please verify and install any that are missing." Better yet, review the script's imports and cross-check against your declared dependencies yourself. Guidance: After an LLM creates utility scripts that use external packages, explicitly ask: "Did you add all required dependencies to package.json? Please verify and install any that are missing." Better yet, review the script's imports and cross-check against your declared dependencies yourself. Guidance: The Refactoring Results With the analyzer recreated, Flash showed how it had decomposed the monolithic function into focused helpers: (cognitive: 5) fetchContent পার্শ্বপ্রতিক্রিয়া (Cognitive: 5) (cognitive: 7) updateTargetContent (cognitive: 2) elementsFromSelector orchestrator (cognitive: 10) handleSrcAttribute The Results Metric Before After Improvement Cognitive Complexity 35 🛑 10 ✅ -71% Cyclomatic Complexity 22 7 -68% Status Critical Slop Clean Code — Cognitive Complexity ৩৫ ১০টি -71% Cyclomatic Complexity 22 7 -68% Status Critical Slop Clean Code — Manual inspection and thorough website testing revealed zero bugs. The cost? A 0.5K increase in file size - negligible. Emboldened, I tackled the template processing logic. Since it spanned multiple functions, this required more extensive refactoring: Extracted Functions: - iteration logic collectNodesFromMutations - scanning logic processAddedNode - template interpolation for text transformTextNode - attribute interpolation and recursion transformElementNode Results: Function Group Previous Max New Max Status MutationObserver Logic 31 🛑 6 ✅ Clean domToElements Logic 12 ⚠️ 6 ✅ Clean MutationObserver Logic ৩১ ৬ পরিষ্কার domToElements Logic 12 ️ 6 ✅ Clean Final Library Metrics After refactoring, lightview-x.js improved significantly: ফাংশন: 93 → 103 (সবচেয়ে ভাল ভাঙন) 66.5 → 66.8 Avg Maintainability: Avg Cognitive: 3.6 → 3.2 সমস্ত গুরুত্বপূর্ণ পতন এড়ানো হয়েছে. ফাংশন সংখ্যা বৃদ্ধি স্বাস্থ্যকর মডুলারতা প্রতিফলিত করে - জটিল যুক্তি বিশেষজ্ঞ, কম জটিলতা সাহায্যকারীদের প্রতিনিধিত্ব করা হয়. প্রকৃতপক্ষে, এটি একটি মেট্রিক দৃষ্টিকোণ থেকে প্রতিষ্ঠিত ফ্রেমওয়ার্কগুলির তুলনায় ভাল বা ভাল: File Functions Maintainability (min/avg/max) Cognitive (min/avg/max) Status lightview.js 58 7.2 / 65.5 / 92.9 0 / 3.4 / 25 ⚖️ Good lightview-x.js 103 0.0 / 66.8 / 93.5 0 / 3.2 / 23 ⚖️ Good lightview-router.js 27 24.8 / 68.6 / 93.5 0 / 2.1 / 19 ⚖️ Good react.development.js 109 0.0 / 65.2 / 91.5 0 / 2.2 / 33 ⚖️ Good bau.js 79 11.2 / 71.3 / 92.9 0 / 1.5 / 20 ⚖️ Good htmx.js 335 0.0 / 65.3 / 92.9 0 / 3.4 / 116 ⚖️ Good juris.js 360 21.2 / 70.1 / 96.5 0 / 2.6 / 51 ⚖️ Good lightview.js 58 7.2 / 65.5 / 92.9 0 / 3.4 / 25 ️ ভালো lightview-x.js 103 0.0 / 66.8 / 93.5 0 / 3.2 / 23 ⚖️ Good lightview-router.js 27 ২.৮ / ৬৮.৬ / ৯৩.৫ 0 / 2.1 / 19 ⚖️ Good react.development.js 109 0.0 / 65.2 / 91.5 0 / 2.2 / 33 ⚖️ Good bau.js 79 ১১.২ / ৭১.৩ / ৯২ 0 / 1.5 / 20 ⚖️ Good htmx.js 335 0.0 / 65.3 / 92.9 0 / 3.4 / 116 ⚖️ Good juris.js 360 ২.২ / ৭০.১ / ৯৬.৫ 0 / 2.6 / 51 ️ ভালো 1. LLMs Mirror Human Behavior—For Better and Worse LLMs সাধারণ ডেভেলপারদের মত একই প্রবণতা প্রদর্শন: Rush to code without full understanding Don't admit defeat or ask for help soon enough Generate defensive, over-engineered solutions when asked to improve reliability Produce cleaner code with structure and frameworks The difference? They do it . They can generate mountains of slop in hours that would take humans weeks. faster and at greater volume 2. Thinking Helps বিস্তৃত উদ্দেশ্য ( "ভাবনা" মোডগুলিতে দেখা যায়) বিকল্পগুলি, আত্ম সংশোধনগুলি এবং মাঝে মাঝে "হ্যাঁ কিন্তু" মুহূর্তগুলি দেখায়। চিন্তাভাবনাটি সাধারণত ফলপ্রসূ, কখনও কখনও বিপর্যস্ত। যখন আপনি বিশ্বাস করেন যে কাজগুলি জটিল বা গুরুত্বপূর্ণ হয় তখন শুধু ছেড়ে বা অন্য কিছু করবেন না। এলএলএমগুলি বিরলভাবে "আমি ছেড়ে দিচ্ছি" বা "আমাকে নির্দেশনা দিন" বলছে - আমি চাই তারা আরো প্রায়শই থাকবে। চিন্তার প্রবাহটি দেখুন এবং প্রয়োজন হলে প্রতিক্রিয়া অনুরোধটি বাতিল করুন। চিন্তাভাবনা পড়ুন এবং পুনর্নির্দেশ করুন বা শুধু বলুন 3. Multiple Perspectives Are Powerful যখন আমি একটি দ্বিতীয় এলএলএমকে বলেছিলাম, "তুমি এই কোডটি পর্যালোচনা করে অন্য একটি এলএলএম। খুঁজে বের করুন: এলএলএমগুলি অসাম্প্রদায়িকভাবে অরক্ষামূলক। যখন একটি বাস্তবায়নের মুখোমুখি হয় যা অত্যন্ত বিরক্তিকর, অসম্ভবভাবে বিরক্তিকর, বা অকার্যকর হিসাবে সমালোচনা করা হয়, নেতৃস্থানীয় এলএলএম (ক্লোড, জিমনি, জিপিটি) বিতর্ক করবে না। When faced with an implementation that's critiqued as too abstract, insufficiently abstract, or inefficient, leading LLMs (Claude, Gemini, GPT) won't argue. They'll do a rapid, thorough analysis and return with honest pros/cons of current versus alternative approaches. Finding: LLMs are remarkably non-defensive. This behavior is actually : beyond what most humans provide How many human developers give rapid, detailed feedback without any defensive behavior? কতগুলি কোম্পানি কোনও সময় কোনও ডেভেলপার দ্বারা জিজ্ঞাসাবাদ করার জন্য উপলব্ধ অভিজ্ঞ আর্কিটেক্টর আছে? কতটি কোড পর্যালোচনা কথোপকথন ঘটে যায় অ্যাকাউন্টে জড়িত হওয়া ছাড়া? Before OR after making changes, switch LLMs deliberately: Guidance: Make progress with one LLM (e.g., Claude builds a feature) Switch to another (e.g., Gemini) and say: "You are a different LLM reviewing this implementation. What are your thoughts on the architecture, potential issues, and alternative approaches?" Then switch back to the first and ask what it thinks now! This is especially valuable before committing to major architectural decisions or after implementing complex algorithms. The second opinion costs just a few tokens but can save hours of refactoring later. পরিবর্তন করার আগে বা পরে, ইচ্ছাকৃতভাবে LLMs পরিবর্তন করুন: Guidance: Make progress with one LLM (e.g., Claude builds a feature) Switch to another (e.g., Gemini) and say: "You are a different LLM reviewing this implementation. What are your thoughts on the architecture, potential issues, and alternative approaches?" Then switch back to the first and ask what it thinks now! This is especially valuable before committing to major architectural decisions or after implementing complex algorithms. The second opinion costs just a few tokens but can save hours of refactoring later. ৪. স্লিপ প্রতিরোধ করে Telling an LLM to use "vanilla JavaScript " without constraints invites slop. Vanilla JavaScript is a wonderful but inherently loose language through which a sometimes sloppy or inconsistent browser API is exposed. Without constraints, it's easy to create unmaintainable code—for both humans and LLMs. Specifying a framework (Bau.js, React, Vue, Svelte, etc.) provides guardrails that lead to cleaner, more maintainable code. Finding: Telling an LLM to use "vanilla JavaScript " without constraints invites slop. Vanilla JavaScript is a wonderful but inherently loose language through which a sometimes sloppy or inconsistent browser API is exposed. Without constraints, it's easy to create unmaintainable code—for both humans and LLMs. Specifying a framework (Bau.js, React, Vue, Svelte, etc.) provides guardrails that lead to cleaner, more maintainable code. Finding: নির্দেশিকা: একটি প্রকল্প শুরু করার সময়, আপনি কি অর্জন করতে চান উপর ভিত্তি করে পরামর্শের জন্য জিজ্ঞাসা করুন: The framework/library to use (React, Vue, Svelte, etc.) The architectural pattern (MVC, MVVM, component-based, etc.) কোড সংগঠন পছন্দ (ফাংশন ভিত্তিক vs. স্তর ভিত্তিক ফোল্ডার) কনভেনশন নামকরণ Whether to use TypeScript or JSDoc for type safety Other libraries to use … no prevent re-invention. Don't say: "Build me a web app in JavaScript" Do say: "Build me a React application using functional components, hooks, TypeScript, and feature-based folder organization. Follow Airbnb style guide for naming." আপনি সামনে যত বেশি কাঠামো সরবরাহ করেন, তত কম পর্দা পাবেন. এটি সমস্ত ভাষার জন্য প্রযোজ্য, শুধুমাত্র JavaScript নয়। When starting a project, based on what you want to accomplish ask for advice on: Guidance: The framework/library to use (React, Vue, Svelte, etc.) The architectural pattern (MVC, MVVM, component-based, etc.) কোড সংগঠন পছন্দ (ফাংশন ভিত্তিক vs. স্তর ভিত্তিক ফোল্ডার) কনভেনশন নামকরণ Whether to use TypeScript or JSDoc for type safety Other libraries to use … no prevent re-invention. Don't say: "Build me a web app in JavaScript" Do say: "Build me a React application using functional components, hooks, TypeScript, and feature-based folder organization. Follow Airbnb style guide for naming." The more structure you provide upfront, the less slop you'll get. This applies to all languages, not just JavaScript. ৫. লক্ষণীয় সত্য প্রদর্শন আমি ভালবাসি যে আনুষ্ঠানিক সফ্টওয়্যার মেট্রিক্স এলএলএম ডেভেলপমেন্ট পরিচালনা করতে পারে। তারা প্রায়ই মানব উন্নয়নের জন্য অত্যন্ত বিরক্তিকর, যান্ত্রিক, কঠিন বা ব্যয়বহুল বলে মনে করা হয়, কিন্তু একটি এলএলএম উন্নত আইডিএলএলএলএলএলএলএলএলএলএলএলএলএলএলএলএলএলএলএলএলএলএলএলএলএলএলএলএলএলএলএলএলএলএলএলএলএলএলএলএলএলএলএলএলএলএলএলএলএলএলএলএলএলএলএলএলএলএল খুঁজে বের করুন: আনুষ্ঠানিক সফটওয়্যার মিটারগুলি উদ্দেশ্যমূলকভাবে উন্নয়ন পরিচালনা করতে পারে। Identifying technical debt automatically Tracking code health over time Guiding refactoring priorities Validating that "improvements" actually improve things They're perfect for: Finding: Formal software metrics can guide development objectively. প্রযুক্তিগত ঋণ স্বয়ংক্রিয়ভাবে সনাক্ত করুন Tracking code health over time Guiding refactoring priorities Validating that "improvements" actually improve things Metrics don't lie. They identified the slop my intuition missed. গাইডিং: আপনার এলএলএম ওয়ার্কফ্লোকে মেট্রিক্স অন্তর্ভুক্ত করুন: Run complexity metrics on all files. Identify functions with cognitive complexity > 15 or cyclomatic complexity > 10. After initial implementation: Address Critical (cognitive > 26) functions first, then "High Friction" (16-25) functions. Prioritize refactoring: Don't just say ‘improve this’. Say ‘Refactor handleSrcAttribute to reduce cognitive complexity to target range’. Request targeted refactoring: After refactoring, re-run metrics. Ensure complexity actually decreased and maintainability increased. Sometimes ‘improvements’ just shuffle complexity around. Verify improvements: Before marking code as done, try to have all functions with a cognitive complexity < 15 and maintainability index > 65. Set quality gates: Integrate metrics into your LLM workflow: Guidance: Run complexity metrics on all files. Identify functions with cognitive complexity > 15 or cyclomatic complexity > 10. After initial implementation: অগ্রাধিকার refactoring: ঠিকানা সমালোচনামূলক (জ্ঞানী > 26) ফাংশন প্রথমে, তারপর "হাই friction" (16-25) ফাংশন। লক্ষ্য রিফ্যাক্টরিং অনুরোধ করুন: শুধু বলবেন না "এটি উন্নত করুন" বলুন "Refactor handleSrcAttribute লক্ষ্য আকারে জ্ঞানীয় জটিলতা হ্রাস করার জন্য"। After refactoring, re-run metrics. Ensure complexity actually decreased and maintainability increased. Sometimes ‘improvements’ just shuffle complexity around. Verify improvements: Before marking code as done, try to have all functions with a cognitive complexity < 15 and maintainability index > 65. Set quality gates: The Verdict এলএলএম জেনারেটেড কোডের 40,000 লাইন পরে, আমি সাবধানে আশাবাদী। কিন্তু মানব ডেভেলপারদের মতো, তাদের প্রয়োজন: Yes, LLMs can generate quality code. স্পষ্ট, বিস্তারিত স্পেসিফিকেশন কাঠামো সীমাবদ্ধতা (ফ্রেমওয়ার্ক, প্যাটার্ন) নিয়মিত পুনর্নির্দেশনা Objective quality measurements আর্কিটেকচার সিদ্ধান্তের বিভিন্ন দৃষ্টিভঙ্গি সমালোচনা যে এলএলএমগুলি পতন উত্পাদন করে তা ভুল নয় - কিন্তু এটি অসম্পূর্ণ। . unclear requirements, insufficient structure, and lack of quality enforcement পার্থক্য iteration গতি. যা একটি মানব দল নির্মাণ এবং refactor মাস লাগতে পারে, LLMs ঘন্টা মধ্যে অর্জন করতে পারেন. পরিষ্কার কাজ অব্যাহত থাকে, কিন্তু প্রাথমিক প্রজন্ম দ্রুত গতিশীল হয়. সামনে দৃষ্টি I'm skeptical that most humans will tolerate the time required to be clear and specific with LLMs - just as they don't today when product managers or developers push for detailed requirements from business staff. The desire to "vibe code" and iterate will persist. কিন্তু এখানে কী পরিবর্তন হয়েছে: The feedback loop has compressed from weeks to hours. We can now iterate and clean up faster when requirements evolve or prove insufficient. কোডিং পরিবেশগুলি আরও ভাল কাঠামোতে এলএলএমগুলি প্যাকেজ করার জন্য বিবর্তিত হয় - স্বয়ংক্রিয় মেট্রিক্স, বাধ্যতামূলক প্যাটার্ন, মাল্টি মডেল পর্যালোচনা - গুণমান উন্নত হবে। প্রকৃত প্রশ্নটি হল LLMs গুণমান কোড উত্পাদন করতে পারে কিনা না. এটা কি আমরা তাদের সরবরাহ করতে পারেন - এবং নিজেদের সঙ্গে - নিয়মিতভাবে এটি করতে। And, I have a final concern … if LLMs are based on history and have a tendency to stick with what they know, then how are we going to evolve the definition and use of things like UI libraries? Are we forever stuck with React unless we ask for something different? Or, are libraries an anachronism? Will LLMs and image or video models soon just generate the required image of a user interface with no underlying code? গেমটিতে তার দেরী প্রবেশের কারণে এবং এলএলএমগুলির ইতিমধ্যে অঙ্কন করার কারণে, আমি লাইটভিউর গ্রহণের জন্য উচ্চ আশা রাখি না, তবে এটি একটি আকর্ষণীয় পরীক্ষা ছিল। https://lightview.dev
