Công cụ lập trình AI đang khiến nhà phát triển trở nên kém thông minh hơn: Dữ liệu đã chứng minh

Gần đây, The New Stack đã đăng tải một bài viết có tác động mạnh mẽ không kém gì một sự cố máy chủ vào ngày Black Friday. Título của bài viết ấy rất thẳng thắn: "Tôi bắt đầu mất đi khả năng lập trình của mình".

Người viết không phải là sinh viên mới ra trường, cũng không phải ai đó mới vào nghề được ba tháng. Đó là một lập trình viên đang làm việc thực tế, trực tiếp sản xuất code, thú nhận rằng các công cụ AI đã âm thầm "ăn mòn" kỹ năng của họ từ bên trong. Bài viết lan truyền như điên vì một lý do tồi tệ nhất: sự đồng cảm. Hàng ngàn lập trình viên đã đọc nó và cảm thấy rung động bởi chính sự tự nhận thức khó chịu đó.

Sự đồng thuận tập thể "chà, tôi cũng vậy" này đáng lẽ phải khiến các lãnh đạo kỹ thuật ở khắp nơi phải hoảng sợ.

Nút Tab là một cái bẫy

Có một con số đáng được xem xét kỹ hơn: các lập trình viên chấp nhận các gợi ý code do AI tạo ra, với rất ít sự chỉnh sửa, trong khoảng 40% đến 60% thời gian. Nhiều nghiên cứu từ GitHub, JetBrains và các nhà nghiên cứu độc lập đều đưa ra con số nằm trong phạm vi này.

Đó không phải là thống kê về năng suất. Đó là thống kê về sự tin tưởng.

Hãy tưởng tượng quy trình làm việc. Copilot đề xuất phần thân của một hàm. Tên biến trông ổn. Kiểu trả về khớp. Lập trình viên nhấn Tab. Xong. Chuyển sang vấn đề tiếp theo.

Nhưng cụm từ "trông ổn" đang phải gánh vác một sức nặng đáng sợ trong câu chuyện này. Một ví dụ thực tế sẽ cho thấy những gì ẩn đằng sau vẻ bề ngoài "trông ổn". Giả sử một lập trình viên cần một hàm để tìm các bản ghi trùng lặp trong danh sách người dùng:

def find_duplicate_emails(users: list[dict]) -> list[str]:
    """Find emails that appear more than once."""
    seen = set()
    duplicates = set()
    for user in users:
        email = user["email"]
        if email in seen:
            duplicates.add(email)
        seen.add(email)
    return list(duplicates)

AI tạo ra đoạn code này. Nó chạy ổn. Gửi đi (ship).

Tuy nhiên, điều gì sẽ xảy ra nếu user["email"] là None? Thế nào với việc viết hoa viết thường — liệu [email protected] có giống [email protected] không? Nếu dict đó không hề có khóa "email" thì sao? Một lập trình viên tự viết đoạn code này từ đầu sẽ ít nhất cũng gặp phải một trong những trường hợp ngoại lệ (edge cases) đó trong quá trình test. Nhưng người đã nhấn Tab thì không bao giờ nghĩ đến chúng.

Tỷ lệ chấp nhận này không đo lường hiệu quả. Nó đo lường tốc độ sụt giảm của ngưỡng kỹ năng.

Não bộ GPS, nhưng áp dụng cho Code

Các nhà khoa học nhận thức đã nghiên cứu những gì xảy ra với những người phụ thuộc vào GPS trong nhiều năm. Kết quả rất ảm đạm. Người dùng GPS nặng nề cho thấy sự thu hẹp có thể đo lường được trong hoạt động của hồi hải mã (hippocampus) — vùng não chịu trách nhiệm về trí nhớ không gian và định hướng. Họ không thể chỉ đường cho những nơi mà họ đã lái xe qua hàng trăm lần. Nếu thả họ cách nhà hai khối mà không có điện thoại, họ sẽ đứng hình.

Não bộ không quên tất cả cùng một lúc. Nó chỉ ngừng luyện tập. Các nơ-ron không cùng kích hoạt sẽ ngừng kết nối với nhau. "Dùng nó hoặc mất nó" không chỉ là một khẩu hiệu động viên, đó là khoa học thần kinh.

Bây giờ hãy áp dụng cơ chế đó cho lập trình. Mỗi khi một lập trình viên mô tả vấn đề trong một chú thích và để AI lấp đầy phần triển khai, một lần luyện tập nhỏ bị bỏ qua. Một lần bỏ qua không có nghĩa gì. Nhưng một ngàn lần bỏ qua trong sáu tháng có nghĩa là lập trình viên đó không còn thực hiện được bài tập nữa.

Não bộ GPS trong terminal trông như thế này. Một lập trình viên có kỹ năng debug đầy đủ sẽ nhìn thấy thông báo lỗi sau:

$ python app.py
Traceback (most recent call last):
  File "app.py", line 47, in process_batch
    result = transform(item)
  File "app.py", line 31, in transform
    return {"id": item.id, "value": item.score / item.baseline}
ZeroDivisionError: division by zero

Não bộ họ phản hồi ngay lập tức: "Ok, item.baseline bằng 0 ở đâu đó. Baseline lấy từ đâu? Là do người dùng nhập? Hay là mặc định của cơ sở dữ liệu? Để tôi kiểm tra file migration và định nghĩa model."

$ grep -n "baseline" models/item.py
12:    baseline: float = Field(default=0.0)

Tìm thấy rồi. Giá trị mặc định là 0.0. Các bản ghi mới chưa được hiệu chuẩn sẽ làm hỏng phép chia. Sửa giá trị mặc định, thêm mệnh đề bảo vệ, viết test, xong.

Toàn bộ chuỗi đó có thể mất khoảng ba phút và không có sự can thiệp của AI. Đó là khả năng nhận diện mẫu được xây dựng từ hàng trăm phiên debug tương tự.

Bây giờ hãy xem cùng một tình huống với một lập trình viên bị teo навык (kỹ năng):

$ python app.py
ZeroDivisionError: division by zero

Họ sao chép toàn bộ traceback. Dán vào trợ lý AI của họ. "Sửa lỗi này". AI đề xuất thêm một khối try/except xung quanh phép chia. Lập trình viên áp dụng bản vá. Lỗi biến mất. Nhưng vấn đề thực tế — một giá trị mặc định tồi trong model dữ liệu — vẫn còn. Nó sẽ cắn trúng người khác sau này, có lẽ là trong môi trường production, có lẽ là lúc 2 giờ sáng.

Khoảng cách giữa hai lập trình viên này không phải là tài năng. Đó là sự luyện tập.

Code Review đang trở thành con dấu cao su

Điều kỳ lạ xảy ra khi mọi pull request (PR) đều chứa code do AI tạo ra. Đoạn code đó trông hoàn hảo. Tên biến sạch sẽ. Gợi ý kiểu (type hints) đúng. Định dạng nhất quán. Các mẫu mã phù hợp.

Đây là điều tồi tệ nhất có thể xảy ra đối với chất lượng code review.

Người kiểm duyệt con người là những máy khớp mẫu. Họ được rèn luyện — qua nhiều năm đọc code lộn xộn, thông minh, và bị hỏng — để phát hiện những điểm bất thường. Nhưng code do AI tạo ra không có điểm bất thường. Nó có bề mặt đồng nhất, bóng bẩy khiến người kiểm duyệt rơi vào trạng thái lướt qua.

Hãy xem xét truy vấn cơ sở dữ liệu do AI tạo ra trong ứng dụng Node.js này:

async function getUserOrders(userId: string): Promise<Order[]> {
  const orders = await db.query(
    `SELECT * FROM orders WHERE user_id = $1 ORDER BY created_at DESC`,
    [userId]
  );
  return orders.rows.map(row => ({
    id: row.id,
    total: row.total,
    status: row.status,
    createdAt: row.created_at,
    items: JSON.parse(row.items_json),
  }));
}

Code sạch. Truy vấn tham số hóa. Ánh xạ đúng. Một người kiểm duyệt sẽ liếc nhìn và phê duyệt. Nhưng không có phân trang. Với người dùng có 50.000 đơn hàng, nó trả về tất cả mọi thứ. SELECT * lấy mọi cột bao gồm cả các blob dữ liệu lớn tiềm ẩn. JSON.parse trên items_json sẽ lỗi nếu cột đó là null hoặc sai định dạng. Không có vấn đề nào trong số này hiển thị ở cấp độ bề mặt.

Khi code luôn trông như thể được viết bởi một senior developer chu đáo, người kiểm duyệt ngừng mong đợi vấn đề. Đó không phải là hiệu quả. Đó là một nông trại bug tiềm ẩn.

Khoảng trống của Lập trình viên Junior

Đây là nơi cuộc hội thoại trở nên u ám.

Các senior developer áp dụng công cụ AI ít nhất cũng đã có nhiều năm "sẹo" (kinh nghiệm xương máu). Họ đã dành những ngày cuối tuần để bisect lịch sử git tìm các regression. Họ đã theo dõi thủ công rò rỉ bộ nhớ thông qua các destructor của C++. Họ đã dán mắt vào hexdumps. Những trải nghiệm đó để lại các đường dẫn thần kinh vĩnh viễn mà AI có thể xói mòn nhưng chưa thể phá hủy hoàn toàn. Tuy nhiên, là "chưa".

Các lập trình viên junior đang gia nhập ngành ngay lúc này? Nhiều người trong số họ đang xây dựng trên nền cát.

Một lập trình viên junior vào năm 2026 có thể dựng (scaffold) một ứng dụng full-stack nguyên chiếc trong một buổi chiều với sự hỗ trợ của AI. Đầu quả ấn tượng. Học hỏi bằng không. Họ chưa bao giờ ngồi với một useEffect bị hỏng trong ba giờ cho đến khi họ thực sự hiểu mảng dependency. Họ chưa bao giờ viết tay một câu lệnh join trong SQL và sai theo bốn cách khác nhau trước khi làm đúng. Họ chưa bao giờ triển khai một danh sách liên kết (linked list) tồi, rồi bớt tồi, rồi mới đúng.

Sự đấu tranh chính là sự giáo dục. Tước bỏ nó và những gì còn lại chỉ là một người có thể vận hành công cụ nhưng không thể lý luận về những gì công cụ tạo ra. Đó không phải là kỹ sư phần mềm. Đó là người điều phối.

Một số người gạt phắt đi điều này. "Công cụ sẽ không biến mất. Thích nghi hay là chết." Chắc chắn rồi. Nhưng có một sự cách biệt lớn giữa một lập trình viên chọn AI vì họ hiểu code bên dưới và một người cần AI vì họ chưa bao giờ hiểu nó. Người đầu tiên bắt được lỗi sai của AI. Người thứ hai gửi chúng đi (ship).

Vấn đề mượn của ngày mai

Các công cụ lập trình AI làm tăng đầu ra. Không ai tranh cãi điều này. Code boilerplate biến mất. Các API lạ lẫm trở nên dễ tiếp cận. Rào cản ngôn ngữ thu hẹp lại. Một lập trình viên có công cụ AI tốt sẽ gửi đi nhiều code hơn mỗi tuần so với chính họ khi không có chúng.

Nhưng đầu ra và năng lực không phải là từ đồng nghĩa.

Nếu khả năng giải quyết vấn đề nguyên thủy của một lập trình viên giảm 5% mỗi năm trong khi năng suất được hỗ trợ bởi công cụ tăng 20% mỗi năm, các bảng điều khiển (dashboard) trông sẽ tuyệt vời. Các vé (ticket) đóng nhanh hơn. Vận tốc sprint (sprint velocity) tăng lên. Ban quản lý rất vui vẻ.

Sau đó, AI ảo giác một lỗ hổng xác thực tinh vi trong quy trình thanh toán. Hoặc LLM tạo ra một hàm đệ quy hoạt động trên dữ liệu test nhưng bị tràn stack (stack-overflow) trên dữ liệu quy mô production. Hoặc nhà cung cấp đám mây gặp sự cố và kỹ sư trực nhật (on-call) cần debug một hệ thống phân tán chỉ với log và curl.

Không ai nhận ra họ không tìm được đường cho đến khi vệ tinh GPS tắt. Và trong phần mềm, vệ tinh luôn tắt vào một lúc nào đó. Môi trường production không quan tâm đến chuỗi công cụ (toolchain) của bạn.

Một danh sách cụ thể những gì đang mục nát

"Khả năng lập trình" quá mơ hồ. Đây là những gì thực sự đang suy thoái cụ thể:

Trực giác Debug — khả năng nhìn vào một hệ thống bị hỏng và hình thành giả thuyết trong dưới 30 giây. Điều này chỉ đến từ sự lặp lại. Không có đường tắt. AI bỏ qua các lần lặp lại này.

Mô hình tinh thần cấp hệ thống — nắm giữ kiến trúc trong đầu, theo dõi luồng dữ liệu qua các ranh giới dịch vụ, dự đoán điều gì sẽ hỏng khi thành phần X bị sập. Các lập trình viên thuê ngoài triển khai ngừng xây dựng những bản đồ này.

Đọc code phản biện — không phải kiểm tra cú pháp, mà là hiểu ý định. Nhận ra rằng một lớp caching bị thiếu. Phát hiện ra rằng cơ chế thử lại (retry) sẽ gây ra hiệu ứng đàn bạo (thundering herd). Điều này teo đi khi hầu hết code mà lập trình viên đọc được do một mô hình tối ưu hóa cho "trông đúng đắn" tạo ra.

Phân tách vấn đề — chia nhỏ một nhiệm vụ khổng lồ thành các mảnh nhỏ có thể giải quyết được. Khi AI có thể nuốt chửng một lời đề xuất mơ hồ và nhả ra một giải pháp hoàn chỉnh, các lập trình viên ngừng tập luyện cơ bắp khiến họ trở thành kiến trúc sư thay vì người gõ phím.

Lý giải thuật toán — hiểu tại sao bản băm (hash map) vượt trội hơn mảng đã sắp xếp cho mẫu truy cập cụ thể này. Biết khi nào O(n log n) quan trọng và khi nào thì không. Các khái niệm này phai nhạt khi một thứ gì đó khác luôn chọn phương pháp tiếp cận.

Điều gì thực sự hữu ích

Việc xác định sự mục nát thì dễ. Đảo ngược nó mới là phần khó.

Thực hành đều đặn không dùng AI. Không phải như một hình phạt. Mà như một sự rèn luyện. Một lần một tuần, hãy chọn một nhiệm vụ nhỏ và làm nó từ đầu. Viết hàm. Debug lỗi. Đọc tài liệu. Giữ cho các đường dẫn thần kinh ấm áp. Vận động viên không bỏ qua các bài tập vì đã có trận đấu.

Đào tạo junior có cấu trúc với sự đấu tranh bắt buộc. Các công ty tuyển dụng lập trình viên mới vào nghề cần các giai đoạn không dùng AI rõ ràng. Hãy để các kỹ sư mới viết code tệ. Hãy để họ debug trong nhiều giờ. Hãy để họ cảm thấy sự bực bội của một điều kiện tranh chấp (race condition) mà họ không hiểu. Sau đó — sau khi nền tảng đã tồn tại — hãy trao cho họ công cụ AI.

Code Review khắt khe hơn, đặc biệt là cho code do AI tạo ra. Nếu một PR được tạo ra với sự trợ giúp của AI (và nó nên được dán nhãn như vậy), người kiểm duyệt nên tăng sự kiểm tra, không phải giảm. Hỏi: "Điều gì xảy ra nếu đầu vào này là null? Độ phức tạp thời gian là bao nhiêu? Test cho trường hợp không mong muốn (unhappy path) ở đâu?"

Công cụ AI nên dạy, không chỉ sản xuất. Kết quả tốt nhất không phải là một AI viết code cho các lập trình viên. Đó là một AI giải thích lý do của nó, làm nổi bật các sự đánh đổi, và hỏi "bạn có chắc về trường hợp ngoại lệ này không?". Một số ma sát là một tính năng. Những lập trình viên chống lại ma sát đó là những người cần nó nhất.

# Một thói quen tập luyện đơn giản cho bất kỳ lập trình viên nào
# Chọn một cái mỗi tuần. Không được phép dùng AI.

Thứ Hai:    Debug một bài test thất bại chỉ bằng cách đọc stacktrace
Thứ Ba:     Triển khai một hàm tiện ích nhỏ từ trí nhớ
Thứ Tư:     Review một PR và viết 3 bình luận mang tính chất xây dựng
Thứ Năm:    Giải thích kiến trúc của một hệ thống trên bảng trắng
Thứ Sáu:    Đọc 200 dòng code nguồn mở quen thuộc

Các công ty cần kiểm tra sự hiểu biết thực tế. Các cuộc phỏng vấn kỹ thuật kiểm tra "bạn có thể giải quyết điều này với Copilot không" là vô giá trị. Hãy kiểm tra xem ứng viên có thể đọc code, phát hiện lỗi, giải thích sự đánh đổi và lý luận về các hệ thống hay không. Ngưỡng không nên giảm chỉ vì công cụ được cải tiến.

Kết thúc khó chịu

Ngành công nghệ đang chạy một thí nghiệm không kiểm soát trên hàng triệu lập trình viên cùng một lúc. Các chỉ số ngắn hạn trông tuyệt vời. Tốc độ tăng lên. Đầu ra tăng lên. Sự tự tin tăng lên.

Bên dưới những chỉ số đó, một thứ gì đó đang rỗng tuếch một cách âm thầm. Các khả năng nhận thức phân biệt một lập trình viên với một thiết bị đầu cuối chấp nhận code đang suy yếu. Bạn có thể thấy nó ở lập trình viên bị đứng hình khi Copilot bị sập. Trong lần review cho lọt qua một lỗ hổng SQL injection. Ở cậu trai junior đã gửi đi năm mươi PR nhưng chưa bao giờ thực sự debug một mình thứ gì.

Các công cụ lập trình AI không xấu. GPS cũng không xấu. Nhưng một tài xế giao hàng không thể đọc được biển báo đường phố là một gánh nặng, và một kỹ sư không thể debug được stack trace là một quả bom hẹn giờ.

Những lập trình viên vẫn còn được thuê trong năm năm tới không phải là những người áp dụng AI nhanh nhất. Họ là những người sử dụng công cụ AI trong khi giữ kỹ năng của sắc bén đủ để bắt lúc AI sai. Điều đó đòi hỏi kỷ luật. Nó đòi hỏi đôi khi chọn con đường chậm hơn một cách cố ý. Nó đòi hỏi thừa nhận rằng sự tiện lợi có cái giá phải trả.

Sự thay thế là một ngành công nghệ tràn ngập các lập trình viên có năng suất đáng kinh ngạc cho đến đúng thời điểm họ cần thực sự suy nghĩ.

Khoảnh khắc đó luôn đến. Và nó không bao giờ tự lên lịch trước.