GDD - Thời đại của "phát triển dẫn dắt bởi gaslighting"

 (tonsky.me)
12 điểm bởi GN⁺ 2025-07-21 | 6 bình luận | Chia sẻ qua WhatsApp
  • Gần đây, người dùng máy tính liên tục lặp lại vô số tác vụ vô nghĩa ngoài ý muốn của bản thân, chỉ đơn giản làm theo những gì máy tính yêu cầu
  • LLM đang ảnh hưởng đến cách các lập trình viên thiết kế API, và thậm chí đã xuất hiện dự đoán rằng các lập trình viên sẽ chấp nhận những tính năng do AI đề xuất, còn phần lớn mã sẽ sớm do AI viết
  • Ví dụ, Soundslice đã thực sự bổ sung một tính năng mà ChatGPT hướng dẫn sai là có
  • Điều này là vì LLM phân tích rất nhiều API và đề xuất một thiết kế trực quan mà lập trình viên có khả năng nghĩ đến đầu tiên
  • Khi phát triển ý tưởng mới hoặc cách tiếp cận độc đáo, LLM không phù hợp, nhưng trong đa số trường hợp, làm theo thiết kế hiển nhiên nhất có thể lại hiệu quả
  • Chúng ta hiện đã bước vào thời đại mà AI không chỉ dẫn dắt việc sử dụng công cụ mà còn cả cách thiết kế công cụ

Gaslight-driven development

Những tác vụ vô nghĩa đã trở thành thường ngày

  • Trong 10 năm qua, bất kỳ ai dùng máy tính đều đã liên tục thực hiện những việc vốn không cần thiết về bản chất như đăng ký tài khoản, xác thực email, đồng ý cookie, nhập captcha
  • Dù đó không phải điều người dùng mong muốn, họ vẫn phải làm theo những gì máy tính yêu cầu
  • Thông qua các tác vụ lặp đi lặp lại này, chúng ta đã phần nào quen với một cuộc sống làm theo những gì máy móc bảo làm

Thực tế phát triển đang bị LLM thay đổi

Ý nghĩa của hiện tượng này

  • Rất khó để kết luận liệu sự thay đổi này là tích cực hay tiêu cực
  • Mặt khác, vì LLM đã học từ vô số API nên nó có tác dụng đề xuất cách làm 'trực quan nhất' từ góc nhìn của lập trình viên
  • Đây cũng là một cách mới để kiểm thử API từ góc nhìn của người mới (newbie’s POV)
    • Trước đây, khi lập trình viên mắc lỗi, họ tự tra tài liệu rồi sửa; còn bây giờ, khi LLM liên tục đưa ra ví dụ sử dụng sai, ngay cả phía nhà phát triển cũng có thể nhận ra vấn đề nhanh hơn

Giới hạn và trăn trở

  • Cách tiếp cận này không phù hợp với công việc mang tính đổi mới
    • LLM không hiểu được các mẫu mà nó chưa quen hoặc những khái niệm hoàn toàn mới
  • Cuối cùng, trong những lĩnh vực như API, 'sự bình thường' có thể lại là tốt nhất
    • Trong đa số tình huống, thay vì thiết kế quá phức tạp, một hình thức mà cả AI lẫn lập trình viên đều có thể hiểu trực quan sẽ có lợi hơn

Kết luận: khởi đầu của một thời đại mới

  • AI giờ đây không chỉ dừng lại ở việc sử dụng công cụ được trao mà còn bắt đầu có quan điểm về việc chính công cụ đó nên được thiết kế như thế nào
  • Và những quan điểm đó đôi khi trở thành một kiểu gaslighting đối với lập trình viên và tổ chức, như thể "vốn dĩ từ đầu đã là như vậy"
  • Trong tương lai, khả năng cao phát triển phần mềm theo kỳ vọng và lẽ thường của AI sẽ trở thành một tiêu chuẩn tự nhiên

Bài viết liên quan

6 bình luận

 
ffdd270 2025-07-21

Thỉnh thoảng tôi có cảm giác vào khái niệm lớn về sự phụ thuộc vào lộ trình đang bị đóng thêm một cái đinh rất mạnh mang tên sự phụ thuộc vào LLM. Cảm giác đang chuyển từ 'vì trước giờ vẫn dùng' sang 'vì LLM thích' thì rốt cuộc sẽ đi đến đâu đây...
 
kandk 2025-07-21

Mấy thứ viết từ trước giờ thì LLM đã học rồi..
 
jujumilk3 2025-07-21

"Giờ bạn có thể tắt nguồn máy tính rồi."
 
rosen 2025-07-21

Ví von quá chuẩn!!
 
GN⁺ 2025-07-21
Ý kiến trên Hacker News
  • Trong tình huống LLM đề xuất các API endpoint không hề tồn tại, tôi đã tưởng tượng xem sẽ ra sao nếu cứ nhận lấy rồi cố tình triển khai endpoint đó, sau đó trả về mã trạng thái "421: Misdirected Request", hoặc cũng có thể dùng luôn mã '501: Not Implemented', nếu cảm thấy sắc thái của '501' chưa phù hợp thì tôi xin đề xuất một mã trạng thái mới là '513: Your Coding Assistant Is Wrong'
    Tham khảo wiki mã trạng thái HTTP
    • Ý tưởng "513: Your Coding Assistant Is Wrong" buồn cười quá, nhờ vậy mà tôi có một trận cười sảng khoái, mặt khác tôi cũng muốn đề xuất thêm 'HTTP 407 Hallucination', nghĩa là máy chủ hiểu yêu cầu nhưng đánh giá rằng nó không phù hợp với thực tế
    • Câu chuyện này với tôi cũng gợi liên tưởng đến một ví dụ biển cảnh báo thú vị nói rằng GPS đã sai
      Ví dụ GPS is wrong
    • Tôi bỏ một phiếu cho việc áp dụng mã trạng thái 513, đã có cả mã 418 rồi thì chẳng có lý do gì không thể có 513
    • Nếu muốn làm kiểu trò đùa này thì mong là hãy dùng phản hồi 418, tôi muốn nó được dùng rộng rãi hơn nữa
  • Việc nhìn thấy theo thời gian thực nhiều người dùng đang xem cùng một trang thì cũng vui, nhưng các dấu hiệu người dùng cứ liên tục ra vào khiến việc đọc bài quá khó khăn
    • Tôi có một bookmarklet trên thanh dấu trang chuyên để loại bỏ toàn bộ các phần tử cố định hoặc sticky như thế chỉ bằng một lần, dùng nó thì mọi phần tử cố định/sticky trên trang sẽ biến mất và cuộn trang cũng được khôi phục nên tôi dùng khá thường xuyên
      (cung cấp mã JavaScript)
    • Tôi cũng thấy bất tiện theo cách tương tự, nên chỉ cần nhấp phải, chọn Inspect để mở công cụ nhà phát triển rồi dán đoạn mã dưới đây vào console là vùng hiển thị người dùng đó sẽ biến mất 
      document.getElementById("presence")?.remove();
      Nếu bạn thắc mắc vì sao bộ não lại nhạy với chuyển động đó đến vậy, thì nó có liên quan đến bản năng phát hiện kẻ săn mồi
      Liên kết bài báo khoa học, Tham khảo wiki thần kinh học
    • Tôi chợt nhớ đến trò chơi Chess Royale, từng có trải nghiệm tương tự với avatar và cờ hiệu, đó thật sự là một trò được làm rất tốt nhưng Ubisoft lại đóng dịch vụ như họ vẫn thường làm, quả là một kiệt tác đáng tiếc phải nhìn nó biến mất
      Ảnh chụp màn hình Chess Royale
    • Có phải đây là trang ngày xưa có đầy con trỏ chuột ở nền không nhỉ, đến mức tôi nghĩ đây là một concept thiết kế kiểu đùa cợt, cố tình gây xao nhãng
    • Tôi đã thử dùng công cụ như uBlock để gỡ các phần tử trên trang, nhưng rồi lại rơi vào tình huống lặp đi lặp lại rất nhanh như trò đập chuột chũi
  • Ở Instant, hàm tx.update được thiết kế để phụ trách cả chèn và cập nhật entity, nhưng LLM cứ liên tục viết mã tx.create, nên cuối cùng tôi cũng đã tạo luôn hàm tx.create, tôi tự hỏi liệu ở những điểm gây nhầm lẫn kiểu này không chỉ LLM mà cả lập trình viên thực tế cũng đã lãng phí quá nhiều thời gian một cách vô ích hay chưa
    • Dù sao nếu tx.create vốn dĩ không tồn tại thì chẳng phải sẽ không có ai phải lãng phí thời gian vì nó sao
  • Nếu là một hàm hỗ trợ cả chèn lẫn cập nhật thì tôi nghĩ nên đặt tên là "put" thay vì "update", vì "update" có thể gây hiểu nhầm
    • Trong trường hợp đó có vẻ "upsert" mới là đúng
    • Tên "put" hàm ý ghi đè nội dung hiện có, còn "upsert" thì mang nghĩa vừa chèn vừa cập nhật
  • Chỉ vì LLM in ra một đoạn văn bản sai mà tôi cảm giác như vũ trụ sẽ rơi vào cái chết nhiệt trước khi tôi kịp sửa một dòng mã, việc phải thay đổi mã vì một lý do vô lý như thế đối với tôi vừa khôi hài vừa khó chấp nhận
  • Tôi không đồng ý với lập luận của bài viết, ngay từ cách tiếp cận kiểu thật sự chúng ta phải làm theo điều máy tính muốn hay sao đã thấy đáng nghi rồi
    Tôi cũng nghĩ rằng việc người dùng xác thực email hay đăng ký tài khoản là kết quả của lựa chọn thiết kế do con người đưa ra, chứ không phải vì máy tính bảo thế
    • Tôi cho rằng gọi nội dung đó là một "thesis" (luận điểm) đã là một cách diễn giải quá rộng lượng, tôi đọc tới đó là đóng trang luôn
  • Gần đây tôi đã có một cuộc trò chuyện thú vị với cả nhóm về các nguyên tắc lập trình của tương lai
    Sau này có lẽ điều quan trọng sẽ không còn là độ dễ đọc của mã, nguyên tắc SOLID hay độ phức tạp nữa, mà là agentic IDE tôi dùng có thể lập chỉ mục ngữ cảnh mã tốt đến mức nào, và mô hình có thể tạo sinh tốt ra sao từ phần mã đó
    Khi tốc độ thay đổi mã tăng lên rất nhiều, khả năng bảo trì của mã lại càng trở thành chỉ số cốt lõi, và tôi dự đoán sẽ có một thế giới nơi mức độ khớp giữa prompt và mã, hay tính hữu dụng của những đoạn mã vô tình ăn khớp tốt, sẽ được chú ý nhiều hơn
  • Nếu có ai đó liên tục tự tin phát tán những lời khuyên phát triển mới mẻ nhưng thực ra là sai về sản phẩm tôi làm, thì từ góc nhìn doanh nghiệp tôi tự hỏi liệu họ sẽ chỉ thêm luôn những tính năng tưởng tượng đó rồi viết một bài blog ngơ ngác về chuyện này hay không
    • Tôi tự hỏi nếu bản thân cũng hành xử như LLM, phạm những sai lầm ngớ ngẩn nhưng vẫn khăng khăng đầy tự tin, thì người khác có đơn giản là sẽ thông cảm cho tôi không
    • Thật ra tôi lại nghĩ đến việc tác giả “Clean Code”, ông Martin, chẳng phải cũng theo phong cách này sao
    • Nếu người đó có ảnh hưởng tới 90% khách hàng của tôi thì có lẽ tôi thật sự sẽ đưa vào tính năng tưởng tượng đó
    • Phần lớn doanh nghiệp có lẽ sẽ tự tin khẳng định rằng tính năng không cần thiết đó là thứ bắt buộc phải có
  • Điều này cũng có cảm giác như điểm khởi đầu của một tình bạn đẹp với LLM, điều làm tôi bực nhất khi làm fractional CTO là ở mỗi khách hàng, ngay cả những quy ước đặt tên nhỏ nhặt như tên môi trường cũng đều khác nhau cả
    Ví dụ trong AWS thì có “dev” và “prod”, còn trong Expo lại là “test” và “production”, nên khi chuyển qua lại giữa nhiều dự án, tôi phải tốn khá nhiều công sức suy nghĩ hơn tưởng tượng
    Tôi nghĩ LLM chắc cũng phải gặp vấn đề này ở quy mô lớn hơn nhiều
    Nếu có thể dành những synapse trong não vốn bị tiêu tốn cho sự hỗn loạn không cần thiết trong cách đặt tên/hành vi của API vào những thứ thực sự có ý nghĩa hơn, thì đó sẽ là điều tốt nhất
    • Có một câu đùa trong khoa học máy tính rằng có ba bài toán khó—vô hiệu hóa cache, đặt tên, và lỗi off-by-one
      Dù LLM có đặt tên thông minh đến đâu thì vấn đề vẫn còn nguyên, vì nó dựa trên một incoherent stochastic process (quá trình xác suất thiếu nhất quán)
      Và tôi cũng muốn hỏi liệu bạn đã từng nghiêm túc đặt câu hỏi vì sao việc đặt tên môi trường lại không được thống nhất hay chưa
      Với tư cách là một cựu CTO, tôi cho rằng những điều như vậy là tín hiệu cho thấy cần cải thiện giao tiếp trong tổ chức, hoặc còn thiếu chuẩn mực
      Vì đây là những chỗ có thể sửa khá dễ để thực sự cải thiện văn hóa và nâng cao nhận thức của thành viên, nên tôi muốn nói rằng thay vì giao cho LLM xử lý, ta nên trực tiếp quan tâm hơn đến chúng
  • Liên kết liên quan
    Xem thảo luận Hacker News trước đó
 
dkmin 2025-07-21

Thành công lan truyền của Soundslice