Khủng hoảng bản sắc của lập trình viên
(hojberg.xyz)- Bản sắc của lập trình viên gần đây đang bị đe dọa bởi sự xuất hiện của AI và các công cụ LLM
- Văn hóa lập trình bắt nguồn từ đạo đức hacker tại MIT vào thập niên 1950, xem việc viết code tự thân nó là một kỹ nghệ (craft) sâu sắc, lấy logic chính xác và sự đắm chìm trong giải quyết vấn đề làm giá trị cốt lõi
- Tuy nhiên, ngành công nghiệp AI hiện nay và các công cụ LLM đang tìm cách biến nhà phát triển thành những người viết đặc tả hoặc người vận hành đơn thuần, ép buộc cách làm kiểu "vibe-coding" chỉ ra lệnh bằng ngôn ngữ tự nhiên thay vì trực tiếp viết code
- Code do LLM tạo ra phi định tính và thiếu chính xác, đồng thời loại bỏ sự thấu hiểu sâu và trạng thái nhập tâm mà lập trình viên có được trong quá trình tự đọc và tự viết code, khiến họ bị cắt đứt khỏi codebase
- Các doanh nghiệp lấy cớ tăng năng suất để ép buộc sử dụng công cụ, thay thế văn hóa cộng tác và mentoring trong nhóm bằng tương tác với AI, từ đó làm suy yếu kết nối giữa con người với con người trong giới phát triển
- Giá trị cốt lõi coi lập trình không chỉ là đầu ra mà là một quá trình tư duy và thấu hiểu đang bị đánh mất, và các lập trình viên cần chống lại sự thay đổi này để bảo vệ kỹ năng, niềm vui và bản sắc nghề nghiệp của mình
Bản chất và truyền thống của lập trình viên
-
Viết code không chỉ là công việc mà chính là bản sắc của lập trình viên; editor là xưởng làm việc đồng thời là thánh địa, nơi họ rèn luyện kỹ nghệ và đi vào trạng thái flow
- Thông qua các công cụ như Vim, họ làm việc không có rào cản giữa tư duy và code, tạo ra một thế giới phi vật chất nhưng có tác động lên thế giới thực
- Bản thân quá trình giải câu đố quan trọng hơn bức tranh hoàn chỉnh, và thời gian như biến mất trong dòng chảy kỹ năng từ đầu ngón tay đến buffer
-
Vào cuối thập niên 1950 tại MIT, một nền văn hóa lập trình mới đã ra đời, khi những hacker có khuynh hướng thử nghiệm và phản văn hóa dùng Flexowriter và máy tính TX-0 để theo đuổi chương trình hoàn hảo
- Họ lấy khái niệm "The Right Thing" làm trung tâm, hướng tới việc viết code thanh nhã và cô đọng
- Các thành viên của Tech Model Railroad Club đắm mình vào ngôn ngữ máy, học thứ ma thuật số và xây dựng văn hóa chia sẻ kiến thức khám phá được với các sinh viên khác
-
Trong lò luyện điện toán của Building 26, kỹ năng coding được tôi luyện, và nền văn hóa được thiết lập từ khoảng 70 năm trước ấy vẫn tiếp tục đến ngày nay, vẫn tồn tại trong tâm trí các nhà phát triển và trong máy móc
- Di sản của các hacker đời đầu còn lại như một kỹ năng sâu sắc và giàu tính vận động, và một ngành công nghiệp đầy đam mê đã được xây dựng trên nền tảng đó
- Các nhà phát triển ngày nay vẫn được thúc đẩy bởi cùng một cảm giác kinh ngạc, thành tựu và vẻ đẹp thanh nhã của việc giải câu đố
-
Tuy nhiên, những giá trị cốt lõi cấu thành bản sắc lập trình viên ấy đang bị đe dọa, và tương lai của lập trình, từng sáng rõ và tươi đẹp, nay bị che phủ bởi bóng tối điềm gở, sự lừa dối và bất định
Ngành AI áp đặt một bản sắc mới
-
Ngành AI trị giá hàng tỷ USD, cộng đồng Hacker News và những người ủng hộ LLM trên LinkedIn đang cho rằng tương lai của phát triển phần mềm gần như không còn giống lập trình, và thứ từng trông như meme cách đây một năm là "vibe-coding" nay đang trở thành dòng chính
- Các nhà phát triển bị buộc phải viết đặc tả bằng Markdown thay vì code, còn sự nhập tâm sâu sắc và chiều sâu kỹ năng của việc khám phá mọi ngóc ngách của codebase, giải đố và tìm ra bí mật thì biến mất
- Thay vào đó, họ phải chấp nhận nhận thức phân tán và liên tục chuyển ngữ cảnh trong khi agent suy nghĩ thay mình; việc giải quyết vấn đề sáng tạo được giao cho máy móc, còn lập trình viên trở thành người vận hành đơn thuần
-
Một số nhà phát triển đón nhận sự thay đổi này cùng bản sắc mới mang tên "Specification Engineering", hào hứng với việc trở thành operator và "chỉ huy dàn nhạc" như Steve Jobs
- Điều đó khiến người ta tự hỏi vì sao họ lại trở thành lập trình viên khi dường như chẳng hứng thú với việc coding, hay có lẽ họ đã nhầm lẫn giữa Woz và Jobs
- Prompt, Context, Specification "Engineering" dường như không hứa hẹn mang lại cho lập trình viên một sự nghiệp tươi sáng và thịnh vượng
-
Điều này đồng nghĩa với sự mất giá của kỹ thuật, tay nghề và lao động, khi năng lực tư duy trừu tượng độc đáo của lập trình viên bị đẩy sang một lĩnh vực không còn cần đến nó, tiến vào không gian vốn đã do product manager và designer chiếm giữ
Thay đổi tương quan quyền lực trong doanh nghiệp
-
Khi bản sắc mới này bị áp đặt trong doanh nghiệp, tương quan quyền lực đang thay đổi; trong nỗ lực cuồng loạn nhằm tăng năng suất ở sai chỗ, các nhà phát triển ngày càng bị ép phải dùng LLM theo những cách rất cụ thể
- Không tuân theo thì либо bị đuổi, либо phải dùng sản phẩm đang báo hiệu sự vô dụng của chính mình, hoặc xin nghỉ việc
- Trước đây hầu như chưa từng có chuyện ban điều hành chỉ đạo công cụ của lập trình viên một cách chi tiết đến thế
-
Các nhà phát triển từ lâu đã rất tự hào về việc tuyển chọn và mài giũa công cụ của mình, giống như đầu bếp hay thợ mộc; họ cá nhân hóa công cụ theo đúng cách tư duy của mình thông qua cấu hình editor tỉ mỉ, tinh chỉnh dotfile, dựng môi trường phát triển
- Họ đã tận tâm với việc cá nhân hóa bộ công cụ như một phần của tay nghề, nên việc ban quản lý vốn hầu như không gắn với công việc hằng ngày lại ra lệnh chuyện này tạo cảm giác như một sự xâm phạm
- Với những lập trình viên vốn đã được ưu ái trong doanh nghiệp suốt hàng chục năm, câu chuyện mới này mang lại cho giới quản lý một cách khác để nghiêng cán cân trở lại có lợi cho họ
Khác biệt bản chất giữa LLM và ngôn ngữ lập trình
-
Một số người ví tác động của LLM với sự chuyển dịch từ ngôn ngữ bậc thấp sang ngôn ngữ bậc cao như từ Assembly sang Fortran, nhưng đó là một phép so sánh sai ở nhiều khía cạnh
- Fortran bắt rễ trong lập trình, không cố gắng xóa bỏ kỹ năng mà xây dựng trên đó; nó mở rộng lập trình mà không loại bỏ độ chính xác và sức biểu đạt của nó
- Fortran luôn tạo ra đúng kết quả từ đầu vào một cách đáng tin cậy, còn trong thế giới của LLM thì không điều nào ở trên còn đúng
-
Máy tính và lập trình có thể rất dễ gây nản lòng, nhưng ít nhất ta luôn có thể tin vào độ chính xác; thông qua lập trình, máy tính thực hiện đúng như những gì được chỉ dẫn
- Chính vì sự phụ thuộc và niềm tin vào tính chính xác của máy tính, người ta dễ tin chatbot khi nó gaslight rằng mình đã làm xong việc được yêu cầu
-
LLM và cách chúng làm việc về bản chất là thiếu chính xác, cả ở đặc tính của mô hình ngôn ngữ lớn lẫn ở phương thức ra lệnh bằng ngôn ngữ tự nhiên vốn đầy chỗ cho hiểu sai
- Thật đáng chú ý khi những lập trình viên vốn ghét tính phi định tính lại chọn cách tiếp cận này, dù họ thường ưa sự dự đoán được, tính kết hợp, tính idempotent và các integration test ổn định
- Code từ LLM lại là điều ngược lại: một sự hỗn loạn thiếu nhất quán
-
Dijkstra, trong bài viết On the foolishness of "natural language programming", đã chỉ ra rằng cần phải thách thức giả định cho rằng ngôn ngữ tự nhiên sẽ đơn giản hóa công việc, và nhấn mạnh rằng ưu điểm của văn bản hình thức là để hợp lệ, nó chỉ cần đáp ứng một vài quy tắc đơn giản
Đánh mất sự thấu hiểu sâu và trạng thái nhập tâm
-
Có xu hướng muốn phân biệt phát triển có AI hỗ trợ với vibe-coding bằng sự nghiêm ngặt và tính quan liêu hơn, nhưng điều đó bỏ qua bản chất nền tảng của vấn đề
- Người ta sẽ không đọc kỹ code do LLM tạo ra như khi chính mình viết hoặc review trong PR, và trong việc code cùng LLM có một điều gì đó vốn dĩ khiến mắt trở nên vô hồn
- Bạn chỉ lướt qua, thấy quá tải và chán nản, rồi mù quáng chấp nhận những cái bẫy nguy hiểm miễn là CI pass và chương trình compile được
- Bạn không kiểm tra xem test có thực sự được cấu hình để chạy không, có import thư viện không tồn tại không, hay có tự triển khai cả một thư viện từ đầu không
-
Review hay tóm tắt một cuốn sách không thể thay thế trải nghiệm tự đọc, thứ đòi hỏi phải cẩn trọng tiếp nhận từng câu chữ qua hàng trăm trang và suy ngẫm về các ý tưởng
- Tương tự, việc chỉ lướt qua phần tóm tắt công việc do AI làm xong sẽ tước đi sự thấu hiểu sâu về domain, vấn đề và các lời giải khả dĩ, đồng thời cắt đứt kết nối với codebase
- Việc lao xuống vực sâu của sự chưa biết để bóc mở chủ đề cùng các hàm ý của nó, để học và để hiểu, vừa thỏa mãn vừa thiết yếu cho phần mềm tốt
- Cảm giác sở hữu, tính chủ thể và công việc sâu sắc, đem lại thỏa mãn bị thay bằng sự chú ý phân tán giữa các tab agent
-
Joan Didion từng nói: "Tôi viết để khám phá xem mình đang nghĩ gì, đang nhìn gì, đang nhìn thấy điều gì và điều đó có nghĩa là gì", và Peter Naur đã khám phá cùng một ý niệm trong Programming as Theory Building
- "Theory" của Naur hiện thân cho sự thấu hiểu về codebase, bao gồm cách nó vận hành, tính hình thức và cách nó biểu đạt thế giới thực
- Bối cảnh và hiểu biết như vậy chỉ có thể đạt được qua sự nhập tâm, và Naur mô tả "Theory" chứ không phải phần mềm như kết quả chủ yếu của lập trình, tức sản phẩm thực sự
- Chỉ khi có một "Theory" phát triển đầy đủ thì người ta mới có thể áp dụng mở rộng và sửa lỗi vào codebase một cách hiệu quả
-
Thiết kế tốt nảy sinh từ sự nhập tâm, xuất hiện qua việc đi đi lại lại trong text buffer và thường cả trong những khoảng thời gian rời bàn phím
- Không thể ôm trọn toàn bộ codebase trong đầu, nên ta phải lao vào module, class, function để làm cho mô hình tinh thần còn mờ trở nên sắc nét hơn
- Cần đọc và viết code để mở rộng nhận thức, khôi phục sự quen thuộc và hiểu biết về domain vấn đề
-
Sau khi đã xây dựng được một phần ngữ cảnh và đi qua nhiều nỗ lực vụng về, cuối cùng ta mới có thể tìm ra lời giải, và phải cảm được sự chói tai của một thiết kế tồi
- Chỉ khi viết ra thứ code xấu xí, lặp lại và khó chịu, ta mới nhận ra có một cách tốt hơn, gọn hơn, thanh nhã hơn, có tính kết hợp và tái sử dụng cao hơn
- Điều đó buộc ta dừng lại để suy nghĩ thật sâu về vấn đề, lùi lại một bước rồi bắt đầu lại từ đầu
- Ngược lại, công việc với AI agent lại không có ma sát, khiến người ta né tránh các lời giải thay thế và không thể biết thứ mình chấp nhận là hoàn hảo, tầm thường, tệ hại hay thậm chí có hại
Sụp đổ của cộng tác nhóm và kết nối con người
-
Món nợ nhận thức của việc coding lấy LLM làm trung tâm còn vượt xa sự mai một kỹ năng; những slop-jockey với thời gian chú ý ngắn ném sản phẩm của họ vào pull request và tài liệu thiết kế, cản trở hợp tác và làm phiền cả nhóm
- Những đồng nghiệp làm code review đang choáng váng khi nhận ra rằng mình giờ không còn là lớp kiểm soát chất lượng cuối cùng mà là lớp đầu tiên
- Họ phải chỉ ra những function mới được thêm vào nhưng không bao giờ được gọi, những thư viện bị hallucinate, hay các lỗi runtime hoặc compile hiển nhiên
- Tác giả vốn chỉ lướt qua đoạn code của chính mình thì không chịu trách nhiệm, chỉ nói rằng: "Claude viết như vậy đấy. AI ngớ ngẩn thật, haha"
-
Những nhà quản lý thích can thiệp và các lãnh đạo chỉ muốn tiết kiệm tiền đang gây áp lực để trong nhóm giảm tương tác giữa con người với nhau — hy vọng là một cách vô thức
- Trong tình trạng bị cô lập và tước mất kết nối, người ta nay được trao quyền và còn được khuyến khích xây tường quanh trải nghiệm làm việc của mình
- Khi cần pair programming, cần trao đổi và bàn bạc giải pháp, cần làm prototype, phác thảo kiến trúc hoặc cần chuyên gia giải đáp về một phần khó hiểu của codebase, người ta dựa vào LLM thay vì con người
- Không còn cần onboarding buddy, mentor hay đồng nghiệp nữa; thay vào đó, bạn có thể nói chuyện với máy
- Việc dùng LLM để né tránh tiếp xúc con người trở nên quá dễ dàng đến mức nó có thể thành tiêu chuẩn
Bảo vệ bản sắc của lập trình viên
-
Thật sốc khi thấy chúng ta tuân phục đến mức nào trước những narrative thổi phồng AI, chủ động tham gia vào việc xóa bỏ kỹ năng đã được lên kế hoạch, và sẵn sàng từ bỏ chính công cụ tư duy của mình
- Chúng ta từng là những người may mắn có thể sống bằng đam mê, nhưng ngay cả khi dựng lên những quy trình nghiêm ngặt và tỉ mỉ để đối phó với slop, ta vẫn đang outsource phần thú vị nhất của công việc và thay nó bằng một cực hình mang tính chỉ huy
-
LLM trông như một giải pháp ném bom hạt nhân từ quỹ đạo vào sự phức tạp của phần mềm, vươn tới thứ còn phức tạp và mơ hồ hơn rất nhiều để chữa triệu chứng thay vì giải quyết vấn đề thực
- Dùng Claude thay cho
sed, hoặc hỏi đáp về một thư viện hay framework sau khi đã mất hàng giờ lục tài liệu mà vẫn chưa tìm ra sự rõ ràng, thì không sao - Nhưng việc chỉ trở thành operator hay người review code, lùi xuống hàng ghế sau trước những phần việc thú vị và hấp dẫn, là điều không mong muốn
- Dùng Claude thay cho
-
Tác giả thích những công cụ giúp xử lý việc lặp lại, giúp hiểu codebase và giúp viết đúng chương trình, nhưng cảm thấy khó chịu với những sản phẩm được thiết kế để suy nghĩ thay mình
- Tác giả từ chối những sản phẩm tước bỏ tính chủ thể trong sự thấu hiểu của bản thân về phần mềm mình tạo ra, đồng thời cắt đứt kết nối với đồng nghiệp
- Ngay cả khi LLM thực sự đáp ứng được lời thổi phồng, chúng ta vẫn sẽ mất đi tất cả những điều này cùng kỹ năng của mình
- Con người quan trọng hơn máy móc và các công ty đứng sau chúng, trong khi phần còn lại của chúng ta mải chạy theo giấc mơ Mỹ mới mà họ đang bán thì họ là bên hưởng lợi
- Đổi lại, chúng ta đang dâng nộp năng lực tư duy phản biện, niềm vui, kỹ năng, quyền riêng tư, và có lẽ cả hành tinh này
3 bình luận
Nhìn chung là đồng cảm
Đặc biệt là chuyện chuyển đổi ngữ cảnh? Việc phải gửi prompt rồi chờ khiến mất tập trung và làm giảm năng suất. Có lẽ nếu tốc độ của LLM tăng lên để phản hồi gần như tức thì thì vấn đề này có thể được giải quyết.
Tôi có cảm giác khá rõ là ngay từ đầu bài viết đã định sẵn kết luận theo kiểu áp đặt. Vấn đề quyền sở hữu và trách nhiệm của lập trình viên bị loại bỏ, theo tôi, có thể được đọc như câu chuyện về "thời đại tinh thần thủ công vs thời đại công nghiệp hóa" hơn là liên quan đến LLM.
Ý kiến trên Hacker News
Điều khiến tôi ấn tượng nhất là nhìn các reviewer dần suy sụp tinh thần khi nhận ra rằng giờ họ không còn là bước cuối của kiểm soát chất lượng nữa mà đã trở thành tuyến phòng thủ đầu tiên. Họ nhận review request, nhưng giờ phải tự mình lôi ra từng thứ như các hàm mới thêm vào nhưng không hề được gọi, thư viện đột nhiên xuất hiện, hay những lỗi runtime hoặc compile quá rõ ràng. Người viết code thì né trách nhiệm kiểu “tại Claude viết đấy, AI lại mắc lỗi rồi, haha” rồi cho qua. Từ sau khi đưa LLM vào, định luật Brandolini (năng lượng để bác bỏ điều nhảm nhí lớn hơn rất nhiều so với năng lượng để tạo ra nó) lại càng thấy đúng hơn bao giờ hết. Khi các lập trình viên ít kinh nghiệm hoặc kỹ năng kém có thể tuôn ra hàng nghìn dòng code chỉ trong vài phút, trách nhiệm đảm bảo tính lành mạnh của hệ thống trên thực tế bị đẩy sang cho reviewer. Nhìn vào mức tăng giảm code của PR (added/removed LoC delta), PR do LLM viết gần như chỉ liên tục thêm vào, còn các senior engineer dày dạn thì thường xóa bớt code cũ nhiều không kém lượng code mới họ thêm vào
Theo tôi đây không phải vấn đề công nghệ mà là vấn đề con người. Một khi chuyện này xảy ra thì phải cảnh cáo nghiêm khắc, nếu lặp lại lần thứ hai thì nên đẩy lên cho quản lý và từ chối. Dù ai viết PR thì cuối cùng sản phẩm vẫn mang tên người đó, nên nếu code tệ thì chính họ cũng phải chịu trách nhiệm
Giờ tôi không còn làm code review trong các đội lớn nữa, nhưng nếu rơi vào hoàn cảnh đó thì kiểu trốn tránh trách nhiệm này tôi có thể bỏ qua một lần, nhưng nếu lặp lại thì tôi sẽ tìm cách đuổi người đó đi. Nếu không làm được thì tôi sẽ nghỉ việc. Môi trường đó tệ đến mức ấy
Tôi nghĩ việc dạo này cảm thấy năng suất của mình giảm cũng có liên quan đến chuyện này. Một phần là áp lực phải tạo ra nhiều code hơn, nhanh hơn; phần khác là khi dùng agent kiểu đó thì tôi không nắm được toàn bộ ngữ cảnh của đoạn code mình viết. Tôi chỉ có thể đảm bảo chất lượng trong phạm vi mà mình đủ sức review cẩn thận từng dòng, và đó là giới hạn. Vì vậy dạo này tôi dùng AI chậm hơn, bảo thủ hơn, và tăng tỷ trọng tự tay viết code. AI có ích đôi chút khi cần áp dụng lặp lại các định nghĩa kiểu hay spec rõ ràng cho nhiều thuộc tính, nhưng ngay cả lúc đó kết quả cũng không phải lúc nào cũng đáng tin
Những senior engineer càng nhiều kinh nghiệm thì càng hay gọt bỏ code cũ nhiều ngang với lượng code họ thêm vào. Bài Negative 2,000 Lines Of Code cũng đáng đọc
Một khi có LLM chen vào, tôi nghĩ góc nhìn về việc chúng ta đổ trách nhiệm cho ai trở thành một vấn đề xã hội rộng lớn hơn. Người ta nhận công về mình khi kết quả tốt, còn khi có chuyện thì rất dễ đổ cho AI. Chỉ cần có vài vụ kiện tiêu biểu đúng chỗ là văn hóa này sẽ thay đổi mạnh
Tôi có cảm giác từ lâu rồi, nhiều người bước vào ngành này xem code không phải là một nghề thủ công đáng tự hào mà chỉ là phương tiện kiếm tiền dễ dàng. Từ lúc tôi đọc những bài viết về các nhà phát triển hạ tầng mã nguồn mở sống chật vật, rồi hình ảnh developer ngồi code trong quán cà phê, bootcamp và phong trào “chỉ cần học code là đủ”, các Leetcode grinder, cho đến những kỹ sư ở San Francisco phải sống trong xe vì giá nhà đắt đỏ, giờ thì lại đến chuyện dùng AI để tự động hóa chính bản thân mình rồi mất việc. Vấn đề là nhận thức rằng developer không phải những professional đúng nghĩa. Chuẩn mực thì lỏng lẻo, không có bộ quy tắc đạo đức, không có bộ kỹ năng nhất quán, cũng chẳng có tính đại diện. Thậm chí người trong ngành còn thiếu tính chủ thể đến mức đi ngược lợi ích của chính mình. Luật sư có đoàn luật sư, bác sĩ có hiệp hội y khoa, còn developer thì chỉ có nỗi bất an hiện sinh. Giờ sếp còn dọa kiểu “tao sẽ tự động hóa công việc của mày bằng AI”. Các nghề chuyên môn khác không thù địch với lợi ích của mình đến vậy, nên tôi thật sự tự hỏi vì sao chỉ ngành này lại như thế
Tôi nghĩ “coder” và software engineer là hai thứ khác nhau. Chỉ vì học xong bootcamp và viết được vài chương trình Python đơn giản không có nghĩa là bạn là software engineer. Mỗi khi tôi nhắc đến chuyện mình có bằng cấp thì lại bị bảo là tinh hoa chủ nghĩa, rồi người ta nói những gì học trong ngành khoa học máy tính đều vô dụng trong công việc thực tế. Nhưng rõ ràng cũng có những người không có bằng mà vẫn tự rèn được thành kỹ sư xuất sắc. Dù vậy, tôi vẫn đồng ý rằng bằng cách nào đó chúng ta cần có chuẩn mực. Với các bootcamper vào làm ở startup kỳ lân đang chạy theo buzzword mới nhất thì cứ chúc mừng họ thôi, nhưng với những hệ thống nhạy cảm kiểu Therac-25 thì tốt hơn hết nên để những người được đào tạo bài bản đảm trách
Sếp nói “nếu cậu không tự động hóa thì công việc của cậu sẽ biến mất” à? Nhưng đó chính là công việc của chúng ta. Tự động hóa lao động là bản chất công việc của chúng ta, và chúng ta cũng là nhóm có nhiều cơ hội lẫn hiểu biết nhất để tự động hóa chính nơi làm việc của mình
Tôi nghĩ nghề dạy học cũng có nhiều điểm giống nghề lập trình. Có giáo viên rất giỏi, có người rất tệ, và rất nhiều người ở giữa. Biết môn học không đồng nghĩa với việc dạy giỏi. Có lẽ developer có thể được xem như những giáo viên đang dạy cho máy móc. Có người dạy từng ký tự, từng ý nghĩ cho nhân vật Munchkin, cũng có người dạy theo kiểu truyền cả bầu không khí tổng thể
Tạm gác LLM sang một bên, thỉnh thoảng tôi vẫn viết được những đoạn code mà chính mình thấy tự hào vì mức độ hoàn thiện của nó. Từ cấu trúc cho đến từng dòng đều không có quyết định nào là vô cớ; với đoạn code đó, tôi là chuyên gia và nắm nó trọn vẹn. Nhưng phần lớn code thì tôi không viết hoàn hảo như vậy. Đa phần là kiểu “làm xong việc là được”, tự cho phép mình hạ chuẩn xuống một chút. Dù vậy, những lúc thực sự nhập tâm và hoàn thành tử tế thì rất đáng giá, đó là những trải nghiệm viết code tuyệt nhất trong đời tôi. Nếu nghĩ thêm về LLM, thì một mặt nó khiến việc code ở mức hoàn thiện cao trở nên dễ hơn, nhưng mặt khác cũng khó hơn tương ứng. Về mặt tâm lý, khi đã vào được trạng thái tập trung sâu, tôi có thể tận dụng LLM tốt để tạo ra kết quả nhanh hơn và đạt chuẩn cao hơn. Tôi có thể viết tốt hơn hẳn code do LLM tạo ra, nhưng cũng có thể dùng LLM để viết ra code còn xuất sắc hơn nữa. Tuy nhiên, việc duy trì trạng thái tập trung đó ngày càng khó. Ta bắt đầu lướt qua thứ code LLM tạo ra, thấy giao diện cũng đẹp, chạy cũng đúng, thế là cho qua luôn. Nhưng thứ code được cho qua hời hợt như vậy sẽ ngày một rối hơn, và nếu cứ tiếp tục chấp nhận trong trạng thái chai lì đó thì đến lúc nhận ra đã quá muộn. Kết quả là bản thân bạn không bao giờ thật sự trở thành chuyên gia của chính đoạn code ấy, chỉ tích lũy thêm những đống code chắp vá
Tôi đọc bài luận này rất thích vì nó khớp đúng với suy nghĩ của mình. Ở công ty tôi cũng từng thử dùng AI, nhưng phần lớn trường hợp kết quả không ra gì nên cuối cùng gần như tôi phải tự viết lại hết. Tôi ngày càng tin chắc rằng giao thời gian suy nghĩ hoặc giải quyết vấn đề cho AI là lựa chọn tệ nhất đối với sự nghiệp của mình. AI chỉ là một cỗ máy sinh văn bản chất lượng tầm trung mà thôi
Với câu hỏi “rốt cuộc mấy người đó tại sao lại quyết định trở thành programmer, trông họ còn chẳng quan tâm đến bản thân code”, tôi muốn nhấn mạnh rằng “mục tiêu là giải quyết vấn đề”. Coding là phương tiện chứ không phải mục đích tự thân. “Tùy chỉnh editor, dotfiles, nghịch môi trường phát triển” có thể vui, nhưng tôi xem đó là độ phức tạp vô ích và sẵn sàng giao nó cho người khác
Tự tay thiết lập editor, dotfiles và môi trường phát triển rốt cuộc là cách để mình quen thuộc hơn với môi trường làm việc, nâng kỹ năng công cụ và tạo ra một môi trường năng suất hơn. Việc phải trở thành “người được gọi đến” khi ai đó cần chỉnh build script xuất phát chính từ việc mình đã quản lý những thứ đó. Có quá nhiều người dùng Git mười năm, hai mươi năm mà vẫn không biết xử lý merge conflict hay nắm được những thao tác cơ bản, nên rốt cuộc mọi việc phiền phức đều dồn vào những người thật sự chịu học công cụ cho đến nơi đến chốn
Kiểu khẳng định “cái này không có giá trị” nếu đẩy logic đi đến cùng thì có thể trượt thành “vậy thì bản thân sự tồn tại có giá trị gì”
Gần như mọi nghề trên đời đều nhằm giải quyết vấn đề, nhưng tôi vẫn thắc mắc tại sao giữa chừng ấy nghề người ta lại chọn phần mềm
Tôi đồng ý 100% với ý “mục tiêu là giải quyết vấn đề, coding chỉ là phương tiện”. Những người buồn bã khi AI thay họ code là kiểu “nghệ sĩ viết code”, tức gắn bó nhiều hơn với chính “hình thức” của thứ mình tạo ra. Còn tôi tập trung vào bản thân vấn đề, nên chuyện AI code thay mình chẳng có gì đáng tiếc
Lập luận “coding không phải mục đích mà là phương tiện”, cũng như ý “vọc editor vui nhưng không có giá trị”, đều là những nhận định cực kỳ chủ quan. Sẽ luôn có những người thích bản thân việc code một cách thuần túy, kể cả khi không còn vấn đề nào cần giải quyết; và nếu thế giới không có lấy một vấn đề nào thì vẫn sẽ có rất nhiều người thích code
Tôi đọc bài này thấy rất thú vị. Nó gần như trùng khớp với cảm giác của tôi về lập trình với LLM. Tôi vốn là người đơn giản là thích code, và cũng đã tận hưởng nó như một nghề nghiệp. Nhưng dạo này tôi thấy tiếc vì trong công việc, sở thích mình từng yêu thích không còn được phát huy nữa. Nó đã trở thành một loại công việc hoàn toàn khác
Tôi cũng có tuổi rồi. Khoảng năm 1995, việc lập trình diễn ra trong một môi trường hoàn toàn khác bây giờ. Khi đó kỹ sư hiểu khách hàng mục tiêu, hiểu stack công nghệ, hiểu xu hướng ngành, và thật sự nắm quyền chủ động. Code của mình là sân chơi của mình; bạn có thể đập đi làm lại theo ý thích, tự chọn cả kiểu thụt lề lẫn dấu ngoặc (hỏng thì tự sửa). Hồi ấy không có unit test như bây giờ (cùng lắm chỉ kiểm tra tham số), cũng hiếm khi có code review chính thức; thay vào đó là đồng nghiệp đứng nói chuyện trong văn phòng và vẽ vời trên bảng trắng. Có bug thì sửa ngay. Cuối cùng phía quản lý đã thắng, và có lẽ thời đại “cowboy coding” như thế khó mà quay lại được nữa. Có thể bạn nhớ Apple của thập niên 90, nhưng ta không thể quay về thời đó nữa. Hồi đó thực sự rất vui
Tôi cũng bắt đầu vào thời kỳ tương tự, nhưng bên tôi có code review định kỳ vì ISO 9001. Chúng tôi in toàn bộ đầu ra ra giấy, ba người ngồi chung một phòng kiểm tra từng dòng rồi ký xác nhận. Việc đó được áp dụng cho RTOS điều khiển công nghiệp. Quản lý dự án thì dùng biểu đồ Gantt dài 40 foot in ra và dán lên tường. Đúng kiểu thời kỳ waterfall nguyên bản
Tôi bắt đầu vào cuối những năm 2000, khi đó lộ trình nghề nghiệp và ranh giới chuyên môn rõ ràng hơn nhiều. System administrator và developer tách biệt hẳn, còn giờ người ta lại kỳ vọng tôi làm luôn cả vai trò vận hành hệ thống nên phạm vi công việc rộng hơn hẳn. Tôi chỉ rèn kỹ năng hệ thống như một sở thích, và thật sự nếu giao việc kiểu đó thì trong thực tế tôi còn muốn né vì tài liệu vendor hay các khóa training thường quá sơ sài
Có lẽ cả ngành sẽ không quay lại kiểu cowboy coding, nhưng tôi nghĩ ở một số môi trường nó vẫn còn tồn tại. Ở WhatsApp trong giai đoạn 2011–2019 chẳng hạn, môi trường khá tự do. Tùy từng môi trường mà cái gì phù hợp sẽ khác nhau, dựa trên chi phí phát hiện lỗi trước production so với sau production. Cá nhân tôi thích cách tiếp cận làm giảm chi phí sửa lỗi. Tất nhiên vẫn cố tránh những lỗi ngớ ngẩn và vẫn test những thứ thực sự cần test
Giờ quá nhiều kiểu người mang tư duy kinh doanh, vibe coder và script kiddie tràn vào nên mọi thứ đều tệ đi
Vấn đề của cowboy coding là chỉ cần một thành viên không đáng tin là có thể phá hỏng cả đội. Tổ chức càng lớn thì càng khó tránh có thêm những người như vậy, và để ngăn vấn đề bùng nổ thì lại cần thêm những cơ chế ngày càng cồng kềnh. Với các đội nhỏ tinh nhuệ dựa trên niềm tin, cowboy coding là cách hiệu quả nhất; nhưng vì việc đánh giá năng lực ứng viên khi tuyển dụng rất khó nên nó hoàn toàn không phù hợp với tổ chức lớn. Sau này kiểu làm việc đó có lẽ chỉ còn sống được ở các công ty nhỏ hoặc những đội nhỏ nằm trong các tập đoàn lớn
Tôi khó mà đồng ý với câu của tác giả rằng "<i>LLM là giải pháp kiểu vũ khí hạt nhân cuối cùng nhắm vào sự phức tạp của phần mềm. Thay vì giải quyết vấn đề thật, nó mang đến sự phức tạp còn lớn hơn để làm dịu triệu chứng</i>". Mục tiêu cốt lõi của việc đưa AI vào là tập trung hóa những “nhân sự sáng tạo, đắt đỏ, tay nghề cao” vào số rất ít công ty thiết kế AI, còn ở mọi công ty khác thì sa thải creative worker và chỉ giữ lại lao động đơn giản. Nói cách khác, mục tiêu là dùng AI để đơn giản hóa mọi độ phức tạp của doanh nghiệp. Lấy ví dụ từ "Phù thủy xứ Oz", không ai muốn nhìn sau tấm rèm, họ chỉ muốn công việc của mình dễ hơn. Đây là hệ quả của việc ai cũng phớt lờ rủi ro dài hạn để chộp lấy lợi ích ngắn hạn
Tôi rất thích bài này. Tôi cũng đồng ý với một số ý kiến rằng giải quyết vấn đề quan trọng hơn code. Nhưng theo tôi, nếu bắt đầu giao cả những bài toán đòi hỏi suy nghĩ sâu cho AI, thì chính năng lực giải quyết vấn đề sâu như thế của con người có thể sẽ mai một theo thời gian. Chỉ đơn giản ra lệnh “hãy làm ra cái gì đó” không phải là giải quyết vấn đề thực sự