ಸೋಮವಾರ ಬೆಳಿಗ್ಗೆ ನೀವು ಎದ್ದಾಗ ಐದು ಗಂಭೀರವಾದ ಬಗ್ ವರದಿಗಳು (bug reports) ನಿಮ್ಮ ಮುಂದೆ ಇರುತ್ತವೆ. ನಿಮ್ಮ ರಿವ್ಯೂ ಮಾನಿಟರಿಂಗ್ ಟೂಲ್ ತನ್ನ ಕೆಲಸವನ್ನು ಸರಿಯಾಗಿ ಮಾಡಿದೆ. ಅದು ಪ್ರತಿಯೊಂದು ಕ್ರ್ಯಾಶ್ ವರದಿ, ಪ್ರತಿಯೊಂದು ಕೋಪಗೊಂಡ ಒಂದು-ಸ್ಟಾರ್ ರಿವ್ಯೂ ಮತ್ತು "ಸೇವ್ ಮಾಡುವಾಗ ಆಪ್ ಫ್ರೀಜ್ ಆಗುತ್ತಿದೆ" ಎಂಬ ಪ್ರತಿಯೊಂದು ದೂಹೆಯನ್ನು ಪತ್ತೆಹಚ್ಚಿದೆ. ಏನನ್ನು ಸರಿಪಡಿಸಬೇಕೆಂದು ನಿಮಗೆ ನಿಖರವಾಗಿ ತಿಳಿದಿದೆ. ಆದರೆ ಎಲ್ಲಿ ಹುಡುಕಬೇಕೆಂದು ನಿಮಗೆ ತಿಳಿದಿಲ್ಲ.
ನನ್ನ ಮೊದಲ ಪೈಪ್ಲೈನ್ (pipeline) ನಿರ್ಮಿಸಿದ ನಂತರ ನಾನು ಎದುರಿಸಿದ ಅಡೆತಡೆ ಇದಾಗಿತ್ತು. ಅದು ಆಪ್ ರಿವ್ಯೂಗಳು ಮತ್ತು ಬರುವ ಕ್ರ್ಯಾಶ್ ಲಾಗ್ಗಳನ್ನು ಯಾವುದೇ ತೊಂದರೆಯಿಲ್ಲದೆ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುತ್ತಿತ್ತು ಮತ್ತು ಪ್ರತಿ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಬಗ್ಗಳು, ಕ್ರ್ಯಾಶ್ಗಳು ಅಥವಾ ಫೀಚರ್ ರಿಕ್ವೆಸ್ಟ್ಗಳಂತಹ ವ್ಯವಸ್ಥಿತ ವರ್ಗಗಳಿಗೆ ವಿಂಗಡಿಸುತ್ತಿತ್ತು. ಡ್ಯಾಶ್ಬೋರ್ಡ್ ಆರೋಗ್ಯಕರವಾಗಿ ಕಾಣುತ್ತಿತ್ತು. ಆದರೆ ನಿಜವಾದ ಡಿಬಗ್ಗಿಂಗ್ (debugging) ಪ್ರಕ್ರಿಯೆ ಅಷ್ಟೊಂದು ಸುಲಭವಾಗಿರಲಿಲ್ಲ.
ಬಗ್ ಇದೆ ಎಂದು ತಿಳಿಯುವುದು ಒಂದು ಮೈಲಿ ಉದ್ದದ ಪ್ರಯಾಣದ ಮೊದಲ ಇಂಚು ಮಾತ್ರ. ನಾನು ಇನ್ನು ಕೂಡ IDE ತೆರೆಯಬೇಕಿತ್ತು, ಮಾಡ್ಯೂಲ್ಗಳಲ್ಲಿ grep ಮಾಡಬೇಕಿತ್ತು, ಸ್ಟ್ಯಾಕ್ ಟ್ರೇಸ್ಗಳನ್ನು (stack traces) ಪ್ರಸ್ತುತ ಕೋಡ್ಬೇಸ್ನೊಂದಿಗೆ ಹೋಲಿಕೆ ಮಾಡಬೇಕಿತ್ತು ಮತ್ತು ವಿಫಲತೆಯ ಹಾದಿಯನ್ನು (failure path) ನನ್ನ ಮನಸ್ಸಿನಲ್ಲಿ ಮರುನಿರ್ಮಿಸಬೇಕಿತ್ತು. ಟಿಕೆಟ್ಗಳು ರಾಶಿಬಿದ್ದಾಗ ಮತ್ತು ಕಾಫಿ ಇನ್ನೂ ಬಿಸಿಯಾಗಿರುವಾಗ, ಈ ಮ್ಯಾನುಯಲ್ ಆರ್ಕಿಯಾಲಜಿ (manual archaeology) ನಿಮ್ಮ ಬಳಿ ಇಲ್ಲದ ಸಮಯವನ್ನು ವ್ಯರ್ಥ ಮಾಡುತ್ತದೆ. ನನಗೆ ಪೈಪ್ಲೈನ್ ಕೇವಲ ಸಮಸ್ಯೆಗಳನ್ನು ಗುರುತಿಸುವುದಕ್ಕಿಂತ ಹೆಚ್ಚಿನದನ್ನು ಮಾಡಬೇಕಿತ್ತು. ಅದು ಸಮಸ್ಯೆಗಳನ್ನು ತನಿಖೆ ಮಾಡಬೇಕಿತ್ತು.
ಆದ್ದರಿಂದ ನಾನು ಒಂದು ಗುರಿಯೊಂದಿಗೆ ವ್ಯವಸ್ಥೆಯನ್ನು ಮರುನಿರ್ಮಿಸಿದೆ: ಒಂದು ಕಚ್ಚಾ ಬಗ್ ವರದಿಯನ್ನು ಪಡೆದು, ದೃಢೀಕರಿಸಿದ ರೋಗನಿರ್ಣಯವನ್ನು (validated diagnosis) ಹಿಂತಿರುಗಿಸುವುದು. ಇದು LLM ನ ಸುದೀರ್ಘ ವಿವರಿಸುವಿಕೆಯಲ್ಲ. ಬದಲಾಗಿ ಫೈಲ್ ಹೆಸರನ್ನು ತಿಳಿಸುವ, ಲೈನ್ ಅನ್ನು ತೋರಿಸುವ, ಅಪಾಯವನ್ನು ಅಂದಾಜಿಸುವ ಮತ್ತು ಪರಿಹಾರವನ್ನು ಸೂಚಿಸುವ ಒಂದು ರಚನಾತ್ಮಕ ಸಂಶೋಧನೆಯಾಗಿರಬೇಕು. ಅದು ಹೇಗೆ ಕಾರ್ಯಗತವಾಯಿತು ಎಂಬುದು ಇಲ್ಲಿದೆ.
ಚಾಟ್ ಲಾಗ್ ಗಿಂತ ರಚನೆ ಏಕೆ ಉತ್ತಮ?
ನಾನು ತನಿಖಾ ಏಜೆಂಟ್ ಅನ್ನು PydanticAI ಬಳಸಿ ನಿರ್ಮಿಸಿದೆ. ಕಾರಣ ಸರಳವಾಗಿತ್ತು. ನೀವು ಕೋಡ್ ಬಗ್ಗೆ ಯೋಚಿಸಲು ಒಂದು ಲ್ಯಾಂಗ್ವೇಜ್ ಮಾಡೆಲ್ ಅನ್ನು ಕೇಳಿದಾಗ, ಅದರ ಡಿಫಾಲ್ಟ್ ಔಟ್ಪುಟ್ ಪಠ್ಯದ ಒಂದು ಸುಲಲಿತ ಹರಿವುವಾಗಿರುತ್ತದೆ. ಅದು ಮಾನವ ಓದುಗರಿಗೆ ಸಹಾಯ ಮಾಡಬಹುದು, ಆದರೆ ಡೌನ್ಸ್ಟ್ರೀಮ್ ಸ್ಕ್ರಿಪ್ಟ್ಗೆ ಅದು ವ್ಯರ್ಥ. ನನಗೆ ಮಷಿನ್-ರೀಡಬಲ್ ಕಾಂಟ್ರಾಕ್ಟ್ (machine-readable contract) ಬೇಕಿತ್ತು.
ಏಜೆಂಟ್ ನಾಲ್ಕು ನಿರ್ದಿಷ್ಟ ಫೀಲ್ಡ್ಗಳೊಂದಿಗೆ ದೃಢೀಕರಿಸಿದ ಡೇಟಾ ಮಾಡೆಲ್ ಅನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ: ಮೂಲ ಕಾರಣ (root cause), ಬಾಧಿತ ಫೈಲ್ಗಳು, ಪ್ರಸ್ತಾವಿತ ಬದಲಾವಣೆಗಳು ಮತ್ತು ಸಂಕೀರ್ಣತೆ ಹಾಗೂ ಅಪಾಯದ ಮೌಲ್ಯಮಾಪನ. ಮಾಡೆಲ್ನಲ್ಲಿ ಯಾವುದಾದರೂ ಫೀಲ್ಡ್ ತಪ್ಪಾಗಿದ್ದರೆ ಅಥವಾ ಫೈಲ್ಪಾತ್ ಅನ್ನು ತಪ್ಪಾಗಿ ನೀಡಿದರೆ (hallucinates), ವ್ಯಾಲಿಡೇಶನ್ ವಿಫಲವಾಗುತ್ತದೆ ಮತ್ತು ನಾನು ಅದನ್ನು ತಕ್ಷಣವೇ ಪತ್ತೆಹಚ್ಚಬಲ್ಲೆ. ಆ ಕಟ್ಟುನಿಟ್ಟಿನ ಕ್ರಮವು ಪೈಪ್ಲೈನ್ ಅನ್ನು ನಿಖರವಾಗಿರಿಸುತ್ತದೆ.
ನಿಜವಾದ ತನಿಖಾ ಕೆಲಸ ಮಾಡಲು, ಏಜೆಂಟ್ಗೆ ಕೇವಲ ನಾಲ್ಕು ರೀಡ್-ಓನ್ಲಿ (read-only) ಟೂಲ್ಗಳು ಮಾತ್ರ ಸಿಗುತ್ತವೆ. ಅದು grep ಮೂಲಕ ಕೋಡ್ ಅನ್ನು ಹುಡುಕಬಹುದು, ಫೈಲ್ನಿಂದ ನಿರ್ದಿಷ್ಟ ಲೈನ್ ವ್ಯಾಪ್ತಿಯನ್ನು ಓದಬಹುದು, ಡೈರೆಕ್ಟರಿ ವಿಷಯಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡಬಹುದು ಮತ್ತು ಕ್ಲಾಸ್ಗಳು ಅಥವಾ ಫಂಕ್ಷನ್ಗಳಂತಹ ಸಿಂಬಲ್ಗಳನ್ನು ಪತ್ತೆಹಚ್ಚಬಹುದು. ರೀಡ್-ಓನ್ಲಿ ಎಂಬುದು ಇಲ್ಲಿ ಮುಖ್ಯವಾದ ಭಾಗ. ರಾತ್ರಿ 2 ಗಂಟೆಗೆ ನನ್ನ ರೆಪೊಸಿಟರಿಯಲ್ಲಿ (repository) ಬರೆಯುವ ಅಧಿಕಾರವಿರುವ ಏಜೆಂಟ್ ಅಲೆದಾಡಬೇಕೆಂದು ನಾನು ಬಯಸಲಿಲ್ಲ. ಮೊದಲು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಿ, ನಂತರ ಎಡಿಟ್ ಮಾಡಿ.
ರೆಪೊ ಮ್ಯಾಪ್: ಟೂಲ್ಗಳಿಗಿಂತ ಮೊದಲು ಸಂದರ್ಭ (Context)
ಏಜೆಂಟ್ನ ಮೊದಲ ಆವೃತ್ತಿಯು ನಿಖರವಾಗಿತ್ತು ಆದರೆ ತುಂಬಾ ದುಬದಿಯಾಗಿತ್ತು. ಅದು ಟೋಕನ್ಗಳನ್ನು (tokens) ಅತಿಯಾಗಿ ವ್ಯರ್ಥ ಮಾಡುತ್ತಿತ್ತು. ಮಾಡೆಲ್ list-dir ಅನ್ನು ಕರೆಯುತ್ತದೆ, ನಂತರ grep, ನಂತರ ಒಂದು ಫೈಲ್ ಅನ್ನು ಓದುತ್ತದೆ, ನಂತರ ಮತ್ತೆ list-dir ಅನ್ನು ಕರೆಯುತ್ತದೆ, ಹೀಗೆ ಪ್ರಾಜೆಕ್ಟ್ ರಚನೆಯ ಮಾನಸಿಕ ಮಾದರಿಯನ್ನು ಒಂದೊಂದೇ ದುಬಾರಿ ಟೋಕನ್ ಮೂಲಕ ನಿಧಾನವಾಗಿ ನಿರ್ಮಿಸುತ್ತಾ ಹೋಗುತ್ತಿತ್ತು.
ಪರಿಹಾರವೆಂದರೆ ಏಜೆಂಟ್ ಪ್ರಾರಂಭಿಸುವ ಮೊದಲೇ ಒಂದು ಸಂಕ್ಷಿಪ್ತ ರೆಪೊ ಮ್ಯಾಪ್ ಅನ್ನು (repo map) ಸಿದ್ಧಪಡಿಸುವುದು. ಈ ಮ್ಯಾಪ್ ರೆಪೊಸಿಟರಿಯ ಸಾರಾಂಶವಾಗಿದೆ: ಪ್ರಮುಖ ಫೈಲ್ಗಳು, ಅವುಗಳ ಪ್ರಾಥಮಿಕ ಫಂಕ್ಷನ್ಗಳು ಅಥವಾ ಕ್ಲಾಸ್ಗಳು ಮತ್ತು ಪ್ರಮುಖ ಮಾಡ್ಯೂಲ್ಗಳು ಹೇಗೆ ಪರಸ್ಪರ ಸಂಬಂಧ ಹೊಂದಿವೆ ಎಂಬ ಮಾಹಿತಿ. ಏಜೆಂಟ್ಗೆ ರಸ್ತೆಗಳನ್ನು ಪ್ರಯತ್ನ ಮತ್ತು ತಪ್ಪುಗಳ ಮೂಲಕ ಹುಡುಕಲು ಹೇಳುವ ಬದಲು, ಒಂದು GPS ಅನ್ನು ನೀಡುವುದಕ್ಕೆ ಇದು ಸಮಾನ.
ಆ ಮ್ಯಾಪ್ ಅದರ ಕಾಂಟೆಕ್ಸ್ಟ್ ವಿಂಡೋದಲ್ಲಿ (context window) ಇದ್ದಾಗ, src/utils/parser.ts ಅಸ್ತಿತ್ವದಲ್ಲಿದೆ ಎಂದು ತಿಳಿಯಲು ಏಜೆಂಟ್ ಅನಗತ್ಯ ಕರೆಗಳನ್ನು ಮಾಡುವುದಿಲ್ಲ. ಅದಕ್ಕೆ ಈಗಾಗಲೇ ಭೂಪ್ರದೇಶದ ಅರಿವಿದೆ. ಅದು ಹೊಗೆ ಏರುತ್ತಿರುವ ಜಾಗಕ್ಕೆ ನೇರವಾಗಿ ತೆರಳುತ್ತದೆ. ಆ ಒಂದು ಬದಲಾವಣೆಯು ಅಲೆದಾಡುವ ಹಂತವನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ತಪ್ಪಿಸಿತು.
ಟೂಲ್ ಫನಲ್: ಒಂದು ತೀರ್ಮಾನಕ್ಕೆ ಬಲವಂತ ಮಾಡುವುದು
ಮ್ಯಾಪ್ ಇದ್ದರೂ ಸಹ, ಏಜೆಂಟ್ ಗೊಂದಲಕ್ಕೀಡಾಗಬಹುದು. ಅದು ಒಂದು ಸಂಶಯಾಸ್ಪದ ಫೈಲ್ ಅನ್ನು ಕಂಡುಕೊಳ್ಳಬಹುದು, ನಂತರ ತನ್ನ ಬಗ್ಗೆ ತಾನೇ ಅನುಮಾನ ಪಡಬಹುದು, ಮತ್ತೆ ಹುಡುಕಬಹುದು, ನಂತರ ಇನ್ನೊಂದು ಫೈಲ್ ಅನ್ನು ಓದಬಹುದು, ಹೀಗೆ "ಇನ್ನೊಂದು ಬಾರಿ ಚೆಕ್ ಮಾಡೋಣ" ಎಂಬ ಅಂತ್ಯವಿಲ್ಲದ ಲೂಪ್ನಲ್ಲಿ ಸಿಲುಕಿಕೊಳ್ಳಬಹುದು. ನಾನು ವೇಗವನ್ನು ಹೆಚ್ಚಿಸಲು ಒಂದು ಮಾರ್ಗವನ್ನು ಕಂಡುಕೊಳ್ಳಬೇಕಿತ್ತು.
ನಾನು ಮೂರು ಹಂತಗಳ ಟೂಲ್ ಫನಲ್ ಅನ್ನು ಜಾರಿಗೆ ತಂದೆ, ಇದು ಏಜೆಂಟ್ ಪ್ರಗತಿ ಹೊಂದುತ್ತಿದ್ದಂತೆ ಅದು ಏನು ಮಾಡಬಹುದು ಎಂಬುದನ್ನು ನಿರ್ಬಂಧಿಸುತ್ತದೆ.
ಮೊದಲ ಹಂತವು ಅನ್ವೇಷಣೆ (exploration). ಏಜೆಂಟ್ಗೆ ನಾಲ್ಕೂ ಟೂಲ್ಗಳ ಸಂಪೂರ್ಣ ಪ್ರವೇಶವಿರುತ್ತದೆ. ತನ್ನ ತರ್ಕದಲ್ಲಿ ಬಗ್ ಅನ್ನು ಪುನರಾವರ್ತಿಸಲು ಬೇಕಾದ ಯಾವುದೇ ವಿಷಯವನ್ನು ಅದು ಹುಡುಕಬಹುದು, ನೋಡಬಹುದು ಮತ್ತು ಓದಬಹುದು.
ಎರಡನೇ ಹಂತವು ಡೀಪ್-ಡೈವ್ (deep-dive). ಏಜೆಂಟ್ ಸಂಭವನೀಯ ದೋಷಗಳನ್ನು ಗುರುತಿಸಿದ ನಂತರ, ಅದು ಅನ್ವೇಷಣಾ ಟೂಲ್ಗಳನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತದೆ. ಅದು ಕೇವಲ ಫೈಲ್ಗಳನ್ನು ಓದಬಹುದು. ಇನ್ನು ಮುಂದೆ grep ಅಥವಾ ಡೈರೆಕ್ಟರಿ ಪಟ್ಟಿ ಮಾಡುವಂತಿಲ್ಲ. ಈ ಹಂತದಲ್ಲಿ ಅದು ಈಗಾಗಲೇ ಕಂಡುಕೊಂಡ ಕೋಡ್ ಅನ್ನು ಅಧ್ಯಯನ ಮಾಡಬೇಕು ಮತ್ತು ತನ್ನ ಸಾಕ್ಷ್ಯಗಳನ್ನು ನಿರ್ಮಿಸಬೇಕು.
ಮೂರನೇ ಹಂತವು ಔಟ್ಪುಟ್ (output). ಎಲ್ಲಾ ಟೂಲ್ಗಳನ್ನು ಲಾಕ್ ಮಾಡಲಾಗುತ್ತದೆ. ಏಜೆಂಟ್ ಇನ್ನು ಮುಂದೆ ಕೋಡ್ಬೇಸ್ ಅನ್ನು ಪ್ರಶ್ನಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಅದು ಕುಳಿತು ವರದಿಯನ್ನು ಬರೆಯಲೇಬೇಕು. ಇದು "ಇನ್ನೊಂದು ವಿಷಯವನ್ನು ಚೆಕ್ ಮಾಡೋಣ" ಎಂಬ ಅಂತ್ಯವಿಲ್ಲದ ಸುಳಿಯನ್ನು ತಡೆಯುತ್ತದೆ.
ಆ ಫನಲ್ನಿಂದಾಗಿ ಸರಾಸರಿ ಟೂಲ್ ಕರೆಗಳ ಸಂಖ್ಯೆಯು ವಿಶ್ಲೇಷಣೆಗೆ ಪ್ರತಿ ಬಾರಿಯೂ ನಲವರಿಂದ ಸುಮಾರು ಹತ್ತಕ್ಕೆ ಇಳಿಯಿತು. ಏಜೆಂಟ್ ವೇಗವಾಗಿ, ಅಗ್ಗವಾಗಿ ಮತ್ತು ವಿಪರ್ಯಾಸವೆಂದರೆ ಹೆಚ್ಚು ಆತ್ಮವಿಶ್ವಾಸದಿಂದ ಕೆಲಸ ಮಾಡತೊಡಗಿತು, ಏಕೆಂದರೆ ಅದು ಒಂದು ತೀರ್ಮಾನಕ್ಕೆ ಬದ್ಧವಾಗಿರಬೇಕಾಯಿತು.
ಬ್ಯಾಕೆಂಡ್ ಅನ್ನು ಬದಲಾಯಿಸಬಹುದಾದಂತೆ ಇರಿಸಿಕೊಳ್ಳುವುದು
ನಾನು ವ್ಯವಸ್ಥೆಯನ್ನು ಕೇವಲ ಒಂದು ಮಾದರಿ ಪೂರೈಕೆದಾರರಿಗೆ (model provider) ಸೀಮಿತಗೊಳಿಸಲು (hardcode) ಇಷ್ಟಪಡಲಿಲ್ಲ. ನಾನು ಕೆಲಸದ ಸ್ವರೂಪಕ್ಕೆ ಅನುಗುಣವಾಗಿ ವಿವಿಧ ಎಂಜಿನ್ಗಳನ್ನು ಬಳಸುತ್ತೇನೆ. ಕೆಲವೊಮ್ಮೆ Claude Code, ಕೆಲವೊಮ್ಮೆ Grok Build, ಅಥವಾ ಆ ಸಮಯದಲ್ಲಿ ಯಾವುದು ಅಗ್ಗವೋ ಅದನ್ನು ಬಳಸುತ್ತೇನೆ. ಮೂಲ ತರ್ಕವನ್ನು (core logic) ಪೂರೈಕೆದಾರರ ಮೇಲೆ ಅವಲಂಬಿತವಾಗದಂತೆ ಇರಿಸಲು, ನಾನು ಕೆಲಸವನ್ನು ಎರಡು ಹಂತಗಳಾಗಿ ವಿಂಗಡಿಸಿದ್ದೇನೆ.
ಮೊದಲ ಹಂತವು ಅನ್ವೇಷಣೆ (exploration). ಯಾವುದೇ ಸಾಮರ್ಥ್ಯವಿರುವ ಮಾದರಿಯನ್ನು ಕೋಡಿಂಗ್ ಏಜೆಂಟ್ ಆಗಿ ಬಳಸಬಹುದು; ಇದು ರೆಪೋ ಮ್ಯಾಪ್ ಅನ್ನು ಓದುತ್ತದೆ, ಪರಿಕರಗಳನ್ನು ಬಳಸುತ್ತದೆ ಮತ್ತು ಒಂದು ಕಚ್ಚಾ ಮಾರ್ಕ್ಡೌನ್ ವರದಿಯನ್ನು ಸಿದ್ಧಪಡಿಸುತ್ತದೆ. ಇದು ಹೆಚ್ಚಿನ ವೆಚ್ಚದ ಆಲೋಚನಾ ಭಾಗವಾಗಿದೆ.
ಎರಡನೇ ಹಂತವು ರಚನೆಗೊಳಿಸುವುದು (structuring). ಒಂದು ಅಗ್ಗದ ಮತ್ತು ವೇಗದ LLM ಆ ಮಾರ್ಕ್ಡೌನ್ ಅನ್ನು ಪಡೆದು, ಅದನ್ನು ಕಟ್ಟುನಿಟ್ಟಾದ Pydantic ಮಾಡೆಲ್ಗೆ ಮರುರೂಪಿಸುತ್ತದೆ. ಈ ಹಂತಕ್ಕೆ ಯಾವುದೇ ಹೆಚ್ಚಿನ ತರ್ಕದ (reasoning) ಅಗತ್ಯವಿಲ್ಲ. ಇದು ಕೇವಲ ಮಾಹಿತಿ ಹೊರತೆಗೆಯುವಿಕೆ (extraction) ಮತ್ತು ಫಾರ್ಮ್ಯಾಟಿಂಗ್ ಆಗಿರುವುದರಿಂದ, ಇದು ಲಘು ಹಾರ್ಡ್ವೇರ್ನಲ್ಲಿಯೂ ಕೆಲಸ ಮಾಡುತ್ತದೆ.
ಈ ವಿಭಜನೆಯು ಸ್ಪಷ್ಟವಾಗಿರುವುದರಿಂದ, ನಾನು ದೃಢೀಕರಣ ತರ್ಕಕ್ಕೆ (validation logic) ಯಾವುದೇ ಬದಲಾವಣೆ ಮಾಡದೆ ಬ್ಯಾಕೆಂಡ್ ಅನ್ನು ಬದಲಾಯಿಸಬಹುದು. ಮಾರ್ಕ್ಡೌನ್ ವರದಿಯು ಅನ್ವೇಷಣಾತ್ಮಕ ಮೆದುಳು ಮತ್ತು ನಾನು ಬಳಸುವ ರಚನಾತ್ಮಕ ಔಟ್ಪುಟ್ ನಡುವೆ ಒಂದು ಸಾರ್ವತ್ರಿಕ ಅಡಾಪ್ಟರ್ನಂತೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.
ವಾಸ್ತವವಾಗಿ ಯಾವುದು ಕೆಲಸ ಮಾಡಿತು
ಈ ವ್ಯವಸ್ಥೆಯು ಬರುವ ಸಮಸ್ಯೆಗಳನ್ನು (issues) ನಾನು ನಿರ್ವಹಿಸುವ ರೀತಿಯನ್ನೇ ಬದಲಾಯಿಸಿತು. ವರ್ಗೀಕರಣ ಪದರವು (classification layer) ಇಂದಿಗೂ ಬಗ್ಗಳನ್ನು (bugs) ಮತ್ತು ವೈಶಿಷ್ಟ್ಯದ ವಿನಂತಿಗಳನ್ನು (feature requests) ಪ್ರತ್ಯೇಕಿಸುತ್ತದೆ, ಆದರೆ ಈಗ ವಿಶ್ಲೇಷಣಾ ಪದರವು (analysis layer) ತಕ್ಷಣವೇ ಅದರ ನಂತರ ಕೆಲಸ ಆರಂಭಿಸುತ್ತದೆ. ನಾನು ಎಡಿಟರ್ ಅನ್ನು ತೆರೆಯುವಷ್ಟರಲ್ಲಿ, ಫೈಲ್ ಪಾತ್, ಲೈನ್ ರೇಂಜ್ ಮತ್ತು ಪ್ರಸ್ತಾವಿತ ಬದಲಾವಣೆಯು ನನ್ನ ಕಾಯುತ್ತಿರುತ್ತದೆ. ನಾನು ಇಂದಿಗೂ ಎಲ್ಲವನ್ನೂ ಸ್ವತಃ ಪರಿಶೀಲಿಸುತ್ತೇನೆ. ಇದು ಸಹಾಯವೇ ಹೊರತು ಆಟೋಪಿಲಟ್ ಅಲ್ಲ. ಆದರೆ ಹಿಂದೆ ಮಾಡಬೇಕಾಗುತ್ತಿದ್ದ ಸಂದರ್ಭದ ಮಾಹಿತಿ ಸಂಗ್ರಹಣೆಯು