- डेवलपर के काम का केंद्र IDE में लाइन-दर-लाइन code editing से हटकर agent orchestration और supervision interfaces की ओर जा रहा है, और Cursor Glass, Claude Code Web, GitHub Copilot Agent जैसे कई टूल इस बदलाव को तेज कर रहे हैं
- नया development loop "intent specification → delegation → observation → diff review → merge" के रूप में उभर रहा है, जहाँ file नहीं बल्कि agent काम की मूल इकाई बन रहा है
- parallel agent execution के लिए work isolation (
git worktree), task state management, background asynchronous execution, और attention routing जैसे patterns अलग-अलग टूल्स में एक जैसी दिशा में विकसित हो रहे हैं
- जब agent 90% सही होता है लेकिन सूक्ष्म रूप से गलत होता है, तब पैदा होने वाली review fatigue और security·governance overhead नई लागत के रूप में उभर रहे हैं
- IDE गायब नहीं हो रहा, बल्कि de-centered हो रहा है; सूक्ष्म inspection, debugging, और कठिन कामों के लिए यह अब भी अहम है, लेकिन programming की शुरुआत अब केवल यहीं से नहीं होती
file editing से workstream control तक
- पारंपरिक IDE को file open → edit → build → debug → repeat जैसे tight inner loop के लिए optimize किया गया था, लेकिन अब agents इस loop का अधिकांश हिस्सा autonomously चला सकते हैं, इसलिए यह productivity की प्रमुख इकाई नहीं रह गया है
- नया loop "intent specification → delegation → observation → diff review → merge" के रूप में है; इसे "chat window वाले autocomplete" से अलग बनाता है tool-use autonomy और उस autonomy को control में रखने वाले interface का मेल
- Claude Code Web (या Desktop) और Codex स्पष्ट रूप से परिभाषित tasks को isolated cloud environments में चलने वाले agents को सौंपते हैं, और उनकी progress browser में देखी जा सकती है — terminal या local setup की ज़रूरत नहीं
- GitHub Copilot Agent multi-file changes को स्वतंत्र रूप से plan और implement करता है, branch बनाता है, tests चलाता है, और PR submit करता है; डेवलपर की मुख्य भूमिका result review और iteration रह जाती है
- Conductor एक desktop app है जो कई Claude Code agents को isolated workspaces में एक साथ चलाते हुए live progress monitoring देता है
- Google Jules asynchronous background task handling पर केंद्रित है — काम assign करें, फिर पूरा होने पर result review करें
- इन टूल्स का साझा mental model: agent ही काम की इकाई है, file नहीं — optimize करने वाला interface वह है जो agents को निर्देश दे, monitor करे, और review करे; न कि सिर्फ तेज़ typing कराए
आकार लेती orchestration layer
- work isolation एक base primitive के रूप में स्थापित हो रहा है: parallel agents को एक-दूसरे से टकराना नहीं चाहिए, इसलिए लगभग सभी प्रमुख टूल्स
git worktree (या समान तरीके) अपना रहे हैं — Conductor हर agent session को isolated workspace से map करता है, और Vibe Kanban भी kanban-based agent workflow में यही तरीका अपनाता है
- planning और task state top-level UI बन रहे हैं: Vibe Kanban जैसे टूल्स "tabs और files" को "tasks और states" से replace करते हैं — task cards (landing page, backend service, email integration आदि) बनाइए, उन्हें अलग-अलग agents और models को assign कीजिए, और पूरे काम को एक lightweight project board की तरह manage कीजिए, जहाँ "team" autonomous रूप से execute करती है
- background agents और async-first design: Cursor, Copilot, Antigravity आदि ऐसे background agents को support करते हैं जो run होते समय user participation नहीं माँगते — intent define करें, फिर हट जाएँ, और पूरा होने पर review करें; Jules भी इसी तरह काम करता है, इस मान्यता के साथ कि progress bar देखते रहने के लिए user attention बहुत कीमती है
- parallel agents के लिए attention management: जब कई agents साथ चल रहे हों, तो असली bottleneck यह जानना है कि अभी किस agent में हस्तक्षेप ज़रूरी है — Conductor sessions के बीच live progress दिखाता है, और cmux terminal panes में notification rings और unread badges लाता है — "agent को attention चाहिए" अब development environment में first-class event बनता जा रहा है
- software lifecycle में embedded agents: GitHub Copilot coding agent asynchronous है, control layer के ज़रिए security सुनिश्चित करता है, और GitHub Actions पर चलता है — यह सिर्फ code लिखने के तरीके से नहीं, बल्कि असली code shipping flow (issue → PR → CI → merge) से जुड़ता है
- ये टूल्स यह दावा नहीं करते कि IDE बेकार हो गया है, और कई टूल्स IDE के साथ interoperable हैं; लेकिन बार-बार दिखने वाले patterns — parallel workspaces, diff-first review, task states, background execution, lifecycle integration — ही वह shift हैं जिनका मतलब "IDE की मौत" वाले दावे से है
डेवलपर अब भी IDE पर क्यों लौटते हैं
- "IDE मर चुका है" के खिलाफ सबसे मज़बूत तर्क: IDE अब भी precise navigation, local reasoning, interactive debugging, और direct manipulation के ज़रिए system understanding जैसी कठिन समस्याओं को एक high-fidelity feedback loop में समेट देता है
- सबसे महत्वाकांक्षी orchestration tools भी manual editing escape hatch बनाए रखते हैं — thread के भीतर diff review, changes पर comments, और फिर editor में manual adjustment वाला workflow जानबूझकर design किया गया है
- कुछ ऐसे क्षेत्र जहाँ agent tools खुद अपनी सीमाएँ दिखाते हैं: बड़े repositories में multi-file refactoring अब भी software engineering agents के लिए सबसे कठिन चुनौतियों में से एक है — यहाँ system का ऐसा mental model चाहिए जिसे agent सिर्फ context से पूरी तरह reconstruct नहीं कर सकता
- वह failure mode जो डेवलपर को IDE-स्तरीय inspection से बाँधे रखता है: जब agent 90% सही हो लेकिन बारीकी से गलत हो — समस्या ढूँढने की लागत अक्सर खुद लिखने की लागत से ज़्यादा हो जाती है, और high-risk changes में IDE अब भी precise inspection के लिए सबसे अच्छा tool है
नई लागत: review fatigue और governance overhead
- जब development "कई parallel agents चलाने" जैसा हो जाता है, तो workflow text editing का नहीं बल्कि distributed systems management का रूप लेने लगता है — observability, permissions, isolation, governance
- agent workflow labor को उलट देता है: code writing की जगह review केंद्र में आ जाता है, और दिन के अंत में 12 parallel agents के 12 diffs का सामना करना पड़ना एक वास्तविक review fatigue समस्या है — यही वजह है कि सबसे सावधान tools attention routing, structured planning, और review-first gates पर ज़ोर देते हैं
- जैसे-जैसे agents को web browsing, database queries, filesystem writes, deployment triggers जैसे और ज़्यादा tools तक पहुँच मिलती है, security surface बढ़ती जाती है — agent क्या कर सकता है जितना महत्वपूर्ण है, उतना ही यह भी कि उसे क्या करने की अनुमति दी गई है
- observability और control के नज़रिए से, IDE-integrated agent modes पहले ही explicit tool logs और approval gates की दिशा में विकसित हो रहे हैं — जिस क्षण agent asynchronously काम करता है और CI pipelines को छूता है, governance विकल्प नहीं बल्कि आवश्यकता बन जाती है
क्या बचेगा: IDE, control plane, या दोनों
- "IDE की मौत" power center के shift के रूप में सही है, लेकिन शाब्दिक भविष्यवाणी के रूप में गलत
- इस दावे का सबसे मज़बूत रूप यह है: IDE मुख्य workspace से पीछे हटकर कई उप-टूल्स में से एक बन जाएगा — इसका उपयोग precise inspection, debugging, और final editing के लिए होगा, जबकि planning, orchestration, review, और agent management dashboards, issue trackers, observability terminals, और cloud control planes की ओर शिफ्ट होंगे
- "बड़ा IDE" वाला framing भी उतना ही तर्कसंगत है: नया "IDE" वह system हो सकता है जो multi-agent orchestration, isolated workspaces, permissions और audit logs, diff-first review, reliable tool connectivity, और attention routing उपलब्ध कराए — file editor अब भी रहेगा, लेकिन अब वह front door नहीं होगा
- IDE मर नहीं रहा, बल्कि de-centered हो रहा है — काम orchestration surfaces की ओर जा रहा है, और इंसान intent define करने, parallel agent runtimes को delegate करने, तथा supervision, review, और governance पर ज़्यादा समय लगाएगा
- IDE अब भी accuracy, understanding, और वे high-difficulty problems जिनसे agents अभी भी जूझते हैं के लिए केंद्रीय है, लेकिन अब programming का इकलौता स्थान नहीं है, और बढ़ती संख्या में डेवलपर्स के लिए यह पहला पड़ाव भी नहीं रह गया है
अभी कोई टिप्पणी नहीं है.