2 điểm bởi GN⁺ 4 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Lập trình bằng LLM vừa nâng cao năng suất, vừa làm tăng mệt mỏi giám sát, khi nhà phát triển phải liên tục kiểm soát ý định và chất lượng, làm lung lay cảm giác thỏa mãn và tính bền vững
  • Mô hình có thể nhanh chóng tạo ra mã trông hợp lý, nhưng có thể bỏ lỡ ý định nhất quán trong các thay đổi phức tạp, khiến con người trở thành cổng kiểm soát chất lượng phải rà soát và sửa chữa lượng đầu ra tăng lên
  • Số việc có thể bắt đầu tăng vọt, nhưng lượng việc có thể hoàn tất một cách cẩn trọng vẫn bị ràng buộc bởi bộ não và sự chú ý của con người; những phần thưởng nhỏ của việc lập trình giảm đi, còn gánh nặng nhận thức của việc rà soát tăng lên
  • Ở những lĩnh vực hiểu sâu, ta có thể hướng dẫn LLM hiệu quả, nhưng ở lĩnh vực chuyên môn còn nông, mô hình dễ nghiêng về vẻ hợp lý hơn là độ chính xác, khiến gu thẩm mỹ và phán đoán kiến trúc trở nên quan trọng hơn
  • Kỹ nghệ phần mềm không biến mất mà sẽ thu hẹp và tái cấu trúc; tài nguyên khan hiếm không phải là việc viết mã, mà là sự chú ý của con người, phán đoán kỹ thuật và khả năng duy trì một tầm nhìn nhất quán cho hệ thống

Lập trình bằng LLM: hữu ích nhưng bất ổn

  • Lập trình bằng LLM thực sự hữu ích nhưng cũng bất ổn, và nếu phớt lờ sự bất ổn đó, nhà phát triển có thể rơi vào kiệt sức
  • Đội ngũ Pydantic cũng đang trải qua cùng sự hỗn loạn khi xây dựng các công cụ xác thực dữ liệu, tạo AI agent và quan sát hệ thống production
  • Trọng tâm không phải là AI có thay thế lập trình viên hay không, mà là trải nghiệm phát triển hiện tại đã thay đổi như thế nào và có thể cải thiện nó bằng gì

Cảm giác tự tay làm ra

  • Lập trình từng mang lại cảm giác sáng tạo: tạo ra thứ gì đó chỉ bằng logic và trực tiếp xử lý các tầng trừu tượng sâu
  • Với trải nghiệm học kỹ nghệ phần mềm bằng thử-sai thay vì giáo dục khoa học máy tính chính quy, các nguyên tắc về kiến trúc và chất lượng mã giống những vết sẹo tích lũy hơn là các quy tắc trong sách giáo khoa
  • Các công cụ low-code/no-code thập niên 2010 và sản phẩm như Dreamweaver cũng từng hứa hẹn tạo ra thứ gì đó mà không cần mã, nhưng lại sinh ra spaghetti code bên trong và không hoàn toàn đáp ứng kỳ vọng
  • Các công cụ AI hiện nay, khác với trước đây, đã thu hẹp khoảng cách giữa lời hứa và thực tế đến mức có ý nghĩa, và chính điều đó khiến chúng đem lại cảm giác bất an hơn

Trải nghiệm thực tế khi “mã tự viết ra”

  • Mã đúng là có thể tự viết ở một mức độ nào đó, nhưng trải nghiệm của con người khi rà soát, chỉ đạo và chỉnh hướng nó lại có thể tệ hơn
  • Douwe, maintainer của Pydantic AI, mỗi sáng phải rà soát khoảng 30 PR do AI của người khác tạo ra qua đêm và phải phán đoán ngay từng PR
    • Cám dỗ giao cả phần rà soát cho AI là rất lớn, nhưng nếu làm vậy thì vẫn còn câu hỏi con người đang làm gì
  • Ngay cả khi dành gần hai ngày để viết và lặp lại việc làm rõ kế hoạch cho LLM thực hiện, mô hình vẫn có thể chuyển React hook sang file story của Storybook hoặc đọc sai kế hoạch rồi tạo ra component không tồn tại
  • Những thất bại này gần với thiếu tính nhất quán hơn là đơn thuần thiếu năng lực
    • Mô hình đủ thông minh để tạo ra mã trông hợp lý, nhưng có thể không duy trì được một ý định xuyên suốt toàn bộ thay đổi phức tạp
  • Con người phải giữ ý định trong đầu và liên tục phán đoán một lượng lớn kết quả “phần lớn là đúng”, từ đó sinh ra một dạng mệt mỏi giám sát mới
  • Trong mã nguồn mở, phần thưởng khi xây dựng tính năng cùng người thật và giúp họ nâng cao năng lực cũng giảm đi
    • Khi công việc đi vào hộp đen của AI, không có ai ở phía bên kia đang học hỏi, nên sự thỏa mãn của hợp tác biến mất

Cái bẫy làm tăng cường độ công việc

  • Nghiên cứu Berkeley Haas do Simon Willison giới thiệu cho rằng việc dùng AI không làm giảm khối lượng công việc mà làm tăng cường độ công việc
    • Cuối ngày vẫn tiếp diễn áp lực nhập thêm một prompt nữa hoặc hoàn thành thêm một tính năng nữa
    • Cảm giác kế hoạch đã gần xong cũng có thể dẫn đến cảnh vẫn nhập prompt đến gần 2 giờ sáng
  • Marcelo của Pydantic đùa rằng nếu một phiên Claude Code bị dừng thì hãy mở 5 phiên
    • Ý là nếu bạn bận phản hồi các phiên khác, bạn thậm chí sẽ không nhận ra một phiên đã dừng
  • Làm việc song song giúp số việc có thể bắt đầu tăng mạnh, nhưng số việc có thể hoàn tất cẩn trọng thì không đổi
    • Việc hoàn tất cần một tài nguyên không thể song song hóa: bộ não con người

Hàm phần thưởng của con người bị hỏng

  • Cũng như hàm phần thưởng trong machine learning định nghĩa kết quả tốt cho agent, việc lập trình thủ công cũng từng có những phần thưởng nhỏ như giải quyết vấn đề, hiểu logic phức tạp, biên dịch thành công và cảm giác kiểm soát
  • Lập trình có LLM hỗ trợ tự động hóa những công việc từng tạo ra phần thưởng dopamine đó, rồi thay thế chúng bằng gánh nặng nhận thức của việc rà soát và giám sát
    • Phần thỏa mãn giảm đi
    • Phần tiêu hao tăng lên
    • Chưa có phần thưởng mới để lấp chỗ trống
  • Hiện tượng năng suất tăng trong khi cảm giác thỏa mãn giảm không phải là khiếm khuyết cá nhân, mà là sự hỏng hóc của vòng phản hồi, và cần được xử lý như một vấn đề kỹ thuật riêng

Cô lập và phần thưởng biến thiên

  • Lập trình bằng LLM có thể trở thành một hoạt động rất cô độc, trong đó con người và máy lặp đi lặp lại việc prompt, sửa đổi và rà soát
  • Những khoảnh khắc hỏi đồng nghiệp, cùng diễn đạt vấn đề thành lời và chia sẻ niềm vui nhỏ khi giải được bài toán bị thay thế bằng một prompt nữa
  • Ở những đội vốn có văn hóa cộng tác yếu, giao tiếp giữa con người còn bị thu hẹp hơn, và khó xác nhận rằng người khác cũng đang gặp khó khăn
  • Việc kết quả lúc thì tuyệt vời, lúc thì rác, nhưng không thể biết trước, tạo ra cấu trúc phần thưởng biến thiên giống Skinner Box
  • Khi cần vẫn có thể tự viết mã, nhưng làm việc với LLM hỗ trợ và làm thủ công có cách tư duy rất khác nhau nên việc chuyển đổi không thoải mái
    • Cần sự trưởng thành và tự tin để tự cho phép mình qua lại giữa hai cách làm

Điểm tương đồng với quá trình chuyển sang thiết kế responsive

  • Khoảng năm 2009, khi web chuyển từ bố cục chiều rộng cố định theo pixel sang thiết kế responsive linh hoạt, các designer cũng trải nghiệm cảm giác mất kiểm soát
  • Với những người xây dựng bản sắc và chuyên môn trên bố cục chính xác và lưới hoàn hảo, khái niệm thiết kế chảy theo chiều rộng màn hình và thiết bị tùy ý là một thay đổi căn bản
  • Những designer thích nghi được với chuyển đổi này không vứt bỏ kỹ năng cũ mà tái cấu trúc chúng
    • Cảm giác về tỷ lệ và hiểu biết về phân cấp vẫn quan trọng
    • Sự ám ảnh với kiểm soát theo từng pixel trở nên ít quan trọng hơn
    • Thiết kế cho hệ thống, khả năng thích nghi và bất định trở nên quan trọng hơn
  • Chuyển đổi AI hiện nay nhanh hơn nhiều so với thiết kế responsive, và các bên liên quan cũng khác
    • Thay đổi của thiết kế responsive diễn ra trong nhiều năm, còn thay đổi hiện tại diễn ra theo đơn vị tháng
    • Khi đó agency cũng mất khách hàng và designer cũng mất việc, nhưng không đi kèm nỗi bất an hiện sinh như hiện nay
  • Dù vậy, khuôn mẫu rằng kỹ năng tiến hóa thay vì biến mất, và năng lực cốt lõi trở nên quan trọng hơn, cũng áp dụng cho lập trình dựa trên LLM
  • Việc không tự tay viết mọi dòng mã không làm giảm giá trị của kỹ sư, nhưng vì họ đã trở thành cổng kiểm soát chất lượng cho lượng đầu ra lớn hơn nhiều, năng lực phân biệt kết quả tốt lại càng cần thiết

Chuyên môn sống sót và cách làm việc mới

  • Trong môi trường ai cũng có thể tạo UI trông hợp lý và mã biên dịch được, gu và sắc thái, phán đoán kiến trúc chín chắn, cùng các quyết định khác số đông dựa trên chuyên môn thực sự sẽ trở thành điểm khác biệt
  • Càng hiểu sâu về mã, quyết định và trade-off trong một lĩnh vực, càng có thể hướng dẫn LLM thành công
  • Càng đi vào các lĩnh vực chuyên môn nông, kết quả càng xa mức sẵn sàng cho production và gần với trạng thái trông ấn tượng, hợp lý hơn là thực sự đúng
    • Mô hình không biết điều nó không biết và tự tin lấp chỗ trống; đây cũng là một kiểu thất bại xuất hiện ở con người
  • Với các kế hoạch phức tạp, có thể dùng pre-mortem
    • Yêu cầu một phiên LLM mới giả định kế hoạch đã thất bại thảm hại rồi chẩn đoán nguyên nhân
    • Việc này giúp tìm ra khoảng trống trong đặc tả mà người đã nhìn vào chi tiết suốt hai ngày có thể bỏ sót
  • Một kỹ sư của Pydantic đã phát triển công cụ trích xuất quy tắc từ hàng nghìn bình luận code review trước đây để tạo thành hướng dẫn ban đầu trong file AGENTS.md
    • Đây là sự chưng cất chuyên môn: biến phán đoán kỹ thuật đã tích lũy ngầm qua nhiều năm thành hướng dẫn mà LLM có thể tuân theo
  • Những người thích nghi với thay đổi có tiêu chuẩn phán đoán mạnh mẽ rút ra từ thực tế, và phân biệt được các nguyên tắc vẫn còn hiệu lực với những thói quen sinh ra từ các ràng buộc băng thông trong quá khứ
  • Họ sẵn sàng thay đổi quy trình làm việc mà không từ bỏ tiêu chuẩn

Tài nguyên khan hiếm lộ diện trong vòng lặp

  • Làn sóng AI hiện tại sẽ không kết thúc nghề kỹ nghệ phần mềm, nhưng có thể dẫn đến sự thu hẹp nghiêm trọng và tái cấu trúc căn bản của ngành
  • Nỗi sợ bị đào thải, suy giảm năng lực và tụt lại nếu không di chuyển đủ nhanh là chính đáng
    • Mối lo cuối cùng đôi khi bị phóng đại, nhưng không hoàn toàn vô căn cứ
  • Nút thắt thực sự không phải là mã, mà là sự chú ý của con người, phán đoán kỹ thuật và khả năng duy trì một tầm nhìn nhất quán về hệ thống
  • Vì việc viết mã từng có vẻ là phần khó, trước đây nút thắt này không lộ rõ; khi quá trình viết được tự động hóa, việc năng lực con người mới là tài nguyên khan hiếm trở nên rõ ràng
  • Nhà phát triển có thể vừa năng suất hơn, vừa kém hạnh phúc và bất ổn hơn; các đội làm công cụ cũng đang gặp cùng vấn đề và điều chỉnh hàm phần thưởng theo thời gian thực
  • Mã và cách phát triển đang thay đổi, nhưng con người vẫn ở trong vòng lặp, và trạng thái cốt lõi hiện nay là sự mệt mỏi của người tham gia là con người

1 bình luận

 
Các ý kiến trên Hacker News
  • Với việc code thủ công, vấn đề càng khó thì những phần thưởng nhỏ như giải quyết được vấn đề, hiểu logic, biên dịch thành công, cảm giác kiểm soát càng lớn. Ngược lại, coding bằng agent liên tục đòi hỏi mức giám sát tương tự bất kể quy mô tính năng, nên ban đầu có cảm giác phấn khích như đang cưỡi làn sóng năng suất, nhưng phần đem lại thỏa mãn giảm dần còn tải nhận thức khi review tăng lên, khiến người ta nhanh chóng kiệt sức

    • Tôi sợ rằng hơn cả mất việc, chẳng mấy chốc mình sẽ ghét chính công việc. Những việc mà dù chỉ thị cho LLM cũng không tiết kiệm được bao nhiêu thời gian thì tôi tự làm, rồi chỉnh lại cấu trúc đầu ra cho dễ hiểu với con người để duy trì cảm giác kiểm soát
    • Động lực của tôi không nằm ở việc code được tạo ra như thế nào, mà ở việc sản phẩm đã tạo có được nhiều người dùng thấy hữu ích hay không. Tôi luôn nghĩ đến người dùng trước và chọn đường tắt khi cần; ngay cả khi dùng LLM, vẫn có thể cân bằng giữa code có thể bảo trì và tốc độ phát hành
    • Phát triển phần mềm có thể chuyển từ một nghề dựa trên tri thức thành thứ giống lao động nhà máy lương thấp. Kiến thức và kinh nghiệm cần để hướng dẫn LLM ít hơn nhiều so với khi tự viết, và trên LinkedIn, ngay cả những người hầu như không có kinh nghiệm hoặc chỉ ở mức junior cũng đang được tuyển làm kỹ sư AI
    • Tôi cảm thấy dopamine khi tạo một vòng lặp để AI tự kiểm thử đầu ra của nó. Những kiểu tự động hóa Rube Goldberg càng rườm rà, như để Codex điều khiển từ xa bằng cách nối cả dongle bàn phím mạng-USB-C, Fingerbot và webcam nhằm làm chế độ ngủ đông hoạt động trên một laptop cụ thể và kernel Linux, thì càng khiến tôi thỏa mãn
    • Trong các dự án cá nhân, việc tạo tính năng trở nên dễ hơn mà kết quả lại tinh tế và nhất quán, nên cảm giác hài lòng thậm chí tăng lên. Nếu tập trung một tháng vào một dự án, có thể đạt kết quả khá tốt; chi phí viết lại và dọn cấu trúc rẻ hơn nên thực sự có thể khám phá không gian thiết kế rộng hơn nhiều. Tuy vậy vẫn có nhiều lúc bực bội, một nửa là do vấn đề cung cấp ngữ cảnh của tôi, một nửa là giới hạn cố hữu của mô hình
  • Tôi đang dùng Claude một cách vui vẻ cho công việc và dự án cá nhân; điểm mấu chốt là tránh cám dỗ của agent và đối xử với nó như một bộ sinh code. Chỉ mở một session, trau chuốt kế hoạch cho đủ kỹ rồi theo dõi việc thực hiện theo từng bước; sau mỗi bước thì review và điều chỉnh hướng đi, như vậy đến cuối vẫn nắm rõ trạng thái code
    Nếu muốn dùng gần kiểu one-shot, ở giai đoạn lập kế hoạch cần cụ thể hóa không chỉ kiến trúc mà cả phần code thực tế sẽ chi phối các quyết định chính. Vì chi phí refactor đang thấp hơn bao giờ hết, chỗ nào khó hiểu thì lập tức sửa cùng LLM, nhưng phải để mỗi lần chỉ một LLM làm một việc và bản thân vẫn liên tục tham gia vào quá trình

    • Sau vài tháng làm việc với Claude, tôi đã học được luồng làm việc: thảo luận đủ chi tiết ngay từ đầu, nếu cần thì dựng cả khung sườn rồi mới cho chạy; tôi đã tổng hợp tại https://github.com/ctomkow/claude/blob/main/README.md. Tôi đang refactor thành công phần code legacy từng trì hoãn lâu nay sang kiến trúc mới
      Nếu trao toàn quyền cho Claude, sự hỗn loạn và các vướng mắc tất yếu phát sinh sẽ bào mòn con người. Khi muốn thì tự code, khi mệt thì giao cho Claude, như vậy vẫn giữ được cảm giác kiểm soát codebase
    • Tôi chỉ dán những đoạn code cần thiết vào một cuộc trò chuyện tách hoàn toàn khỏi editor, thảo luận các ràng buộc và ý tưởng; nếu thấy ổn thì chuyển sang editor để tinh chỉnh thêm tên gọi và triển khai. Những việc rõ ràng hoặc thú vị thì tự làm, và cũng phải tham gia vào quyết định kiến trúc thì mới cảm thấy gắn kết với dự án và hiểu sâu được
    • Vibe coding, dù dùng nhiều vòng lặp agent, vẫn dễ gây kiệt sức hơn cách dùng như công cụ hỗ trợ khi ta theo dõi sát đầu ra
    • Dù làm việc theo từng bước, khi người khác review thì họ vẫn phải nhìn toàn bộ kết quả cùng lúc bằng con mắt lần đầu thấy, nên gánh nặng review không giảm
    • Quy trình làm việc có thể qua lại tối đa giữa hai luồng, nhưng nhiều hơn thế thì đầu óc hoàn toàn kiệt vì chuyển đổi ngữ cảnh
  • Khi review code của đồng nghiệp hoặc cấp dưới, tôi phải dùng phần lớn tinh lực để cân nhắc không chỉ tính đúng đắn kỹ thuật của phản hồi, mà cả tự ái, khác biệt góc nhìn kiến trúc, giọng điệu lịch sự, khối lượng việc phát sinh và động lực trong đội. Ngược lại, với LLM thì không cần bận tâm đến tác động cảm xúc, nên việc review và chỉnh hướng dễ hơn nhiều

    • Nếu biết đồng nghiệp sẽ lại đưa feedback của tôi cho AI, tôi sẽ viết cho AI đọc hơn là cho người, và sẽ truyền đạt danh sách chỉnh sửa ngắn gọn, thẳng thắn hơn nhiều
    • Là tech lead, tôi đã gặp phản ứng kiểu “thế này là đủ rồi” ở từng PR; với LLM thì có thể thoải mái yêu cầu làm lại theo đúng cách mà không bị phản kháng
  • Ở nơi làm việc, chúng tôi bắt đầu gọi thay cho human in the loop là Human on the hook. Cách gọi này diễn tả chính xác hơn cấu trúc trong đó nếu mọi việc suôn sẻ thì con người không được ghi công, nhưng nếu sai thì trở thành bên chịu trách nhiệm, tức con người chỉ quan trọng khi có vấn đề xảy ra

  • Bản thân việc viết code chưa bao giờ là phần khó với tôi. Nhờ gõ nhanh, chỉnh sửa modal trong Vim, lệnh Unix, script và phím tắt, Git, refactor trong IDE, Java, nên khi biết mình cần tạo gì, tôi làm việc với tốc độ của suy nghĩ
    Những lúc tôi khựng lại không phải vì gõ phím hay cú pháp, mà vì phải nghĩ về hình dạng của code và thay đổi đúng đắn; khi việc trở nên khó, tôi tạo abstraction tốt hơn, công cụ IDE, hoặc pipeline Unix gồm cả sed. Vì vậy nút thắt không phải là viết code mà là suy nghĩ và phán đoán
    Lý do AI coding có cảm giác như một bước nhảy vọt lớn có thể là vì số lập trình viên chưa từng tiếp cận hoặc chưa thành thạo các công cụ tốt nhiều hơn tưởng tượng. Nếu bây giờ tôi ở tuổi 20, có lẽ tôi đã dành ít thời gian hơn để học các kỹ năng này, nhưng khoảnh khắc khiến kỹ nghệ phần mềm hấp dẫn với tôi là khi tôi hiểu rằng không có thứ nào trong đó là ma thuật

    • Cách nói “AI có vẻ giỏi những việc mà bản thân bạn không giỏi” rất đúng. Nếu chưa thạo lập trình, đầu ra của AI trông nhanh và xuất sắc; nhưng với lập trình viên lành nghề, cộng cả việc chỉ thị, chờ đợi, thuyết phục, sửa lỗi và refactor thì có thể không nhanh hơn tự làm
      Giống như tôi vẽ kém nên tranh AI trông thật ấn tượng, việc đánh giá AI programming cũng có thể theo cùng nguyên lý
  • Sự mệt mỏi mà nhiều người cảm thấy bắt nguồn từ mất kiểm soát, khi lực đẩy nhanh hơn kết hợp với hỗn loạn lớn hơn. LLM nằm đâu đó giữa thiên tài và trẻ nhỏ, nên ngồi ghế sau quan sát vừa phấn khích vừa đáng sợ
    Sau một thời gian lao đi thật nhanh, có lẽ ta sẽ nhận ra rằng đi bộ cũng không tệ, và thậm chí còn có khả năng cao hơn để đến đúng nơi mình muốn

  • Lập trình bằng LLM có cảm giác như đang làm nghi thức kéo cần máy đánh bạc, lặp đi lặp lại và hy vọng lần này sẽ được. Lỗi trong lập trình thông thường có nguyên nhân nhất quán, và được thiết kế để ta hiểu nguyên nhân đó rồi loại bỏ vĩnh viễn nếu có thể. Một lập trình viên lành nghề không thử ngẫu nhiên rồi khi thành công lại xem đó là chuyện không biết vì sao
    Nếu bạn đã kiệt sức vì phải đối phó với nhiều bên liên quan thậm chí không thống nhất được hệ thống là gì, có lẽ bạn đã sớm biết rằng sự chú ý của con người và phán đoán kỹ thuật vốn là điểm nghẽn

    • Khi mới học lập trình và làm web app, tôi từng ngồi lì trước máy tính đến khuya, đoán mò và chạy thử kiểu “thử cái này có được không?”. Khi kỹ năng tăng lên và tôi dùng ngôn ngữ có kiểu, compiler, LSP, tôi hiểu được thứ gì sẽ hoạt động, và có thể bước vào trạng thái flow thỏa mãn thay vì sự đoán mò gây nghiện
      Lập trình với Claude cho tôi cảm giác quay lại giai đoạn đoán mò đó nên tôi không muốn. Tuy vậy, trong những mảng vốn có nhiều phỏng đoán mù mờ như các công việc kiểu DevOps, nơi phải nối API phức tạp với nhiều thành phần, hội thoại với LLM lại hữu ích nhất
    • Giờ đây, thay vì đạt đồng thuận, các bên liên quan dùng LLM để tạo ra kế hoạch và mục tiêu theo quý còn non nớt, rồi giao cả thiết kế, story, chi tiết kỹ thuật, triển khai và review code cho LLM. Trong toàn bộ quá trình, tư duy phản biện và kiểm chứng biến mất, chỉ còn tài liệu thiết kế và code với mục đích mơ hồ chất đống, đến mức theo dõi thôi cũng khó
      Kế hoạch có thể thay đổi bất cứ lúc nào và khả năng mọi thứ bị viết lại bốc đồng từ đầu cũng lớn hơn
  • Tôi đồng cảm với cốt lõi của bài viết, nhưng ở nhiều chỗ vẫn lộ văn phong đặc trưng của Claude, khiến việc đọc một bài do ai đó viết bằng AI càng mệt hơn

    • Có khả năng không phải AI trực tiếp viết, mà đã qua biên tập và rà soát để khớp với văn phong doanh nghiệp. Bản thân LLM cũng được huấn luyện trên kiểu văn phong này
    • Phần lớn là do AI viết, nhưng có sự can thiệp của con người nhiều hơn hẳn so với bài AI thông thường nên không gây khó chịu như mọi khi
    • Nhìn vào dấu vết văn phong như lặp lại “It’s not” và dùng dấu gạch ngang, tôi cho rằng đây là bài viết do AI tạo
    • Nếu họ không bỏ công tự viết, tôi cũng không muốn bỏ công đọc
  • Làm tôi nhớ đến bài viết năm 2021 The Animal is Tired: https://www.robinhobb.com/blog/archives/2021-05

    • Trang gốc chặn IP nên có thể xem ở mirror ít hạn chế hơn https://archive.is/RWxXP. Cảm nhận sự suy tàn của chính mình có thể là nỗi buồn lớn nhất, và ai rồi cũng gặp
      Dù có giữ gìn cơ thể hơn, cuối cùng ta vẫn có thể đến cùng vị trí đó mà lại bỏ lỡ những ký ức quý giá. Hãy chăm sóc cơ thể, nhưng đừng đối xử với nó như lọ thuốc trong game mà bạn không bao giờ dùng đến cuối vì sợ sẽ cần cho trận chiến tiếp theo. Mỗi phần cơ thể của chúng ta chỉ có thể hy sinh một lần cho mục đích lớn hơn, hoặc không hy sinh gì cả
      Chỉ nghĩ đến những điều này thôi cũng đủ làm tôi khóc, nên rõ ràng tôi vẫn đang ở trong một cơn khủng hoảng cảm xúc
  • Thông cáo nghiên cứu của Berkeley Haas về việc sử dụng AI làm tăng cường độ công việc khá ấn tượng, nhưng đã hơn 5 tháng kể từ khi bài HBR https://hbr.org/2026/02/ai-doesnt-reduce-work-it-intensifies... và tài liệu truyền thông https://newsroom.haas.berkeley.edu/ai-promised-to-free-up-wo... được đăng mà vẫn không tìm thấy bài báo khoa học thực sự hay bản preprint nào
    Những gì hiện được biết chỉ là khoảng 40 cuộc phỏng vấn định tính tại một công ty trong một ngành duy nhất, nên khó đánh giá độ tin cậy của kết quả nếu không kiểm tra phương pháp nghiên cứu