Ảo tưởng Copilot - The Copilot Delusion

 (deplet.ing)
37 điểm bởi GN⁺ 2025-05-25 | 25 bình luận | Chia sẻ qua WhatsApp
  • Niềm tin rằng các công cụ lập trình AI thực sự nâng cao năng suất phát triển là một sự ngộ nhận
  • Những công cụ này làm tổn hại niềm vui của việc lập trình và khả năng thấu hiểu sâu sắc của con người
  • AI hữu ích cho việc sinh mã lặp đi lặp lại, nhưng yếu ở ngữ cảnh, hiệu năng và sắc thái
  • Việc phụ thuộc quá mức dẫn đến suy giảm ý chí học hỏi·khám phá và chất lượng mã của lập trình viên
  • Vấn đề bản chất của nghề lập trình đang dần biến mất vì sự tiện lợi do AI mang lại ngày càng lớn

Mở đầu: Ảo tưởng về công cụ lập trình AI

  • Bài viết này đề cập đến thực tế của các công cụ sinh mã AI tính đến tháng 5 năm 2025
  • Tranh cãi về sự kém cỏi của AI có thể giảm dần theo thời gian, nhưng vấn đề làm tổn hại bản chất và niềm vui của lập trình lại được dự đoán sẽ càng nghiêm trọng hơn

Chương 1: Đồng nghiệp của tôi, lập trình viên

  • Tác giả nêu ví dụ về trải nghiệm làm việc với những lập trình viên không chuyên sao chép và dán mã một cách vô trách nhiệm, nhấn mạnh các vấn đề mà những đồng nghiệp này để lại như hiệu năng suy giảm / bom lỗi / phớt lờ kiến trúc
  • Những đồng nghiệp như vậy liên tục sửa mã mà không có kiểm thử, profiling hay hiểu ngữ cảnh, và cuối cùng làm mất động lực cũng như ý chí học hỏi của cả đội
  • Qua cú lật ngược với lời thú nhận về "Captain Obvious", tác giả tiết lộ rằng mô tả này thực chất là sự châm biếm nhắm vào các công cụ lập trình AI như GitHub Copilot, Claude Codex
  • Một cơ phó thực thụ của máy bay hiểu toàn bộ hệ thống, biết cộng tác và có trách nhiệm. Trái lại, các AI Copilot chỉ để lại phần mã bề mặt mà không có sự hiểu biết bản chất
  • Chỉ mượn cái tên "Copilot", chúng đang bị ép đưa vào IDE của mọi lập trình viên dưới vỏ bọc năng suất và đổi mới

Chương 2: Ưu điểm của Copilot

  • Các công cụ lập trình AI cũng không phải hoàn toàn vô dụng
  • Chúng hữu ích khi người mới chỉ cần làm quen với cú pháp phức tạp của các ngôn ngữ như C++, hoặc khi cần tham khảo nhanh một khái niệm
  • Trong các việc như brainstorming, sắp xếp ngữ cảnh, mã mẫu lặp đi lặp lại, chúng nhanh hơn và ít mắc lỗi hơn thực tập sinh con người
  • Tuy nhiên, rõ ràng vẫn có rủi ro xảy ra thảm họa chất lượng sản phẩm nếu để mặc chúng hoạt động mà không có giám sát xung quanh, nhất là vì chúng hoàn toàn không bận tâm đến hiệu năng hay hiệu suất
  • Chúng có thể nhanh chóng cung cấp scaffold/bản nháp mã thiếu ngữ cảnh, nhưng việc thiết kế và tinh chỉnh hoàn chỉnh vẫn là phần việc của lập trình viên con người

Chương 3: Tôi với tư cách một lập trình viên và AI

  • Tác giả coi trọng "niềm vui của việc viết mã" và cảm giác thành tựu khi tự tay tạo ra thứ gì đó
  • Nếu giao mã lặp lại (boilerplate) cho AI và tự từ bỏ cả việc hiện thực thư viện/macro, thì cuối cùng sự sáng tạo và động lực nội tại của lập trình viên sẽ biến mất
  • Hiện tượng dựa vào Copilot vì FOMO (nỗi sợ bị tụt lại phía sau) để nhanh chóng tuôn ra những đoạn mã thô và chưa được kiểm chứng đang xảy ra
  • Sự phụ thuộc vào AI cướp đi cơ hội học tập thực sự, cũng như cơ hội hiểu hiệu năng mức thấp, cấu trúc hệ thống và quản lý chất lượng mã
  • Cái tên "Copilot" không phải hình ảnh của một đồng nghiệp ngang hàng, mà giống như ảo tưởng rằng một game thủ chỉ có ít kinh nghiệm có thể lái máy bay

Chương 4: Máy tính là máy móc

  • Khả năng hiểu bản chất của máy móc (phần cứng), cấu trúc và đặc tính hiệu năng chỉ con người mới có
  • AI không có trực giác hay kinh nghiệm trực tiếp về cache miss thực tế, memory layout, profiling hay các điểm nghẽn hiệu năng
  • Những câu trả lời AI đưa ra tách rời khỏi ngữ cảnh, và trong các lĩnh vực cần tối ưu hóa cụ thể thì gần như vô dụng
  • Dù chỉ xây dựng một ứng dụng CRUD bình thường, lập trình viên vẫn phải có sự tôn trọng và tinh thần nghiêm túc đối với người dùng và hệ thống
  • Tính chuyên môn và tay nghề được hình thành từ trải nghiệm trực tiếp, đau đớn và những lần cải tiến lặp đi lặp lại

Chương 5: Kết luận

  • Các công cụ lập trình AI và mức độ dễ tiếp cận của chúng đang dẫn đến sự biến mất của tinh thần hacker
  • Tác giả lo ngại về hiện tượng chỉ còn lại trong ngành những người dùng thụ động không thực sự quan tâm đến mã, cấu trúc hay hiệu năng
  • Trước đây, người ta từng tràn đầy sự tò mò thuần túy và tính sáng tạo với IRC thâu đêm, thử nghiệm phần cứng và khám phá tầng thấp
  • Giờ đây chỉ còn lại công việc máy móc và sự thờ ơ, lặp đi lặp lại việc "xem xét bản vá do AI tạo ra"
  • Tác giả cảnh báo về nguy cơ việc sinh mã thiếu hiểu biết ngữ cảnh và năng lực thực sự trở thành tiêu chuẩn ngành, cùng thực tế những người thực sự giỏi bị gạt ra ngoài

Lịch sử chỉnh sửa bài viết

  • Thêm chú thích miễn trừ về ngày viết
  • Làm rõ lập trường về phạm vi chỉ trích hiệu năng (hệ thống phức tạp so với CRUD) để phản ánh ý kiến trên HN
  • Điều chỉnh một phần văn phong câu chữ và cách dùng ký hiệu để dễ đọc hơn

Bài viết liên quan

25 bình luận

 
roxie 2025-05-27

Bài viết thì thú vị, nhưng có vẻ quá nhiều bài có thể được tóm lại là: “Không dùng AI không phải là không thể sống, nhưng cứ thế tin tưởng vô điều kiện rồi bị nó thuần hóa cũng không phải điều tốt”, nên tôi hơi thấy mệt..
 
ifmkl 2025-05-26

LLM và AI đang tiếp tục phát triển theo thời gian. Chỉ mới vài tháng trước thôi, gần như khó có thể kỳ vọng vào những thứ như tính nhất quán của mã theo đúng như đã mô tả, nhưng giờ thì trong không gian làm việc đó, nếu tải lên dưới dạng tệp phần mã mà AI đã được yêu cầu cấu hình ban đầu, rồi khi viết mã mới luôn đưa ra chỉ dẫn phải tuân thủ phong cách mã hiện có, thì nó thực sự có thể tạo ra mã khá nhất quán.
 
crawler 2025-05-26

Xem các bài viết trước đây của người viết thì có vẻ họ là một lập trình viên phát triển game.
Vì kiến thức và tài liệu về phát triển game không được LLM học với khối lượng lớn, nên khác với trường hợp ứng dụng CRUD, có vẻ tác giả bài viết cảm nhận rõ hơn các giới hạn của LLM.

Tôi đã đọc hết và cuối cùng nghĩ rằng chính vì điều này mà tác giả có góc nhìn hơi thiên lệch.
Dĩ nhiên, làm theo nội dung bài viết thì gần như là điều mang tính giáo khoa nên cũng đúng thôi,
nhưng tôi cho rằng AI đã làm đủ tốt ở mảng CRUD và frontend, nơi có rất nhiều tài liệu để học.
Có lẽ cần tận dụng nó tốt nhất có thể trong chính domain của mình.
 
superscv 2025-05-26

Tôi nghĩ có lẽ đang có một chút hiểu lầm trong việc nắm bắt ý nghĩa mà tác giả muốn truyền đạt.
Tác giả tập trung vào hiệu năng, độ ổn định và kiến trúc dễ bảo trì cùng tính nhất quán của mã trong dự án mình quản lý; mà tiêu biểu là kiến trúc và tính nhất quán của mã lại là một trong những lĩnh vực mà các LLM hiện nay thực sự làm rất kém.

Đặc biệt, mảng web là nơi có rất nhiều người đổ vào làm, và tư tưởng kiểu “miễn sao chạy được là được” cũng rất mạnh, nên có vô số đoạn mã chất lượng thấp đã được triển khai. Và vì LLM được huấn luyện dựa trên những thứ đó, chất lượng đầu ra rơi xuống mức khó tin.

Cứ thử yêu cầu GPT kiểu: "Tôi định đưa vào frontend web, hãy triển khai thuật toán quicksort bằng js giúp tôi" xem. Nếu bạn không tìm ra vấn đề trong đầu ra của nó, thì tôi nghĩ cuộc thảo luận này cũng không còn nhiều ý nghĩa.
 
ohnul 2025-05-26

Xin chào. Vì tò mò nên tôi đã thử nói rằng: "Tôi định đưa vào frontend web, hãy triển khai giúp tôi thuật toán quicksort bằng js". Nhưng theo những gì tôi thấy thì khá khó để nhận ra vấn đề nằm ở đâu. Nếu bạn có thể chỉ ra giúp thì sẽ là trợ giúp rất lớn đối với tôi. Xin cảm ơn trước. https://chatgpt.com/share/68340f9b-b684-8002-8dd5-495d477065cd
 
ohnul 2025-05-26

Có vẻ như có gì đó không hoạt động tốt với liên kết nên tôi đăng lại. https://chatgpt.com/canvas/shared/68341217ae788191b66a523c948b1a8e
 
superscv 2025-05-26

quickSortInPlace() thứ hai mà bạn đính kèm cũng là một cách triển khai chậm.

Hãy thử chạy đoạn mã dưới đây.

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

Về cơ bản, có thể xem đây là đoạn code hoàn toàn không đồng cảm với gánh nặng của việc tạo, vận hành và hợp nhất collection. Với C++, từ khoảng 10 năm trước đã có các đề xuất/triển khai về Move Constructor, và việc luôn cực kỳ nhạy cảm với chi phí sao chép bộ nhớ vốn là điều cơ bản nhất. Về mặt cơ chế, quick sort là thuật toán có thể xác định index của mọi giá trị, và tốt hơn là mỗi field nên hỗ trợ random access.

Ngay cả khi không có những tối ưu hóa kiểu "dị" mà chỉ áp dụng những điểm trên, hiệu năng cũng chênh hơn 2 lần so với cách ở link bạn gửi.
 
dudlf016 2025-05-27

Tôi đã tự chạy thử thì thấy có xu hướng chậm hơn một chút, nhưng có vẻ không đến mức gấp đôi.

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();  
  
    // đến 2 chữ số thập phân  
    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

À.. tôi đã hiểu anh đang nói gì. Có vẻ anh đã không hiểu là cần phải so sánh cái gì với cái gì.... thuật toán quick sort không phải là có hai cách triển khai là quicksort và in-place đâu......

Ngay từ đầu, điều tôi xem là vấn đề chính là việc viết quickSortGPT() và quickSort() trong đoạn mã trên — đều là mã do GPT tạo ra — với phần hợp nhất Array được tích hợp sẵn, rồi cung cấp chúng cho người dùng AI.
 
dudlf016 2025-05-27

Trong câu trả lời của GPT có cả quickSort và quicSortInPlace, và vì trong bình luận có chỉ ra phần [...,quickSort(left), ...equal, ...quickSort(right)] nên tôi hiểu là phải so sánh quickSort với quickSort, còn quickSortInPlace với quickSortInPlace, nhưng có vẻ không phải vậy.
 
superscv 2025-05-27

Câu nói "quickSort thì với quickSort" khiến tôi ôm gáy ngao ngán.
 
superscv 2025-05-27

Khi đọc bài, xin hãy обязательно kiểm tra ngữ cảnh.

Hiện tại tôi không phải đang khoe trình độ lập trình của mình. Điều tôi đang chỉ ra là những đoạn mã tệ hại như quickSort() được dùng làm ví dụ ở đây lại đang được GPT ưu tiên xuất ra ở mức cao.

Nếu thử tìm kiếm với GPT nhiều lần, sẽ thấy khá thường xuyên nó trả về riêng kết quả của hàm quickSort(), và một lần nữa, quickSort() chỉ là một ví dụ mà thôi. Khi yêu cầu GPT viết mã cho mục đích công việc, nó thường xuất ra rất nhiều đoạn mã có chất lượng quá thấp (đây là trải nghiệm của người dùng trả phí). Tôi đồng cảm với ý kiến của tác giả bài viết rằng nếu bản thân lập trình viên không có khả năng phân biệt điều này, thì dự án rất dễ đi theo hướng hỏng dần, và từ đó mới dẫn tới mạch ngữ cảnh hiện tại.

Ngay xung quanh tôi, những dự án bị phủ đầy kiểu mã tệ hại như vậy đang tiếp tục gia tăng.
 
superscv 2025-05-27

Tất nhiên, phần so sánh phải là so sánh hiệu năng của hai hàm quickSort() và quickSortInPlace()........
 
superscv 2025-05-27

Chia sẻ kết quả cho thấy chênh lệch từ hơn gấp 2 đến tận 3~4 lần mà lại nói có vẻ không đến mức gấp 2 là sao?
 
superscv 2025-05-26

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

Hãy đặt đoạn mã này xuống và suy nghĩ kỹ về nó.
 
roxie 2025-05-27

Học hỏi được rất nhiều.
 
ohnul 2025-05-26

Cảm ơn vì câu trả lời!
 
crawler 2025-05-26

Trước hết, trong ý tôi nói về việc "ứng dụng AI trong phạm vi domain", thì chuyện con người đảm nhiệm thiết kế và điều phối là điều hiển nhiên...
Thực ra, có lẽ ngày xưa thì khác, nhưng bây giờ khi ai cũng biết giới hạn của LLM rồi thì đây là chuyện quá đương nhiên, đến mức chẳng cần phải nói ra nữa.

Tiếp theo là trường hợp những người bình thường không có kiến thức phát triển dùng LLM,
có vẻ như cả bài gốc, Hacker News lẫn tôi đều chưa từng nói về chuyện này, nhưng dù sao thì ngay cả trong trường hợp đó, chất lượng cũng đã đạt đến mức người dùng có thể hài lòng với kết quả.
Nếu không phải vậy thì Bolt.new, v0, hay cả Cursor chắc cũng không nhận được những đánh giá như bây giờ.
 
superscv 2025-05-26

Tóm tắt,

Tác giả: Nhà phát triển phải tự nâng cao và duy trì năng lực của mình. Thậm chí AI còn không hoạt động tốt đến vậy.

crawler: Ủa? Tôi thì dùng rất ổn mà?

superscv: Có nhiều vấn đề lắm...

crawler: Phải tinh chỉnh cho phù hợp rồi mới dùng chứ

superscv: Có vẻ ngay từ đầu đã đi quá xa khỏi thông điệp mà tác giả muốn truyền đạt..
 
crawler 2025-05-26

Có vẻ như bạn chưa hiểu rõ vì sao tôi nhắc đến lĩnh vực của tác giả và “miền chuyên môn của bản thân” nghĩa là gì.
Giao mọi quyết định cho AI mà không có suy nghĩ riêng thì có vẻ ngớ ngẩn,
nhưng tôi cũng không hiểu lắm những người đứng ở thái cực ngược lại.

Cuối cùng, điều tôi muốn hỏi là superscv đang nghĩ nên dùng LLM cho việc lập trình như thế nào thì tốt?
 
superscv 2025-05-26

Thường thì tôi không hay viết bình luận, nhưng lý do tôi đặc biệt để lại bình luận cho bài này là vì tôi đồng cảm khá nhiều với suy nghĩ của tác giả. Tôi nghĩ điều quan trọng không phải là AI hay LLM, mà là với tư cách một lập trình viên, bản thân "tôi" phải luôn sẵn sàng dù môi trường nào có đến đi nữa.

Do đặc tính của mã nguồn đã được huấn luyện, LLM chủ yếu cung cấp dữ liệu nằm gần mức trung bình của dữ liệu trực tuyến trên toàn thế giới. (Ví dụ quicksort trong js trước đó đã chứng minh điều này.) Vì vậy, tôi thường dùng nó để hỏi xem về mặt tư tưởng/thiết kế thì nó có phần nào đồng điệu hay lệch khỏi góc nhìn phổ biến hay không, hoặc để hỏi những nội dung mà từ trước đến nay khá khó biết nên hỏi ai.
 
superscv 2025-05-26

Tôi không rõ việc tiếp tục trao đổi thêm còn có ý nghĩa gì.

Ngay từ đầu, nếu ý kiến là mã do AI tạo ra có thể tiềm ẩn một số rủi ro, nên cần tinh chỉnh kỹ và sử dụng cho phù hợp, thì có lẽ chỉ cần giải thích xem trong bài viết của tác giả, suy nghĩ nào của tác giả là thiên lệch. Ngay cả trong bản tóm tắt cũng có câu mang ý tương tự: "có thể nhanh chóng cung cấp scaffold/mã nháp thiếu ngữ cảnh, nhưng thiết kế hoàn chỉnh và tinh chỉnh vẫn là phần việc của lập trình viên con người".
 
superscv 2025-05-26

Thông điệp của tác giả có phần hơi mạnh, nhưng nếu đọc kỹ bài viết thì đó không phải là "đừng dùng AI". Bài viết có đưa ra gợi ý về việc nên tận dụng nó như thế nào, và ý chính là bản thân lập trình viên không được thiếu năng lực.

Nếu nhìn vào lý do vì sao thông điệp của tác giả lại tạo cảm giác mạnh như vậy, thì có thể thấy nó được xây dựng như một góc nhìn phản biện trước quan điểm cho rằng sẽ có thể phát triển phần mềm bằng copilot (mang sắc thái phụ thuộc nhiều vào copilot trong phát triển). Vì thế, tác giả đã dẫn dắt thông điệp theo hướng rằng các lập trình viên không nên tự đặt mình vào một lập trường làm tổn hại giá trị tồn tại của chính mình.

Tác giả cũng không hề nhắn nhủ rằng "đừng dùng AI", nên nếu nói đến việc tận dụng AI thì rốt cuộc cũng sẽ nằm đâu đó ở một điểm thỏa hiệp. Vì vậy, thông điệp tổng thể cũng có phần khá giống với điều bạn vừa trả lời trước đó.

Tuy nhiên, trong nội dung bạn viết ban đầu, tôi khó đồng ý với phần gọi đó là một "góc nhìn thiên lệch", nên mới trả lời trước như vậy.
 
GN⁺ 2025-05-25
Ý kiến trên Hacker News

  • Nếu bạn muốn làm ra phần mềm phải vững chắc tuyệt đối như phần mềm cho máy tạo nhịp tim, hệ thống dẫn đường tên lửa hay xe tăng M1, thì hãy dẹp AI coding agent sang một bên và tự rèn tư thế tự học
    Nhưng đa số chúng ta đâu có làm những thứ như vậy, mà chủ yếu tạo ra các ứng dụng CRUD có yêu cầu gần như y hệt nhau, chỉ khác đôi chút ở schema và cách tích hợp
    Thực tế thì phần mềm mà đa số chúng ta làm chẳng có gì mới
    Trong nhiều trường hợp, tái sử dụng tri thức sẵn có vốn đã là lựa chọn tốt nhất
    Với tôi, coding agent là một phiên bản cực đại của việc tái sử dụng code trong quá khứ
    Nói thêm thì, trớ trêu là chính bài này cũng cho cảm giác như do AI viết

    • Tôi vốn cũng không muốn viết code low-level mang tính mission-critical
      Tôi không nghĩ các công cụ AI hữu ích vô điều kiện như tác giả bài viết, nhưng tôi cũng quá chán kiểu tranh luận “không làm system programming bằng C thì không phải lập trình viên” rồi
      Tôi thích làm frontend
      Tôi cũng không hề muốn tự tay làm thư viện đồ họa cấp thấp
      Tôi không phải kiểu thức dậy lúc tờ mờ sáng để hack code, nhưng tôi vẫn có đam mê và tự hào với công việc của mình
      Tôi không nghĩ ai cũng phải mang tư thế cực đoan như tác giả
      Theo tôi, thị trường phần mềm cần có sự đa dạng

    • Phản bác lập luận của tác giả thì được, nhưng nói rằng chính bài này là do AI viết thì hơi quá
      Tác giả đã hòa trộn lối diễn đạt sống động, các ẩn dụ mạnh và cả kiểu hài hước thật sự thú vị vào xuyên suốt bài theo đúng phong cách riêng của mình
      Với năng lực hiện tại, để LLM viết ra kiểu bài như thế này là cực kỳ khó
      Đây không phải AI, mà là một bài viết hay
      Dù có đồng ý với lập luận hay không, vẫn phải công nhận bút lực của tác giả

    • Ngay trong nguyên văn cũng có đoạn này
      “Có lẽ bạn sẽ không trực tiếp viết thứ code giúp máy bay bay trên trời hay thứ code gắn liền với sinh mạng con người. Hầu hết mọi người đều không làm vậy. Nhưng kể cả khi bạn làm ở một doanh nghiệp chuyên vá chằng vá đụp các ứng dụng CRUD đơn giản, cuối cùng bạn vẫn có trách nhiệm giữ sự tôn trọng và phẩm giá cho người dùng”
      Điều này nhấn mạnh rằng dù phần mềm có đơn giản đến đâu thì vẫn cần một mức trách nhiệm tối thiểu

    • Thực tế, chính tác giả cũng thừa nhận một vài trường hợp AI hữu ích
      Vấn đề cốt lõi của tác giả là chúng ta gọi AI là “copilot”, khiến người mới có thể quá tin nó
      Copilot thật sự phải là một người dày dạn và là đồng đội, còn AI hiện giờ thì có khi một nửa xác suất là đồng đội tệ hại
      “Lúc này, chúng ta đang để sự tò mò và quyền chủ động ở bên ngoài hệ thống. Những người vốn có tố chất phát triển thì lại đang nguội dần nhiệt huyết vì chỉ ngồi duyệt patchset của AI. Terminal biến thành spreadsheet, debugger biến thành quan tài”
      Tuy nhiên, AI rốt cuộc cũng chỉ là một dạng trừu tượng hóa
      Cũng như người ta lo rằng khi tự động hóa trở nên hiển nhiên như GC (garbage collector) thì nền tảng cơ bản sẽ bị bỏ quên, AI cũng làm dấy lên nỗi lo rằng các năng lực lập trình/học tập rất nền tảng cuối cùng có thể biến mất
      Nhờ trừu tượng hóa, web developer vẫn có thể làm ra phần lớn các website tốt mà không cần hiểu sâu cấu trúc tầng dưới của stack
      Nhưng AI là một lớp trừu tượng đầy lỗ hổng, nên nó vẫn có thể hoạt động ở mức nào đó ngay cả khi bạn thật sự không nắm cơ bản
      Vấn đề là đến một lúc nào đó bạn sẽ phát hiện những bug nghiêm trọng đã bị che giấu, và khả năng debug, giải quyết vấn đề, tự học là phần mà AI không thể thay thế
      Vì vậy có nỗi lo rằng nếu chỉ học theo cách dễ nhờ AI thì những năng lực nền tảng quan trọng có thể bị lược bỏ
      Cuối cùng thì trưởng thành thông qua lặp đi lặp lại và tự va chạm trực tiếp mới là cách học thật sự
      Nếu AI trừu tượng hóa luôn cả chính quá trình “học”, thì về lâu dài năng lực của lập trình viên sẽ suy yếu
      Tất nhiên không phải cứ chỉ dùng AI là ai cũng trở nên ngốc đi, và những người chủ động học hỏi vẫn sẽ tồn tại
      Nhưng xét tổng thể, tỷ lệ đó rất có thể sẽ giảm xuống
      Vì bản thân trải nghiệm “tự suy nghĩ và tự làm” dành cho người mới có thể biến mất
      Và lớp trừu tượng mang tên AI rốt cuộc có quá nhiều khe hở
      Với người mới, có thể trông như AI làm hết mọi thứ, nhưng cuối cùng vẫn cần năng lực cốt lõi về lập trình và debug
      Nên nếu muốn thật sự bắt được vấn đề trong phần code do AI tạo ra, bạn vẫn bắt buộc phải tích lũy kỹ năng
      Tôi cũng đang tận dụng AI coding assistant khá tốt
      Nhưng vì nó có nhược điểm, nên kết luận của tôi là không thể chỉ nhìn nó như thứ gì cũng tuyệt vời

    • Sau khi làm một video hài ngắn của riêng mình bằng Google Whisk rồi đăng lên TikTok, tôi vào xem thì thấy toàn nội dung do AI tạo hoặc video người ta sao chép lẫn nhau
      Tôi từng nghĩ “sáng tạo nguyên bản” hẳn phải có điều gì đó thật sự đặc biệt, nhưng rốt cuộc chúng ta là những thực thể bị tái tạo quá dễ dàng
      Kể cả nếu chúng ta đăng video code mỗi ngày lên TikTok, rốt cuộc cũng chỉ là vô tận những ứng dụng giống hệt nhau lặp lại
      Như Elon Musk nói, giờ có cảm giác thứ duy nhất còn lại là thật sự đi tới sao Hỏa
      Hai năm trước tôi cũng từng nói rằng LLM không còn “hallucination” nhiều đến thế nữa, và dù người ta vẫn tin con người là không thể thiếu, tôi muốn nói rằng điều đó ngày càng không còn đúng
      Tôi muốn nhắc lại cuộc nói chuyện này sau 2 năm nữa

  • “Máy móc là thứ có thật. Silicon là thật, DRAM là thật, L1 cache và false sharing là thật, cả chuyện branch predictor tung đồng xu cũng là thật. Chỉ cần bạn quan tâm, bạn có thể chạm vào tất cả những thứ đó”
    Đã lâu lắm rồi tôi mới thấy một câu văn đẹp như vậy

    • Tôi cũng cảm thấy y hệt
      Tác giả viết vui nhộn theo phong cách Dave Barry nên tôi đã bật cười mấy lần
      Tôi thích cách bài viết diễn đạt những suy nghĩ rất đồng cảm về Copilot một cách hài hước và xuất sắc

  • Điều thường bị bỏ sót trong các cuộc thảo luận về phát triển phần mềm là không phải chỉ có “kết quả đầu ra của đoạn code” mới là tất cả
    Chính hành trình đi tới kết quả đó, với vô số đánh đổi, mới cực kỳ quan trọng
    Chỉ cần cùng một junior làm một tính năng trong codebase hơi phức tạp là bạn sẽ lập tức cảm nhận được, với tư cách kỹ sư già dạn, mình đang vô thức thực hiện những trade-off nào
    AI cũng có khái niệm về các trade-off này, nhưng phần lớn chỉ ở mức học từ quan sát
    Đúng là nó giúp “viết code tốt hơn”, nhưng cuối cùng chuyện phán đoán và tư duy vẫn là phần việc của con người
    LLM không “suy nghĩ”
    Và khi AI càng tiến bộ, nguy cơ con người càng suy nghĩ ít đi là có thật

  • Với tôi, cả ưu lẫn nhược của Copilot đều rất dễ đồng cảm
    Nhưng khác với hình ảnh hacker hay “tinh thần thủ công” thời niên thiếu, các engineer lúc nào cũng vẫn là engineer
    Lý do những công nghệ cốt lõi ngày nay từng xuất hiện một cách gian nan là vì vào thời đó người ta buộc phải giải quyết những trở ngại ấy bằng mọi giá
    Nếu khái quát hóa lịch sử đầy kịch tính đó thành kiểu “ngày xưa vốn là vậy” thì rất dễ rơi vào góc nhìn thiên lệch

    • Là một software engineer đã hơn 20 năm phát triển theo cách khó khăn, với tôi việc tự giải các bài toán khó vừa là đặc quyền vừa là niềm xứng đáng
      Những cập nhật CRUD đơn giản thì lặp lại và buồn tẻ, nhưng những lúc hiếm hoi xuất hiện bài toán đau đầu, hay khoảnh khắc đem kiến thức học từ thời đại học ra dùng, cùng các trường hợp ngoại lệ như recursive algorithm, đều là những viên ngọc trong sự nghiệp
      Tôi mong rằng các software engineer do AI dẫn dắt trong tương lai cũng sẽ trân trọng những trải nghiệm đó hơn
      AI có thể đưa ra đáp án nghe có vẻ logic, nhưng đôi khi lại sai hoàn toàn theo cách rất nguy hiểm, nên vẫn cần có người thật sự biết phải làm gì
      Khi AI “hallucination” hoặc thiếu ngữ cảnh, sẽ luôn có lúc con người buộc phải là người trực tiếp giải quyết vấn đề

  • Chuẩn so sánh của tôi không phải pair programming mà là lập trình viên outsource ở nước ngoài
    Thực ra lý do Copilot, Cursor và các công cụ AI khác cho cảm giác tốt hơn hẳn là vì giờ tôi không còn phải lãng phí thời gian vào những cuộc Zoom với vấn đề giao tiếp mơ hồ, rào cản ngôn ngữ và chênh lệch thấu hiểu nữa
    Ví dụ như kiểu “liên quan tới root node có thêm hàm isChild(trả về boolean), nhưng không liên quan tới việc kiểm tra có parent hay không”, hoặc “API parameter đột nhiên không nhận array nữa” — những chuyện rất hay gặp khi outsource
    Khi làm việc với AI, dù có phát sinh mấy vấn đề đó, chỉ cần nói ngay là sai và giải thích lý do thì nó sửa rất nhanh
    Hầu như không có chuyện giao tiếp, hiểu lầm hay lãng phí thời gian như khi làm với con người
    Một khi AI được nối dễ dàng với ticket trên Jira, khoảng 80% công việc phát triển sẽ biến thành viết ticket và làm vai trò giám sát
    Tất nhiên điều đó không có nghĩa vai trò của engineer biến mất — bộ phận Biz cũng đâu thể viết ticket tốt, và cuối cùng vẫn phải có ai đó chịu trách nhiệm sau cùng
    Dù vậy, nhiều tổ chức sẽ quên mất điều này, và kết quả là có thể mở đường cho những tai nạn lớn

  • Điều tôi rút ra cốt lõi từ bài này là
    “Chúng ta sẽ bắt đầu tung hô hiện trạng lạc hậu, phình to và bị trừu tượng hóa quá mức của phần mềm như thể đó là đỉnh cao. Văn hóa vắt kiệt hiệu năng đến tận cùng, hay xây dựng hệ thống gọn, sắc và sáng rõ sẽ chỉ còn lại như chuyện kể ngày xưa”
    Tôi lo rằng các library hay architectural pattern được tạo ra trước năm 2023 rồi sẽ bị cố định như bộ khung trung tâm của dữ liệu mà LLM học từ đó
    Thay vì tiếp tục đổi mới, rất có thể những dependency chồng chất và đống code bừa bộn tích lũy suốt 30 năm qua sẽ kéo dài mãi mãi
    Tôi cũng lo Javascript sẽ sống mãi luôn

  • Gần đây tôi thật sự cảm nhận được áp lực từ leadership kiểu “chúng ta chưa dùng AI đủ nhiều”, “nếu áp dụng AI thì có thể cắt một nửa timeline hiện tại” mỗi ngày
    Thực tế là bị ép phải đưa thêm công cụ AI mới vào để đạt KPI, nếu không thích nghi còn bị nhắc tới chuyện cắt giảm nhân sự trong team
    Cảm giác như thế giới phát điên thật sự rồi
    AI lúc nào cũng được đóng gói như “công cụ thay thế công việc của người khác”
    Nhưng lý do AI có vẻ tốt chỉ đúng khi tôi đánh giá công việc của người khác mà thật ra không hiểu đủ rõ công việc đó
    Có cảm giác ban lãnh đạo đang cầm cây búa mang tên AI và thử đóng đinh tất cả mọi thứ trên đời

    • Thật sự phải nghĩ cách nào đó để tinh gọn cấu trúc quản lý, và tìm cách đổ thời gian vào những việc thật sự tạo ra năng suất
      Tôi hy vọng có một văn hóa tập trung vào công việc thực tế và delivery hơn là chỉ chăm chăm vào chuyện dùng AI

    • Thật ra đây chỉ là mô típ quen thuộc của “hype cycle” trong ngành AI
      Khi tình hình lắng xuống, chỉ những công cụ và kỹ thuật thực sự dùng được mới còn lại, còn phần lớn sẽ biến mất
      Quan điểm của tôi là phải nhìn cho khôn ngoan xem cái gì thực sự sẽ trụ lại, và nếu có thể tạo ảnh hưởng lên sự thay đổi đó thì đó sẽ là con đường để tiếp tục sống sót về sau, nên chúng ta cần cố gắng như vậy

    • Sự ép buộc “phải triển khai nhanh” hiện tại thật ra hoàn toàn trái ngược với bản chất của engineering/design/làm kỹ thuật mà tôi từng biết
      Trước đây, nguyên tắc chuẩn là phải cân nhắc cẩn thận việc có nên đưa một tool, ngôn ngữ hay dịch vụ vào hay không, rồi chuẩn bị căn cứ vì sao nó phù hợp với trường hợp của chúng ta, có ưu và nhược điểm gì
      Quy trình ra quyết định kiểu “vì sao cần cái này, vì sao dịch vụ này hợp lý hơn” vốn là điều bình thường
      Từng có cả quy trình kiểm thử xem công nghệ đó có thật sự cần thiết để triển khai không, rồi sau đó đánh giá hiệu quả hay hiệu suất áp dụng
      Doanh nghiệp hiện nay đang ngày càng rời xa cách làm lành mạnh đó

    • Ảo tưởng rằng “AI luôn là công cụ có thể thay thế công việc của người khác” đang lan rộng quá mức
      Đúng là có nhiều việc lặp đi lặp lại đơn giản, nhưng đa số công việc nếu muốn làm tốt thì vẫn đòi hỏi sắc thái và độ tinh tế riêng, mà những thứ đó có nguy cơ biến mất hết trong quá trình tự động hóa
      Tôi không đồng ý với kiểu nói “AI làm được 80% là đủ rồi”
      Sai sót sẽ ảnh hưởng tới toàn bộ hệ thống, còn những người đánh giá thì khó tránh khỏi thiếu trải nghiệm thực tế tại hiện trường

    • Tôi nghĩ chẳng bao lâu nữa các vị trí quản lý sẽ biến mất nhanh hơn
      Từ giờ tới lúc đó, cố lên nhé mọi người

  • Tác giả bài này rõ ràng có vẻ là một lập trình viên C++
    Trên thực tế, AI coding assistant hiếm khi hoạt động ra hồn với C++, còn những người dùng hiệu quả thì phần lớn là trong ngôn ngữ scripting hoặc ứng dụng CRUD

    • Xem các bài cũ của tác giả thì có vẻ là một game developer
      Vì tri thức và tài liệu về phát triển game không được LLM học với quy mô lớn, nên khác với trường hợp ứng dụng CRUD, có lẽ tác giả cảm nhận giới hạn của LLM rõ rệt hơn

  • Một phần của bài này nghe như đang được đọc bằng giọng của nhân vật ‘Bertram Gilfoyle’ trong series Silicon Valley
    Không biết có mình tôi thấy vậy không

  • Cốt lõi là luôn phải giữ được năng lực “kính viễn vọng”
    Nhờ coding agent, làm việc ở mức độ cao hơn thì không sao, nhưng khi cần vẫn phải có khả năng chui sâu vào code, tự hiểu và tự sửa thì mới an toàn