Thật ra nếu LLM gợi ý một dự án mã nguồn mở cụ thể thì tôi còn nghĩ chắc thử dùng xem sao,
nhưng nếu nó gợi ý chính các sản phẩm để mua sắm thì lại khiến tôi càng muốn lờ đi hơn, vì không biết có thật sự đáng tin hay không.
Không biết rồi một ngày nào đó chuyện này cũng sẽ thay đổi nhỉ.

Mong mọi người hãy dành nhiều tình cảm cho RollerCoaster Tycoon.

Đường cong học tập cực kỳ dốc. Đổi lại việc đảm bảo tính tái lập thì nó đòi hỏi trình độ cao.
Dùng flake rồi mà vẫn khá kén người dùng.

Ngoài ra có vẻ bên trong nó dùng sqlite, mà cái này thì hiệu năng lại lên xuống thất thường, nên thời gian cần để tái tạo lại môi trường một lần cũng dao động khá nhiều.

Thế nào là một người lãnh đạo, quản lý, hay thành viên nhóm tốt? Đôi khi, một người là quản lý đồng thời cũng là thành viên nhóm của ai đó nên...

Nhờ được chuẩn hóa bằng Electron nên vậy...

Dự án mới ra mỗi ngày, chỉ cần có vài ảnh chụp màn hình thôi là tôi cũng dễ bị hấp dẫn và muốn dùng thử ngay.

Đúng là ở đâu thì cách con người sống và cư xử cũng giống nhau cả. :)

Vì Linux không chạy được 😭

Ừ thì~ chỉ riêng việc viết ra để tạo nên cuộc tranh luận như thế này thôi cũng đã đủ thể hiện ý đồ rồi mà

IDE, PR đều chết cả rồi mà code lại hồi sinh à?

Để bao hàm góc nhìn về nghịch lý Jevons, trước hết cần xác định đâu là tài nguyên.
Vì đây là bài viết phân tích triển vọng nhu cầu lập trình viên, nên tài nguyên trong bài này hẳn phải là lập trình viên.

• Ngành mà nghịch lý Jevons vốn dùng để giải thích (động cơ hơi nước <-> than đá) và ngành phần mềm có rất nhiều điểm khác nhau.
  • Hàng hóa số là hàng hóa không cạnh tranh và là ngành có chi phí cận biên gần như bằng 0. Tức là một ngành xoay quanh chi phí cố định.
  • Trong các ngành như vậy, việc tăng năng suất thường diễn ra theo hướng cắt giảm hoặc đóng băng nhân sự, đồng thời tăng đòn bẩy cho lực lượng hiện có.
• Để nghịch lý Jevons成立, nhu cầu phải cực kỳ nhạy cảm với giá, và việc giảm chi phí phải trực tiếp dẫn tới bùng nổ nhu cầu.
  • Phát triển phần mềm không phải là việc một lập trình viên làm một mình. Điểm nghẽn không nằm ở "chi phí viết code" mà ở chi phí lập kế hoạch, rủi ro, vận hành, tổ chức và tuân thủ quy định.
  • Từ trước đến nay, đa phần không phải vì chi phí phần mềm quá đắt nên không làm được, mà là vì “không cần thiết / ROI không đạt / không thể vận hành” nên không làm.
• Có ảo giác trong các chỉ số năng suất.
  • Các chỉ số được dùng trong bài (tăng lượng mã được tạo, tăng PR, tăng số lần triển khai) đều là chỉ số “mức độ hoạt động”.
  • Lượng code tăng không đồng nghĩa giá trị tăng. PR tăng kéo theo chi phí review/xác minh tăng, và code do AI tạo ra làm tăng rủi ro về chất lượng/bảo mật.
  • Tức là, code AI sẽ làm tăng nợ kỹ thuật, chi phí debug và độ phức tạp trong vận hành.
  • Do đó, mức tăng năng suất có thể sẽ không tăng mạnh một cách kịch tính như các chỉ số hoạt động.
• Vừa thừa nhận “vách đá junior” vừa giữ thái độ lạc quan là mâu thuẫn.
  • Khác với than đá, lập trình viên là một cấu trúc phát triển từ junior lên senior.
  • Nếu số lượng junior giảm, thì số lượng senior trong tương lai cũng giảm. Vì vậy, về trung và dài hạn, toàn bộ pool lập trình viên sẽ thu hẹp lại.
• Tăng trưởng quy mô thị trường và tăng trưởng việc làm không phải là một.
  • Đặc biệt, AI là ngành thâm dụng vốn, không phải “ngành dùng thêm nhiều người” mà là “ngành tạo ra quy mô lớn hơn với ít nhân lực hơn”.
• Lập trình viên là con người, và tiền lương của con người có những đặc điểm khác với giá than đá.
  • Trong thị trường lao động, tiền lương không thể giảm hoàn toàn linh hoạt, nên việc giảm chi phí không truyền đủ sang giảm giá.
  • Tiền lương thực tế có tính cứng nhắc theo chiều giảm. Điều này là do mức lương tối thiểu, luật lao động, cấu trúc hợp đồng, sự công bằng nội bộ trong tổ chức, tinh thần làm việc/rủi ro nghỉ việc, v.v.
  • Tức là, khi năng suất tăng lên, doanh nghiệp không hạ lương mà giảm tuyển dụng.

“Vấn đề là nó khiến ta ngộ nhận rằng cảm giác mơ hồ (vibe) giống như một sự trừu tượng hóa chính xác” — tôi rất đồng cảm với ý này. Chính sự trừu tượng hóa mới là thứ chỉ những người đã hiểu mức low-level theo hướng bottom-up mới có thể làm được.

Cảm ơn bản canary

Việc những thứ trước đây chạy được mà giờ không chạy được thì quả là bất tiện, nhưng chỉ riêng việc dọn bỏ đống spaghetti đã từng bị vật vã trong x11 để làm cho nó chạy được thôi cũng đã đủ lý do để đánh giá cao rồi.
Tuy vậy, nếu tìm nguyên nhân vì sao đến giờ vẫn còn nhiều thứ không chạy được thì cuối cùng vấn đề vẫn là chưa được tiêu chuẩn hóa, và đúng là khoảng thời gian đó kéo dài lâu hơn tưởng tượng.
Có lẽ đến cả năm 2030 người ta vẫn sẽ còn nói rằng nó vẫn còn lâu mới hoàn thiện, nhưng việc quay lại x11 sẽ là điều không thể.
Ngay cả trong giai đoạn hỗn loạn khi hệ sinh thái thay đổi, các giải pháp thay thế rồi cũng sẽ lại nghe những lời tương tự, còn chuyện quay lại thì có vẻ sẽ chỉ gây ra phản ứng ngược từ một hệ sinh thái mà mọi người đã quen thuộc.

Được ăn cơm nhà thì tốt thật.

Trước đây tôi từng thấy ở đâu đó một đề xuất rằng thay vì dùng cách nói "ăn thức ăn cho chó" trong tiếng Hàn thì dùng "ăn cơm nhà" sẽ hay hơn, và quả thật "ăn cơm nhà" cũng có sắc thái khá ổn.

Có lẽ cần xem liệu nó có thể được thay thế bằng các phương pháp kiểm chứng khác hay không. Càng gần phía frontend, chỉ với E2E thông qua hành vi của trình duyệt cũng có thể xác minh rằng nó hoạt động tốt. Nhưng với code ở phía backend, và càng gần hạ tầng hơn, thì có lẽ code review là điều bắt buộc. Nếu không, sẽ khó kiểm chứng các side effect như transaction vô hình được mở rồi đóng, hay các lệnh gọi API được gửi đi.

Không biết bao giờ mới có WYSIWYG cho WinUI 3 nữa.

Wow!! Garry Tan đã retweet GeekNews rồi nhé.
https://x.com/garrytan/status/2035898375934300353

Tạo ra 1 triệu dòng mã bằng 13 tỷ token... thật sự quá ấn tượng.
Cảm ơn bạn! Mình sẽ thử dùng kỹ rồi sau này chia sẻ cả phần đánh giá trên blog nữa haha