ภาพลวงตาของ Copilot - The Copilot Delusion

 (deplet.ing)
37 คะแนน โดย GN⁺ 2025-05-25 | 25 ความคิดเห็น | แชร์ทาง WhatsApp
  • ความเชื่อที่ว่า เครื่องมือเขียนโค้ดด้วย AI ช่วยเพิ่มผลิตภาพการพัฒนาได้จริงนั้นเป็นความเข้าใจผิด
  • เครื่องมือเหล่านี้บั่นทอน ความสนุกของการเขียนโปรแกรม และความเข้าใจเชิงลึกของมนุษย์
  • AI มีประโยชน์กับการสร้างโค้ดซ้ำๆ แต่มีจุดอ่อนในเรื่อง บริบท ประสิทธิภาพ และ nuance
  • การพึ่งพามากเกินไปทำให้ แรงจูงใจในการเรียนรู้และสำรวจ รวมถึงคุณภาพโค้ด ของนักพัฒนาลดลง
  • ปัญหาที่ แก่นแท้ของอาชีพโปรแกรมเมอร์ ค่อยๆ เลือนหายไปเพราะความสะดวกจาก AI กำลังรุนแรงขึ้น

บทนำ: ภาพลวงตาเกี่ยวกับเครื่องมือเขียนโค้ดด้วย AI

  • บทความนี้ว่าด้วยความเป็นจริงของเครื่องมือสร้างโค้ดด้วย AI ณ เดือนพฤษภาคม 2025
  • ข้อถกเถียงเรื่องความไร้ความสามารถของ AI อาจอ่อนลงเมื่อเวลาผ่านไป แต่ปัญหาเรื่อง การบั่นทอนแก่นแท้และความสนุกของการเขียนโปรแกรม กลับมีแนวโน้มจะรุนแรงขึ้น

บทที่ 1: เพื่อนร่วมงานของผม โปรแกรมเมอร์

  • ยกตัวอย่างประสบการณ์การทำงานกับนักพัฒนาที่ไม่เป็นมืออาชีพซึ่ง คัดลอกและวางโค้ดอย่างไม่รับผิดชอบ พร้อมเน้นปัญหาที่เพื่อนร่วมงานลักษณะนี้ทิ้งไว้ เช่น ประสิทธิภาพแย่ลง/ระเบิดบั๊ก/เมินสถาปัตยกรรม
  • เพื่อนร่วมงานแบบนี้จะคอยแก้โค้ดต่อเนื่องโดยไม่มี การทดสอบ การทำ profiling หรือความเข้าใจบริบท และสุดท้ายก็บั่นทอนแรงจูงใจและความตั้งใจเรียนรู้ของทีม
  • ผ่านการเฉลยหักมุมด้วยคำว่า "Captain Obvious" ผู้เขียนเผยว่าคำบรรยายนี้คือ การเสียดสีเครื่องมือเขียนโค้ดด้วย AI อย่าง GitHub Copilot, Claude Codex เป็นต้น
  • copilot ของเครื่องบินจริงเข้าใจทั้งระบบ ทำงานร่วมกับผู้อื่น และมีความรับผิดชอบ ตรงกันข้าม AI Copilot ทิ้งไว้เพียง โค้ดผิวเผินโดยไร้ความเข้าใจสาระสำคัญ
  • คำว่า "Copilot" ถูกยืมมาใช้เพื่อ ภาพลักษณ์เรื่องผลิตภาพและนวัตกรรม แล้วถูกยัดเยียดเข้าสู่ IDE ของนักพัฒนาทุกคน

บทที่ 2: ข้อดีของ Copilot

  • เครื่องมือเขียนโค้ดด้วย AI ไม่ใช่สิ่งที่ไร้ประโยชน์โดยสิ้นเชิง
  • มีประโยชน์เมื่อมือใหม่ต้องการเรียนรู้ไวยากรณ์ซับซ้อนของภาษาอย่าง C++ แบบคร่าวๆ หรืออ้างอิงคอนเซปต์อย่างรวดเร็ว
  • ในงานอย่าง brainstorming การจัดระเบียบบริบท หรือโค้ด template ที่ทำซ้ำๆ มันเร็วกว่าและผิดพลาดน้อยกว่าฝึกงานที่เป็นมนุษย์
  • แต่ก็ชัดเจนว่ามันไม่สนใจเรื่องประสิทธิภาพ/ความคุ้มค่าเลย และหาก ปล่อยทิ้งไว้โดยไม่มีการกำกับดูแล ก็เสี่ยงเกิดหายนะด้านคุณภาพการผลิต
  • มันช่วยให้ scaffold/โค้ดร่างที่ไร้บริบทได้อย่างรวดเร็ว แต่การออกแบบและการจูนอย่างครบถ้วนยังเป็นหน้าที่ของนักพัฒนามนุษย์

บทที่ 3: ตัวตนของผมในฐานะนักพัฒนาและ AI

  • ผู้เขียนให้ความสำคัญกับ "ความสนุกของการเขียนโค้ด" และความสำเร็จจากการลงมือสร้างด้วยตนเอง
  • หากมอบหมายโค้ดซ้ำๆ (boilerplate) ให้ AI และเลิกแม้แต่จะเขียนไลบรารี/แมโครด้วยตัวเอง ท้ายที่สุด ความคิดสร้างสรรค์และแรงขับภายใน ของนักพัฒนาก็จะหายไป
  • การพึ่งพา Copilot เพราะ FOMO (ความกลัวว่าจะตามไม่ทัน) จนเร่งผลิตโค้ดหยาบๆ ที่ไม่ผ่านการตรวจสอบออกมาจำนวนมาก เป็นปรากฏการณ์ที่เกิดขึ้นจริง
  • การพึ่งพา AI แย่งชิงโอกาสในการเรียนรู้จริง รวมถึง ความเข้าใจด้านประสิทธิภาพระดับล่าง โครงสร้าง และการดูแลคุณภาพโค้ด
  • ชื่อ "Copilot" ไม่ได้หมายถึง เพื่อนร่วมงานที่เท่าเทียมกัน แต่คล้ายภาพฝันของเกมเมอร์ประสบการณ์สั้นๆ ที่คิดว่าจะมาบังคับเครื่องบินได้

บทที่ 4: คอมพิวเตอร์คือเครื่องจักร

  • ความสามารถในการเข้าใจ ตัวตน โครงสร้าง และคุณลักษณะด้านประสิทธิภาพของเครื่องจักร (ฮาร์ดแวร์) มีอยู่ในมนุษย์เท่านั้น
  • AI ไม่มี สัญชาตญาณหรือประสบการณ์โดยตรง เกี่ยวกับ cache miss, memory layout, profiling หรือคอขวดด้านประสิทธิภาพจริง
  • คำตอบจาก AI มักหลุดจากบริบท และในพื้นที่ที่ต้องการ การปรับแต่งเชิง optimization อย่างเฉพาะเจาะจง มันแทบไร้ประโยชน์
  • ต่อให้สร้างเพียงแอป CRUD ธรรมดา นักพัฒนาก็ควรมี ความใส่ใจและความซื่อสัตย์ต่อผู้ใช้และระบบ
  • ความเป็นมืออาชีพและจิตวิญญาณของช่างฝีมือก่อรูปจาก ประสบการณ์ตรง ความเจ็บปวด และการปรับปรุงซ้ำๆ

บทที่ 5: บทสรุป

  • เครื่องมือเขียนโค้ดด้วย AI และการเข้าถึงที่ง่ายของมันกำลังนำไปสู่ การหายไปของจิตวิญญาณแบบแฮ็กเกอร์
  • ผู้เขียนกังวลกับปรากฏการณ์ที่อุตสาหกรรมอาจเหลือเพียง ผู้ใช้เชิงรับที่ไม่สนใจการเขียนโค้ด โครงสร้าง และประสิทธิภาพอย่างแท้จริง
  • ในอดีตเคยเต็มไปด้วย ความอยากรู้อยากเห็นและความคิดสร้างสรรค์อย่างบริสุทธิ์ เช่น การคุย IRC ตลอดคืน การทดลองฮาร์ดแวร์ และการสำรวจระดับล่าง
  • ตอนนี้กลับเหลือเพียง งานเชิงกลและความไม่ใส่ใจ ที่วนอยู่กับการ "รีวิวแพตช์จาก AI"
  • ผู้เขียนเตือนถึงความเสี่ยงที่ การสร้างโค้ดโดยขาดความเข้าใจบริบทและความสามารถจริง จะกลายเป็นมาตรฐานของวงการ และความจริงที่ว่าคนมีฝีมือแท้อาจถูกกันออกไป

ประวัติการแก้ไขบทความ

  • เพิ่มคำชี้แจงเกี่ยวกับวันที่เขียน
  • สะท้อนความเห็นจาก HN เพื่อทำให้จุดยืนเรื่องขอบเขตของคำวิจารณ์ด้านประสิทธิภาพชัดเจนขึ้น (ระบบซับซ้อน vs CRUD)
  • ปรับสไตล์ประโยคและการใช้สัญลักษณ์บางส่วนเพื่อให้อ่านง่ายขึ้น

บทความที่เกี่ยวข้อง

25 ความคิดเห็น

 
roxie 2025-05-27

บทความหลักอ่านสนุกดี แต่พอมีหลายบทความเกินไปที่สรุปได้ประมาณว่า “การไม่ใช้ AI ไม่ได้แปลว่าทุกอย่างจะจบ แต่ในขณะเดียวกันการเชื่อใจมันแบบไม่ลืมหูลืมตาและปล่อยให้ตัวเองคุ้นชินไปกับมันก็ไม่ใช่เรื่องดี” ก็เริ่มรู้สึกเหนื่อยนิดหน่อยเหมือนกัน..
 
ifmkl 2025-05-26

LLM และ AI พัฒนาขึ้นเรื่อย ๆ ตามกาลเวลา เมื่อไม่กี่เดือนก่อน เรื่องอย่างความสม่ำเสมอของโค้ดยังแทบคาดหวังไม่ได้เลย แต่ตอนนี้ถ้าให้ AI อัปโหลดโค้ดที่ขอให้ตั้งค่าเริ่มต้นไว้ในสเปซนั้นเป็นไฟล์ และเมื่อเขียนโค้ดใหม่ก็กำชับให้ยึดตามสไตล์ของโค้ดเดิมเสมอ ก็จะได้โค้ดที่มีความสม่ำเสมอค่อนข้างดีทีเดียว
 
crawler 2025-05-26

> ดูจากโพสต์เก่า ๆ ของผู้เขียน น่าจะเป็นนักพัฒนาเกม
> ความรู้หรือข้อมูลด้านการพัฒนาเกมนั้น LLM ยังไม่ได้เรียนรู้ในปริมาณมาก จึงดูเหมือนว่าผู้เขียนบทความหลักจะรับรู้ข้อจำกัดของ LLM ได้ชัดเจนกว่ากรณีแอปแบบ CRUD

ผมอ่านทั้งหมดแล้ว และคิดว่าสุดท้ายผู้เขียนก็มองเรื่องนี้ค่อนข้างเอนเอียงอยู่บ้างเพราะประเด็นนี้
แน่นอนว่าสิ่งที่บทความหลักพูดก็แทบจะเป็นแนวทางแบบตำราเรียน จึงถือว่าถูกต้อง
แต่ผมคิดว่า AI นั้นทำได้ดีมากพอแล้วกับงาน CRUD และงานฝั่งฟรอนต์เอนด์ที่มีข้อมูลให้เรียนรู้จำนวนมาก
น่าจะต้องพยายามนำมันไปใช้ให้เกิดประโยชน์สูงสุดภายในโดเมนของตัวเอง
 
superscv 2025-05-26

ผมคิดว่าน่าจะมีการเข้าใจความหมายที่ผู้เขียนตั้งใจจะสื่อคลาดเคลื่อนไปเล็กน้อย
ผู้เขียนโฟกัสที่ประสิทธิภาพ ความเสถียรของโปรเจกต์ที่ตัวเองดูแล รวมถึงสถาปัตยกรรมและความสม่ำเสมอของโค้ดที่เอื้อต่อการบำรุงรักษา และโดยเฉพาะอย่างยิ่งเรื่องสถาปัตยกรรมกับความสม่ำเสมอของโค้ดนั้น เป็นหนึ่งในด้านที่ LLM ปัจจุบันยังทำได้แย่มากจริง ๆ

โดยเฉพาะฝั่งเว็บ เป็นสายงานที่มีคนไหลเข้ามาพัฒนาเยอะ และมีแนวคิดแบบ "ขอแค่รันได้ก็พอ" ค่อนข้างแรง เลยมีโค้ดคุณภาพต่ำถูกปล่อยใช้งานอยู่เป็นจำนวนมาก และ LLM ก็ถูกฝึกจากสิ่งเหล่านี้ด้วย ทำให้คุณภาพของผลลัพธ์ที่ออกมาตกต่ำแบบน่าเหลือเชื่อ

ลองขอ GPT ง่าย ๆ ว่า "จะเอาไปใส่ในเว็บฟรอนต์ ช่วยเขียนอัลกอริทึม quicksort ด้วย js ให้หน่อย" ดูก็ได้ครับ ถ้าคุณมองไม่เห็นปัญหาในผลลัพธ์ที่มันให้มา ผมคิดว่าบทสนทนานี้ก็คงไม่มีความหมายมากนัก
 
ohnul 2025-05-26

สวัสดีครับ/ค่ะ ด้วยความสงสัยเลยลองพิมพ์ว่า "จะเอาไปใส่ในเว็บฟรอนต์ ช่วยเขียนอัลกอริทึม quicksort เป็น js ให้หน่อย" แต่สำหรับผม/ฉันแล้วค่อนข้างดูออกยากว่าอะไรคือปัญหา ถ้าช่วยบอกให้หน่อยจะเป็นประโยชน์มากเลยครับ/ค่ะ ขอบคุณล่วงหน้าครับ/ค่ะ 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 เลยแม้แต่น้อย ในกรณีของ C++ นั้น ตั้งแต่ราว 10 ปีก่อนก็มีทั้งข้อเสนอ/การนำ MoveConstructor ไปใช้แล้ว และการระแวดระวังภาระที่เกี่ยวข้องกับการคัดลอกหน่วยความจำก็เป็นพื้นฐานอย่างยิ่งอยู่เสมอ quick sort ตามกลไกของมันเป็นอัลกอริทึมที่สามารถกำหนด index ของค่าทั้งหมดได้ และแต่ละฟิลด์ก็ควรรองรับ random access

ต่อให้ไม่ทำ optimization แบบสุดโต่ง แค่นำสิ่งที่กล่าวมาข้างต้นไปใช้ ก็ได้ประสิทธิภาพต่างจากวิธีในลิงก์ที่คุณให้มาเกิน 2 เท่าแล้ว
 
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 ไม่ได้มีวิธี implement อยู่สองแบบคือ quicksort กับ in-place นะครับ......

ประเด็นที่ผมวิจารณ์ตั้งแต่แรกคือ การเขียน quickSortGPT() กับ quickSort() ในโค้ดข้างต้นซึ่งมีการรวม Array ไว้ในตัวอยู่แล้ว (ทั้งสองอันเป็นโค้ดที่ GPT สร้างออกมา) แล้วนำไปให้ผู้ใช้ AI ใช้งานนั่นเอง
 
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

โปรดตรวจสอบบริบทให้แน่ใจก่อนอ่านบทความนี้

ตอนนี้ผมไม่ได้กำลังอวดทักษะการเขียนโค้ดของตัวเองอยู่ สิ่งที่กำลังชี้ให้เห็นคือโค้ดแย่ ๆ อย่าง quickSort() ที่ถูกใช้เป็นตัวอย่างอยู่ตอนนี้ กลับถูก GPT แสดงผลออกมาด้วยลำดับความสำคัญที่สูงกว่า

ถ้าลองค้นหาด้วย GPT หลาย ๆ ครั้ง จะพบว่ามีหลายกรณีที่มันให้ผลลัพธ์เป็นฟังก์ชัน quickSort() แบบเดี่ยว ๆ และอีกครั้ง quickSort() ก็เป็นเพียงแค่ตัวอย่างหนึ่งเท่านั้น เวลาขอให้ GPT เขียนโค้ดเพื่อใช้ทำงานจริง มักจะมีโค้ดคุณภาพต่ำจำนวนมากถูกสร้างออกมา (จากประสบการณ์ของผู้ใช้แบบเสียเงิน) และหากนักพัฒนาเองไม่มีความสามารถในการแยกแยะสิ่งนี้ได้ ก็มีโอกาสสูงที่โปรเจกต์จะเดินไปในทิศทางที่พัง ซึ่งผมเห็นด้วยกับความเห็นของผู้เขียนบทความในประเด็นนี้ จึงมาถึงบริบทการพูดคุยในตอนนี้

รอบตัวผมเอง ตอนนี้ก็มีโปรเจกต์ที่เต็มไปด้วยโค้ดแย่ ๆ ในลักษณะนี้เพิ่มขึ้นอย่างต่อเนื่องอยู่แล้ว
 
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 กันอยู่แล้ว มันก็กลายเป็นเรื่องธรรมดาไปมาก

ถัดมาคือกรณีที่คนทั่วไปซึ่งไม่มีความรู้ด้านการพัฒนาใช้ LLM
ผมคิดว่าไม่ว่าจะในบทความ บน Hacker News หรือแม้แต่ตัวผมเอง ก็ไม่เคยพูดถึงกรณีนี้นะ แต่ถึงอย่างนั้น ตอนนี้มันก็พัฒนามาถึงระดับที่ผู้ใช้พอใจกับผลลัพธ์ได้แล้ว
ไม่อย่างนั้น Bolt.new, v0, จนถึง Cursor ก็คงไม่ได้รับการประเมินแบบทุกวันนี้หรอกครับ
 
superscv 2025-05-26

สรุป

ผู้เขียน: นักพัฒนาต้องพัฒนาความสามารถของตัวเองและรักษามันไว้ แม้แต่ AI เองก็ยังทำงานได้ไม่ดีนัก

crawler: หือ? แต่ของฉันใช้ได้ดีนะ?

superscv: มีปัญหาเยอะ...

crawler: ก็ต้องปรับจูนให้ดีแล้วค่อยใช้สิ

superscv: ดูเหมือนจะออกห่างจากสารที่ผู้เขียนตั้งใจจะสื่อมาตั้งแต่แรกมากเกินไปแล้ว..
 
crawler 2025-05-26

ดูเหมือนว่าคุณจะยังไม่ค่อยเข้าใจว่าทำไมผมถึงพูดถึงสาขาของผู้เขียน และคำว่าโดเมนของตัวเองหมายถึงอะไร
การมอบหมายการตัดสินใจทุกอย่างให้ AI โดยไม่มีความคิดของตัวเองก็ดูเป็นเรื่องไม่ฉลาดเหมือนกัน
แต่คนที่อยู่สุดโต่งในอีกด้านหนึ่ง ผมก็ไม่ค่อยเข้าใจเหมือนกัน

สุดท้ายนี้มีเรื่องที่อยากถามคือ คุณ superscv คิดว่าควรใช้ LLM กับการเขียนโค้ดอย่างไรถึงจะดี
 
superscv 2025-05-26

ปกติผมไม่ค่อยเขียนคอมเมนต์เท่าไร แต่เหตุผลที่คอมเมนต์ในบทความนี้เป็นพิเศษก็เพราะผมเห็นด้วยกับความคิดของผู้เขียนอย่างมาก ผมคิดว่าสิ่งสำคัญไม่ใช่ AI หรือ LLM แต่ไม่ว่าสภาพแวดล้อมแบบไหนจะมาถึง ตัว "ผม" ในฐานะนักพัฒนาต้องพร้อมอยู่เสมอ

ด้วยลักษณะของซอร์สที่ใช้ในการฝึก LLM จึงมักให้ข้อมูลที่อยู่ใกล้กับค่าเฉลี่ยของข้อมูลออนไลน์ที่กระจายอยู่ทั่วโลกเป็นหลัก (ก่อนหน้านี้กรณี js quicksort ก็พิสูจน์เรื่องนี้ได้) เพราะฉะนั้นโดยทั่วไปผมจึงใช้มันเพื่อถามว่าในด้านแนวคิด/การออกแบบ สิ่งนั้นสอดคล้องหรือคลาดไปจากมุมมองทั่วไปมากน้อยแค่ไหน หรือใช้ถามเรื่องที่ก่อนหน้านี้ไม่ค่อยแน่ใจว่าจะไปถามที่ไหนดี
 
superscv 2025-05-26

ผมไม่ค่อยแน่ใจว่าการคุยต่อไปอีกจะมีความหมายอย่างไร

ตั้งแต่แรกแล้ว ถ้าความเห็นคือโค้ดที่ AI สร้างให้ในตอนแรกอาจมีความเสี่ยงอยู่บ้าง จึงควรขัดเกลาให้ดีและนำไปใช้อย่างเหมาะสม ก็คงพอจะอธิบายได้ว่าบทความของผู้เขียนมีแนวคิดส่วนไหนที่เอนเอียงไปบ้าง เพราะแม้แต่ในบทสรุปก็มีข้อความในทำนองเดียวกันว่า "สามารถสร้าง scaffold/โค้ดร่างที่ไร้บริบทได้อย่างรวดเร็ว แต่การออกแบบและการจูนให้สมบูรณ์ยังเป็นหน้าที่ของนักพัฒนามนุษย์" อยู่เหมือนกัน
 
superscv 2025-05-26

แม้สารที่ผู้เขียนต้องการสื่อจะค่อนข้างหนักแน่นอยู่บ้าง แต่ถ้าอ่านบทความดี ๆ จะเห็นว่าไม่ได้หมายถึง "อย่าใช้ AI" ครับ มีข้อเสนอเกี่ยวกับการนำไปใช้อย่างไร และใจความสำคัญคือ นักพัฒนาเองต้องไม่ขาดความสามารถพื้นฐาน

ถ้าจะดูว่าทำไมสารของผู้เขียนถึงให้ความรู้สึกหนักแน่น ก็เพราะมันถูกสร้างขึ้นในฐานะมุมมองตอบโต้ต่อแนวคิดที่ว่า จะสามารถพัฒนาได้ด้วย copilot (มีนัยของการพึ่งพา copilot ในการพัฒนาค่อนข้างสูง) ผู้เขียนจึงเลือกเดินเกมด้วยสารในลักษณะว่า อย่ามีท่าทีที่บั่นทอนคุณค่าการมีอยู่ของนักพัฒนาเอง

อีกอย่าง ผู้เขียนเองก็ไม่ได้สื่อว่า "อย่าใช้ AI" อยู่แล้ว ดังนั้นถ้าจะบอกว่าให้ใช้ AI สุดท้ายก็คงต้องไปอยู่ที่จุดประนีประนอมตรงไหนสักแห่ง ซึ่งในแง่นั้นสารโดยรวมก็ดูคล้ายกับสิ่งที่คุณเพิ่งตอบไปพอสมควร

อย่างไรก็ตาม ในข้อความที่คุณเขียนตอนแรก ผมเห็นด้วยได้ยากกับส่วนที่ว่าเป็น 'มุมมองที่มีอคติ' ก็เลยตอบกลับมาก่อนครับ
 
GN⁺ 2025-05-25
ความเห็นจาก Hacker News

  • ถ้าคุณอยากสร้างซอฟต์แวร์ที่ต้องแข็งแกร่งไร้ที่ติจริง ๆ อย่างซอฟต์แวร์ในเครื่องกระตุ้นหัวใจ ระบบนำวิถีขีปนาวุธ หรือรถถัง M1 ก็ต้องวาง AI coding agent ลงแล้วฝึกเรียนรู้ด้วยตัวเอง
    แต่คนส่วนใหญ่ไม่ได้สร้างของแบบนั้น เราส่วนมากแค่ทำแอป CRUD ที่ข้อกำหนดแทบเหมือนเดิม ต่างกันแค่นิดหน่อยที่สคีมาและวิธีเชื่อมต่อระบบ
    ซอฟต์แวร์ที่พวกเราส่วนใหญ่สร้างกัน แทบไม่มีอะไรใหม่จริง ๆ
    หลายครั้งการนำความรู้เดิมที่มีอยู่แล้วกลับมาใช้ใหม่คือทางเลือกที่ดีที่สุด
    สำหรับผม coding agent ก็คือการรีไซเคิลโค้ดแบบเวอร์ชันโหดมากของอดีต
    อีกอย่าง แบบน่าขันหน่อย ๆ คือบทความนี้เองก็ให้ความรู้สึกเหมือนบทความที่ AI เขียน

    • เดิมทีผมก็ไม่ได้อยากเขียนโค้ดระดับล่างที่ mission-critical อยู่แล้ว
      ผมไม่ได้คิดว่าเครื่องมือ AI มีประโยชน์ไปหมดแบบที่ผู้เขียนมอง แต่ก็เบื่อมากกับการถกเถียงแนว ๆ ว่า “ถ้าไม่ทำ system programming ด้วย C ก็ไม่ใช่โปรแกรมเมอร์”
      ผมชอบเขียนฟรอนต์เอนด์
      และก็ไม่ได้อยากสร้าง low-level graphics library เองด้วย
      ผมไม่ใช่สายลุกขึ้นมาตีสามแล้วนั่งแฮ็ก แต่ก็ยังมีแพสชันและความภูมิใจกับงานของตัวเอง
      ผมไม่คิดว่าทุกคนต้องมีท่าทีสุดโต่งแบบผู้เขียน
      ผมคิดว่าตลาดซอฟต์แวร์ควรมีความหลากหลาย

    • จะโต้แย้งประเด็นของผู้เขียนก็ได้ แต่การบอกว่าบทความนี้ AI เขียนนี่เกินไปหน่อย
      ผู้เขียนใส่ทั้งสำนวนสด ๆ ภาพเปรียบเทียบจัดจ้าน และมุกตลกที่ขำจริงลงไปทั่วทั้งบทความในแบบของตัวเอง
      ตอนนี้ให้ LLM เขียนอะไรแบบนี้ยังยากมาก
      นี่ไม่ใช่งานของ AI แต่เป็นงานเขียนที่ดี
      จะเห็นด้วยกับข้อโต้แย้งหรือไม่ก็เถอะ ฝีมือการเขียนต้องยอมรับ

    • ในต้นฉบับก็มีข้อความประมาณนี้
      “คุณคงไม่ได้เป็นคนเขียนโค้ดที่ทำให้เครื่องบินลอยอยู่บนฟ้า หรือโค้ดที่เกี่ยวข้องกับชีวิตมนุษย์โดยตรงหรอก คนส่วนใหญ่ก็ไม่ทำแบบนั้น แต่ถึงจะทำงานในองค์กรที่ปะติดปะต่อแอป CRUD ธรรมดา ๆ อยู่ทุกวัน คุณก็ยังมีหน้าที่ต้องปฏิบัติต่อผู้ใช้อย่างมีความเคารพและให้เกียรติ”
      เป็นการเน้นว่าต่อให้ซอฟต์แวร์จะเรียบง่ายแค่ไหน อย่างน้อยก็ต้องมีความรับผิดชอบขั้นต่ำ

    • จริง ๆ แล้วผู้เขียนเองก็ยอมรับว่า AI มีประโยชน์ในบางกรณี
      ปัญหาหลักของผู้เขียนคือการที่เราตั้งชื่อ AI ว่า “copilot” จนมือใหม่อาจเชื่อมันมากเกินไป
      copilot ที่แท้จริงควรเป็นคนที่ชำนาญและเป็นเพื่อนร่วมงาน แต่ AI ตอนนี้ยังมีโอกาสครึ่งต่อครึ่งที่จะเป็นเพื่อนร่วมงานห่วย ๆ
      “ตอนนี้เรากำลังปล่อยให้ความอยากรู้อยากเห็นและความเป็นเจ้าของงานอยู่นอกระบบ คนที่เดิมทีน่าจะเติบโตได้กลับต้องมานั่งรีวิว patch set จาก AI จนไฟมอด เทอร์มินัลกลายเป็นสเปรดชีต และดีบักเกอร์กลายเป็นโลงศพ”
      แต่ AI ก็เป็นเพียง abstraction อีกรูปแบบหนึ่งเท่านั้น
      คนจำนวนมากก็กังวลแบบเดียวกับตอนที่ GC (garbage collector) กลายเป็นของปกติ ว่ารากฐานสำคัญจะถูกละเลยไป และกับ AI ก็มีความกลัวว่าความสามารถพื้นฐานด้านการเขียนโปรแกรม/การเรียนรู้อาจค่อย ๆ หายไป
      นักพัฒนาเว็บสามารถสร้างเว็บดี ๆ ได้เป็นส่วนใหญ่แม้ไม่เข้าใจโครงสร้างลึกของสแตก เพราะ abstraction ช่วยไว้
      แต่ AI เป็น abstraction ที่ยังเต็มไปด้วยรูรั่ว เลยทำให้มันพอใช้งานได้แม้ผู้ใช้จะไม่รู้พื้นฐานจริง ๆ
      ปัญหาคือสักจุดหนึ่งคุณจะพบว่ามีบั๊กร้ายแรงซ่อนอยู่ และความสามารถในการดีบัก แก้ปัญหา และเรียนรู้ด้วยตัวเอง คือสิ่งที่ AI แทนไม่ได้
      เลยมีความกังวลว่าถ้าเรียนรู้ผ่าน AI แบบง่าย ๆ อย่างเดียว ความสามารถพื้นฐานสำคัญอาจถูกข้ามไป
      ท้ายที่สุด การเติบโตผ่านการทำซ้ำและลงมือชนด้วยตัวเองต่างหากคือการเรียนรู้ที่แท้จริง
      ถ้า AI ทำให้แม้แต่ “การเรียนรู้” เองกลายเป็น abstraction ก็อาจทำให้ศักยภาพของนักพัฒนาถดถอยในระยะยาว
      แน่นอนว่าไม่ใช่ว่าใช้ AI แล้วทุกคนจะโง่ลง คนที่เรียนรู้เชิงรุกก็ยังจะมีอยู่
      แต่โดยรวมแล้วสัดส่วนของคนแบบนั้นมีแนวโน้มจะลดลง
      เพราะประสบการณ์แบบ “คิดเองแล้วสร้างเอง” สำหรับผู้เริ่มต้นอาจหายไปเลย
      และ abstraction ที่ชื่อ AI ก็มีช่องโหว่มากอยู่ดี
      สำหรับมือใหม่มันอาจดูเหมือน AI ทำให้หมด แต่สุดท้ายความสามารถหลักด้านการเขียนโปรแกรมและการดีบักก็ยังจำเป็น
      เพราะงั้นถ้าอยากจับปัญหาในโค้ดที่ AI สร้างได้จริง ก็ควรสะสมทักษะให้แน่นไว้
      ผมเองก็ใช้ AI coding assistant ได้ค่อนข้างดี
      แต่เพราะมันมีข้อเสีย ผมเลยสรุปว่าเราไม่ควรมองมันเป็นของดีไปเสียทั้งหมด

    • ผมลองทำคลิปตลกสั้น ๆ ของตัวเองด้วย Google Whisk แล้วเอาไปลง TikTok พอเข้าไปดูก็เจอแต่คอนเทนต์ที่ AI ทำ หรือไม่ก็วิดีโอที่คนก็อปกันไปมาเต็มไปหมด
      ผมเคยคิดว่า “งานสร้างสรรค์ต้นฉบับ” น่าจะยังมีอะไรบางอย่างอยู่จริง แต่สุดท้ายพวกเราก็เป็นสิ่งที่ถูกทำซ้ำได้ง่ายเกินไป
      ต่อให้เราเอาคลิปการเขียนโค้ดทุกวันไปลง TikTok ก็จะมีแต่แอปเดิม ๆ ซ้ำไปซ้ำมาไม่รู้จบ
      เหมือนที่ Elon Musk พูด ตอนนี้มันให้ความรู้สึกว่าเหลือแค่ไปดาวอังคารจริง ๆ เท่านั้น
      เมื่อสองปีก่อนผมก็เคยพูดว่า LLM ไม่ได้ “หลอน” มากขนาดนั้น และจนถึงตอนนี้คนก็ยังเชื่อว่ามนุษย์ยังจำเป็นแบบขาดไม่ได้ แต่ผมอยากจะบอกว่ามันเริ่มไม่ใช่แบบนั้นแล้ว
      อยากกลับมาทบทวนประเด็นนี้อีกทีในอีก 2 ปี

  • “เครื่องจักรคือของจริง ซิลิคอนก็จริง DRAM ก็จริง L1 cache กับ false sharing ก็จริง และ branch predictor ที่เหมือนโยนเหรียญก็คือของจริงทั้งหมด ถ้าสนใจ คุณก็เข้าไปจัดการมันได้”
    รู้สึกว่านานมากแล้วที่ไม่ได้อ่านถ้อยคำสวยงามแบบนี้

    • ผมก็รู้สึกเหมือนกัน
      ผู้เขียนเขียนแบบมีอารมณ์ขันสไตล์ Dave Barry จนผมหัวเราะออกมาหลายรอบ
      ผมชอบที่เขาถ่ายทอดความคิดเรื่อง Copilot ที่ชวนเห็นด้วยออกมาได้ดีและตลกไปพร้อมกัน

  • สิ่งที่มักหายไปจากการถกเรื่องการพัฒนาซอฟต์แวร์ คือมันไม่ได้มีแค่ “ผลลัพธ์ของการเขียนโค้ด” เท่านั้น
    เส้นทางที่เราผ่าน trade-off มากมายเพื่อไปถึงผลลัพธ์นั้นสำคัญมาก
    แค่ลองให้จูเนียร์ทำฟีเจอร์หนึ่งใน codebase ที่ซับซ้อนขึ้นมาหน่อย คุณก็จะสัมผัสได้ทันทีว่าในฐานะวิศวกรที่มีประสบการณ์ คุณกำลังทำ trade-off อะไรแบบอัตโนมัติอยู่บ้าง
    AI เองก็มีแนวคิดเรื่อง trade-off แบบนี้อยู่ แต่ส่วนใหญ่เป็นระดับที่เรียนรู้จากการสังเกต
    มันช่วย “เขียนโค้ดให้ดีขึ้น” ได้จริง แต่สุดท้ายการตัดสินใจและการคิดยังเป็นหน้าที่ของคน
    LLM ไม่ได้ “คิด”
    และยิ่ง AI พัฒนา ก็ยิ่งมีความเสี่ยงที่มนุษย์จะคิดน้อยลงเรื่อย ๆ

  • สำหรับผม ข้อดีข้อเสียของ Copilot ฟังแล้วโดนทั้งคู่
    แต่ต่างจากภาพฝันเรื่องแฮ็กเกอร์หรือ “งานช่างฝีมือ” ในวัยเด็ก วิศวกรก็คือวิศวกรมาโดยตลอด
    เหตุผลที่เทคโนโลยีหลักในปัจจุบันถือกำเนิดขึ้นมาอย่างยากลำบาก ก็เพราะในตอนนั้นมันเป็นปัญหาที่จำเป็นต้องแก้ให้ได้ไม่ว่าจะยังไงก็ตาม
    ถ้าเอาประวัติศาสตร์ที่เข้มข้นแบบนั้นไปเหมารวมว่าเป็น “สมัยก่อนเขาทำกันแบบนี้” ก็เสี่ยงจะมองโลกแบบลำเอียง

    • ผมเป็นวิศวกรซอฟต์แวร์ที่พัฒนาด้วยวิธีที่ยากมาตลอดกว่า 20 ปี การได้แก้ปัญหายาก ๆ เองถือเป็นทั้งสิทธิพิเศษและความคุ้มค่า
      การอัปเดต CRUD ง่าย ๆ นั้นซ้ำซากและน่าเบื่อ แต่โจทย์ชวนปวดหัวที่โผล่มาเป็นครั้งคราว ช่วงเวลาที่ได้หยิบความรู้จากมหาวิทยาลัยกลับมาใช้ หรือเคสพิเศษอย่าง recursive algorithm คืออัญมณีในเส้นทางอาชีพ
      ผมหวังว่าวิศวกรซอฟต์แวร์ที่ขับเคลื่อนด้วย AI ในอนาคตจะยิ่งเห็นคุณค่าของประสบการณ์แบบนี้
      AI อาจให้คำตอบที่ดูมีตรรกะได้ แต่บางครั้งมันก็ผิดแบบหลุดโลกและอันตราย จึงยังต้องมีคนที่รู้จริงว่าควรทำอะไร
      เมื่อ AIs “หลอน” หรืออยู่ในสถานการณ์ที่ขาดบริบท สุดท้ายก็จะยังมีช่วงเวลาที่มนุษย์ต้องเป็นคนแก้ปัญหาอยู่เสมอ

  • สำหรับผม ตัวเทียบไม่ได้คือ pair programming แต่คือทีมนักพัฒนาที่ outsource ไปต่างประเทศ
    จริง ๆ แล้ว Copilot, Cursor และเครื่องมือ AI อื่น ๆ ให้ความรู้สึกดีกว่ามาก เพราะผมไม่ต้องเสียเวลากับปัญหาการสื่อสารคลุมเครือ อุปสรรคด้านภาษา หรือความเข้าใจไม่ตรงกันบน Zoom call อีกต่อไป
    เช่นสถานการณ์แบบ “มีการเพิ่มฟังก์ชัน isChild (คืนค่า boolean) ที่เกี่ยวกับ root node แต่ไม่เกี่ยวอะไรกับการเช็กว่ามีพาเรนต์หรือไม่” หรือ “จู่ ๆ API parameter ก็รับ array ไม่ได้แล้ว” ซึ่งเป็นเรื่องที่เจอบ่อยในการ outsource
    เวลาทำงานกับ AI ต่อให้เกิดปัญหาแบบนี้ แค่บอกว่ามันผิดและอธิบายเหตุผล มันก็แก้ให้ได้เร็ว
    แทบไม่มีต้นทุนด้านการสื่อสาร ความเข้าใจผิด หรือการเสียเวลาแบบที่เกิดเวลาทำงานกับคน
    ทันทีที่ AI เชื่อมกับ Jira ticket ได้ง่าย ๆ วันทำงานพัฒนาซอฟต์แวร์สัก 80% ก็คงจะกลายเป็นการเขียน ticket และทำหน้าที่กำกับตรวจงาน
    แน่นอนว่านั่นไม่ได้หมายความว่าบทบาทของวิศวกรจะหายไป เพราะฝ่าย Biz คงไม่เขียน ticket ดี ๆ ได้เอง และสุดท้ายก็ต้องมีคนรับผิดชอบงานขั้นสุดท้ายอยู่ดี
    ถึงอย่างนั้น หลายองค์กรก็คงลืมข้อเท็จจริงข้อนี้ และนั่นอาจเปิดทางให้เกิดความเสียหายครั้งใหญ่

  • สิ่งสำคัญที่ผมรับมาจากบทความนี้คือ
    “เรากำลังจะยกย่องความล้าหลัง อืดเทอะทะ และเต็มไปด้วย abstraction เกินพอดีของซอฟต์แวร์ยุคนี้ว่าเป็นสิ่งสูงสุด วัฒนธรรมของการบีบประสิทธิภาพจนถึงขีดสุด หรือการสร้างระบบให้ผอม คม และชัดเจน จะเหลือเป็นเพียงเรื่องเล่าของอดีต”
    ผมกังวลว่าไลบรารีหรือ architectural pattern ที่สร้างก่อนปี 2023 จะถูกทำให้แข็งตัวเป็นแกนกลางของข้อมูลฝึก LLM ในอนาคต
    แทนที่จะเดินหน้าสร้างนวัตกรรมต่อไป เราอาจต้องอยู่กับ dependency และโค้ดรก ๆ ที่สะสมมาสามสิบปีต่อไปตลอดกาล
    ผมถึงขั้นกังวลว่า Javascript จะอยู่ไปตลอดกาล

  • ทุกวันนี้ผมรู้สึกถึงแรงกดดันจากฝั่งผู้นำทุกวันว่า “เราใช้ AI ไม่พอ” หรือ “ถ้าเอา AI มาใช้ เราตัดเวลาเดิมลงครึ่งหนึ่งได้”
    เราถูกบังคับให้เอาเครื่องมือ AI ตัวใหม่มาใช้เพื่อให้ถึง KPI และถ้าปรับตัวไม่ได้ก็มีการพูดถึงการลดจำนวนคนในทีม
    มันให้ความรู้สึกเหมือนโลกบ้าไปไกลมากแล้ว
    AI มักถูกขายในฐานะ “เครื่องมือสำหรับแทนที่งานของคนอื่น” เสมอ
    ทั้งที่จริงเหตุผลที่ AI ดูดี มักเป็นเพราะคนประเมินไม่เข้าใจงานของคนอื่นดีพออยู่แล้วต่างหาก
    เหมือนผู้บริหารถือค้อนชื่อ AI แล้วพยายามตอกทุกสิ่งบนโลกให้เป็นตะปู

    • เราคงต้องคิดจริงจังว่าจะลดโครงสร้างผู้บริหารลงยังไง และหาวิธีทุ่มเวลาให้กับงานที่สร้างผลลัพธ์จริงมากขึ้น
      หวังว่าจะเกิดวัฒนธรรมที่โฟกัสกับงานจริงและการส่งมอบ มากกว่าการโชว์ว่าใช้ AI

    • อันที่จริงนี่ก็เป็นแค่รูปแบบของ “hype cycle” ในอุตสาหกรรม AI เท่านั้น
      พอสถานการณ์นิ่งลง สุดท้ายจะเหลือแค่เครื่องมือและเทคโนโลยีที่มีประโยชน์จริง ส่วนที่เหลือส่วนใหญ่จะหายไป
      ความเห็นนี้มองว่า ถ้าเรามองให้ออกอย่างชาญฉลาดว่าอะไรจะอยู่รอดจริง และสามารถมีอิทธิพลต่อการเปลี่ยนแปลงนั้นได้ ก็ยังเป็นหนทางให้อยู่รอดต่อไปในอนาคต และควรพยายามแบบนั้น

    • การถูกบังคับว่า “ต้องรีบนำมาใช้” แบบตอนนี้ ขัดกับแก่นแท้ของการเป็นวิศวกร นักออกแบบ หรือคนทำเทคโนโลยีอย่างที่ผมเคยรู้จักโดยสิ้นเชิง
      แต่เดิมเราต้องพิจารณาอย่างรอบคอบว่าจะนำเครื่องมือ ภาษา หรือบริการใดมาใช้ ทำไมมันถึงเหมาะกับกรณีของเรา และมีข้อดีข้อเสียอะไรบ้าง พร้อมเตรียมเหตุผลรองรับก่อนนำมาใช้
      กระบวนการตัดสินใจเชิงนโยบายแบบ “ทำไมเราต้องใช้สิ่งนี้ ทำไมบริการนี้ถึงสมเหตุสมผลกว่า” คือเรื่องปกติ
      มีการทดสอบก่อนว่าเทคโนโลยีนี้จำเป็นต่อการใช้งานจริงไหม แล้วค่อยประเมินผลลัพธ์หรือประสิทธิภาพหลังนำมาใช้
      องค์กรทุกวันนี้กำลังห่างออกไปจากวิธีการที่ดีต่อสุขภาพแบบนั้น

    • ภาพฝันที่ว่า “AI เป็นเครื่องมือแทนงานของคนอื่นได้เสมอ” แพร่หลายมากเกินไป
      จริงอยู่ที่งานซ้ำ ๆ มีเยอะ แต่ถ้าจะทำงานส่วนใหญ่ให้ดี มันต้องอาศัยความละเอียดอ่อนและความเฉพาะตัวที่ต่างกันไป และสิ่งเหล่านี้เสี่ยงจะหายไปหมดในกระบวนการทำให้เป็นอัตโนมัติ
      ผมไม่เห็นด้วยกับคำพูดว่า “ให้ AI ทำได้สัก 80% ก็พอ”
      ความผิดพลาดส่งผลต่อทั้งระบบ และคนที่มีหน้าที่ประเมินก็มักหลีกเลี่ยงไม่ได้ที่จะขาดประสบการณ์หน้างาน

    • ผมคิดว่าอีกไม่นานตำแหน่งผู้จัดการจะหายไปเร็วกว่างานประเภทอื่นเสียอีก
      ถึงตอนนั้นก็ขอให้พวกเราสู้ไปด้วยกัน

  • ผู้เขียนดูน่าจะเป็นนักพัฒนา C++ ชัดเจน
    ในทางปฏิบัติ AI coding assistant มักทำงานกับ C++ ได้ไม่ค่อยดีนัก และคนที่ใช้มันได้ผลส่วนมากก็มักใช้กับภาษา scripting หรือแอป CRUD

    • ถ้าไปดูโพสต์เก่า ๆ ของผู้เขียน เขาน่าจะเป็นนักพัฒนาเกม
      ความรู้และข้อมูลด้าน game development ไม่ได้ถูก LLM ฝึกมาอย่างมหาศาลแบบกรณีแอป CRUD จึงน่าจะทำให้ผู้เขียนต้นฉบับสัมผัสข้อจำกัดของ LLM ได้ชัดกว่า

  • บางช่วงของบทความนี้อ่านแล้วเหมือนกำลังได้ยินเสียงตัวละคร ‘Bertram Gilfoyle’ จากซีรีส์ Silicon Valley อยู่ในหัว
    ไม่รู้ว่ามีใครรู้สึกแบบผมไหม

  • แก่นสำคัญคือการต้องรักษาความสามารถแบบ “telescope” เอาไว้เสมอ
    ต่อให้ coding agent ทำให้เราทำงานในระดับสูงได้เป็นหลักก็จริง แต่เมื่อจำเป็น เราต้องสามารถเจาะลึกลงไปในโค้ด เข้าใจมันด้วยตัวเอง และแก้มันเองได้ทุกเมื่อ ถึงจะปลอดภัย