Đừng gọi mình là 'lập trình viên thủ công' — cuộc chiến ngôn từ trong kỷ nguyên AI

Trong vài năm trở lại đây, một cách phân chia tưởng như vô hại đã len lỏi vào mọi cuộc tranh luận về lập trình: người thì chia làm hai phe — "kỹ sư nghiêm túc" chỉ quan tâm đến kết quả cuối cùng, và "coder thủ công" (artisanal coder) coi trọng trải nghiệm viết code hơn sản phẩm. Cách phân chia này không mô tả đúng về tác giả, cũng không đúng với rất nhiều người khác.

Điều đáng nói là cách gọi tên này đang âm thầm định hình lại toàn bộ chuẩn mực của ngành — và theo hướng bất lợi cho những ai vẫn coi trọng sự cẩn trọng trong từng dòng code.

Tôi muốn chương trình của mình đáng tin cậy

Tác giả thẳng thắn nói rằng anh muốn các chương trình của mình hoạt động đáng tin cậy. Sự kiên nhẫn và cẩn thận là hai nguyên liệu quan trọng không thể thiếu.

Khi thiết kế chương trình từ con số không và dành đủ thời gian, anh biết chắc code của mình đúng, và mọi lỗi nếu có chỉ là do gõ nhầm. Các công cụ như unit test, review bằng LLM, hay trình chứng minh (prover) có thể đảm bảo code đúng 99%, nhưng không thể đảm bảo 100% — tức là tối ưu, dễ bảo trì, dễ đọc, và không phụ thuộc vào những hành vi không được ghi chép hoặc không tuân chuẩn.

Tôi chỉ có thể bắt đầu đạt được cái 100% đó khi có sự kết nối sâu sắc với code. Vì vậy tôi từ chối dùng LLM, bởi chúng tách tôi khỏi những chi tiết cấp thấp quan trọng và không thể đảm bảo tính đúng đắn ngay từ khâu thiết kế.

Nghịch lý của sự phân chia

Theo cách phân loại phổ biến, tác giả bị xếp vào nhóm "coder thủ công" vì không dùng LLM. Nhưng nếu ngành gọi mặt đối lập của "thủ công" là "kỹ sư phần mềm", thì ẩn ý ở đây là anh không phải kỹ sư.

Đây có vẻ là chuyện nhỏ, nhưng nó tác động ở tầng ý thức. Sự cẩn trọng, chú tâm và chính xác chính là đặc trưng định nghĩa của kỹ thuật — vậy tại sao thuật ngữ đó lại bị chiếm dụng bởi những người ngày càng giống quản lý hơn là kỹ sư?

Ngày trước, lập trình viên ghét những nhà quản lý không chịu dành thời gian xử lý nợ kỹ thuật (tech debt), và thái độ "move fast and break things" bị coi là trẻ con. Ngày nay, "vibecoding" được coi là chuẩn mực, còn dành thời gian cho công việc đảm bảo độ tin cậy bị coi là thiếu nghiêm túc.

Nghịch lý trong cách gọi tên

Năm 2021, Hillel Wayne chạy dự án Crossover, phỏng vấn nhiều người chuyển từ các ngành kỹ thuật khác sang phần mềm. Câu hỏi trọng tâm: những người có kinh nghiệm thực tế ở cả hai lĩnh vực có coi nghề của chúng ta là kỹ thuật không? Câu trả lời là "có".

Nhưng điểm đáng chú ý hơn nằm ở phần bổ sung:

Kỹ thuật phần mềm là kỹ thuật thực thụ, nhưng rất nhiều người viết phần mềm không làm kỹ thuật phần mềm... Không phải ai làm việc với điện cũng là kỹ sư điện; nhiều người là thợ điện. Và điều đó không sao cả.

Wayne gọi những người cẩn trọng — mà ngày nay ta gọi là "coder thủ công" — là kỹ sư, và gọi những người viết code bằng AI là thợ thủ công (craftsman). Cách gọi này trực giác hơn nhiều: có lẽ nghệ thuật trong prompt engineering còn nhiều hơn trong việc viết code bằng tay.

Nhưng bằng cách tự nhận mình là "thủ công", cộng đồng đã để mất thuật ngữ "kỹ sư" — và qua đó, thua luôn cuộc tranh luận về việc liệu vibecoding có phải là một hình thức kỹ thuật hay không.

Một cuộc chiến về bản sắc

Đây không giống những tranh cãi trước đây trong cộng đồng lập trình. Người tin vào hệ thống kiểu mạnh (strong type system) có thể coi lập trình viên PHP là ngốc nghếch, nhưng vẫn coi họ là nhà phát triển. Người cuồng Rust vẫn là lập trình viên.

Các cuộc tranh luận cũ xoay quanh việc lựa chọn nào đáng tin cậy hơn, dễ dùng hơn — chứ không phải việc bạn có nên quan tâm đến độ tin cậy hay không. Điều này rất khác.

Vibecoding được miêu tả không phải như một giải pháp tốt hơn, mà là giải pháp duy nhất hợp lý — phủ nhận thẳng thừng mọi kinh nghiệm quá khứ. Người không dùng LLM không phải là kỹ sư phần mềm, họ là "coder thủ công". Đó là một cuộc tấn công vào bản sắc.

Tác giả nhớ lại thời điểm mọi người còn đùa nhau: "từ trái nghĩa của vibecoder là software engineer", rồi chỉ một tháng sau, ai cũng thoải mái gọi mình là "artisanal programmer" và để mặc cụm "software engineer" cho những người dùng AI "có trách nhiệm". Thuật ngữ lan truyền với tốc độ của meme, dường như không vì bất kỳ lý do tự nhiên nào.

Chủ nghĩa phản tri thức trong ngành

Tác giả cho rằng nguyên nhân sâu xa là chủ nghĩa phản tri thức (anti-intellectualism) đang lan rộng trong cộng đồng phần mềm.

Trước khi Rust phổ biến, lập luận chống lại nó phổ biến nhất là gì? Rằng nó giống toán học thuần túy, không dùng được cho mục đích thực tế. Điều tương tự vẫn được nói về Haskell, đặc biệt là về monad — trong khi Rust đã chứng minh monad có thể hiểu dễ dàng (Result, Option, Future đều là monad!).

Ngay cả con trỏ (pointer) cũng bị coi là phức tạp, vì "ôi không, bạn phải học gì đó trước khi dùng chúng!". Chúng ta khao khát giải pháp dễ dàng, nhưng ý thực sự là từ chối đọc tài liệu và chỉ muốn sao chép code từ StackOverflow.

Nếu đó không phải là chủ nghĩa phản tri thức, tôi không biết nó là gì.

Và tất nhiên, chúng ta phủ nhận giá trị của học vấn, của nỗ lực, của tư duy, của việc dành thời gian — những thứ đó bị coi là "woke" và chúng ta "giỏi hơn thế".

Chúng ta cần phản công

Mục tiêu không phải là đảo ngược kịch bản và tuyên bố tránh AI là cách duy nhất đúng để viết phần mềm — điều đó sẽ không hiệu quả. Mục tiêu là đảm bảo lập trình không dùng AI vẫn giữ được vị trí trong thảo luận công khai, không bị đánh đồng với lập trình giải trí.

Về thuật ngữ, tác giả đề xuất:

• Dùng "lập trình có hỗ trợ AI" (AI-assisted coding) khi AI được sử dụng
• Dùng "kỹ thuật phần mềm không dùng AI" (AI-free software engineering) khi làm thủ công

Cách này giữ được thông báo về việc dùng AI, nhưng đảo ngược nửa "lập trình vs kỹ thuật" và loại bỏ từ "thủ công" vốn có thể bị hiểu là một hình thức chơi đùa.

Nói về con người chúng ta

Rộng hơn, chúng ta cần thách thức giả định rằng lập trình có hỗ trợ AI là cách duy nhất hợp lý để viết code.

Công chúng hiểu rằng dùng tác phẩm do AI tạo ra cho bất kỳ mục đích nào đều đáng nghi ngờ. Chúng ta cần thuyết phục họ rằng nguyên tắc tương tự cũng áp dụng cho code do AI tạo ra. Nếu một người xem "nghệ thuật" AI có thể cảm thấy bị lừa dối dù không biết vẽ, không có lý do gì điều này lại không hiệu quả với chương trình.

Chúng ta cần nói về sự cẩn trọng đặt vào phát triển phần mềm, cách chúng ta thiết kế code, những vấn đề đang gặp phải, và vẻ đẹp của cách chúng ta cộng tác. Chúng ta nên nhấn mạnh rằng speedrun lỗi thú vị vì ta thấy lỗi phát sinh từ sai lầm của con người, rằng nghệ thuật máy tính thật tuyệt, và thật ấm lòng khi một nhà phát triển trau chuốt ứng dụng của họ để cải thiện trải nghiệm người dùng.

Chúng ta cần nói về tính người của mình — dù đó không phải sở trường của chúng ta.

Với độc giả Việt Nam đang làm việc trong ngành công nghệ — đặc biệt là các bạn trẻ đang cân nhắc giữa việc dùng AI để tăng tốc và việc đầu tư vào kỹ năng nền tảng — bài viết này là lời nhắc rằng ngôn từ định hình chuẩn mực, và chuẩn mực định hình tương lai nghề nghiệp. Việc bạn gọi mình là gì không chỉ là chuyện danh xưng.