सॉफ्टवेयर commits के बीच बनता है

 (zed.dev)
1 पॉइंट द्वारा GN⁺ 4 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • DeltaDB agents के साथ हुई बातचीत और agents द्वारा edit की गई worktree, दोनों को साथ में version control करने वाला एक नए तरह का version control system है
  • Git अलग-अलग commit के इर्द-गिर्द बना है, इसलिए code लगातार बदलते रहने के दौरान चलती बातचीत और code changes को साथ में संभालने के लिए इसे design नहीं किया गया था
  • DeltaDB सिर्फ commits ही नहीं, बल्कि काम के दौरान होने वाली हर operation को बारीक delta stream के रूप में रिकॉर्ड करता है और हर delta को एक stable identifier देता है
  • messages और उन messages से बने edits को साथ-साथ रिकॉर्ड किया जाता है, और कई लोग व agents अलग-अलग machines पर एक ही file को एक साथ edit कर सकते हैं
  • collaboration, commit और push के बाद होने वाली review process की बजाय, code बनते समय होने वाली बातचीत और worktree के भीतर अधिक सीधे तरीके से हो सकती है

पृष्ठभूमि और समस्या-बोध

  • Zed team pull request वाले तरीके की आदी नहीं थी; वे एक ही worktree में साथ काम करते हुए, code लिखने के दौरान चर्चा करके trust और shared understanding बनाते आए थे
  • GitHub में code पर बात commit और push के बाद ही की जा सकती है, लेकिन Zed team की अहम बातचीत आम तौर पर उस समय से पहले ही पूरी हो जाती थी
  • Zed की शुरुआत 2021 में commit की सीमाओं से आगे बढ़ने के लिए हुई थी, और लक्ष्य था पहले दुनिया के बेहतरीन developers के लायक editor बनाना, फिर उसी के भीतर बेहतर collaboration देना
  • इंसानों के बीच collaboration के संदर्भ में जिस समस्या पर लंबे समय से विचार किया गया था, वही agents के साथ collaboration करते समय और भी महत्वपूर्ण हो गई
  • code बनाने वाली बातचीत अब धीरे-धीरे software का वास्तविक source बन रही है, और उस बातचीत को लगातार आगे बढ़ते व बदलते code के साथ परस्पर संदर्भित होना चाहिए
  • Git अलग-अलग commits के इर्द-गिर्द बना है, इसलिए इसे ऐसी सतत बातचीत और code बदलावों के संबंध को support करने के लिए design नहीं किया गया था

DeltaDB और अगला कदम

  • हर commit नहीं, हर operation

    • DeltaDB काम को बारीक delta stream में बांटता है, और Git जहाँ हर commit पर snapshot store करता है, वहीं यह commits के बीच होने वाली हर operation को रिकॉर्ड करता है
    • हर delta का एक stable identifier होता है, इसलिए code लगातार बदलते रहने पर भी उसके evolution के किसी खास पल को point किया जा सकता है
    • worktree को उसके बदलने की पूरी process सहित version control किया जाता है, और उसे उन बातचीतों के साथ संभाला जाता है जो उन बदलावों को आगे बढ़ाती हैं
    • messages और उन messages से बने edits को साथ-साथ रिकॉर्ड किया जाता है, ताकि वे एक-दूसरे से अलग न हों
    • DeltaDB में conflict-free replicated worktree built-in है, जिससे कई लोग और agents अलग-अलग machines पर एक ही file को एक साथ edit कर सकते हैं
    • files वास्तविक files होती हैं; agents terminal के ज़रिए files पर काम करते हैं, और users ज़रूरत पड़ने पर पूरी worktree को disk पर mount करके अपने tools इस्तेमाल कर सकते हैं

  • source code अब source conversation है

    • references line numbers की बजाय delta पर fixed होते हैं, इसलिए code नीचे खिसक जाए तब भी reference बना रहता है
    • पुरानी बातचीत की किसी भी line से वर्तमान state के code तक या उस समय agent ने जो code लिखा था, वहाँ जाया जा सकता है
    • code की किसी भी line से उस code को बनाने वाली बातचीत और बाद में उस code को छूने वाली हर बातचीत को खोजा जा सकता है
    • agents भी इस जानकारी का उपयोग करके उस code की background context ला सकते हैं जिसे वे बदल रहे हैं
    • agents पहले उस code पर काम कर चुके agent को वापस बुलाकर पूछ सकते हैं कि इसे उस तरह क्यों लिखा गया था

  • collaboration के लिए commit करना ज़रूरी नहीं होना चाहिए

    • लक्ष्य यह है कि agents के साथ बातचीत ही collaboration के लिए ज़रूरी एकमात्र बातचीत बन जाए
    • team members काम जारी रहने के दौरान ही शामिल हो सकते हैं, काम करने वाले agent से बात कर सकते हैं और progress के बीच में comments जोड़ सकते हैं
    • team members को शामिल होने के लिए पहले commit और push का इंतज़ार करने की ज़रूरत नहीं होती
    • pull requests, review threads और inline comments ऐसी प्रक्रियाएँ थीं जो बाद में चर्चा को code से फिर जोड़ने के लिए बनीं, क्योंकि code और discussion अलग-अलग जगहों पर थे
    • जब code और discussion एक ही जगह हों, तो ऐसी प्रक्रियाएँ गायब हो जाती हैं
    • Git और CI जाँच चलाने और बाहरी दुनिया से जुड़ने की भूमिका तक सीमित रहते हैं; वे collaboration के लिए मजबूरन होने वाली जगह नहीं बनते

  • अगला कदम

    • software अब commit नहीं, बल्कि बातचीत के भीतर आकार ले रहा है
    • DeltaDB इसके लिए बना version control system है, और इसे कुछ हफ्तों में शुरुआती users के लिए उपलब्ध कराया जाएगा
    • अगर आप इसे पहले आज़माना चाहते हैं, तो waitlist में नाम दर्ज कर सकते हैं

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 4 시간 전
Hacker News की राय

  • commits के बीच का काम गंदी soup जैसा होता है, इसलिए उसे देखने से किसी को भी खास फायदा नहीं होता। git rebase से history को फिर से लिखकर हर commit को छोटा और atomic बनाया जा सकता है, और commits से बनी कहानी यह समझा सकती है कि चीज़ें अपनी मौजूदा स्थिति तक क्यों पहुँचीं
    असल में चीज़ें समयक्रम में कैसे आगे बढ़ीं, यह उतना महत्वपूर्ण नहीं है। मैं इस बात से सहमत हूँ कि pull request review बहुत देर से होता है, लेकिन समस्या यह है कि pull requests पूरे branch के नतीजे को एक साथ review करने के लिए डिज़ाइन किए गए हैं, इसलिए individual commit review मुश्किल हो जाता है। समाधान यह नहीं होना चाहिए कि सारा noise साझा कर दिया जाए, बल्कि यह कि feature या fix पूरा होने से पहले शुरुआती काम की review हो सके, इसके लिए छोटे और atomic commits को बढ़ावा दिया जाए

    • यहाँ के comments और मेरे पेशेवर नेटवर्क को देखें तो लोग आम तौर पर दो खेमों में बँटे दिखते हैं। एक पक्ष Git को एक तरह के खुरदरे auto-save की तरह इस्तेमाल करता है और merge के समय चीज़ों को जोड़ता है, जबकि दूसरा साफ-सुथरे, पूरी तरह काम करने वाले atomic commits को पसंद करता है
      मेरे अनुभव में पहला तरीका ज़्यादा आम है, शायद इसलिए कि GitHub स्वाभाविक रूप से उसी तरीके को बेहतर support करता है, और squash commits दूसरे तरीके की कुछ समस्याएँ भी हल कर सकते हैं। अगर चुनना पड़े, तो मुझे पहला तरीका कहीं ज़्यादा समझदारी भरा लगता है
    • क्या यह Phabricator या Gerrit जैसे tools की समस्या नहीं, बल्कि बस GitHub की समस्या है?
    • वह गंदी soup हो या कुछ और, अगर disk space या cost समस्या नहीं है, तो किसी का—शायद किसी agent का—यह देख पाना कि मैंने क्या किया, अपने आप में ठीक है
      मुझे इस पर बहुत मजबूत यक़ीन नहीं है, लेकिन मुझे लगता है कि agent, भले कुछ लोगों को यह noise लगे, फिर भी अतिरिक्त जानकारी को पसंद करेंगे
    • मुझे उम्मीद थी कि ऐसी प्रतिक्रिया आएगी। यह पढ़ते हुए मुझे वह निराशा याद आई जो version control पर हर बार ऐसी ही भावना देखकर होती है
      बहुत से लोग record को “साफ़” दिखाने के लिए उसे बहुत आसानी से फेंक देते हैं। यह बेमानी है, लेकिन हैरानी की बात है कि कुछ programmers की एक खास तरह की logic में यह ठीक लगता है
      मेरा तरीका है कि मैं दिन में कई दर्जन बार commit करता हूँ। commit वह record है जो वास्तव में हुआ, और मैं चाहता हूँ कि उस record का जितना हो सके उतना हिस्सा बचा रहे। कई बार git bisect ने किसी ऐसे छोटे एक-line commit की ओर इशारा किया है जो देखने में बिल्कुल harmless लगता था, और उसी से बहुत बाद में मिली किसी subtle bug का पता चला
      मेरे हिसाब से source control का मकसद ही ऐसी चीज़ें ढूँढ़ना है। अगर मुझे बड़े commits की हर line खंगालनी पड़ती, तो ऐसी समस्याएँ कहीं ज़्यादा दर्दनाक होतीं
      इसलिए जब लोग जानबूझकर PR-भर के commits को मिलाकर एक कर देते हैं, और version control का वही हिस्सा फेंक देते हैं जो वास्तव में उपयोगी है, तो यह मुझे सच में समझ नहीं आता। parent comment जैसे खेमे भी बहुत हैं, इसलिए लेखक की ज़्यादा granular record रखने की योजना आसान लड़ाई नहीं होगी
    • जिस तरह आप commits इस्तेमाल करते हैं, वह मुझे उस तरीके जैसा लगता है जिससे मैं काम पर stacked PRs का इस्तेमाल करता हूँ
      अच्छी commit hygiene को team स्तर पर लागू कराना मुश्किल है, लेकिन अजीब तरह से PR स्तर पर लोग अच्छे explanations लिखने और change groups को साफ-सुथरा रखने में काफ़ी सहयोगी होते हैं

  • यह Git पर कम भरोसे वाले frequent auto-commits जैसा लगता है। Git frequent auto-commits को काफ़ी अच्छी तरह संभाल सकता है
    अगर आप frequent auto-commits को ज़्यादा “साफ़” higher-level commits में roll up करना चाहते हैं, लेकिन अलग-अलग समय के auto-commits की “conversation” भी बचाए रखना चाहते हैं, तो कभी-कभी git merge --no-ff इस्तेमाल करें और --first-parent जैसे tools से “conversation” commits की बजाय higher-level commits पर focus करें
    Git backend में पहले से ही Git pack और दूसरे tools के लिए delta DB optimization काफी है, और असल में थोड़ा सुधार Git frontend में चाहिए—खासकर --first-parent—और उन अनगिनत Git UIs में जो “subway map first/subway map only” तरह के हैं। बहुत से लोगों को वे diagrams बदसूरत, उलझाने वाले और अप्रिय लगते हैं, इसलिए --first-parent के अनुरूप ज़्यादा drill-down UI होने चाहिए

    • मैं भी ऐसा ही करता हूँ। branch के commits मैं आम तौर पर नहीं देखता, लेकिन ज़रूरत पड़े तो वे मौजूद रहते हैं। git blame को भी --first-parent इस्तेमाल करने के लिए configure किया जा सकता है

  • मैं “software commits के बीच बनता है” से सहमत हूँ, लेकिन “DeltaDB हर commit के बीच का सारा काम capture करता है” से सहमत नहीं हूँ
    सबसे पहले, यह दखल देने वाला लगता है। मैं काम करते समय 24x7 चलने वाला screen recorder भी नहीं चाहूँगा। मेरी गलतियाँ दिख जाना गलत बात नहीं है, लेकिन अगर मैं अपना काम ठीक से कर रहा हूँ, तो जो value मैं बनाता हूँ वह commits में आनी चाहिए, और वह तरीका मुझे कहीं कम intrusive लगता है
    दूसरा, मैं कई tools इस्तेमाल करता हूँ, और मैं उन सबको किसी अजीब DB में जोड़ना नहीं चाहता। अगर किसी बिंदु पर बात बस “किसी external process ने कुछ किया” पर खत्म हो जाती है, तो फिर सब कुछ capture करने का मतलब क्या है? Zed बहुत कुछ integrate कर सकता है, यह अच्छी बात है, लेकिन इसका मतलब यह नहीं कि मैं Zed में integrated हर चीज़ इस्तेमाल करना चाहता हूँ। आख़िरी बार जब मैंने देखा था, Zed में ACP के ज़रिए Claude Code इस्तेमाल करते समय पुरानी messages को rewind करके edit भी नहीं किया जा सकता था
    आख़िर में, व्यक्तिगत रूप से मुझे लगता है कि हम पहले ही commits की असल भावना खो चुके हैं। ज़्यादातर लोग बस मनमाने, असीमित बदलावों का एक bundle बना लेते हैं, फिर git commit चला देते हैं, उसके बाद उस bundle की review एक विशाल lump की तरह होती है, और फिर commits आपस में merge कर दिए जाते हैं। इससे दुनिया खत्म नहीं हो जाती, लेकिन हाथ से गढ़े गए अच्छे commits वाकई शानदार होते हैं। जिन projects में यह तरीका enforce किया जाता है, वहाँ git blame चलाकर आप तुरंत समझ जाएँगे कि मेरा मतलब क्या है
    DeltaDB जैसी चीज़ें बस commits को ढीले-ढाले ढंग से जोड़ने की आदत को और मज़बूत और पक्का करेंगी। अगर जानना हो कि क्या हुआ, तो अब आप बस user और LLM के बीच हुई बातचीत को voyeur की तरह replay कर सकते हैं
    आख़िरी बिंदु दिलचस्प भी है और चिढ़ाने वाला भी। टीम के साथियों के लिए उपयोगी अच्छी engineering practice होने के नाम पर लोगों को changes और motivation document करने के लिए मनाना मुश्किल था, लेकिन हर कोई LLM को समझाने के लिए तैयार है। इसका बड़ा कारण यह है कि LLM से काम करवाने के लिए इसकी ज़रूरत पड़ती है, लेकिन यह देखना दिलचस्प है कि लोग LLM को संतुष्ट करने के लिए कितनी ऐसी चीज़ें करने लगे हैं जो वे पहले नहीं करते थे। अचानक वे चीज़ें, जो अजीब तरह से पहले document नहीं थीं, CLAUDE.md में document होने लगी हैं

  • कमिट्स के बीच लिखा गया कोड मेरी सोचने की प्रक्रिया है। मैं कोड लिखकर, मिटाकर, फिर से लिखकर सोचता हूँ
    जो कोड कमिट के रूप में बाहर जाता है, वह इस तरह लिखा जाता है कि दूसरे लोग उसे समझ सकें, और वह सोचने के लिए लिखी गई प्रक्रिया का परिणाम होता है। मैं यह नहीं चाहता कि मेरी सोच serialize हो, version control में जाए, और सबके लिए सार्वजनिक रूप से सुलभ हो
    https://www.nature.com/articles/s44222-025-00323-4

    • JJ के बारे में भी यही समस्या थी। मैं नहीं चाहता कि कमिट्स के बीच की हर चीज़ version control में जाए
      यह भी पक्का नहीं कि कमिट्स के बीच की हर intermediate state प्रासंगिक या उपयोगी होती है। लेकिन लगता है कि मैं अल्पमत में हूँ
    • इसलिए मैं PR से पहले rebase इस्तेमाल करता हूँ, और squash पसंद नहीं है। 2 साल बाद यह याद नहीं रहेगा कि उस कोड को मैंने वैसा क्यों लिखा था, और bug को समझने तथा Chesterton's fence जैसी स्थिति पहचानने के लिए हमारे पास delta और commit history के अलावा कुछ नहीं होता
      अगर squash कर दिया जाए, तो संदर्भ में सिर्फ वही 400-line कोड बचता है जो आपने “एक ही बार में” लिखा, और वह feature request जिससे वह कोड जोड़ा गया था। इससे कोई मदद नहीं मिलती
      सबसे खराब व्यक्ति वह था जो नया module लिखते समय तब तक कुछ भी check-in नहीं करता था जब तक वह कुछ हद तक चलने न लगे। शायद यह उसके नाज़ुक अहंकार से भी जुड़ा था, क्योंकि वह अपने कोड के bug पहले बताने के बजाय चुपके से ठीक करता था। वह Kernighan's law को सच साबित करने वाला उलझा हुआ कोड लिखता था, और ऐसा करने के लिए उसके पास 10 साल ज़्यादा अनुभव था। वह अपने कोड को “powerful” कहकर शेखी बघारता था, जो तारीफ़ नहीं बल्कि अशुभ संकेत था। मैंने उसके शुरुआती commit कोड में कई बार bug पकड़े। बस कुछ तो छोड़ जाओ, यही मन होता है
      आपने समस्या मिलने तक जो-तब जो भी आज़माया, उसकी स्वीकारोक्ति करने की ज़रूरत नहीं है। B बिंदु तक पहुँचना संभव है यह जान लेने के बाद, A से B तक की वह कहानी बनाई जा सकती है जो आप बताना चाहते हैं। अगर आपको शुरू से ठीक-ठीक पता होता कि क्या करना है, तो आप जैसे लिखते, उसी तरह commits को फिर से व्यवस्थित कर सकते हैं। जो 90% कोड लिखा और तुरंत मिटा दिया गया, या जो उस narrative को support नहीं करता, उसे फेंक देना चाहिए
      law enforcement में parallel construction नाम की चीज़ होती है। किसी ऐसे तथ्य से आपको पता चल सकता है कि संदिग्ध दोषी है जो अदालत में स्वीकार्य नहीं होगा, लेकिन फिर उसी तथ्य को प्रक्रिया के अनुसार दोबारा खोजा जाता है। जैसे कचरा उठाने वाले दिन उसका कचरा हासिल करना, पड़ोसियों से बात करना, तलाशी वारंट के लिए पर्याप्त circumstantial evidence जुटाना, और फिर उस सबूत को दोबारा पाना
    • लगता है यह मुख्यतः AI agents को ध्यान में रखकर लिखा गया है। यह एक दिलचस्प विचार है जो मैंने पहले भी देखा है, और यह मज़ेदार है कि हर कोई AI के लिए कुछ न कुछ फिर से invent करना चाहता है
      लेकिन मुझे संदेह है, क्योंकि क्या बस एक text file बनाकर उसमें commit references नहीं डाले जा सकते? यह भी समझ नहीं आता कि Fossil क्यों न इस्तेमाल करें। वह SQLite database है, इसलिए उसमें पहले से ही मनचाही चीज़ें बाँधी जा सकती हैं, और commit को reference करने वाले हर तरह के features built-in हैं
    • collaboration वाला हिस्सा मुझे संदिग्ध लगता है, लेकिन यह enterprise customers के लिए feature जैसा सुनाई देता है, इसलिए मंशा समझ में आती है
    • पूरी तरह सहमत। surveillance जैसा एहसास बेहद अप्रिय है। खासकर यह हिस्सा: “DeltaDB काम को granular delta stream में तोड़ता है. जहाँ Git हर commit का snapshot capture करता है, वहीं DeltaDB उनके बीच के हर action को capture करता है और हर एक को stable identifier देता है”
      सुना था कि Zed में emacs keymap आ गया है, तो सोचा था एक बार आज़माऊँ, लेकिन अब नहीं। यह बहुत ही भयानक रूप से दखल देने वाला feature है, और मैं बिल्कुल नहीं चाहता कि review के लिए सार्वजनिक किए गए commit तक पहुँचने से पहले के हर intermediate edit को सहकर्मी keystroke स्तर पर जाँचें
      PR डालने से पहले मैं कभी-कभी magit में commit history को थोड़ा साफ़-सुथरा कर देता हूँ ताकि वह ज़्यादा linear और समझने में आसान हो। जैसे explanation ठीक करना या पास-पास के commits को मिला देना। लेकिन यह feature उस काम के एक पूरे पहलू को ही फेंक देता है, और मानो कहता है, “सहकर्मी, यह delta का firehose लो और मज़ा करो”
      “हम जो सच में चाहते हैं वह सरल है। agents के साथ बातचीत ही आपके लिए ज़रूरी एकमात्र बातचीत बन जाए” — इसका आख़िर मतलब क्या है? नहीं, यह गलत है

  • Anthropic या OpenAI द्वारा Zed का अधिग्रहण होना लगभग तय-सा लगता है, और यह सोचकर बेचैनी होती है। आइडिया बहुत अच्छा है और software भी बहुत अच्छा है

    • Zed का coding harness, Claude Code से कहीं बेहतर है, लेकिन क्योंकि वह सीधे Claude API इस्तेमाल करता है, इसलिए काफ़ी महँगा भी है। अगर वह उसी product family में आ जाए, तो शायद product category को परिभाषित करने के स्तर तक पहुँच सकता है
    • Zed पर ही क्यों रुकें? AI कंपनियों ने जो 1 ट्रिलियन डॉलर की funding जुटाई है, वह नाममात्र में data centers के लिए थी, लेकिन जब लागत बढ़ती जाए और completion timeline सामान्य business planning की सीमा से बाहर चली जाए, तो उस पैसे को कहीं और लगाना ज़्यादा efficient होगा। 1 ट्रिलियन डॉलर से आप जो चाहें खरीद सकते हैं
    • Anthropic या OpenAI जहाँ जाना चाहते हैं, वहाँ शायद अब editor बचता ही नहीं। निजी तौर पर, मैं बेहतर read-only code tools चाहता हूँ, या फिर UML की वापसी

  • अभी इस क्षेत्र में प्रतिस्पर्धा कर रहे शुरुआती startup वाकई बहुत ज़्यादा हैं। पिछले कुछ हफ्तों में interview देते हुए मैंने कम-से-कम दो जगहों से बात की है
    अगर इन tools को बड़े पैमाने पर सफल होने लायक जगह बनानी है, तो प्रतिस्पर्धा बहुत तीखी होगी। लेकिन यह विचार दिमाग से नहीं निकलता कि यह सब मिलकर developer surveillance को उस स्तर तक संभव बनाता है, जिससे मैं बहुत असहज महसूस करता हूँ

    • अगर कोई manager अपने अधीन हर developer की हर keystroke देखने में ही सारा समय खर्च कर दे, तो इसका मतलब है कि उसके पास करने के लिए असली काम या ध्यान देने लायक business problems बहुत कम हैं

  • commits उपयोगी इसलिए होते हैं क्योंकि उन्हें पहले से व्यवस्थित किया गया होता है। उनके बीच का trial and error वह जगह है जहाँ कुछ आज़माया जाता है और dead ends मिटा दिए जाते हैं, और उसका ज़्यादातर हिस्सा फेंक दिया जाना चाहिए
    अगर हर बदलाव और agent messages को सहेज लिया जाए, तो वह कचरा बस बना रहेगा

  • Google शायद citc के साथ यह काम लगभग 10 साल पहले से कर रहा है। Gemini वास्तव में इसका इस्तेमाल कब करेगा, पता नहीं, लेकिन Google के पास कम-से-कम 10 साल से लगभग हर developer का रिकॉर्ड Ctrl-S स्तर पर लगभग पूरा मौजूद है
    अगर Gemini अभी बेवकूफ-सा दिखता है, तो सिर्फ इसलिए कि वह compute resource allocation बचा रहा है
    0 - https://en.wikipedia.org/wiki/Piper_(source_control_system)

  • यहाँ value proposition क्या है, यह समझ नहीं आ रहा। मैंने कई कंपनियों को मोटे तौर पर ऐसी सुविधा प्रस्तावित करते देखा है, लेकिन किसी ने भी यह तकनीक क्यों मौजूद होनी चाहिए, इसका कोई ठोस और भरोसेमंद कारण नहीं दिया

    • यह दिलचस्प है कि आपका अनुभव और workflow मेरे अनुभव से इतना अलग है। यह एक ऐसी सुविधा है जो दावा करती है कि यह उस वास्तविक समस्या को हल करती है जिससे मैं हर दिन जूझता हूँ
      हमारी कंपनी पूरी तरह remote है, और मेरे सहकर्मी ज़्यादातर मेरे पास नहीं रहते। हम दिन में कुछ बार video chat पर मिलते हैं, लेकिन ज़्यादातर बातचीत Slack पर होती है
      हम अच्छे code लिखवाने के लिए LLM agent अपनाने की प्रक्रिया में भी काफ़ी आगे हैं। अच्छे models और एक खास coding harness में बहुत अच्छे safeguards की वजह से आजकल LLM हमारे code का ज़्यादातर हिस्सा लिखता है
      आम तौर पर मैं दिन की शुरुआत एक ticket उठाकर उसे LLM को दिखाने और साथ मिलकर समस्या सुलझाने से करता हूँ। हम architecture से जुड़े फ़ैसले लेते हैं, plan बनाते हैं, और उसे execute करते हैं। मैंने हाल में जो feature deploy किया, उसकी token cost 19 डॉलर थी, और काम के चरम पर LLM बिना मेरे किसी input के लगभग 30 मिनट तक लगातार काम करता रहा
      जब मुझे यह यक़ीन न हो कि कौन-सी दिशा बेहतर है, तभी मैं team chat में सवाल डालकर सहकर्मियों की राय लेता हूँ। लेकिन बहुत-से tickets पूरी तरह autonomous तरीके से पूरे हो जाते हैं
      उसके बाद मैं PR खोलता हूँ और review माँगने के लिए Slack पर PR link डालता हूँ, और तभी मेरे सहकर्मी पहली बार implementation देखते हैं। कभी-कभी वे सवाल पूछते हैं। तेज़ real-time बातचीत के लिए GitHub comments उतने उपयुक्त नहीं होते, इसलिए वे अक्सर PR comments की बजाय Slack thread में सवाल डालते हैं
      उन सवालों के जवाब मेरे laptop पर मौजूद LLM के chat log में होते हैं, लेकिन उन्हें सहकर्मियों को आसानी से दिखाने का कोई तरीका नहीं है। इसलिए मुझे सहकर्मियों के सवाल Slack से LLM chat में copy करने और जवाब फिर वापस paste करने वाला telephone game खेलना पड़ता है
      यह विचार कि मेरे सहकर्मी, LLM और मैं एक ही बातचीत में कहीं ज़्यादा आसानी से शामिल हो सकें, बहुत आकर्षक है
      इसका मतलब यह नहीं कि Zed team सही दिशा में है, और हो सकता है कि अगर हमारी team किसी और तरीके से काम करे तो वह बेहतर हो। लेकिन मौजूदा approach इतनी “सफल” है कि उसे संगठनात्मक रूप से बदलने का ज़्यादा दबाव नहीं है

  • software team का काम यह है कि वह मिलकर ऐसे models सीखे जो किसी domain में प्रभावी ढंग से काम करें। फिर उन models और सीखी गई बातों को code, tests, और संबंधित documentation के रूप में व्यक्त करे
    इसलिए एक तरफ़ मैं पूरी तरह सहमत हूँ कि pull requests और code review इस प्रक्रिया को घातक रूप से बाधित करते हैं, लेकिन साथ ही यह सोचकर हिचक भी होती है कि हम तुरंत कोई और द्वितीयक प्रक्रिया और artifacts बना लें जो हमें और भटका दें। यह सब codebase में ही दिखाई देना चाहिए
    किसी अलग चीज़ में नहीं। न commit messages के किसी ढेर में, न ADRs के किसी संग्रह में। अगर codebase इंसानों और AI दोनों के लिए अपने-आप यह पूरी तरह नहीं समझा पाता कि क्या और क्यों, तो वह असफल है, और उस असफलता को संभालने के लिए हम जीवन भर और प्रक्रियाएँ बनाते रहेंगे

    • features और experiments के लिए cheap branching, किसी खास commit को जल्दी से revert कर पाने की क्षमता, और यह पढ़ पाना कि code की किसी एक line को आख़िरी बार बदले जाने पर commit message क्या था — ये सब बेहद महत्वपूर्ण हैं, और distributed version control system ने इन्हें संभव बनाया है
      सिर्फ़ code की वर्तमान स्थिति आधुनिक software development के लिए काफ़ी नहीं है