ಮುಖ್ಯ ವಿಷಯಕ್ಕೆ ನೇರವಾಗಿ ಹೋಗಿ
OpenAI

ಫೆಬ್ರವರಿ 11, 2026

ಎಂಜಿನಿಯರಿಂಗ್

ಹಾರ್ನೆಸ್ ಎಂಜಿನಿಯರಿಂಗ್: ಏಜೆಂಟ್-ಪ್ರಥಮ ಜಗತ್ತಲ್ಲಿ Codex ಬಳಸುವುದು

ರೈಯನ್ ಲೋಪೋಪೋಲೋ, ತಾಂತ್ರಿಕ ಸಿಬ್ಬಂದಿಯ ಸದಸ್ಯ

ಲೋಡ್ ಆಗುತ್ತಿದೆ…

ಕಳೆದ ಐದು ತಿಂಗಳುಗಳಲ್ಲಿ, ನಮ್ಮ ತಂಡ ಒಂದು ಪ್ರಯೋಗವನ್ನು ನಡೆಸುತ್ತಿದೆ: ಕೈಯಾರೆ ಬರೆಯಲಾದ ಕೋಡ್‌ನ ಶೂನ್ಯ ಸಾಲುಗಳೊಂದಿಗೆ ಸಾಫ್ಟ್‌ವೇರ್ ಉತ್ಪನ್ನದ ಆಂತರಿಕ ಬೀಟಾವನ್ನು ನಿರ್ಮಿಸಿ ರವಾನಿಸಿದೆ.

ಉತ್ಪನ್ನಕ್ಕೆ ಆಂತರಿಕ ದೈನಂದಿನ ಬಳಕೆದಾರರು ಮತ್ತು ಬಾಹ್ಯ ಆಲ್ಫಾ ಪರೀಕ್ಷಕರು ಇದ್ದಾರೆ. ಇದು ರವಾನಿಸಲಾಗುತ್ತದೆ, ನಿಯೋಜಿಸಲಾಗುತ್ತದೆ, ಕೆಡುತ್ತದೆ ಮತ್ತು ಸರಿಪಡಿಸಲಾಗುತ್ತದೆ. ವ್ಯತ್ಯಾಸವೆಂದರೆ ಕೋಡ್‌ನ ಪ್ರತಿಯೊಂದು ಸಾಲು—ಅಪ್ಲಿಕೇಶನ್ ಲಾಜಿಕ್, ಪರೀಕ್ಷೆಗಳು, CI ಸಂರಚನೆ, ಡಾಕ್ಯುಮೆಂಟೇಶನ್, ಆಬ್ಸರ್ವೆಬಿಲಿಟಿ ಮತ್ತು ಆಂತರಿಕ ಉಪಕರಣಗಳು—Codex ಮೂಲಕ ಬರೆಯಲಾಗಿದೆ. ನಾವು ಇದನ್ನು ಕೈಯಿಂದ ಕೋಡ್ ಬರೆಯಲು ಬೇಕಾಗುವ ಸಮಯದ 1/10 ರಷ್ಟು ಸಮಯದಲ್ಲಿ ನಿರ್ಮಿಸಿದ್ದೇವೆ ಎಂದು ಅಂದಾಜಿಸುತ್ತೇವೆ.

ಮಾನವರು ಚಾಲನೆ ಮಾಡುತ್ತಾರೆ. ಏಜೆಂಟ್‌ಗಳು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ.

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

ಈ ಪೋಸ್ಟ್ ಏಜೆಂಟ್‌ಗಳ ತಂಡದೊಂದಿಗೆ ಹೊಸ ಉತ್ಪನ್ನವನ್ನು ನಿರ್ಮಿಸುವ ಮೂಲಕ ನಾವು ಕಲಿತದ್ದರ ಬಗ್ಗೆ—ಏನು ತಪ್ಪಾಯಿತು, ಏನು ಸಂಕೀರ್ಣವಾಯಿತು ಮತ್ತು ನಮ್ಮ ಅಪರೂಪದ ಸಂಪನ್ಮೂಲವಾದ ಮಾನವ ಸಮಯ ಮತ್ತು ಗಮನವನ್ನು ಹೇಗೆ ಗರಿಷ್ಠಗೊಳಿಸಬೇಕು ಎಂಬುದರ ಬಗ್ಗೆ.

ನಾವು ಖಾಲಿ git ರಿಪೊಸಿಟರಿಯಿಂದ ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ.

ಖಾಲಿ ರಿಪೊಸಿಟರಿಗೆ ಮೊದಲ ಕಮಿಟ್ 2025ರ ಆಗಸ್ಟ್ ಅಂತ್ಯದ ವೇಳೆಗೆ ಸೇರಿಸಲಾಯಿತು.

ಆರಂಭಿಕ ಸ್ಕ್ಯಾಫೋಲ್ಡ್—ರಿಪೊಸಿಟರಿ ರಚನೆ, CI ಸಂರಚನೆ, ಫಾರ್ಮ್ಯಾಟಿಂಗ್ ನಿಯಮಗಳು, ಪ್ಯಾಕೇಜ್ ಮ್ಯಾನೇಜರ್ ಸೆಟಪ್ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಫ್ರೇಮ್‌ವರ್ಕ್—Codex CLI ಮೂಲಕ GPT‑5 ಬಳಸಿ, ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಟೆಂಪ್ಲೇಟ್‌ಗಳ ಸಣ್ಣ ಸಮೂಹದ ಮಾರ್ಗದರ್ಶನದಲ್ಲಿ ರಚಿಸಲಾಯಿತು. ರಿಪೊಸಿಟರಿಯಲ್ಲಿ ಏಜೆಂಟ್‌ಗಳು ಹೇಗೆ ಕೆಲಸ ಮಾಡಬೇಕು ಎಂದು ಮಾರ್ಗದರ್ಶನ ನೀಡುವ ಆರಂಭಿಕ AGENTS.md ಫೈಲ್ ಕೂಡ Codex ನಿಂದಲೇ ಬರೆಯಲ್ಪಟ್ಟಿತ್ತು.

ವ್ಯವಸ್ಥೆಯನ್ನು ಆಧರಿಸಲು ಪೂರ್ವ-ಅಸ್ತಿತ್ವದಲ್ಲಿದ್ದ ಮಾನವ-ಬರೆದ ಕೋಡ್ ಇರಲಿಲ್ಲ. ಆರಂಭದಿಂದಲೇ, ರಿಪೊಸಿಟರಿಯನ್ನು ಏಜೆಂಟ್ ರೂಪಿಸಿತು.

ಐದು ತಿಂಗಳುಗಳ ನಂತರ, ರಿಪೊಸಿಟರಿ ಅಪ್ಲಿಕೇಶನ್ ಲಾಜಿಕ್, ಮೂಲಸೌಕರ್ಯ, ಟೂಲಿಂಗ್, ಡಾಕ್ಯುಮೆಂಟೇಶನ್, ಮತ್ತು ಆಂತರಿಕ ಡೆವಲಪರ್ ಉಪಯುಕ್ತತೆಗಳಲ್ಲಿ ಸುಮಾರು ಒಂದು ಮಿಲಿಯನ್ ಸಾಲುಗಳ ಕೋಡ್ ಅನ್ನು ಹೊಂದಿರುತ್ತದೆ. ಆ ಅವಧಿಯಲ್ಲಿ, ಸುಮಾರು 1,500 pull request ಗಳನ್ನು ತೆರೆಯಲಾಗಿದೆ ಮತ್ತು ವಿಲೀನಗೊಳಿಸಲಾಗಿದೆ, Codex ಅನ್ನು ಮುನ್ನಡೆಸಲು ಕೇವಲ ಮೂರು ಎಂಜಿನಿಯರ್‌ಗಳ ಸಣ್ಣ ತಂಡವೊಂದೇ ಚಾಲನೆ ನೀಡಿದೆ. ಇದು ಪ್ರತಿ ಎಂಜಿನಿಯರ್‌ಗೆ ಪ್ರತಿ ದಿನ ಸರಾಸರಿ 3.5 PRs ಥ್ರೂಪುಟ್‌ಗೆ ಅನುವಾದವಾಗುತ್ತದೆ ಮತ್ತು ಆಶ್ಚರ್ಯಕರವಾಗಿ ತಂಡವು ಈಗ ಏಳು ಎಂಜಿನಿಯರ್‌ಗಳವರೆಗೆ ಬೆಳೆದಂತೆ ಥ್ರೂಪುಟ್ ಹೆಚ್ಚಿದೆ. ಮುಖ್ಯವಾಗಿ, ಇದು ಔಟ್‌ಪುಟ್‌ಗಾಗಿ ಔಟ್‌ಪುಟ್ ಅಲ್ಲ: ಈ ಉತ್ಪನ್ನವನ್ನು ದೈನಂದಿನ ಆಂತರಿಕ ಶಕ್ತಿಶಾಲಿ ಬಳಕೆದಾರರನ್ನು ಒಳಗೊಂಡಂತೆ ನೂರಾರು ಆಂತರಿಕ ಬಳಕೆದಾರರು ಬಳಸಿದ್ದಾರೆ.

ಅಭಿವೃದ್ಧಿ ಪ್ರಕ್ರಿಯೆಯ ಅವಧಿಯಲ್ಲಿ, ಮಾನವರು ನೇರವಾಗಿ ಯಾವುದೇ ಕೋಡ್‌ಗೆ ಎಂದಿಗೂ ಕೊಡುಗೆ ನೀಡಲಿಲ್ಲ. ಇದು ತಂಡದ ಪ್ರಮುಖ ತತ್ತ್ವಶಾಸ್ತ್ರವಾಯಿತು: ಹಸ್ತಚಾಲಿತವಾಗಿ ಬರೆಯಲಾದ ಕೋಡ್ ಇಲ್ಲ.

ಎಂಜಿನಿಯರ್‌ನ ಪಾತ್ರವನ್ನು ಮರುಪರಿಭಾಷಿಸುವುದು

ಪ್ರಾಯೋಗಿಕ ಮಾನವ ಕೋಡಿಂಗ್‌ನ ಕೊರತೆಯು ಸಿಸ್ಟಮ್‌ಗಳು, ಸ್ಕಾಫೋಲ್ಡಿಂಗ್ ಮತ್ತು ಲಿವರೇಜ್ ಮೇಲೆ ಕೇಂದ್ರೀಕೃತವಾದ ವಿಭಿನ್ನ ರೀತಿಯ ಎಂಜಿನಿಯರಿಂಗ್ ಕೆಲಸವನ್ನು ಪರಿಚಯಿಸಿತು.

ನಾವು ನಿರೀಕ್ಷಿಸಿದ್ದಕ್ಕಿಂತ ಆರಂಭಿಕ ಪ್ರಗತಿ ನಿಧಾನವಾಗಿತ್ತು, Codex ಅಸಮರ್ಥವಾಗಿದ್ದರಿಂದ ಅಲ್ಲ, ಆದರೆ ಪರಿಸರವು ಸಮರ್ಪಕವಾಗಿ ನಿರ್ದಿಷ್ಟಗೊಳಿಸಲಾಗಿರಲಿಲ್ಲ. ಏಜೆಂಟ್‌ಗೆ ಉನ್ನತ ಮಟ್ಟದ ಗುರಿಗಳತ್ತ ಪ್ರಗತಿಯನ್ನು ಸಾಧಿಸಲು ಅಗತ್ಯವಾದ ಸಾಧನಗಳು, ಅಮೂರ್ತೀಕರಣಗಳು ಮತ್ತು ಆಂತರಿಕ ರಚನೆಗಳ ಕೊರತೆಯಿತ್ತು. ನಮ್ಮ ಎಂಜಿನಿಯರಿಂಗ್ ತಂಡದ ಮುಖ್ಯ ಕೆಲಸವು ಏಜೆಂಟ್‌ಗಳಿಗೆ ಉಪಯುಕ್ತ ಕೆಲಸವನ್ನು ಮಾಡಲು ಅನುಮತಿಸುವುದಾಗಿ ಮಾರ್ಪಟ್ಟಿತು.

ಪ್ರಾಯೋಗಿಕವಾಗಿ, ಇದರರ್ಥ ಆಳ-ಮುಖ್ಯತೆಯಾಗಿ ಕೆಲಸ ಮಾಡುವುದು: ದೊಡ್ಡ ಗುರಿಗಳನ್ನು ಸಣ್ಣ ನಿರ್ಮಾಣ ಘಟಕಗಳಾಗಿ (ವಿನ್ಯಾಸ, ಕೋಡ್, ವಿಮರ್ಶೆ, ಪರೀಕ್ಷೆ, ಇತ್ಯಾದಿ) ವಿಭಜಿಸುವುದು, ಆ ಘಟಕಗಳನ್ನು ನಿರ್ಮಿಸಲು ಏಜೆಂಟ್‌ಗೆ ಪ್ರೇರೇಪಣೆ ನೀಡುವುದು ಮತ್ತು ಅವುಗಳನ್ನು ಬಳಸಿ ಇನ್ನಷ್ಟು ಸಂಕೀರ್ಣ ಕಾರ್ಯಗಳನ್ನು ಅನ್ಲಾಕ್ ಮಾಡುವುದು. ಏನಾದರೂ ವಿಫಲವಾದಾಗ, ಪರಿಹಾರವು ಬಹುತೇಕ ಎಂದಿಗೂ “ಇನ್ನಷ್ಟು ಪ್ರಯತ್ನಿಸಿ” ಆಗಿರಲಿಲ್ಲ. ಪ್ರಗತಿ ಸಾಧಿಸಲು Codex ಕೆಲಸ ಮಾಡುವುದು ಅನಿವಾರ್ಯವಾಗಿದ್ದರಿಂದ, ಮಾನವ ಎಂಜಿನಿಯರ್‌ಗಳು ಯಾವಾಗಲೂ ಕಾರ್ಯಕ್ಕೆ ಮುಂದಾಗಿ ಕೇಳುತ್ತಿದ್ದರು: “ಯಾವ ಸಾಮರ್ಥ್ಯ ಕೊರತೆಯಾಗಿದೆ ಮತ್ತು ಅದನ್ನು ಏಜೆಂಟ್‌ಗೆ ಓದಲು ಸುಲಭವಾಗುವಂತೆ ಮತ್ತು ಜಾರಿಗೊಳಿಸಬಹುದಾಗುವಂತೆ ನಾವು ಹೇಗೆ ಮಾಡಬಹುದು?”

ಮಾನವರು ವ್ಯವಸ್ಥೆಯೊಂದಿಗೆ ಬಹುತೇಕ ಸಂಪೂರ್ಣವಾಗಿ ಪ್ರಾಂಪ್ಟ್‌ಗಳ ಮೂಲಕ ಸಂವಹನ ಮಾಡುತ್ತಾರೆ: ಒಬ್ಬ ಎಂಜಿನಿಯರ್ ಒಂದು ಕಾರ್ಯವನ್ನು ವಿವರಿಸುತ್ತಾರೆ, ಏಜೆಂಟ್ ಅನ್ನು ಚಾಲನೆ ಮಾಡುತ್ತಾರೆ ಮತ್ತು ಅದಕ್ಕೆ pull request ತೆರೆಯಲು ಅನುಮತಿಸುತ್ತಾರೆ. PR ಅನ್ನು ಪೂರ್ಣಗೊಳಿಸಲು, ನಾವು Codex ಗೆ ತನ್ನ ಬದಲಾವಣೆಗಳನ್ನು ಸ್ಥಳೀಯವಾಗಿ ಪರಿಶೀಲಿಸಲು, ಸ್ಥಳೀಯ ಮತ್ತು ಕ್ಲೌಡ್‌ನಲ್ಲಿ ಹೆಚ್ಚುವರಿ ನಿರ್ದಿಷ್ಟ ಏಜೆಂಟ್ ವಿಮರ್ಶೆಗಳನ್ನು ಕೇಳಲು, ಮಾನವ ಅಥವಾ ಏಜೆಂಟ್ ನೀಡಿದ ಪ್ರತಿಕ್ರಿಯೆಗೆ ಪ್ರತಿಕ್ರಿಯಿಸಲು ಮತ್ತು ಎಲ್ಲಾ ಏಜೆಂಟ್ ವಿಮರ್ಶಕರು ತೃಪ್ತರಾಗುವವರೆಗೆ ಲೂಪ್‌ನಲ್ಲಿ ಪುನರಾವರ್ತಿಸಲು ಸೂಚಿಸುತ್ತೇವೆ (ಇದು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ರಾಲ್ಫ್ ವಿಗಂ ಲೂಪ್(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ)). Codex ನಮ್ಮ ಮಾನಕ ಅಭಿವೃದ್ಧಿ ಉಪಕರಣಗಳನ್ನು ನೇರವಾಗಿ (gh, ಸ್ಥಳೀಯ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳು ಮತ್ತು ರಿಪೊಸಿಟರಿ-ಎಂಬೆಡೆಡ್ ಕೌಶಲ್ಯಗಳು) ಬಳಸುತ್ತದೆ, CLI ಗೆ ಮಾನವರು ಕಾಪಿ-ಪೇಸ್ಟ್ ಮಾಡದೇ ಸನ್ನಿವೇಶವನ್ನು ಸಂಗ್ರಹಿಸಲು.

ಮಾನವರು pull requests‌ಗಳನ್ನು ಪರಿಶೀಲಿಸಬಹುದು, ಆದರೆ ಅವುಗಳನ್ನು ಪರಿಶೀಲಿಸುವುದು ಅಗತ್ಯವಿಲ್ಲ. ಕಾಲಕ್ರಮೇಣ, ನಾವು ಬಹುತೇಕ ಎಲ್ಲಾ ವಿಮರ್ಶಾ ಪ್ರಯತ್ನವನ್ನು ಏಜೆಂಟ್-ನಿಂದ-ಏಜೆಂಟ್‌ಗೆ ನಿರ್ವಹಿಸಲು ತಳ್ಳಿದ್ದೇವೆ.

ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ಓದುಗತೆಯನ್ನು ಹೆಚ್ಚಿಸುವುದು

ಕೋಡ್ ಥ್ರೂಪುಟ್ ಹೆಚ್ಚಿದಂತೆ, ನಮ್ಮ ಬಾಟಲ್‌ನೆಕ್ ಮಾನವ QA ಸಾಮರ್ಥ್ಯವಾಗಿ ಮಾರ್ಪಟ್ಟಿತು. ಸ್ಥಿರ ನಿರ್ಬಂಧವು ಮಾನವ ಸಮಯ ಮತ್ತು ಗಮನವಾಗಿರುವುದರಿಂದ, ಅಪ್ಲಿಕೇಶನ್ UI, ಲಾಗ್‌ಗಳು ಮತ್ತು ಆ್ಯಪ್ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು Codex ಗೆ ನೇರವಾಗಿ ಓದಲು ಸಾಧ್ಯವಾಗುವಂತೆ ಮಾಡುವ ಮೂಲಕ, ಏಜೆಂಟ್‌ಗೆ ಹೆಚ್ಚಿನ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಸೇರಿಸಲು ನಾವು ಪ್ರಯತ್ನಿಸಿದ್ದೇವೆ.

ಉದಾಹರಣೆಗೆ, ನಾವು ಆಪ್ ಅನ್ನು git worktree ಪ್ರತಿ ಬೂಟಬಲ್ ಆಗಿ ಮಾಡಿದ್ದೇವೆ, ಆದ್ದರಿಂದ Codex ಪ್ರತಿ ಬದಲಾವಣೆಗೆ ಒಂದು ಉದಾಹರಣೆಯನ್ನು ಪ್ರಾರಂಭಿಸಿ ಚಾಲನೆ ಮಾಡಬಹುದು. ನಾವು Chrome DevTools Protocol ಅನ್ನು ಏಜೆಂಟ್ ರನ್‌ಟೈಮ್‌ಗೆ ಸಂಪರ್ಕಿಸಿದ್ದೇವೆ ಮತ್ತು DOM ಸ್ನ್ಯಾಪ್‌ಶಾಟ್‌ಗಳು, ಸ್ಕ್ರೀನ್‌ಶಾಟ್‌ಗಳು ಮತ್ತು ನ್ಯಾವಿಗೇಶನ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಕೌಶಲ್ಯಗಳನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಿದ್ದೇವೆ. ಇದು Codex ಗೆ ದೋಷಗಳನ್ನು ಪುನರುತ್ಪಾದಿಸಲು, ಪರಿಹಾರಗಳನ್ನು ಮಾನ್ಯಗೊಳಿಸಲು ಮತ್ತು UI ನಡವಳಿಕೆಯನ್ನು ನೇರವಾಗಿ ವಿಶ್ಲೇಷಿಸಲು ಅನುಮತಿಸಿತು.

“Codex Chrome DevTools MCP ಮೂಲಕ ಆ್ಯಪ್ ಅನ್ನು ಚಾಲನೆ ಮಾಡಿ ತನ್ನ ಕೆಲಸವನ್ನು ಮೌಲ್ಯೀಕರಿಸುತ್ತದೆ” ಎಂಬ ಶೀರ್ಷಿಕೆಯ ಡಯಾಗ್ರಾಂ. Codex ಒಂದು ಗುರಿಯನ್ನು ಆಯ್ಕೆಮಾಡುತ್ತದೆ, UI ಪಾತ್ ಅನ್ನು ಟ್ರಿಗರ್ ಮಾಡುವ ಮೊದಲು ಮತ್ತು ನಂತರದ ಸ್ಥಿತಿಯನ್ನು ಸ್ನ್ಯಾಪ್‌ಶಾಟ್ ಮಾಡುತ್ತದೆ, Chrome DevTools ಮೂಲಕ ರನ್‌ಟೈಮ್ ಈವೆಂಟ್‌ಗಳನ್ನು ಗಮನಿಸುತ್ತದೆ, ಪರಿಹಾರಗಳನ್ನು ಅನ್ವಯಿಸುತ್ತದೆ, ಮರುಪ್ರಾರಂಭಿಸುತ್ತದೆ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಸ್ವಚ್ಛವಾಗುವವರೆಗೆ ವ್ಯಾಲಿಡೇಶನ್ ಅನ್ನು ಮರು-ಚಲಾಯಿಸುವ ಲೂಪ್ ಅನ್ನು ಪುನರಾವರ್ತಿಸುತ್ತದೆ.

ನಾವು ಪರಿವೀಕ್ಷಣಾ ಸಾಧನಗಳಿಗಾಗಿ ಕೂಡ ಅದೇ ಮಾಡಿದೆವು. ಲಾಗ್‌ಗಳು, ಮೆಟ್ರಿಕ್‌ಗಳು ಮತ್ತು ಟ್ರೇಸ್‌ಗಳನ್ನು ಯಾವುದೇ ನಿರ್ದಿಷ್ಟ ವರ್ಕ್‌ಟ್ರೀಗಾಗಿ ಅಲ್ಪಕಾಲಿಕವಾಗಿರುವ ಸ್ಥಳೀಯ ಆಬ್ಸರ್ವಬಿಲಿಟಿ ಸ್ಟ್ಯಾಕ್ ಮೂಲಕ Codex ಗೆ ಬಹಿರಂಗಗೊಳಿಸಲಾಗುತ್ತದೆ. Codex ಆ ಅಪ್ಲಿಕೇಶನ್‌ನ ಸಂಪೂರ್ಣವಾಗಿ ಪ್ರತ್ಯೇಕಿತ ಆವೃತ್ತಿಯಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ—ಅದರ ಲಾಗ್‌ಗಳು ಮತ್ತು ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಒಳಗೊಂಡಂತೆ, ಆ ಕಾರ್ಯ ಪೂರ್ಣಗೊಂಡ ನಂತರ ಅವುಗಳನ್ನು ತೆಗೆದುಹಾಕಲಾಗುತ್ತದೆ. ಏಜೆಂಟ್‌ಗಳು LogQL ಬಳಸಿ ಲಾಗ್‌ಗಳನ್ನು ಮತ್ತು PromQL ಬಳಸಿ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಕ್ವೇರಿ ಮಾಡಬಹುದು. ಈ ಸಂದರ್ಭ ಲಭ್ಯವಿರುವುದರಿಂದ, “800ms ಒಳಗೆ ಸೇವೆಯ ಆರಂಭವನ್ನು ಪೂರ್ಣಗೊಳ್ಳುವಂತೆ ಖಚಿತಪಡಿಸಿ” ಅಥವಾ “ಈ ನಾಲ್ಕು ನಿರ್ಣಾಯಕ ಬಳಕೆದಾರ ಪ್ರಯಾಣಗಳಲ್ಲಿ ಯಾವುದೇ ಸ್ಪ್ಯಾನ್ ಎರಡು ಸೆಕೆಂಡುಗಳನ್ನು ಮೀರಬಾರದು” ಎಂಬಂತಹ ಪ್ರಾಂಪ್ಟ್‌ಗಳು ಸುಲಭವಾಗಿ ನಿರ್ವಹಿಸಬಹುದಾಗುತ್ತವೆ.

“ಸ್ಥಳೀಯ ಡೆವ್‌ನಲ್ಲಿ Codex ಗೆ ಸಂಪೂರ್ಣ ವೀಕ್ಷಣೀಯತೆ ಸ್ಟ್ಯಾಕ್ ನೀಡುವುದು” ಎಂಬ ಶೀರ್ಷಿಕೆಯ ಡಯಾಗ್ರಾಂ. ಒಂದು ಆಪ್ ಲಾಗ್‌ಗಳು, ಮೆಟ್ರಿಕ್‌ಗಳು ಮತ್ತು ಟ್ರೇಸ್‌ಗಳನ್ನು ವೆಕ್ಟರ್ ಗೆ ಕಳುಹಿಸುತ್ತದೆ, ಅದು ಡೇಟಾವನ್ನು ವಿಕ್ಟೋರಿಯಾ ಲಾಗ್‌ಗಳು, ಮೆಟ್ರಿಕ್ಸ್ ಮತ್ತು ಟ್ರೇಸ್‌ಗಳು ಒಳಗೊಂಡಿರುವ ವೀಕ್ಷಣಾ ಸ್ಟಾಕ್ ಗೆ ವಿತರಿಸುತ್ತದೆ. ಪ್ರತಿಯೊಂದನ್ನೂ LogQL, PromQL, ಅಥವಾ TraceQL API ಗಳ ಮೂಲಕ ಕ್ವೇರಿ ಮಾಡಲಾಗುತ್ತದೆ. Codex ಈ ಸಿಗ್ನಲ್‌ಗಳನ್ನು ಕ್ವೆರಿ, ಕೊರಿಲೇಟ್ ಮತ್ತು ರೀಸನ್ ಮಾಡಲು ಬಳಸುತ್ತದೆ, ನಂತರ ಕೋಡ್‌ಬೇಸ್‌ನಲ್ಲಿ ತಿದ್ದುಪಡಿ ಮಾಡುತ್ತದೆ, ಆಪ್ ಅನ್ನು ಮರುಪ್ರಾರಂಭಿಸುತ್ತದೆ, ವರ್ಕ್‌ಲೋಡ್‌ಗಳನ್ನು ಮರು-ರನ್ ಮಾಡುತ್ತದೆ, UI ಜರ್ನಿಗಳನ್ನು ಪರೀಕ್ಷಿಸುತ್ತದೆ ಮತ್ತು ಫೀಡ್‌ಬ್ಯಾಕ್ ಲೂಪ್‌ನಲ್ಲಿ ಪುನರಾವರ್ತಿಸುತ್ತದೆ.

ನಾವು ನಿಯಮಿತವಾಗಿ ಒಂದೇ Codex ರನ್ ಒಂದೇ ಕಾರ್ಯದ ಮೇಲೆ ಆರು ಗಂಟೆಗಳಿಗಿಂತ ಹೆಚ್ಚು ಕಾಲ ಕೆಲಸ ಮಾಡುವುದನ್ನು ನೋಡುತ್ತೇವೆ (ಅನೇಕ ಬಾರಿ ಮಾನವರು ನಿದ್ರಿಸುತ್ತಿರುವಾಗ).

ನಾವು ರಿಪೊಸಿಟರಿ ಜ್ಞಾನವನ್ನು ದಾಖಲೆ ವ್ಯವಸ್ಥೆಯಾಗಿ ಮಾಡಿದ್ದೇವೆ

ಸಂದರ್ಭ ನಿರ್ವಹಣೆ ದೊಡ್ಡ ಮತ್ತು ಸಂಕೀರ್ಣ ಕಾರ್ಯಗಳನ್ನು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ನಿರ್ವಹಿಸಲು ಏಜೆಂಟ್‌ಗಳನ್ನು ಪರಿಣಾಮಕಾರಿಯಾಗಿಸುವಲ್ಲಿ ಅತಿದೊಡ್ಡ ಸವಾಲುಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ. ನಾವು ಕಲಿತ ಅತ್ಯಂತ ಆರಂಭಿಕ ಪಾಠಗಳಲ್ಲಿ ಒಂದು ಸರಳವಾಗಿತ್ತು: Codex ಗೆ 1,000-ಪುಟಗಳ ಸೂಚನಾ ಕೈಪಿಡಿಯ ಬದಲು, ಒಂದು ನಕ್ಷೆಯನ್ನು ನೀಡಿ.

ನಾವು “ಒಂದು ದೊಡ್ಡ AGENTS.md(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ)” ವಿಧಾನವನ್ನು ಪ್ರಯತ್ನಿಸಿದ್ದೇವೆ. ಇದು ನಿರೀಕ್ಷಿತ ರೀತಿಗಳಲ್ಲಿ ವಿಫಲವಾಯಿತು:

  • ಸಂದರ್ಭವು ಅಪರೂಪದ ಸಂಪನ್ಮೂಲವಾಗಿದೆ. ಒಂದು ದೈತ್ಯ ಸೂಚನಾ ಫೈಲ್ ಕಾರ್ಯ, ಕೋಡ್, ಮತ್ತು ಸಂಬಂಧಿತ ಡಾಕ್ಯುಮೆಂಟ್‌ಗಳನ್ನು ಮರೆಮಾಡುತ್ತದೆ—ಹೀಗಾಗಿ ಏಜೆಂಟ್ either ಮುಖ್ಯ ನಿರ್ಬಂಧಗಳನ್ನು ತಪ್ಪಿಸಿಕೊಳ್ಳುತ್ತದೆ ಅಥವಾ ತಪ್ಪು ನಿರ್ಬಂಧಗಳಿಗಾಗಿ ಆಪ್ಟಿಮೈಸ್ ಮಾಡಲು ಆರಂಭಿಸುತ್ತದೆ.
  • ಅತಿಯಾದ ಮಾರ್ಗದರ್ಶನ ಮಾರ್ಗದರ್ಶನವಲ್ಲ. ಎಲ್ಲವೂ “ಮುಖ್ಯ” ಆಗಿದ್ದರೆ, ಯಾವುದೂ ಮುಖ್ಯವಲ್ಲ. ಏಜೆಂಟ್‌ಗಳು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ನ್ಯಾವಿಗೇಟ್ ಮಾಡುವ ಬದಲು ಸ್ಥಳೀಯವಾಗಿ ಮಾದರಿ ಹೊಂದಿಸುವಿಕೆಯಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುತ್ತವೆ.
  • ಇದು ತಕ್ಷಣವೇ ಹಾಳಾಗುತ್ತದೆ. ಏಕಘಟಕ ಮ್ಯಾನುಯಲ್ ಹಳೆಯ ನಿಯಮಗಳ ಸ್ಮಶಾನವಾಗಿ ಮಾರ್ಪಡುತ್ತದೆ. ಏಜೆಂಟ್‌ಗಳು ಯಾವುದು ಇನ್ನೂ ಸತ್ಯವೋ ಅದನ್ನು ತಿಳಿಯಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ, ಮಾನವರು ಅದನ್ನು ನಿರ್ವಹಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತಾರೆ ಮತ್ತು ಫೈಲ್ ಮೌನವಾಗಿ ಆಕರ್ಷಕ ತೊಂದರೆಯಾಗಿ ಮಾರ್ಪಡುತ್ತದೆ.
  • ಇದು ಪರಿಶೀಲಿಸಲು ಕಷ್ಟಕರವಾಗಿದೆ. ಒಂದು ಏಕೈಕ blob ಯಾಂತ್ರಿಕ ಪರಿಶೀಲನೆಗಳಿಗೆ (ಕವರೆಜ್, ತಾಜಾತನ, ಮಾಲೀಕತ್ವ, ಕ್ರಾಸ್-ಲಿಂಕ್ಸ್) ಅನುಕೂಲಕರವಾಗಿಲ್ಲ, ಆದ್ದರಿಂದ ಡ್ರಿಫ್ಟ್ ಅನಿವಾರ್ಯ.

ಆದ್ದರಿಂದ AGENTS.md ಅನ್ನು ವಿಶ್ವಕೋಶವಾಗಿ ಪರಿಗಣಿಸುವ ಬದಲು, ನಾವು ಅದನ್ನು ವಿಷಯಸೂಚಿಯಂತೆ ಪರಿಗಣಿಸುತ್ತೇವೆ.

ರಿಪೊಸಿಟರಿಯ ಜ್ಞಾನಕೋಶವು ರಚಿತ docs/ ಡೈರೆಕ್ಟರಿಯಲ್ಲಿ ಇರುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ದಾಖಲೆ ವ್ಯವಸ್ಥೆಯಾಗಿ ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ. ಒಂದು ಚಿಕ್ಕ AGENTS.md (ಸುಮಾರು 100 ಸಾಲುಗಳು) ಅನ್ನು ಸಂದರ್ಭಕ್ಕೆ ಸೇರಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಅದು ಮುಖ್ಯವಾಗಿ ನಕ್ಷೆಯಂತೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಬೇರೆಡೆ ಇರುವ ಆಳವಾದ ಸತ್ಯದ ಮೂಲಗಳಿಗೆ ಸೂಚನೆಗಳನ್ನು ನೀಡುತ್ತದೆ.

ಸರಳ ಪಠ್ಯ

1
AGENTS.md
2
ARCHITECTURE.md
3
docs/
4
├── design-docs/
5
│ ├── index.md
6
│ ├── core-beliefs.md
7
│ └── ...
8
├── exec-plans/
9
│ ├── active/
10
│ ├── completed/
11
│ └── tech-debt-tracker.md
12
├── generated/
13
│ └── db-schema.md
14
├── product-specs/
15
│ ├── index.md
16
│ ├── new-user-onboarding.md
17
│ └── ...
18
├── references/
19
│ ├── design-system-reference-llms.txt
20
│ ├── nixpacks-llms.txt
21
│ ├── uv-llms.txt
22
│ └── ...
23
├── DESIGN.md
24
├── FRONTEND.md
25
├── PLANS.md
26
├── PRODUCT_SENSE.md
27
├── QUALITY_SCORE.md
28
├── RELIABILITY.md
29
└── SECURITY.md

ರಿಪೊಸಿಟರಿ ಒಳಗಿನ ಜ್ಞಾನ ಸಂಗ್ರಹಣೆಯ ವಿನ್ಯಾಸ.

ವಿನ್ಯಾಸ ಡಾಕ್ಯುಮೆಂಟೇಶನ್ ಅನ್ನು ಕ್ಯಾಟಲಾಗ್ ಮಾಡಲಾಗಿದ್ದು, ಸೂಚ್ಯಂಕಗೊಳಿಸಲಾಗಿದೆ, ಇದರಲ್ಲಿ ಪರಿಶೀಲನೆ ಸ್ಥಿತಿ ಮತ್ತು ಏಜೆಂಟ್-ಪ್ರಥಮ ಕಾರ್ಯಾಚರಣೆ ತತ್ವಗಳನ್ನು ನಿರ್ಧರಿಸುವ ಮೂಲ ನಂಬಿಕೆಗಳ ಸಮೂಹವನ್ನು ಒಳಗೊಂಡಿದೆ. ವಾಸ್ತುಶಿಲ್ಪ ಡಾಕ್ಯುಮೆಂಟೇಶನ್(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ) ಡೊಮೇನ್‌ಗಳು ಮತ್ತು ಪ್ಯಾಕೇಜ್ ಲೇಯರಿಂಗ್‌ನ ಉನ್ನತ ಮಟ್ಟದ ನಕ್ಷೆಯನ್ನು ಒದಗಿಸುತ್ತದೆ. ಗುಣಮಟ್ಟದ ಡಾಕ್ಯುಮೆಂಟ್ ಪ್ರತಿಯೊಂದು ಉತ್ಪನ್ನ ಕ್ಷೇತ್ರ ಮತ್ತು ಆರ್ಕಿಟೆಕ್ಚರಲ್ ಲೇಯರ್‌ಗೆ ಶ್ರೇಣಿಯನ್ನು ನೀಡುತ್ತದೆ ಮತ್ತು ಕಾಲಕ್ರಮೇಣ ಅಂತರಗಳನ್ನು ಹತ್ತಿರದಿಂದ ಗಮನಿಸುತ್ತದೆ.

ಯೋಜನೆಗಳನ್ನು ಪ್ರಥಮ ದರ್ಜೆಯ ವಸ್ತುಗಳಂತೆ ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ. ಸಣ್ಣ ಬದಲಾವಣೆಗಳಿಗೆ ತಾತ್ಕಾಲಿಕ ಲಘು ತೂಕದ ಯೋಜನೆಗಳನ್ನು ಬಳಸಲಾಗುತ್ತದೆ, ಆದರೆ ಸಂಕೀರ್ಣ ಕೆಲಸವನ್ನು ಪ್ರಗತಿ ಮತ್ತು ನಿರ್ಧಾರ ಲಾಗ್‌ಗಳೊಂದಿಗೆ ಕಾರ್ಯಗತ ಯೋಜನೆಗಳಲ್ಲಿ(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ) ಸೆರೆಹಿಡಿದು ರಿಪೊಸಿಟರಿಯಲ್ಲಿ ದಾಖಲಿಸಲಾಗುತ್ತದೆ. ಸಕ್ರಿಯ ಯೋಜನೆಗಳು, ಪೂರ್ಣಗೊಂಡ ಯೋಜನೆಗಳು, ಮತ್ತು ತಿಳಿದಿರುವ ತಾಂತ್ರಿಕ ಸಾಲವು ಆವೃತ್ತೀಕರಿಸಲ್ಪಟ್ಟು ಒಂದೇ ಸ್ಥಳದಲ್ಲಿ ಇರಿಸಲಾಗಿದ್ದು, ಏಜೆಂಟ್‌ಗಳು ಬಾಹ್ಯ ಸಂದರ್ಭದ ಮೇಲೆ ಅವಲಂಬಿಸದೆ ಕಾರ್ಯನಿರ್ವಹಿಸಲು ಅವಕಾಶ ಮಾಡಿಕೊಡುತ್ತವೆ.

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

ನಾವು ಇದನ್ನು ಯಾಂತ್ರಿಕವಾಗಿ ಜಾರಿಗೊಳಿಸುತ್ತೇವೆ. ಮೀಸಲಾದ ಲಿಂಟರ್‌ಗಳು ಮತ್ತು CI jobs ಜ್ಞಾನಕೋಶವನ್ನು ನವೀಕರಿಸಲಾಗಿದೆ, ಕ್ರಾಸ್-ಲಿಂಕ್ ಮಾಡಲಾಗಿದೆ ಮತ್ತು ಸರಿಯಾಗಿ ರಚಿಸಲಾಗಿದೆ ಎಂದು ಪರಿಶೀಲಿಸುತ್ತವೆ. ಮರುಕಳಿಸುವ “ಡಾಕ್-ತೋಟಗಾರಿಕೆ” ಏಜೆಂಟ್ ನಿಜವಾದ ಕೋಡ್ ವರ್ತನೆಯನ್ನು ಪ್ರತಿಬಿಂಬಿಸದ ಹಳೆಯ ಅಥವಾ ಅವಧಿ ಮೀರಿದ ಡಾಕ್ಯುಮೆಂಟೇಶನ್‌ಗಾಗಿ ಸ್ಕ್ಯಾನ್ ಮಾಡಿ, ಸರಿಪಡಿಸುವ pull request‌ಗಳನ್ನು ತೆರೆಯುತ್ತದೆ.

ಏಜೆಂಟ್ ಓದಲು ಸುಲಭವಾಗಿರುವುದೇ ಗುರಿ

ಕೋಡ್‌ಬೇಸ್ ವಿಕಸನಗೊಳ್ಳುತ್ತಿದ್ದಂತೆ, ವಿನ್ಯಾಸ ನಿರ್ಧಾರಗಳಿಗಾಗಿ Codex ಚೌಕಟ್ಟು ಕೂಡ ವಿಕಸನಗೊಳ್ಳಬೇಕಾಗಿತ್ತು.

ರಿಪೊಸಿಟರಿ ಸಂಪೂರ್ಣವಾಗಿ ಏಜೆಂಟ್-ಜನಿತವಾಗಿರುವುದರಿಂದ, ಇದು ಮೊದಲಿಗೆ Codex ಪಠ್ಯಪಾರ್ಶ್ವದ ಆಪ್ಟಿಮೈಜೇಶನ್‌ಗೆ ಹೊಂದಿಸಲಾಗಿದೆ. ಹೊಸ ಎಂಜಿನಿಯರಿಂಗ್ ನೇಮಕಾತಿಗಳಿಗಾಗಿ ತಮ್ಮ ಕೋಡ್‌ನ ನ್ಯಾವಿಗೇಶನ್ ಸುಲಭತೆಯನ್ನು ಸುಧಾರಿಸಲು ತಂಡಗಳು ಪ್ರಯತ್ನಿಸುವ ರೀತಿಯಲ್ಲೇ, ನಮ್ಮ ಮಾನವ ಎಂಜಿನಿಯರ್‌ಗಳ ಗುರಿಯೂ ಏಜೆಂಟ್‌ಗೆ ಸಂಪೂರ್ಣ ವ್ಯವಹಾರ ಡೊಮೇನ್ ಬಗ್ಗೆ ರಿಪೊಸಿಟರಿಯಿಂದ ನೇರವಾಗಿ ತರ್ಕಿಸಲು ಸಾಧ್ಯವಾಗಿಸುವುದು.

ಏಜೆಂಟ್‌ನ ದೃಷ್ಟಿಕೋನದಿಂದ, ಅದು ಕಾರ್ಯನಿರ್ವಹಿಸುವಾಗ ಕಾಂಟೆಕ್ಸ್‌ಟ್‌ನಲ್ಲಿ ಪ್ರವೇಶಿಸಲು ಸಾಧ್ಯವಾಗದ ಯಾವುದೂ ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲ. Google Docs, ಚಾಟ್ ಥ್ರೆಡ್‌ಗಳು ಅಥವಾ ಜನರ ತಲೆಯಲ್ಲಿರುವ ಜ್ಞಾನವು ವ್ಯವಸ್ಥೆಗೆ ಪ್ರವೇಶಯೋಗ್ಯವಾಗಿಲ್ಲ. ರಿಪೊಸಿಟರಿ-ಸ್ಥಳೀಯ, ಆವೃತ್ತಿಗೊಳಿಸಿದ ಆಬ್ಜೆಕ್ಟ್‌ಗಳು (ಉದಾ., ಕೋಡ್, ಮಾರ್ಕ್‌ಡೌನ್, ಸ್ಕೀಮಾಗಳು, ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದಾದ ಯೋಜನೆಗಳು) ಮಾತ್ರವೇ ಅದು ನೋಡಬಲ್ಲದು.

“ಏಜೆಂಟ್ ಜ್ಞಾನದ ಮಿತಿಗಳು: Codex ಕಾಣದಿರುವುದು ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲ.” ಎಂಬ ಶೀರ್ಷಿಕೆಯ ಡಯಾಗ್ರಾಂ. Codex ನ ಜ್ಞಾನವನ್ನು ಮಿತಿಯೊಳಗಿನ ಬಬಲ್ ಆಗಿ ತೋರಿಸಲಾಗುತ್ತದೆ. ಅದರ ಕೆಳಗೆ ಕಾಣದ ಜ್ಞಾನದ ಉದಾಹರಣೆಗಳಿವೆ—Google Docs, Slack ಸಂದೇಶಗಳು ಮತ್ತು ಅನುಕ್ತ ಮಾನವ ಜ್ಞಾನ. ಬಾಣಗಳು ಈ ಮಾಹಿತಿಯನ್ನು Codex ಗೆ ಗೋಚರವಾಗಿಸಲು, ಅದನ್ನು ಕೋಡ್‌ಬೇಸ್‌ನಲ್ಲಿ ಮಾರ್ಕ್‌ಡೌನ್ ಆಗಿ ಎನ್‌ಕೋಡ್ ಮಾಡಬೇಕು ಎಂದು ಸೂಚಿಸುತ್ತವೆ.

ಕಾಲಕ್ರಮೇಣ ನಾವು ರೆಪೊಗೆ ಹೆಚ್ಚು ಹೆಚ್ಚು ಸಂದರ್ಭವನ್ನು ಸೇರಿಸಬೇಕೆಂದು ತಿಳಿಯುತ್ತಾ ಬಂದೆವು. ತಂಡವನ್ನು ವಾಸ್ತುಶಿಲ್ಪ ಮಾದರಿಯ ಮೇಲೆ ಒಂದೇ ಸಾಲಿಗೆ ತಂದ ಆ Slack ಚರ್ಚೆ? ಏಜೆಂಟ್‌ಗೆ ಅದು ಪತ್ತೆಯಾಗದಿದ್ದರೆ, ಮೂರು ತಿಂಗಳುಗಳ ನಂತರ ಸೇರುವ ಹೊಸ ನೇಮಕಾತಿಗೆ ಅದು ತಿಳಿಯದಿರುವಂತೆಯೇ ಅದು ಓದಲು ಅಸಾಧ್ಯವಾಗಿರುತ್ತದೆ.

Codex ಗೆ ಹೆಚ್ಚಿನ ಸಂದರ್ಭವನ್ನು ನೀಡುವುದು ಎಂದರೆ, ಏಜೆಂಟ್ ಅದನ್ನು ಆಧರಿಸಿ ತಾರ್ಕಿಕವಾಗಿ ಯೋಚಿಸಬಹುದಾದಂತೆ ಸರಿಯಾದ ಮಾಹಿತಿಯನ್ನು ಸಂಘಟಿಸಿ ಮತ್ತು ಬಹಿರಂಗಪಡಿಸುವುದು, ಅದನ್ನು ಅಡ್ಹಾಕ್ ಸೂಚನೆಗಳಿಂದ ತುಂಬಿಸುವ ಬದಲು. ನೀವು ಉತ್ಪನ್ನದ ತತ್ವಗಳು, ಎಂಜಿನಿಯರಿಂಗ್ ಮಾನದಂಡಗಳು ಮತ್ತು ತಂಡದ ಸಂಸ್ಕೃತಿ (ಎಮೋಜಿ ಆದ್ಯತೆಗಳನ್ನೂ ಸೇರಿಸಿ) ಕುರಿತು ಹೊಸ ತಂಡದ ಸದಸ್ಯನನ್ನು ಆನ್‌ಬೋರ್ಡ್ ಮಾಡುವ ರೀತಿಯಲ್ಲೇ, ಈ ಮಾಹಿತಿಯನ್ನು ಏಜೆಂಟ್‌ಗೆ ನೀಡುವುದರಿಂದ ಉತ್ತಮ ಹೊಂದಾಣಿಕೆಯ ಔಟ್‌ಪುಟ್ ದೊರೆಯುತ್ತದೆ.

ಈ ಚೌಕಟ್ಟಿನ ಮೂಲಕ ಅನೇಕ ವ್ಯತ್ಯಾಸಗಳನ್ನು ಸ್ಪಷ್ಟಪಡಿಸಲಾಯಿತು. ನಾವು ರೆಪೊ ಒಳಗೇ ಸಂಪೂರ್ಣವಾಗಿ ಆಂತರೀಕರಿಸಿ ತಾರ್ಕಿಕವಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬಹುದಾದ ಅವಲಂಬನೆಗಳು ಮತ್ತು ಅಮೂರ್ತೀಕರಣಗಳಿಗೆ ಆದ್ಯತೆ ನೀಡಿದ್ದೇವೆ. “ಬೋರು” ಎಂದು ಹೆಚ್ಚಾಗಿ ವಿವರಿಸಲ್ಪಡುವ ತಂತ್ರಜ್ಞಾನಗಳು ಸಂಯೋಜ್ಯತೆ, API ಸ್ಥಿರತೆ ಮತ್ತು ತರಬೇತಿ ಸೆಟ್‌ನಲ್ಲಿ ಪ್ರತಿನಿಧಿತ್ವದ ಕಾರಣದಿಂದ ಏಜೆಂಟ್‌ಗಳಿಗೆ ಮಾಡೆಲ್ ಮಾಡಲು ಸಾಮಾನ್ಯವಾಗಿ ಸುಲಭವಾಗಿರುತ್ತವೆ. ಕೆಲವು ಸಂದರ್ಭಗಳಲ್ಲಿ, ಸಾರ್ವಜನಿಕ ಲೈಬ್ರರಿಗಳ ಅಸ್ಪಷ್ಟ ಮೇಲ್ಭಾಗದ ನಡವಳಿಕೆಯನ್ನು ತಪ್ಪಿಸಲು ಪ್ರಯತ್ನಿಸುವುದಕ್ಕಿಂತ, ಏಜೆಂಟ್ ಮೂಲಕ ಕಾರ್ಯಕ್ಷಮತೆಯ ಕೆಲವು ಉಪಸಮೂಹಗಳನ್ನು ಮರು ತರುವುದು ಕಡಿಮೆ ವೆಚ್ಚವಾಗಿತ್ತು. ಉದಾಹರಣೆಗೆ, ಸಾಮಾನ್ಯ p-limit-ಶೈಲಿಯ ಪ್ಯಾಕೇಜ್ ಅನ್ನು ಬಳಸುವುದಕ್ಕಿಂತ, ನಾವು ನಮ್ಮದೇ ನಕ್ಷೆ-ಸಮನ್ವಯತೆಯೊಂದಿಗೆ ಸಹಾಯಕವನ್ನು ಅನುಷ್ಠಾನಗೊಳಿಸಿದ್ದೇವೆ: ಇದು ನಮ್ಮ OpenTelemetry ಸಾಧನಗಳೊಂದಿಗೆ ಗಟ್ಟಿಯಾಗಿ ಸಂಯೋಜಿತವಾಗಿದೆ, 100% ಪರೀಕ್ಷಾ ವ್ಯಾಪ್ತಿಯನ್ನು ಹೊಂದಿದೆ ಮತ್ತು ನಮ್ಮ ರನ್‌ಟೈಮ್ ನಿರೀಕ್ಷಿಸುವ ರೀತಿಯಲ್ಲೇ ನಿಖರವಾಗಿ ವರ್ತಿಸುತ್ತದೆ.

ಏಜೆಂಟ್ ಪರಿಶೀಲಿಸಬಹುದಾದ, ಮಾನ್ಯಗೊಳಿಸಬಹುದಾದ, ಮತ್ತು ನೇರವಾಗಿ ತಿದ್ದುಪಡಿ ಮಾಡಬಹುದಾದ ರೂಪಕ್ಕೆ ವ್ಯವಸ್ಥೆಯ ಹೆಚ್ಚಿನ ಭಾಗವನ್ನು ಎಳೆಯುವುದರಿಂದ ಲೀವರೇಜ್ ಹೆಚ್ಚುತ್ತದೆ—Codex ಮಾತ್ರವಲ್ಲ, ಇತರ ಏಜೆಂಟ್‌ಗಳಿಗೂ (ಉದಾ. Aardvark) ಕೋಡ್‌ಬೇಸ್‌ನ ಮೇಲೂ ಕೆಲಸ ಮಾಡುತ್ತಿರುವವು.

ವಾಸ್ತುಶಿಲ್ಪ ಮತ್ತು ರುಚಿಯನ್ನು ಜಾರಿಗೊಳಿಸುವುದು

ಡಾಕ್ಯುಮೆಂಟೇಶನ್ ಮಾತ್ರದಿಂದ ಸಂಪೂರ್ಣವಾಗಿ ಏಜೆಂಟ್-ರಚಿತ ಕೋಡ್‌ಬೇಸ್ ಸಮ್ಮತವಾಗುವುದಿಲ್ಲ. ಅಚಲ ನಿಯಮಗಳನ್ನು ಜಾರಿಗೊಳಿಸುವ ಮೂಲಕ, ಅನುಷ್ಠಾನಗಳನ್ನು ಸೂಕ್ಷ್ಮವಾಗಿ ನಿರ್ವಹಿಸುವುದನ್ನು ಬಿಟ್ಟು, ನಾವು ಅಡಿಪಾಯವನ್ನು ದುರ್ಬಲಗೊಳಿಸದೆ ಏಜೆಂಟ್‌ಗಳಿಗೆ ವೇಗವಾಗಿ ಸಾಗಿಸಲು ಅನುಮತಿಸುತ್ತೇವೆ. ಉದಾಹರಣೆಗೆ, ನಾವು Codex ಗೆ ಗಡಿಯಲ್ಲಿನ ಡೇಟಾ ಆಕಾರಗಳನ್ನು ಪಾರ್ಸ್ ಮಾಡಲು(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ) ಅಗತ್ಯವಿದೆ, ಆದರೆ ಅದು ಹೇಗೆ ನಡೆಯಬೇಕು ಎಂಬುದರ ಬಗ್ಗೆ ನಾವು ನಿರ್ದೇಶನ ನೀಡಿಲ್ಲ (ಮಾಡೆಲ್‌ಗೆ Zod ಇಷ್ಟವಾಗುವಂತೆ ಕಾಣುತ್ತದೆ, ಆದರೆ ನಾವು ಆ ನಿರ್ದಿಷ್ಟ ಲೈಬ್ರರಿಯನ್ನು ಸೂಚಿಸಿಲ್ಲ).

ಏಜೆಂಟ್‌ಗಳು ಕಟ್ಟುನಿಟ್ಟಾದ ಗಡಿಗಳು ಮತ್ತು ಊಹಿಸಬಹುದಾದ ರಚನೆ(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ) ಇರುವ ಪರಿಸರಗಳಲ್ಲಿ ಅತ್ಯಂತ ಪರಿಣಾಮಕಾರಿಯಾಗಿರುತ್ತಾರೆ, ಆದ್ದರಿಂದ ನಾವು ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಕಠಿಣ ವಾಸ್ತುಶಿಲ್ಪ ಮಾಡೆಲ್ ಸುತ್ತ ನಿರ್ಮಿಸಿದ್ದೇವೆ. ಪ್ರತಿ ವ್ಯವಹಾರ ಡೊಮೇನ್ ಅನ್ನು ನಿಗದಿತ ಲೇಯರ್‌ಗಳ ಸಮೂಹವಾಗಿ ವಿಭಜಿಸಲಾಗುತ್ತದೆ, ಕಟ್ಟುನಿಟ್ಟಾಗಿ ಪರಿಶೀಲಿಸಲಾದ ಅವಲಂಬನೆ ದಿಕ್ಕುಗಳು ಮತ್ತು ಅನುಮತಿಸಲ್ಪಟ್ಟ ಎಡ್ಜ್‌ಗಳ ಸೀಮಿತ ಸಮೂಹದೊಂದಿಗೆ. ಈ ನಿರ್ಬಂಧಗಳನ್ನು ಕಸ್ಟಮ್ ಲಿಂಟರ್‌ಗಳು (ನಿಸ್ಸಂದೇಹವಾಗಿ Codex-ಜನಿತ!) ಮತ್ತು ರಚನಾತ್ಮಕ ಪರೀಕ್ಷೆಗಳ ಮೂಲಕ ಯಾಂತ್ರಿಕವಾಗಿ ಜಾರಿಗೊಳಿಸಲಾಗುತ್ತದೆ.

ಕೆಳಗಿನ ರೇಖಾಚಿತ್ರವು ನಿಯಮವನ್ನು ತೋರಿಸುತ್ತದೆ: ಪ್ರತಿಯೊಂದು ವ್ಯವಹಾರ ಡೊಮೇನ್‌ನೊಳಗೆ (ಉದಾಹರಣೆಗೆ, ಅಪ್ಲಿಕೇಶನ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳು), ಕೋಡ್ ನಿಶ್ಚಿತ ಲೇಯರ್‌ಗಳ ಸಮೂಹದ ಮೂಲಕ ಮಾತ್ರ “ಮುಂದಕ್ಕೆ” ಅವಲಂಬಿಸಬಹುದು (ವಿಧಗಳು → ಕಾನ್ಫಿಗ್ → ರೆಪೋ → ಸೇವೆ → ರನ್ಟೈಮ್ → UI). ಕ್ರಾಸ್-ಕಟ್ಟಿಂಗ್ ಚಿಂತೆಗಳು (ದೃಢೀಕರಣ, ಕನೆಕ್ಟರ್ಸ್, ಟೆಲಿಮೆಟ್ರಿ, ಫೀಚರ್ ಫ್ಲ್ಯಾಗ್‌ಗಳು) ಒಂದೇ ಸ್ಪಷ್ಟ ಇಂಟರ್ಫೇಸ್ ಮೂಲಕ ಪ್ರವೇಶಿಸುತ್ತವೆ: ಪ್ರೊವೈಡರ್‌ಗಳು. ಮತ್ತೆಲ್ಲವೂ ನಿರ್ಬಂಧಿತವಾಗಿದ್ದು, ಯಾಂತ್ರಿಕವಾಗಿ ಜಾರಿಗೊಳಿಸಲಾಗುತ್ತದೆ.

“ಲೇಯರ್ಡ್ ಡೊಮೇನ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ವಿತ್ ಎಕ್ಸ್‌ಪ್ಲಿಸಿಟ್ ಕ್ರಾಸ್-ಕಟ್ಟಿಂಗ್ ಬೌಂಡರೀಸ್” ಎಂಬ ಶೀರ್ಷಿಕೆಯ ಡಯಾಗ್ರಾಂ. ವ್ಯವಹಾರ ಲಾಜಿಕ್ ಡೊಮೇನ್‌ನೊಳಗೆ ಮಾಡ್ಯೂಲ್‌ಗಳು ಇವೆ: ವಿಧಗಳು → ಕಾನ್ಫಿಗ್ → ರೆಪೋ ಮತ್ತು ಪೂರೈಕೆದಾರರು → ಸೇವೆ → ರನ್ಟೈಮ್ → UI, ಕೆಳಭಾಗದಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್ ವೈರಿಂಗ್ + UI. ಒಂದು Utils ಮಾಡ್ಯೂಲ್ ಗಡಿಯ ಹೊರಗೆ ಇರುತ್ತದೆ ಮತ್ತು ಪೂರೈಕೆದಾರರಿಗೆ ಮಾಹಿತಿ ಒದಗಿಸುತ್ತದೆ.

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

ಪ್ರಯೋಗದಲ್ಲಿ, ನಾವು ಈ ನಿಯಮಗಳನ್ನು ಕಸ್ಟಮ್ ಲಿಂಟರ್‌ಗಳು ಮತ್ತು ರಚನಾತ್ಮಕ ಪರೀಕ್ಷೆಗಳ ಮೂಲಕ, ಜೊತೆಗೆ “ರುಚಿ ಅಚಲಾಂಶಗಳು” ಎಂಬ ಸಣ್ಣ ಸಮೂಹದ ಮೂಲಕ ಅನುಷ್ಠಾನಗೊಳಿಸುತ್ತೇವೆ. ಉದಾಹರಣೆಗೆ, ನಾವು ಕಸ್ಟಮ್ ಲಿಂಟ್‌ಗಳ ಮೂಲಕ ರಚಿತ ಲಾಗಿಂಗ್, ಸ್ಕೀಮಾ ಮತ್ತು ಪ್ರಕಾರಗಳ ನಾಮಕರಣ ಸಂಪ್ರದಾಯಗಳು, ಫೈಲ್ ಗಾತ್ರದ ಮಿತಿಗಳು ಮತ್ತು ಪ್ಲಾಟ್‌ಫಾರ್ಮ್-ನಿರ್ದಿಷ್ಟ ವಿಶ್ವಾಸಾರ್ಹತೆ ಅಗತ್ಯಗಳನ್ನು ಸ್ಥಿರವಾಗಿ ಜಾರಿಗೊಳಿಸುತ್ತೇವೆ. ಲಿಂಟ್‌ಗಳು ಕಸ್ಟಮ್ ಆಗಿರುವುದರಿಂದ, ಏಜೆಂಟ್ ಸಂದರ್ಭಕ್ಕೆ ಪರಿಹಾರ ಸೂಚನೆಗಳನ್ನು ಸೇರಿಸಲು ನಾವು ದೋಷ ಸಂದೇಶಗಳನ್ನು ಬರೆಯುತ್ತೇವೆ.

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

ಅದೇ ಸಮಯದಲ್ಲಿ, ನಿರ್ಬಂಧಗಳು ಎಲ್ಲಿ ಮುಖ್ಯವಾಗುತ್ತವೆ ಮತ್ತು ಎಲ್ಲಿ ಮುಖ್ಯವಾಗುವುದಿಲ್ಲ ಎಂಬುದರ ಬಗ್ಗೆ ನಾವು ಸ್ಪಷ್ಟವಾಗಿ ಹೇಳುತ್ತೇವೆ. ಇದು ದೊಡ್ಡ ಎಂಜಿನಿಯರಿಂಗ್ ವೇದಿಕೆ ಸಂಸ್ಥೆಯನ್ನು ಮುನ್ನಡೆಸುವಂತಿದೆ: ಕೇಂದ್ರದಲ್ಲಿ ಗಡಿಗಳನ್ನು ಜಾರಿಗೊಳಿಸಿ, ಸ್ಥಳೀಯವಾಗಿ ಸ್ವಾಯತ್ತತೆಯನ್ನು ಅನುಮತಿಸಿ. ನೀವು ಗಡಿಗಳು, ಸರಿಯಾದತೆ ಮತ್ತು ಪುನರುತ್ಪಾದಕತೆಯ ಬಗ್ಗೆ ಆಳವಾಗಿ ಕಾಳಜಿ ವಹಿಸುತ್ತೀರಿ. ಆ ಮಿತಿಗಳೊಳಗೆ, ಪರಿಹಾರಗಳನ್ನು ಹೇಗೆ ವ್ಯಕ್ತಪಡಿಸಲಾಗುತ್ತದೆ ಎಂಬುದರಲ್ಲಿ ನೀವು ತಂಡಗಳಿಗೆ—ಅಥವಾ ಏಜೆಂಟ್‌ಗಳಿಗೆ—ಗಣನೀಯ ಸ್ವಾತಂತ್ರ್ಯವನ್ನು ಅನುಮತಿಸುತ್ತೀರಿ.

ಫಲಿತಾಂಶದ ಕೋಡ್ ಯಾವಾಗಲೂ ಮಾನವ ಶೈಲಿಯ ಮೆಚ್ಚುಗೆಗೆ ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ ಮತ್ತು ಅದು ಸರಿ. ಔಟ್‌ಪುಟ್ ಸರಿಯಾಗಿದ್ದು, ನಿರ್ವಹಿಸಬಹುದಾಗಿದ್ದು ಮತ್ತು ಭವಿಷ್ಯದ ಏಜೆಂಟ್‌ಗಳ ಕಾರ್ಯಾಚರಣೆಗಳಿಗೆ ಓದಲು ಸುಲಭವಾಗಿರುವವರೆಗೆ, ಅದು ಮಾನದಂಡವನ್ನು ಪೂರೈಸುತ್ತದೆ.

ಮಾನವ ರುಚಿಯನ್ನು ನಿರಂತರವಾಗಿ ವ್ಯವಸ್ಥೆಗೆ ಹಿಂತಿರುಗಿಸಲಾಗುತ್ತದೆ. ಪರಿಶೀಲನೆ ಕಾಮೆಂಟ್‌ಗಳು, pull request‌ಗಳು ಮತ್ತು ಬಳಕೆದಾರರಿಗೆ ಕಾಣಿಸುವ ದೋಷಗಳನ್ನು ಡಾಕ್ಯುಮೆಂಟೇಶನ್ ನವೀಕರಣಗಳಾಗಿ ಸೆರೆಹಿಡಿಯಲಾಗುತ್ತದೆ ಅಥವಾ ನೇರವಾಗಿ ಸಾಧನಗಳಲ್ಲಿ ಎನ್‌ಕೋಡ್ ಮಾಡಲಾಗುತ್ತದೆ. ಡಾಕ್ಯುಮೆಂಟೇಶನ್ ಅಪೂರ್ಣವಾಗಿದಾಗ, ನಾವು ಆ ನಿಯಮವನ್ನು ಕೋಡ್‌ಗೆ ಉತ್ತೇಜಿಸುತ್ತೇವೆ

ಥ್ರೂಪುಟ್ ವಿಲೀನ ತತ್ತ್ವವನ್ನು ಬದಲಿಸುತ್ತದೆ

Codex ನ ಥ್ರೂಪುಟ್ ಹೆಚ್ಚಿದಂತೆ, ಅನೇಕ ಸಾಂಪ್ರದಾಯಿಕ ಎಂಜಿನಿಯರಿಂಗ್ ಮಾನದಂಡಗಳು ಪ್ರತಿಕೂಲಕರವಾಗಿದವು.

ರಿಪೊಸಿಟರಿ ಕನಿಷ್ಠ ತಡೆಗಟ್ಟುವ ಮರ್ಜ್ ಗೇಟ್‌ಗಳೊಂದಿಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. Pull requests ಅಲ್ಪಕಾಲಿಕವಾಗಿರುತ್ತವೆ. ಟೆಸ್ಟ್ ಫ್ಲೇಕ್‌ಗಳನ್ನು ಪ್ರಗತಿಯನ್ನು ಅನಿರ್ದಿಷ್ಟವಾಗಿ ತಡೆಗಟ್ಟುವ ಬದಲು ಫಾಲೋ-ಅಪ್ ರನ್‌ಗಳ ಮೂಲಕ ಸಾಮಾನ್ಯವಾಗಿ ಪರಿಹರಿಸಲಾಗುತ್ತದೆ. ಏಜೆಂಟ್ ಥ್ರೂಪುಟ್ ಮಾನವ ಗಮನವನ್ನು ಬಹಳವಾಗಿ ಮೀರಿಸುವ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ, ತಿದ್ದುಪಡಿಗಳು ಅಗ್ಗವಾಗಿವೆ, ಆದರೆ ಕಾಯುವುದು ದುಬಾರಿಯಾಗಿದೆ.

ಕಡಿಮೆ-ಥ್ರೂಪುಟ್ ಪರಿಸರದಲ್ಲಿ ಇದು ಜವಾಬ್ದಾರಿಯಿಲ್ಲದ ಕಾರ್ಯವಾಗುತ್ತದೆ. ಇಲ್ಲಿ, ಇದು ಬಹುಸಾರಿ ಸರಿಯಾದ ತ್ಯಾಗವಾಗಿದೆ.

“ಏಜೆಂಟ್-ರಚಿತ” ಎಂದರೆ ನಿಜವಾಗಿ ಏನು ಅರ್ಥ

ನಾವು ಕೋಡ್‌ಬೇಸ್ ಅನ್ನು Codex ಏಜೆಂಟ್‌ಗಳು ರಚಿಸುತ್ತವೆ ಎಂದು ಹೇಳಿದಾಗ, ಕೋಡ್‌ಬೇಸ್‌ನಲ್ಲಿರುವ ಎಲ್ಲವನ್ನೂ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತೇವೆ.

ಏಜೆಂಟ್‌ಗಳು ಇವನ್ನು ಉತ್ಪಾದಿಸುತ್ತವೆ:

  • ಉತ್ಪನ್ನ ಕೋಡ್ ಮತ್ತು ಪರೀಕ್ಷೆಗಳು
  • CI ಸಂರಚನೆ ಮತ್ತು ಬಿಡುಗಡೆ ಸಾಧನಗಳು
  • ಆಂತರಿಕ ಡೆವಲಪರ್ ಉಪಕರಣಗಳು
  • ದಾಖಲೆ ಮತ್ತು ವಿನ್ಯಾಸ ಇತಿಹಾಸ
  • ಮೌಲ್ಯಮಾಪನ ಹಾರ್ನೆಸ್‌ಗಳು
  • ವಿಮರ್ಶಾ ಕಾಮೆಂಟ್‌ಗಳು ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆಗಳು
  • ರಿಪೊಸಿಟರಿಯನ್ನು ಸ್ವತಃ ನಿರ್ವಹಿಸುವ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳು
  • ಉತ್ಪಾದನಾ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್ ವ್ಯಾಖ್ಯಾನ ಫೈಲ್‌ಗಳು

ಮಾನವರು ಯಾವಾಗಲೂ ಲೂಪ್‌ನಲ್ಲಿ ಇರುತ್ತಾರೆ, ಆದರೆ ನಾವು ಹಿಂದೆ ಮಾಡುತ್ತಿದ್ದುದಕ್ಕಿಂತ ವಿಭಿನ್ನ ಅಮೂರ್ತೀಕರಣದ ಹಂತದಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತಾರೆ. ನಾವು ಕೆಲಸಕ್ಕೆ ಆದ್ಯತೆ ನೀಡುತ್ತೇವೆ, ಬಳಕೆದಾರರ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಸ್ವೀಕಾರ ಮಾನದಂಡಗಳಾಗಿ ಪರಿವರ್ತಿಸುತ್ತೇವೆ ಮತ್ತು ಫಲಿತಾಂಶಗಳನ್ನು ಪರಿಶೀಲಿಸುತ್ತೇವೆ. ಏಜೆಂಟ್‌ಗೆ ಕಷ್ಟವಾಗುವಾಗ, ನಾವು ಅದನ್ನು ಒಂದು ಸಂಕೇತವಾಗಿ ಪರಿಗಣಿಸುತ್ತೇವೆ: ಏನು ಕೊರತೆಯಿದೆ—ಪರಿಕರಗಳು, ಗಾರ್ಡ್‌ರೈಲ್‌ಗಳು, ಡಾಕ್ಯುಮೆಂಟೇಶನ್—ಎಂಬುದನ್ನು ಗುರುತಿಸಿ, ಅದನ್ನು ರಿಪೊಸಿಟರಿ‌ಗೆ ಮರಳಿ ಸೇರಿಸುತ್ತೇವೆ ಮತ್ತು ಯಾವಾಗಲೂ Codex ತಾನೇ ಸರಿಪಡಿಸುವುದನ್ನು ಬರೆಯಲು Codex ಅನ್ನು ಬಳಸುತ್ತೇವೆ.

ಏಜೆಂಟ್‌ಗಳು ನಮ್ಮ ಮಾನಕ ಅಭಿವೃದ್ಧಿ ಸಾಧನಗಳನ್ನು ನೇರವಾಗಿ ಬಳಸುತ್ತಾರೆ. ಅವರು ವಿಮರ್ಶಾ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಪಡೆಯುತ್ತಾರೆ, ಇನ್‌ಲೈನ್‌ನಲ್ಲಿ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತಾರೆ, ನವೀಕರಣಗಳನ್ನು ಪುಷ್ ಮಾಡುತ್ತಾರೆ ಮತ್ತು ತಮ್ಮದೇ pull request ಗಳನ್ನು ಸ್ಕ್ವಾಶ್ ಮಾಡಿ ಮರ್ಜ್ ಮಾಡುತ್ತಾರೆ.

ಸ್ವಾಯತ್ತತೆಯ ಹೆಚ್ಚುತ್ತಿರುವ ಹಂತಗಳು

ಅಭಿವೃದ್ಧಿ ಚಕ್ರದ ಹೆಚ್ಚಿನ ಭಾಗವನ್ನು ನೇರವಾಗಿ ವ್ಯವಸ್ಥೆಗೆ ಎನ್‌ಕೋಡ್ ಮಾಡಲಾಗುತ್ತಿದ್ದಂತೆ—ಪರೀಕ್ಷಣೆ, ಮಾನ್ಯತೆ, ವಿಮರ್ಶೆ, ಪ್ರತಿಕ್ರಿಯೆ ನಿರ್ವಹಣೆ, ಮತ್ತು ಪುನಃಪ್ರಾಪ್ತಿ—ರಿಪೊಸಿಟರಿ ಇತ್ತೀಚೆಗೆ Codex ಅನ್ನು ಎಂಡ್-ಟು-ಎಂಡ್ ಹೊಸ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಮುನ್ನಡೆಸಲು ಸಾಧ್ಯವಾಗುವಂತಹ ಅರ್ಥಪೂರ್ಣ ಮಿತಿಯನ್ನು ದಾಟಿದೆ.

ಒಂದೇ ಪ್ರಾಂಪ್ಟ್ ನೀಡಿದಾಗ, ಏಜೆಂಟ್ ಈಗ ಇವನ್ನೆಲ್ಲಾ ಮಾಡಬಹುದು:

  • ಕೋಡ್‌ಬೇಸ್‌ನ ಪ್ರಸ್ತುತ ಸ್ಥಿತಿಯನ್ನು ಪರಿಶೀಲಿಸುವುದು
  • ವರದಿ ಮಾಡಿದ ದೋಷವನ್ನು ಪುನರುತ್ಪಾದಿಸುವುದು
  • ವಿಫಲತೆಯನ್ನು ತೋರಿಸುವ ವೀಡಿಯೊವನ್ನು ದಾಖಲಿಸುವುದು
  • ಸರಿಪಡಿಸುವಿಕೆಯನ್ನು ಜಾರಿಗೆ ತರುವುದು
  • ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಚಾಲನೆ ಮಾಡುವ ಮೂಲಕ ಸರಿಪಡಿಸುವಿಕೆಯನ್ನು ಪರಿಶೀಲಿಸುವುದು
  • ರೆಸಲ್ಯೂಶನ್ ಅನ್ನು ತೋರಿಸುವ ಎರಡನೇ ವೀಡಿಯೊವನ್ನು ದಾಖಲಿಸುವುದು
  • Pull request ಅನ್ನು ತೆರೆಯುವುದು
  • ಏಜೆಂಟ್ ಮತ್ತು ಮಾನವ ಪ್ರತಿಕ್ರಿಯೆಗೆ ಪ್ರತಿಕ್ರಿಯಿಸುವುದು
  • ಬಿಲ್ಡ್ ವೈಫಲ್ಯಗಳನ್ನು ಪತ್ತೆಹಚ್ಚಿ ಮತ್ತು ಸರಿಪಡಿಸುವುದು
  • ತೀರ್ಮಾನ ಅಗತ್ಯವಿರುವಾಗ ಮಾತ್ರ ತೀರ್ಮಾನಕ್ಕೆ ಮಾನವಿಗೆ ವರ್ಗಾಯಿಸುವುದು
  • ಬದಲಾವಣೆಯನ್ನು ವಿಲೀನಗೊಳಿಸುವುದು

ಈ ವರ್ತನೆ ಈ ರಿಪೊಸಿಟರಿಯ ನಿರ್ದಿಷ್ಟ ರಚನೆ ಮತ್ತು ಉಪಕರಣಗಳ ಮೇಲೆ ಬಹಳ ಮಟ್ಟಿಗೆ ಅವಲಂಬಿತವಾಗಿದೆ ಮತ್ತು ಸಮಾನ ಹೂಡಿಕೆ ಇಲ್ಲದೆ ಇದನ್ನು ಸಾಮಾನ್ಯೀಕರಿಸಬಾರದು—ಕನಿಷ್ಠ ಮಟ್ಟಿಗೆ, ಇನ್ನೂ ಅಲ್ಲ.

ಎಂಟ್ರೋಪಿ ಮತ್ತು ಕಸದ ಸಂಗ್ರಹಣೆ

ಏಜೆಂಟ್‌ಗಳಿಗೆ ಸಂಪೂರ್ಣ ಸ್ವಾಯತ್ತತೆ ಹೊಸ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಚಯಿಸುತ್ತದೆ. Codex ರಿಪೊಸಿಟರಿಯಲ್ಲಿ ಈಗಾಗಲೇ ಇರುವ ಮಾದರಿಗಳನ್ನು—ಅಸಮ ಅಥವಾ ಅತ್ಯುತ್ತಮವಲ್ಲದವುಗಳನ್ನೂ ಸಹ—ಪುನರಾವರ್ತಿಸುತ್ತದೆ. ಕಾಲಕಾಲಾಂತರದಲ್ಲಿ, ಇದು ಅನಿವಾರ್ಯವಾಗಿ ಚಲನೆಗೆ ಕಾರಣವಾಗುತ್ತದೆ.

ಆರಂಭದಲ್ಲಿ, ಮಾನವರು ಇದನ್ನು ಕೈಯಿಂದಲೇ ನಿರ್ವಹಿಸುತ್ತಿದ್ದರು. ನಮ್ಮ ತಂಡವು ಪ್ರತಿ ಶುಕ್ರವಾರ (ವಾರದ 20%) “AI ಸ್ಲಾಪ್” ಅನ್ನು ಸ್ವಚ್ಛಗೊಳಿಸಲು ಸಮಯ ಕಳೆಯುತ್ತಿತ್ತು. ಅಚ್ಚರಿಯೇನಿಲ್ಲ, ಅದು ವಿಸ್ತರಿಸಲಿಲ್ಲ.

ಬದಲಾಗಿ, ನಾವು “ಸುವರ್ಣ ತತ್ವಗಳು” ಎಂದು ಕರೆಯುವುದನ್ನು ನೇರವಾಗಿ ರಿಪೊಸಿಟರಿಯೊಳಗೆ ಎನ್‌ಕೋಡ್ ಮಾಡಲಾರಂಭಿಸಿ, ಮರುಕಳಿಸುವ ಕ್ಲೀನ್‌ಅಪ್ ಪ್ರಕ್ರಿಯೆಯನ್ನು ನಿರ್ಮಿಸಿದ್ದೇವೆ. ಈ ತತ್ವಗಳು ಅಭಿಪ್ರಾಯಾಧಾರಿತ, ಯಾಂತ್ರಿಕ ನಿಯಮಗಳಾಗಿದ್ದು, ಭವಿಷ್ಯದ ಏಜೆಂಟ್ ಕಾರ್ಯಾಚರಣೆಗಳಿಗಾಗಿ ಕೋಡ್‌ಬೇಸ್ ಅನ್ನು ಓದಲು ಸುಲಭವಾಗಿಯೂ ಸ್ಥಿರವಾಗಿಯೂ ಇಡುತ್ತವೆ. ಉದಾಹರಣೆಗೆ: (1) ಇನ್ವೇರಿಯಂಟ್ಸ್‌ಗಳನ್ನು ಕೇಂದ್ರಿಕೃತವಾಗಿ ಇರಿಸಲು ನಾವು ಕೈಯಾರೆ ಮಾಡಿದ ಸಹಾಯಕಗಳಿಗಿಂತ ಹಂಚಿಕೊಂಡ ಉಪಯುಕ್ತ ಪ್ಯಾಕೇಜ್‌ಗಳಿಗೆ ಆದ್ಯತೆ ನೀಡುತ್ತೇವೆ ಮತ್ತು (2) ನಾವು ಡೇಟಾವನ್ನು “YOLO-ಶೈಲಿ”ಯಲ್ಲಿ ಪರಿಶೀಲಿಸುವುದಿಲ್ಲ—ನಾವು ಗಡಿಗಳನ್ನು ಮಾನ್ಯಗೊಳಿಸುತ್ತೇವೆ ಅಥವಾ ಟೈಪ್ ಮಾಡಿದ SDKs ಮೇಲೆ ಅವಲಂಬಿಸುತ್ತೇವೆ, ಹೀಗಾಗಿ ಏಜೆಂಟ್ ತಪ್ಪಾಗಿ ಆಕಸ್ಮಿಕವಾಗಿ ಊಹಿಸಿದ ಆಕಾರಗಳ ಮೇಲೆ ನಿರ್ಮಿಸಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ. ನಿಯಮಿತ ಅವಧಿಯಲ್ಲಿ, ನಾವು ವಿಚಲನಗಳನ್ನು ಸ್ಕ್ಯಾನ್ ಮಾಡುವ, ಗುಣಮಟ್ಟದ ಶ್ರೇಣಿಗಳನ್ನು ನವೀಕರಿಸುವ ಮತ್ತು ಗುರಿಯಲ್ಲಿರುವ ಮರುಫ್ಯಾಕ್ಟರಿಂಗ್ pull request ಗಳನ್ನು ತೆರೆಯುವ ಹಿನ್ನೆಲೆ Codex ಕಾರ್ಯಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಇವುಗಳಲ್ಲಿ ಹೆಚ್ಚಿನವುಗಳನ್ನು ಒಂದು ನಿಮಿಷಕ್ಕಿಂತ ಕಡಿಮೆ ಸಮಯದಲ್ಲಿ ಪರಿಶೀಲಿಸಿ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಮರ್ಜ್ ಮಾಡಬಹುದು.

ಇದು ಗಾರ್ಬೇಜ್ ಕಲೆಕ್ಷನ್‌ನಂತೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ತಾಂತ್ರಿಕ ಸಾಲವು ಹೆಚ್ಚಿನ ಬಡ್ಡಿದರದ ಸಾಲದಂತಿದೆ: ಅದನ್ನು ಸಂಕೀರ್ಣವಾಗಿ ಹೆಚ್ಚಲು ಬಿಡುವುದಕ್ಕಿಂತ, ಸಣ್ಣ ಹಂತಗಳಲ್ಲಿ ನಿರಂತರವಾಗಿ ತೀರಿಸುವುದು ಬಹಳಷ್ಟು ಉತ್ತಮ. ಮಾನವ ಅಭಿರುಚಿಯನ್ನು ಒಮ್ಮೆ ಸೆರೆಹಿಡಿದು, ನಂತರ ಪ್ರತಿಯೊಂದು ಕೋಡ್ ಸಾಲಿನ ಮೇಲೂ ನಿರಂತರವಾಗಿ ಅನ್ವಯಿಸಲಾಗುತ್ತದೆ. ಇದು ನಮಗೆ ಕೆಟ್ಟ ಮಾದರಿಗಳನ್ನು ದಿನನಿತ್ಯ ಪತ್ತೆಹಚ್ಚಿ ಪರಿಹರಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ, ಅವುಗಳನ್ನು ಕೋಡ್‌ಬೇಸ್‌ನಲ್ಲಿ ದಿನಗಳು ಅಥವಾ ವಾರಗಳ ಕಾಲ ಹರಡಲು ಬಿಡುವ ಬದಲು.

ನಾವು ಇನ್ನೂ ಏನು ಕಲಿಯುತ್ತಿದ್ದೇವೆ

ಈ ಕಾರ್ಯತಂತ್ರವು ಇದುವರೆಗೆ OpenAI ನಲ್ಲಿ ಆಂತರಿಕ ಪ್ರಾರಂಭ ಮತ್ತು ಅಳವಡಿಕೆಗೆ ಯಶಸ್ವಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಿದೆ. ನಿಜವಾದ ಬಳಕೆದಾರರಿಗಾಗಿ ನಿಜವಾದ ಉತ್ಪನ್ನವನ್ನು ನಿರ್ಮಿಸುವುದು ನಮ್ಮ ಹೂಡಿಕೆಗಳನ್ನು ವಾಸ್ತವಿಕತೆಯಲ್ಲಿ ನೆಲೆಗೊಳಿಸಲು ಮತ್ತು ದೀರ್ಘಾವಧಿಯ ನಿರ್ವಹಣೀಯತೆಯತ್ತ ನಮ್ಮನ್ನು ಮಾರ್ಗದರ್ಶನ ಮಾಡಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ.

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

ಸ್ಪಷ್ಟವಾಗಿರುವುದು ಏನೆಂದರೆ: ಸಾಫ್ಟ್‌ವೇರ್ ನಿರ್ಮಾಣಕ್ಕೆ ಇನ್ನೂ ಶಿಸ್ತು ಅಗತ್ಯವಿದೆ, ಆದರೆ ಆ ಶಿಸ್ತು ಕೋಡ್‌ಗಿಂತ ಹೆಚ್ಚು ಸ್ಕಾಫೋಲ್ಡಿಂಗ್‌ನಲ್ಲಿ ಕಾಣಿಸುತ್ತದೆ. ಕೋಡ್‌ಬೇಸ್ ಅನ್ನು ಸಮ್ಮತವಾಗಿ ಇರಿಸಲು ಉಪಕರಣಗಳು, ಅಬ್ಸ್ಟ್ರಾಕ್ಷನ್‌ಗಳು ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆ ಲೂಪ್‌ಗಳು ದಿನೇದಿನೇ ಹೆಚ್ಚು ಮಹತ್ವ ಪಡೆಯುತ್ತಿವೆ.

ನಮ್ಮ ಅತ್ಯಂತ ಕಠಿಣ ಸವಾಲುಗಳು ಈಗ ಪರಿಸರಗಳು, ಪ್ರತಿಕ್ರಿಯಾ ಲೂಪ್‌ಗಳು ಮತ್ತು ನಿಯಂತ್ರಣ ವ್ಯವಸ್ಥೆಗಳನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸುವುದರ ಮೇಲೆ ಕೇಂದ್ರೀಕೃತವಾಗಿವೆ — ಏಜೆಂಟ್‌ಗಳು ನಮ್ಮ ಗುರಿಯನ್ನು ಸಾಧಿಸಲು ಸಹಾಯ ಮಾಡುವಂತೆ: ದೊಡ್ಡ ಪ್ರಮಾಣದಲ್ಲಿ ಸಂಕೀರ್ಣ, ವಿಶ್ವಾಸಾರ್ಹ ಸಾಫ್ಟ್‌ವೇರ್ ಅನ್ನು ನಿರ್ಮಿಸಿ ಮತ್ತು ನಿರ್ವಹಿಸಿ.

Codex ನಂತಹ ಏಜೆಂಟ್‌ಗಳು ಸಾಫ್ಟ್‌ವೇರ್ ಜೀವನಚಕ್ರದ ದೊಡ್ಡ ಭಾಗಗಳನ್ನು ಹೊತ್ತುಕೊಳ್ಳುತ್ತಿದ್ದಂತೆ, ಈ ಪ್ರಶ್ನೆಗಳು ಇನ್ನಷ್ಟು ಮಹತ್ವ ಪಡೆಯುತ್ತವೆ. ನಾವು ಕೆಲವು ಆರಂಭಿಕ ಪಾಠಗಳನ್ನು ಹಂಚಿಕೊಳ್ಳುವುದರಿಂದ ನೀವು ನಿಮ್ಮ ಪ್ರಯತ್ನವನ್ನು ಎಲ್ಲಿ ಹೂಡಿಕೆ ಮಾಡಬೇಕೆಂದು ಯೋಚಿಸಲು ಸಹಾಯವಾಗುತ್ತದೆ ಎಂದು ನಾವು ಆಶಿಸುತ್ತೇವೆ, ಇದರಿಂದಾಗಿ ನೀವು ಸರಳವಾಗಿ ವಸ್ತುಗಳನ್ನು ನಿರ್ಮಿಸಬಹುದು.

ಲೇಖಕ

Ryan Lopopolo

ಕೃತಜ್ಞತೆಗಳು

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