ମୁଁ କିପରି ଏକ /goal କମାଣ୍ଡ ତିଆରି କଲି ଏବଂ ଏହା ମୋ ପାଇଁ କିପରି କାମ କରେ

ମୋର ଅଧିକାଂଶ AI କୋଡିଂ ସେସନ୍ ସମାନ ଭାବରେ ଶେଷ ହେଉଥିଲା: ଏକ ଦୀର୍ଘ ଚାଟ୍, ଅଧା-ସରିଥିବା କାମ, ଏବଂ କ’ଣ ହୋଇଛି ଓ କ’ଣ ହୋଇନାହିଁ ତାହା ମନେ ରଖିବାକୁ ମୋର ଚେଷ୍ଟା। ତେଣୁ ମୁଁ ଏକ କମାଣ୍ଡ ତିଆରି କଲି ଯାହାର ନାମ /goal। ଆପଣ ଏହାକୁ ଗୋଟିଏ ବଡ଼ ଲକ୍ଷ୍ୟ ଦିଅନ୍ତୁ, ଏବଂ ସେହି ଲକ୍ଷ୍ୟ ସମ୍ପନ୍ନ ଓ ଯାଞ୍ଚ ନହେବା ପର୍ଯ୍ୟନ୍ତ, କିମ୍ବା ଏହା କୌଣସି ପ୍ରକୃତ ପ୍ରତିବନ୍ଧକର ସମ୍ମୁଖୀନ ନହେବା ପର୍ଯ୍ୟନ୍ତ ଏହା କାମ ଜାରି ରଖେ।

ଆଜି ହେଉଛି ନଭେମ୍ବର 9, 2026। ଏହା ଏବେ ଗୁରୁତ୍ୱପୂର୍ଣ୍ଣ କାରଣ AI ଆସିଷ୍ଟାଣ୍ଟମାନେ ଶୀଘ୍ର ବହୁତ କୋଡ୍ ଲେଖିପାରିବେ, ଏବଂ କଠିନ କାମଟି କୋଡ୍ ଲେଖିବାରୁ ଏହା ଉପରେ ବିଶ୍ୱାସ କରିବା ଦିଗକୁ ବଦଳି ଯାଇଛି। /goal ହେଉଛି ସେହି ସମସ୍ୟାର ମୋର ଉତ୍ତର।

/goal ପ୍ରକୃତରେ କ’ଣ

ଏହା କୌଣସି ପ୍ରୋଗ୍ରାମ ନୁହେଁ। ଏହା ଲିଖିତ ନିର୍ଦ୍ଦେଶାବଳୀର ଏକ ସେଟ୍ ଯାହାକୁ ଆସିଷ୍ଟାଣ୍ଟ ଅନୁସରଣ କରେ ଯେତେବେଳେ ମୁଁ ଟାଇପ୍ କରେ /goal ଏବଂ ତାହା ପରେ ଏକ ଲକ୍ଷ୍ୟ ଲେଖେ। ନିର୍ଦ୍ଦେଶଗୁଡ଼ିକ ଏକ ପ୍ରକ୍ରିୟା ବର୍ଣ୍ଣନା କରେ, ଯେପରି ଏକ ଚେକଲିଷ୍ଟ୍ ଏକ ରିଲିଜ୍ କିପରି କରିବାକୁ ହୁଏ ତାହା ବର୍ଣ୍ଣନା କରେ।

ଲକ୍ଷ୍ୟଟି ଗୋଟିଏ ବାକ୍ୟ ହୋଇପାରେ। ମୋର ସର୍ବଶେଷ ଲକ୍ଷ୍ୟ ଥିଲା: "ମୋ browser extension ପାଇଁ v1.1 ଯୋଜନାକୁ ସମ୍ପୂର୍ଣ୍ଣ ଭାବରେ, ପର୍ଯ୍ୟାୟ କ୍ରମେ କାର୍ଯ୍ୟକାରୀ କରନ୍ତୁ, ପ୍ରତି ପର୍ଯ୍ୟାୟରେ ଥରେ commit କରନ୍ତୁ, ଏବଂ ମୋ ଅନୁମତି ବିନା push କିମ୍ବା deploy କରନ୍ତୁ ନାହିଁ।" ସେହି ଗୋଟିଏ ବାକ୍ୟ ଦଶଟି ପର୍ଯ୍ୟାୟର କାମ, ପ୍ରାୟ ପଚିଶଟି commits କଭର୍ କରିଥିଲା।

ଗୋଟିଏ ଧାଡ଼ିରେ ମୂଳ ଧାରଣା

ବିଭିନ୍ନ କାମ ପାଇଁ ବିଭିନ୍ନ ମଡେଲ୍ ନିୟୋଜିତ ହୁଅନ୍ତି, ଏବଂ କେହି ନିଜ ହୋମୱାର୍କ ନିଜେ ଯାଞ୍ଚ କରନ୍ତି ନାହିଁ।

• ପ୍ଲାନିଂ ସବୁଠାରୁ ଶକ୍ତିଶାଳୀ planning model କୁ ଯାଏ। ଏହା ପ୍ରୋଜେକ୍ଟକୁ ପଢ଼େ, କ’ଣ ବାକି ଅଛି ତାହା କ୍ରମାନୁସାରେ ସଜାଏ, ଲକ୍ଷ୍ୟକୁ ବିଭିନ୍ନ ପର୍ଯ୍ୟାୟରେ ବିଭକ୍ତ କରେ, ଏବଂ ଏକ tracker ଫାଇଲ୍ ଲେଖେ।
• ନିର୍ମାଣ ଏକ ଦ୍ରୁତ, ଶସ୍ତା କୋଡିଂ ମଡେଲକୁ ଯାଏ। ପ୍ରତ୍ୟେକ ପର୍ଯ୍ୟାୟ ଏକ ନୂତନ agent ପାଏ ଯାହା tracker ରୁ ଆରମ୍ଭ ହୁଏ, ତେଣୁ କୌଣସି ପର୍ଯ୍ୟାୟ ପୂର୍ବ ପର୍ଯ୍ୟାୟର ଦୁର୍ବଳ ହୋଇଯାଇଥିବା ସ୍ମୃତି ଉପରେ ନିର୍ଭର କରେ ନାହିଁ।
• Critical କୋଡ୍ ସବୁଠାରୁ ସତର୍କ କୋଡିଂ ମଡେଲକୁ ଯାଏ। ଯେତେବେଳେ କୌଣସି ଟାସ୍କ ୟୁଜର୍ ଡାଟା ଡିଲିଟ୍ କରିବା, ଫାଇଲ୍ overwrite କରିବା, କିମ୍ବା release scripts ଭଳି ଜିନିଷକୁ ସ୍ପର୍ଶ କରେ, ମୁଁ ସେତେବେଳେ ତାହାକୁ critical ଭାବରେ ଚିହ୍ନିତ କରେ।
• ସମୀକ୍ଷା ଏକ ପୃଥକ read-only reviewer କୁ ଯାଏ। ଏହା କେବେବି କୋଡ୍ ଲେଖି ନଥାଏ। ଏହା diff ପଢ଼େ ଏବଂ ସମସ୍ୟାଗୁଡ଼ିକ ରିପୋର୍ଟ କରେ; ଏହା କିଛି ବି edit କରିପାରିବ ନାହିଁ।

ଏହା କିପରି ଚାଲେ, ପଦକ୍ଷେପ ଅନୁସାରେ ପଦକ୍ଷେପ

ଷ୍ଟେପ୍ 1: ପ୍ଲାନିଂ ପାସ୍

କୌଣସି କୋଡ୍ ପୂର୍ବରୁ, planner ପ୍ରୋଜେକ୍ଟକୁ ଯାଞ୍ଚ କରେ: ଖୋଲା ଥିବା ନୋଟ୍, ଅସମାପ୍ତ କାର୍ଯ୍ୟ, git state ଏବଂ build ଓ test ପାଇଁ ବ୍ୟବହୃତ commands। ତା’ପରେ ଏହା ଲକ୍ଷ୍ୟ, ଏକ checklist, ଏବଂ ପ୍ରତ୍ୟେକ ଆଇଟମ୍ ପାଇଁ ଏକ ଏକ-ଧାଡ଼ିଆ ଯାଞ୍ଚ ସହିତ ଏକ tracker ଫାଇଲ୍ ଲେଖେ ଯାହା ପ୍ରମାଣିତ ହୋଇପାରିବ, ଯେପରିକି ଏକ command ଯାହା ପାସ୍ ହେବା ଆବଶ୍ୟକ। ପ୍ରତ୍ୟେକ ଆଇଟମ୍ ମଧ୍ୟ ଏକ model tag ପାଏ। ଏହି tracker ହେଉଛି ସତ୍ୟର ଏକମାତ୍ର ଉତ୍ସ (single source of truth)। ଯଦି କଥାବାର୍ତ୍ତା ବହୁତ ଲମ୍ବା ହୋଇଯାଏ ଏବଂ assistant ଭୁଲିଯାଏ, ତଥାପି tracker ସବୁ ମନେ ରଖିଥାଏ।

ଏହା ନିଷ୍ପତ୍ତିଗୁଡ଼ିକୁ ମଧ୍ୟ ରେକର୍ଡ କରେ। ଯେତେବେଳେ ମୋ ଯୋଜନାରେ ଉତ୍ତର ନଥିବା କିଛି ଖୋଲା ପ୍ରଶ୍ନ ଥିଲା, tracker ପ୍ରତ୍ୟେକ ପାଇଁ ବାଛିଥିବା default ତାଲିକାଭୁକ୍ତ କରିଥିଲା, ଯାହାଫଳରେ ମୁଁ ପରେ ସେଗୁଡ଼ିକୁ ବଦଳାଇ ପାରିବି।

ଷ୍ଟେପ୍ 2: ପ୍ରତି ପର୍ଯ୍ୟାୟ ପାଇଁ ଗୋଟିଏ ନୂତନ agent

ପ୍ରତ୍ୟେକ ପର୍ଯ୍ୟାୟ ଏକ ନୂତନ agent ଦ୍ୱାରା ନିର୍ମିତ ହୁଏ। ଏହା କୋଡ୍ ଲେଖେ, build ଏବଂ tests ଚଲାଏ, ତ୍ରୁଟିଗୁଡ଼ିକ ସୁଧାରେ, ଏବଂ ଏକ ସରଳ ବାର୍ତ୍ତା ସହିତ ଗୋଟିଏ commit କରେ। ଏହା tracker ରେ ଥିବା ଏହାର ଆଇଟମ୍‌ଗୁଡ଼ିକୁ ଟିକ୍ କରେ। ତା’ପରେ ଏହା ବନ୍ଦ ହୁଏ, ଏବଂ ପରବର୍ତ୍ତୀ ପର୍ଯ୍ୟାୟ ଏକ clean slate ରୁ ଆରମ୍ଭ ହୁଏ।

ଷ୍ଟେପ୍ 3: ରିଭ୍ୟୁ ଗେଟ୍

ଯେତେବେଳେ ଏକ ପର୍ଯ୍ୟାୟ commit ହୁଏ, ଏକ ପୃଥକ reviewer tracker ର ଯାଞ୍ଚ ବିରୁଦ୍ଧରେ diff ପଢ଼େ। ଏହା କ୍ରମାନ୍ୱୟରେ ଚାରୋଟି ଜିନିଷ ଦେଖେ: କୋଡ୍ ପ୍ରକୃତରେ acceptance checks ପୂରଣ କରୁଛି କି, ଏହା ସୁରକ୍ଷିତ କି, ଏହା odd cases କୁ ସମ୍ଭାଳୁଛି କି, ଏବଂ docs ଗୁଡ଼ିକ କୋଡ୍ ଯାହା କରୁଛି ତାହା ସହିତ ମେଳ ଖାଉଛି କି। ଏହା ସମସ୍ୟାଗୁଡ଼ିକର ଏକ କ୍ରମାଙ୍କିତ ତାଲିକା ଫେରାଏ, ପ୍ରତ୍ୟେକରେ ଗୋଟିଏ ଫାଇଲ୍, ଗୋଟିଏ ଧାଡ଼ି ଏବଂ ଏକ ଏକ-ବାକ୍ୟ ବିଶିଷ୍ଟ failure scenario ଥାଏ।

ଷ୍ଟେପ୍ 4: Fix ଏବଂ ପୁନଃ-ସମୀକ୍ଷା

ନିଶ୍ଚିତ ହୋଇଥିବା ସମସ୍ୟାଗୁଡ଼ିକ fix tasks ଭାବରେ ଏକ ନୂତନ agent ନିକଟକୁ ଯାଏ। ସମାଧାନ ପରେ, reviewer ପୁଣି ଥରେ ଯାଞ୍ଚ କରେ। ସମାଧାନ ହୋଇନଥିବା ଏକ ନିଶ୍ଚିତ ସମସ୍ୟା ଥିବା ପର୍ଯ୍ୟାୟକୁ done ଭାବରେ ଚିହ୍ନିତ କରାଯାଇପାରିବ ନାହିଁ, ଏବଂ ସମଗ୍ର ଲକ୍ଷ୍ୟକୁ complete ବୋଲି କୁହାଯାଇପାରିବ ନାହିଁ।

ଷ୍ଟେପ୍ 5: ସତ୍ୟନିଷ୍ଠ ରିପୋର୍ଟ

ଶେଷରେ ମୁଁ ଏକ ରିପୋର୍ଟ ପାଏ ଯାହା କେବଳ ସେତିକିବେଳେ COMPLETE ବୋଲି କୁହେ ଯଦି ପ୍ରତ୍ୟେକ ମାନଦଣ୍ଡ ପୂରଣ ହୋଇଥାଏ ଏବଂ ପ୍ରତ୍ୟେକ ଯାଞ୍ଚ green ହୋଇଥାଏ। ଅନ୍ୟଥା ଏହା PARTIAL ବୋଲି କୁହେ ଏବଂ ପ୍ରକୃତରେ କ’ଣ ବାକି ଅଛି ତାହା ତାଲିକାଭୁକ୍ତ କରେ। ରିପୋର୍ଟ କେବେବି ଅତିରଞ୍ଜିତ କରି ଦର୍ଶାଏ ନାହିଁ।

ଏକ ପ୍ରକୃତ ପ୍ରୋଜେକ୍ଟରେ ଏହା କ’ଣ ଧରିପାରିଲା

ପ୍ରୋଜେକ୍ଟଟି ଏକ ବ୍ୟକ୍ତିଗତ browser extension ଥିଲା ଯାହା ଏକ ବ୍ରାଉଜର୍ ଟ୍ୟାବ୍‌ର ଅଡିଓ ରେକର୍ଡ କରେ। ନୂତନ ସଂସ୍କରଣଟି ରେକର୍ଡିଂଗୁଡ଼ିକୁ ବ୍ରାଉଜରର ପ୍ରାଇଭେଟ୍ ଫାଇଲ୍ ସିଷ୍ଟମରେ ସାଇତି ରଖିଲା, ମୋତେ ନାମ ଅନୁସାରେ ଫୋଲ୍ଡରରେ ସେଭ୍ କରିବାକୁ ଅନୁମତି ଦେଲା, ଭିଡିଓ ଫାଇଲଗୁଡ଼ିକୁ ମରାମତି କଲା, ଏବଂ ଏକ library page ଯୋଡ଼ିଲା।

Reviewers ମାନେ ଏପରି ପ୍ରକୃତ bugs ପାଇଲେ ଯାହା tests ମାନେ ଧରିପାରି ନଥିଲେ:

• ଫୋଲ୍ଡର୍-ସେଭ୍ ଫିଚରଟି ପ୍ରତ୍ୟେକ ଥର ନୀରବରେ ପୁରୁଣା Save As ଡାଏଲଗ୍ କୁ ଫେରି ଯାଇଥାନ୍ତା। ଯେଉଁ background page ରେ ସେଭ୍ ଚାଲୁଥିଲା ତାହା extension settings ପଢ଼ିପାରିବ ନାହିଁ, ତେଣୁ କୋଡ୍ ଚୁପଚାପ୍ default ବାଛି ନେଇଥିଲା। Tests ଗୁଡ଼ିକ ପାସ୍ ହୋଇଗଲା କାରଣ ସେମାନେ ଏକ ନକଲି settings store ବ୍ୟବହାର କରିଥିଲେ।
• ଏକ repair step ଏକ ଛୋଟ ଫାଇଲ୍ ତିଆରି କରିପାରିଥାନ୍ତା ଯାହା ତଥାପି ଏହାର ନିଜସ୍ୱ ଯାଞ୍ଚଗୁଡ଼ିକୁ ପାସ୍ କରିଥାନ୍ତା ଏବଂ ତା’ପରେ ମୂଳ ଫାଇଲକୁ replace କରିଦେଇଥାନ୍ତା।
• ପୁନରୁଦ୍ଧାର ହୋଇଥିବା ରେକର୍ଡିଂଗୁଡ଼ିକ ସେମାନଙ୍କର ଫାଇଲ୍ ନାମରେ ଭୁଲ୍ ଅବଧି ପାଇଲା, କାରଣ ଏକ repaired ଫାଇଲର ଏକ ନୂତନ modification date ଥାଏ।
• ଏକ ବିଫଳ write ନୀରବରେ ଏକ ରେକର୍ଡିଂର ଅବଶିଷ୍ଟ ଅଂଶକୁ drop କରିଦେଇପାରିଥାନ୍ତା।

ଏଥିମଧ୍ୟରୁ କୌଣସିଟି ବି ଅସ୍ୱାଭାବିକ ନଥିଲା। ପ୍ରତ୍ୟେକଟି ସପ୍ତାହ ପରେ ଏକ ହଜିଯାଇଥିବା, ଛୋଟ ହୋଇଯାଇଥିବା କିମ୍ବା ଭୁଲ୍ ନାମ ଥିବା ରେକର୍ଡିଂ ଭାବରେ ସାମ୍ନାକୁ ଆସିଥାନ୍ତା।

ଏଥିରେ ମୁଁ ଲେଖିଥିବା ନିୟମଗୁଡ଼ିକ

• ପ୍ରଶ୍ନ ପଚାରିବା ପାଇଁ ଅଟକନ୍ତୁ ନାହିଁ। ନିଷ୍ପତ୍ତି ନିଅନ୍ତୁ, tracker ରେ ନିଷ୍ପତ୍ତି ଲେଖନ୍ତୁ, ଏବଂ ଜାରି ରଖନ୍ତୁ।
• ଏହାର ବ୍ୟତିକ୍ରମ ହେଉଛି ବାହ୍ୟ-ମୁଖୀ କିମ୍ବା ବିନାଶକାରୀ କାର୍ଯ୍ୟ: pushing, deploying, ମେସେଜ୍ ପଠାଇବା, ଡାଟା ଡିଲିଟ୍ କରିବା, କିମ୍ବା ମୋ ପାସୱାର୍ଡ ଆବଶ୍ୟକ କରୁଥିବା ଯେକୌଣସି ଜିନିଷ। ସେଗୁଡ଼ିକ ମୁଁ ଚଳାଇବାକୁ ଥିବା ସଠିକ୍ command ସହିତ blocked items ପାଲଟିଯାଏ।
• କୌଣସି failing check କୁ ପାସ୍ କରାଇବା ପାଇଁ ତାହାକୁ କେବେବି disable କରନ୍ତୁ ନାହିଁ, ଏବଂ ଏକ failing test କୁ କେବେବି delete କରନ୍ତୁ ନାହିଁ।
• କୌଣସି ଅସମ୍ପୃକ୍ତ clean-ups ନାହିଁ। କେବଳ ସେହି କୋଡ୍ ଯାହା ଲକ୍ଷ୍ୟ ପାଇଁ କାମ କରେ।
• ମୁଁ କୌଣସି flag ପାସ୍ ନକରିବା ପର୍ଯ୍ୟନ୍ତ କିମ୍ବା ନକହିବା ପର୍ଯ୍ୟନ୍ତ କେବେବି push କିମ୍ବା release କରନ୍ତୁ ନାହିଁ।

ଉପସଂହାର

/goal ମୋ ପାଇଁ କାମ କରେ କାରଣ ଏହା ଏକ ଅସ୍ପଷ୍ଟ ଇଚ୍ଛାକୁ ପ୍ରମାଣଯୋଗ୍ୟ ପଦକ୍ଷେପଗୁଡ଼ିକର ଏକ ଟ୍ରାକ୍ କରାଯାଇଥିବା ତାଲିକାରେ ପରିଣତ କରେ, ଏବଂ କାରଣ ଯେଉଁ ବ୍ୟକ୍ତି ଏକ ଅଂଶ ନିର୍ମାଣ କରନ୍ତି ସେ କେବେବି ତାହାକୁ ଅନୁମୋଦନ କରୁଥିବା ବ୍ୟକ୍ତି ନୁହଁନ୍ତି। ଏହା assistant କୁ ଅଧିକ ବୁଦ୍ଧିମାନ କରେ ନାହିଁ। ଏହା ଫଳାଫଳକୁ ଅଧିକ ବିଶ୍ୱସନୀୟ କରେ ଏବଂ ମୋ ନିଜର ଧ୍ୟାନର ଆବଶ୍ୟକତାକୁ କମାଇଦିଏ।

ସୁବିଧାଗୁଡ଼ିକ

• ଇନପୁଟ୍‌ର ଗୋଟିଏ ବାକ୍ୟ ଏକ ବୃହତ, ବହୁ-ପର୍ଯ୍ୟାୟ ବିଶିଷ୍ଟ କାର୍ଯ୍ୟକୁ ପରିଚାଳିତ କରିପାରିବ।
• ଦୀର୍ଘ ସେସନ୍ ଏବଂ context loss ସତ୍ତ୍ୱେ tracker ତିଷ୍ଠି ରହିଥାଏ।
• ସ୍ୱତନ୍ତ୍ର ସମୀକ୍ଷା ଏପରି bugs ଖୋଜି ବାହାର କରେ ଯାହା ଲେଖକଙ୍କ ନିଜସ୍ୱ tests ଧରିବାରେ ବିଫଳ ହୁଏ।
• ପ୍ରତ୍ୟେକ ପର୍ଯ୍ୟାୟ ହେଉଛି ଗୋଟିଏ ଛୋଟ commit, ତେଣୁ history ପଢ଼ିବା ଏବଂ undo କରିବା ସହଜ।
• ଚୂଡ଼ାନ୍ତ ରିପୋର୍ଟଟି କ’ଣ ଯାଞ୍ଚ ହୋଇଥିଲା ଏବଂ କ’ଣ ଯାଞ୍ଚ ହୋଇନଥିଲା ସେ ସମ୍ବନ୍ଧରେ ସତ୍ୟନିଷ୍ଠ ରହିଥାଏ।
• Pushing ଏବଂ deploying ଭଳି ବିପଦପୂର୍ଣ୍ଣ କାର୍ଯ୍ୟଗୁଡ଼ିକ ମୋ ନିୟନ୍ତ୍ରଣରେ ରହିଥାଏ।

ଅସୁବିଧାଗୁଡ଼ିକ

• ଏହା ମନ୍ଥର। ଏହି ପ୍ରୋଜେକ୍ଟଟି ବହୁତ ଘଣ୍ଟା ସମୟ ନେଇଥିଲା କାରଣ ପ୍ରତ୍ୟେକ ପର୍ଯ୍ୟାୟରେ ଏକ build, review ଏବଂ fix loop ଥାଏ।
• ଏହା ବହୁତ ପରିମାଣର tokens ବ୍ୟବହାର କରେ, କାରଣ ଏକାଧିକ agents ସମାନ କୋଡ୍ ପଢ଼ନ୍ତି।
• Reviewers ମାନେ ଅସଂଖ୍ୟ ଛୋଟ ଛୋଟ edge cases ଖୋଜି ପାରନ୍ତି, ତେଣୁ ଆପଣଙ୍କୁ review rounds ଉପରେ ଏକ ସୀମା ରଖିବାକୁ ପଡ଼ିବ।
• ଏକ fake environment ରେ ଚାଲୁଥିବା tests ଗୁଡ଼ିକ real-device ବ୍ୟବହାର ପ୍ରମାଣ କରିପାରିବ ନାହିଁ। କିଛି checks ପାଇଁ ଏବେ ବି ଜଣେ ବ୍ୟକ୍ତିଙ୍କ ଆବଶ୍ୟକତା ଥାଏ।
• ଏକ ଦୁର୍ବଳ ଲକ୍ଷ୍ୟ ବିବରଣୀ ଏକ ଦୁର୍ବଳ ଯୋଜନା ପ୍ରସ୍ତୁତ କରେ। ଯଦି ଲକ୍ଷ୍ୟ ଅସ୍ପଷ୍ଟ ଥାଏ ତେବେ କମାଣ୍ଡ ତାହାକୁ ଠିକ୍ କରିପାରିବ ନାହିଁ।

ସତର୍କତା

ଏହି ଆର୍ଟିକିଲ୍‌ଟି ଶିକ୍ଷଣୀୟ ଏବଂ ମୋର ନିଜସ୍ୱ setup ବର୍ଣ୍ଣନା କରେ। ନାମ, paths ଏବଂ ପ୍ରୋଜେକ୍ଟ ବିବରଣୀ ସାଧାରଣୀକରଣ କରାଯାଇଛି, ଏବଂ ଆପଣଙ୍କର ନିଜ commands ରେ ଥିବା ଯେକୌଣସି placeholder ମୂଲ୍ୟକୁ ଆପଣଙ୍କର ନିଜ ମୂଲ୍ୟ ସହିତ ବଦଳାଇବାକୁ ପଡ଼ିବ। Model names ଏବଂ tool behaviour ବାରମ୍ବାର ପରିବର୍ତ୍ତିତ ହୁଏ, ତେଣୁ ଗୁରୁତ୍ୱପୂର୍ଣ୍ଣ କାର୍ଯ୍ୟ ପାଇଁ ଏହା ଉପରେ ନିର୍ଭର କରିବା ପୂର୍ବରୁ ପ୍ରତ୍ୟେକ ଦାବିକୁ ଯାଞ୍ଚ କରନ୍ତୁ ଏବଂ ଏକ ଛୋଟ, କମ୍ ବିପଦ ଥିବା ପ୍ରୋଜେକ୍ଟରେ ପ୍ରକ୍ରିୟାଟିକୁ ପରୀକ୍ଷା କରନ୍ତୁ।

ବାରମ୍ବାର ପଚରାଯାଉଥିବା ପ୍ରଶ୍ନଗୁଡ଼ିକ

• ଏକ /goal କମାଣ୍ଡ କ’ଣ? — ଏହା ସଂରକ୍ଷିତ ନିର୍ଦ୍ଦେଶାବଳୀର ଏକ ସେଟ୍ ଯାହା ଏକ AI କୋଡିଂ ଆସିଷ୍ଟାଣ୍ଟକୁ ଗୋଟିଏ ବଡ଼ ଲକ୍ଷ୍ୟର ଯୋଜନା କରିବା, ନିର୍ମାଣ କରିବା, ସମୀକ୍ଷା କରିବା ଏବଂ ଯାଞ୍ଚ କରିବା ପାଇଁ ବାଧ୍ୟ କରେ, ତା’ପରେ ସତ୍ୟନିଷ୍ଠ ଭାବରେ ରିପୋର୍ଟ ଦିଏ।
• ଏହା ଏକ ପ୍ରୋଗ୍ରାମ କିମ୍ବା ପ୍ଲଗଇନ୍ କି? — ନା। ଏହା ଏକ କମାଣ୍ଡ ଫାଇଲରେ ଏକ ଲିଖିତ ପ୍ରକ୍ରିୟା ଯାହାକୁ ଆସିଷ୍ଟାଣ୍ଟ ଅନୁସରଣ କରେ, ତେଣୁ ଆପଣ ଯେକୌଣସି ଟେକ୍ସଟ୍ ଡକ୍ୟୁମେଣ୍ଟ ଭଳି ଏହାକୁ edit କରିପାରିବେ।
• ପ୍ରତ୍ୟେକ କାମ ପାଇଁ ଏକ ଭିନ୍ନ ମଡେଲ୍ କାହିଁକି ବ୍ୟବହାର କରିବେ? — Planning, routine coding ଏବଂ ସତର୍କ review ପାଇଁ ବିଭିନ୍ନ ଦକ୍ଷତା ଆବଶ୍ୟକ, ଏବଂ ପ୍ରତ୍ୟେକ ପାଇଁ ସଠିକ୍ ମଡେଲ୍ ବ୍ୟବହାର କରିବା ଦ୍ୱାରା ଖର୍ଚ୍ଚ କମିଥାଏ ଓ ଗୁଣବତ୍ତା ବୃଦ୍ଧି ପାଇଥାଏ।
• ପ୍ରତ୍ୟେକ ପର୍ଯ୍ୟାୟ ପାଇଁ ଏକ ନୂତନ agent କାହିଁକି? — ଏକ ଦୀର୍ଘ, ଆଂଶିକ ଭୁଲିଯାଇଥିବା କଥାବାର୍ତ୍ତା ପରିବର୍ତ୍ତେ ଏକ ନୂତନ agent tracker ରୁ ଆରମ୍ଭ ହୁଏ, ଯାହା drift ଏବଂ ପୁରୁଣା ଅନୁମାନକୁ ଏଡ଼ାଇଥାଏ।
• Reviewer କାହିଁକି builder ଠାରୁ ପୃଥକ ହେବା ଆବଶ୍ୟକ? — ଜଣେ ଲେଖକ ନିଜ କାମକୁ ଅଧିକ ବିଶ୍ୱାସ କରିବାର ପ୍ରବୃତ୍ତି ରଖନ୍ତି, ତେଣୁ ଯେଉଁ ପାଠକ କୋଡ୍ ଲେଖି ନାହାଁନ୍ତି ସେ ଏପରି ସମସ୍ୟା ଖୋଜି ପାଆନ୍ତି ଯାହା ଲେଖକ ଦେଖିବାରେ ବିଫଳ ହୁଅନ୍ତି।
• ଏହା ନିଜେ ନିଜେ କୋଡ୍ deploy କିମ୍ବା push କରେ କି? — ନା। Pushing, releasing ଏବଂ deploying ପାଇଁ ମୋର ସ୍ପଷ୍ଟ ଅନୁମୋଦନ ଆବଶ୍ୟକ, ଏବଂ କମାଣ୍ଡ ତାହା ବଦଳରେ ସେଗୁଡ଼ିକୁ blocked steps ଭାବରେ ତାଲିକାଭୁକ୍ତ କରେ।
• ଯେତେବେଳେ ଏହା କିଛି ଶେଷ କରିପାରେ ନାହିଁ ସେତେବେଳେ ଏହା କ’ଣ କରେ? — ଏହା ଆଇଟମକୁ blocked ଭାବରେ ଚିହ୍ନିତ କରେ, ସଠିକ୍ ତ୍ରୁଟି ଏବଂ କ’ଣ ଏହାକୁ unblock କରିବ ତାହା ଲେଖେ, ଏବଂ ଅନ୍ୟ ସ୍ୱାଧୀନ କାର୍ଯ୍ୟ ଆଡ଼କୁ ଆଗେଇ ଯାଏ।
• ଏଥିପାଇଁ ଅତିରିକ୍ତ ସମୟ ଦେବା କ’ଣ ଯଥାର୍ଥ? — ବଡ଼ କିମ୍ବା ବିପଦପୂର୍ଣ୍ଣ ପରିବର୍ତ୍ତନ ପାଇଁ, ହଁ, କାରଣ review rounds ଗୁଡ଼ିକ ଶୀଘ୍ର bugs ଧରିଥାଏ। ଏକ ଛୋଟ ସମାଧାନ ପାଇଁ, ଏକ ସାଧାରଣ chat ଅଧିକ ଦ୍ରୁତ।

ଟ୍ୟାଗ୍‌ଗୁଡ଼ିକ

#ClaudeCode #AICoding #DeveloperWorkflow #CodeReview #Automation #SoftwareEngineering #AIAgents #Productivity #DevTools #BuildInPublic