आप एक ही codebase पर multiple AI coding agents चला रहे हैं। शायद तीन, शायद तेरह। हर एक को अपना काम track करना है: issues बनाना, statuses update करना, dependencies check करना, progress report करना। पूरे fleet में हर मिनट दर्जनों writes हो रहे हैं।
यही agentic engineering है: इंसान AI agents के fleets को coordinate करके software ship करते हैं। Workflow नया है, लेकिन सबसे पहले हर कोई उस tool की तरफ हाथ बढ़ाता है जो पहले से जानता है। Jira। Linear। GitHub Issues। Notion। जो भी आपकी team project management के लिए use करती है।
यह काम नहीं करता। और यह mismatch surface-level नहीं है। यह architectural है।
Latency throughput को खत्म कर देती है
एक Jira API call में 200-800ms लगते हैं। Linear API तेज़ है लेकिन फिर भी 100-300ms। एक single issue बनाना, उसकी dependencies पढ़ना, status update करना: HTTPS, DNS resolution, TLS handshake, और JSON serialization से होकर तीन round-trips। अच्छे दिन में 500ms।
Local CLI से SQLite database में write करने में 50ms से कम लगता है। अक्सर 10ms से भी कम।
यह rounding error लगता है जब तक operations की संख्या से multiply न करें। एक agent किसी task पर काम करते हुए 2-3 sub-issues बना सकता है, parent का status update कर सकता है, blockers check कर सकता है, और progress comment कर सकता है। छह operations। हर एक 500ms पर, यह 3 seconds की pure waiting है। हर एक 10ms पर, यह 60 milliseconds। जो agent 30 seconds में task cycle पूरा कर सकता था, अब वह 10% time code लिखने की जगह HTTP wait में खर्च कर रहा है।
इसे 13 agents तक scale करें और overhead hours में minutes में measure होने लगता है।
Auth infrastructure नाज़ुक glue है
हर agent को API token चाहिए। Tokens expire होते हैं। Rate limits हैं। एक agent के 20 rapid-fire updates का burst 429 Too Many Requests trigger कर देता है। अब वह अपना काम करने की बजाय exponential backoff वाले retry loop में फंसा है।
आपने एक पूरा failure mode add कर दिया जिसका काम से कोई लेना-देना नहीं। Token rotation, secret management, agents के बीच rate limit budgeting। यह सब operational overhead है एक ऐसी capability के लिए जो trivial होनी चाहिए: local database में एक record लिखना।
जब issue tracker disk पर एक file हो, तो authenticate करने के लिए कुछ है ही नहीं। Agent filesystem पढ़ सकता है तो issues भी पढ़-लिख सकता है। एक कम चीज़ जो टूट सकती है।
Data model humans को assume करता है
Jira खोलो। Sprints दिखते हैं। Story points। Profile photos और email addresses वाले assignees। "In Review" और "Ready for Grooming" जैसे states वाले workflows। पूरा data model उस team के लिए design हुआ है जो standups, sprint planning, और retrospectives करती है।
Agents standups नहीं करते। Story points में estimate नहीं करते। उन्हें सात states और चार approval gates वाला workflow नहीं चाहिए।
Agents को dependency graph चाहिए। यह task उस task से blocked है। इस epic में 12 children हैं और 7 complete हैं। इस agent ने यह issue 45 seconds पहले claim किया और तब से report नहीं आई। Fundamental data structure columns में move होने वाले cards का board नहीं है, बल्कि blocking relationships वाला tasks का tree है।
SaaS tools "automation" features bolt on करते हैं, लेकिन नीचे का core model अभी भी humans के लिए Kanban board है। आप Jira plugin लिख सकते हैं जो agents को issues create करने दे। लेकिन यह नहीं बदल सकते कि Jira आपके agent को sprint team का एक person मानता है।
Cloud dependency single point of failure है
आपके agents locally चलते हैं। Local files पढ़ते हैं, local code लिखते हैं, local git repos में commit करते हैं। Offline काम कर सकते हैं, plane में, या 2000ms latency वाले network पर। उन्हें फर्क नहीं पड़ता।
लेकिन अगर issue tracker एक SaaS product है, तो हर agent operation को internet access चाहिए। Linear 10 minutes के लिए down हो गया? पूरा fleet रुक जाता है। घर का internet 30 seconds के लिए हिचकिचाया? हर agent retry loop में जा रहा है। Issue tracker, जिसे काम coordinate करना था, पूरे system का single point of failure बन जाता है।
Local-first का मतलब issue tracker filesystem जितना reliable है। हमेशा available, हमेशा fast, हमेशा आपके control में।
Write volume orders of magnitude गलत है
SaaS project management tools 5-10 humans की team के लिए design हैं जो दिन में कुछ updates करती है। पूरी team में शायद 50-100 writes।
13 agents हर कुछ minutes में issues update कर रहे हैं, एक single project से per hour सैंकड़ों API calls आ रही हैं। यह usage में marginal increase नहीं है। यह एक बिलकुल अलग usage pattern है। Human teams के लिए generous लगने वाली rate limits agent fleets के लिए hard walls बन जाती हैं।
और बात सिर्फ volume की नहीं है। Concurrency की है। तीन agents एक ही epic के children को simultaneously update कर रहे हैं। Status fields पर race conditions। Comment threads पर optimistic locking failures। ये वो problems हैं जो SaaS tools को कभी solve नहीं करनी पड़ीं क्योंकि humans तीन terminals से एक ही issue को एक ही instant में update नहीं करते।
Collaboration का मतलब data छोड़ना है
Jira project किसी teammate के साथ share करने के लिए दोनों को Jira accounts चाहिए। Data Atlassian के servers पर है। आप per seat, per month pay कर रहे हैं अपने ही project data को उनकी API से access करने के privilege के लिए।
दूसरे tool पर जाना है? जो export हो सके CSV में करो और बाकी छोड़ दो। Comments, attachments, custom fields, audit history: usable format में निकालना good luck की बात है। SaaS model data ownership को convenience के बदले trade करता है।
लेकिन collaboration के लिए बीच में vendor की ज़रूरत नहीं। अगर आपका issue database Dolt (databases के लिए Git) जैसी चीज़ से backed है, तो remote पर push करो और teammate pull करे। Code को branch करते हो वैसे ही issue database को branch करो। Merge भी वैसे ही। Conflicts भी उन्हीं tools और mental model से resolve करो। Data तुम्हारा रहता है। Collaboration git की तरह काम करता है, subscription की तरह नहीं।
असल में क्या काम करता है
Brand names हटाओ और सोचो कि agents को issue tracker से actually क्या चाहिए:
- Local-first. कोई network dependency नहीं। Database disk पर एक file है।
- CLI-native. Agents terminal में रहते हैं। Interface भी वहीं होना चाहिए।
- Git-backed. Versioned, mergeable, auditable। कोई vendor lock-in नहीं।
- कोई auth overhead नहीं। Agent filesystem पढ़ सकता है तो issues track कर सकता है।
- Low latency. Per operation 50ms से कम, 500ms नहीं।
- बिना middleman के syncable. API webhooks नहीं, git repo की तरह push और pull।
यही मैं daily use करता हूं। beads एक Git-native issue tracker है जो exactly इसी workflow के लिए बना है। सब कुछ local SQLite database में store होता है, Dolt से versioning और sync मिलती है। CLI primary interface है। Agents issues create, update, और query वैसे ही करते हैं जैसे कोई और command run करते हैं।
Beadbox इसके ऊपर मैंने जो visual layer बनाई है वह है। यह local database में changes watch करती है और dependency trees, epic progress, और agent activity real time में render करती है। Agents CLI use करते हैं। मैं dashboard use करता हूं। दोनों same local database से read करते हैं।
पुराने tools problem नहीं हैं
Jira अपने काम में excellent है: structured workflows से human teams को coordinate करना। Linear छोटी teams के लिए beautiful है जो speed और polish चाहती हैं। GitHub Issues open-source collaboration के लिए frictionless है।
कोई भी bad नहीं है। वे एक अलग problem solve कर रहे हैं। अगर आपका workflow पांच humans का two-week sprints वाला है, तो उन्हें use करते रहो।
लेकिन अगर आप 5, 10, या 13 AI agents चला रहे हैं जो same codebase पर real time में coordinate कर रहे हैं, तो आप SaaS model से आगे निकल चुके हैं। Agentic engineering को agentic engineering के लिए बना tooling चाहिए, न कि human workflows जिन पर API bolt on किया गया हो।