Copilot का भ्रम - The Copilot Delusion

 (deplet.ing)
37 पॉइंट द्वारा GN⁺ 2025-05-25 | 25 टिप्पणियां | WhatsApp पर शेयर करें
  • यह मानना कि AI coding tools वास्तव में डेवलपर productivity बढ़ाते हैं, एक गलतफ़हमी है
  • ऐसे टूल programming के आनंद और इंसानी गहरी समझ को नुकसान पहुँचाते हैं
  • AI दोहराए जाने वाले code generation में काम आ सकता है, लेकिन context, performance, और nuance में इसकी कमज़ोरी है
  • अत्यधिक निर्भरता डेवलपर की सीखने-समझने की इच्छा और code quality को गिराती है
  • programming पेशे का मूल स्वभाव AI की सुविधा के कारण धीरे-धीरे मिटता जा रहा है, और यह समस्या गंभीर होती जा रही है

प्रस्तावना: AI coding tools को लेकर भ्रम

  • यह लेख मई 2025 तक के AI code generation tools की वास्तविकता पर बात करता है
  • AI की अक्षमता पर बहस समय के साथ कमज़ोर पड़ सकती है, लेकिन programming के मूल स्वभाव और आनंद को नुकसान पहुँचाने की समस्या उल्टे और गंभीर होने की आशंका है

अध्याय 1: मेरा सहकर्मी, प्रोग्रामर

  • लेखक एक ऐसे गैर-पेशेवर डेवलपर के साथ काम करने के अनुभव का उदाहरण देता है जो ग़ैर-जिम्मेदाराना ढंग से code copy-paste करता है, और ऐसे सहकर्मी द्वारा छोड़ी गई performance गिरावट / bug bomb / architecture की अनदेखी जैसी समस्याओं पर ज़ोर देता है
  • ऐसा सहकर्मी बिना testing, profiling, और context की समझ के लगातार code बदलता रहता है, और अंततः टीम की प्रेरणा और सीखने की इच्छा छीन लेता है
  • "Captain Obvious" जैसी उलट स्वीकारोक्ति के ज़रिए लेखक बताता है कि यह वर्णन दरअसल GitHub Copilot, Claude Codex जैसे AI coding tools पर व्यंग्य है
  • असली विमान copilot पूरे system को समझता है, सहयोग करता है और ज़िम्मेदारी लेता है। इसके विपरीत AI Copilot बिना मूलभूत समझ के सिर्फ ऊपरी सतह वाला code छोड़ते हैं
  • "Copilot" नाम उधार लेकर productivity और innovation के दिखावे के साथ इसे हर डेवलपर IDE में ठूँसा जा रहा है

अध्याय 2: Copilot के फ़ायदे

  • AI coding tools पूरी तरह बेकार भी नहीं हैं
  • नए लोग C++ जैसी भाषा के जटिल syntax को साधारण रूप में सीखने या किसी concept को जल्दी देखने के लिए इनसे लाभ उठा सकते हैं
  • brainstorming, context को व्यवस्थित करना, और दोहराए जाने वाले template code जैसे कामों में यह इंसानी intern से तेज़ और कम ग़लतियाँ करने वाला हो सकता है
  • performance/efficiency की चिंता न होना, और बिना आसपास निगरानी के छोड़ देने पर production-quality disaster का जोखिम साफ़ है
  • यह बिना context वाले scaffold/प्रारूप code जल्दी दे सकता है, लेकिन सही design और tuning अब भी इंसानी डेवलपर की ज़िम्मेदारी है

अध्याय 3: डेवलपर के रूप में मैं और AI

  • लेखक "coding करने के अपने आनंद" और खुद बनाकर पाने वाली उपलब्धि को महत्व देता है
  • अगर दोहराए जाने वाले code (boilerplate) AI को दे दिए जाएँ और डेवलपर खुद library/macro implementation करना भी छोड़ दे, तो अंततः उसकी रचनात्मकता और आंतरिक प्रेरणा खत्म हो जाती है
  • FOMO (पीछे छूट जाने का डर) के कारण Copilot पर निर्भर होकर भद्दा और अप्रमाणित code तेज़ी से उगलने की प्रवृत्ति पैदा होती है
  • AI पर निर्भरता असली सीखने, low-level performance और structure की समझ, तथा code quality management के अवसर छीन लेती है
  • "Copilot" नाम बराबरी के सहकर्मी का नहीं, बल्कि थोड़े-से अनुभव वाला gamer विमान उड़ाने लगे, ऐसी कल्पना जैसा है

अध्याय 4: कंप्यूटर एक मशीन है

  • मशीन (hardware) की वास्तविकता, संरचना, और performance characteristics को समझने की क्षमता इंसानों में ही होती है
  • AI के पास असली cache miss, memory layout, profiling, या performance bottleneck के बारे में सीधा intuition या अनुभव नहीं है
  • AI के जवाब context से कटे हुए होते हैं, और जहाँ ठोस optimization चाहिए वहाँ यह बेकार साबित होता है
  • चाहे साधारण CRUD app ही क्यों न बनानी हो, डेवलपर के पास user और system के प्रति शिष्टता और ईमानदार मेहनत होनी चाहिए
  • पेशेवर कौशल और craftsmanship सीधे अनुभव, कठिनाई, और बार-बार सुधार से बनते हैं

अध्याय 5: निष्कर्ष

  • AI coding tools और उनकी आसान उपलब्धता hacker spirit के लुप्त होने का कारण बन रही है
  • लेखक को चिंता है कि उद्योग में अंततः सिर्फ निष्क्रिय users बचेंगे, जिन्हें असली coding/structure/performance में दिलचस्पी नहीं है
  • पहले रात-रात भर IRC, hardware experiments, और low-level exploration जैसी चीज़ों में शुद्ध जिज्ञासा और रचनात्मकता भरी रहती थी
  • अब सिर्फ "AI patch review" दोहराने वाला यांत्रिक काम और उदासीनता बची है
  • लेखक चेतावनी देता है कि context की समझ और वास्तविक क्षमता से रहित code generation उद्योग का मानक बन सकता है, और असली प्रतिभाशाली लोग बाहर धकेले जा सकते हैं

लेख संपादन का इतिहास

  • लेखन तिथि को लेकर एक disclaimer जोड़ा गया
  • HN की राय को ध्यान में रखकर performance आलोचना की सीमा (जटिल system बनाम CRUD) पर रुख स्पष्ट किया गया
  • पढ़ने में आसानी के लिए वाक्य शैली और कुछ प्रतीकों के उपयोग में आंशिक बदलाव किए गए

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

25 टिप्पणियां

 
roxie 2025-05-27

लेख दिलचस्प है, लेकिन अब बहुत-से लेख ऐसे लगते हैं जिनका सार बस इतना है कि “AI का इस्तेमाल न करना भी हर समस्या का हल नहीं है, लेकिन उस पर आँख मूंदकर भरोसा करना और उसके मुताबिक ढल जाना भी अच्छा नहीं है”, इसलिए थोड़ा थकान-सा महसूस होता है..
 
ifmkl 2025-05-26

LLM और AI समय के साथ लगातार बेहतर हो रहे हैं। सिर्फ़ कुछ महीने पहले तक, जैसा कहा जाता था वैसी code consistency की उम्मीद करना लगभग मुश्किल था, लेकिन अब अगर उसी स्पेस में AI से शुरुआती setup के लिए माँगा गया कोड फ़ाइलों के रूप में अपलोड कर दिया जाए, और नया कोड लिखते समय हमेशा मौजूदा code style का पालन करने का निर्देश देकर इस्तेमाल किया जाए, तो यह काफ़ी हद तक consistent कोड लिख देता है।
 
crawler 2025-05-26

> लेखक की पुरानी पोस्टें देखें तो लगता है कि वह गेम डेवलपर हैं
> गेम डेवलपमेंट का ज्ञान या सामग्री LLM बड़े पैमाने पर सीख नहीं पाए हैं, इसलिए CRUD ऐप केस के विपरीत, मुझे लगता है कि मुख्य लेख के लेखक LLM की सीमाओं को ज़्यादा अच्छी तरह महसूस करते हैं

पूरा पढ़ा, और आखिरकार मुझे लगता है कि इसी वजह से लेखक ने थोड़ा पक्षपाती नज़रिया अपना लिया है.
बेशक, मुख्य लेख में जो कहा गया है वह लगभग पाठ्यपुस्तक जैसी बात है, इसलिए सही भी है, लेकिन
मेरा मानना है कि CRUD और फ्रंटेंड, जिनके लिए AI के पास सीखने की बहुत सामग्री है, उनमें यह पहले से ही काफी अच्छा काम कर रहा है.
लगता है कि हमें अपने-अपने domain के भीतर इसे जितना हो सके उतना अच्छी तरह उपयोग करना चाहिए.
 
superscv 2025-05-26

मुझे लगता है कि लेखक के अभिप्रेत अर्थ को समझने में थोड़ी गलतफहमी हुई है.
लेखक का फोकस उस प्रोजेक्ट के performance, stability, maintainability, architecture और code consistency पर है जिसे वह स्वयं मैनेज करते हैं, और खास तौर पर architecture तथा code consistency ऐसे क्षेत्रों में हैं जिनमें मौजूदा LLM वास्तव में बहुत कमजोर हैं.

खासतौर पर web में, डेवलपमेंट में आने वालों की संख्या बहुत अधिक है और 'किसी तरह चल जाए तो ठीक है' वाली सोच भी काफी मजबूत है, इसलिए बहुत बड़ी मात्रा में low-quality code deploy किया गया है. और LLM इन्हीं पर आधारित होकर train हुए हैं, इसलिए इनके outputs की quality हैरान कर देने वाली हद तक गिर जाती है.

बस, GPT से यह कहकर देखिए: 웹 프론트에 넣을껀데 js로 퀵소트 알고리즘 좀 구현해줘। अगर आप उसके output में समस्या नहीं ढूंढ पाते, तो मुझे नहीं लगता कि इस बातचीत का कोई खास मतलब बचेगा.
 
ohnul 2025-05-26

नमस्ते। जिज्ञासा में मैंने यह कहकर देखा: "इसे web front में डालना है, तो js में quicksort algorithm थोड़ा implement करके दो"। लेकिन मुझे देखकर यह समझना मुश्किल हो रहा है कि समस्या क्या है। अगर आप बता दें तो बहुत मदद होगी। पहले से धन्यवाद। https://chatgpt.com/share/68340f9b-b684-8002-8dd5-495d477065cd
 
ohnul 2025-05-26

लगता है लिंक ठीक से काम नहीं कर रहा, इसलिए मैं इसे फिर से आज़मा रहा हूँ। https://chatgpt.com/canvas/shared/68341217ae788191b66a523c948b1a8e
 
superscv 2025-05-26

आपके द्वारा संलग्न दूसरा quickSortInPlace() भी धीमा implementation है।

नीचे दिया गया कोड चलाकर देखिए।

function quickSortInPlace(arr, left = 0, right = arr.length - 1) {
if (left >= right) return;

const pivotIndex = partition(arr, left, right);
quickSortInPlace(arr, left, pivotIndex - 1);
quickSortInPlace(arr, pivotIndex + 1, right);
}

function partition(arr, left, right) {
const pivot = arr[right];
let i = left;

for (let j = left; j < right; j++) {
if (arr[j] < pivot) {
[arr[i], arr[j]] = [arr[j], arr[i]];
i++;
}
}

[arr[i], arr[right]] = [arr[right], arr[i]];
return i;
}

function quickSort(arr) {
if (arr.length <= 1) return arr;

const pivot = arr[arr.length - 1];
const left = [];
const right = [];

for (let i = 0; i < arr.length - 1; i++) {
if (arr[i] < pivot) {
left.push(arr[i]);
} else {
right.push(arr[i]);
}
}

return [...quickSort(left), pivot, ...quickSort(right)];
}

const repeat = 100;
const arrLength = 10000;
const unsortedArray = new Array<number>();
for(let i = 0; i < arrLength; i++)
unsortedArray.push(Math.round(Math.random() * arrLength));

let sorted: Array<number>;

const qb = performance.now();
for(let i = 0; i < repeat; i++)
sorted = quickSort(unsortedArray);
const qe = performance.now();

const rqb = performance.now();
for(let i = 0; i < repeat; i++) {
let copied = [...unsortedArray];
quickSortInPlace(copied);
}
const rqe = performance.now();

console.log(q: ${qe - qb} ::: rq: ${rqe - rqb});
 
superscv 2025-05-26

मूल रूप से, इसे ऐसा कोड कहा जा सकता है जिसमें collection के creation, operation और merge की लागत के प्रति बिल्कुल भी संवेदनशीलता नहीं है। C++ के मामले में, लगभग 10 साल पहले ही MoveConstructor के लिए प्रस्ताव/implementation आ चुके थे, और memory copy से जुड़ी लागत के प्रति हमेशा सतर्क रहना सबसे बुनियादी बातों में से एक है। quick sort अपने mechanism के अनुसार ऐसा algorithm है जो सभी values के index तय कर सकता है, और हर field के लिए random access उपलब्ध कराना बेहतर होता है.

बिना किसी सनकी optimization के भी, सिर्फ ऊपर की बातें लागू कर देने पर आपके दिए गए link वाले तरीके की तुलना में 2 गुना से अधिक performance अंतर आता है।
 
dudlf016 2025-05-27

मैंने इसे सीधे चलाकर देखा, थोड़ा धीमा होने की प्रवृत्ति तो है, लेकिन 2 गुना तक नहीं लगता।

function quickSortInPlace(arr, left = 0, right = arr.length - 1) {  
    if (left &gt;= right) return;  
  
    const pivotIndex = partition(arr, left, right);  
    quickSortInPlace(arr, left, pivotIndex - 1);  
    quickSortInPlace(arr, pivotIndex + 1, right);  
}  
  
function partition(arr, left, right) {  
    const pivot = arr[right];  
    let i = left;  
  
    for (let j = left; j &lt; right; j++) {  
        if (arr[j] &lt; pivot) {  
            [arr[i], arr[j]] = [arr[j], arr[i]];  
            i++;  
        }  
    }  
  
    [arr[i], arr[right]] = [arr[right], arr[i]];  
    return i;  
}  
  
function quickSort(arr) {  
    if (arr.length &lt;= 1) return arr;  
  
    const pivot = arr[arr.length - 1];  
    const left = [];  
    const right = [];  
  
    for (let i = 0; i &lt; arr.length - 1; i++) {  
        if (arr[i] &lt; pivot) {  
            left.push(arr[i]);  
        } else {  
            right.push(arr[i]);  
        }  
    }  
  
    return [...quickSort(left), pivot, ...quickSort(right)];  
}  
  
// =============  
  
function quickSortGPT(arr) {  
    if (!Array.isArray(arr)) {  
        throw new TypeError('quickSort expects an array');  
    }  
    if (arr.length &lt;= 1) return [...arr];  
  
    const pivot = arr[Math.floor(arr.length / 2)];  
    const left = [];  
    const equal = [];  
    const right = [];  
  
    for (const el of arr) {  
        if (el &lt; pivot) left.push(el);  
        else if (el &gt; pivot) right.push(el);  
        else equal.push(el);  
    }  
  
    return [...quickSortGPT(left), ...equal, ...quickSortGPT(right)];  
}  
  
function quickSortInPlaceGPT(arr) {  
    if (!Array.isArray(arr)) {  
        throw new TypeError('quickSortInPlace expects an array');  
    }  
  
    const stack = [[0, arr.length - 1]];  
  
    while (stack.length) {  
        const [lo, hi] = stack.pop();  
        if (lo &gt;= hi) continue;  
  
        const pivotIndex = partitionGPT(arr, lo, hi);  
  
        // Tail‑recursion elimination: push larger partition first  
        if (pivotIndex - 1 - lo &gt; hi - (pivotIndex + 1)) {  
            stack.push([lo, pivotIndex - 1]);  
            stack.push([pivotIndex + 1, hi]);  
        } else {  
            stack.push([pivotIndex + 1, hi]);  
            stack.push([lo, pivotIndex - 1]);  
        }  
    }  
    return arr;  
}  
  
function medianOfThreeGPT(a, b, c) {  
    return (a - b) * (c - a) &gt;= 0 ? a  
        : (b - a) * (c - b) &gt;= 0 ? b  
            : c;  
}  
  
function partitionGPT(arr, lo, hi) {  
    const mid = lo + ((hi - lo) &gt;&gt; 1);  
    const pivotValue = medianOfThreeGPT(arr[lo], arr[mid], arr[hi]);  
  
    while (true) {  
        while (arr[lo] &lt; pivotValue) lo++;  
        while (arr[hi] &gt; pivotValue) hi--;  
  
        if (lo &gt;= hi) return hi;  
  
        [arr[lo], arr[hi]] = [arr[hi], arr[lo]];  
        lo++;  
        hi--;  
    }  
}  
  
function testQuicksort(qs, qsp) {  
    const repeat = 100;  
    const arrLength = 100000;  
    const unsortedArray = new Array();  
    for (let i = 0; i &lt; arrLength; i++)  
        unsortedArray.push(Math.round(Math.random() * arrLength));  
  
    let sorted = [];  
  
    const qb = performance.now();  
    for (let i = 0; i &lt; repeat; i++)  
        sorted = qs(unsortedArray);  
    const qe = performance.now();  
  
    const rqb = performance.now();  
    for (let i = 0; i &lt; repeat; i++) {  
        let copied = [...unsortedArray];  
        qsp(copied);  
    }  
    const rqe = performance.now();  
  
    // दशमलव के बाद 2 अंकों तक  
    const p1 = ((qe - qb) / repeat).toFixed(2);  
    const p2 = ((rqe - rqb) / repeat).toFixed(2);  
    
    console.log(`Quicksort: ${p1} ms, In-place: ${p2} ms`);  
}  
  
function main() {  
    const useGPT = process.argv.includes('--gpt');  
    console.log(`Using ${useGPT ? 'GPT' : 'geekNews'} quicksort implementation.`);  
    if (useGPT) {  
        testQuicksort(quickSortGPT, quickSortInPlaceGPT);  
    } else {  
        testQuicksort(quickSort, quickSortInPlace);  
    }  
}  
  
main();

===
node q.js
Using geekNews quicksort implementation.
Quicksort: 29.55 ms, In-place: 9.94 ms
node q.js
Using geekNews quicksort implementation.
Quicksort: 28.42 ms, In-place: 9.07 ms
node q.js
Using geekNews quicksort implementation.
Quicksort: 26.91 ms, In-place: 9.15 ms
node q.js --gpt
Using GPT quicksort implementation.
Quicksort: 28.73 ms, In-place: 9.22 ms
node q.js --gpt
Using GPT quicksort implementation.
Quicksort: 26.87 ms, In-place: 9.22 ms
node q.js --gpt
Using GPT quicksort implementation.
Quicksort: 27.97 ms, In-place: 9.30 ms
node --version
v22.14.0

bun q.js
Using geekNews quicksort implementation.
Quicksort: 32.05 ms, In-place: 17.39 ms
bun q.js
Using geekNews quicksort implementation.
Quicksort: 30.97 ms, In-place: 17.82 ms
bun q.js
Using geekNews quicksort implementation.
Quicksort: 29.73 ms, In-place: 16.14 ms
bun q.js --gpt
Using GPT quicksort implementation.
Quicksort: 30.61 ms, In-place: 12.63 ms
bun q.js --gpt
Using GPT quicksort implementation.
Quicksort: 31.09 ms, In-place: 12.76 ms
bun q.js --gpt
Using GPT quicksort implementation.
Quicksort: 33.24 ms, In-place: 12.75 ms
bun --version
1.2.14

deno q.js
Using geekNews quicksort implementation.
Quicksort: 32.30 ms, In-place: 6.79 ms
deno q.js
Using geekNews quicksort implementation.
Quicksort: 26.79 ms, In-place: 6.86 ms
deno q.js
Using geekNews quicksort implementation.
Quicksort: 26.09 ms, In-place: 6.85 ms
deno q.js --gpt
Using GPT quicksort implementation.
Quicksort: 27.18 ms, In-place: 7.92 ms
deno q.js --gpt
Using GPT quicksort implementation.
Quicksort: 25.34 ms, In-place: 8.12 ms
deno q.js --gpt
Using GPT quicksort implementation.
Quicksort: 25.39 ms, In-place: 8.09 ms
deno --version
deno 2.3.3 (stable, release, x86_64-pc-windows-msvc)
v8 13.7.152.6-rusty
typescript 5.8.3
 
superscv 2025-05-27

आह.. अब समझ गया कि आपका मतलब क्या है। लगता है आप यह समझ नहीं पाए कि किस चीज़ की किससे तुलना करनी चाहिए.... quick sort algorithm की quicksort और in-place जैसी दो implementation methods नहीं होतीं......

मैंने शुरू से ही इस बात को समस्या बताया था कि array merge built-in होने के बावजूद, ऊपर दिए गए कोड में quickSortGPT() और quickSort() (दोनों ही GPT द्वारा जनरेट किया गया कोड हैं) लिखकर AI users को दिए जा रहे थे.
 
dudlf016 2025-05-27

GPT के जवाब में quickSort और quicSortInPlace दोनों हैं, और टिप्पणी में '[...quickSort(left), ...equal, ...quickSort(right)]' वाले हिस्से की ओर इशारा किया गया था, इसलिए मैंने समझा था कि quickSort की तुलना quickSort से, और quickSortInPlace की तुलना quickSortInPlace से करनी चाहिए, लेकिन शायद ऐसा नहीं है।
 
superscv 2025-05-27

"quickSort तो quickSort के साथ ही" जैसी बात सुनकर मेरा माथा ठनक जाता है।
 
superscv 2025-05-27

कृपया लिखे गए लेख को पढ़ते समय संदर्भ ज़रूर देखें।

मैं अभी अपनी coding skill का बखान नहीं कर रहा हूँ। मैं यह इंगित कर रहा हूँ कि quickSort() जैसे घटिया code, जो अभी उदाहरण के रूप में इस्तेमाल हो रहे हैं, GPT में ऊँची प्राथमिकता के साथ output हो रहे हैं.

अगर आप GPT search कई बार करके देखें, तो कई मामलों में यह अकेले quickSort() function का result दे देता है, और फिर से कहूँ तो quickSort() सिर्फ एक उदाहरण है। काम के उद्देश्य से GPT से code माँगने पर बहुत घटिया quality का code अक्सर output होता है (यह एक paid user का अनुभव है)। अगर developer खुद ऐसी चीज़ों में फर्क करने की क्षमता के बिना हो, तो परियोजना के बिगड़ने की दिशा में जाने की संभावना बहुत अधिक है — इस मुख्य लेख के लेखक की इस राय से सहमत होते हुए मैं इस संदर्भ तक पहुँचा हूँ।

मेरे आसपास भी इस तरह के घटिया code से पुते हुए projects लगातार बढ़ते जा रहे हैं।
 
superscv 2025-05-27

बिल्कुल, तुलना quickSort() और quickSortInPlace() इन दो फ़ंक्शनों के प्रदर्शन की होनी चाहिए........
 
superscv 2025-05-27

???? 2 गुना से लेकर 3~4 गुना तक का अंतर दिखाने वाला नतीजा शेयर करके फिर यह कहना कि शायद 2 गुना तक भी नहीं है, इसका क्या मतलब है?
 
superscv 2025-05-26

return [...quickSort(left), ...equal, ...quickSort(right)];

कोड के इस हिस्से को ध्यान से रखकर सोचिए।
 
roxie 2025-05-27

बहुत कुछ सीखने को मिल रहा है
 
ohnul 2025-05-26

जवाब के लिए धन्यवाद!
 
crawler 2025-05-26

सबसे पहले, मैंने जो "डोमेन के भीतर AI का उपयोग" कहा था, उसमें डिज़ाइन और समन्वय इंसान करता है—यह तो स्वाभाविक बात है...
दरअसल, भले ही पहले ऐसा न रहा हो, लेकिन अब जब हर कोई LLM की सीमाएँ जानता है, तो यह इतनी स्पष्ट बात हो गई है कि इसे अलग से कहने की भी ज़रूरत नहीं लगती।

इसके बाद, आपने जो कहा कि सामान्य लोग जिनके पास development knowledge नहीं है, वे LLM का उपयोग करते हैं—
ऐसा मामला न तो मूल लेख में, न Hacker News में, और न ही मैंने खुद कभी कहा था; लेकिन फिर भी, इस स्थिति में भी यूज़र्स जिस स्तर तक नतीजों से संतुष्ट हो सकें, वहाँ तक बात पहुँच चुकी है।
अगर ऐसा न होता, तो शायद Bolt.new, v0, और Cursor को आज जैसी प्रतिक्रिया नहीं मिल रही होती।
 
superscv 2025-05-26

सारांश,

लेखक: डेवलपर्स को खुद अपनी क्षमता बढ़ानी और उसे बनाए रखना चाहिए। यहाँ तक कि AI ठीक से काम भी नहीं करता।

crawler: अरे? मेरे लिए तो अच्छा काम करता है?

superscv: समस्याएँ बहुत हैं...

crawler: उसे सही तरह से ट्यून करके इस्तेमाल करना चाहिए

superscv: लगता है कि यह मूल लेखक जो संदेश देना चाहता था, उससे बहुत दूर निकल आया है..
 
crawler 2025-05-26

मुझे लगता है कि आप यह ठीक से नहीं समझ पाए कि मैंने लेखक के क्षेत्र का ज़िक्र क्यों किया था और अपने डोमेन का क्या मतलब होता है।
बिना खुद सोचे हर फैसला AI को सौंप देना भी मूर्खता लगती है,
लेकिन इसके ठीक उलट छोर पर मौजूद लोगों को भी मैं अच्छी तरह नहीं समझ पाता।

आखिर में मैं यह पूछना चाहता हूँ कि superscv-ssi, आप क्या सोचते हैं कि coding में LLM का इस्तेमाल कैसे करना बेहतर होगा?
 
superscv 2025-05-26

मैं आमतौर पर ज़्यादा comments नहीं लिखता, लेकिन मैंने इस लेख पर खास तौर पर comment इसलिए किया क्योंकि मैं लेखक की सोच से काफ़ी हद तक सहमत हूँ। मेरा मानना है कि AI या LLM का महत्वपूर्ण होना असली मुद्दा नहीं है; बल्कि किसी भी माहौल में एक developer के तौर पर 'मैं' तैयार रहना चाहिए।

LLM, अपने training source की प्रकृति के कारण, मुख्य रूप से दुनिया भर में फैले online data के औसत के आसपास की जानकारी देता है। (पहले वाला js quicksort इसका प्रमाण है।) इसलिए मैं इसे आमतौर पर इस बात को परखने के लिए इस्तेमाल करता हूँ कि विचारधारा/design के स्तर पर कोई बात सामान्य नज़रिए से कितनी मेल खाती है या उससे कितनी अलग है, या फिर उन बातों पर सवाल पूछने के लिए जिनके बारे में अब तक यह स्पष्ट नहीं था कि किससे पूछा जाए।
 
superscv 2025-05-26

इसके अलावा और बातचीत करने का क्या मतलब है, यह मुझे ठीक से समझ नहीं आता।

अगर मूल रूप से राय यह है कि AI द्वारा जनरेट किया गया कोड कुछ हद तक जोखिम वाले तत्व रख सकता है, इसलिए उसे अच्छी तरह परिष्कृत करके उचित तरीके से इस्तेमाल करना चाहिए, तो मुझे लगता है कि लेखक की इस बात में कौन-सी सोच पक्षपाती है, यह समझा देना पर्याप्त होगा। सारांश में भी इसी तरह का आशय है कि "यह बिना संदर्भ के scaffold/ड्राफ्ट कोड जल्दी उपलब्ध करा सकता है, लेकिन पूर्ण डिज़ाइन और tuning मानव डेवलपर की जिम्मेदारी है"।
 
superscv 2025-05-26

लेखक का संदेश थोड़ा कड़ा लग सकता है, लेकिन अगर आप लेख को ध्यान से पढ़ें, तो बात यह नहीं है कि "AI का उपयोग मत करो"। इसमें इस बात का सुझाव है कि इसका उपयोग कैसे किया जाए, और मुख्य संदेश यह है कि डेवलपर में खुद क्षमता की कमी नहीं होनी चाहिए.

अगर देखें कि लेखक का संदेश इतना कड़ा क्यों महसूस होता है, तो यह उस दृष्टिकोण के जवाब के रूप में बनाया गया है कि copilot के साथ development संभव हो जाएगा (यानि copilot पर development की निर्भरता अधिक होने वाली है)। इसी वजह से उन्होंने डेवलपर्स के लिए ऐसा रुख न अपनाने की बात कुछ तीखे अंदाज़ में रखी, जो उनकी अपनी मौजूदगी के मूल्य को नुकसान पहुँचाए.

लेखक का संदेश भी "AI का उपयोग मत करो" नहीं है, इसलिए अंत में अगर AI का उपयोग करना है, तो बात कहीं न कहीं एक समझौते के बिंदु पर ही आएगी; इस लिहाज़ से, आपने अभी जो जवाब दिया, उसका मूल संदेश भी लगभग उसी से मिलता-जुलता लगता है.

हालाँकि, आपने शुरुआत में जो 'पक्षपाती दृष्टिकोण' वाली बात लिखी थी, उससे सहमत होना मेरे लिए कठिन था, इसलिए पहले यह उत्तर दिया.
 
GN⁺ 2025-05-25
Hacker News की राय

  • अगर आप ऐसा software बनाना चाहते हैं जिसे बिल्कुल चट्टान जैसी मजबूती चाहिए—जैसे pacemaker, missile guidance system, या M1 tank में जाने वाला software—तो AI coding agents को किनारे रखकर खुद सीखने वाली मानसिकता ज़रूरी है
    लेकिन हममें से ज़्यादातर लोग वह सब नहीं बना रहे; हम तो लगभग एक जैसे requirements, बस थोड़ा अलग schema और थोड़ा अलग integration वाले CRUD apps बना रहे हैं
    सच कहें तो हममें से ज़्यादातर जो software बनाते हैं उसमें कुछ भी नया नहीं होता
    कई बार मौजूदा knowledge को फिर से इस्तेमाल करना ही सबसे अच्छा होता है
    मेरे लिए coding agents, पुराने code reuse का एक बहुत बड़ा version हैं
    और जोड़ूँ तो, विडंबना यह लगी कि यह लेख खुद AI द्वारा लिखा हुआ-सा महसूस हुआ

    • मैं तो mission-critical low-level code शुरू से ही नहीं लिखना चाहता
      मैं AI tools को लेखक जितना उपयोगी नहीं मानता, लेकिन “अगर तुम C में system programming नहीं करते तो programmer ही नहीं हो” जैसी बहसों से तंग आ चुका हूँ
      मुझे frontend coding पसंद है
      मैं low-level graphics libraries खुद बनाना भी नहीं चाहता
      मैं वह इंसान नहीं हूँ जो भोर में जागकर hacking करता हो, लेकिन अपने काम के लिए मेरे भीतर जुनून और गर्व है
      मुझे नहीं लगता कि हर किसी को लेखक जैसी चरम मानसिकता रखनी चाहिए
      software market में विविधता होनी चाहिए

    • लेखक की दलील का विरोध करना ठीक है, लेकिन यह कहना कि यह लेख खुद AI ने लिखा है, कुछ ज़्यादा ही है
      लेखक ने जीवंत अभिव्यक्तियाँ, दमदार रूपक, और सच में मज़ेदार हास्य मिलाकर अपनी शैली पूरे लेख में उतार दी है
      इस तरह की writing LLM से अभी के दौर में निकलवाना सच में मुश्किल है
      यह AI नहीं, बल्कि अच्छी writing है
      आप लेख की बातों से सहमत हों या नहीं, लेखन-कौशल मानना पड़ेगा

    • मूल लेख में ऐसा वाक्य भी है
      “शायद आप वह code सीधे नहीं लिखेंगे जो हवाई जहाज़ को आसमान में रखता है, या वह code जो इंसानी जान से सीधा जुड़ा हो। ज़्यादातर लोग नहीं लिखते। लेकिन अगर आप किसी enterprise में बस साधारण CRUD apps ही जोड़ते जा रहे हों, तब भी अंत में उपयोगकर्ता के प्रति सम्मान और गरिमा बनाए रखने की ज़िम्मेदारी आपकी है”
      बात यह है कि चाहे software कितना भी साधारण हो, कम-से-कम बुनियादी जिम्मेदारी तो चाहिए

    • असल में लेखक ने खुद भी AI के कुछ उपयोगी cases माने हैं
      लेखक की मुख्य समस्या यह है कि हम AI को “copilot” कहते हैं, और इससे juniors उस पर ज़रूरत से ज़्यादा भरोसा कर सकते हैं
      असली copilot तो अनुभवी और सहयोगी होना चाहिए, जबकि AI अभी आधे समय एक बेकार साथी जैसा है
      “अभी हम जिज्ञासा और पहल को system के बाहर रख रहे हैं। जो लोग स्वाभाविक रूप से आगे बढ़ सकते थे, वे AI patchsets की review करते-करते ही अपनी आग खो रहे हैं। terminal spreadsheet बन रहा है, debugger ताबूत।”
      लेकिन AI भी आखिरकार एक abstraction ही है
      जैसे लोग GC (garbage collector) जैसी automation के आम हो जाने पर बुनियादी skills खोने की चिंता करते थे, वैसे ही AI को लेकर भी डर है कि बहुत बुनियादी programming/learning skills ही गायब हो सकती हैं
      web developers abstraction की मदद से stack की गहराई जाने बिना भी ज़्यादातर अच्छे sites बना लेते हैं
      लेकिन AI वाला abstraction बहुत जगह से छेददार है, इसलिए बुनियाद जाने बिना भी कुछ हद तक चीज़ें चल सकती हैं
      समस्या यह है कि किसी बिंदु पर पता चलता है कि गंभीर bugs छिपे हुए हैं, और debugging, problem solving, और खुद सीखने की क्षमता ऐसी चीज़ें हैं जिन्हें AI बदल नहीं सकता
      इसलिए चिंता यह है कि अगर AI के सहारे सीखना बहुत आसान हो गया, तो ज़रूरी मूल क्षमताएँ छूट सकती हैं
      आखिरकार, बार-बार भिड़कर और खुद करके ही असली सीख होती है
      अगर AI उसी “सीखने” को भी abstract कर दे, तो लंबे समय में developers की क्षमता कमज़ोर होगी
      बेशक सिर्फ AI इस्तेमाल करने से हर कोई मूर्ख नहीं हो जाएगा, और जो लोग पहल करके सीखते हैं वे आगे भी रहेंगे
      लेकिन कुल मिलाकर ऐसे लोगों का अनुपात घट सकता है
      क्योंकि beginners के लिए “खुद सोचकर बनाना” वाला अनुभव ही गायब हो सकता है
      और AI जैसा abstraction आखिरकार बहुत खाली जगहों वाला है
      नए लोगों को लग सकता है कि AI सब कर दे रहा है, लेकिन अंत में असली programming और debugging skills की ज़रूरत रहती ही है
      इसलिए अगर AI द्वारा बनाए code की समस्याएँ सच में पकड़नी हैं, तो कौशल तो बनाना ही पड़ेगा
      मैं खुद भी AI coding assistants का काफ़ी अच्छा उपयोग कर रहा हूँ
      लेकिन कमियाँ हैं, इसलिए उसे सिर्फ अच्छी चीज़ मानकर नहीं देखना चाहिए—यही मेरा निष्कर्ष है

    • मैंने Google Whisk से अपना छोटा-सा comedy video बनाकर TikTok पर डाला, लेकिन अंदर गया तो चारों तरफ AI-generated content और एक-दूसरे की नकल करते videos ही भरे पड़े थे
      लगा था कि “original creation” में सच में कुछ खास होगा, लेकिन आखिर में हम शायद बहुत आसानी से दोहराए जा सकने वाले प्राणी हैं
      अगर हम रोज़ coding करते हुए videos भी TikTok पर डालें, तब भी वही एक जैसे apps बार-बार दोहरते रहेंगे
      Elon Musk की बात की तरह अब लगता है कि सच में बस Mars जाना ही बाकी रह गया है
      दो साल पहले भी मैंने कहा था कि LLM इतने “hallucination” नहीं करते, और आज भी लोग मानते हैं कि इंसान ज़रूरी है, लेकिन मैं कहना चाहता हूँ कि धीरे-धीरे बात वैसी नहीं रह जाएगी
      दो साल बाद इस बात को फिर याद दिलाना चाहूँगा

  • “मशीनें वास्तविक हैं। silicon, DRAM, L1 cache, false sharing, और branch predictor का सिक्का उछालना—सब वास्तविक है। अगर दिलचस्पी हो तो इनसे जूझा जा सकता है”
    ऐसा वाक्य पढ़कर सच में बहुत समय बाद सुंदरता का अहसास हुआ

    • मुझे भी बिल्कुल यही लगा
      लेखक ने Dave Barry जैसी शैली में इसे इतने मज़ेदार ढंग से लिखा कि मैं कई बार हँस पड़ा
      copilot को लेकर अपनी सहमति वाली बातों को उसने हास्य के साथ बहुत अच्छी तरह व्यक्त किया—यह बात मुझे बहुत पसंद आई

  • software development की चर्चा में अक्सर यह बात छूट जाती है कि सिर्फ “लिखा गया code” ही सब कुछ नहीं है
    अनगिनत trade-offs से गुजरते हुए नतीजे तक पहुँचने की पूरी यात्रा भी उतनी ही अहम है
    किसी junior के साथ थोड़ा जटिल codebase में सिर्फ एक feature बनाने बैठें, तो एक experienced engineer के रूप में आप तुरंत महसूस कर लेते हैं कि आप अनजाने में कितने trade-offs कर रहे हैं
    AI के पास भी trade-offs का कुछ concept है, लेकिन वह अधिकतर observation से सीखा हुआ है
    यह सही है कि वह “अच्छा code लिखने में मदद” कर सकता है, लेकिन आखिर में निर्णय लेना और सोचना इंसान का काम है
    LLM “सोचता” नहीं है
    और AI जितना बेहतर होगा, उतना ही खतरा है कि इंसान सोचना कम करता जाए

  • मुझे Copilot के फायदे और नुकसान दोनों समझ आते हैं
    लेकिन hacker या बचपन के “craftsmanship” वाले रोमांटिक विचार से अलग, engineers हमेशा engineer ही रहे हैं
    आज की core technologies इतनी मेहनत से इसलिए उभरीं क्योंकि उस समय उन कठिनाइयों को हर हाल में हल करना ज़रूरी था
    उस नाटकीय इतिहास को “पहले सब कुछ ऐसे ही होता था” कहकर सामान्य बनाना एक पक्षपाती नज़रिया हो सकता है

    • मैं 20 साल से ज़्यादा समय से कठिन रास्ते से development करने वाला software engineer हूँ, और मुश्किल समस्याएँ हल करना मेरे लिए सौभाग्य भी है और संतोष भी
      साधारण CRUD updates दोहराव भरे और उबाऊ होते हैं, लेकिन कभी-कभी जो सिर खपा देने वाले tasks आते हैं, या जब कॉलेज में सीखी चीज़ें काम आती हैं, और recursive algorithms जैसे अपवाद सामने आते हैं—वे career के रत्न जैसे पल होते हैं
      आगे AI-led SW engineers भी इन अनुभवों की और ज़्यादा कद्र करें, ऐसी उम्मीद है
      AI कभी-कभी जवाब तर्कसंगत दे देगा, लेकिन कभी पूरी तरह अजीब और खतरनाक रूप से गलत भी हो सकता है, इसलिए ऐसे लोगों का होना ज़रूरी है जो जानते हों कि वास्तव में क्या करना है
      जब AIs “hallucination” करें या context की कमी हो, तब अंत में समस्या इंसान को ही सुलझानी पड़ेगी—ऐसी स्थिति हमेशा रहेगी

  • मेरे लिए तुलना का पैमाना pair programming नहीं, बल्कि overseas outsourcing developers हैं
    सच तो यह है कि Copilot, Cursor, और दूसरे AI tools बेहतर इसलिए लगते हैं क्योंकि अब Zoom calls पर अस्पष्ट communication, language barrier, और समझ के फर्क में समय बर्बाद नहीं करना पड़ता
    जैसे “root node के बारे में isChild (boolean return) नाम का function जोड़ दिया गया, लेकिन उसका parent existence check से कोई लेना-देना नहीं” या “API parameter अब अचानक array accept नहीं कर रहा” जैसी outsourcing में बार-बार दिखने वाली स्थितियाँ
    AI के साथ काम करते समय अगर ऐसी समस्या हो भी जाए, तो तुरंत बता सकते हैं कि यह गलत है और क्यों गलत है, और वह जल्दी ठीक भी कर देता है
    इंसानों के साथ होने वाली communication की दिक्कत, गलतफहमी, और समय की बर्बादी यहाँ बहुत कम होती है
    आगे चलकर जिस दिन AI और Jira tickets आसानी से जुड़ गए, उस दिन development का लगभग 80% काम tickets लिखने और supervision की भूमिका में बदल जाएगा
    बेशक इसका मतलब यह नहीं कि engineers की भूमिका खत्म हो जाएगी—Biz teams अच्छे tickets लिखेंगी, यह मानना मुश्किल है, और आखिरकार किसी न किसी को अंतिम जिम्मेदारी लेनी ही होगी
    फिर भी बहुत-सी organizations यह बात भूल जाएँगी, और वहीं से बड़े हादसों की गुंजाइश बनेगी

  • इस लेख से मैंने जो केंद्रीय बात ली, वह यह है
    “हम software की आज की पिछड़ी, फूली हुई, और अति-अमूर्त वास्तविकता को ही सर्वोत्तम मानने लगेंगे। performance को चरम तक निचोड़ने, lean, sharp, और crystal-clear systems बनाने की संस्कृति बस पुरानी कहानी बनकर रह जाएगी”
    चिंता यह है कि 2023 से पहले बने libraries और architecture patterns आगे LLM के training data की रीढ़ बन जाएँगे और वहीं जमकर रह जाएँगे
    लगातार innovation करने के बजाय, पिछले 30 सालों की dependencies और गंदा code हमेशा के लिए चलता रह सकता है
    मुझे तो यह भी डर है कि Javascript जैसी चीज़ें हमेशा जीवित रहेंगी

  • आजकल leadership से हर दिन यह दबाव महसूस हो रहा है कि “हम AI का पर्याप्त उपयोग नहीं कर रहे”, “AI अपनाएँ तो मौजूदा timeline आधी की जा सकती है”
    नए AI tools अपनाने के लिए KPI के नाम पर मजबूर किया जा रहा है, और अगर आप जल्दी adapt न करें तो team downsizing तक की बात होने लगती है
    लगता है दुनिया हद से ज़्यादा पागल हो गई है
    AI को हमेशा “दूसरे लोगों का काम replace करने वाले tool” के रूप में पेश किया जाता है
    असल में AI अच्छा तभी लगता है जब आप किसी और के काम को वास्तव में जाने बिना उसका मूल्यांकन कर रहे हों
    ऐसा लगता है management ने AI नाम का हथौड़ा उठा लिया है और अब दुनिया की हर चीज़ को कील समझ रहा है

    • सच में, management structure को किसी तरह छोटा करने और समय को सचमुच productive कामों पर लगाने का रास्ता ढूँढना होगा
      उम्मीद है कि culture AI इस्तेमाल से ज़्यादा वास्तविक काम और delivery पर केंद्रित हो

    • यह दरअसल AI industry के “hype cycle” का ही pattern है
      जब स्थिति शांत होगी, तब केवल काम के tools और technologies बचेंगे, बाकी ज़्यादातर गायब हो जाएँगे
      कौन-सी चीज़ सच में टिकेगी, यह समझदारी से पहचानना और उस बदलाव पर प्रभाव डाल पाना ही आगे बचे रहने का रास्ता है—और उसी दिशा में मेहनत करनी चाहिए

    • अभी का “जल्दी अपनाओ” वाला दबाव, मेरे जानने वाले engineering/design/technologist के मूल स्वभाव के बिल्कुल उलट है
      पहले तो किसी tool, language, service वगैरह को अपनाने से पहले बहुत सावधानी से देखा जाता था कि यह हमारे case में क्यों फिट बैठता है, इसके फायदे-नुकसान क्या हैं, और उसके आधार क्या हैं
      “हमें इसकी ज़रूरत क्यों है, यह service ज़्यादा तर्कसंगत क्यों है” जैसी policy decision process सामान्य बात थी
      पहले यह जाँचा जाता था कि तकनीक सच में अपनाने लायक है या नहीं, और बाद में उसके performance या adoption efficiency का मूल्यांकन भी होता था
      आज की companies उस स्वस्थ तरीके से दूर जा रही हैं

    • “AI हमेशा दूसरे लोगों का काम replace कर सकता है” वाला भ्रम बहुत ज़्यादा फैल गया है
      सच है कि बहुत-सा काम दोहराव वाला होता है, लेकिन अधिकांश कामों को अच्छी तरह करने के लिए अपनी विशिष्ट बारीकियाँ और सूक्ष्मता चाहिए होती है, और automation के दौरान यही चीज़ें गायब होने का बड़ा खतरा है
      “AI से 80% हो जाए तो काफी है” जैसी बात से मैं सहमत नहीं हूँ
      गलतियाँ पूरे system को प्रभावित करती हैं, और मूल्यांकन करने वाले लोगों के पास अक्सर ground-level experience कम होता है

    • मुझे लगता है कि जल्द ही managerial roles और तेज़ी से गायब होंगे
      तब तक हम सब एक-दूसरे का हौसला बनाए रखें

  • लेखक साफ़ तौर पर C++ developer लगता है
    वास्तव में AI coding assistants का C++ में ठीक से काम करना कम ही दिखता है, और जो लोग इन्हें प्रभावी ढंग से इस्तेमाल करते हैं वे ज़्यादातर scripting languages या CRUD apps में ऐसा करते हैं

    • लेखक की पुरानी posts देखें तो वह game developer लगता है
      game development का knowledge या material LLM ने बड़े पैमाने पर नहीं सीखा है, इसलिए CRUD app cases की तुलना में लेखक को LLM की सीमाएँ ज़्यादा तीखेपन से महसूस होती होंगी

  • इस लेख के कुछ हिस्से पढ़ते हुए ऐसा लगा जैसे TV शो Silicon Valley का ‘Bertram Gilfoyle’ character बोल रहा हो
    पता नहीं सिर्फ मुझे ऐसा लगा या औरों को भी

  • मूल बात यह है कि “telescope” क्षमता हमेशा बनी रहनी चाहिए
    coding agents की वजह से ऊँचे स्तर का काम करना ठीक है, लेकिन ज़रूरत पड़ने पर code के भीतर गहराई तक जाकर उसे खुद समझना और ठीक करना आना चाहिए—तभी यह सुरक्षित है