1 điểm bởi GN⁺ 6 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Hình ảnh phần mềm được vibe coding thay đổi một cách ngẫu nhiên và ngoài dự đoán giống với Tháp Babel, nơi công trình phải dừng lại vì mất đi ngôn ngữ chung; nhưng trong kỷ nguyên AI, điểm khác là việc xây dựng vẫn tiếp diễn ngay cả sau khi sự thấu hiểu đã sụp đổ
  • Giới hạn của phần mềm quy mô lớn không chỉ phụ thuộc vào tốc độ một cá nhân tạo ra mã, mà còn phụ thuộc vào việc điều phối tốt đến đâu sự hiểu biết chung về khái niệm, ranh giới, điều kiện bất biến, quyền sở hữu và lý do thiết kế
  • Ma sát từng phát sinh trong việc khám phá và đặt câu hỏi về mã, review, cũng như trao đổi giữa các nhóm vừa là lãng phí, vừa là quá trình đồng bộ hóa hiểu biết của nhau và xác nhận sự đồng thuận về hệ thống
  • Các agent thực hiện song song những việc như thêm OAuth, caching, tái cấu trúc cơ sở dữ liệu mà không cần trò chuyện; dù mỗi thay đổi đều hợp lý và vượt qua kiểm thử, mô hình chung của con người vẫn có thể suy yếu
  • Trong kỹ thuật phần mềm có AI hỗ trợ, agent diễn giải và chỉnh sửa từng khu vực để công trình tiếp tục mà không thất bại tức thì, nên con người khó nhận ra sự mất mát của ngôn ngữ kiến trúc từng giúp họ cùng suy luận về hệ thống

Sức mạnh của Tháp Babel nằm ở sự điều phối hơn là công nghệ

  • Cách một số phần mềm vibe coding thay đổi theo hướng khá ngẫu nhiên và ngoài dự kiến gợi liên tưởng đến The Tower of Babel của Bruegel
  • Câu chuyện Tháp Babel thường được diễn giải là câu chuyện về kiêu ngạo, tham vọng và lý do con người nói những ngôn ngữ khác nhau, nhưng đồng thời cũng cho thấy sự đoàn kết giúp tiến bộ công nghệ trở nên khả thi
  • Trong Sáng thế ký 11:3–6 (KJV), con người đạt được cải tiến kỹ thuật khi dùng gạch nung thay cho đá, dùng nhựa đường thay cho vữa, rồi cố xây một thành phố và một tòa tháp chạm tới trời
  • Điều Chúa xem là vấn đề không phải là gạch hay kiến thức chế tạo, mà là việc con người là một và cùng chia sẻ một ngôn ngữ, nên không gì có thể hạn chế họ
  • Khi kết hợp công việc của từng người bằng một ngôn ngữ chung, họ có thể xây dựng thứ mà không ai có thể tự mình tạo ra
  • Khi thứ biến mất không phải là gạch hay công thức chế tạo, mà là năng lực hiểu nhau, việc điều phối trở nên bất khả thi và công trình cũng dừng lại

Tòa tháp vẫn tiếp tục cao lên sau khi AI agent loại bỏ ma sát

  • Lập trình có AI hỗ trợ mang đến cho cá nhân những công cụ mạnh hơn; lập trình viên dùng agent có thể thay đổi codebase với phạm vi lớn hơn nhiều
  • Tuy nhiên, giới hạn của các dự án quy mô lớn không chỉ là tốc độ một cá nhân tạo ra mã, mà còn phụ thuộc vào việc con người điều phối hiểu biết về hệ thống sẽ bị thay đổi tốt đến đâu
  • Ngôn ngữ chung của một dự án phần mềm không phải là tiếng Anh hay bản thân Python, mà là sự hiểu biết chung về các yếu tố sau
    • Mỗi khái niệm có ý nghĩa gì
    • Ranh giới hệ thống nằm ở đâu
    • Những điều kiện bất biến nào là quan trọng
    • Ai sở hữu cái gì
    • Vì sao hệ thống có cấu trúc hiện tại
  • Sự hiểu biết này không được ghi chép đầy đủ ở một nơi duy nhất; nó được tích lũy không chỉ trong tài liệu và mã, mà còn qua code review, trò chuyện, tranh luận và trải nghiệm giải thích thay đổi cho người khác
  • Trước khi có agent, nếu muốn thay đổi tầng lưu trữ của người khác, thường phải đọc mã, đặt câu hỏi và trao đổi với nhóm khác đang vận hành các dịch vụ phụ thuộc
    • Quá trình này có phần lãng phí, nhưng cũng có chức năng truyền hiểu biết của một người sang người khác và kiểm tra xem hai bên có còn đồng thuận về cách hệ thống hoạt động hay không
    • Chính những ma sát này đã đồng bộ hóa hiểu biết của con người
  • Agent làm giảm đáng kể những ma sát đó, cho phép nhiều người yêu cầu các thay đổi khác nhau mà không cần trò chuyện với nhau
    • Một người thêm OAuth, người khác đưa caching vào, người khác nữa xây dựng lại cơ sở dữ liệu từ đầu và đổi UI sang màu hồng
    • Mỗi thay đổi riêng lẻ có thể hợp lý; mã có thể biên dịch, vượt qua kiểm thử và thậm chí tạo ra lời giải thích khi cần
    • Không ai cần trò chuyện với người khác, cũng không cần tiếp thu một phần của mô hình chung mà trước đây họ sẽ học được trong quá trình thay đổi
  • Agent không cảm thấy đau, chỉ con người mới cảm thấy đau; chúng còn cho phép thay đổi cả những khu vực hệ thống và codebase mà trước đây cần có sự giúp đỡ của người khác
  • Các dự án vibe coding khi mở rộng trở thành codebase kiểu Tháp Babel không phải vì không thể giao tiếp, mà vì không còn cần giao tiếp nữa
    • Mỗi lập trình viên có một phiên dịch viên không biết mệt, có thể giải thích một khu vực cụ thể của tòa tháp và thực hiện thay đổi cục bộ mong muốn
    • Thay đổi vẫn tiếp tục được đưa vào, nhưng ngôn ngữ kiến trúc từng giúp con người cùng suy luận về hệ thống có thể biến mất
  • Trong Tháp Babel của Kinh Thánh, việc mất ngôn ngữ chung khiến công trình dừng lại; còn trong kỹ thuật phần mềm có AI hỗ trợ, việc xây dựng vẫn có thể tiếp tục ngay cả sau khi sự hiểu biết chung đã sụp đổ
  • Vì tòa tháp không sụp đổ và không có thất bại tức thì xảy ra, rất khó nhận ra điều gì đã mất, và tòa tháp vẫn tiếp tục cao lên

1 bình luận

 
Ý kiến trên Hacker News
  • Từ lâu tôi đã nghĩ khả năng kết hợp của phần mềm nên giống như Tetris, các hàng cần được xóa đi. Những người dùng agent một cách vụng về hoặc các kỹ sư còn ít kinh nghiệm có xu hướng bỏ lỡ việc dọn dẹp này và chỉ tiếp tục xây tháp cao hơn
    Có thể khiến agent lặp lại việc hợp nhất các thành phần hiện có thành những tầng trừu tượng tốt hơn, nhưng ngay cả Fable hay Sol 5.6 vẫn còn kém con người khá xa về cảm quan kiến trúc cấp cao để dự đoán sự tiến hóa tinh vi của phần mềm. Có vẻ các hệ thống hiện tại vẫn chưa duy trì đủ tốt mô hình thế giới chất lượng cao, thưa nhưng có thể phóng to/thu nhỏ mà con người xử lý được, nhưng bản thân việc khoảng cách nay đã thu hẹp đến mức tinh vi như vậy cũng là điều đáng hy vọng

    • Tôi không thể chứng minh điều này, nhưng tôi tin mạnh rằng logic và trực giác cần cho việc trừu tượng hóa có tính đến các thay đổi trong tương lai không thể được hiện thực hóa chỉ bằng chuỗi token dự đoán. Có một thứ gì đó không đo được đang bị thiếu
    • Trước đây năng lực của trí óc con người là giới hạn trên của độ phức tạp chương trình, nhưng vibe coding có thể phá vỡ rào cản đó. Không phải vì vấn đề thực sự phức tạp đến vậy, mà vì quá trình phát triển không hội tụ về những tầng trừu tượng gọn gàng
      Đây là phiên bản AI của vấn đề mở rộng mà Brooks bàn trong 《The Mythical Man-Month》: khi quy mô tăng lên, bùng nổ tổ hợp trở nên tệ hơn và mã triển khai về thực chất cùng một chức năng xuất hiện trùng lặp khắp dự án. Cần có cách khiến việc lập trình dựa trên AI theo đuổi tính cô đọng
    • Cửa sổ ngữ cảnh của con người có thể nhỏ hơn rất nhiều so với LLM ngày nay. Ràng buộc này lại có lợi vì buộc ta phải mô-đun hóa và trừu tượng hóa để có thể giữ công việc trong đầu; còn với LLM có thể chứa nhiều thứ hơn cùng lúc thì không có cùng động lực đó, nên agent tạo ra mã spaghetti không được dọn dẹp
    • Cuối cùng chỉ là vấn đề thời gian. gpt2 hay llama2, nếu so với các mô hình ngày nay, tệ đến mức gây sốc và khi đó cũng gần như vô dụng, vậy mà chúng ta vẫn trầm trồ
      GPT3.5 và gpt4 từng được tung hô giờ cũng đã thua xa qwen27b hay gemma31b. Nếu có đủ thời gian và học tăng cường (RL) phù hợp, các mô hình rồi cũng sẽ xây dựng được trong đầu những mô hình hệ thống phần mềm xuất sắc
    • Có phải đây là kết quả của việc LLM được học tăng cường để giải các nhiệm vụ trong khung thời gian ngắn? Không giống các bài toán vượt qua bài test, những nỗ lực kéo dài nhiều năm, kiến trúc sạch và cảm quan tốt không dễ tối ưu hóa bằng benchmark
  • Luận điểm cốt lõi của bài này gợi nhớ đến Lisp Curse và Bipolar Lisp Programmer. Lập luận khi đó là Lisp khiến cá nhân quá dễ tạo ra điều mình muốn, nên các lập trình viên ít động lực hợp tác để xây những kết quả tổng quát và phức tạp, và vì vậy hệ sinh thái phần mềm công khai lại nghèo nàn hơn so với các ngôn ngữ đòi hỏi nỗ lực đáng kể hơn
    Có vẻ Armin cũng đang đưa ra một luận điểm rất tương tự về lập trình với AI: Lisp Curse, Bipolar Lisp Programmer

    • Các lập trình viên assembly cũng từng đưa ra logic tương tự. Đây là quan niệm lặp đi lặp lại mỗi khi kỹ nghệ phần mềm trải qua một chuyển dịch mô hình, và luôn có những người khó thích nghi với chuyển dịch đó hơn người khác
    • Tôi nghi ngờ liệu đây có thực sự là cùng một logic không. Giờ đây cũng có rất nhiều người cho rằng không cần phải tụ họp để cộng tác nữa, chỉ cần huy động một bầy agent là có thể tạo ra bất kỳ phần mềm phức tạp nào họ tưởng tượng ra
    • Ngược lại, nếu TypeScript và Rust không càn quét thị trường thì bây giờ hẳn là thời điểm tốt để trở thành người điều khiển LLM cho Lisp. Agent dạo này có thể giải thích hầu hết mọi thứ gần như không còn ảo giác, nên nếu có ý chí muốn hiểu thì rào cản để hiểu thực ra gần như đã biến mất, và đó cũng là trọng tâm của bài viết
    • Tiền đề rằng các ngôn ngữ khác đòi hỏi “nỗ lực nhiều hơn rất nhiều” để cho ra cùng một kết quả là điều không rõ ràng. Nhiều lập trình viên không dùng Lisp coi trọng cú pháp, còn các lập trình viên Lisp thì không; và ngay cả sau khi đã trải nghiệm việc tư duy được mở rộng nhờ Lisp, vẫn có nhiều người không thích Lisp
      Có thể tồn tại các kiểu xử lý nhận thức khác nhau giữa hai nhóm. Để Lisp đạt năng suất ngang các ngôn ngữ khác thì phải tích cực tận dụng tính đồng hình (homoiconicity), nhưng hệ quả là các chương trình Lisp nghiêm túc dễ trở thành tập hợp các ngôn ngữ đặc thù miền (DSL) mà chỉ một hoặc hai người hiểu được
  • Giới hạn của các dự án phần mềm quy mô lớn không nằm ở việc mỗi cá nhân có thể viết mã nhanh đến đâu, mà ở việc những người thay đổi hệ thống có thể điều phối mức độ hiểu biết chung về hệ thống đó tốt đến đâu. Nói rằng mọi thứ đã trở nên phức tạp hơn kể từ ngày 30 tháng 11 năm 2022 là hoàn toàn chính xác

    • Phần mềm đã trở nên quá phức tạp khi chồng hết lớp này lên lớp khác, và để xử lý nó, chúng ta lại đang dùng những công cụ tạo ra còn nhiều phức tạp hơn nữa. Trong thập niên 1990 và đầu những năm 2000, ngay cả khi không qua đào tạo chính quy, người ta vẫn có thể tạo ra các ứng dụng mạnh mẽ bằng Visual Basic hoặc PHP, nhưng ngày nay phát triển web hay desktop đã trở nên áp đảo về độ phức tạp, và ngay cả để dùng React cho ra hồn cũng phải biết quá nhiều thứ
      Việc đưa AI vào đây gần như là một sai lầm khi chồng thêm một lớp phức tạp khác lên trên độ phức tạp sẵn có. Nhìn tích cực thì đó là sự lãng phí phần cứng khổng lồ; nhìn tiêu cực thì agent sẽ tạo ra bug mới nhiều ngang với số bug nó sửa, phần mềm rác đầy lỗ hổng sẽ gia tăng, đồng thời con người không học kỹ năng nên năng lực chung của toàn nhân loại có thể suy yếu. Phần mềm về bản chất không nhất thiết phải phức tạp đến mức này, và để giải quyết thì cần coi trọng tinh thần thủ công
    • Việc phải hiểu hệ thống trước khi thay đổi nó không phải điều mới mẻ. Programming as Theory Building của Peter Naur đã xuất hiện từ thập niên 1980, và ngay cả khi chưa từng đọc nó thì trong giới lập trình viên có kinh nghiệm, việc hiểu hệ thống là điều hiển nhiên
    • Không phải mọi thứ đều trở nên phức tạp hơn. Các cơ sở dữ liệu chủ chốt đã tích hợp những công cụ tính sẵn sàng cao thực dụng, microservices đang thoái trào, và cơ sở dữ liệu có cấu trúc đang quay trở lại thay cho NoSQL
      HTML và pre-rendering cũng trở lại cùng với HTMx và LiveView, còn CSS thì đã thoát khỏi những lối lách kỳ quặc của ngày xưa. Nếu giải thích cho đồng nghiệp trẻ cách từng debug trang web trên IE6, sẽ có cảm giác như đã qua cả một thời đại. Có những thứ phức tạp hơn, nhưng cũng có những thứ đã đủ chín muồi để trở nên đơn giản hơn
    • Không phải “sau ngày 30 tháng 11 năm 2022” mà phải nói là mọi thứ đã phức tạp hơn kể từ năm 2022 trước Công nguyên. Sự gia tăng phức tạp gần như chính là lịch sử văn minh nhân loại
      Con người năm 20.000 TCN đi tìm thức ăn, tránh rét và tránh thú săn mồi; nhưng con người năm 5.000 TCN đã trồng trọt, lo mưa và bệnh tật, đồng thời tạo ra các hệ thống để quản lý cộng đồng và đất đai. Ngày nay, đa số không còn tự trồng lương thực mà quản lý sự phức tạp của một xã hội khổng lồ. Nếu một lập trình viên thập niên 1970–80 nhìn vào, thì ngay cả phần mềm trước thời LLM cũng đã cực kỳ phức tạp, và giờ đây hầu như không ai còn viết trực tiếp lên phần cứng mà không có các tầng trừu tượng. Mật mã học cũng được dạy qua các thư viện che giấu độ phức tạp và lời khuyên “đừng tự triển khai”. Giờ câu hỏi cốt lõi là LLM có thể điều phối sự hiểu biết về hệ thống cần thay đổi nhanh đến mức nào
  • Ngôn ngữ chung của một dự án phần mềm không phải là tiếng Anh hay Python, mà là sự hiểu biết chung về ý nghĩa của các khái niệm, ranh giới, các bất biến, quyền sở hữu và lý do hệ thống trở thành hình dạng hiện tại. Pattern Language của Christopher Alexander bàn đúng về vấn đề này, và việc ông khuyến nghị tạo ra pattern language phù hợp cho từng miền đã dẫn tới GoF Design Patterns nổi tiếng
    Tôi đang thử nghiệm một tính năng cho AI duy trì ba pattern language riêng cho từng dự án: kinh doanh, sản phẩm và miền kỹ thuật, và nó hoạt động rất tốt. Khi lập kế hoạch thì tham chiếu vào đó, còn trong lúc triển khai và review thì sắp xếp lại, nên ngay cả những dự án được code 100% bằng AI cũng trở nên có hệ thống, đồng bộ tốt giữa các miền và dễ xử lý hơn

    • Tôi muốn xem ví dụ thực tế. Tôi đã nhiều lần nghe nói quá trình trưởng thành của code giống như sự phát triển tự nhiên của một thành phố, nhưng chưa từng thấy kết quả cụ thể
    • Không biết có ví dụ GitHub công khai nào không
  • Trong tháp Babel, công trình dừng lại khi mất ngôn ngữ chung, nhưng trong phát triển có AI hỗ trợ thì việc xây dựng vẫn tiếp tục ngay cả sau khi sự hiểu biết chung đã sụp đổ. Tác giả không nói rõ đó là tốt hay xấu, nhưng rõ ràng xem đây là điều xấu
    Nếu biết cà chua là trái cây là trí thông minh, còn không cho nó vào salad trái cây là sự khôn ngoan, thì AI là hình thái tối hậu của trí thông minh không có chút khôn ngoan nào, và trên thực tế gần như là ảo giác về trí thông minh. Nếu không còn ai hiểu AI đang làm gì, thì ta nên dừng lại và thừa nhận rằng mình đang thiếu sự khôn ngoan để kiểm soát thứ mình tạo ra

    • Tôi thích việc tác giả không thuyết giáo mà để chính hình ảnh tự truyền tải ý nghĩa. Lịch sử không lặp lại y hệt, nhưng nhịp điệu thì luôn tương đồng
    • Những sáo ngữ ngây ngô như “biết cà chua là trái cây là trí thông minh” tốt hơn nên tránh, trừ khi mục đích là gây hiểu lầm. Chỉ riêng việc hiểu phân loại và quan hệ phụ thuộc cũng đã là vấn đề đủ khó, còn theo tiêu chuẩn thuế ở siêu thị hay trong vụ Nix v. Hedden thì cà chua là rau
  • Tôi cũng nghĩ đến Babel và bức tranh của Bruegel, nhưng nhìn với sự bi quan hơn nhiều. Những agent nhỏ bé thiển cận đang phát triển từng phần lãnh địa của một tổng thể quá lớn đến mức không thể hiểu nổi; bên này có 50 bức tường thành, bên kia có một ngọn tháp nhô ra kỳ dị, phía trên sân trong lại là mái adobe mà chẳng rõ vì sao, và cạnh chiếu nghỉ cầu thang lại mọc lên một tòa tháp mái tranh
    Ở cấp độ thiết kế riêng lẻ thì đều có vẻ hợp lý, nhưng vì thiếu các tầng chính sách và phán đoán để hợp nhất toàn bộ dự án nên nó biến thành một con quái vật thiết kế khổng lồ. Việc tạo và duy trì ngôn ngữ chung trong một tổ chức đủ lớn đòi hỏi kỷ luật cũng thể hiện qua thuật ngữ đặc thù của các công ty thành công và quân đội. “Gastown Mayors”, bên dưới là “polecats”, rồi thấp hơn nữa là các golem đều tưởng như đang dùng cùng một ngôn ngữ, nhưng chỉ sau khi mọi thứ hoàn tất, người ngồi trên ngai mới nhận ra rằng thứ mình từng tin là đã truyền đạt hoàn hảo thực ra chưa hề được chia sẻ

  • Anakin: “Những lập trình viên dùng agent sẽ có khả năng thay đổi codebase tăng lên đáng kể”
    Padmé: “Theo hướng tốt hơn, đúng chứ?”
    Anakin: im lặng
    Padmé: “Theo hướng tốt hơn, đúng chứ?”

  • Có vẻ lý do vibe coding khuyên đừng đọc code được sinh ra là vì một khi đã nhìn thấy nỗi kinh hoàng ẩn nấp trong các file Python thì không thể nào quên được. Theo nghĩa rộng thì nó hoạt động đúng như yêu cầu, nhưng mỗi lần phải chọn cách đạt mục tiêu, nó lại đưa ra những quyết định thiếu nhất quán
    Nó chỉ áp dụng việc kiểm tra kỳ quặc với một số đầu vào người dùng, lặp lại việc sắp xếp dữ liệu hoặc chuyển thành chữ thường qua ba bước mà không có lý do, thậm chí còn hardcode toàn bộ tên cột ở hàng đầu tiên của file CSV đầu vào thành chuỗi. Một nửa thì tạo hàm toàn cục nhận dataclass, nửa còn lại lại triển khai bằng class. Nếu nghĩ rằng rồi sẽ có ngày chính mình phải cập nhật và bảo trì nó, thì rất khó không sửa lại; nhưng càng sửa như thế thì một phần đáng kể thời gian đã tiết kiệm được lại biến mất

  • Lập trình dựa trên agent gần với công việc quản lý hơn nhiều so với lập trình thực tế. Người quản lý thường chỉ nắm công việc của từng cá nhân đóng góp ở mức cao, và trong nhiều trường hợp không có đủ thời gian, năng lực nhận thức hoặc khả năng để hiểu mọi chi tiết
    Càng có nhiều phần mềm được viết bởi agent, vai trò của kỹ sư phần mềm sẽ càng trở nên gần với vị trí quản lý hơn là vị trí kỹ thuật

    • Lập trình viên cũng vậy. Phần lớn các cá nhân đóng góp không biết điều gì đang diễn ra ở các tầng bên dưới tầng mà họ làm việc, và cũng không nắm được cách triển khai nội bộ của thư viện, framework, remote API hay system call
      Vì không có đủ thời gian và dư địa để hiểu tất cả, họ chỉ thực hiện những công việc cần thiết trong tầng trừu tượng của riêng mình
    • Cảm giác như phải review code của junior developer cả ngày nên tôi hầu như không dùng, chủ yếu chỉ dùng để tìm những chỗ tôi đã bỏ sót
  • Trước đây, refactor quy mô lớn đòi hỏi rất nhiều công sức nên cần có lý do đủ thuyết phục. Giờ thì chỉ cần prompt hơi mơ hồ và không rà soát kết quả cẩn thận, agent có thể viết lại một nửa code, khiến linh hồn của chương trình có thể thay đổi mạnh mỗi ngày. Đây vừa là điều tuyệt vời, vừa hoàn toàn không phải vậy

    • Rào cản lớn nhất của refactor quy mô lớn ban đầu không phải là khối lượng công việc, mà là giảm thiểu rủi ro bug, bảo toàn chức năng và đảm bảo tương thích với hệ sinh thái hiện có. Lý do nó trở nên dễ hơn trong thời đại AI là vì chúng ta không còn để tâm đến những điều này nữa