Học lập trình thời đại LLM: Khi AI giúp bạn xây dựng thứ vượt quá tầm hiểu của chính mình

Một độc giả gửi cho tác giả Mark Seemann lá thư dài kể về hành trình xây dựng hệ thống phần mềm lớn nhờ LLM dù không có nền tảng khoa học máy tính chính quy — và cảm giác bất an khi nhận ra mình đã tạo ra thứ vượt quá tầm hiểu. Seemann, người đã lập trình hơn 30 năm, trả lời thẳng thắn về mối quan hệ giữa lập trình viên và AI: ông không phản đối AI, nhưng hoài nghi sâu sắc về việc nó có thể thay thế quá trình học tập nền tảng hay không.

Khi AI thu hẹp khoảng cách giữa ý tưởng và sản phẩm

Độc giả này kể lại hành trình của mình: chỉ khoảng một năm trước, anh bắt đầu say mê lập trình có AI hỗ trợ. Không có bằng cấp chính quy về khoa học máy tính, nhưng nhờ LLM, anh đã xây dựng được một hệ thống TypeScript/JavaScript khá lớn, bao gồm API, PostgreSQL, pipeline LLM, tự động hóa nghiên cứu và quy trình đa mô hình.

"Ban đầu nó gần như kỳ diệu: AI dường như thu hẹp khoảng cách giữa việc có một ý tưởng và việc có thể xây dựng nó."

Nhưng khi chuyển từ dự án thử nghiệm sang sản phẩm thực tế, mọi thứ trở nên khó khăn. Anh sửa một lỗi bằng AI, rồi lỗi khác xuất hiện, rồi một phần khác hành xử theo cách anh không hiểu hết. Sau nhiều tháng tái cấu trúc, anh nhận ra một điều khó chịu:

Có thể anh đã xây dựng một hệ thống nằm trên chính mức độ hiểu biết của mình.

Khi mọi thứ hoạt động, khoảng cách đó gần như vô hình. Khi nó hỏng, khoảng cách trở nên rất thực. Có những lúc anh thật sự không biết làm gì tiếp theo nếu không hỏi một mô hình khác — và tự hỏi liệu mình đã dành một năm để xây dựng sản phẩm, hay chỉ xây dựng vẻ ngoài của một sản phẩm.

Vị thế của người viết: Hoài nghi nhưng không cực đoan

Seemann thẳng thắn bày tỏ quan điểm trước khi trả lời: ông chưa quyết định hẳn về AI, nhưng nghiêng về phía không thích nó, dù biết nó có thể là xu hướng không thể cưỡng lại.

Ông vẫn làm việc và thử nghiệm với AI, và thường bị nó gây ấn tượng. Nhưng nghịch lý là: chính lúc AI gây ấn tượng mạnh nhất, ông lại thấy bực bội nhất — vì đó là lúc cảm giác về hơn 30 năm học hỏi của mình trở nên vô nghĩa.

Với tư cách một nhà kinh tế học (nền tảng ông ít khi nhắc đến), Seemann đặt vấn đề vĩ mô: nếu tỷ lệ thất nghiệp trong lao động tri thức lên tới 30-40%, nền kinh tế khó tránh khỏi ảnh hưởng nghiêm trọng.

Ông cũng phản biện lập luận quen thuộc rằng "công nghệ mới luôn tạo ra việc làm mới":

• Đúng là việc làm mới được tạo ra, nhưng thường không dành cho những người vừa mất việc. Thợ mỏ than không thể trở thành lập trình viên qua một đêm.
• Lập luận tương tự từng được dùng khi Trung Quốc gia nhập WTO: nhiều việc làm mới được tạo ra — nhưng phần lớn không ở phương Tây.

Có nên học nền tảng lập trình khi đã có AI?

Câu hỏi cốt lõi của độc giả: Nếu bắt đầu lại từ hôm nay, liệu có nên học nghiêm túc ngôn ngữ, cấu trúc dữ liệu, cơ sở dữ liệu, mạng, hệ điều hành, gỡ lỗi và kiến trúc phần mềm?

Seemann trả lời không do dự: Có, ông thấy may mắn vì đã học lập trình trước thời LLM — những kỹ năng đó phục vụ ông suốt 30 năm.

Nhưng nếu bắt đầu từ hôm nay, ông thừa nhận sẽ nghiêm túc cân nhắc học nghề mộc, gia công kim loại, hay chế tạo súng — những nghề đòi hỏi phối hợp tay-mắt. Dù robot cũng đang tiến bộ, việc thay thế lao động chân tay dường như còn xa hơn nhiều so với lao động trí óc.

Về câu hỏi liệu AI có giúp người ta xây dựng nhanh hơn khả năng hiểu — Seemann cho rằng cần thời gian kiểm chứng. Ông nhắc lại thực tế: lập trình viên đã làm việc trên các tầng trừu tượng mà họ không hiểu suốt nhiều thập kỷ.

• Lập trình viên web thường không biết nhiều về lập trình trình biên dịch.
• Người viết trình biên dịch không biết nhiều về thiết kế vi mạch tích hợp.
• Kỹ sư thiết kế vi mạch lại không hiểu các tầng trừu tượng phía trên.

Nguyên tắc thực dụng từng được đúc kết: Hiểu tầng trừu tượng ngay dưới và ngay trên tầng bạn làm việc — đủ để xử lý hầu hết sự cố.

Nền tảng yếu + sản phẩm AI-built: Học hay tiếp tục xây?

Với tình huống cụ thể của độc giả — có dự án lớn do AI xây nhưng nền tảng yếu — Seemann thừa nhận đây là câu hỏi khó vì bản thân ông không còn ở vị thế đó. Ông kể lại thời điểm tương tự trong sự nghiệp:

Năm 1999, ông viết các component COM bằng C++, không hiểu rõ nhiều thứ mình đang làm. Ông vẫn làm cho nó chạy được, thậm chí loại bỏ được các rò rỉ bộ nhớ rõ ràng. Nhưng ông chưa bao giờ hài lòng với việc lắp ghép mọi thứ mà không hiểu chúng hoạt động thế nào — nên ông lùi lại để học bài bản các nền tảng cơ bản.

Chiến lược đó hiệu quả cho một sự nghiệp khởi đầu giữa thập niên 1990. Liệu nó có hiệu quả hôm nay? Seemann không chắc:

"Để đạt mức năng lực đủ cao nhận ra sự tự tin trong quá khứ của mình nằm rõ ràng ở phần 'quá thiếu hiểu biết để nhận ra' của đường cong Dunning-Kruger đã mất hàng thập kỷ. Liệu bạn có ngần ấy thời gian trong thời đại hôm nay?"

Dù LLM giúp học nhanh hơn nhờ đặt câu hỏi có định hướng tốt hơn, ông nghi ngờ tốc độ học của con người khó tăng đáng kể: nút thắt không phải giáo viên hay tài liệu, mà là tốc độ bộ não hấp thụ kiến thức mới.

Cách Seemann học — và cách ông dùng LLM

Về hành trình học của bản thân: ông học chậm, dựa trên nhiều lần thử và sai, thỉnh thoảng có sách hỗ trợ. Dự án lập trình đầu tiên là tính lại biểu đồ phân nhánh và attractor Lorenz cho luận văn thạc sĩ kinh tế, viết bằng QBasic, học từ các mẫu đi kèm và hỏi bạn bè.

Suốt thập niên 1990-2000, ông chủ yếu học từ ví dụ và tài liệu — nắm các phương ngữ Basic và C# hoàn toàn qua tài liệu và mã mẫu. Nhưng với F# và Haskell, sách lại đóng vai trò quyết định.

Về cách học ngôn ngữ mới hôm nay, ông thừa nhận kinh nghiệm của mình vô dụng với người mới: sau khi đã thấy quá nhiều ngôn ngữ, ông thường chỉ cần đọc code hiện có và tra vài điểm chưa rõ là đủ.

Điểm đáng chú ý nhất: Seemann không dùng LLM nhiều để học.

"LLM không hallucinate; chúng nói nhảm (bullshit), và tôi cực kỳ nghi ngờ mọi thứ chúng nói với tôi."

Tuy nhiên ông vẫn dùng LLM — nhưng chỉ với câu hỏi có câu trả lời kiểm chứng được. Ví dụ: "Tôi có thể làm biểu thức Haskell này ngắn gọn hơn không?" Câu trả lời hữu ích là một gợi ý code chạy được hay không, ngắn hơn hay không — dễ kiểm chứng.

Ngược lại, câu hỏi như "Tôi nên học gì tiếp theo?" không cho câu trả lời kiểm chứng được — và ông tránh hỏi LLM những điều đó.

Bài học cho lập trình viên Việt Nam

Với cộng đồng lập trình Việt Nam — nơi nhiều người chuyển nghề hoặc tự học nhờ AI — chia sẻ của Seemann mang lại vài gợi ý thực tế:

• Xây dựng sản phẩm từ AI nhưng đặt câu hỏi về nền tảng: Nếu bạn không giải thích được một đoạn code AI sinh ra cho đồng nghiệp, đó là dấu hiệu nợ kỹ thuật cần trả.
• Hiểu tầng trừu tượng liền kề: Bạn không cần biết hết mọi thứ, nhưng hiểu tầng ngay trên và dưới giúp bạn xử lý phần lớn sự cố.
• Đặt câu hỏi có thể kiểm chứng cho LLM: Thay vì "nên học gì tiếp?", hãy hỏi những câu mà câu trả lời đúng/sai rõ ràng — và kiểm chứng lại.
• Đầu tư dài hạn vào nền tảng: Trong thị trường lao động công nghệ ngày càng cạnh tranh, người hiểu sâu hệ thống sẽ khó bị thay thế hơn người chỉ biết ghép các mảnh do AI tạo ra.

Kết lại, Seemann không đưa ra câu trả lời dứt khoát — vì thời đại này quá bất định để ai đó tuyên bố chân lý. Nhưng cách ông tiếp cận LLM — như một công cụ mạnh mẽ nhưng chỉ đáng tin khi câu trả lời có thể kiểm chứng — có lẽ là nguyên tắc lành mạnh nhất cho bất kỳ ai đang học lập trình hôm nay.