Lập trình viên làm sao để không bị AI 'thay thế'? Tiến hóa là chìa khóa

10 tháng 7, 2026

Năm 1993, bộ phim Jurassic Park ra mắt và tạo nên một cuộc cách mạng trong việc sử dụng CGI trong điện ảnh[1]. Đối với công chúng, trải nghiệm đó thật kỳ diệu. Nhưng với một số người trong ngành công nghiệp điện ảnh, đó là một sự thức tỉnh đầy khắc nghiệt.

Đạo diễn Steven Spielberg đã thuê bậc thầy stop-motion[2] Phil Tippett[3] để thổi hồn vào những chú khủng long toàn thân trong phim bằng kỹ thuật go-motion của ông. Spielberg đã rất hoài nghi về việc liệu hình ảnh do máy tính tạo ra (CGI) có thể mô tả một con khủng long một cách chân thực hay không[4]. Nhưng Dennis Muren và các nghệ sĩ kỹ thuật số tại Industrial Light & Magic (ILM) đã thực hiện một bản chứng minh khái niệm (proof-of-concept) bằng CGI. Họ đã dựng hình một con T. rex có kết cấu đầy đủ, chân thực như ảnh chụp đang đuổi theo một đàn Gallimimus dưới ánh nắng mặt trời rực rỡ.

Tôi đã đi cùng [giám sát hiệu ứng hình ảnh] Dennis Muren khi ông ấy trình bày bài kiểm tra T-Rex cho Steven, và Steven đã thốt lên: "Wow, đó chính là điều chúng ta sẽ làm", và ông ấy hỏi tôi cảm thấy thế nào, tôi đã trả lời: "Tôi cảm thấy mình đã tuyệt chủng"[5].

Có vẻ như mọi thứ tôi đã xây dựng cho đến thời điểm đó đều giống như một lời khẳng định: "Chúng ta sẽ không làm việc đó nữa"[6].

Gần đây tôi suy nghĩ rất nhiều về giai thoại này. Tôi thấy rất nhiều sự bi quan[7] xung quanh các lập trình viên. Nỗi lo sợ trở nên lỗi thời đặc biệt rõ rệt trên mạng[8][9].

Cách tốt nhất để tránh bị tuyệt chủng là tiến hóa. Tôi thích quan điểm của zkmon trên Hacker News.

Hãy đón đầu con sóng. Bạn đã từng làm vậy khi các trang web/ứng dụng web là xu hướng. Tôi bước vào ngành phần mềm trước khi có internet, và cứ liên tục thay đổi "con ngựa" của mình. Bạn không bao giờ là quá già để học những kỹ năng mới. Làn sóng mới tạo ra những loại hình công việc và người lao động mới. Hãy trở thành một trong số đó. Hãy cưỡi lên con quái vật, làm chủ các công cụ. Đó vẫn là trò chơi cũ mà thôi.

Mặc dù giai đoạn hiện tại làm zkmon nhớ đến thời kỳ web giữa những năm 90, nhưng nó lại khiến tôi nghĩ đến lĩnh vực Đồ họa máy tính vào đầu những năm 2000 và sự trỗi dậy của "Mobile First" vào đầu những năm 2010. Mỗi thế hệ lập trình viên có lẽ đều đã chứng kiến một hình thức r-evolution (tiến hóa/cách mạng). Đây thực sự vẫn là trò chơi cũ. Cuộc sống là sự biến đổi không ngừng[10]. LLM cũng chỉ là một công cụ khác. Tiến hóa nghĩa là đầu tư thời gian để tìm hiểu cách nó hoạt động và cách sử dụng nó hiệu quả nhất.

Tài nguyên tốt nhất mà tôi tìm thấy để học cách LLM hoạt động là kênh của Andrej Karpathy. Người đàn ông này rõ ràng rất quan tâm đến LLM và thực sự muốn bạn hiểu thấu đáo về chúng. Chuỗi video của ông ấy cho đến nay là 25 giờ kiến thức quý giá.

Một tài liệu tiếp nối tuyệt vời là cuốn sách Build a Large Language Model (From Scratch) của Sebastian Raschka. Sách có rất nhiều hình vẽ màu sắc đầy đủ với những khoảnh khắc "Now Draw the Owl" (hướng dẫn vẽ cú mèo) hiếm hoi. Đây thực sự là một cuốn sách rất hay.

Viết từng dòng code bằng tay không còn là chuẩn mực nữa. Những ai từ chối sử dụng LLM sẽ bị tụt hậu vì họ sẽ không thể tạo ra năng suất tương đương - và tôi biết vài lập trình viên từ chối sử dụng các tác nhân (agents). John Carmack gần đây đã có một quan điểm thú vị về việc lập trình.

"Lập trình" chưa bao giờ là nguồn gốc của giá trị, và mọi người không nên quá gắn bó với nó. Giải quyết vấn đề mới là kỹ năng cốt lõi. Sự kỷ luật và chính xác mà lập trình truyền thống đòi hỏi sẽ vẫn là những thuộc tính có giá trị và có thể chuyển đổi, nhưng chúng sẽ không còn là rào cản gia nhập ngành nữa.

Nhiều năm qua, tôi đã nhiều lần nghĩ về một lập trình viên giỏi mà tôi từng biết, người yêu ngôn ngữ assembly đến mức không muốn chuyển sang C. Tôi cũng phải đấu tranh với những cảm xúc tương tự khi sử dụng các cơ sở mã khổng lồ hiện có và các ngôn ngữ kém hiệu quả, nhưng tôi vẫn vượt qua.

Mặc dù tôi không trực tiếp viết code, tôi vẫn đang gián tiếp tạo ra code. Và có sự tùy ý đáng kể trong việc tạo ra cái gì. Nếu tôi "full-vibe-code" và để LLM chạy, tôi có thể tạo ra gấp 1000 lần những gì tôi từng làm và nhận lại một mớ hỗn độn không thể giải mã. Đó có phải là điều tồi tệ không? Nếu tôi làm việc trên một bản mẫu hoặc một dự án cá nhân nhỏ, thì không sao cả. Nhưng với mọi thứ khác, chất lượng code vẫn cực kỳ quan trọng. LLM có thể khẳng định rằng chúng hiểu dự án và đề xuất giải pháp, nhưng tôi đã thấy chúng thất bại thảm hại và bị "ảo giác" (hallucinate).

Việc có thể đọc code và hiểu kiến trúc vẫn rất quan trọng. Nghe có vẻ hiển nhiên, nhưng tôi đã thấy nhiều lập trình viên không làm được điều đó. Kết quả là, tôi giảm tốc độ của mình bằng cách lặp lại PR cho đến khi nó đạt được cùng mức chất lượng mà tôi sẽ tạo ra "bằng tay". Mỗi khi nhận thấy điều gì đó không ưng ý, tôi thêm nó vào ~/.gemini/GEMINI.md/~/.claude/CLAUDE.md để tác nhân có thể mô phỏng phong cách của tôi. Trong vài tháng qua, tôi đã thêm khá nhiều dòng như dưới đây.

Khó khăn lớn nhất mà tôi gặp phải là "chuyển đổi ngữ cảnh" (context switching). Làm việc trên nhiều dự án / tính năng độc lập cho phép tôi điều khiển nhiều tác nhân cùng lúc. Việc theo kịp chúng đòi hỏi sự linh hoạt về tinh thần rất lớn. Tôi đã thấy các báo cáo về "kiệt sức tinh thần" và bản thân tôi cũng đã trải qua sự mệt mỏi về trí óc ngày càng tăng. Đây chắc chắn là điều cần phải theo dõi.

Với việc các công cụ ngày càng tốt hơn, tôi có kỳ vọng cao hơn nhiều trong các buổi đánh giá code (code reviews).

Hiện nay không có lý do gì để bào chữa cho các commit message kém chất lượng. Có rất nhiều hướng dẫn về cách viết một commit message tốt. Đây là hướng dẫn tốt nhất mà tôi từng bắt gặp. Chỉ mất 1 phút để yêu cầu LLM tóm tắt nó và chuyển đổi thành các chỉ dẫn mà bạn có thể thêm vào GEMINI.md/CLAUDE.md của mình.

Vì việc viết code tốn ít công sức hơn nhiều, tôi mong đợi các kỹ sư phần mềm (SWE) sẽ chăm chút hơn vào việc thiết kế các giải pháp thanh lịch. Tôi không ngần ngại yêu cầu cải thiện độ rõ ràng/đơn giản của code nếu PR đó là một mớ hỗn độn.

Điều tương tự cũng áp dụng cho kích thước PR. Trước đây, việc chia nhỏ một PR thành các phần dễ đánh giá hơn rất tẻ nhạt. Bây giờ không còn như vậy nữa và tôi không gặp vấn đề gì khi yêu cầu tác giả chia nhỏ PR của họ trừ khi họ có lý do chính đáng.

Nhiều công cụ đánh giá code hiện nay đã tích hợp LLM. Bạn có thể tạo prompt ưa thích của riêng mình để tự động thực hiện lượt kiểm tra đầu tiên. Đối với các cơ sở mã mà tôi sở hữu, tôi đã thêm nội dung của GEMINI.md/CLAUDE.md mà tôi có thể kích hoạt chỉ bằng một cú nhấp chuột. Trước khi gửi PR để đánh giá, việc đầu tiên tôi làm là yêu cầu LLM phê bình/tìm lỗi. Điều này tránh lãng phí thời gian của người đánh giá ở phía bên kia.

Viết test từng là một nỗi đau. Bây giờ không còn nữa. Việc yêu cầu unit test/CI test cho mỗi PR là hoàn toàn hợp lý. Những bài test này chưa bao giờ quan trọng hơn thế vì các đợt tái cấu trúc (refactor) lớn đang ngày càng phổ biến. Đánh giá của con người và LLM có thể bỏ sót lỗi, nhưng các bài test tốt sẽ phát hiện ra những chỗ bị hỏng.

Hiện nay việc từ chối thêm các phụ thuộc (dependencies) trở nên dễ dàng hơn. Trước đây, đó là giải pháp mặc định để tránh viết bất cứ thứ gì phức tạp. Ngay sáng nay, tôi đã yêu cầu LLM viết một hàm khoảng cách Levenshtein thay vì thêm một phụ thuộc vào dự án của mình.

Chúng ta có thể đạt được nhiều thành tựu hơn với các nhóm nhỏ hơn. Có lẽ chúng ta không còn xa mô hình những năm 90, khi một nhóm bốn người có thể tạo ra phần mềm chuyên nghiệp. Tôi đã có thể hồi sinh các dự án mà tôi từng từ bỏ vì cho rằng chúng quá tốn thời gian hoặc phức tạp. Tháng trước, tôi đã hoàn thành việc kỹ thuật đảo ngược (reverse engineering) định dạng video Silpheed và tôi đang tiến triển tốt với Ikaruga cho Dreamcast và Zelda: A Link to the Past trên SNES.

Bối cảnh LLM thật hấp dẫn. Và thật thú vị khi chính chủ đề cần nghiên cứu lại là một công cụ tuyệt vời để giúp bắt kịp xu hướng. Một LLM sẽ giúp bạn đi sâu vào bất kỳ cơ sở mã nào và đưa ra các chỉ dẫn về kiến trúc tổng thể. Tôi rất thích tìm hiểu cách hoạt động của llama-cpp, OpenCode, ollama và vLLM. Ngoài ra còn có nhiều giải pháp phần cứng như Tenstorrent, Etched, MatX, d-Matrix hoặc Cerebras Systems mà việc theo dõi chúng cực kỳ thú vị.

Đọc các bài báo nghiên cứu lúc đầu rất khó khăn vì tôi luôn có mối quan hệ khó khăn với ký hiệu toán học. LLM đã giúp tôi bù đắp những thiếu sót đó. Việc có một người bạn đưa ra ý kiến và kiểm tra chéo giúp ích rất nhiều để tăng tốc.

Quan trọng nhất là vấn đề tìm kiếm động lực để học hỏi. Có nhiều lý do chính đáng để tránh nỗ lực, trong đó có những câu chuyện về những người tìm thấy thành công bằng cách chuyển hướng.

Tiếp tục hay không là quyết định của mỗi chúng ta. Đó là kết quả của một quá trình bao gồm niềm tin và cảm hứng. Trong khi niềm tin đến từ bên trong, tôi đôi khi tìm thấy cảm hứng từ những câu chuyện thành công. Điều này đưa tôi trở lại giai thoại ở đầu bài viết. Tôi không chọn câu chuyện của Phil Tippett một cách ngẫu nhiên. Trong khi nhiều người biết đến phần trích dẫn sai "Don't you meant extinct?" (Ý anh là tuyệt chủng?), thì những gì xảy ra sau đó lại ít được biết đến hơn.

Bất chấp cú sốc ban đầu, Tippett, ở tuổi 41, còn lâu mới "tuyệt chủng". Spielberg vẫn giữ ông lại làm "Giám sát Khủng long" cho bộ phim. Vì các nhà làm hoạt họa máy tính tại ILM là các lập trình viên và nghệ sĩ kỹ thuật hơn là các nhà làm hoạt họa biểu diễn truyền thống, họ không biết làm thế nào để một sinh vật di chuyển với trọng lượng, nhịp điệu và ý đồ sinh học.

Tippett đã đồng phát triển Dinosaur Input Device (DID)[11], một khung xương vật lý có khớp nối cao được kết nối với các cảm biến, cùng với ILM. Sau đó, nhóm của ông thao tác vật lý trên DID giống như stop-motion, và máy tính chuyển đổi các chuyển động đó vào không gian kỹ thuật số.

Phil Tippett (cùng với Dennis Muren, Stan Winston và Michael Lantieri) đã giành giải Oscar cho Hiệu ứng hình ảnh xuất sắc nhất cho Jurassic Park vào năm 1994[12]. Công ty của ông, Tippett Studio, vẫn tiếp tục tồn tại để tham gia vào các bộ phim như StarShip Troopers, Dragonheart và bảy mươi lăm tựa phim khác[13].

Tài liệu tham khảo