Chất lượng trong thời đại Slop

 (sinclairtarget.com)
1 điểm bởi GN⁺ 2 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Mượn khái niệm cốt lõi Quality (chất lượng) từ cuốn bestseller năm 1974 "ZAMM" để khám phá xem liệu 'code tốt' và tinh thần người thợ thủ công (craftsman ethos) còn giữ nguyên giá trị trong thời đại các công cụ lập trình AI lan rộng hay không
  • Khi AI sản xuất hàng loạt mã nguồn, cảm giác khủng hoảng rằng chỉ còn lại "code chạy được và code không chạy được", còn ranh giới giữa code đẹp, xuất sắc hay đáng giá có thể biến mất được gọi là the Maw (hố hư vô)
  • Bảo dưỡng xe máy và bảo trì phần mềm về bản chất là cùng một hoạt động, trong đó quan sát tỉ mỉ và tư duy chính xác là cốt lõi
  • Khái niệm Quality của Pirsig hợp nhất cách hiểu lãng mạn (romantic) và cách hiểu cổ điển (classical), đồng thời cho rằng ngay trong nền tảng của khoa học và toán học cũng đã hàm chứa các phán đoán thẩm mỹ và phán đoán về chất lượng
  • Nếu giao việc lập trình cho các AI agent, ta sẽ đánh mất sự gắn bó (caring/đồng nhất hóa) với công việc và 'cảm nhận về chất lượng của công việc', vì vậy điều quan trọng là phải theo đuổi human excellence (sự xuất sắc của con người) trong chính công việc của mình

Cuốn sách mang tên ZAMM

  • Bài viết này gần như hoàn toàn nói về cuốn bestseller năm 1974 "Zen and the Art of Motorcycle Maintenance (ZAMM)", đồng thời cũng bàn về AI
  • ZAMM thường bị xem là một cuốn sách khoa trương, lên mặt (pretentious); điểm GoodReads là 3.78, nhưng cũng có rất nhiều đánh giá chê bai
    • "Zora": chấm 1 sao và nói đây là một cuốn giả triết học ngụy trang thành tiểu thuyết, thậm chí còn là cú lừa lớn hơn cả Kinh Thánh, không đáng đọc nổi 3 phút
    • "Lala BooksandLala": chấm 1 sao chỉ với một câu "absolutely not"
  • Thành thật mà nói, tác giả cũng thừa nhận một bài blog về ZAMM và AI có thể không nghe quá vui vẻ

the Maw — hố hư vô mở ra trong ngành công nghệ

  • the Maw là một cái hố của chủ nghĩa hư vô (nihilism) mở ra ngay giữa ngành công nghệ, và là chủ đề của khoảng 63% các bài blog được tổng hợp trên các trang kiểu Hacker News
  • Một số bài gần đây liên quan đến chủ đề này gồm “Do I Belong in Tech Anymore?”, loạt 10 phần “The Future of Everything is Lies, I Guess.”, và “I Think I’m Done Thinking About Gen AI for Now,”
  • Các kỹ sư phần mềm vốn không ngại công nghệ mới, nhưng lại đang tìm lý do để từ chối các công cụ lập trình agentic mới nhất, và cảm thấy khó chịu trước hàm ý rằng đại số tuyến tính (linear algebra) đang viết phần mềm

  • Tranh luận Commenter A vs Commenter B

    • Người bình luận A phàn nàn rằng Claude Code đã đặt tên hàm theo kiểu dễ gây hiểu nhầm một cách tinh vi
    • Người bình luận B (một tín đồ của Maw) phản bác rằng AI đọc toàn bộ thân hàm để hiểu ý nghĩa nên tên gọi là vô nghĩa, và chẳng bao lâu nữa con người sẽ không còn đọc code nữa
    • Lập luận của người bình luận B nghe như đang nói rằng toàn bộ ngành kỹ nghệ phần mềm (kiến thức về best practice, kiến trúc, khả năng bảo trì) sắp trở nên vô dụng
  • Điều đáng sợ nhất ở the Maw là nó muốn xóa bỏ vĩnh viễn sự phân biệt giữa good và bad, để rồi chỉ còn code chạy được và code không chạy được; một thế giới không còn code đẹp, xuất sắc hay thông minh duyên dáng
  • Câu hỏi cốt lõi là: liệu vẫn còn tồn tại lập trình viên giỏi và code tốt hay không, vì sao cái 'tốt' lại quan trọng, và một lập trình viên giỏi sử dụng công cụ AI sẽ trông như thế nào

Thực ra ZAMM là một cuốn sách về lập trình

  • Trên thực tế, ZAMM hoàn toàn có thể được gọi là "Zen and the Art of Software Maintenance", vì bảo dưỡng xe máy và bảo trì phần mềm về bản chất là cùng một hoạt động
  • Bản chất của việc bảo trì không phải lao động chân tay mà là quan sát tỉ mỉ và tư duy chính xác; người thợ tập trung vào các hình ảnh tinh thần và hệ thứ bậc trong đầu (chương 9 của ZAMM)
  • Dù là động cơ hỏng hay một web service bị deadlock, quy trình debug là như nhau; cũng giống meme "wired in" trong phim "The Social Network" năm 2010, người thợ sửa máy cũng đang xây những tòa tháp trừu tượng trong đầu
  • Các lời khuyên vật lý trực tiếp trong ZAMM chỉ có hai điều (đặt ghế ở hai bên xe đạp để bảo vệ lưng, và xử lý linh kiện chính xác một cách tinh tế); còn lại đều nói về trạng thái tinh thần của người thợ

  • Gumption Trap (bẫy hụt hơi)

    • Gumption là phần dự trữ ý chí dùng cho hoạt động trí tuệ mang tên bảo trì, được ví như "psychic gasoline (nhiên liệu tinh thần)"
    • Gumption trap là những sự cố làm cạn sạch động lực trong quá trình bảo trì chỉ trong một lần
      • intermittent failure setback: khi vừa định sửa thì vấn đề lại biến mất; tương ứng trong phần mềm là could-not-reproduce / Heisenbug
      • impatience trap: đánh giá thấp thời gian công việc, bị lịch trình thúc ép nên chọn đường tắt, rồi mắc sai lầm lớn khiến còn chậm hơn

  • Pirsig là người mê máy tính

    • Tại Smithsonian có trưng bày một chiếc Apple II cắm 7 card mở rộng cùng với chiếc Honda Super Hawk 1966
    • Apple II ra mắt năm 1977, tức là được ông mua sau khi ZAMM xuất bản, nhưng trước đó ông đã làm technical writer cho Honeywell
    • Trong ZAMM có nhiều phép so sánh liên quan đến mạch điện và manual của máy tính số; nếu được viết muộn hơn 10–20 năm thì hẳn đây đã là một cuốn sách về máy tính

Quality (Q viết hoa) — tư tưởng cốt lõi của ZAMM

  • Việc ZAMM nói về bảo trì rốt cuộc chỉ là con đường dẫn tới tư tưởng trung tâm của nó: Quality (chất lượng)
  • ZAMM được cấu trúc gần như một tiểu thuyết trinh thám trí tuệ
  • Khởi đầu nằm ở chương 1, khi Pirsig nhận ra rằng thái độ của ông với chiếc mô tô của mình rất khác với thái độ của người bạn đồng hành John

  • Sự đối lập giữa John và Pirsig

    • John mua chiếc BMW Đức đáng tin cậy nhất chỉ để tránh việc tự bảo dưỡng vừa phiền phức vừa xấu xí
    • Pirsig lại thấy vẻ đẹp trong cơ chế vận hành bên trong của chiếc mô tô, và cho rằng thái độ không muốn hiểu nó là thiếu thực tế
    • Liệu có một ý tưởng nào có thể gắn kết hai cách nhìn ấy hay không chính là bí ẩn của ZAMM
    • Thái độ của John thuộc về cách hiểu lãng mạn (romantic) — cảm xúc và ấn tượng tức thời; còn của Pirsig là cách hiểu cổ điển (classical) — hình thức nền tảng và trừu tượng logic
    • Pirsig cho rằng trong thập niên 1960–70, nhiều người xem công nghệ là thứ thù địch, áp đặt và “square”; xã hội và công nghệ bị cách hiểu cổ điển thống trị quá mức nên hai kiểu hiểu này bị tách rời
    • Chính vì hai cách hiểu bị tách ra và xã hội bị cách hiểu cổ điển chi phối, nên cần một fulcrum idea (ý niệm điểm tựa) để hòa giải chúng

  • Sự giác ngộ trong lớp hùng biện

    • Pirsig nhớ lại thời mình dạy hùng biện ở đại học, khi ông bắt đầu hoài nghi về việc rốt cuộc mình nên dạy sinh viên điều gì
    • Nhiệm vụ của ông là dạy sinh viên viết hay
    • Viết tốt được giảng dạy bằng những thủ pháp như metaphor (ẩn dụ), parallelism (kết cấu song song), anaphora (điệp ngữ); nhưng dù có đủ những thủ pháp ấy vẫn có thể viết dở, còn không có cái nào vẫn có thể viết hay
    • Sinh viên vẫn phân biệt được bài viết hay và dở ngay cả khi không biết các thủ pháp, nghĩa là cần đến một kiểu hiểu romantic mà đại học (pháo đài của cách hiểu cổ điển) khó lòng giảng dạy
    • Điều Pirsig thực sự muốn dạy chính là Quality
      ai cũng nhận ra được nhưng không thể định nghĩa hình thức, và đó là khái niệm gắn kết cách hiểu lãng mạn với cách hiểu cổ điển

  • Siêu hình học của Quality và sự xuất sắc của cái tên

    • Không thể đo đếm được việc một bài viết, một chiếc mô tô hay một trải nghiệm nào đó có Quality cao hay thấp, nên nó không khách quan; nhưng vì Quality được xem là thứ tạo ra chủ thể nên nó cũng không đơn thuần chủ quan
    • Quality không thể đo lường nên không khách quan, lại tồn tại trước cả chủ thể nên cũng không chủ quan; nó là một cái sàng (sieve) áp dụng trước cả chủ thể và khách thể
    • Sự xuất sắc của tên gọi "Quality" nằm ở chỗ nó trộn lẫn nghĩa "giá trị cao" và "đặc tính/thuộc tính", hàm ý rằng cái Good được tranh luận từ thời Plato là thứ được tri giác tức thì trước cả logic và lý tính
    • Pirsig cho rằng khoa học và toán học trong phạm vi của mình thì nhất quán và logic, nhưng ở nền móng và vùng rìa của chúng vẫn có các phán đoán Quality
    • Trong hình học, một khi đã chọn tiên đề thì có thể suy diễn chắc chắn; nhưng nếu chọn các tiên đề khác thì sẽ ra các hình học khác, và việc tiên đề nào “đúng hơn” gần với sở thích và mức độ phù hợp mục đích hơn
    • Trong khoa học, sau khi hình thành giả thuyết thì phương pháp khoa học có thể chỉ ra bước tiếp theo; nhưng giữa vô số giả thuyết khả dĩ, việc chọn cái nào lại gần với nghệ thuật vì không có phương pháp cố định
    • Henri Poincaré nói rằng nhà toán học hay nhà khoa học ở tuyến đầu tri thức phải chọn một khả năng trong số rất nhiều khả năng được suy ra từ các quy luật hiện có, và quy tắc dẫn dắt lựa chọn đó quá tinh tế để diễn đạt chính xác, cần được cảm nhận hơn là công thức hóa
    • Occam’s Razor cũng là nguyên lý chọn lý thuyết đơn giản hơn, nhưng việc phán đoán rằng cần loại bỏ những giải thích không cần thiết đến cùng vẫn là một phán đoán thẩm mỹ và phán đoán Quality
    • Cần vứt bỏ châm ngôn rằng “khoa học và đứa con của nó là công nghệ thì trung lập giá trị, tức quality-free”; ấn tượng về Quality đóng vai trò như đầu tàu chỉ hướng cho chuyến tàu tri thức đi về đâu

Phê phán AI và lời giải từ ZAMM

  • Phần lớn các phê phán AI tập trung vào việc liệu các công cụ agentic có hoạt động đúng như quảng cáo hay không (phá nát codebase, hallucination ra các hàm không tồn tại)
  • Dù thừa nhận rằng các công cụ AI hiện tại thường xuyên mắc lỗi, tranh luận về hiệu quả có thể vẫn lệch khỏi điểm cốt lõi
  • Nhiều kỹ sư có thể vẫn không muốn dùng công cụ agentic ngay cả khi chúng thực sự hoạt động đúng như quảng cáo

  • Trong bài "I Think I'm Done Thinking about Gen AI"

    • Tác giả không thể bác bỏ lập luận thực dụng của phía đối diện bằng dữ liệu; trải nghiệm genAI của bản thân thì rất tệ nhưng cũng chỉ là giai thoại, trong khi dữ liệu khoa học hầu như không có
    • Nguồn gốc của thiên kiến tiêu cực là việc đặc tính thẩm mỹ của genAI gây khó chịu đến cực độ, và tác giả đi đến kết luận rằng dù miễn phí cũng sẽ không dùng
  • ZAMM đã giúp tôi theo 2 cách

    • Cách thứ nhất — tôi đã bị mắc kẹt trong tư duy cổ điển

      • Vai trò quan trọng nhất của Quality là mở rộng lý tính, tức đồng hóa những yếu tố phi lý tính mà trước đây không được chấp nhận
      • Việc không đồng hóa được các yếu tố phi lý tính tạo ra "một tinh thần hiện đại rối loạn và đứt gãy", và vì tư duy cổ điển thống trị nên từ trước đến nay ta vẫn xem nhẹ (discount) sự phản kháng bản năng đối với AI
      • Ý kiến của mọi người đều chủ quan như nhau, và ngay cả trước nghiên cứu nói rằng "dùng coding agent làm tăng lượng code thêm 50%", ta vẫn có đầy đủ chính danh để hỏi "vì sao lại cần thêm số code đó, và phán đoán Quality nào đóng góp cho sự hưng thịnh của con người"

    • Cách thứ hai — hiểu rõ bản chất của sự phản kháng

      • Công nghệ hiện đại bị chi phối bởi góc nhìn subject-object (chủ thể-khách thể) tách biệt, và manual sản phẩm mặc định người dùng là một thực thể không can dự, chỉ việc 'thao tác' lên sản phẩm
      • Một xã hội nơi những người thờ ơ tạo ra công nghệ để bán cho những người thờ ơ khác
      • Lời giải là người làm kỹ thuật phải đồng nhất hóa (identify) với công việc; khi sự tách biệt giữa chủ thể và khách thể biến mất thì "caring (sự quan tâm/gắn bó)" xuất hiện, và đằng sau đó Quality lộ ra (chương 25 của ZAMM)
      • Trong từng khoảnh khắc làm việc luôn có hàng nghìn ngã rẽ đều hợp lý theo tiêu chuẩn cổ điển, và chỉ Occam's Razor lấy Quality làm trung tâm (cảm nhận về cái tốt) mới giúp ta tiếp tục tiến lên (chương 24 của ZAMM)
      • Nếu giao việc lập trình cho agent, ta sẽ mất "cảm nhận về chất lượng của công việc"; LLM hữu ích cho tìm kiếm hoặc rubber duck, nhưng bản chất của nó là tính ngẫu nhiên (randomness), lại sản xuất code với tốc độ khó mà bắt kịp, khiến ma sát giữa ta và công việc tăng lên và làm cho caring trở nên khó khăn hơn

Kết — trở thành tấm gương trong công việc của chính mình

  • Tác giả mong một thế giới nơi con người đồng nhất bản thân với công việc và theo đuổi sự xuất sắc, và điều ta có thể làm là nêu gương ngay trong chính công việc của mình

"Bước đầu tiên để làm cho thế giới trở thành một nơi tốt đẹp hơn bắt đầu ngay từ tâm trí, đầu óc và đôi tay của chính bạn, rồi từ đó mới lan ra bên ngoài. Người khác có thể nói về việc mở rộng tương lai của nhân loại như thế nào, còn tôi chỉ muốn nói về cách sửa một chiếc mô tô. Tôi nghĩ điều tôi nói sẽ có giá trị lâu bền hơn nhiều." - chương 25 của ZAMM

Bài viết liên quan

1 bình luận

 
GN⁺ 2 giờ trước
Ý kiến trên Lobste.rs

  • Tôi lo rằng phát triển phần mềm sẽ trở thành một nghề đi bộ theo đặc tả. Không phải vì agent thực sự có thể làm được những phần khó và tinh vi nhất của công việc, mà vì phần lớn phần mềm trên đời vốn dĩ chỉ là một đống tạp nham đáng ngờ miễn sao chạy tạm được là xong
    Kết hợp với thị trường chanh điển hình, phần lớn SaaS sẽ trở thành đống tạp nham đầy lỗi và người mua sẽ không còn khả năng phân biệt với thứ tốt. Khi đó giá cả và nhu cầu sẽ giảm. Dù vẫn sẽ có người tiếp tục dùng phần mềm, tổng số nhân lực sẽ giảm và phần lớn công việc có khả năng sẽ là quản lý đống tạp nham. Ngoại lệ sẽ là một số ít may mắn làm ở những nơi như “hệ thống ghi chép” nơi mọi thứ buộc phải hoạt động đúng
    Đó là viễn cảnh trung hạn, còn mục tiêu thật sự của các phòng thí nghiệm AI là tạo ra thứ gì đó có thể thay thế toàn bộ lao động trí óc và thể chất của con người với chi phí rẻ hơn. Họ chưa biết cách, nhưng sẽ thử bằng cách đốt nốt đồng 1 đô la cuối cùng trên Trái Đất. Điều các nhà đầu tư mơ tới thực chất gần như là người kế vị tiến hóa của loài người
    Chính sách AI cá nhân của tôi là thế này. Khi tay nghề thủ công quan trọng, tôi muốn dùng agent viết code như trợ lý của nghệ sĩ, giống những người từng vẽ nền cho các danh họa. Opus 4.8 đã quá thông minh nên ngược lại lại không phù hợp, và chỉ trong một hai giờ liều lĩnh có thể làm tuột mất cả codebase. Hiện tôi thích Qwen3.6 27B vì nó đủ thông minh để lần bug, refactor hoặc triển khai những tính năng được đặc tả rõ trong phần code mà tôi hiểu. Nhưng khoảnh khắc tôi đánh mất sự hiểu biết về code thì mô hình cũng rối theo và tôi lập tức phải trả giá
    Về chính sách công, tôi cho rằng việc tạo ra người kế vị tiến hóa của mình mà không có bảo đảm nào về khả năng cùng tồn tại là điều ngu ngốc. Vì vậy tôi kiên quyết phản đối việc tạo ra trí tuệ thật sự ngang mức con người. Tuy vậy, sự phản đối đó phải ở cấp độ hiệp ước quốc tế. Không phải hiệp ước giả, mà là kiểu hiệp ước mà nếu vi phạm thì Mỹ và Trung Quốc sẽ căng thẳng ở mức sâu sắc và quyết tâm buộc dừng việc chạy huấn luyện. Cấm trung tâm dữ liệu theo khu vực cũng tốt, nhưng nếu ai đó tạo ra SkyNet ở Iceland hay Middle East thì rốt cuộc ta vẫn phải chiến đấu với SkyNet. Việc dừng AI về bản chất là vấn đề ở cấp quốc gia, và quấy rầy các maintainer mã nguồn mở chỉ vì có file AGENTS.md không phải là hành động nghiêm túc
    Vì vậy nhìn chung tôi đồng ý với bài gốc. Phát triển phần mềm có thể là một nghề thủ công đích thực, và tôi đã được làm điều mình yêu thích suốt 30 năm với thù lao tốt. Nhưng nếu mô hình trở nên tốt hơn nhiều, ta có nguy cơ bước vào một thế giới nơi số người thật lòng yêu nghề thủ công phần mềm vượt quá nhu cầu thực tế. Khối vật chất tối là các ứng dụng nội bộ doanh nghiệp phần lớn cũng sẽ hài lòng với đống tạp nham chỉ khá hơn hiện tại một chút, và đó mới là phần lớn việc làm thật sự của nghề này
    Tôi tiếc thương nghề mình đã chọn, nhưng còn tiếc thương thế giới và nhân loại hơn. Không cần phải đổ mọi của cải để tạo ra thứ gì đó thông minh hơn con người, rẻ hơn con người và có thể sao chép bằng lệnh cp. Nhưng chúng ta vẫn sẽ đốt nguồn lực để thử

    • Tôi bắt đầu học lập trình khi khoảng 10~11 tuổi, và vì bị nó cuốn hút nên cứ tiếp tục. Khi có công việc đầu tiên, tôi nhận ra mình sẽ phải làm web development, và trong phần lớn sự nghiệp tôi đã giữ việc lập trình để vui và việc làm vì lương như hai nghề thủ công tách biệt nghiêm ngặt
      Càng lớn tuổi tôi càng gặp nhiều người trẻ học lập trình vì đây là nghề kiếm tiền tốt, và tôi thấy khó hiểu khi họ không có sự mê hoặc mà tôi cảm nhận. Vì vậy tôi không tiếc thương quá nhiều. Nếu số lượng software developer giảm 80%, có lẽ nghề này thậm chí còn trở thành nơi đáng gắn bó hơn
      Tôi cũng đồng ý với việc dùng AI như trợ lý của nghệ sĩ. Ngay cả các mô hình mới nhất cũng không thể để chạy quá lâu mà không giám sát vì tôi biết chúng sẽ phá hỏng mọi thứ. Dù vậy tôi thích có Opus làm trợ lý hơn, vì không cần phải giải thích quá chi tiết. Nhưng sẽ tốt hơn nữa nếu ở đầu dây bên kia là một junior developer thật sự để họ có thể học nghề thủ công. Giống như các trợ lý nghệ sĩ thật sự đã từng làm

  • Điều tôi sợ nhất ở “The Maw” là cảm giác nó muốn nuốt chửng vĩnh viễn ranh giới giữa thứ tốt và thứ xấu. Câu nói rằng kết quả sẽ là một thế giới nơi code đẹp, xuất sắc, đức hạnh hay thú vị biến mất, chỉ còn lại code chạy được và code không chạy được thực sự chạm đúng cảm giác đó

    • Theo tôi “The Maw” không liên quan nhiều đến AI, và thứ cảm xúc này đã bắt đầu từ trước cả khi LLM trở nên giỏi như bây giờ. Đó đơn giản là chủ nghĩa tư bản thiển cận
      Khi viết code như một công việc, bạn phải đáp ứng yêu cầu, và thế là hết. Mục đích của công ty là kiếm tiền, còn mọi thứ khác bị đẩy xuống hàng sau. Khi lãi suất tăng và dòng tiền co lại, áp lực phải cứ thế phát hành thứ code chỉ vừa đủ hoạt động để kiếm tiền đã lớn hơn bao giờ hết
      Theo đuổi cái đẹp và sự thanh nhã là sự xa xỉ của nghệ sĩ, chứ không phải phần việc của công nhân dây chuyền lắp ráp mà nghề lập trình ngày càng giống theo. Đương nhiên trong môi trường như vậy, việc học hỏi, sáng tạo và đổi mới sẽ bị đẩy lùi, nhưng tác động của nó có thể phải vài năm, thậm chí vài chục năm nữa mới cảm nhận được. Đó là một cuộc chơi thiển cận, nhưng lại đủ dài so với nhiệm kỳ trung bình của CEO hoặc cho tới lúc IPO, nên tình hình mới thành ra như bây giờ

  • Bài này có thiên vị vì nói về cuốn sách đã một mình thay đổi cuộc đời tôi, nhưng nhìn chung là rất hay. Tuy vậy, tôi không nghĩ mở đầu bằng những bài viết ra vẻ hợp lý trên Goodreads là một ý hay
    Gumption trap có liên hệ rất chặt với lập trình, và tôi nghĩ ai rồi cũng sẽ gặp từng cái mà Pirsig liệt kê ra vào một thời điểm nào đó trong sự nghiệp. Tôi cũng từng viết về chuyện này trước khi LLM được áp dụng rộng rãi
    Lời khuyên trong ZAMM hợp với lập trình đến mức nếu bạn từng tự hỏi liệu Pirsig có từng lập trình hay không, thì câu trả lời hiển nhiên là có. Trong phần tiếp theo của Z&AMM là Lila, ông còn nhắc trực tiếp đến COBOL
    Tôi nghĩ cách tốt nhất để giải thích chất lượng là xem nó như một tầng nằm bên trên chủ quan và khách quan. Cách giải thích cô đọng nhất nằm trong Lila. Một người ngồi trên bếp lò nóng có thể biết mình đang ở trong một tình huống chất lượng thấp với giá trị tiêu cực mà không cần bất kỳ lập luận triết học nào; và giá trị đó không phải là phán đoán hay mô tả về trải nghiệm, mà chính là bản thân trải nghiệm. Nghĩa là giá trị nằm giữa chủ thể và khách thể, và nó được cảm nhận trực tiếp hơn, thực hơn cả cái “bản ngã” hay “đối tượng” sẽ được quy gán về sau
    Nếu muốn, còn có ghi chú thêm về điều này. Trong Lila, Pirsig cố gắng xây dựng một hệ thống siêu hình học hoàn chỉnh, chia các mẫu chất lượng tĩnh thành vô cơ, hữu cơ, xã hội và trí tuệ, rồi đặt lên trên đó chất lượng động không thể định nghĩa được, vốn là trọng tâm của Z&AMM
    Tôi nghĩ câu hỏi nên là việc áp dụng AI tự thân có phải là một sự kiện chất lượng thấp hay không, hay liệu có thể tích hợp mô hình ngôn ngữ vào công việc của lập trình viên theo cách chất lượng cao hay không. Cách mọi người đang thiết lập quan hệ với AI tạo cảm giác là chất lượng thấp, nhưng lại khó diễn đạt vì thiếu ngôn ngữ và khung tư duy để nói về nó ở cấp độ không dựa trên nhị nguyên chủ thể-khách thể, nên có lẽ vì vậy mà họ chọn cách bác bỏ toàn bộ
    Ở một mức độ nào đó, AI cho phép một cách tiếp cận lãng mạn hơn với lập trình. Nếu chỉ xử lý đầu ra do AI tạo ra ở mức bề mặt và không định đào sâu hơn, thì trong khoảnh khắc đó có thể vẫn ổn. Nhưng khi thực sự nhìn vào bên trong mã nguồn, bạn sẽ nhận ra không có cấu trúc cổ điển nào để bộc lộ ra cả. Mô hình chỉ giả như nó đã làm việc theo cách đó, nhưng thực tế thì không. Có lẽ vì thế mà các lãnh đạo, product designer, nhà đầu tư và solo founder — những người chỉ xem công nghệ như phương tiện để đạt mục tiêu khác — không hiểu rõ được sự thất vọng của lập trình viên trước mã do AI sinh ra
    Nhận xét rằng sách hướng dẫn sản phẩm tiêu dùng mặc nhiên xem quan hệ giữa sản phẩm và người dùng chỉ là vấn đề “thao tác”, đồng thời coi như hiển nhiên thế nào là nướng bánh tốt, cắt cỏ tốt hay tính toán tốt, vẫn áp dụng nguyên vẹn cho tài liệu của thư viện phần mềm và công cụ ngày nay. Gần đây tôi đọc tài liệu về Pi agent, và thấy bức bối vì nó giả định rằng bạn đã biết cách dùng tốt là gì rồi, chỉ đang tìm cách tinh chỉnh cho hợp sở thích. Khi tôi hỏi đồng nghiệp “thế dùng cái này cho tốt thì làm sao?”, họ nhìn tôi đầy ngạc nhiên
    Nó cũng làm tôi nghĩ đến Vim. Chỉ đọc manual của Vim thôi là đủ thấy bối rối. Cần đến hàng chục năm tích lũy các bài viết về “cách dùng Vim cho tốt”. Và rồi sau đó người ta đi đến kết luận rằng nền tảng tối ưu cho việc dùng Vim tốt có thể lại không phải chính Vim, nên mới xuất hiện Kakoune hay Helix
    Với tư cách là cha của một bé gái hai tuổi, tôi xin chúc mừng câu chuyện đang chờ đón đứa con gái đầu lòng. Một hành trình tuyệt vời nhất đời đang chờ phía trước. Nếu tìm tài liệu cùng tinh thần với Z&AMM, tôi gợi ý Surfaces and Essences của Hofstadter và Sander, phần tiếp theo là Lila, cùng với các nội dung của Sevilla King và John Vervaeke

  • Tôi đã đọc hết bài. Không rõ là vì bài hay hay vì khả năng của tôi trong việc bám theo một bài dài, nhưng tôi nghĩ là vế đầu
    Có một điều Robert nói về chất lượng là lý do mọi người cảm nhận chất lượng khác nhau không phải vì bản thân chất lượng khác nhau, mà vì trải nghiệm của họ khác nhau
    Vì vậy, trước khi nói với cả nhóm về chất lượng, tôi tự hỏi trước xem trải nghiệm của chúng tôi có giống nhau không. Nếu không giống, thì nói “hãy cải thiện chất lượng” cũng không có tác dụng. Phải nói cụ thể cần cải thiện điều gì
    Mở rộng điều này sang mã do AI sinh ra, tôi thấy tự hỏi liệu chất lượng có phải cũng thay đổi theo trải nghiệm hay không

  • Một bài viết rất đẹp. Dù không nhận được gì khác từ ngày tận thế AI, ít nhất nó cũng khiến tôi suy ngẫm sâu sắc hơn rất nhiều về mối quan hệ giữa kỹ sư phần mềm và đoạn mã họ viết

  • Thật nhẹ nhõm khi thấy còn có người khác cũng chú ý đến Pirsig. Trong Previously, on Lobsters, họ đang có gần như đúng cùng một cuộc tranh luận mà Phaedrus từng có với các nhà cổ điển về việc liệu một bài luận có chất lượng hay không, chỉ khác ở chỗ bài luận đó do chatbot viết hay do sinh viên con người viết
    Dùng LLM như công cụ tìm kiếm hay một con vịt cao su cực mạnh thì rất hữu ích, nhưng để LLM viết code — khi điểm bán hàng của nó là về bản chất có chứa tính ngẫu nhiên và tạo ra nhiều code hơn mức tôi có thể theo kịp — lại giống như chèn thêm một lớp ma sát giữa tôi và thứ tôi đang tạo ra
    Theo khung của Pirsig, khi một chủ thể con người nhìn vào một vật thể vật lý, chất lượng của sự tương tác đó — tức nguồn gốc của phán đoán giá trị về vật thể — không phải do con người quyết định một cách chủ quan hay do các thuộc tính vật lý của vật thể quyết định một cách khách quan, mà nảy sinh từ chính bản thân sự tương tác. Có thể nói phán đoán là mang tính ngữ cảnh hoặc mang tính tham dự. Không phải mọi vật thể đều tham dự theo cùng một cách. Khi con người quan sát photon, do Kochen-Conway theorem nên photon có một mức độ tự do nội tại trong cách nó phản ứng, còn cây cối thì vì duy trì cân bằng nội môi nên hầu như không đáp lại ánh nhìn. Ở khoảng giữa đó, M. pudica và D. muscipula phản ứng với tiếp xúc và tiếng ồn nhưng không phản ứng với ánh nhìn, nên đây cũng không phải là một phổ một chiều
    Vậy thiết bị chạy LLM hay chatbot phản ứng thế nào trước sự quan sát? Thực ra là không phản ứng. Nó chỉ là một đối tượng toán học hữu hạn và tương đối nhỏ. Mọi thuộc tính đều khách quan, và đầu ra thì không có lựa chọn hay biến dị. Ta có thể thêm một bộ sinh giả ngẫu nhiên để khiến nó đi bộ ngẫu nhiên giữa các token có vẻ hợp lý hơn hoặc kém hợp lý hơn, và ta có thể ép nó nuốt các token do ta chọn để điều khiển bước đi đó, nhưng cũng chỉ đến vậy. LLM trông có vẻ sâu sắc vì nó có tôpô hyperbolic, và việc khám phá không gian hyperbolic tạo cảm giác như phóng to mãi với chi tiết tăng lên vô tận
    Theo lối suy luận của Pirsig, chỉ có hai cách nhìn có thể đi tới về LLM. Một là xem LLM như một hệ thống mang tính ngữ cảnh, lấy đầu vào của con người làm ngữ cảnh cho các phản hồi hợp lý về mặt thống kê; hai là xem nó như một hệ thống khách quan, lấy đầu vào của con người làm đoạn mở đầu cho một phát ngôn hợp lý về mặt thống kê. Dù theo cách nào, LLM cũng gần với một tấm gương phản chiếu người dùng trở lại với chính họ, còn người dùng chỉ chọn góc tiếp cận. Prompt được chọn là phương tiện chính của điều khiển điều khiển học nhằm đạt tới thông tin hay trạng thái mong muốn, còn mô hình chỉ cung cấp một mảng lựa chọn được cấu hình sẵn lớn đến mức áp đảo con người. Có lẽ chatbot gây ra hiệu ứng ELIZA và dễ dẫn đến loạn thần là vì nó là một tấm gương độ trung thực cao, được thiết kế để bóp méo hình ảnh người dùng bằng sự tâng bốc và love bombing, khiến họ nghiện dùng chatbot
    Dùng LLM để viết code khiến tôi thấy như có một bức tường ngăn giữa tôi và máy tính. Các vibe coder thừa nhận điều đó nhưng lập luận rằng, giống như các API khác, bức tường ấy mang lại sự trừu tượng hóa và cô lập. Nhưng theo ẩn dụ tấm gương thì gương không nằm giữa tôi và máy tính mà nằm bên cạnh. Thay vì dùng máy tính trực tiếp, ta nhắm vào gương, cẩn thận phóng to đúng vùng cần thiết, và khi đủ chính xác thì chỉ cần biết rằng từ một góc nào đó có thể nhìn thấy máy tính là đã có thể ra chỉ thị. Nhưng đây không phải là trừu tượng hóa, và sự cô lập cũng yếu hơn. Nó chỉ là làm thêm việc để tìm một điểm nhìn có khi còn không tồn tại
    Lý do vibe coder làm vậy có thể là vì họ không biết cách quan sát máy tính. HCI là mang tính tham dự, và con người cần có ngữ cảnh lập trình trước khi viết code, tức cái “lý thuyết” của Naur được bàn trong previously, on Lobsters. Hoặc cũng có thể chỉ là sự hư vinh: họ thích nhìn vào gương vì gương phản chiếu chính họ. Nhưng tôi thấy thực sự chỉ có hai con đường đó mới có thể có ý nghĩa. Đã có quá nhiều problems between the keyboard and chair, chẳng có lý do gì để thêm một cái nữa mà lại không cải thiện năng lực biểu đạt/trừu tượng hóa

  • Cá nhân tôi cảm thấy nếu có một “đường ranh”, thì mình đang đứng vắt qua cả hai phía của nó
    Một mặt, tôi khao khát mối liên kết và quan hệ với phần code mà mình sẽ tự viết nếu không có AI, và tôi cảm nhận rằng khi dùng AI thì mối liên kết đó biến mất. Điều này là có thật
    Mặt khác, tôi nghĩ việc dùng AI đẩy tôi lên một mức trừu tượng hóa cao hơn, và ở cấp đó cho tôi cơ hội vận dụng sự phân định và áp đặt góc nhìn riêng của mình về chất lượng. Nếu để AI thực hiện code thay mình mà không tham gia đủ sâu, sự kết nối ở cấp độ bản thân code sẽ mất đi hoặc suy yếu. Nhưng ở cấp độ trừu tượng hóa nơi tôi không yêu cầu AI đóng góp, sự kết nối đó không biến mất
    Trong các dự án cá nhân của tôi, cấp độ đó là kiến trúc và định nghĩa giao diện. Gần đây tôi đang xây một harness và pipeline gọi tới nhiều nhà cung cấp LLM, và tôi suy nghĩ rất cẩn thận về đầu vào, đầu ra, luồng điều khiển của các lời gọi, cũng như cách kết hợp chúng thành những luồng đạt được mục tiêu lớn hơn. Nếu dành thời gian và sự chú ý cho quá trình này, tôi cảm thấy dù có mất kết nối với bản thân code, tôi vẫn không mất kết nối với ý định và kiến trúc của mình. Nói cách khác, với tôi chất lượng và tính thủ công không chỉ bị giới hạn ở phần tận dụng AI
    Đây là một ẩn dụ giờ đã hơi cũ, nhưng nó giống với việc trở thành quản lý hoặc điều hành công ty của chính mình. Người ta thường nói cửa ải khó nhất trên hành trình làm CEO là buông bỏ sự kiểm soát — tức kiểm soát việc chính xác tầm nhìn của mình được thực hiện theo cách nào. Với CEO của một công ty đủ lớn, việc biết mọi chi tiết về cách tầm nhìn của mình được triển khai là điều bất khả thi. CTO cũng tương tự, chỉ là ở mức độ nhẹ hơn vì vẫn phải tiếp tục quan tâm phần nào đến các chi tiết kỹ thuật
    Điều mất mát mà tôi đã chấp nhận là giữa thời gian bỏ vào, mức độ hiểu biết và đầu ra của một công việc cụ thể có một trade-off. Tối ưu hai thứ thì sự chú ý sẽ rời khỏi thứ thứ ba. Dù vậy, tối ưu tổ hợp nào đi nữa thì vẫn còn rất nhiều cơ hội để vận dụng sự phân định và gán chất lượng

  • Tôi là commenter B trong bài này, và đã đọc bài rất kỹ. Tôi chưa đọc ZAMM nhưng đã đọc qua Zen một chút.
    Nhận định này khá xác đáng. Phần lớn mọi người, khi có được sự tự do tùy nghi — tức tiền bất ngờ hoặc mức tăng năng suất — sẽ lập tức lãng phí nó và biến nó thành thứ rác rưởi to lớn, phiền toái nhất. Có một nỗi bất an rất rõ ràng quanh chuyện này.
    Những người dùng máy tính có xu hướng không nhận ra cần bao nhiêu tay nghề thủ công và nỗ lực để tạo ra một cuốn sách. Điều này vẫn đúng nếu lần ngược về máy đánh chữ, kỹ thuật in chữ rời, chữ viết tay, trí nhớ của chính mình, và cả khả năng chỉ dùng vẻ đẹp của ngôn từ để thuyết phục người khác lặp lại những lời ấy.
    Việc có máy tính không ngăn con người đầu tư nhiều vào chất lượng đầu ra và tạo ra những thứ tuyệt vời. Chỉ là trên đời cũng có cực kỳ nhiều rác.

  • Một suy nghĩ về ZAMM là quan điểm “lãng mạn” của John về các sản phẩm kỹ thuật, nếu áp dụng theo từng trường hợp cụ thể, thì vẫn có thể được bảo vệ trên phương diện thực dụng.
    Ví dụ, giả sử trong một dự án bạn phụ thuộc vào hạ tầng mã nguồn mở. Nếu phải đào sâu vào một lỗi obscure của kernel hoặc compiler — thứ có thể dễ dàng lách qua, được ghi lại trong tài liệu, và có thể hoàn tác cách lách đó nếu ai đó sửa lỗi — thì điều đó mang lại gì cho dự án? Kết luận là mỗi người phải chọn chiến trường để chiến đấu của mình một cách khôn ngoan.

    • Tôi thực sự đã làm việc như vậy, và một dòng đã được đưa vào dự án Linux Kernel manpages. Tôi không xem đó là lãng phí thời gian, vì trải nghiệm ấy đã khiến tôi trở thành một lập trình viên giỏi hơn.