2,900 ಇಂಜಿನಿಯರ್‌ಗಳ ಮೇಲೆ ನಡೆಸಲಾದ 2026ರ ಸಮೀಕ್ಷೆಯ ಪ್ರಕಾರ, ಡೆವಲಪರ್‌ಗಳು ಈಗ ವಾರಕ್ಕೆ 11.4 ಗಂಟೆಗಳನ್ನು AI-ಸೃಷ್ಟಿಸಿದ ಕೋಡ್ ಅನ್ನು ಪರಿಶೀಲಿಸಲು (reviewing) ಬಳಸುತ್ತಿದ್ದಾರೆ, ಇದು ಅವರು ತಾವೇ ಬರೆಯುವ 9.8 ಗಂಟೆಗಳಿಗಿಂತಲೂ ಹೆಚ್ಚಾಗಿದೆ. ಅಡಚಣೆಯು "AI ಕೋಡ್ ಅನ್ನು ಉತ್ಪಾದಿಸಬಲ್ಲದೇ?" ಎಂಬ ಪ್ರಶ್ನೆಯಿಂದ "ಅದು ಉತ್ಪಾದಿಸುವ ಕೋಡ್ ಅನ್ನು ನಾವು ನಂಬಬಹುದೇ?" ಎಂಬ ಪ್ರಶ್ನೆಗೆ ಬದಲಾಗಿದೆ ಮತ್ತು ತಂಡಗಳು ಸ್ಪಷ್ಟವಾದ ನಿರ್ಧಾರದ ಹಾದಿ (decision trails) ಮತ್ತು ಹೆಚ್ಚಿನ ವಿಶ್ವಾಸವನ್ನು ನೀಡುವ multi-agent AI workflows ಕಡೆಗೆ ಸಾಗುತ್ತಿವೆ.

ಚರ್ಚೆಯನ್ನು ಹುಟ್ಟುಹಾಕಿದ ಸಮೀಕ್ಷೆ

ಈ ವರ್ಷದ ಆರಂಭದಲ್ಲಿ ನಡೆಸಲಾದ ಪ್ರಶ್ನಾವಳಿಯು, ಹೊಸ ಕೋಡ್ ಬರೆಯುವುದು ಮತ್ತು AI-ಸೃಷ್ಟಿಸಿದ ಕೋಡ್ ಅನ್ನು ಪರಿಶೀಲಿಸುವುದರ ನಡುವೆ ಡೆವಲಪರ್‌ಗಳು ತಮ್ಮ ಸಮಯವನ್ನು ಹೇಗೆ ಹಂಚಿಕೊಳ್ಳುತ್ತಾರೆ ಎಂದು ಕೇಳಿತು. ಆರಂಭಿಕ ರಚನೆಗಿಂತ ಈಗ ಪರಿಶೀಲನೆಗೆ ಹೆಚ್ಚು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಎಂದು ಪ್ರತಿಕ್ರಿಯಿಸಿದವರು ತಿಳಿಸಿದ್ದಾರೆ. ಅವರು ಒಂದೇ ಪ್ರಾಜೆಕ್ಟ್‌ನಲ್ಲಿ ಎರಡು ಮೂರು ಅಥವಾ ನಾಲ್ಕು ವಿಭಿನ್ನ AI ಅಸಿಸ್ಟೆಂಟ್‌ಗಳನ್ನು ಬಳಸುತ್ತಿದ್ದಾರೆ ಮತ್ತು 70% ರಷ್ಟು ಜನರು ಈ ಅಭ್ಯಾಸವು ಈಗ ದಿನಚರಿಯಾಗಿದೆ ಎಂದು ಹೇಳಿದ್ದಾರೆ.

ಈ ಅಂಕಿಅಂಶಗಳು ಹೆಚ್ಚುತ್ತಿರುವ ಅಸಮಾಧಾನವನ್ನು ಪ್ರತಿಧ್ವನಿಸುತ್ತವೆ: ಒಂದು ಏಕೈಕ, ಸರ್ವವ್ಯಾಪಿ ಮಾಡೆಲ್ (all-purpose model) ಸೆಕೆಂಡುಗಳಲ್ಲಿ ಒಂದು ಫಂಕ್ಷನ್ ಅನ್ನು ಬರೆಯಬಲ್ಲದು, ಆದರೆ ಅದು ಯಾವುದೇ ದಾಖಲೆ ಇಲ್ಲದೆ ಡೇಟಾ ಸ್ಟ್ರಕ್ಚರ್‌ಗಳು (data structures), ಎರರ್ ಹ್ಯಾಂಡ್ಲಿಂಗ್ (error handling) ಮತ್ತು ಪರ್ಫಾರ್ಮೆನ್ಸ್ ಆಪ್ಟಿಮೈಸೇಶನ್‌ಗಳ ಬಗ್ಗೆ ಗುಪ್ತ ನಿರ್ಧಾರಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಡೆವಲಪರ್‌ಗಳು ಅಂತಿಮವಾಗಿ ಆ ನಿರ್ಧಾರಗಳನ್ನು ರಿವರ್ಸ್-ಇಂಜಿನಿಯರಿಂಗ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ, ಈ ಪ್ರಕ್ರಿಯೆಯು ಇಡೀ ಕೆಲಸದ ದಿನವನ್ನೇ ವ್ಯಯಿಸಬಹುದು.

ಏಕೈಕ ಮಾಡೆಲ್ ಈಗ ಯಾಕೆ ಸಾಕಾಗುವುದಿಲ್ಲ?

ವರ್ಷಗಟ್ಟಲೆ ಸಾಮಾನ್ಯ ವರ್ಕ್‌ಫ್ಲೋ ಹೀಗಿತ್ತು: ಒಬ್ಬ ಡೆವಲಪರ್ ಪ್ರಾಂಪ್ಟ್ ಟೈಪ್ ಮಾಡುತ್ತಾರೆ, ಮಾಡೆಲ್ ಒಂದು ಫೈಲ್ ಅನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ ಮತ್ತು ಡೆವಲಪರ್ ಅದನ್ನು ಕೋಡ್‌ಬೇಸ್‌ಗೆ ಕಾಪಿ ಮಾಡುತ್ತಾರೆ. ಇದು ತ್ವರಿತ ಡೆಮೋಗಳಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಆದರೆ ಪ್ರೊಡಕ್ಷನ್ ಸಾಫ್ಟ್‌ವೇರ್‌ಗೆ ಕೇವಲ ಒಂದು ಬಾರಿ ನೀಡುವ ಔಟ್‌ಪುಟ್ (one-shot output) ಸಾಕಾಗುವುದಿಲ್ಲ. ಉದಾಹರಣೆಗೆ, ಮಾಡೆಲ್ ಅರೇ (array) ಬದಲಿಗೆ ಲಿಂಕ್ಡ್ ಲಿಸ್ಟ್ (linked list) ಬಳಸಲು ಅಥವಾ ಎಕ್ಸೆಪ್ಶನ್‌ಗಳನ್ನು (exceptions) ಸುಮ್ಮನೆ ನಿರ್ಲಕ್ಷಿಸಲು ನಿರ್ಧರಿಸಿದಾಗ, ಆ ಆಯ್ಕೆಗಳು ಕೋಡ್‌ನಲ್ಲಿ ಸೇರಿಕೊಳ್ಳುತ್ತವೆ ಮತ್ತು ಪರಿಶೀಲಕನ ದೃಷ್ಟಿಯಿಂದ ಮಾಯವಾಗುತ್ತವೆ.

ಮಾಡೆಲ್‌ನ ಆಂತರಿಕ ತರ್ಕವನ್ನು (internal reasoning) ದಾಖಲಿಸದ ಕಾರಣ, ತಂಡಗಳು "AI ಈ ಪ್ಯಾಟರ್ನ್ ಅನ್ನು ಏಕೆ ಆರಿಸಿತು?" ಎಂದು ನಂತರ ಕೇಳಬೇಕಾಗುತ್ತದೆ. ಇದಕ್ಕೆ ಉತ್ತರ ಹುಡುಕಲು ಸೃಷ್ಟಿಸಲಾದ ಕಾಮೆಂಟ್‌ಗಳನ್ನು ಹುಡುಕುವುದು, ವಿಭಿನ್ನ ಟೆಂಪರೇಚರ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳೊಂದಿಗೆ ಪ್ರಾಂಪ್ಟ್ ಅನ್ನು ಮರು-ಚಲಾಯಿಸುವುದು ಅಥವಾ ಇಡೀ ಜನರೇಷನ್ ಹಂತವನ್ನು ಮರುಸೃಷ್ಟಿಸುವುದು ಬೇಕಾಗಬಹುದು. ಈ ಅನಿಶ್ಚಿತತೆಯೇ ಈಗ ಸಮೀಕ್ಷೆಯಲ್ಲಿ ಹೆಚ್ಚುವರಿ ಪರಿಶೀಲನಾ ಗಂಟೆಗಳಾಗಿ ಕಂಡುಬರುತ್ತಿದೆ.

ಕೆಲಸದ ವಿಭಜನೆ: multi-agent ಸಿಸ್ಟಮ್‌ಗಳು ಹೇಗೆ ಸಹಾಯ ಮಾಡುತ್ತವೆ

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

  • Architect agent: ಹೈ-ಲೆವೆಲ್ ಡಿಸೈನ್ ಡಾಕ್ಯುಮೆಂಟ್ ಅನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ, ಡೇಟಾ ಮಾಡೆಲ್‌ಗಳು, API ಕಾಂಟ್ರಾಕ್ಟ್‌ಗಳು ಮತ್ತು ಎರರ್-ಹ್ಯಾಂಡ್ಲಿಂಗ್ ತಂತ್ರಗಳನ್ನು ರೂಪಿಸುತ್ತದೆ.
  • Implementation agent: ಸ್ಪೆಸಿಫಿಕೇಶನ್‌ಗಳನ್ನು ಚೆಕ್‌ಲಿಸ್ಟ್ ಆಗಿ ಬಳಸಿಕೊಂಡು, ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನ್ನು ನಿಖರವಾಗಿ ಅನುಸರಿಸುವ ಕೋಡ್ ಅನ್ನು ಬರೆಯುತ್ತದೆ.
  • Verification agent: ಕೇವಲ ಗುಣಮಟ್ಟದ ಭರವಸೆಯ ಮೇಲೆ (quality assurance) ಗಮನಹರಿಸಿ, ಯೂನಿಟ್ ಟೆಸ್ಟ್‌ಗಳನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ, ಸ್ಟ್ಯಾಟಿಕ್ ಅನಾಲಿಸಿಸ್ ನಡೆಸುತ್ತದೆ ಅಥವಾ CI/CD ಪೈಪ್‌ಲೈನ್‌ಗಳನ್ನು ಸಿದ್ಧಪಡಿಸುತ್ತದೆ.

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

Multi-agent ವರ್ಕ್‌ಫ್ಲೋಗಳನ್ನು ಪ್ರಾಯೋಗಿಕವಾಗಿಸುವ ಪರಿಕರಗಳು

ಡೆವಲಪರ್‌ಗಳು ಈಗಾಗಲೇ ವಿವಿಧ ಉಪಕರಣಗಳ (utilities) ಮಿಶ್ರಣದೊಂದಿಗೆ ಈ ಪೈಪ್‌ಲೈನ್‌ಗಳನ್ನು ಜೋಡಿಸುತ್ತಿದ್ದಾರೆ:

  • IDE integrations: ಏಜೆಂಟ್‌ಗಳು ಸೈಡ್ ಪ್ಯಾನಲ್‌ಗಳಾಗಿ ಕಾಣಿಸಿಕೊಳ್ಳಲು ಮತ್ತು ಒಂದು ಕ್ಲಿಕ್ ಮೂಲಕ ಆರ್ಕಿಟೆಕ್ಚರ್ ಡಾಕ್ಯುಮೆಂಟ್ ಅನ್ನು ಕೋಡ್-ಜನರೇಷನ್ ಅಸಿಸ್ಟೆಂಟ್‌ಗೆ ವರ್ಗಾಯಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತವೆ.
  • CLI utilities: ಸ್ಕ್ರಿಪ್ಟ್ ಮಾಡಲಾದ ಸರಣಿಗಳನ್ನು (scripted sequences) ಸಕ್ರಿಯಗೊಳಿಸುತ್ತವೆ: ಆರ್ಕಿಟೆಕ್ಟ್ ಅನ್ನು ರನ್ ಮಾಡಿ, ಅದರ ಔಟ್‌ಪುಟ್ ಅನ್ನು ಕೋಡರ್‌ಗೆ ವರ್ಗಾಯಿಸಿ, ನಂತರ ಫಲಿತಾಂಶವನ್ನು ಟೆಸ್ಟರ್‌ಗೆ ನೀಡಿ.
  • Frameworks: ಪ್ರಾಜೆಕ್ಟ್ ಅಗತ್ಯಗಳಿಗೆ ಅನುಗುಣವಾಗಿ ಬದಲಾಯಿಸಬಹುದಾದ ಕಸ್ಟಮ್ ಏಜೆಂಟ್‌ಗಳನ್ನು ನಿರ್ಮಿಸಲು ಲೈಬ್ರರಿಗಳನ್ನು ಒದಗಿಸುತ್ತವೆ.
  • Specification-first platforms: ಯಾವುದೇ ಜನರೇಷನ್ ಪ್ರಾರಂಭವಾಗುವ ಮೊದಲು ಔಪಚಾರಿಕ ಅವಶ್ಯಕತೆಗಳ ಫೈಲ್ ಅನ್ನು (formal requirements file) ಬಯಸುತ್ತವೆ, ಇದರಿಂದ ವಿನ್ಯಾಸದ ಹಂತವನ್ನು ಬಿಟ್ಟುಹೋಗಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ.

ಸಮೀಕ್ಷೆಯ 70% ರಷ್ಟು ಅಂಕಿಅಂಶವು ಹೆಚ್ಚಿನ ತಂಡಗಳು ಈಗಾಗಲೇ ಈ ಪೈಪ್‌ಲೈನ್‌ಗಳ ಅಡ್-ಹಾಕ್ (ad-hoc) ಆವೃತ್ತಿಗಳನ್ನು ನಿರ್ಮಿಸಿವೆ ಎಂದು ಸೂಚಿಸುತ್ತದೆ. ಹೊಸ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳು ಇಂಜಿನಿಯರ್‌ಗಳು ಕೈಯಿಂದ ಮಾಡುತ್ತಿದ್ದ ಕೆಲಸವನ್ನು ಕೇವಲ ಔಪಚಾರಿಕಗೊಳಿಸುತ್ತವೆ.

ಯಾರು ಲಾಭ ಪಡೆಯುತ್ತಾರೆ—ಮತ್ತು ಯಾರು ಹಿಂದೆ ಉಳಿಯಬಹುದು?

ಹಣಕಾಸು ಅಥವಾ ಆರೋಗ್ಯ ರಕ್ಷಣೆಯಂತಹ ಕಟ್ಟುನಿಟ್ಟಾದ ಆಡಿಟ್ ಅಗತ್ಯತೆಗಳನ್ನು ಪೂರೈಸಬೇಕಾದ ಉದ್ಯಮಗಳು ತಕ್ಷಣವೇ ಪ್ರಯೋಜನ ಪಡೆಯುತ್ತವೆ. ದಾಖಲಿತ ಡಿಸೈನ್-ಟು-ಕೋಡ್ ಚೈನ್ (design-to-code chain) ಪ್ರೊಡಕ್ಷನ್‌ಗೆ ಗುಪ್ತ ದೌರ್ಬಲ್ಯಗಳು (vulnerabilities) ನುಗ್ಗುವ ಅಪಾಯವನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ. ಸಣ್ಣ ಸ್ಟಾರ್ಟ್‌ಅಪ್‌ಗಳು ವೇಗವಾಗಿ ಚಲಿಸುತ್ತಿದ್ದರೆ, ಒಂದೇ ಮಾಡೆಲ್‌ನ ವೇಗವು ಸಾಂದರ್ಭಿಕ ಮರುಕೆಲಸದ (rework) ವೆಚ್ಚಕ್ಕಿಂತ ಹೆಚ್ಚಾಗುವುದರಿಂದ, ಅನೇಕ ಏಜೆಂಟ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸುವ ಹೊರೆ ಅನಗತ್ಯವೆಂದು ಕಂಡേಬಹುದು.

ಮಲ್ಟಿ-ಏಜೆಂಟ್ ಸಿಸ್ಟಮ್‌ಗಳು ಸಂಕೀರ್ಣತೆಯನ್ನು ಹೆಚ್ಚಿಸುತ್ತವೆ ಎಂದು ಒಂದು ವಿರೋಧಾತ್ಮಕ ವಾದವು ತಿಳಿಸುತ್ತದೆ. ಮೂರು ಅಥವಾ ಅದಕ್ಕಿಂತ ಹೆಚ್ಚು ಮಾಡೆಲ್‌ಗಳನ್ನು ಸಂಯೋಜಿಸುವುದು ಇಂಟಿಗ್ರೇಷನ್ ಬಗ್‌ಗಳನ್ನು (integration bugs) ಉಂಟುಮಾಡಬಹುದು, ವಿಳಂಬವನ್ನು (latency) ಹೆಚ್ಚಿಸಬಹುದು ಮತ್ತು ಹೆಚ್ಚು ಸುಧಾರಿತ ಮೇಲ್ವಿಚಾರಣೆಯನ್ನು (monitoring) ಬಯಸಬಹುದು. ಕಸ್ಟಮ್ ಏಜೆಂಟ್‌ಗಳನ್ನು ನಿರ್ಮಿಸಲು ಅಥವಾ ನಿರ್ವಹಿಸಲು ಅಗತ್ಯವಿರುವ ಪರಿಣತಿಯಿಲ್ಲದ ತಂಡಗಳು, ವಾಸ್ತವಿಕ ಅಭಿವೃದ್ಧಿಗಿಂತ ಹೆಚ್ಚಾಗಿ ಆರ್ಕೆಸ್ಟ್ರೇಶನ್ (orchestration) ಮಾಡುವಲ್ಲಿ ಹೆಚ್ಚಿನ ಸಮಯವನ್ನು ಕಳೆಯಬಹುದು. ಅಂತಹ ಗುಂಪುಗಳಿಗೆ, ಉತ್ತಮವಾಗಿ ಟ್ಯೂನ್ ಮಾಡಲಾದ ಏಕೈಕ ಮಾಡೆಲ್—ವಿಶೇಷವಾಗಿ ಅಂತರ್ಗತ ವಿವರಣಾತ್ಮಕತೆಯನ್ನು (built-in explainability) ನೀಡುವ ಮಾಡೆಲ್—ಪ್ರಾಯೋಗಿಕ ಆಯ್ಕೆಯಾಗಿ ಉಳಿಯಬಹುದು.

ಮುಂಬರುವ ತಿಂಗಳುಗಳಲ್ಲಿ ಗಮನಿಸಬೇಕಾದ ಅಂಶಗಳು

  • AI-ಸೃಷ್ಟಿಸಿದ ಆರ್ಟಿಫ್ಯಾಕ್ಟ್‌ಗಳಿಗಾಗಿ ಪ್ರಮಾಣಿತ ಲಾಗಿಂಗ್ ಫಾರ್ಮ್ಯಾಟ್‌ಗಳು (Standardised logging formats) ಇದ್ದರೆ, ವಿವಿಧ ಏಜೆಂಟ್‌ಗಳ ಔಟ್‌ಪುಟ್‌ಗಳನ್ನು ಹೋಲಿಸುವುದು ಸುಲಭವಾಗಬಹುದು.
  • ಆರ್ಕಿಟೆಕ್ಚರ್, ಕೋಡಿಂಗ್ ಮತ್ತು ಟೆಸ್ಟಿಂಗ್ ಏಜೆಂಟ್‌ಗಳನ್ನು ಒಂದೇ ಸಬ್‌ಸ್ಕ್ರಿಪ್ಶನ್‌ನಲ್ಲಿ ಒಟ್ಟಿಗೆ ನೀಡುವ ಮಾರ್ಕೆಟ್‌ಪ್ಲೇಸ್ ಕೊಡುಗೆಗಳು (Marketplace offerings), ಸ್ವಂತ AI ಪರಿಣತಿಯಿಲ್ಲದ ತಂಡಗಳಿಗೆ ಇರುವ ಅಡೆತಡೆಗಳನ್ನು ಕಡಿಮೆ ಮಾಡಬಹುದು.
  • AI-ಸಹಾಯಿತ ಕೋಡ್ ಕುರಿತಾದ ನಿಯಂತ್ರಕ ಮಾರ್ಗದರ್ಶನವು (Regulatory guidance) ಹೆಚ್ಚಿನ ಸಂಸ್ಥೆಗಳನ್ನು ಲೆಕ್ಕಪರಿಶೋಧನೆಗೆ ಒಳಪಡಿಸಬಹುದಾದ (auditable), ಬಹು-ಹಂತದ ಪೈಪ್‌ಲೈನ್‌ಗಳತ್ತ ತಳ್ಳಬಹುದು.
  • ಕೇವಲ ಜನರೇಷನ್ ವೇಗವನ್ನಷ್ಟೇ ಅಲ್ಲದೆ, ಒಟ್ಟು ಅಭಿವೃದ್ಧಿ ಸಮಯವನ್ನು ಅಳೆಯುವ ಪರ್ಫಾರ್ಮೆನ್ಸ್ ಬೆಂಚ್‌ಮಾರ್ಕ್‌ಗಳು (Performance benchmarks), ಹೆಚ್ಚುವರಿ ಸಂಯೋಜನೆಯ ಹೊರೆ (coordination overhead) ಲಾಭದಾಯಕವೇ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಲು ತಂಡಗಳಿಗೆ ಸಹಾಯ ಮಾಡುತ್ತವೆ.

ಸಮೀಕ್ಷೆಯ ಪ್ರಮುಖ ಅಂಕಿಅಂಶಗಳು ಒಂದು ಸ್ಪಷ್ಟವಾದ ಕಥೆಯನ್ನು ಹೇಳುತ್ತವೆ: ಡೆವಲಪರ್‌ಗಳು ಹೊಸ ಕೋಡ್ ಬರೆಯುವುದಕ್ಕಿಂತ ಹೆಚ್ಚಾಗಿ, AI ಔಟ್‌ಪುಟ್ ಅನ್ನು ಮರುಪರಿಶೀಲಿಸಲು ತಮ್ಮ ವಾರದ ಹೆಚ್ಚಿನ ಸಮಯವನ್ನು ಕಳೆಯುತ್ತಿದ್ದಾರೆ. ಮಲ್ಟಿ-ಏಜೆಂಟ್ ವರ್ಕ್‌ಫ್ಲೋಗಳು ಇದಕ್ಕೆ ನೇರ ಪ್ರತಿಕ್ರಿಯೆಯಾಗಿ ಹೊರಹೊಮ್ಮುತ್ತಿವೆ; ಇವು "ಬ್ಲಾಕ್-ಬಾಕ್ಸ್" (black-box) ಜನರೇಷನ್ ಅನ್ನು ದಾಖಲಿತ ಮತ್ತು ಪರಿಶೀಲಿಸಬಹುದಾದ ಪ್ರಕ್ರಿಯೆಯನ್ನಾಗಿ ಮಾಡುವ ಟ್ರೇಸಬಿಲಿಟಿ (traceability) ಅನ್ನು ಒದಗಿಸುತ್ತವೆ. ಹೆಚ್ಚುವರಿ ಆರ್ಕೆಸ್ಟ್ರೇಶನ್ ಸಂಕೀರ್ಣತೆಯು ಪ್ರತಿಯೊಂದು ತಂಡಕ್ಕೂ ಸಮರ್ಥನೀಯವೇ ಎಂಬುದು ಇನ್ನು ನೋಡಬೇಕಿದೆ, ಆದರೆ AI ಜವಾಬ್ದಾರಿಗಳನ್ನು ವಿಭಜಿಸುವ ಪ್ರವೃತ್ತಿಯು ಸಾಫ್ಟ್‌ವೇರ್ ನಿರ್ಮಾಣದ ವಿಧಾನವನ್ನೇ ಈಗಾಗಲೇ ಮರುರೂಪಿಸುತ್ತಿದೆ.