- Việc tăng năng suất AI ở cấp độ cá nhân của nhân viên không tự động dẫn đến học hỏi ở cấp độ tổ chức; thách thức cốt lõi là con đường để các phát hiện thực tế chuyển từ cá nhân sang đội nhóm và năng lực tổ chức
- Trong giai đoạn trung gian phức tạp của việc áp dụng AI, các công cụ như Copilot, ChatGPT Enterprise, Claude, Gemini, Cursor đã được dùng rộng rãi nhưng độ sâu sử dụng khác nhau giữa các nhóm, và một phần việc học hỏi bị ẩn nên khó so sánh và lan tỏa
- Các phương thức quản trị thay đổi truyền thống như cộng đồng, mạng lưới champion, demo, khảo sát, dashboard khó ghi lại đầy đủ bối cảnh, thất bại, kiểm chứng và sự can thiệp của con người trong việc sử dụng AI phát sinh ngay trong công việc thực tế
- Kỹ thuật agentic làm giảm chi phí lặp lại, giúp chuyển nhanh từ ý định sang nguyên mẫu và đánh giá, nhưng các quy trình Scrum, sprint, bàn giao của tổ chức vẫn có thể dựa trên giả định rằng việc lặp lại là thứ hiếm và tốn kém
- Tổ chức cần đồng thời có Agent Operations, Loop Intelligence và Agent Capabilities; điều quan trọng là một feedback harness giúp hiểu các vòng lặp công việc thực tế để biến chúng thành năng lực có thể tái sử dụng và học hỏi nhanh hơn, chứ không phải để giám sát nhân viên
Giai đoạn trung gian phức tạp của việc áp dụng AI khi tổ chức không học được gì
- Theo góc nhìn của Ethan Mollick trong
Leadership, Lab, and Crowd, việc nâng cao năng suất AI ở cấp độ cá nhân không tự động trở thành kết quả ở cấp độ tổ chức
- Nhân viên có thể viết nhanh hơn, phân tích nhiều hơn, tự động hóa và làm việc như một “cyborg”, nhưng công ty có thể hầu như không học được gì
- Các công cụ như GitHub Copilot, ChatGPT Enterprise, Claude, Gemini, Cursor đã đi vào trong doanh nghiệp, và ở mỗi nhóm đều có những người đi xa hơn rất nhiều so với tài liệu đào tạo chính thức
- Ban lãnh đạo có thể nhìn thấy mức sử dụng license, số prompt, khảo sát, PoC nội bộ, tài liệu của ban chỉ đạo, nhưng khó thấy được việc học hỏi thực sự đang diễn ra ở đâu
- Ở một số công ty, AI được chuyển thẳng sang bộ phận IT rồi không còn tiến triển gì thêm
- Giai đoạn trung gian phức tạp của việc áp dụng AI bắt đầu khi việc sử dụng AI đã lan rộng nhưng không đồng đều, một phần bị che khuất, khó so sánh và vẫn chưa kết nối được với học hỏi của tổ chức
- Đơn vị áp dụng không còn là toàn bộ tổ chức nữa, thậm chí có thể không còn là cả một nhóm, mà chuyển thành các loop trong công việc thực tế
Điều xảy ra sau khi ai cũng có Copilot
- Giai đoạn đầu của việc áp dụng AI trông khá quen thuộc, giống một đợt rollout enterprise thông thường
- Mua seat, xác định phạm vi sử dụng được chấp nhận, đào tạo, xây dựng mạng lưới champion, và yêu cầu chia sẻ use case trong các kênh Teams
- Những kênh này có thể sôi động trong một thời gian rồi biến thành kho lưu trữ nội bộ đầy thiện chí nhưng ít giá trị sử dụng
- Ở giai đoạn thứ hai, cách sử dụng AI phân hóa mạnh ngay trong cùng một công ty
- Có nhóm chỉ dùng Copilot như công cụ tự động hoàn thành
- Nhóm khác vận hành Claude Code trong một loop chặt chẽ cùng với kiểm thử, review và hiệu chỉnh liên tục
- Người làm sản phẩm thay vì tạo màn hình Figma thì bắt đầu prototype phần mềm thực sự
- Một kỹ sư senior giao phân tích nguyên nhân gốc cho agent và nhận được lời giải hợp lệ trong vòng 1 giờ, rút ngắn công việc vốn sẽ mất 2 tuần nếu không có AI
- Một junior có thể tạo ra code trau chuốt nhưng lại không biết những giả định kiến trúc nào đã len vào hệ thống
- Đội hỗ trợ âm thầm biến ticket lặp lại thành workflow tự động hóa, và họ biết những điểm đau thật sự mà Center of Excellence chưa từng hỏi tới
- Trong cấu trúc của Mollick, leadership đặt ra định hướng và quyền cho phép, Crowd làm công việc thực tế nên phát hiện ra use case, còn Lab biến những phát hiện đó thành thực hành dùng chung, công cụ, benchmark và hệ thống mới
- Điểm khó cốt lõi nằm ở việc các phát hiện thực sự di chuyển từ cá nhân sang nhóm, rồi từ nhóm sang năng lực tổ chức như thế nào
Cách quản trị thay đổi truyền thống quá chậm
- Phần lớn công ty cố xử lý việc áp dụng AI bằng bộ công cụ quản trị thay đổi hiện có
- Các cộng đồng thực hành, buổi lunch session, mạng lưới champion, tài liệu enablement, office hour, demo hàng tháng, khảo sát, dashboard... đều được sử dụng
- Ở những tổ chức mà ngay cả việc được phép thử nghiệm vẫn còn là vấn đề, các cách làm này vẫn hữu ích
- Nhưng những cách dùng AI thú vị nhất không chờ đến cuộc họp cộng đồng tiếp theo mà xuất hiện ngay trong công việc thực tế
- Chúng xuất hiện trong code review, đề xuất bán hàng, công việc nghiên cứu, prototype sản phẩm, sự cố vận hành, chiến lược kiểm thử, câu hỏi compliance
- Trong một số loại component sản phẩm cụ thể, có thể hình thành mô thức gần với một “dark factory”
- Viết ra ý định
- Để agent chạy một loop lỏng
- Tạo đủ backpressure để giữ đúng hướng
- Đánh giá kết quả bằng các scenario mạnh
- Tinh chỉnh ý định và lặp lại để đạt kết quả chất lượng cao một cách nhất quán
- Những gì được học hữu ích thường mất đi độ sắc khi bị đóng gói thành slide best practice
- Vì thứ tạo ra giá trị thực sự chính là bối cảnh bị lược bỏ, các bài test thất bại, hành vi API kỳ lạ, và ma sát khi con người phải kéo agent quay lại lúc nó đi lệch hẳn sang hướng vô lý
- Theo góc nhìn elastic loop, hợp tác với AI không phải chỉ có một chế độ
- Nó trải dài từ kiểu cùng lái đồng bộ, chặt chẽ đến kiểu ủy quyền lỏng hơn và bất đồng bộ hơn
- Câu hỏi quan trọng không phải là “mọi người có dùng AI không”, mà là nhóm nên dùng loop cỡ nào, cần lực cản ở đâu, đầu ra nào phải còn tồn tại sau loop, và đầu ra đó được biến thành học hỏi của tổ chức như thế nào
- Đây là những câu hỏi khó hơn nhiều so với việc đếm lượng dùng công cụ hay số token
Scrum được tạo ra trên giả định rằng lặp lại là thứ đắt đỏ
- Phần lớn quy trình phần mềm hiện đại tồn tại vì việc lặp lại của con người vốn đắt đỏ
- Sprint planning, estimate, standup, user story, dọn dẹp ticket, handoff, và các nghi thức nhằm điều phối và giảm rủi ro đều thuộc nhóm này
- Nếu một vòng lặp mất nhiều ngày hoặc nhiều tuần, cần có cấu trúc để ngăn lặp lại lãng phí
- Kỹ thuật agentic thay đổi tính kinh tế của sự lặp lại
- Nó cho phép hiện thực hóa nhiều lựa chọn hơn
- Giúp đi từ ý định đến prototype rồi đánh giá nhanh hơn
- Giúp người làm sản phẩm nhìn thấy phần mềm chạy được sớm hơn
- Giúp kỹ sư kiểm tra nhiều giả thuyết hơn trước khi ra quyết định
- Nó không khiến việc delivery trở nên dễ như phép màu, nhưng chuyển điểm nghẽn từ triển khai sang ý định, xác minh, phán đoán và phản hồi
- Nhiều tổ chức đã tự gọi mình là agile suốt 20 năm nhưng vẫn giữ lại những phản xạ tổ chức mà agile từng muốn loại bỏ
- AI khiến sự linh hoạt thực sự có vẻ khả thi hơn, nhưng hệ thống vẫn đòi hỏi cam kết sprint 2 tuần, tài liệu handoff và các quy trình dựa trên giả định rằng lặp lại là hiếm
- Các loop có thể chạy nhanh hơn tốc độ tổ chức có thể hấp thụ những gì học được từ chúng
Phí sử dụng AI buộc tổ chức phải đặt ra câu hỏi tốt hơn
- Việc sử dụng AI có khả năng được đo lường rõ hơn
- Bầu không khí enterprise hiện tại kiểu “ai cũng có quyền truy cập và chưa cần quá lo về chi phí” có thể sẽ không kéo dài
- Model routing, ngân sách token, định giá theo mức sử dụng, chi phí suy luận và governance về việc công việc nào được phép dùng model nào sẽ trở nên rõ ràng hơn
- Câu hỏi quan trọng không phải là cắt giảm chi phí token một cách trừu tượng
- Cũng như trong delivery phần mềm, câu hỏi quan trọng chưa từng là làm sao giảm số lần gõ phím
- Câu hỏi tốt hơn là: “Vì đã dùng số token đó nên điều gì đã thay đổi?”
- Cần tránh kiểu đo lường bằng cách đếm số pull request
- Loop nào đã được khép lại nhanh hơn?
- Quyết định nào đã được cải thiện?
- Phân tích nguyên nhân gốc nào trở nên sắc bén hơn?
- Review nào bắt được nhiều vấn đề hơn?
- Nhóm nào đã học được những mô thức có thể tái sử dụng?
- Ý tưởng sản phẩm nào bị loại bỏ sớm hơn vì prototype làm lộ ra điểm yếu?
- AI đã tạo ra học hỏi ở đâu, và ở đâu nó chỉ đơn giản tạo thêm nhiều đầu ra hơn?
- “Đầu ra trên mỗi token” chỉ là phản xạ đo lường cũ trong lớp áo mới
- Điều quan trọng hơn là gần với học hỏi trên mỗi token
Loop Intelligence như một đường phản hồi còn thiếu
- Trong giai đoạn trung gian phức tạp của việc áp dụng AI, công ty cần ba năng lực
-
Agent Operations
- Quản lý những agent và công cụ AI nào đang chạy, có thể chạm vào hệ thống nào và được nhìn thấy dữ liệu nào
- Điều này cũng bao gồm hành động nào cần phê duyệt, danh tính, audit, quyền hạn và mức độ hiển thị ở runtime nằm ở đâu
- Vì công việc kiểu agent cuối cùng sẽ chạm vào các hệ thống thật, nên khía cạnh kiểm soát là rất quan trọng
-
Loop Intelligence
- Xác định loop nào có AI hỗ trợ hoặc hoàn toàn agentic đang thực sự tạo ra học hỏi
- Nhìn ra loop nào còn bỏ ngỏ, loop nào suy yếu, nơi nào agent tạo ra đòn bẩy và nơi nào nó lan sang các nhánh phụ
- Đánh giá nhóm nào còn bị buộc vào giám sát chặt vì thiếu kiểm thử, thiếu bối cảnh, thiếu trực giác, và nhóm nào đã sẵn sàng cho mức ủy quyền lỏng hơn
-
Agent Capabilities
- Triển khai các năng lực hữu ích trên toàn tổ chức nhưng không giả định rằng ba agent khổng lồ là có thể làm hết công việc cho mọi người
- AI bắt đầu vận động giống một công nghệ nền linh hoạt hơn là một danh mục ứng dụng đơn lẻ
- Nó không phù hợp với cách xây dựng một “vườn thú enterprise” gồm một “HR agent”, một “engineering agent”, một “sales agent”
- Năng lực phải chảy đến đúng nơi công việc thực sự diễn ra
- harness cho nhân viên
- background agent
- nhóm sản phẩm
- dịch vụ nền tảng
- kỹ năng cục bộ
- MCP server
- bộ đánh giá
- runbook
- ví dụ
- quy trình theo miền
Câu hỏi ở cấp nền tảng và feedback harness
- Ở cấp platform, câu hỏi quan trọng là quyền sở hữu và cách di chuyển của các năng lực hữu ích
- Cần có cách để một kỹ năng agent hữu ích được phát hiện trong một nhóm có thể truyền sang nhóm khác thay vì biến thành một template chết
- Harness của developer, harness của người làm sản phẩm, background agent của đội hỗ trợ, workflow compliance cần được tăng cường theo các cách khác nhau
- Có năng lực cần ở gần đội ngũ, có năng lực nên nằm ở lớp platform, và cũng có năng lực mà bối cảnh cục bộ chính là cốt lõi nên không nên tổng quát hóa
- Chỉ có một trong ba năng lực thì sẽ nhanh chóng trở nên kỳ quặc
- Chỉ có Agent Operations mà không có Loop Intelligence thì sẽ thành bộ máy quan liêu kiểm soát
- Chỉ có Loop Intelligence mà không có Agent Capabilities thì sẽ thành một tầng phân tích phát hiện được mô thức hữu ích nhưng không đưa được chúng trở lại công việc
- Chỉ có Agent Capabilities mà không có Operations và Loop Intelligence thì sẽ thành một mớ công cụ hỗn loạn với branding đẹp hơn
- Đường kiểm soát, đường học hỏi và đường năng lực phải gặp nhau ở đâu đó
- Nội bộ có thể gọi đây là feedback harness
- Thứ khách hàng mua không phải là một cơ chế tao nhã mà là sự tự tin, quyết định tốt hơn, học nhanh hơn, ít lãng phí hơn và ủy quyền an toàn hơn
- Một khái niệm hữu ích hơn với khách hàng có thể là Loop Intelligence Hub
- Feedback harness là thiết bị lắng nghe các loop công việc thực tế
- Nó quan sát task, prompt, spec, review, scenario, các giả thuyết được chấp nhận hoặc bác bỏ, tín hiệu vận hành, rework, quyết định và can thiệp của con người
- Mục tiêu không phải để giám sát con người mà để hiểu loop
- Phiên bản đầu không cần là một platform khổng lồ
- Chỉ cần chọn vài workflow thực tế, đo đạc những điểm mà ý định, công việc của agent, xác minh và quyết định của con người đã để lại dấu vết, rồi thu thập đủ phản hồi định tính để hiểu vì sao loop thành công hoặc thất bại và biến điều đó thành đầu ra học hỏi có tính lặp lại
- Loop Intelligence Hub biến tín hiệu thành dạng mà tổ chức có thể hành động
- backlog enablement
- radar năng lực
- bản tóm tắt đầu tư
- khoảng trống governance
- workflow có thể tái sử dụng
- nhu cầu đào tạo
- ưu tiên đánh giá
- Điều cần thiết không phải là một dashboard cho mọi nơi, mà là đầu ra phù hợp với mức độ liên quan
- Đầu ra thú vị không phải là bản thân dashboard mà là quyết định phía sau nó
- Có nhóm cần backpressure tốt hơn trước khi ủy quyền nhiều hơn
- Có nhóm sản phẩm sở hữu mô thức dark factory có thể lặp lại cho một loại component hẹp
- Có workflow compliance cần ranh giới công cụ có governance áp dụng được
- Có kỹ năng nên được đưa lên platform vì đã có năm nhóm cùng tái phát minh sai theo cách riêng của họ
- Harness thu thập, hub giúp tổ chức ra quyết định, và lớp năng lực đưa phần học được trở lại công việc
Nếu biến thành giám sát nhân viên thì sẽ thất bại
- Nếu cấu trúc này biến thành chấm điểm nhân viên thì toàn bộ sẽ sụp đổ
- Nếu nhân viên tin rằng tổ chức đang đo xem họ đã dùng AI đủ nhiều chưa, họ sẽ thao túng tín hiệu
- Nếu họ tin rằng mọi thử nghiệm đều sẽ biến thành kỳ vọng năng suất, họ sẽ giấu thử nghiệm đi
- Nếu họ tin rằng workflow tốt nhất của họ sẽ sớm trở thành khối lượng công việc mặc định mới, họ sẽ giữ nó cho riêng mình
- Công ty sẽ rơi vào hình thức áp dụng tệ nhất: tuân thủ nhìn thấy được nhưng học hỏi thì vô hình
- Câu hỏi hữu ích không phải là “ai dùng AI đủ nhiều”
- AI đã thay đổi công việc ở đâu theo cách mà tổ chức có thể học được?
- Loop nào trở nên lành mạnh hơn?
- Nhóm nào cần backpressure tốt hơn trước khi ủy quyền nhiều hơn?
- Nếu prototype đang trở thành phần mềm thật, nhóm sản phẩm nào cần một môi trường khác?
- Chính sách là cần thiết, nhưng governance cũng như học hỏi chỉ trở nên thực tế thông qua việc sử dụng
- Khi agent chạm vào những công việc sát với vận hành
- Khi người làm sản phẩm tạo prototype thay vì viết spec
- Khi developer ủy quyền phân tích nguyên nhân gốc
- Khi chi tiêu token tăng lên và ban lãnh đạo cần câu trả lời
- Lúc đó tổ chức sẽ biết liệu mình đã xây được một hệ thống học hỏi hay chỉ đơn giản là mua rất nhiều seat
Giai đoạn trung gian phức tạp không phải thứ để chịu đựng cho qua
- Giai đoạn đầu của việc áp dụng AI xoay quanh quyền truy cập
- Ai được dùng công cụ, ai được cấp phép, ai đàm phán hợp đồng, ai có thể thử model mới nhất mà không cần ticket mua sắm đều là những câu hỏi quan trọng
- Giai đoạn này vẫn quan trọng nhưng sẽ không còn là yếu tố khác biệt lâu dài
- Quyền truy cập vào trí tuệ tuyến đầu có thể được mượn, nhưng kiểm soát vận hành và học hỏi tổ chức thì không thể mượn theo cách đó
- Lợi thế tiếp theo là tốc độ học hỏi
- Ai tìm ra được các mô thức thực sự nhanh hơn?
- Ai chuyển được phát hiện từ cá nhân sang nhóm, rồi từ nhóm sang năng lực tổ chức?
- Ai đưa backpressure vào các loop agentic để ngăn agent lan tràn?
- Ai triển khai được các năng lực agent hữu ích mà không biến chúng thành những enterprise agent khổng lồ không phù hợp với tất cả mọi người?
- Ai dùng kỹ thuật agentic để khiến agile gần với thực tế hơn, thay vì chỉ chồng thêm AI lên các nghi thức cũ?
- Rất khó hiểu được thay đổi này nếu cứ chờ một playbook áp dụng đã được chốt sẵn
- Thay vì chờ câu trả lời cuối cùng từ vendor, consultant hay AI lab, cần đo đạc công việc thực tế, chia sẻ việc học hỏi còn lộn xộn, để người khác chỉ ra lỗ hổng và lặp lại một cách công khai
1 bình luận
Ý kiến trên Hacker News
Trong môi trường doanh nghiệp lớn, việc triển khai AI hầu như không vượt ra ngoài nhóm phát triển, và chỉ lập trình viên mới được dùng GitHub Copilot
Từ lúc code được commit đến khi triển khai lên production mất 6–12 tháng, và tốc độ phát triển vốn chưa bao giờ là nút thắt cổ chai
Những thứ tốn thời gian là các quy trình như cấp phát hạ tầng, kiểm thử, phê duyệt, quản lý thay đổi, lịch triển khai; AI chỉ làm nút thắt sau giai đoạn phát triển tệ hơn, khiến các thay đổi chất đống trước “chuyến tàu phát hành”
Muốn có ROI từ chi phí token, các tập đoàn lớn phải học cách triển khai phần mềm nhanh hơn, vì code chưa được triển khai không phải tài sản mà là khoản nợ
Đúng là phát triển phần mềm có nhiều chỗ kém hiệu quả, nhưng cốt lõi không phải là viết code mà là quá trình khảo sát và thiết kế để tìm ra cần viết loại code nào, và phần này thường không được tính đến
Khi Microsoft hô “code nhanh hơn 50%!”, lãnh đạo sẽ hiểu thành “sản phẩm cũng ra nhanh hơn 50%, tiền cũng về nhanh hơn 50%”
Ngay khi bắt đầu đòi ROI thì rất dễ thành thảm họa, chỉ là hiện giờ mọi người vẫn đang né đo lường mà thôi
Sớm muộn gì nhà đầu tư cũng sẽ nói “đã chi 2 triệu USD thì phải tạo ra 4 triệu USD lợi nhuận ròng”, nhưng rất khó có được kết quả như vậy
Copilot và Claude không giải quyết được những nút thắt thật sự như tri thức tổ chức cũ kỹ, các giải pháp đặc thù không được tài liệu hóa, hay khả năng tận dụng trong tương lai
Code không phải sản phẩm thật, cũng không phải công việc thật; trong một codebase lành mạnh, nó gần như là sản phẩm phụ gần như miễn phí của quá trình thiết kế và khảo sát
Một khi đã gọt “bộ phận mua hàng thấy khó dùng tính năng tìm kiếm” thành một ticket đủ thực tế, thì component bộ lọc tìm kiếm bằng React về cơ bản đã được quyết định sẵn, việc code gần như chỉ còn là một thủ tục hình thức kéo dài 10 phút
Copilot có rút nó xuống còn 5 phút thì cũng chẳng ấn tượng lắm nếu trước đó đã tốn 6 tiếng họp và gọi điện
Dinh dưỡng và calo cũng chỉ hữu ích đến một mức nào đó, sau đó lợi ích giảm dần rồi cuối cùng còn phản tác dụng
Đây không phải phép ví von hoàn hảo, nhưng nó giúp hình dung mô hình tư duy rằng sản xuất nhiều hơn đôi khi lại tạo ra ít giá trị hơn
Từng nhận phản hồi từ khách hàng rằng tài liệu đầy đủ, chi tiết nhưng quá ngợp, và cuối cùng nhận ra vài bullet point ngắn nêu đúng trọng tâm còn tốt hơn một tài liệu dài 5 trang
[0] https://en.wikipedia.org/wiki/Theory_of_constraints
[1] https://www.goodreads.com/book/show/113934.The_Goal
[2] https://www.goodreads.com/en/book/show/17255186-the-phoenix-...
Bộ phận tài chính từng hỏi liệu họ có thể vibe coding một ứng dụng lập kế hoạch tài chính bằng Copilot, Cursor, Claude hay không, còn nói thêm rằng “CFO đã thử Lovable, thấy ổn nên bảo bọn tôi vibe code một app”
Họ biết chỉ cần lôi lý do “CFO nói thế” ra là lãnh đạo sẽ khựng lại
Cuối cùng họ còn bọc lại bằng câu nghe rất hợp lý kiểu “cần kiểm tra xem liệu một ứng dụng vibe coding có thể tồn tại trong lĩnh vực tài chính doanh nghiệp với bảo mật dữ liệu và khả năng bảo trì phù hợp hay không”
Điều còn gây sốc hơn là kiểu lập luận này lại xuất hiện ở một công ty có doanh thu hằng năm hơn 20 tỷ USD
Với một kỹ sư bình thường như tôi, dùng AI trong công ty chẳng mang lại lợi ích thực tế nào
Công ty đang từ từ luộc chúng tôi, còn tầng lớp tinh hoa trên HN như nhà đầu tư, lãnh đạo, người nổi tiếng, kỹ sư top đầu thì sẽ bảo “làm sao lại phản đối đổi mới được?”
AI/LLM không phải kiểu đổi mới như TCP/IP, Linux hay Postgres
Những thứ như Claude, Codex, Gemini, Grok tồn tại vì lợi nhuận; đó là công cụ để vắt kiệt năng suất đến giọt cuối cùng rồi sa thải khi không còn cần nữa
Nếu AI thực sự tốt thì tốt hơn hết là dùng mô hình mã nguồn mở và dùng cho dự án cá nhân
AI có thể tung ra rất nhiều code, nhưng vẫn cần kỹ sư hiểu thực sự chuyện gì đang xảy ra, và đó từ trước đến nay mới là nút thắt
Vị trí junior có thể biến mất, nhưng kỹ sư senior có lẽ vẫn ổn trong một thời gian
Tôi vốn cũng hay chống đối nên đây là bài học khó nuốt, nhưng một khi đã được thuê thì bạn được thuê để làm điều lãnh đạo muốn
Nếu chống lại thì chỉ còn cách hy vọng họ không nhận ra hoặc không quan tâm, chứ rất khó tạo ra thay đổi lớn
Không biết mọi người còn nhớ SCO đã làm gì với ngành này lúc họ sụp đổ không
Tôi vẫn không hiểu vì sao các công ty lại giao thông tin mật nội bộ như code, quy trình, yêu cầu khách hàng, chính trị nội bộ, ý tưởng lãnh đạo cho startup và các tập đoàn lớn khó mà tin tưởng
Microsoft cũng từng nổi tiếng vì NDA và lạm dụng giao dịch
Tôi không tin các đại gia LLM lại không huấn luyện trên dữ liệu doanh nghiệp, và cũng không tin họ sẽ không nói dối về chuyện đó
Nếu họ bắt đầu sụp, cơn sốt vàng này có thể để lại một cái đuôi dài và rất xấu xí
Thực tế, bên bị sa thải là những người không áp dụng các công nghệ này, và cư xử như vậy thì tự đưa mình vào vùng nguy hiểm
Chỉ nhìn ví dụ Coinbase hôm nay cũng thấy, họ đang dọn dẹp những người không chấp nhận tương lai
Những người đó không giúp thúc đẩy tiến bộ, không đẩy mọi thứ tiến lên, và còn níu chân những người làm điều đó
Bài viết chạm đúng vào messy middle
Một lập trình viên có trách nhiệm và công việc gắn liền với mình gần như không có động lực để xây các vòng lặp thông minh kiểu này
Lãnh đạo có nói khéo đến đâu đi nữa, tôi cũng không định vị tha chia sẻ miễn phí việc tăng năng suất cá nhân của mình cho cả công ty
Nếu chỉ là công cụ hữu ích thì có thể tôi sẽ chia sẻ, nhưng các bí quyết học cách dùng AI hay cấu hình agent thì tốt hơn nên giữ cho riêng mình nếu không có sự ghi nhận tương xứng cho việc chia sẻ
Công ty tôi còn làm cả giải “prompt của tuần” và các buổi ăn trưa để thúc đẩy phổ biến áp dụng, thậm chí có đội chuyên phát triển những luồng này
Nhưng nếu không có thưởng tiền thật hoặc bảo đảm việc làm, thì rủi ro và chi phí của việc lan truyền kiến thức hoàn toàn đổ lên đầu lập trình viên
Từ rất lâu trước khi AI đạt mức như bây giờ, tôi đã tự làm CLI cá nhân để công việc dễ hơn và viết script tự động hóa
Đồng nghiệp thấy công cụ đó rồi bảo tôi chia sẻ, nhưng câu trả lời ngoại giao thực chất là từ chối
Chia sẻ xong thì phát sinh gánh nặng hỗ trợ, mọi người đều làm việc năng suất như tôi, và lợi thế của tôi biến mất — một kiểu lợi suất âm
Hơn nữa, lãnh đạo cũng chẳng công nhận sự sáng tạo của tôi là tài sản nên độ an toàn việc làm cũng không tăng
Đằng nào tương lai gần tôi cũng có thể bị sa thải, nên tôi không định giúp công ty chỉ vì thiện chí
Trong thị trường hiện tại, nếu lập trình viên đang lo lắng về công việc thì workflow cá nhân nên được xem như bí mật thương mại
Ví dụ này không chỉ giới hạn ở AI, nhưng với workflow AI thì áp dụng y hệt
Ở thị trường lao động nghiêng về phía người lao động, chia sẻ kiểu kiến thức đó với tổ chức đôi khi còn vui; nhưng ở thị trường nghiêng về phía chủ lao động, nếu muốn tiếp cận lựa chọn cá nhân của tôi thì phải trả tiền
Tôi không phải kiểu xem công ty là gia đình, nhưng sẽ tốt hơn nếu mọi người có thể cùng làm tốt và chia sẻ với nhau mà không phải lo mình đang tự đào mồ chôn mình
Đa số mọi người được trả lương để làm việc, và trong giờ làm thì đương nhiên phải làm việc cho chủ lao động
Thực ra hiếm có thứ gì quá ghê gớm đến mức người khác không thể tự nghĩ ra
Theo kinh nghiệm của tôi, dù có chia sẻ prompt hay kỹ thuật thì cũng rất ít người dùng, hoặc nó quá cơ bản đến mức ai cũng đã có phiên bản riêng rồi
Ngay cả trước AI, nếu ai đó đã không quan tâm đến xyz thì kể cả bày ra tận nơi sau thời AI họ cũng chẳng tự nhiên quan tâm hơn
Những việc nhàm chán gần như biến mất, có vấn đề thì cứ quăng sang một bên là nó tự được xử lý, và mỗi ngày lấy lại được 1–4 tiếng
Liệu người đó có hợp lý đến mức dùng khoảng thời gian ấy để tự đi tìm thêm việc mà làm không? Trừ khi đó là công ty của chính họ hoặc họ có động lực đặc biệt, khả năng đó khá thấp
Là một nhà phân tích hệ thống đã nghỉ hưu được 3 năm, tôi thấy thương cho các đồng nghiệp trẻ hơn
Năm 2023 tôi là một trong những người dùng AI sớm hơn trong nhóm, để gỡ một đống code legacy viết bằng Perl mà tác giả gốc đã rời đi từ lâu và gần như không để lại chú thích hay tài liệu
Đống code đó làm công việc quan trọng, AI đã kéo chúng tôi ra khỏi thế bí nên mọi người đều trầm trồ trước công nghệ mới này
Nhưng càng về sau nó càng giống thứ tác động lên tôi hơn là một công cụ tôi có thể dùng
Không ai thật sự yêu cầu điều này
Tôi không biết từ khi nào cảm hứng và tư duy lại bị xem nhẹ và trở nên vô giá trị dưới danh nghĩa xử lý mọi thứ ngay lập tức, công việc đã mất đi linh hồn
Bản thân AI thì không hữu ích đến thế
Hãy quên agent đi: chúng quên trước quên sau và mắc đủ lỗi khiến bạn phải kiểm tra mọi tác vụ, rốt cuộc còn có thể làm năng suất giảm đi
Giá trị thật chỉ xuất hiện khi xem AI như công cụ để tạo ra công cụ khác
Ví dụ bắt nó tạo ra công cụ buộc một nhiệm vụ phải tiếp tục chạy cho đến khi đạt chất lượng nhất định, hoặc chạy kiểm tra tuân thủ trên đầu ra để chỉ ra cần sửa chỗ nào
Lúc đó mới có thể tin vào công việc được
Hiện nay phần lớn vai trò và workflow được thiết kế theo kiểu dùng bộ công cụ sẵn có để hoàn thành một việc cụ thể, và trong hệ đó AI chỉ có thể chen vào ở rìa
Bài hay, và phần nổi bật nhất là chỗ nói cách tổ chức định nghĩa công việc đang thay đổi
Ở mô hình cũ, thành tích và OKR gắn với chuyên môn, chức danh và kỳ vọng theo vai trò
Trong kỷ nguyên AI, những ranh giới đó bắt đầu sụp đổ
Vấn đề sâu hơn là tâm lý và tổ chức: mọi người sẽ liên tục thương lượng ranh giới giữa “đây là việc của tôi” và “đây không phải trách nhiệm của tôi”
Từ đó nảy sinh vấn đề áp dụng cốt lõi: lợi ích của việc được công nhận rõ ràng là một người dùng AI thành thạo là gì?
Nếu công ty biết tôi có thể làm nhanh hơn, tốt hơn và xuyên nhiều chức năng hơn, thì vì sao tôi phải để lộ điều đó nếu không có một cơ chế rõ ràng về ghi nhận, thưởng và thăng tiến nghề nghiệp?
Trong một thế giới nơi agent đi qua đi lại giữa các ranh giới đó, mọi chuyện có thể sẽ rất lộn xộn
Một kỹ sư AI dẫn theo cả đàn agent liệu có chịu luôn trách nhiệm giữ mọi thứ vận hành hay không? Khá đáng nghi, nhưng cứ chờ xem
Chỉ cần ai đó bị hấp dẫn bởi nghề mới ấy rồi kết hợp vài tuần lời khuyên theo bối cảnh từng công ty với các cách làm mới nhất, cuối cùng người đó lại rơi đúng vào vai trò chuyên gia miền nghiệp vụ sẽ bị loại bỏ
Câu trả lời cho “ROI của 2 triệu euro trả cho Anthropic năm ngoái ở đâu?” là tấm biển token bạch kim phong cách YouTube treo trong văn phòng CEO
Thiên lệch trong giả định ngầm sau câu hỏi “ROI của 2 triệu euro trả cho Anthropic năm ngoái ở đâu?” thật sự rất lố bịch
Vấn đề là AI tạo sinh không tạo ra ROI nhìn thấy được
Nhưng “giải pháp” lại được đưa ra như thể phải tái cơ cấu cả tổ chức phát triển xoay quanh công nghệ đó rồi phát minh công cụ mới
Mục đích thật của các bài kiểu này không nằm ở bề mặt nội dung, mà ở việc bình thường hóa các giả định làm nền cho cuộc thảo luận ấy
Làm việc trong lĩnh vực này bây giờ thực sự rất tệ
Ở công ty tôi, sếp để cả những người không phải lập trình viên cũng dùng AI
Tôi thực sự muốn nghỉ và làm ở lĩnh vực khác, nhưng nơi tôi sống thì lương khởi điểm không đủ trả tiền thuê nhà, mà tôi cũng đang có tuổi hơn rồi
So sánh lời hứa của AI với bong bóng dot-com giúp tôi hiểu vấn đề hơn, và đúng là có nhiều điểm giống nhau
Nhưng với doanh nghiệp, internet là một khái niệm đơn giản hơn nhiều
Về cơ bản, nó chỉ có nghĩa là giờ đây người ta có thể mua đồ trên máy tính của mình
Còn lời hứa của AI là gì? Là có thể xấp xỉ việc suy luận về sự vật sao?
Đây là một bài toán triển khai thật sự khó hơn rất nhiều
Ngoài các tác vụ lập trình ra, tôi vẫn chưa thấy được thứ gì thực sự thiết thực