सिर्फ ऐसे मौकों पर ही इनकी सोच मिलती है।
Open को अपने नाम में रखकर भी बेशर्मी से व्यवहार करने वाली OpenAI हो या
यह कहकर अलग हुई Anthropic कि OpenAI बदल गई है,
पता नहीं यह सब पैसे की वजह से है, या AI को वर्चस्व की लड़ाई मानकर सरकार दखल दे रही है और मैनेजमेंट को अपने इशारों पर नचा रही है।
मुझे लगता है कि 3वां बिंदु (एजेंट्स के बीच जिम्मेदारी का विभाजन) सबसे कठिन हिस्सा है। मैंने कभी कुछ public benchmark traces देखे थे, और वहाँ दिखा एक पैटर्न साझा कर रहा हूँ.
सबसे आम चीज़ "गलत निर्णय" से ज़्यादा यह थी कि एक ही काम दो बार execute हो रहा था। जैसे वही parameters देकर email बार-बार भेजना, या वही file फिर से लिख देना। खासकर timeout के बाद retry वाले हिस्से में यह अक्सर दिखा। यानी पहली call बस धीमी थी, लेकिन उसे failure मानकर फिर से बुला लिया गया।
इसे track करना मुश्किल इसलिए है क्योंकि error आता ही नहीं। दोनों बार 200 होता है और logs भी साफ रहते हैं, इसलिए बाद में सिर्फ logs देखकर यह दिखता नहीं।
हम जो तरीका इस्तेमाल करते हैं, वह है (tool, normalized arguments, output hash) के आधार पर group करके यह mechanically गिनना कि वही combination कितनी बार दोहराया गया। इसमें LLM judgment की ज़रूरत नहीं पड़ती, सिर्फ computation से काम हो जाता है, इसलिए यह reproducible भी है। लेकिन इसकी सीमा साफ है: इससे सिर्फ इतना पता चलता है कि "दो बार call हुआ", यह नहीं कि "वास्तव में दो बार execute हुआ या नहीं"। जिन tools के response में entity ID मिलता है (जैसे document creation API), उनमें ID compare करके verify किया जा सकता है, लेकिन email जैसे tools जो सिर्फ "send success" लौटाते हैं, उनमें कोई तरीका नहीं मिला।
आपने 2वें बिंदु में जो कहा कि "speed के लिए बस pass होने देना", उससे भी मैं सहमत हूँ। हमने भी real-time में block करने पर विचार किया था, लेकिन execution से पहले result दिखता नहीं, इसलिए सिर्फ arguments के आधार पर निर्णय लेना पड़ता है, और उसकी accuracy कम थी। कई बार normal retries भी block हो जाती थीं, इसलिए हमने वह विचार छोड़ दिया।
बग फिक्स करना भी काफी सस्ता हो गया है, और software update की लागत भी लगभग 0 के करीब पहुंच रही है। ऊपर से finance sector जैसी सख्त जगहों को छोड़ दें तो अक्सर bug हो तो बस ठीक कर देने से काम चल जाता है...
लेकिन ऐसी सोच जमा होती रहे तो आखिरकार कोई बड़ा हादसा हो ही जाएगा।
इस्तेमाल करके देखें, और अगर Jumpback बातचीत में ठीक से काम न करे या कहीं लगे कि "यह थोड़ा असुविधाजनक है", तो बेझिझक कमेंट छोड़ दें। हर साइट की बातचीत की संरचना अलग होती है, इसलिए असली उपयोग के उदाहरण सबसे ज़्यादा मददगार होते हैं। आगे मैं Perplexity support और Notion/Obsidian export देख रहा हूँ, लेकिन अगर उससे भी ज़्यादा ज़रूरी कुछ है तो पहले वही करने की सोच रहा हूँ haha
धन्यवाद। इस्तेमाल करके देखें, और अगर किसी बातचीत में जंपबैक ठीक से कैच न हो तो आराम से बता दीजिएगा~
मैं भी इसे इस्तेमाल कर रहा हूँ, लेकिन अच्छा होगा अगर असली यूज़र्स की परेशानियाँ भी साथ में सुन सकूँ, haha
जब भी agent कोई बदलाव करे, उसके diff logs को observe करके अगर वह shotgun surgery या बड़ी मात्रा में changes कर रहा हो, तो उसे SE की bad smell मानकर reinforcement learning करना संभव लगता है...
[आपको पढ़ने में असुविधा न हो, इसलिए मैंने README का Korean अनुवाद लिख दिया है!]
Clew
एजेंट ट्रेस में बेकार हुए काम को खोजने वाला एक deterministic detector।
Clew पूरी हो चुकी AI एजेंट execution traces को पढ़कर ऐसे steps ढूंढता है जिन्होंने पहले से किए गए काम को दोहराया हो — उसी tool को उसी arguments के साथ फिर से call करना, failed call को उसी arguments के साथ retry करना, context में पहले से मौजूद जानकारी को फिर से query करना। यह LLM judgment के बिना काम करता है, इसलिए वही trace देने पर हर बार वही result मिलता है।
estimated cost impact: $0.026340 ~ $0.263400 (cache-hit to cache-miss)
यह क्यों महत्वपूर्ण है
AI coding agent sessions में यह बर्बादी सिर्फ bill आने पर दिखती है। सभी tool calls 200 return करते हैं, और कुछ भी error नहीं देता, इसलिए बर्बादी दिखती नहीं है। लेकिन trace के अंदर एजेंट एक ही file को दो बार पढ़ता है, failed call को उसी arguments के साथ retry करता है, और उसी tool को उसी payload के साथ फिर से बुलाता है।
क्योंकि coding agent sessions में read operation tokens का 65~90% हिस्सा ले लेते हैं, ऐसी बर्बादी बिना ध्यान दिए जमा होती रहती है। observability tools traces तो दिखाते हैं, लेकिन कौन-सा step duplicate था यह नहीं बताते।
क्या detect करता है
Clew तीन तरह के duplicate patterns ढूंढता है:
repeat — वही tool/node बार-बार call होता है
requery — वही tool उसी input के साथ फिर से call होता है (output समान)
pingpong — दो एजेंट लगभग वही सामग्री एक-दूसरे को भेजते हैं (multi-agent)
हर finding को चार श्रेणियों में वर्गीकृत किया जाता है:
error_repeat — output error है, लेकिन वही call दोहराई जाती है
side_effect — state बदलने वाले tools (send/write/create आदि) को फिर से चलाना
idempotent — read-only/declarative tools को दोहराना (side effect नहीं, पर tokens खर्च होते हैं)
unclassified — mapping में नहीं आने वाले tools। effect payload पर निर्भर करता है, इसलिए सिर्फ tool name से अनुमान नहीं लगाया जाता (Bash/PowerShell आदि)
[यह कैसे काम करता है]
यह 2-stage cascade है:
structure gate — उसी tool को उन्हीं (normalized) arguments के साथ call किए गए मामलों को group करता है
identity gate — जांचता है कि output का sha256 पूरी तरह match करता है या नहीं। अलग होने पर state बदल चुकी मानी जाती है, इसलिए flag नहीं किया जाता
सस्ता structural check पहले candidates छांटता है, और महंगा semantic check (embedding+cosine) सिर्फ जरूरत पड़ने पर चलता है। LLM judgment न होने से results deterministic रहते हैं — अगर इसे CI में डालना हो तो यह महत्वपूर्ण है।
[input formats]
Claude Code — session JSONL को सीधे analyze करता है
LangGraph — trace में chain duplication detect करता है
LangChain·CrewAI·AutoGen·LlamaIndex आदि — OpenTelemetry/OpenInference standard format में instrumented traces को parse करता है (format support है, framework-specific empirical validation अभी चल रही है)
public benchmark traces (Toolathlon, RedundancyBench)
Cursor और Codex sessions अभी supported नहीं हैं — local formats की समीक्षा चल रही है।
[validation results]
public benchmark (Toolathlon, 6,780 traces, 176,270 tool spans):
8,042 duplicate calls detect हुईं। इनमें 47% gray area थीं (idempotent operations, completion declarations), और इन्हें हटाने पर 4,251 बचती हैं (tool spans के मुकाबले 2.41%)। यह Claude Code sessions (0.80%) की तुलना में लगभग 3 गुना है।
state-changing tools के 1,343 duplicate executions detect हुए, जिनमें 459 बार वही email उसी arguments के साथ बार-बार भेजी गई। हालांकि, यह सिर्फ इतना detect करता है कि वही tool उसी arguments के साथ duplicate call हुआ; actual side effect हुआ या नहीं, इसकी पुष्टि नहीं हुई है।
labeling benchmark (RedundancyBench):
precision 0.826 (file के भीतर duplication के लिए lower-bound estimate)। RB labels का बड़ा हिस्सा cross-file duplication है, जो session-level analysis design के दायरे से बाहर है। recall 0.157 है, जो कम है।
[ईमानदार सीमाएँ]
मापी गई savings का अभी कोई case नहीं है। detect और estimate तो किया जा सकता है, लेकिन किसी real user ने कुछ सुधारकर bill वास्तव में कम किया हो, ऐसा before/after data 0 है।
benchmark में flag हुई चीज़ों में 47% gray area हैं (idempotent re-execution)। इन्हें filter नहीं किया जाता, सिर्फ classify किया जाता है — क्योंकि read-only re-execution सच में waste थी या नहीं, यह ऐसे context पर निर्भर करता है जो दिखाई नहीं देता।
क्योंकि sha256 का exact match जरूरी है, output थोड़ा भी अलग हो तो flag नहीं किया जाता। recall कम होने का यही कारण है, और design precision की तरफ झुका हुआ है।
Claude Code असामान्य रूप से अच्छी तरह optimized है। actual CC sessions में छह candidate waste patterns मापे गए थे, जिनमें से पाँच वहाँ मौजूद ही नहीं थे। दिलचस्प बर्बादी CC में नहीं, बल्कि multi-tool MCP environments में दिखी।
cost estimation (amplification) measurement नहीं, estimation है, और यह सिर्फ Claude Code format में संभव है।
जो validate नहीं होता, उसे हटा दिया जाता है
मैंने file re-read detector बनाया था, लेकिन 30-sample human annotation में उसकी precision pre-registered threshold (70%) से काफी नीचे निकली (उदारता से देखें तो 3.3%, सख्ती से देखें तो 0%), इसलिए उसे हटा दिया गया। prediction और results दोनों pre-registration document में साथ छोड़े गए हैं।
लेखक की अपडेट है। मैंने उस MCP server हिस्से पर, जिसका मुख्य लेख में सिर्फ एक लाइन में ज़िक्र था, अलग से एक पोस्ट डाली है — जब agent migration लिखता है तो column name अपने मन से बना देने की समस्या को, physical name को "input" नहीं बल्कि शब्दकोश-आधारित "calculation" में बदलकर हल करने वाली संरचना है: https://sqemo.com/blog/erd-mcp-server
(अभी यह सिर्फ stdio local तक सीमित है, इसलिए remote MCP समर्थित नहीं है; app का मुख्य भाग non-public है और केवल MCP server open है).
इसे बिना signup के तुरंत आज़मा सकते हैं (app.sqemo.com), इसलिए अगर कहीं कोई दिक्कत लगे तो comment करें — अभी शुरुआती चरण है, इसलिए feedback तुरंत लागू किया जाता है.
पहली पोस्ट के बाद से, मैंने Repolis को एक साधारण 3D repo ब्राउज़र से आगे बढ़ाकर एक ऐसे छोटे कस्बे की दिशा में लगातार विस्तार दिया है, जहां फिर से आने की वजह हो।
GitHub traffic और public repo की जानकारी रोज़ इमारतों और रात की lighting में दिखती है।
Starlight Row जोड़ा गया है, जिसमें 8 निवासी और उनके अपने घर हैं, साथ ही दिन/रात की lifestyle routines और निवासियों की छोटी सैर व बातचीत भी।
Explorer Passport, Village Chronicle, Town Gazette के ज़रिए visit history और नए repo, release, push व metrics में बदलाव लगातार देखे जा सकते हैं।
threejs-sculpt-dna Copilot plugin से बनाया गया procedural World Tree वास्तविक Repolis शहर में लगाया गया है।
default अब भी backend और key के बिना चलने वाला zero-build static app है, और grounded AI taxi/scholar features सिर्फ़ optional हैं।
नई पोस्ट बनाने के बजाय, आगे के बदलाव भी इसी मूल पोस्ट के comment में रिकॉर्ड करता रहूंगा।
Mac के कोरियाई कीबोर्ड पर इसे टाइप नहीं कर सकते T Claude जवाब देते समय यह निशान ज़्यादा इस्तेमाल करता लगता है, लेकिन कोरियाई यूज़र्स के लिए यह परिचित नहीं है...
मैं लेखक हूँ। कुछ बातें जो मुख्य लेख में शामिल नहीं हो सकीं, यहाँ जोड़ रहा हूँ —
· डेमो वीडियो (फोन approval flow, desktop 3-way command center) लैंडिंग पेज पर वास्तविक कैप्चर के साथ हैं: adhf.dev
· self-hosting के लिए बस एक लाइन npm i -g adhdev, और localhost:3847 पर dashboard खुल जाता है (अकाउंट की ज़रूरत नहीं)
· ff-only merge डिज़ाइन या MAGI cross-validation वास्तव में क्या पकड़ता है जैसे डिज़ाइन सवालों का स्वागत है
आजकल लोग technical debt नहीं, बल्कि cognitive debt की बात करते हैं.
कभी-कभी सहकर्मियों से बात करते हुए ऐसा भी देखने को मिलता है कि उन्होंने खुद ही कुछ बनाया है, फिर भी वे ठीक से नहीं समझ पाते कि वह कैसे काम करता है—यह थोड़ा सिहराने वाला लगता है.
ऐसे-ऐसे समय बीतने पर शायद हालत यह हो जाएगी कि कोई भी उसके काम करने का तरीका नहीं समझेगा, लेकिन फिर यह भी लगता है कि AI से analysis कराकर उससे पूछ लिया जाए तो शायद यह कोई समस्या ही न रहे.
सिर्फ ऐसे मौकों पर ही इनकी सोच मिलती है।
Open को अपने नाम में रखकर भी बेशर्मी से व्यवहार करने वाली OpenAI हो या
यह कहकर अलग हुई Anthropic कि OpenAI बदल गई है,
पता नहीं यह सब पैसे की वजह से है, या AI को वर्चस्व की लड़ाई मानकर सरकार दखल दे रही है और मैनेजमेंट को अपने इशारों पर नचा रही है।
छी...
शिक्षा बेचकर पैसा कमाना सबसे ज़्यादा cost-effective है। न कोई ज़िम्मेदारी होती है, बस फीस वसूली जाती है। AI ऐसे धंधे में बड़ा हिस्सा लेगा।
कुछ साल पहले देखा था ऐसा लगता है
पहले मूल साइट पर गया, तो देखा कि समझाने के लिए इमेज इस्तेमाल की गई हैं, इसलिए intuitively समझना आसान है।
सैर या पढ़ने जैसी ऑफलाइन गतिविधियाँ बढ़ाएँगे तो सुधार होगा।haha
मुझे लगता है कि 3वां बिंदु (एजेंट्स के बीच जिम्मेदारी का विभाजन) सबसे कठिन हिस्सा है। मैंने कभी कुछ public benchmark traces देखे थे, और वहाँ दिखा एक पैटर्न साझा कर रहा हूँ.
सबसे आम चीज़ "गलत निर्णय" से ज़्यादा यह थी कि एक ही काम दो बार execute हो रहा था। जैसे वही parameters देकर email बार-बार भेजना, या वही file फिर से लिख देना। खासकर timeout के बाद retry वाले हिस्से में यह अक्सर दिखा। यानी पहली call बस धीमी थी, लेकिन उसे failure मानकर फिर से बुला लिया गया।
इसे track करना मुश्किल इसलिए है क्योंकि error आता ही नहीं। दोनों बार 200 होता है और logs भी साफ रहते हैं, इसलिए बाद में सिर्फ logs देखकर यह दिखता नहीं।
हम जो तरीका इस्तेमाल करते हैं, वह है (tool, normalized arguments, output hash) के आधार पर group करके यह mechanically गिनना कि वही combination कितनी बार दोहराया गया। इसमें LLM judgment की ज़रूरत नहीं पड़ती, सिर्फ computation से काम हो जाता है, इसलिए यह reproducible भी है। लेकिन इसकी सीमा साफ है: इससे सिर्फ इतना पता चलता है कि "दो बार call हुआ", यह नहीं कि "वास्तव में दो बार execute हुआ या नहीं"। जिन tools के response में entity ID मिलता है (जैसे document creation API), उनमें ID compare करके verify किया जा सकता है, लेकिन email जैसे tools जो सिर्फ "send success" लौटाते हैं, उनमें कोई तरीका नहीं मिला।
आपने 2वें बिंदु में जो कहा कि "speed के लिए बस pass होने देना", उससे भी मैं सहमत हूँ। हमने भी real-time में block करने पर विचार किया था, लेकिन execution से पहले result दिखता नहीं, इसलिए सिर्फ arguments के आधार पर निर्णय लेना पड़ता है, और उसकी accuracy कम थी। कई बार normal retries भी block हो जाती थीं, इसलिए हमने वह विचार छोड़ दिया।
बग फिक्स करना भी काफी सस्ता हो गया है, और software update की लागत भी लगभग 0 के करीब पहुंच रही है। ऊपर से finance sector जैसी सख्त जगहों को छोड़ दें तो अक्सर bug हो तो बस ठीक कर देने से काम चल जाता है...
लेकिन ऐसी सोच जमा होती रहे तो आखिरकार कोई बड़ा हादसा हो ही जाएगा।
इस्तेमाल करके देखें, और अगर Jumpback बातचीत में ठीक से काम न करे या कहीं लगे कि "यह थोड़ा असुविधाजनक है", तो बेझिझक कमेंट छोड़ दें। हर साइट की बातचीत की संरचना अलग होती है, इसलिए असली उपयोग के उदाहरण सबसे ज़्यादा मददगार होते हैं। आगे मैं Perplexity support और Notion/Obsidian export देख रहा हूँ, लेकिन अगर उससे भी ज़्यादा ज़रूरी कुछ है तो पहले वही करने की सोच रहा हूँ haha
धन्यवाद। इस्तेमाल करके देखें, और अगर किसी बातचीत में जंपबैक ठीक से कैच न हो तो आराम से बता दीजिएगा~
मैं भी इसे इस्तेमाल कर रहा हूँ, लेकिन अच्छा होगा अगर असली यूज़र्स की परेशानियाँ भी साथ में सुन सकूँ, haha
जब भी agent कोई बदलाव करे, उसके diff logs को observe करके अगर वह shotgun surgery या बड़ी मात्रा में changes कर रहा हो, तो उसे SE की bad smell मानकर reinforcement learning करना संभव लगता है...
[आपको पढ़ने में असुविधा न हो, इसलिए मैंने README का Korean अनुवाद लिख दिया है!]
Clew
एजेंट ट्रेस में बेकार हुए काम को खोजने वाला एक deterministic detector।
Clew पूरी हो चुकी AI एजेंट execution traces को पढ़कर ऐसे steps ढूंढता है जिन्होंने पहले से किए गए काम को दोहराया हो — उसी tool को उसी arguments के साथ फिर से call करना, failed call को उसी arguments के साथ retry करना, context में पहले से मौजूद जानकारी को फिर से query करना। यह LLM judgment के बिना काम करता है, इसलिए वही trace देने पर हर बार वही result मिलता है।
pip install "clew-custos[detect]"python -m clew analyze ~/.claude/projects/<slug>/<uuid>.jsonl --out report.mdpublic Claude Code sessions पर चलाए गए actual output का उदाहरण:
Result: WASTE DETECTED
1. requery — Read on
.../boot.tsयह क्यों महत्वपूर्ण है
AI coding agent sessions में यह बर्बादी सिर्फ bill आने पर दिखती है। सभी tool calls 200 return करते हैं, और कुछ भी error नहीं देता, इसलिए बर्बादी दिखती नहीं है। लेकिन trace के अंदर एजेंट एक ही file को दो बार पढ़ता है, failed call को उसी arguments के साथ retry करता है, और उसी tool को उसी payload के साथ फिर से बुलाता है।
क्योंकि coding agent sessions में read operation tokens का 65~90% हिस्सा ले लेते हैं, ऐसी बर्बादी बिना ध्यान दिए जमा होती रहती है। observability tools traces तो दिखाते हैं, लेकिन कौन-सा step duplicate था यह नहीं बताते।
क्या detect करता है
Clew तीन तरह के duplicate patterns ढूंढता है:
repeat — वही tool/node बार-बार call होता है
requery — वही tool उसी input के साथ फिर से call होता है (output समान)
pingpong — दो एजेंट लगभग वही सामग्री एक-दूसरे को भेजते हैं (multi-agent)
हर finding को चार श्रेणियों में वर्गीकृत किया जाता है:
error_repeat — output error है, लेकिन वही call दोहराई जाती है
side_effect — state बदलने वाले tools (send/write/create आदि) को फिर से चलाना
idempotent — read-only/declarative tools को दोहराना (side effect नहीं, पर tokens खर्च होते हैं)
unclassified — mapping में नहीं आने वाले tools। effect payload पर निर्भर करता है, इसलिए सिर्फ tool name से अनुमान नहीं लगाया जाता (Bash/PowerShell आदि)
[यह कैसे काम करता है]
यह 2-stage cascade है:
structure gate — उसी tool को उन्हीं (normalized) arguments के साथ call किए गए मामलों को group करता है
identity gate — जांचता है कि output का sha256 पूरी तरह match करता है या नहीं। अलग होने पर state बदल चुकी मानी जाती है, इसलिए flag नहीं किया जाता
सस्ता structural check पहले candidates छांटता है, और महंगा semantic check (embedding+cosine) सिर्फ जरूरत पड़ने पर चलता है। LLM judgment न होने से results deterministic रहते हैं — अगर इसे CI में डालना हो तो यह महत्वपूर्ण है।
[input formats]
Claude Code — session JSONL को सीधे analyze करता है
LangGraph — trace में chain duplication detect करता है
LangChain·CrewAI·AutoGen·LlamaIndex आदि — OpenTelemetry/OpenInference standard format में instrumented traces को parse करता है (format support है, framework-specific empirical validation अभी चल रही है)
public benchmark traces (Toolathlon, RedundancyBench)
Cursor और Codex sessions अभी supported नहीं हैं — local formats की समीक्षा चल रही है।
[validation results]
public benchmark (Toolathlon, 6,780 traces, 176,270 tool spans):
8,042 duplicate calls detect हुईं। इनमें 47% gray area थीं (idempotent operations, completion declarations), और इन्हें हटाने पर 4,251 बचती हैं (tool spans के मुकाबले 2.41%)। यह Claude Code sessions (0.80%) की तुलना में लगभग 3 गुना है।
state-changing tools के 1,343 duplicate executions detect हुए, जिनमें 459 बार वही email उसी arguments के साथ बार-बार भेजी गई। हालांकि, यह सिर्फ इतना detect करता है कि वही tool उसी arguments के साथ duplicate call हुआ; actual side effect हुआ या नहीं, इसकी पुष्टि नहीं हुई है।
labeling benchmark (RedundancyBench):
precision 0.826 (file के भीतर duplication के लिए lower-bound estimate)। RB labels का बड़ा हिस्सा cross-file duplication है, जो session-level analysis design के दायरे से बाहर है। recall 0.157 है, जो कम है।
[ईमानदार सीमाएँ]
मापी गई savings का अभी कोई case नहीं है। detect और estimate तो किया जा सकता है, लेकिन किसी real user ने कुछ सुधारकर bill वास्तव में कम किया हो, ऐसा before/after data 0 है।
benchmark में flag हुई चीज़ों में 47% gray area हैं (idempotent re-execution)। इन्हें filter नहीं किया जाता, सिर्फ classify किया जाता है — क्योंकि read-only re-execution सच में waste थी या नहीं, यह ऐसे context पर निर्भर करता है जो दिखाई नहीं देता।
क्योंकि sha256 का exact match जरूरी है, output थोड़ा भी अलग हो तो flag नहीं किया जाता। recall कम होने का यही कारण है, और design precision की तरफ झुका हुआ है।
Claude Code असामान्य रूप से अच्छी तरह optimized है। actual CC sessions में छह candidate waste patterns मापे गए थे, जिनमें से पाँच वहाँ मौजूद ही नहीं थे। दिलचस्प बर्बादी CC में नहीं, बल्कि multi-tool MCP environments में दिखी।
cost estimation (amplification) measurement नहीं, estimation है, और यह सिर्फ Claude Code format में संभव है।
जो validate नहीं होता, उसे हटा दिया जाता है
मैंने file re-read detector बनाया था, लेकिन 30-sample human annotation में उसकी precision pre-registered threshold (70%) से काफी नीचे निकली (उदारता से देखें तो 3.3%, सख्ती से देखें तो 0%), इसलिए उसे हटा दिया गया। prediction और results दोनों pre-registration document में साथ छोड़े गए हैं।
लेखक की अपडेट है। मैंने उस MCP server हिस्से पर, जिसका मुख्य लेख में सिर्फ एक लाइन में ज़िक्र था, अलग से एक पोस्ट डाली है — जब agent migration लिखता है तो column name अपने मन से बना देने की समस्या को, physical name को "input" नहीं बल्कि शब्दकोश-आधारित "calculation" में बदलकर हल करने वाली संरचना है:
https://sqemo.com/blog/erd-mcp-server
(अभी यह सिर्फ stdio local तक सीमित है, इसलिए remote MCP समर्थित नहीं है; app का मुख्य भाग non-public है और केवल MCP server open है).
इसे बिना signup के तुरंत आज़मा सकते हैं (app.sqemo.com), इसलिए अगर कहीं कोई दिक्कत लगे तो comment करें — अभी शुरुआती चरण है, इसलिए feedback तुरंत लागू किया जाता है.
अपडेट रिकॉर्ड (2026-07-25)
पहली पोस्ट के बाद से, मैंने Repolis को एक साधारण 3D repo ब्राउज़र से आगे बढ़ाकर एक ऐसे छोटे कस्बे की दिशा में लगातार विस्तार दिया है, जहां फिर से आने की वजह हो।
नई पोस्ट बनाने के बजाय, आगे के बदलाव भी इसी मूल पोस्ट के comment में रिकॉर्ड करता रहूंगा।
Live: https://hyeonsangjeon.github.io/Repolis/
Source: https://github.com/hyeonsangjeon/Repolis
Mac के कोरियाई कीबोर्ड पर इसे टाइप नहीं कर सकते T Claude जवाब देते समय यह निशान ज़्यादा इस्तेमाल करता लगता है, लेकिन कोरियाई यूज़र्स के लिए यह परिचित नहीं है...
मेरे पास भी यह रोल आउट हो गया था, तो मैंने इसे आज़माया.. उफ़, कोरियन अभी तक नहीं है :(
मैं लेखक हूँ। कुछ बातें जो मुख्य लेख में शामिल नहीं हो सकीं, यहाँ जोड़ रहा हूँ —
· डेमो वीडियो (फोन approval flow, desktop 3-way command center) लैंडिंग पेज पर वास्तविक कैप्चर के साथ हैं: adhf.dev
· self-hosting के लिए बस एक लाइन
npm i -g adhdev, औरlocalhost:3847पर dashboard खुल जाता है (अकाउंट की ज़रूरत नहीं)· ff-only merge डिज़ाइन या MAGI cross-validation वास्तव में क्या पकड़ता है जैसे डिज़ाइन सवालों का स्वागत है
फ़ीडबैक देंगे तो मैं तुरंत उसे शामिल कर दूँगा।
मैं तो gpt6 की उम्मीद कर रहा था... opus5 आ गया है, तो क्या अब नया मॉडल नहीं आना चाहिए?
आजकल लोग technical debt नहीं, बल्कि cognitive debt की बात करते हैं.
कभी-कभी सहकर्मियों से बात करते हुए ऐसा भी देखने को मिलता है कि उन्होंने खुद ही कुछ बनाया है, फिर भी वे ठीक से नहीं समझ पाते कि वह कैसे काम करता है—यह थोड़ा सिहराने वाला लगता है.
ऐसे-ऐसे समय बीतने पर शायद हालत यह हो जाएगी कि कोई भी उसके काम करने का तरीका नहीं समझेगा, लेकिन फिर यह भी लगता है कि AI से analysis कराकर उससे पूछ लिया जाए तो शायद यह कोई समस्या ही न रहे.
मुझे ऐसे लेख बहुत पसंद हैं