Tutorial 4 Prompting and Reviewing bn

টিউটোরিয়াল ৪ · প্রম্পটিং ও রিভিউ

লক্ষ্য: মেটা-দক্ষতা। আপনি এখন একটি এজেন্ট দিয়ে একটি feature তৈরি করতে পারেন — এই অধ্যায় সেটা মসৃণভাবে ও বারবার করা নিয়ে: এমন prompt লেখা যা প্রথমবারেই কাজ করে, diff দক্ষতার সঙ্গে review করা, সব উল্টে গেলে iterate করা, এবং একাধিক session জুড়ে গতি ধরে রাখা।

← পূর্ববর্তী: টিউটোরিয়াল ৩ আপনার প্রথম এজেন্ট টাস্ক · পরবর্তী: টিউটোরিয়াল ৫ লোকালাইজেশন

---

একটি search box নয়, একজন লিডের মতো prompt দিন

এজেন্ট একজন দ্রুত, আক্ষরিক, উৎসাহী junior ইঞ্জিনিয়ার। একজন ভালো junior-কে যেভাবে নেতৃত্ব দিতেন, সেভাবেই একে নেতৃত্ব দিন:

• লক্ষ্য এবং constraint বলুন। "endorse যোগ করো" দুর্বল। "connect pattern অনুসরণ করে endorse যোগ করো, শুধু seeded RNG, test সহ, গেট সবুজ থাকে" শক্তিশালী। Constraint-ই হলো এমন কোড পাওয়ার উপায় যা মানানসই।
• উদাহরণ দেখান। "renderConnect যে pattern ব্যবহার করে সেটা অনুসরণ করো" একটি অনুচ্ছেদের বর্ণনার চেয়ে ভালো। বিদ্যমান কোডই সেরা spec।
• edit-এর আগে একটি plan চান যেকোনো non-trivial কাজে। একটি plan পুনর্নির্দেশ করা সস্তা; দশটি edit করা ফাইল আনডু করা ব্যয়বহুল।
• প্রতি prompt-এ একটি কাজ। "endorse যোগ করো, RNG-ও refactor করো, README-ও update করো" একত্র করলে জট পাকানো diff হয় যা review করা কঠিন।
• তাকে test গেট দিন। "npm test চালাও এবং সবুজ না হওয়া পর্যন্ত সম্পন্ন ভেবো না" এজেন্টকে এমন কিছুতে পরিণত করে যা নিজের কাজ নিজে যাচাই করে।

প্রতিবার diff review করুন

গতিই একটি এজেন্টের মূল কথা — কিন্তু না-পড়া গতিই এমন উপায় যেভাবে bug ship হয়। একটি দ্রুত, সামঞ্জস্যপূর্ণ review প্রতিবর্তী অভ্যাস গড়ুন:

1. Scope: এটি কি শুধু যা বদলানো উচিত তাই বদলেছে? সম্পর্কহীন সরানো line একটি গন্ধ।
2. Pattern: এটি কি আশপাশের কোডের সঙ্গে মেলে, কোনো নতুন dependency ও src/-এর ভেতরে কোনো I/O ছাড়া?
3. প্রকল্পের নিয়ম: এই repo-র জন্য, সেটা হলো শুধু seeded RNG (diff-এ Math.random grep করুন), ব্যবহারকারী-দৃশ্যমান text language bundle-এ (hardcode নয়), এবং card line কখনো সেই width ছাড়ায় না যেখানে layout pad করে।
4. Accessibility: নতুন output কি --accessible-এ টিকে থাকে? lockedin --accessible <your command> চালান এবং দেখুন এটি পরিচ্ছন্ন plain text হিসেবে পড়ে কিনা — a11yFilter পেরিয়ে কোনো নতুন decorative glyph লুকিয়ে যাচ্ছে না।
5. Test: একটি নতুন test আছে কি, এবং feature ভাঙলে সেটি কি সত্যিই fail হবে? জিজ্ঞেস করুন: "এই নতুন test-কে fail করাতে আমি কোন line বদলাব?"
6. চালান: npm test, তারপর কমান্ডটি চালান এবং output-টা দেখুন।

আপনাকে প্রতিটি অক্ষর বুঝতে হবে না — কিন্তু আপনাকে প্রতিটি সিদ্ধান্ত বুঝতে হবে। একটি পরিবর্তন ব্যাখ্যা করতে না পারলে, গ্রহণ করার আগে এজেন্টকে সেটা ব্যাখ্যা করতে বলুন।

সবুজ না হলে iterate করুন

একটি লাল গেট একটি স্বাভাবিক ধাপ, ব্যর্থতা নয়। সমাধান হলো নিখুঁত feedback:

"npm test এই দিয়ে ফেল হয়: [paste the exact error]। renderEndorse width test প্রত্যাশা করে প্রতিটি card line ≤ ৬০ visible column। test দুর্বল না করে এটি fix করো।"

আসল error text paste করুন। "এটা ভাঙা" এজেন্টকে অনুমান করায়; stack trace তাকে fix করায়। এবং নতুন করে শুরু করার বদলে একই conversation চালিয়ে যাওয়া পছন্দ করুন — এজেন্টের কাছে সে এইমাত্র যা লিখেছে তার context আছে। দুই-তিনটি iteration converge না করলে, পিছিয়ে এসে re-scope করুন: কাজটি একটি prompt-এর পক্ষে হয়তো খুব বড়।

Session জুড়ে গতি ধরে রাখুন

আসল কাজ একাধিক বৈঠকে ছড়িয়ে থাকে। দুটি অভ্যাস একটি এজেন্টকে সময়ের সঙ্গে কার্যকর রাখে:

• Memory / convention। আপনার এজেন্ট যদি স্থায়ী memory বা একটি project instructions ফাইল সমর্থন করে, সেখানে যে নিয়ম তার সবসময় মানা উচিত তা লিখে রাখুন (যেমন "সমস্ত randomness অবশ্যই pick/shuffle ব্যবহার করবে", "সম্পন্ন ঘোষণার আগে npm test চালাও")। আপনি প্রতিটি prompt-এর বদলে একবার একটি convention বলেন।
• একটি handoff note। এই repo একটি সংক্ষিপ্ত, sanitized status doc রাখে docs/HANDOFF.md-এ: প্রকল্পটি কী, কীভাবে তৈরি, কীভাবে test করা, এবং পরে কী। আপনি ফিরে এলে (বা একজন সহকর্মী — বা আরেকটি এজেন্ট-এর কাছে হস্তান্তর করলে), ওই note সেকেন্ডে context পুনর্গঠন করে। এজেন্টকে বলুন একটি পরিবর্তনের অংশ হিসেবে এটি আপ-টু-ডেট রাখতে।

রাখার মতো Guardrail

• গেট আপসহীন। কিছু ship করার আগে সবুজ test। এটাই আপনাকে দ্রুত এগোতে এবং output-এ আস্থা রাখতে দেয়।
• আপনিই নথিভুক্ত reviewer। এজেন্ট লেখে; আপনি সিদ্ধান্ত নেন। একটি diff গ্রহণ করা মানে আপনি তার দায়িত্ব নিচ্ছেন।
• ছোট, যাচাইযোগ্য ধাপ একটি বিশাল লাফের চেয়ে ভালো। প্রতিটি গৃহীত পরিবর্তন অ্যাপটিকে চালু অবস্থায় রেখে যাওয়া উচিত।

---

✅ আপনার এজেন্ট দিয়ে করে দেখুন

1. একটি mentor কমান্ডের ("অযাচিত পরামর্শ বিতরণ করে") জন্য একটি এক-অনুচ্ছেদ spec লিখুন, constraint সহ, এবং এজেন্টকে দিয়ে test-first পদ্ধতিতে তৈরি করান — plan, test, code, গেট — প্রতিটি ধাপে review করে।
2. এজেন্টকে docs/HANDOFF.md update করতে বলুন যাতে নতুন কমান্ডের উল্লেখ থাকে।
3. ইচ্ছাকৃতভাবে কিছু ভাঙুন (যেমন একটি pool entry মুছে দিন), npm test চালান, এবং এজেন্টকে ঠিক failure খাইয়ে fix করানোর অনুশীলন করুন।

---

এরপর কোথায়

• src/lockedin.js-এর আসল কোড চোখ বুলান — আপনি এখন এর গঠন জানেন।
• প্রকল্পের নিজস্ব status ও architecture note-এর জন্য docs/HANDOFF.md পড়ুন।
• কমান্ড রেফারেন্স-এর রসিকতাগুলো উপভোগ করুন।

এটাই টিউটোরিয়াল। আপনি এখন একটি AI এজেন্টকে দিয়ে একটি test গেটের পেছনে সত্যিকারের software তৈরি ও বদলাতে নির্দেশ দিতে পারেন — কল্পনাযোগ্য সবচেয়ে অতি-আত্মবিশ্বাসী উদাহরণ দিয়ে। Agree? 👇