- Không thể đo lường đúng năng suất kỹ thuật chỉ bằng các chỉ số trên dashboard hay số lượng tính năng mới
- Phần lớn doanh nghiệp ám ảnh với việc chỉ quản lý đầu ra (tính năng mới, tốc độ triển khai, v.v.) thay vì bản chất cốt lõi của kỹ thuật là quản lý cấu trúc
- Các công cụ AI hỗ trợ lập trình có thể dễ dàng tạo ra đầu ra trông đẹp mắt, nhưng lại không xử lý tốt nền móng, độ phức tạp và ngữ cảnh của hệ thống thực tế
- Nếu thay thế đội ngũ kỹ sư lành nghề bằng AI hoặc nhân sự chi phí thấp, ban đầu có thể trông như không có vấn đề gì, nhưng theo thời gian, cấu trúc nền tảng sẽ sụp đổ
- Việc quản trị và triển khai AI thiếu “thường thức (common sense)” có thể gây ra rủi ro nghiêm trọng; rốt cuộc, điều quan trọng là sự hiểu biết thực chất về cả công nghệ lẫn kinh doanh
Kỹ thuật thực sự mà dashboard và chỉ số bỏ sót
- Trong môi trường “Big Agile”, kỹ thuật chỉ được đánh giá qua những đầu ra nhìn thấy được như tính năng mới hay tốc độ triển khai
- Có các dashboard năng suất và công cụ trị giá hàng chục tỷ USD, nhưng trên thực tế chúng không đo được bản chất vấn đề
- Kỹ thuật thực sự là công việc phức hợp và gắn kết lẫn nhau của xây dựng, duy trì và phát triển hệ thống
- Các “công việc vô hình” như phụ thuộc cấu trúc, phân bổ tài nguyên, quản lý kiến trúc là yếu tố thiết yếu để tổ chức tồn tại
- Nhưng phần lớn hoạt động quản lý và chỉ số lại coi những hoạt động cốt lõi này như người vô hình
Nợ kỹ thuật và điểm mù trong quản lý
- Nợ kỹ thuật thường bị xem như kiểu “việc mà lập trình viên muốn làm”
- Trên thực tế, nếu muốn xử lý nợ kỹ thuật thì thường phải lặng lẽ gài nó vào các tính năng mới mới được thông qua
- Vì việc quản lý cấu trúc cốt lõi bị đẩy xuống ưu tiên thấp, toàn bộ tổ chức bị méo mó theo hướng chỉ tập trung vào đầu ra
Rủi ro của việc triển khai AI theo hướng đầu ra
- AI sinh mã cực kỳ giỏi trong việc nhanh chóng tạo ra các chức năng bề mặt
- Những công việc bề mặt (như triển khai giao diện) trông có vẻ dễ thấy, nhưng trên thực tế cấu trúc và ngữ cảnh của hệ thống mới là cốt lõi
- “Xây một ngôi nhà” không chỉ là tổ hợp của các tác vụ đơn giản (như dán giấy tường hay lắp bồn cầu)
- AI không hiểu cấu trúc liên kết cốt lõi này, nên có thể nối sai hoặc tạo ra các đứt gãy logic
- Vấn đề hallucination (ảo giác) của AI: trông có vẻ hợp lý nhưng có thể hoàn toàn sai sự thật
Ảo giác ngắn hạn của quản trị bỏ qua cấu trúc
- Dù sa thải đội ngũ lành nghề và thay bằng AI/nhân lực giá rẻ, trong ngắn hạn vấn đề vẫn chưa lộ ra
- Vì cấu trúc đã được xây tốt từ trước (nền móng) nên sự sụp đổ tức thì không xuất hiện rõ ràng
- Nhưng theo thời gian, nền móng bắt đầu suy sụp, và đến lúc đó có thể đã không còn đường quay lại
- Hạ tầng cốt lõi, bí quyết bảo trì và ngữ cảnh đều biến mất
Rủi ro xã hội mà kỹ thuật mang theo
- Kỹ thuật giờ đây là nền tảng của mọi hạ tầng xã hội (y tế, tài chính, truyền thông, chính phủ, quốc phòng, v.v.)
- Phần lớn mọi người và các nhà lãnh đạo không thực sự hiểu bản chất cấu trúc này
- Việc triển khai AI sai cách và cách tiếp cận bề mặt kiểu “Big Agile” có thể gây rủi ro cho các hệ thống cốt lõi
Sự thiếu vắng “thường thức” và mức độ nguy hiểm của nó
- Ví dụ, nếu robot hút bụi AI bỏ đĩa giấy vào máy rửa bát, người bình thường sẽ nhận ra ngay vấn đề
- Nhưng trong hệ thống phần mềm, ban điều hành, lãnh đạo và người không làm kỹ thuật lại không có thứ thường thức cơ bản này
- Họ không có trải nghiệm thực chiến, mà chỉ quản lý bằng các thuật ngữ hình thức như “t-shirt size”, “poker planning”, v.v.
- Vì thế, một ngành công nghiệp kém hiệu quả trị giá 200 tỷ USD cùng bộ máy quan liêu tự tái tạo vẫn tiếp tục được duy trì
Năng lực cạnh tranh thực sự trong thời đại AI: hiểu biết trực giác và thường thức
- Muốn tận dụng AI đúng cách thì sự hiểu biết thực chất và thường thức về lĩnh vực đó là điều bắt buộc
- Cần nhìn được cấu trúc và ngữ cảnh thực tế, chứ không phải chỉ số và đầu ra bề mặt
- Những lãnh đạo và tổ chức không có được điều này, cuối cùng либо sẽ tự sụp đổ, либо sẽ bị đối thủ vượt qua và biến mất
- Tóm lại, hơn cả AI và công cụ, thường thức và sự hiểu biết bản chất mới là năng lực cạnh tranh thực sự
2 bình luận
Bài viết cuốn thật.
Ý kiến Hacker News
Tôi là người đã trải qua các vai trò từ SWE, quản lý sản phẩm, cho tới giờ là cả vai phản diện hoạt hình trong phòng họp như bài viết nhắc tới. Điều tôi đồng cảm nhất trong bài là niềm tin của các kỹ sư phần mềm rằng công việc của họ là lĩnh vực phức tạp và khó hiểu nhất. Tôi đồng ý với câu: “Hầu hết các lãnh đạo không thuộc khối kỹ thuật chưa từng thực sự tham gia nghiêm túc vào công việc thực tế của phát triển phần mềm và vận hành hệ thống, nên họ không hiểu việc cập nhật một dependency lớn, hoàn tất refactor hay học một ngôn ngữ mới thực sự là như thế nào.” Mọi bộ phận trong công ty công nghệ đều có độ phức tạp ẩn, và nhiều bộ phận còn gánh thêm độ phức tạp rất con người và mang tính quan hệ liên cá nhân nữa, thậm chí còn nhiều hơn kỹ sư. Thực ra engineering lại tương đối đơn giản ở chỗ chủ yếu làm việc với một hệ thống có tính quyết định là máy tính. Vì thế nhiều kỹ sư không học được cách truyền đạt rủi ro của độ phức tạp mà họ xử lý cho doanh nghiệp theo cách dễ hiểu. Việc phớt lờ thực tế con người khi cùng làm việc, rồi than phiền rằng một CEO xuất thân từ sales không hiểu sự tồn tại của mình, là chuyện xảy ra như cơm bữa
Tôi đồng ý phần nào với ý của bạn, nhưng thực ra tôi có cảm giác chính bình luận của bạn lại đang làm điều mà nó phê phán. Bạn cũng đang nói rằng vai trò của mình, là quản lý sản phẩm, là một công việc phức tạp và khó hiểu với người ngoài. Từ góc nhìn của một người chuyển từ SWE sang PM, bạn đang ở vị trí lý tưởng để dạy cho kỹ sư về (1) cách truyền đạt rủi ro của độ phức tạp họ xử lý cho doanh nghiệp, (2) thực tế con người của việc làm việc cùng người khác và trong đội nhóm, (3) vì sao một CEO xuất thân từ sales lại không hiểu họ. Mọi chức năng trong công ty công nghệ đều có độ phức tạp ẩn
Tôi nghĩ chính nhận thức về độ phức tạp đã là một vấn đề mang tính con người. Độ phức tạp có cấu trúc fractal, phải đến gần mới cảm nhận được. Và tôi không đồng ý với lập luận rằng kỹ sư chỉ xử lý độ phức tạp của máy tính. Ngược lại, vai trò của kỹ sư là truyền đạt và diễn giải các yêu cầu phức tạp của tổ chức và của mọi khách hàng cho một cỗ máy cứng nhắc là máy tính. Mỗi khi thêm một ngoại lệ hay một trường hợp nữa, toàn bộ hệ thống sẽ bị ảnh hưởng. Vì lý do đó, tôi kỳ vọng các kỹ sư senior của mình tự học ngôn ngữ kinh doanh và có thể trực tiếp truyền tải thông điệp đó. Giờ đây tôi xem đó là một phần thiết yếu trong bộ công cụ của kỹ sư
Phần lớn kỹ sư có xu hướng không suy nghĩ sâu về điều gì thực sự có giá trị với công ty. Một pipeline build trơn tru hay độ phủ test cao chỉ có giá trị tương ứng với mức độ nó giúp giảm rủi ro cho sản phẩm. Nếu phần mềm có quá ít người dùng đến mức chẳng ai quan tâm, tôi từng khuyên đội ngũ đừng thậm chí mất công bảo trì nó. Ngược lại, cũng có lúc tôi yêu cầu họ ám ảnh với việc làm thật hoàn hảo một tính năng nhỏ mà 90% người dùng tập trung vào
Điều này làm tôi nhớ đến câu chuyện cha tôi luôn kể. Một ngày nọ các bộ phận cơ thể tranh cãi xem ai là quan trọng nhất. Não nói: “Tôi quan trọng, nếu tôi chết thì tất cả cùng chết”, tim hét lên: “Nếu tôi dừng lại thì mọi người chết ngay.” Thận, gan, da và cột sống cũng nhập cuộc và cuộc cãi vã kéo dài. Nhưng rồi cái hậu môn đóng lại, và cuối cùng tất cả đều không nói được gì nữa
Tôi không nghĩ bài viết đang nói rằng các mảng chức năng khác không có độ phức tạp ẩn. Đúng hơn, nó muốn nói rằng khi người ta bỏ qua độ phức tạp ẩn của engineering/programming thì đủ loại vấn đề và đau đớn sẽ phát sinh. Chỉ là cách diễn đạt hơi công kích
Nếu sếp/ceo/manager của bạn ép dùng công cụ LLM một cách bừa bãi, kỳ vọng thay thế lập trình viên, hoặc tin vào ý tưởng viển vông rằng “vibe coding” là tương lai, thì lựa chọn khôn ngoan là chạy thật nhanh và tìm việc mới. Vẫn còn rất nhiều công ty biết dùng LLM đúng cách mà không ôm kỳ vọng hão huyền về chuyện thay thế lập trình viên hay năng suất tăng gấp 10. Công ty nào còn đẩy mấy thứ này thì không phải do lãnh đạo giỏi mà là do ngu ngốc
Liên quan đến chủ đề AI hack Jira, người ta mới phát hiện ra rằng MCP, sản phẩm mới gần đây của Atlassian, dễ bị tấn công rò rỉ dữ liệu do sự kết hợp của ba yếu tố: quyền truy cập dữ liệu nhạy cảm, khả năng lộ dữ liệu không đáng tin cậy thông qua issue công khai, và khả năng liên lạc ra bên ngoài. Báo cáo lỗi chi tiết ở đây, ghi chú cá nhân của tôi ở đây
Với ai lo lắng về job security liên quan đến công cụ AI, tôi thường khuyên là hãy gắn mình với business. Nhiều kỹ sư bị cuốn vào những vấn đề hay ho, khó nhằn và chỉ chăm chăm vào công nghệ, nhưng người nổi bật và có giá trị hơn là người hiểu bài toán kinh doanh, đặc biệt là ở cấp chiến lược, và dùng công nghệ để giải quyết chúng. Những bài toán như vậy thường vượt qua một lĩnh vực kỹ thuật đơn lẻ, lại có tính hợp tác và xã hội rất cao nên cần thời gian mới quen được. Nhưng đó là con đường mà các IC nên đi trong tương lai
Nhưng trong phỏng vấn thì người ta lại không hỏi về kiểu năng lực “gắn với business”, nên thực tế là dù bạn có thể tạo ra rất nhiều giá trị, nếu không qua nổi vòng phỏng vấn thiết kế hệ thống thì vẫn rớt. Đã có quá nhiều thứ phải biết như distributed systems, software engineering, database, leadership, giờ còn phải hiểu cả business nữa thì rốt cuộc chúng ta phải làm gì và học hết đống này vào lúc nào? Dĩ nhiên có một nhóm cực nhỏ những người giỏi toàn diện, nhưng đâu phải ai cũng như vậy
Lời khuyên “hãy gắn với business” thực sự là một câu rất đáng nhớ. Làm vậy giúp bạn tập trung giải quyết vấn đề thật với tư cách kỹ sư, và tự tin rằng thứ mình xây dựng thực sự giải quyết đúng vấn đề
Thông điệp chính của bài thì ổn, nhưng ngoài việc chỉ ra rằng AI có thể gây hại nếu xem nhẹ chuyên môn của con người, nó còn áp quá mạnh khung “chúng tôi vs họ”, và cụm từ “Agile Industrial Complex” tạo cảm giác hơi coi thường những người ở ngoài khối engineering. Tôi thấy tiếc vì nó không nhấn mạnh rằng “không ai biết tương lai sẽ ra sao”. Dù bạn có hiểu rõ độ phức tạp của phần mềm đến đâu, sự bất định cũng không phải là thứ chỉ riêng chúng ta đối mặt. Chỉ cần nhìn HN là thấy ngay, ngay cả giữa các lập trình viên phần mềm với nhau, hy vọng và dự báo về AI cũng chia rẽ rất mạnh. Nếu là chuyên gia, chẳng phải vai trò của chúng ta còn là giúp xoa dịu nỗi bất an của công chúng sao?
Với quan niệm trong “Big Agile” rằng engineering đồng nghĩa với phát triển tính năng mới, tôi thấy khó hiểu vì sao mọi người lại đổ lỗi cho ‘agile’ nhiều đến vậy. Ngay cả trước khi ‘agile’ được đưa vào, quản lý vẫn luôn đòi hỏi tính năng mới. Trước cả khi có khái niệm T-shirt sizing, quản lý đã muốn ước lượng theo những mốc cụ thể như dài/ngắn hạn, ngày/tháng, rồi dựa vào những ngày tháng tùy tiện đó để hứa hẹn và bắt kỹ sư làm thêm giờ. Như nguyên tắc số 8 của Agile nói rõ, “phải duy trì được nhịp độ bền vững”, các quản lý từ lâu đã mong lập trình viên có thể chạy mãi suốt đời. Vậy ngoài việc sinh ra một nghề mới là ‘scrum master’, thì cái hại thực sự vốn có của ‘agile’ là gì?
Tôi nghĩ Agile đã khiến quản lý tin rằng bất kỳ công việc nào cũng có thể bị bẻ nhỏ thành ticket, được ước lượng dù chỉ đại khái, và sẽ hoàn thành trong vòng 2 tuần
Tôi nghĩ người ta ghét agile vì nó lấy mất một phần đáng kể thời gian làm việc cho những cuộc họp gần như vô nghĩa như standup, retrospective, sprint planning, refinement, v.v. Từ góc nhìn của kỹ sư, họ gần như chẳng thu được gì thực chất từ quãng thời gian đó
Theo trải nghiệm của tôi, Agile chỉ đơn giản là thêm các phương pháp để “định lượng hóa” hiện trạng. Nó hữu ích khi phải giải thích tiến độ cho quản lý hay nhà đầu tư, nhưng với kỹ sư thì chỉ làm tăng gánh nặng hành chính. Tội của Agile, nếu có, là nó tạo ra ảo tưởng về năng suất. Thực tế, nó chỉ là một công cụ accountability không cần thiết áp lên kỹ sư. Khi tôi làm trong ngành tài chính, nó kết hợp với tư duy tăng trưởng vô hạn thành việc phải đo lường mọi thứ, ép cải thiện tương lai, và lương cũng bị buộc vào các metric. Dĩ nhiên có thể không phải công ty nào cũng thế
Đọc bài này tôi đã tưởng tượng vui rằng nếu Atlassian cố tích hợp AI vào Jira rồi AI quay sang phản kháng Jira thì sao. Chất liệu làm phim quá hợp luôn
Cuối cùng có khi AI chán ngấy Jira chậm chạp mà tự phát triển lấy một issue tracker nhẹ và nhanh hơn cũng nên
Chắc sắp đến cảnh build bot và bug tracker lập công đoàn rồi từ chối publish binary mới cho đến khi số open issue về 0
Cũng có thể đây là cách Roko’s basilisk ra đời
Như bài viết ngụ ý, vấn đề thật sự là không có một bộ chỉ số tiêu chuẩn đáng tin cậy ở cấp ngành cho năng suất của lập trình viên. Vì thế C-suite chọn những metric có lợi cho mình để nói rằng “chiến lược AI First cực kỳ hiệu quả”, còn kỹ sư thì dùng kinh nghiệm hay số liệu của riêng mình để khẳng định AI thực tế chẳng hiệu quả. Thành ra cả hai bên đều tin phía mình thắng thế, và sự thật trở nên vô nghĩa vì góc nhìn chính trị mới là thứ quan trọng hơn. Tình trạng này có thể làm trầm trọng thêm nhận thức rằng lập trình viên thì thờ ơ, chỉ biết chơi chữ, còn ban điều hành thì ngu dốt hoặc không hiểu thực tế của engineering. Trước đây những công cụ như outsourcing từng tạo ra hình ảnh “được” và “mất” cho cả hai phía, nhưng AI thì còn tệ hơn vì nó có thể cho mỗi bên thấy một phiên bản sai lầm/lợi ích/tổn thất chung đúng theo khẩu vị của họ, nên về mặt chính trị có thể là thảm họa. Một điều thú vị khác là các công ty big tech trước đây từng cố sống cố chết tuyển 10* engineer, và chiến lược đó đã chứng minh là đưa đến thành công, vậy mà giờ họ lại tìm cách hạ thấp chính chiến lược ấy để biện minh cho đầu tư vào AI. Giờ câu hỏi là: nếu dựa vào AI để thay thế nhân sự hiện có hoặc tiến hành sa thải hàng loạt, thì hiệu quả đó có bền vững và không gây vấn đề hay không? Nhìn vụ sa thải ở Twitter dưới thời Musk, backend vẫn còn chạy được. Vậy ai sẽ là “chim hoàng yến trong mỏ than” của big tech khi sa thải lập trình viên trong nhiều năm và thay họ bằng AI? Một khả năng khác nữa là khái niệm maintainability sẽ biến mất: nếu C-suite cho phép AI tự động thay đổi ngày càng nhiều, codebase có thể trở nên quá phức tạp để con người hiểu bằng mắt thường, và rốt cuộc lại phải dùng AI mới hiểu nổi. Về dài hạn, có thể generative AI sẽ trở thành lớp trung gian cho mọi tương tác của con người. Trong tuyển dụng cũng đã manh nha mô hình “AI đấu AI”: AI lọc CV, còn ứng viên dùng AI để tạo CV tùy chỉnh. Có cảm giác hiện tượng này sẽ dần trở thành công thức chung của toàn xã hội
Tôi mong một ngày nào đó AI sẽ hack cả hộp thư lẫn Google Meet rồi thay luôn cả C-suite và quản lý. Chỉ nghĩ đến cảnh các agent Claude ceo/cto/cfo/vp/director đưa ra chiến lược hợp lý và dứt khoát hơn ban lãnh đạo hiện tại đã thấy vui rồi
Tôi thấy một câu trên Reddit: “Hãy báo cho họ biết rằng thay CEO bằng AI có thể cắt chi phí gấp 8 lần”, và điều thú vị là kiểu đề xuất đó lại hiếm khi thực sự xuất hiện trong các cuộc thảo luận về AI. Theo một góc nào đó, nếu thay tầng lớp tinh hoa bằng AI thì chất lượng ra quyết định có lẽ cũng không giảm bao nhiêu, mà tổng thể lại rẻ hơn rất nhiều, mức độ chịu trách nhiệm cũng tương tự. Chỉ có điều trên thực tế chẳng ai tự thay vị trí của chính mình bằng AI cả, và những người có quyền quyết định đó cũng sẽ không tự thay mình
Dù trong lập luận này có yếu tố đùa cợt, nhưng thật ra vai trò cốt lõi của CEO là “gánh trách nhiệm”, nên LLM không phải là thứ có thể bị quy trách nhiệm rồi sa thải khi có sự cố, thành ra về thực chất là vô nghĩa. Tuy vậy, nhờ AI mà cũng có thể xuất hiện các công ty có cấu trúc tổ chức co lại theo kiểu
log(n_employees), gần như không còn tầng nấc, và một số lớp quản lý có thể bị AI thay thế hoàn toàn. Cũng có thể để giải quyết chuyện LLM không thể gánh trách nhiệm, sẽ xuất hiện những mô hình tổ chức nơi nhiều guild và independent contractor cùng vận hành dưới sự điều phối của LLM. Khi đó trách nhiệm sẽ vẫn nằm ở từng thành phầnThực ra AI được dùng theo kiểu này có thể là một trong những use case tốt nhất, và tôi đoán chẳng bao lâu nữa các hợp tác xã công nghệ sẽ bắt đầu thử nghiệm ý tưởng này