ಲೂಪ್ ಎಂಜಿನಿಯರಿಂಗ್ (Loop engineering) ಈಗ ಚರ್ಚೆಯ ಕೇಂದ್ರಬಿಂದುವಾಗಿದೆ. ಯಾವುದೇ ತಾಂತ್ರಿಕ ಫೋರಂ ಅನ್ನು ನೋಡಿದರೂ, ನಾವು AI ಏಜೆಂಟ್ಗಳನ್ನು ಕೇವಲ ಚತುರ ಪ್ರಾಂಪ್ಟ್ಗಳ ಮೂಲಕ ತರಬೇತಿ ನೀಡಬೇಕಾದ ಚಾಟ್ಬಾಟ್ಗಳಂತೆ ಪರಿಗಣಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಬೇಕು ಎಂದು ವಾದಿಸುವ ಧ್ವನಿಗಳು ಕೇಳಿಬರುತ್ತವೆ. ಬದಲಾಗಿ, ನಾವು ಲೂಪ್ಗಳನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸಬೇಕು ಎಂದು ಅವರು ಹೇಳುತ್ತಾರೆ: ಅಂದರೆ ಏಜೆಂಟ್ ಯೋಜಿಸಲು, ಕಾರ್ಯಗತಗೊಳಿಸಲು, ತನ್ನ ಕೆಲಸವನ್ನು ತಾನೇ ಪರಿಶೀಲಿಸಲು ಮತ್ತು ನಾವು ಮಲಗಿರುವಾಗಲೂ ಪುನರಾವರ್ತಿಸಲು (iterate) ಅನುವು ಮಾಡಿಕೊಡುವ ಸ್ವಾಯತ್ತ ಚಕ್ರಗಳು (autonomous cycles). ಈ ಪ್ರಸ್ತಾವನೆಯು ಆಕರ್ಷಕವಾಗಿದೆ. ಲೂಪ್ ಅನ್ನು ಸರಿಯಾಗಿ ನಿರ್ಮಿಸಿದರೆ, ಏಜೆಂಟ್ ನಿರಂತರ ಮಾನವ ಮೇಲ್ವಿಚಾರಣೆಯಿಲ್ಲದೆ ಸರಿಯಾದ ಹಾದಿಯಲ್ಲಿರುತ್ತದೆ ಮತ್ತು ನಮ್ಮ ಉದ್ದೇಶವನ್ನು ರಾತ್ರೋರಾತ್ರಿ ಪೂರ್ಣಗೊಂಡ ಫಲಿತಾಂಶವಾಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ.
ಆ ಭರವಸೆಯು ಸಿದ್ಧಾಂತದಲ್ಲಿ ಅದ್ಭುತವಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಆದರೆ ಪ್ರಾಯೋಗಿಕವಾಗಿ, ಹೆಚ್ಚಿನ ಏಜೆಂಟ್ಗಳು ಈಗಾಗಲೇ ಲೂಪ್ಗಳನ್ನು ಬಳಸುತ್ತಿವೆ. ಅವು ಕೋಡ್ ಅನ್ನು ರಚಿಸುತ್ತವೆ, ಕಾಂಪೈಲರ್ ದೋಷಗಳನ್ನು ಅಥವಾ ಟೆಸ್ಟ್ ವೈಫಲ್ಯಗಳನ್ನು ಪರಿಶೀಲಿಸುತ್ತವೆ, ಕೋಡ್ ಅನ್ನು ಸರಿಪಡಿಸುತ್ತವೆ ಮತ್ತು ಮತ್ತೆ ರನ್ ಮಾಡುತ್ತವೆ. ಈ ಮೂಲಭೂತ ಫೀಡ್ಬ್ಯಾಕ್ ಚಕ್ರವು ಹೊಸತಲ್ಲ. ಈಗ ಬೆಂಬಲಿಗರು ಕೇಳುತ್ತಿರುವುದು ಹೆಚ್ಚು ಮಹತ್ವಾಕಾಂಕ್ಷೆಯ ವಿಷಯ: ಕೇವಲ ಸಿಂಟ್ಯಾಕ್ಸ್ ದೋಷಗಳನ್ನು ಮಾತ್ರವಲ್ಲದೆ, ಇಡೀ ಕಾರ್ಯವನ್ನು ನಿಯಂತ್ರಿಸುವ ಒಂದು 'ಔಟರ್ ಲೂಪ್' (outer loop). ಆ ಔಟರ್ ಲೂಪ್ ಅನ್ನು ನಿರ್ಮಿಸುವುದು ಕಷ್ಟಕರವಾದ ಕೆಲಸ, ಏಕೆಂದರೆ ಸಾಫ್ಟ್ವೇರ್ ಎಂಜಿನಿಯರಿಂಗ್ ಎಂಬುದು ಸ್ಥಿರ ನಿಯಮಗಳನ್ನು ಹೊಂದಿರುವ ಮುಚ್ಚಿದ ವ್ಯವಸ್ಥೆಯಲ್ಲ (closed system).
ಲೂಪ್ ವಿನ್ಯಾಸದ ಸಮಸ್ಯೆ (The Loop Design Problem)
ಉತ್ಪನ್ನದ ಗುರಿಗಳು ಗೊಂದಲಮಯವಾಗಿರುತ್ತವೆ. ನೀವು ಎಂದಿಗೂ ಕೆಲಸದ ಸಂಪೂರ್ಣ ವ್ಯಾಖ್ಯಾನದೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸುವುದಿಲ್ಲ. ಹೆಚ್ಚಾಗಿ, ನೀವು ಕೆಲಸದ ಮಧ್ಯೆ ಇರುವಾಗಲೇ ನಿಜವಾದ ಗುರಿಯನ್ನು ಕಂಡುಕೊಳ್ಳುತ್ತೀರಿ. ವೈಟ್ಬೋರ್ಡ್ ಮೇಲೆ ಸರಳವಾಗಿ ಕಂಡಿದ್ದ ಅವಶ್ಯಕತೆಯು, ಕೆಲಸದ ಹಂತದಲ್ಲಿ ಅನಿರೀಕ್ಷಿತ ಸಂದರ್ಭಗಳನ್ನು (edge cases) ಎದುರಿಸಬಹುದು, ಇದು ಪರಿಹಾರದ ರೂಪವನ್ನೇ ಸಂಪೂರ್ಣವಾಗಿ ಬದಲಾಯಿಸಬಹುದು. ನೀವು ಏಜೆಂಟ್ ಅನ್ನು ಒಂದು ಬಿಗಿಯಾದ (rigid) ಲೂಪ್ ಒಳಗೆ ಇರಿಸಿದಾಗ, ಆ ಬಿಗಿತವು ಒಂದು ಹೊರೆಯಾಗುತ್ತದೆ. ಲೂಪ್ ತಪ್ಪು ಗುರಿಯನ್ನೇ ಪದೇ ಪದೇ ಹಿಂಬಾಲಿಸುತ್ತಿರುತ್ತದೆ. ಅದಕ್ಕಿಂತ ಕೆಟ್ಟದಾಗಿ, ಒಂದು ನಮ್ಯವಾದ (flexible) ಲೂಪ್ ಕೆಲವೊಮ್ಮೆ ತಾನು ನೀಡಿದ ಫಲಿತಾಂಶಕ್ಕೆ ತಕ್ಕಂತೆ ಗುರಿಯನ್ನೇ ಮೌನವಾಗಿ ಬದಲಾಯಿಸುವ ಮೂಲಕ ಸಮಸ್ಯೆಯನ್ನು ಬಗೆಹರಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತದೆ. ಎರಡೂ ಫಲಿತಾಂಶಗಳು ಉಪಯುಕ್ತವಲ್ಲ. ಒಂದು ಕಂಪ್ಯೂಟಿಂಗ್ ಶಕ್ತಿಯನ್ನು ವ್ಯರ್ಥ ಮಾಡುತ್ತದೆ; ಇನ್ನೊಂದು ಆತ್ಮವಿಶ್ವಾಸದಿಂದ ಕಸವನ್ನು (garbage) ಸಾಗಿಸುತ್ತದೆ.
ಆಳವಾದ ಸಮಸ್ಯೆ ಎಂದರೆ ಸ್ಪೆಸಿಫಿಕೇಶನ್ ವೆಚ್ಚ (specification cost). ನೀವು ಲೂಪ್ ಅನ್ನು ಮೇಲ್ವಿಚಾರಣೆಯಿಲ್ಲದೆ ನಡೆಸಲು ಬಯಸಿದರೆ, ನೀವು ಪ್ರತಿಯೊಂದನ್ನೂ ನಿರೀಕ್ಷಿಸುವಂತಹ ಸ್ಪೆಸಿಫಿಕೇಶನ್ ಅನ್ನು ಬರೆಯಲೇಬೇಕು. ಏಜೆಂಟ್ ನಿಖರವಾಗಿ ಏನನ್ನು ಬದಲಾಯಿಸಬೇಕು? ಯಾವ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ನಡವಳಿಕೆಯನ್ನು ಬದಲಾಯಿಸಬಾರದು? ಯಾವ ನಿಖರವಾದ ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ ಏಜೆಂಟ್ ಪುನರಾವರ್ತನೆಯನ್ನು ನಿಲ್ಲಿಸಬೇಕು? ಯಾವ ಅಪಾಯಗಳನ್ನು ಒಪ್ಪಿಕೊಳ್ಳಬಹುದು ಮತ್ತು ಯಾವ ಪರಿಣಾಮಗಳು ತಕ್ಷಣದ ಸ್ಥಗಿತಕ್ಕೆ ಕಾರಣವಾಗಬೇಕು? ಆ ದಾಖಲೆಯನ್ನು ಬರೆಯುವುದು ಏಜೆಂಟ್ ಜೊತೆ ಕುಳಿತು ಕೆಲಸ ಮಾಡುವುದಕ್ಕಿಂತ ಹೆಚ್ಚು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳಬಹುದು. ನೀವು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸುವಿಕೆಗಾಗಿ (automation) ದೊಡ್ಡ ಮೊತ್ತದ ಮುಂಗಡ ತೆರಿಗೆಯನ್ನು ಪಾವತಿಸುತ್ತಿದ್ದೀರಿ, ಇದು ಪರಿಶೀಲನೆ (verification) ಮಾಡುವುದು ಕೆಲಸ ಮಾಡುವುದಕ್ಕಿಂತ ಬಹಳ ಅಗ್ಗವಾಗಿದ್ದಾಗ ಮಾತ್ರ ಲಾಭದಾಯಕವಾಗಿರುತ್ತದೆ.
ಲೂಪ್ಗಳು ನಿಜವಾಗಿಯೂ ಎಲ್ಲಿ ಪ್ರಯೋಜನಕಾರಿಯಾಗುತ್ತವೆ (Where Loops Actually Earn Their Keep)
ಇದರರ್ಥ ಲೂಪ್ ಎಂಜಿನಿಯರಿಂಗ್ ನಿರುಪಯುಕ್ತ ಎಂದಲ್ಲ. ಇದರರ್ಥ ಇದು ಒಂದು ವಿಶೇಷವಾದ ಸಾಧನವೇ ಹೊರತು ಸಾರ್ವತ್ರಿಕ ತಂತ್ರವಲ್ಲ. ಪರಿಶೀಲನಾ ವೆಚ್ಚಗಳು ಹೆಚ್ಚಾಗುವಾಗ ಮತ್ತು ಯಶಸ್ಸಿನ ಮಾನದಂಡಗಳು ಸ್ಪಷ್ಟವಾಗಿದ್ದಾಗ ಲೂಪ್ಗಳು ಅತ್ಯುತ್ತಮವಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತವೆ. ಇದು ಮೂರು ಸಂದರ್ಭಗಳಲ್ಲಿ ನಿಜವಾಗುತ್ತದೆ.
ದಿನನಿತ್ಯದ ಯಾಂತ್ರಿಕ ಕೆಲಸಗಳು (Routine mechanical work). ಹಿರಿಯ ಎಂಜಿನಿಯರ್ಗಳು ನಿವೃತ್ತರಾಗಲು ಬಯಸುವ ಕೆಲಸಗಳನ್ನು ನೆನಪಿಸಿಕೊಳ್ಳಿ: ನಿರ್ದಿಷ್ಟ ಕ್ರಮದಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್ಗಳನ್ನು ಪ್ರಾರಂಭಿಸುವುದು, ಪ್ರತಿ ಹಂತವನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಡಿಪ್ಲಾಯ್ಮೆಂಟ್ UI ಮೂಲಕ ಕ್ಲಿಕ್ ಮಾಡುವುದು, ರಿಲೀಸ್ ನಂತರ ಲಾಗ್ಗಳನ್ನು ಪರಿಶೀಲಿಸುವುದು ಅಥವಾ ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್ ಸರಿಯಾದ ಎಲ್ಲಾ ನೋಡ್ಗಳಿಗೆ ಬರೆಯಲಾಗಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸುವುದು. ಈ ಹಂತಗಳು ಮನುಷ್ಯರಿಗೆ ಬೇಸರ ತರಿಸಬಹುದು ಆದರೆ ಪರಿಶೀಲಿಸಲು ಸುಲಭವಾಗಿವೆ. ಒಂದು ಲೂಪ್ ಈ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಬಹುದು, ಪ್ರತಿ ರೀಸ್ಟಾರ್ಟ್ ನಂತರ ಹೆಲ್ತ್ ಎಂಡ್ಪಾಯಿಂಟ್ಗಳನ್ನು ಪರಿಶೀಲಿಸಬಹುದು ಮತ್ತು ಮೊದಲ ಸೂಚನೆಯಲ್ಲೇ ಹಿಂದಕ್ಕೆ ಪಡೆಯಬಹುದು (roll back). ಮನುಷ್ಯನು ಇನ್ನೂ ರೋಲ್ಔಟ್ ಯೋಜನೆಯನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತಾನೆ. ಲೂಪ್ ಕೇವಲ ಅದನ್ನು ಯಂತ್ರದ ತಾಳ್ಮೆಯಿಂದ ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತದೆ.
ಅಳೆಯಬಹುದಾದ ಆಪ್ಟಿಮೈಸೇಶನ್ ಗುರಿಗಳು (Measurable optimization goals). ಯಶಸ್ಸು ಒಂದು ಸಂಖ್ಯೆಯಾದಾಗ, ಲೂಪ್ಗಳು ಅತ್ಯಂತ ಪರಿಣಾಮಕಾರಿಯಾಗಿರುತ್ತವೆ. p99 લેಟೆನ್ಸಿಯನ್ನು 150 ಮಿಲಿಸೆಕೆಂಡ್ಗಿಂತ ಕಡಿಮೆ ಮಾಡುವುದು. ಮೆಮೊರಿ ಬಳಕೆಯನ್ನು ಇಪ್ಪತ್ತು ಪ್ರತಿಶತ ಕಡಿಮೆ ಮಾಡುವುದು. ಪೈಥಾನ್ನಿಂದ ರಸ್ಟ್ (Rust) ಗೆ ಹೈಟ್ ಪಾತ್ ಅನ್ನು ವರ್ಗಾಯಿಸುವುದು ಮತ್ತು ಎಲ್ಲಾ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಯೂನಿಟ್ ಟೆಸ್ಟ್ಗಳು ಪಾಸಾಗುವಂತೆ ಮಾಡುವುದು. ಲೂಪ್ ಒಂದು ಬದಲಾವಣೆಯನ್ನು ಮಾಡಬಹುದು, ಅದನ್ನು ಬೆಂಚ್ಮಾರ್ಕ್ ಮಾಡಬಹುದು, ಉತ್ತಮ ಫಲಿತಾಂಶ ನೀಡಿದ ಬದಲಾವಣೆಯನ್ನು ಉಳಿಸಿಕೊಳ್ಳಬಹುದು ಮತ್ತು ಉಳಿದದ್ದನ್ನು ಕೈಬಿಡಬಹುದು. ಪರಿಶೀಲನೆಯು ಸ್ವಯಂಚಾಲಿತವಾಗಿರುವುದರಿಂದ ಮತ್ತು ಹುಡುಕಾಟದ ವ್ಯಾಪ್ತಿ ದೊಡ್ಡದಾಗಿರುವುದರಿಂದ, ಮ್ಯಾನುಯಲ್ ರಿವ್ಯೂ ಮಾಡುವುದು ಅಸಾಧ್ಯವಾಗುತ್ತದೆ. ಗುರಿ ಸ್ಥಿರವಾಗಿದೆ. ಹಾದಿ ತಿಳಿದಿಲ್ಲ. ಇದು ಲೂಪ್ಗಳಿಗೆ ಅತ್ಯುತ್ತಮ ಅವಕಾಶ.
ಕಾರ್ಯಾಚರಣೆಯ ಪ್ಲೇಬುಕ್ಗಳು (Operational playbooks). ಇನ್ಸಿಡೆಂಟ್ ರೆಸ್ಪಾನ್ಸ್ ಮತ್ತು ಸಪೋರ್ಟ್ ಟಿಕೆಟ್ಗಳು ಮನುಷ್ಯರು ಈಗಾಗಲೇ ಕಂಡುಕೊಂಡಿರುವ ಮಾದರಿಗಳನ್ನು ಅನುಸರಿಸುತ್ತವೆ. ನಿರ್ದಿಷ್ಟ ರೀತಿಯ ಪ್ರೊಡಕ್ಷನ್ ದೋಷವು ಯಾವಾಗಲೂ ಕ್ರೆಡೆನ್ಶಿಯಲ್ ಅನ್ನು ಬದಲಾಯಿಸುವುದು ಮತ್ತು ಕ್ಯಾಶ್ ಅನ್ನು ಕ್ಲಿಯರ್ ಮಾಡುವುದನ್ನು ಬಯಸುತ್ತದೆ. ಮೂರು ನಿರ್ದಿಷ್ಟ ಪರಿಸ್ಥಿತಿಗಳು ಪೂರೈಕೆಯಾದಾಗ ಸಪೋರ್ಟ್ ವಿನಂತಿಯನ್ನು ರಿಫಂಡ್ ಮೂಲಕ ಪರಿಹರಿಸಬಹುದು. ಒಂದು ಲೂಪ್ ಆ ಟ್ರಿಗ್ಗರ್ಗಳಿಗಾಗಿ ಕಾಯಬಹುದು ಮತ್ತು ಪ್ಲೇಬುಕ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದು, ಮಾದರಿಯು ಬದಲಾದಾಗ ಮಾತ್ರ ಎಸ್ಕಲೇಟ್ ಮಾಡಬಹುದು. ಇದು ಪ್ಲೇಬುಕ್ ಸರಿಯಾಗಿದೆ ಎಂದು ನಿರ್ಧರಿಸುವುದಿಲ್ಲ; ಇದು ಕೇವಲ ಎಂಜಿನಿಯರ್ಗಳು ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲದ ವೇಗ ಮತ್ತು ಪ್ರಮಾಣದಲ್ಲಿ ಸ್ಥಿರತೆಯನ್ನು ಕಾಪಾಡುತ್ತದೆ.
ನಿಯಂತ್ರಕರು, ರೆಫರೆನ್ಸ್-ಸೆಟ್ಟರ್ಗಳಲ್ಲ (Regulators, Not Reference-Setters)
ಪ್ರಸ್ತುತ ನಡೆಯುತ್ತಿರುವ ಹೆಚ್ಚಿನ ಚರ್ಚೆಗಳಲ್ಲಿ ಒಂದು ಪ್ರಮುಖ ವ್ಯತ್ಯಾಸವು ಕಾಣದಂತಿದೆ. Loops ನಿಯಂತ್ರಕಗಳಾಗಿವೆ. ಥರ್ಮೋಸ್ಟಾಟ್ ಒಂದು ಕೋಣೆಯನ್ನು ಎಪ್ಪತ್ತೆರಡು ಡಿಗ್ರಿ ತಾಪಮಾನದಲ್ಲಿ ಹೇಗೆ ಇಡುತ್ತದೆಯೋ, ಹಾಗೆಯೇ ಅವು ಒಂದು ವ್ಯವಸ್ಥೆಯನ್ನು ಮೊದಲೇ ನಿರ್ಧರಿಸಿದ ಗುರಿಯೊಂದಿಗೆ ಹೊಂದಿಕೆಯಾಗುವಂತೆ ಮಾಡುತ್ತವೆ. ಆದರೆ ಥರ್ಮೋಸ್ಟಾಟ್ ತಾನಾಗಿಯೇ ಎಪ್ಪತ್ತೆರಡು ಡಿಗ್ರಿ ಎಂದು ನಿರ್ಧರಿಸುವುದಿಲ್ಲ. ಮೊದಲು ಯಾರೋ ಒಬ್ಬರು ಅದು ಸರಿಯಾದ ತಾಪಮಾನ ಎಂದು ನಿರ್ಧರಿಸಿರಬೇಕು.
ಸಾಫ್ಟ್ವೇರ್ಗೆ ಅನ್ವಯಿಸಿದರೆ, ಇದರರ್ಥ ಒಂದು loop ಒಳಗಿರುವ agent ದಿನವಿಡೀ bugs ಸರಿಪಡಿಸಬಹುದು, functions ಅನ್ನು refactor ಮಾಡಬಹುದು ಅಥವಾ parameters ಅನ್ನು tune ಮಾಡಬಹುದು. ಆದರೆ, ಯಾವ feature ಗ್ರಾಹಕರಿಗೆ ನಿಜವಾಗಿಯೂ ಸಹಾಯ ಮಾಡುತ್ತದೆ ಅಥವಾ ಮುಂದಿನ release ಮೊದಲು ಒಂದು bug ಅನ್ನು ಸರಿಪಡಿಸುವುದು ಅಗತ್ಯವೇ ಎಂಬುದನ್ನು ಅದು ನಿರ್ಧರಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಅಂತಹ ಆಯ್ಕೆಗಳಿಗೆ business context, ಬಳಕೆದಾರರ ತೊಂದರೆ ಮತ್ತು ಕಾರ್ಯತಂತ್ರದ ಆದ್ಯತೆಯ ಬಗ್ಗೆ ನಿರ್ಧಾರ ತೆಗೆದುಕೊಳ್ಳುವ ಸಾಮರ್ಥ್ಯ ಬೇಕಾಗುತ್ತದೆ. Agents ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತವೆ. Humans ನಿರ್ಧರಿಸುತ್ತಾರೆ. ಈ ಎರಡರ ನಡುವಿನ ವ್ಯತ್ಯಾಸವನ್ನು ಗೊಂದಲ ಮಾಡಿಕೊಳ್ಳುವುದರಿಂದ, ತಂಡಗಳು ತಪ್ಪು ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುವ ಸುಂದರವಾಗಿ optimized ಮಾಡಲಾದ ವ್ಯವಸ್ಥೆಗಳನ್ನು ನಿರ್ಮಿಸುವಂತಾಗುತ್ತದೆ.
Loop engineering ಉಪಯುಕ್ತವಾಗಿದೆ, ಆದರೆ ಅದು ಸೀಮಿತವಾಗಿದೆ. ಇದು ಯಂತ್ರವನ್ನು ಶಿಸ್ತು ಮತ್ತು ವೇಗದಿಂದ ನಡೆಸಲು ನಿಮಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಯಾವ ಯಂತ್ರವನ್ನು ನಿರ್ಮಿಸಬೇಕು, ಅದು ಯಾರಿಗಾಗಿ ಮತ್ತು ಮಾನವೀಯ ದೃಷ್ಟಿಕೋನದಲ್ಲಿ ಯಶಸ್ಸು ಎಂದರೆ ಏನು ಎಂಬುದನ್ನು ಇದು ನಿರ್ಧರಿಸುವುದಿಲ್ಲ. ಯಾವ feature ಮುಖ್ಯವಾಗುತ್ತದೆ, ಯಾವ ಅಪಾಯವನ್ನು ಸ್ವೀಕರಿಸಬಹುದು ಮತ್ತು ಯಾವಾಗ ಗುರಿಯನ್ನೇ ಬದಲಾಯಿಸಬೇಕು ಎಂಬ ನಿರ್ಧಾರಗಳು ನಿಮ್ಮ ಮೇಲಿರುತ್ತವೆ. ನೀವು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಪರಿಶೀಲಿಸಲು ಸಾಧ್ಯವಿರುವಷ್ಟು ಚೆನ್ನಾಗಿ ತಿಳಿದಿರುವ ಕೆಲಸಗಳಿಗಾಗಿ loops ನಿರ್ಮಿಸಿ. ಉಳಿದ ಎಲ್ಲವನ್ನೂ ನಿಮ್ಮ ನಿಯಂತ್ರಣದಲ್ಲಿ ಇಟ್ಟುಕೊಳ್ಳಿ.
ಈ ಲೇಖನವು ಮೂಲತಃ Isaac Hagoel ಅವರು “Loop Engineering Minus The Hype.” ನಲ್ಲಿ ಚರ್ಚಿಸಿದ ವಿಚಾರಗಳನ್ನು ಆಧರಿಸಿದೆ. ಹೆಚ್ಚಿನ ಇಂಜಿನಿಯರಿಂಗ್ ಚರ್ಚೆಗಳಿಗಾಗಿ, Telegram ನಲ್ಲಿ ನಮ್ಮ ಕಲಿಕಾ ಸಮುದಾಯವನ್ನು ಸೇರಿ.