ನಾನು ಒಂದು /goal ಕಮಾಂಡನ್ನು ಹೇಗೆ ರೂಪಿಸಿದೆ ಮತ್ತು ಅದು ನನಗಾಗಿ ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ

ನನ್ನ ಹೆಚ್ಚಿನ AI ಕೋಡಿಂಗ್ ಸೆಷನ್‌ಗಳು ಇದೇ ರೀತಿಯಾಗಿ ಕೊನೆಗೊಳ್ಳುತ್ತಿದ್ದವು: ದೀರ್ಘವಾದ ಚಾಟ್, ಅರ್ಧಕ್ಕೆ ನಿಂತ ಕೆಲಸ, ಮತ್ತು ಏನಾಯಿತು ಹಾಗೂ ಏನಾಗಲಿಲ್ಲ ಎಂಬುದನ್ನು ನೆನಪಿಸಿಕೊಳ್ಳಲು ನಾನು ಪಡುವ ಕಷ್ಟ. ಆದ್ದರಿಂದ ನಾನು ರೂಪಿಸಿದ ಕಮಾಂಡ್ ಹೆಸರು /goal. ನೀವು ಅದಕ್ಕೆ ಒಂದು ದೊಡ್ಡ ಗುರಿಯನ್ನು ನೀಡಿದರೆ ಸಾಕು, ಆ ಗುರಿ ಪೂರ್ಣಗೊಂಡು ಪರಿಶೀಲನೆಯಾಗುವವರೆಗೆ ಅಥವಾ ಅದು ನಿಜವಾದ ತಡೆಯನ್ನು ಎದುರಿಸುವವರೆಗೆ ಅದು ಕೆಲಸ ಮಾಡುತ್ತಲೇ ಇರುತ್ತದೆ.

ಇಂದು ನವೆಂಬರ್ 9, 2026. ಇದು ಈಗ ಮುಖ್ಯವಾಗಿದೆ ಏಕೆಂದರೆ AI ಸಹಾಯಕರು ಬಹಳಷ್ಟು ಕೋಡ್ ಅನ್ನು ತ್ವರಿತವಾಗಿ ಬರೆಯಬಲ್ಲರು, ಮತ್ತು ಕಷ್ಟಕರವಾದ ಕೆಲಸವು ಕೋಡ್ ಬರೆಯುವುದರಿಂದ ಅದನ್ನು ನಂಬುವ ಕಡೆಗೆ ಬದಲಾಗಿದೆ. /goal ಎಂಬುದು ಆ ಸಮಸ್ಯೆಗೆ ನನ್ನ ಪರಿಹಾರವಾಗಿದೆ.

ವಾಸ್ತವವಾಗಿ /goal ಎಂದರೇನು

ಇದು ಯಾವುದೇ ಪ್ರೋಗ್ರಾಂ ಅಲ್ಲ. ನಾನು ಟೈಪ್ ಮಾಡಿದಾಗ ಸಹಾಯಕ ಅನುಸರಿಸುವ ಲಿಖಿತ ಸೂಚನೆಗಳ ಗುಚ್ಛವಿದು /goal ಅದರ ನಂತರ ಒಂದು ಗುರಿ ಇರುತ್ತದೆ. ಚೆಕ್‌ಲಿಸ್ಟ್ ಬಿಡುಗಡೆಯ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಹೇಗೆ ವಿವರಿಸುತ್ತದೆಯೋ, ಹಾಗೆಯೇ ಈ ಸೂಚನೆಗಳು ಒಂದು ಪ್ರಕ್ರಿಯೆಯನ್ನು ವಿವರಿಸುತ್ತವೆ.

ಗುರಿಯು ಒಂದೇ ವಾಕ್ಯವಾಗಿರಬಹುದು. ನನ್ನ ಇತ್ತೀಚಿನ ಗುರಿ ಹೀಗಿತ್ತು: "Implement the v1.1 plan for my browser extension in full, phase by phase, commit once per phase, and do not push or deploy without my go-ahead." ಆ ಒಂದೇ ವಾಕ್ಯವು ಕೆಲಸದ ಹತ್ತು ಹಂತಗಳನ್ನು ಮತ್ತು ಸುಮಾರು ಇಪ್ಪತ್ತೈದು commits ಒಳಗೊಂಡಿತ್ತು.

ಒಂದೇ ಸಾಲಿನಲ್ಲಿ ಈ ಕಲ್ಪನೆ

ವಿವಿಧ ಕೆಲಸಗಳಿಗೆ ವಿವಿಧ ಮಾಡೆಲ್‌ಗಳನ್ನು ಬಳಸಲಾಗುತ್ತದೆ, ಮತ್ತು ಯಾರೂ ತಮ್ಮ ಹೋಂವರ್ಕ್ ಅನ್ನು ತಾವೇ ತಿದ್ದಿಕೊಳ್ಳುವುದಿಲ್ಲ.

• ಪ್ಲಾನಿಂಗ್ ಅತ್ಯಂತ ಬಲಿಷ್ಠವಾದ ಪ್ಲಾನಿಂಗ್ ಮಾಡೆಲ್‌ಗೆ ಹೋಗುತ್ತದೆ. ಇದು ಪ್ರಾಜೆಕ್ಟ್ ಅನ್ನು ಓದುತ್ತದೆ, ಬಾಕಿಯಿರುವ ಕೆಲಸಗಳನ್ನು ಆದ್ಯತೆಯ ಮೇರೆಗೆ ಜೋಡಿಸುತ್ತದೆ, ಗುರಿಯನ್ನು ಹಂತಗಳಾಗಿ ವಿಭಜಿಸುತ್ತದೆ ಮತ್ತು ಟ್ರ್ಯಾಕರ್ ಫೈಲ್ ಅನ್ನು ಬರೆಯುತ್ತದೆ.
• ಬಿಲ್ಡಿಂಗ್ ವೇಗವಾದ ಮತ್ತು ಕಡಿಮೆ ವೆಚ್ಚದ ಕೋಡಿಂಗ್ ಮಾಡೆಲ್‌ಗೆ ಹೋಗುತ್ತದೆ. ಪ್ರತಿ ಹಂತಕ್ಕೂ ಟ್ರ್ಯಾಕರ್‌ನಿಂದ ಪ್ರಾರಂಭವಾಗುವ ಹೊಸ ಏಜೆಂಟ್ ಸಿಗುತ್ತದೆ, ಆದ್ದರಿಂದ ಯಾವುದೇ ಹಂತವು ಹಿಂದಿನ ಹಂತದ ಮರೆಯಾದ ನೆನಪಿನ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುವುದಿಲ್ಲ.
• ಕ್ರಿಟಿಕಲ್ ಕೋಡ್ ಅತ್ಯಂತ ಎಚ್ಚರಿಕೆಯ ಕೋಡಿಂಗ್ ಮಾಡೆಲ್‌ಗೆ ಹೋಗುತ್ತದೆ. ಬಳಕೆದಾರರ ಡೇಟಾ ಅಳಿಸುವುದು, ಫೈಲ್‌ಗಳನ್ನು ಓವರ್‌ರೈಟ್ ಮಾಡುವುದು ಅಥವಾ ರಿಲೀಸ್ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳಂತಹ ವಿಷಯಗಳಿಗೆ ಸಂಬಂಧಿಸಿದಾಗ ನಾನು ಕಾರ್ಯವನ್ನು ಕ್ರಿಟಿಕಲ್ ಎಂದು ಗುರುತಿಸುತ್ತೇನೆ.
• ರಿವ್ಯೂ ಪ್ರತ್ಯೇಕ ರೀಡ್-ಓನ್ಲಿ ರಿವ್ಯೂಯರ್‌ಗೆ ಹೋಗುತ್ತದೆ. ಇದು ಎಂದಿಗೂ ಕೋಡ್ ಬರೆದಿಲ್ಲ. ಇದು diff ಅನ್ನು ಓದುತ್ತದೆ ಮತ್ತು ಸಮಸ್ಯೆಗಳನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ; ಇದು ಯಾವುದನ್ನೂ ಎಡಿಟ್ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ.

ಇದು ಹಂತ ಹಂತವಾಗಿ ಹೇಗೆ ನಡೆಯುತ್ತದೆ

ಹಂತ 1: ಪ್ಲಾನಿಂಗ್ ಪಾಸ್

ಯಾವುದೇ ಕೋಡ್ ಬರೆಯುವ ಮೊದಲು, ಪ್ಲಾನರ್ ಪ್ರಾಜೆಕ್ಟ್ ಅನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ: ತೆರೆದ ಟಿಪ್ಪಣಿಗಳು, ಅಪೂರ್ಣ ಕೆಲಸ, git ಸ್ಥಿತಿ ಮತ್ತು ಬಿಲ್ಡ್ ಹಾಗೂ ಟೆಸ್ಟ್ ಮಾಡಲು ಬಳಸುವ ಕಮಾಂಡ್‌ಗಳು. ನಂತರ ಅದು ಗುರಿ, ಚೆಕ್‌ಲಿಸ್ಟ್ ಮತ್ತು ಪ್ರತಿ ಅಂಶಕ್ಕೂ ಪಾಸ್ ಆಗಲೇಬೇಕಾದ ಕಮಾಂಡ್‌ನಂತಹ ಸಾಬೀತುಪಡಿಸಬಹುದಾದ ಒಂದು ಸಾಲಿನ ಚೆಕ್‌ನೊಂದಿಗೆ ಟ್ರ್ಯಾಕರ್ ಫೈಲ್ ಬರೆಯುತ್ತದೆ. ಪ್ರತಿಯೊಂದು ಅಂಶಕ್ಕೂ ಮಾಡೆಲ್ ಟ್ಯಾಗ್ ಕೂಡ ಸಿಗುತ್ತದೆ. ಟ್ರ್ಯಾಕರ್ ಎಂಬುದು ಏಕೈಕ ಸತ್ಯದ ಮೂಲ (single source of truth). ಸಂಭಾಷಣೆ ತುಂಬಾ ದೀರ್ಘವಾಗಿ ಸಹಾಯಕ ಮರೆತುಹೋದರೂ, ಟ್ರ್ಯಾಕರ್‌ಗೆ ಎಲ್ಲವೂ ತಿಳಿದಿರುತ್ತದೆ.

ಇದು ತೆಗೆದುಕೊಂಡ ನಿರ್ಧಾರಗಳನ್ನೂ ದಾಖಲಿಸುತ್ತದೆ. ನನ್ನ ಪ್ಲಾನ್‌ನಲ್ಲಿ ನಾನು ಉತ್ತರಿಸದ ತೆರೆದ ಪ್ರಶ್ನೆಗಳಿದ್ದಾಗ, ಟ್ರ್ಯಾಕರ್ ಪ್ರತಿಯೊಂದಕ್ಕೂ ತಾನು ಆಯ್ಕೆಮಾಡಿದ ಡೀಫಾಲ್ಟ್ ಅನ್ನು ಪಟ್ಟಿ ಮಾಡಿದೆ, ಆದ್ದರಿಂದ ನಾನು ನಂತರ ಅವುಗಳನ್ನು ಬದಲಾಯಿಸಬಹುದು.

ಹಂತ 2: ಪ್ರತಿ ಹಂತಕ್ಕೂ ಒಂದು ಹೊಸ ಏಜೆಂಟ್

ಪ್ರತಿ ಹಂತವನ್ನು ಹೊಸ ಏಜೆಂಟ್ ನಿರ್ಮಿಸುತ್ತದೆ. ಇದು ಕೋಡ್ ಬರೆಯುತ್ತದೆ, ಬಿಲ್ಡ್ ಮತ್ತು ಟೆಸ್ಟ್‌ಗಳನ್ನು ರನ್ ಮಾಡುತ್ತದೆ, ವೈಫಲ್ಯಗಳನ್ನು ಸರಿಪಡಿಸುತ್ತದೆ ಮತ್ತು ಸರಳ ಸಂದೇಶದೊಂದಿಗೆ ಒಂದು ಕಮಿಟ್ ಮಾಡುತ್ತದೆ. ಇದು ಟ್ರ್ಯಾಕರ್‌ನಲ್ಲಿ ತನ್ನ ಅಂಶಗಳನ್ನು ಗುರುತಿಸುತ್ತದೆ. ನಂತರ ಅದು ನಿಲ್ಲುತ್ತದೆ, ಮತ್ತು ಮುಂದಿನ ಹಂತವು ಹೊಸದಾಗಿ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ.

ಹಂತ 3: ರಿವ್ಯೂ ಗೇಟ್

ಒಂದು ಹಂತವನ್ನು ಕಮಿಟ್ ಮಾಡಿದಾಗ, ಪ್ರತ್ಯೇಕ ರಿವ್ಯೂಯರ್ ಟ್ರ್ಯಾಕರ್‌ನ ತಪಾಸಣೆಗಳಿಗೆ ವಿರುದ್ಧವಾಗಿ diff ಅನ್ನು ಓದುತ್ತದೆ. ಅದು ಕ್ರಮವಾಗಿ ನಾಲ್ಕು ವಿಷಯಗಳನ್ನು ನೋಡುತ್ತದೆ: ಕೋಡ್ ನಿಜವಾಗಿಯೂ ಸ್ವೀಕಾರ ತಪಾಸಣೆಗಳನ್ನು ಪೂರೈಸುತ್ತದೆಯೇ, ಅದು ಸುರಕ್ಷಿತವಾಗಿದೆಯೇ, ವಿಚಿತ್ರ ಸನ್ನಿವೇಶಗಳನ್ನು ನಿಭಾಯಿಸುತ್ತದೆಯೇ, ಮತ್ತು ಡಾಕ್ಯುಮೆಂಟೇಶನ್ ಕೋಡ್ ಮಾಡುವ ಕೆಲಸಕ್ಕೆ ಹೊಂದಿಕೆಯಾಗುತ್ತದೆಯೇ. ಇದು ಸಮಸ್ಯೆಗಳ ಶ್ರೇಣೀಕೃತ ಪಟ್ಟಿಯನ್ನು ಹಿಂದಿರುಗಿಸುತ್ತದೆ, ಪ್ರತಿಯೊಂದೂ ಫೈಲ್, ಲೈನ್ ಮತ್ತು ಒಂದು ವಾಕ್ಯದ ವೈಫಲ್ಯದ ಸನ್ನಿವೇಶವನ್ನು ಹೊಂದಿರುತ್ತದೆ.

ಹಂತ 4: ಸರಿಪಡಿಸುವುದು ಮತ್ತು ಮರು-ಪರಿಶೀಲನೆ

ದೃಢಪಟ್ಟ ಸಮಸ್ಯೆಗಳು ಪರಿಹಾರ ಕಾರ್ಯಗಳಾಗಿ ಹೊಸ ಏಜೆಂಟ್‌ಗೆ ಹೋಗುತ್ತವೆ. ಸರಿಪಡಿಸಿದ ನಂತರ, ರಿವ್ಯೂಯರ್ ಮತ್ತೆ ಪರಿಶೀಲಿಸುತ್ತದೆ. ಬಗೆಹರಿಯದ ದೃಢಪಟ್ಟ ಸಮಸ್ಯೆಯನ್ನು ಹೊಂದಿರುವ ಹಂತವನ್ನು ಪೂರ್ಣಗೊಂಡಿದೆ ಎಂದು ಗುರುತಿಸಲಾಗುವುದಿಲ್ಲ, ಮತ್ತು ಸಂಪೂರ್ಣ ಗುರಿಯನ್ನು ಮುಗಿದಿದೆ ಎಂದು ಕರೆಯಲಾಗುವುದಿಲ್ಲ.

ಹಂತ 5: ಪ್ರಾಮಾಣಿಕ ವರದಿ

ಕೊನೆಯಲ್ಲಿ ಪ್ರತಿ ಮಾನದಂಡವು ಪೂರೈಸಲ್ಪಟ್ಟು ಮತ್ತು ಪ್ರತಿ ತಪಾಸಣೆಯು ಗ್ರೀನ್ ಆಗಿದ್ದಾಗ ಮಾತ್ರ COMPLETE ಎಂದು ಹೇಳುವ ವರದಿ ನನಗೆ ಸಿಗುತ್ತದೆ. ಇಲ್ಲದಿದ್ದರೆ ಅದು PARTIAL ಎಂದು ಹೇಳುತ್ತದೆ ಮತ್ತು ನಿಖರವಾಗಿ ಏನು ಬಿಟ್ಟುಹೋಗಿದೆ ಎಂಬುದನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ. ವರದಿಯು ಎಂದಿಗೂ ಉತ್ಪ್ರೇಕ್ಷೆ ಮಾಡುವುದಿಲ್ಲ.

ನೈಜ ಪ್ರಾಜೆಕ್ಟ್‌ನಲ್ಲಿ ಇದು ಏನನ್ನು ಪತ್ತೆಹಚ್ಚಿದೆ

ಆ ಪ್ರಾಜೆಕ್ಟ್ ಬ್ರೌಸರ್ ಟ್ಯಾಬ್‌ನ ಆಡಿಯೊವನ್ನು ರೆಕಾರ್ಡ್ ಮಾಡುವ ವೈಯಕ್ತಿಕ ಬ್ರೌಸರ್ ಎಕ್ಸ್‌ಟೆನ್ಶನ್ ಆಗಿತ್ತು. ಹೊಸ ಆವೃತ್ತಿಯು ರೆಕಾರ್ಡಿಂಗ್‌ಗಳನ್ನು ಬ್ರೌಸರ್‌ನ ಖಾಸಗಿ ಫೈಲ್ ಸಿಸ್ಟಮ್‌ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಿತು, ಹೆಸರಿನ ಪ್ರಕಾರ ಫೋಲ್ಡರ್‌ಗಳಲ್ಲಿ ಸೇವ್ ಮಾಡಲು ನನಗೆ ಅವಕಾಶ ನೀಡಿತು, ವೀಡಿಯೊ ಫೈಲ್‌ಗಳನ್ನು ರಿಪೇರಿ ಮಾಡಿತು ಮತ್ತು ಲೈಬ್ರರಿ ಪುಟವನ್ನು ಸೇರಿಸಿತು.

ಟೆಸ್ಟ್‌ಗಳು ಪತ್ತೆಹಚ್ಚದ ನೈಜ ಬಗ್‌ಗಳನ್ನು ರಿವ್ಯೂಯರ್‌ಗಳು ಕಂಡುಕೊಂಡಿದ್ದಾರೆ:

• ಫೋಲ್ಡರ್-ಸೇವ್ ವೈಶಿಷ್ಟ್ಯವು ಪ್ರತಿ ಬಾರಿಯೂ ಹಳೆಯ Save As ಡೈಲಾಗ್‌ಗೆ ಸದ್ದಿಲ್ಲದೆ ಹಿಂತಿರುಗುವ ಸಾಧ್ಯತೆಯಿತ್ತು. ಸೇವ್ ರನ್ ಆಗುವ ಬ್ಯಾಕ್‌ಗ್ರೌಂಡ್ ಪುಟವು ಎಕ್ಸ್‌ಟೆನ್ಶನ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಓದಲು ಸಾಧ್ಯವಿಲ್ಲ, ಆದ್ದರಿಂದ ಕೋಡ್ ಸದ್ದಿಲ್ಲದೆ ಡೀಫಾಲ್ಟ್ ಅನ್ನು ಆಯ್ಕೆಮಾಡಿಕೊಂಡಿತ್ತು. ನಕಲಿ ಸೆಟ್ಟಿಂಗ್ಸ್ ಸ್ಟೋರ್ ಬಳಸಿದ್ದರಿಂದ ಟೆಸ್ಟ್‌ಗಳು ಪಾಸ್ ಆಗಿದ್ದವು.
• ರಿಪೇರಿ ಹಂತವು ತನ್ನದೇ ಆದ ತಪಾಸಣೆಗಳಲ್ಲಿ ಪಾಸ್ ಆದರೂ ಕಡಿಮೆ ಗಾತ್ರದ ಫೈಲ್ ಅನ್ನು ರಚಿಸಿ, ನಂತರ ಮೂಲ ಫೈಲ್ ಅನ್ನು ಬದಲಾಯಿಸುವ ಅಪಾಯವಿತ್ತು.
• ಮರುಪಡೆಯಲಾದ ರೆಕಾರ್ಡಿಂಗ್‌ಗಳು ತಮ್ಮ ಫೈಲ್ ಹೆಸರುಗಳಲ್ಲಿ ತಪ್ಪು ಅವಧಿಯನ್ನು ಪಡೆದುಕೊಂಡವು, ಏಕೆಂದರೆ ರಿಪೇರಿ ಮಾಡಿದ ಫೈಲ್ ಹೊಸ ಮಾರ್ಪಾಡು ದಿನಾಂಕವನ್ನು ಹೊಂದಿರುತ್ತದೆ.
• ವಿಫಲವಾದ ಬರವಣಿಗೆಯ ಪ್ರಕ್ರಿಯೆಯು ರೆಕಾರ್ಡಿಂಗ್‌ನ ಉಳಿದ ಭಾಗವನ್ನು ಸದ್ದಿಲ್ಲದೆ ಕೈಬಿಡುವ ಸಾಧ್ಯತೆಯಿತ್ತು.

ಇವುಗಳಲ್ಲಿ ಯಾವುದೂ ಅಸಾಮಾನ್ಯವಾಗಿರಲಿಲ್ಲ. ಇವುಗಳಲ್ಲಿ ಪ್ರತಿಯೊಂದೂ ವಾರಗಳ ನಂತರ ರೆಕಾರ್ಡಿಂಗ್ ಕಾಣೆಯಾಗುವುದು, ಅಪೂರ್ಣವಾಗಿರುವುದು ಅಥವಾ ತಪ್ಪು ಹೆಸರನ್ನು ಹೊಂದಿರುವುದು ಎಂಬ ರೂಪದಲ್ಲಿ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತಿದ್ದವು.

ನಾನು ಇದರಲ್ಲಿ ಬರೆದ ನಿಯಮಗಳು

• ಪ್ರಶ್ನೆಗಳನ್ನು ಕೇಳಲು ನಿಲ್ಲಬೇಡಿ. ನಿರ್ಧರಿಸಿ, ನಿರ್ಧಾರವನ್ನು ಟ್ರ್ಯಾಕರ್‌ನಲ್ಲಿ ಬರೆಯಿರಿ ಮತ್ತು ಮುಂದುವರಿಯಿರಿ.
• ಬಾಹ್ಯ-ಮುಖಿ ಅಥವಾ ವಿನಾಶಕಾರಿ ಕ್ರಿಯೆಗಳು ಮಾತ್ರ ಇದಕ್ಕೆ ಅಪವಾದ: pushing, deploying, ಸಂದೇಶಗಳನ್ನು ಕಳುಹಿಸುವುದು, ಡೇಟಾವನ್ನು ಅಳಿಸುವುದು ಅಥವಾ ನನ್ನ ಪಾಸ್‌ವರ್ಡ್ ಅಗತ್ಯವಿರುವ ಯಾವುದೇ ಕ್ರಿಯೆ. ಅವು ನಾನು ರನ್ ಮಾಡಬೇಕಾದ ನಿಖರವಾದ ಕಮಾಂಡ್‌ನೊಂದಿಗೆ ನಿರ್ಬಂಧಿತ ಅಂಶಗಳಾಗುತ್ತವೆ (blocked items).
• ಫೇಲ್ ಆಗುತ್ತಿರುವ ತಪಾಸಣೆಯನ್ನು ಪಾಸ್ ಮಾಡಲು ಅದನ್ನು ಎಂದಿಗೂ ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಬೇಡಿ (disable), ಮತ್ತು ಫೇಲ್ ಆಗುತ್ತಿರುವ ಟೆಸ್ಟ್ ಅನ್ನು ಎಂದಿಗೂ ಅಳಿಸಬೇಡಿ.
• ಸಂಬಂಧವಿಲ್ಲದ ಕ್ಲೀನ್-ಅಪ್ ಬೇಡ. ಗುರಿಗೆ ನೆರವಾಗುವ ಕೋಡ್ ಮಾತ್ರ ಇರಲಿ.
• ನಾನು ಫ್ಲ್ಯಾಗ್ ಅನ್ನು ಪಾಸ್ ಮಾಡದಿದ್ದರೆ ಅಥವಾ ಹಾಗೆ ಹೇಳದಿದ್ದರೆ ಎಂದಿಗೂ push ಅಥವಾ release ಮಾಡಬೇಡಿ.

ಉಪಸಂಹಾರ

/goal ನನಗಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಏಕೆಂದರೆ ಇದು ಅಸ್ಪಷ್ಟ ಇಚ್ಛೆಯನ್ನು ಸಾಬೀತುಪಡಿಸಬಹುದಾದ ಹಂತಗಳ ಟ್ರ್ಯಾಕ್ ಮಾಡಲಾದ ಪಟ್ಟಿಯಾಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ, ಮತ್ತು ಒಂದು ಭಾಗವನ್ನು ನಿರ್ಮಿಸುವ ವ್ಯಕ್ತಿಯು ಅದನ್ನು ಅನುಮೋದಿಸುವ ವ್ಯಕ್ತಿಯಾಗಿರುವುದಿಲ್ಲ. ಇದು ಸಹಾಯಕವನ್ನು ಹೆಚ್ಚು ಬುದ್ಧಿವಂತನನ್ನಾಗಿ ಮಾಡುವುದಿಲ್ಲ. ಇದು ಫಲಿತಾಂಶವನ್ನು ಹೆಚ್ಚು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿಸುತ್ತದೆ ಮತ್ತು ನನ್ನ ಸ್ವಂತ ಗಮನದ ಅಗತ್ಯವನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.

ಪ್ರಯೋಜನಗಳು

• ಒಂದು ವಾಕ್ಯದ ಇನ್‌ಪುಟ್ ದೊಡ್ಡದಾದ, ಬಹು-ಹಂತದ ಕೆಲಸವನ್ನು ನಡೆಸಬಲ್ಲದು.
• ದೀರ್ಘ ಸೆಷನ್‌ಗಳು ಮತ್ತು ಸಂದರ್ಭದ ನಷ್ಟವನ್ನು (context loss) ಟ್ರ್ಯಾಕರ್ ತಡೆದುಕೊಳ್ಳುತ್ತದೆ.
• ಲೇಖಕರ ಸ್ವಂತ ಪರೀಕ್ಷೆಗಳು ತಪ್ಪಿಹೋದ ಬಗ್‌ಗಳನ್ನು ಸ್ವತಂತ್ರ ವಿಮರ್ಶೆಯು ಕಂಡುಕೊಳ್ಳುತ್ತದೆ.
• ಪ್ರತಿ ಹಂತವು ಒಂದು ಸಣ್ಣ commit ಆಗಿರುತ್ತದೆ, ಆದ್ದರಿಂದ ಇತಿಹಾಸವನ್ನು ಓದಲು ಮತ್ತು ರದ್ದುಗೊಳಿಸಲು (undo) ಸುಲಭವಾಗಿರುತ್ತದೆ.
• ಏನು ಪರಿಶೀಲಿಸಲಾಗಿದೆ ಮತ್ತು ಏನು ಪರಿಶೀಲಿಸಲಾಗಿಲ್ಲ ಎಂಬುದರ ಬಗ್ಗೆ ಅಂತಿಮ ವರದಿಯು ಪ್ರಾಮಾಣಿಕವಾಗಿರುತ್ತದೆ.
• pushing ಮತ್ತು deploying ನಂತಹ ಅಪಾಯಕಾರಿ ಕ್ರಮಗಳು ನನ್ನ ನಿಯಂತ್ರಣದಲ್ಲಿಯೇ ಇರುತ್ತವೆ.

ಅನನುಕೂಲಗಳು

• ಇದು ನಿಧಾನವಾಗಿರುತ್ತದೆ. ಈ ಪ್ರಾಜೆಕ್ಟ್‌ಗೆ ಹಲವು ಗಂಟೆಗಳು ಬೇಕಾದವು ಏಕೆಂದರೆ ಪ್ರತಿಯೊಂದು ಹಂತದಲ್ಲೂ ಬಿಲ್ಡ್, ರಿವ್ಯೂ ಮತ್ತು ಫಿಕ್ಸ್ ಲೂಪ್ ಇರುತ್ತದೆ.
• ಹಲವಾರು ಏಜೆಂಟ್‌ಗಳು ಒಂದೇ ಕೋಡ್ ಅನ್ನು ಓದುವುದರಿಂದ ಇದು ಬಹಳಷ್ಟು ಟೋಕನ್‌ಗಳನ್ನು ಬಳಸುತ್ತದೆ.
• ರಿವ್ಯೂಯರ್‌ಗಳು ಅಂತ್ಯವಿಲ್ಲದ ಸಣ್ಣ ಎಡ್ಜ್ ಕೇಸ್‌ಗಳನ್ನು ಹುಡುಕಬಹುದು, ಆದ್ದರಿಂದ ನೀವು ರಿವ್ಯೂ ಸುತ್ತುಗಳ ಮೇಲೆ ಮಿತಿಯನ್ನು ಹೊಂದಿರಬೇಕು.
• ನಕಲಿ ಪರಿಸರದಲ್ಲಿ ರನ್ ಆಗುವ ಪರೀಕ್ಷೆಗಳು ನೈಜ-ಸಾಧನದ ನಡವಳಿಕೆಯನ್ನು ಸಾಬೀತುಪಡಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಕೆಲವು ತಪಾಸಣೆಗಳಿಗೆ ಇನ್ನೂ ವ್ಯಕ್ತಿಯ ಅಗತ್ಯವಿರುತ್ತದೆ.
• ದುರ್ಬಲ ಗುರಿಯ ಹೇಳಿಕೆಯು ದುರ್ಬಲ ಯೋಜನೆಯನ್ನು ನೀಡುತ್ತದೆ. ಅಸ್ಪಷ್ಟವಾಗಿರುವ ಗುರಿಯನ್ನು ಈ ಕಮಾಂಡ್ ಸರಿಪಡಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ.

ಎಚ್ಚರಿಕೆ

ಈ ಲೇಖನವು ಶೈಕ್ಷಣಿಕ ಉದ್ದೇಶಕ್ಕಾಗಿ ಮತ್ತು ನನ್ನ ಸ್ವಂತ ಸೆಟಪ್ ಅನ್ನು ವಿವರಿಸುತ್ತದೆ. ಹೆಸರುಗಳು, ಪಾತ್‌ಗಳು ಮತ್ತು ಪ್ರಾಜೆಕ್ಟ್ ವಿವರಗಳನ್ನು ಸಾಮಾನ್ಯೀಕರಿಸಲಾಗಿದೆ, ಮತ್ತು ನಿಮ್ಮ ಸ್ವಂತ ಕಮಾಂಡ್‌ಗಳಲ್ಲಿನ ಯಾವುದೇ ಪ್ಲೇಸ್‌ಹೋಲ್ಡರ್ ಮೌಲ್ಯಗಳನ್ನು ನಿಮ್ಮದೇ ಆದ ಮೌಲ್ಯಗಳೊಂದಿಗೆ ಬದಲಾಯಿಸಬೇಕು. ಮಾಡೆಲ್ ಹೆಸರುಗಳು ಮತ್ತು ಟೂಲ್ ವರ್ತನೆಗಳು ಆಗಾಗ್ಗೆ ಬದಲಾಗುತ್ತವೆ, ಆದ್ದರಿಂದ ಪ್ರಮುಖ ಕೆಲಸಕ್ಕಾಗಿ ಇದರ ಮೇಲೆ ಅವಲಂಬಿತರಾಗುವ ಮೊದಲು ಪ್ರತಿಯೊಂದು ಅಂಶವನ್ನು ಪರಿಶೀಲಿಸಿ ಮತ್ತು ಸಣ್ಣ, ಕಡಿಮೆ ಅಪಾಯದ ಪ್ರಾಜೆಕ್ಟ್‌ನಲ್ಲಿ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಪರೀಕ್ಷಿಸಿ.

ಪದೇ ಪದೇ ಕೇಳಲಾಗುವ ಪ್ರಶ್ನೆಗಳು

• /goal ಕಮಾಂಡ್ ಎಂದರೇನು? — ಇದು AI ಕೋಡಿಂಗ್ ಸಹಾಯಕವು ಒಂದು ದೊಡ್ಡ ಗುರಿಯನ್ನು ಯೋಜಿಸಲು, ನಿರ್ಮಿಸಲು, ಪರಿಶೀಲಿಸಲು ಮತ್ತು ದೃಢೀಕರಿಸಲು ಹಾಗೂ ಪ್ರಾಮಾಣಿಕವಾಗಿ ವರದಿ ಮಾಡಲು ನಿರ್ದೇಶಿಸುವ ಉಳಿಸಲಾದ ಸೂಚನೆಗಳ ಗುಚ್ಛವಾಗಿದೆ.
• ಇದು ಪ್ರೋಗ್ರಾಂ ಅಥವಾ ಪ್ಲಗಿನ್ ಆಗಿದೆಯೇ? — ಅಲ್ಲ. ಇದು ಸಹಾಯಕವು ಅನುಸರಿಸುವ ಕಮಾಂಡ್ ಫೈಲ್‌ನಲ್ಲಿರುವ ಲಿಖಿತ ಪ್ರಕ್ರಿಯೆಯಾಗಿದೆ, ಆದ್ದರಿಂದ ನೀವು ಇದನ್ನು ಯಾವುದೇ ಪಠ್ಯ ದಾಖಲೆಯಂತೆ ಎಡಿಟ್ ಮಾಡಬಹುದು.
• ಪ್ರತಿ ಕೆಲಸಕ್ಕೂ ವಿಭಿನ್ನ ಮಾಡೆಲ್ ಏಕೆ ಬಳಸಬೇಕು? — ಪ್ಲಾನಿಂಗ್, ಸಾಮಾನ್ಯ ಕೋಡಿಂಗ್ ಮತ್ತು ಎಚ್ಚರಿಕೆಯ ಪರಿಶೀಲನೆಗೆ ವಿಭಿನ್ನ ಸಾಮರ್ಥ್ಯಗಳ ಅಗತ್ಯವಿರುತ್ತದೆ, ಮತ್ತು ಪ್ರತಿಯೊಂದಕ್ಕೂ ಸರಿಯಾದ ಮಾಡೆಲ್ ಬಳಸುವುದು ವೆಚ್ಚವನ್ನು ಉಳಿಸುತ್ತದೆ ಮತ್ತು ಗುಣಮಟ್ಟವನ್ನು ಸುಧಾರಿಸುತ್ತದೆ.
• ಪ್ರತಿ ಹಂತಕ್ಕೂ ಹೊಸ ಏಜೆಂಟ್ ಏಕೆ? — ಹೊಸ ಏಜೆಂಟ್ ದೀರ್ಘವಾದ, ಭಾಗಶಃ ಮರೆತುಹೋದ ಸಂಭಾಷಣೆಯ ಬದಲು ಟ್ರ್ಯಾಕರ್‌ನಿಂದ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ, ಇದು ವಿಷಯಾಂತರ ಮತ್ತು ಹಳೆಯ ಊಹೆಗಳನ್ನು ತಪ್ಪಿಸುತ್ತದೆ.
• ರಿವ್ಯೂಯರ್ ಬಿಲ್ಡರ್‌ನಿಂದ ಏಕೆ ಪ್ರತ್ಯೇಕವಾಗಿರಬೇಕು? — ಒಬ್ಬ ಲೇಖಕ ತನ್ನದೇ ಕೆಲಸವನ್ನು ಹೆಚ್ಚು ನಂಬುವ ಪ್ರವೃತ್ತಿ ಹೊಂದಿರುತ್ತಾನೆ, ಆದ್ದರಿಂದ ಕೋಡ್ ಬರೆಯದ ಓದುಗ ಲೇಖಕನು ಗಮನಿಸದ ಸಮಸ್ಯೆಗಳನ್ನು ಕಂಡುಕೊಳ್ಳುತ್ತಾನೆ.
• ಇದು ಸ್ವತಃ ಕೋಡ್ ಅನ್ನು deploy ಅಥವಾ push ಮಾಡುತ್ತದೆಯೇ? — ಇಲ್ಲ. Pushing, releasing ಮತ್ತು deploying ಗೆ ನನ್ನ ಸ್ಪಷ್ಟ ಅನುಮೋದನೆಯ ಅಗತ್ಯವಿದೆ, ಮತ್ತು ಕಮಾಂಡ್ ಅವುಗಳನ್ನು ನಿರ್ಬಂಧಿತ ಹಂತಗಳಾಗಿ (blocked steps) ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ.
• ಯಾವುದನ್ನಾದರೂ ಪೂರ್ಣಗೊಳಿಸಲು ಸಾಧ್ಯವಾಗದಿದ್ದಾಗ ಅದು ಏನು ಮಾಡುತ್ತದೆ? — ಅದು ಆ ಅಂಶವನ್ನು blocked ಎಂದು ಗುರುತಿಸುತ್ತದೆ, ನಿಖರವಾದ ದೋಷ ಮತ್ತು ಅದನ್ನು ಯಾವುದು ಅನ್‌ಬ್ಲಾಕ್ ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ಬರೆಯುತ್ತದೆ, ಮತ್ತು ಸ್ವತಂತ್ರ ಕೆಲಸಕ್ಕೆ ಮುಂದುವರಿಯುತ್ತದೆ.
• ಹೆಚ್ಚುವರಿ ಸಮಯವನ್ನು ವಿನಿಯೋಗಿಸುವುದು ಉಪಯುಕ್ತವೇ? — ದೊಡ್ಡ ಅಥವಾ ಅಪಾಯಕಾರಿ ಬದಲಾವಣೆಗಳಿಗೆ, ಹೌದು, ಏಕೆಂದರೆ ಪರಿಶೀಲನಾ ಸುತ್ತುಗಳು ಬಗ್‌ಗಳನ್ನು ಮೊದಲೇ ಹಿಡಿಯುತ್ತವೆ. ಸಣ್ಣ ಪರಿಹಾರಕ್ಕಾಗಿ, ಸಾಮಾನ್ಯ ಚಾಟ್ ವೇಗವಾಗಿರುತ್ತದೆ.

ಟ್ಯಾಗ್‌ಗಳು

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