- AI tạo sinh cho phép tạo sinh xuyên lĩnh vực, nơi người không được đào tạo có thể tạo ra đầu ra thuộc một lĩnh vực chuyên môn khác, khiến người mới trông như đã tăng năng suất dù không có khả năng phán đoán để rà soát kết quả
- Tại nơi làm việc, số lượng đầu ra trông bề ngoài như có tiến triển — như mã nguồn, hệ thống dữ liệu, tài liệu — tăng lên, nhưng người dùng lại không thể giải thích cách chúng thực sự hoạt động, hoặc ngay từ schema và mục tiêu ban đầu đã đi sai hướng
- AI cắt đứt mối quan hệ trong đó chất lượng đầu ra từng phản ánh năng lực của người tạo ra nó, tạo nên sự tách rời giữa đầu ra và năng lực, và biến người dùng thành thứ gần giống một đường ống chỉ chuyển tiếp kết quả mà không đánh giá được nó
- Tài liệu nội bộ và các bản cập nhật trở nên dài hơn vì chi phí tạo ra giảm xuống, nhưng chi phí đọc không giảm, khiến việc tìm ra tín hiệu trong tổ chức khó hơn và tạo thành một dạng AI slop mới do những người đang hưởng lương tạo ra
- AI tạo sinh phù hợp với bản nháp, ví dụ, tóm tắt, brainstorming và hiệu đính — những việc mà con người vẫn là người phán đoán cuối cùng và có thể đưa phản hồi nhanh — còn năng lực cung cấp công việc đáng tin cậy vẫn là lợi thế cạnh tranh của doanh nghiệp
Vấn đề của đầu ra AI trông như năng suất công việc
- AI tạo sinh có thể tạo ra kết quả trông như đầu ra chuyên nghiệp dù không có chuyên môn, và thất bại xuất hiện dưới hai dạng
- Người mới trong một lĩnh vực tạo ra kết quả nhanh hơn khả năng phán đoán của chính họ hoặc trông tinh vi hơn mức họ có thể đánh giá
- Người chưa từng được đào tạo trong lĩnh vực đó lại tạo ra đầu ra của một lĩnh vực chuyên môn khác
- Các nghiên cứu trước đây chủ yếu đo lường dạng đầu tiên, nhưng điều nguy hiểm hơn là tạo sinh xuyên lĩnh vực, nơi người chưa được đào tạo tạo ra đầu ra của lĩnh vực khác
- Trên các kênh công khai, có những trường hợp đồng nghiệp dán nguyên câu trả lời trông như từ Claude và tỏ ra tự tin như thể họ hiểu một công nghệ mà thực tế họ không hề nắm được
- Trong tình huống như vậy, đối phương không thực sự đang ở phía bên kia của cuộc đối thoại, mà hoạt động như một thực thể chỉ chuyển tiếp đầu ra của mô hình
Tạo sinh xuyên lĩnh vực
- Đã xuất hiện những tình huống người không biết lập trình lại làm phần mềm, và người chưa từng thiết kế hệ thống dữ liệu lại đi thiết kế hệ thống dữ liệu
- Phần lớn không được phát hành, nhưng được chia sẻ đầy hào hứng trong nội bộ hoặc âm thầm sử dụng, đôi khi còn lộ ra với khách hàng
- Hiện vẫn có một số người làm thực tế dùng công cụ dạng agent để xử lý đúng các việc phức tạp, nhưng rất hiếm và chủ yếu thấy ở mảng sinh mã
- Năng lực AI ở cấp cá nhân đã tăng lên, nhưng trong môi trường làm việc thì chưa mở rộng được đúng cách
- Một đồng nghiệp ở vị trí không thuộc kỹ thuật đã dành hai tháng đầu năm để xây dựng một hệ thống lẽ ra phải do người được đào tạo bài bản về kiến trúc dữ liệu thiết kế
- Theo tiêu chí đánh giá việc dùng công cụ AI hiện nay, anh ấy dùng công cụ khá tốt, tạo ra nhiều mã nguồn, tài liệu và các đầu ra bề ngoài trông như có tiến triển
- Nhưng khi bị hỏi, anh ấy không thể giải thích hệ thống thực sự hoạt động như thế nào
- Schema và mục tiêu đã sai ngay từ ngày đầu tiên, ở mức mà người có 2 năm kinh nghiệm trong lĩnh vực đó cũng có thể nhận ra
- Nhiều người biết chuyện này và thông tin đã lên tới cấp V.P., nhưng quản lý đã đầu tư vào vẻ ngoài của đà tiến nên không muốn làm nó chệch hướng
- Công cụ này không biến anh ấy thành một đồng nghiệp tệ hơn, mà cho phép anh ấy bắt chước một cách có vẻ thuyết phục một lĩnh vực chưa được đào tạo trong suốt vài tháng
- Các động lực trong tổ chức nghiêng về phía để màn bắt chước đó tiếp tục
- Có thể đây là thất bại trong quản trị, nhưng ý chí của cấp quản lý muốn đón nhận AI đã khiến họ chấp nhận rủi ro
- Nếu mô hình đánh giá trung thực về đầu ra thì có thể giảm bớt phần nào, nhưng thực tế không phải vậy
- Kết quả là người mới có thể tăng năng suất cá nhân ở những lĩnh vực ngoài chuyên môn của mình, nhưng lại thiếu năng lực để rà soát xem đầu ra đó có đúng hay không
Vấn đề đường ống
- Hiện tượng này ngày càng được gọi là sự tách rời giữa đầu ra và năng lực (output-competence decoupling)
- Trước đây, chất lượng đầu ra nhìn chung là tín hiệu phản ánh năng lực của người tạo ra nó
- Bài viết của người mới nghe giống người mới, và mã nguồn của người mới sẽ thất bại theo những cách rất đặc trưng của người mới
- AI cắt đứt mối quan hệ này, cho phép người mới tạo ra đầu ra không còn bộc lộ rằng họ là người mới
- Năng lực mà đầu ra phản ánh không phải năng lực của người dùng, mà là năng lực của hệ thống
- Người dùng có thể chuyển kết quả cho người nhận, nhưng gần giống một đường ống không thể đánh giá thứ mình đang chuyển đi
- Năng lực tạo ra đầu ra và năng lực phán đoán vốn dĩ luôn là hai việc khác nhau, nhưng quá trình tự tay làm việc trước đây đã bồi đắp khả năng phán đoán
- Năng lực thứ nhất là tạo đầu ra nay phần lớn đã được chuyển cho máy móc
- Năng lực thứ hai là phán đoán vẫn còn ở con người, nhưng số người muốn học hoặc sử dụng nó đang giảm đi
- Trước đây, những lời phê bình kiến trúc thường đến từ người đã được đào tạo hoặc đã nhiều lần tự xây rồi làm hỏng những hệ thống tương tự
- Giờ đây, những phê bình như thế lại đến từ mô hình không có ký ức nhập thân về việc từng xây hay từng làm hỏng
- Sự chậm rãi không chỉ là chi phí bám vào công việc thực tế, mà chính là quá trình giúp công việc tốt hơn, con người trở nên lành nghề hơn và công ty có thể hứa với khách hàng về một mức chất lượng nhất định
- Thế hệ hệ thống dạng agent hiện tại được thiết kế xoay quanh giả định rằng con người là nút thắt cổ chai
- Giả định là càng ít độ trễ do con người đọc và phán đoán điều sắp xảy ra, vòng lặp sẽ càng nhanh và sạch
- Trong nhiều trường hợp, điều này lại hoàn toàn ngược lại: con người trong vòng lặp không phải tàn dư của quá khứ, mà là thành phần duy nhất có quyền lợi gắn với kết quả
- Loại bỏ con người khỏi HITL không phải là tối ưu hóa hiệu quả, mà là từ bỏ cơ chế duy nhất giúp hệ thống tự phát hiện sai sót của chính nó
AI slop ở bên trong tổ chức
- Tài liệu công việc đang dài ra rất nhanh
- Tài liệu yêu cầu từng dài một trang nay thành 12 trang
- Bản cập nhật trạng thái từng chỉ ba câu nay thành tài liệu gồm các bullet là bản tóm tắt của bản tóm tắt
- Hồi cứu, báo cáo sự cố, ghi chú thiết kế, deck kickoff và mọi đầu ra có thể dài ra đều đang dài ra
- Chi phí sản xuất đã gần như về 0, nhưng chi phí đọc không giảm, thậm chí còn tăng
- Người đọc phải lọc bỏ bối cảnh tổng hợp để tìm ra tài liệu ban đầu thực sự muốn nói gì
- Quyết định kéo dài tài liệu của mỗi cá nhân trông có vẻ hợp lý và được thưởng một cách độc lập
- Theo Beyond the Steeper Curve: AI-Mediated Metacognitive Decoupling, người đọc cảm thấy tự tin hơn với những lời giải thích do AI tạo ra mà dài hơn, bất kể độ chính xác của chúng
- Kết quả là việc tìm tín hiệu trong nơi làm việc khó hơn trước nhiều
- Các checkpoint bị giấu bên trong tài liệu, và con người bị chôn vùi trong công việc giấy tờ ngay cả khi họ thực sự muốn làm mọi thứ “ngắn gọn”
- Đây là một dạng slop mới còn đắt đỏ hơn AI slop lan ra thị trường công khai
- Vì những người tạo ra nó đang được trả lương
- Công việc từng dạy cho con người khả năng phán đoán nay đã bị công cụ làm thay, còn các vai trò đầu vào nơi sự đào tạo đó từng diễn ra thì bị thu hẹp vì công cụ có thể làm việc
- Ở nhiều văn phòng, chuyển động thì rất nhiều nhưng kết quả thực chất mà kiểu chuyển động ngày xưa từng tạo ra thì ngày càng ít
- Thảo luận công khai chủ yếu tập trung vào AI slop chảy ra thị trường công khai, và Generative AI and the market for creative content của University of Florida cũng bàn về dòng chảy đó
- Nhưng cùng một động lực cũng xuất hiện bên trong tổ chức
- Thời gian đang bị dùng cho những việc vốn không cần AI, những đầu ra không ai đọc, và những quy trình chỉ tồn tại vì công cụ giúp tạo chúng quá rẻ
- Ngày càng có nhiều việc phải bung thành deck những điều trước đây thậm chí không cần nói ra hoặc được coi là đương nhiên
Cách ứng phó
- Kỷ luật cần thiết trong môi trường này lại gần với cách làm cũ
- Chỉ nên dùng công cụ ở nơi có thể xác minh chính xác kết quả mà nó tạo ra
- Không nên yêu cầu mô hình tự xác nhận
- Công cụ sẽ đồng ý với bất kỳ ai, và sự đồng ý không có chi phí gì cho phía đồng ý thì không có giá trị
- AI tạo sinh phù hợp nhất với những việc có phản hồi nhanh, đúng đại khái là đủ và con người vẫn là người phán đoán cuối cùng
- Soạn nháp ghi chú
- Tạo ví dụ
- Tóm tắt tài liệu mà người đọc có thể tự kiểm chứng nếu muốn
- Generative AI Guidance của University of Illinois và Ten simple rules for optimal and careful use of generative AI in science của PLOS Computational Biology khuyến nghị các cách dùng sau
-
Brainstorming
-
Hiệu đính
-
Tái cấu trúc ý tưởng của chính mình
-
Phát hiện mẫu trong dữ liệu mà bản thân đã hiểu rõ
- Trong mọi cách dùng được khuyến nghị, con người cung cấp sự phán đoán còn công cụ cung cấp thông lượng
- Đây là lập trường mạnh hơn cả việc chỉ đơn giản có con người trong vòng lặp
- Công cụ nên đứng ngoài công việc và chỉ đóng góp khi được mời, còn ngoài ra thì phải im lặng
- Điều này đi ngược lại hướng đi của nhiều hệ thống dạng agent hiện nay
- Với doanh nghiệp, năng lực cung cấp công việc đáng tin cậy vẫn là lợi thế cạnh tranh
- Càng nhiều đối thủ biến mình thành dây chuyền tạo nội dung và hy vọng khách hàng không nhận ra, giá trị của công việc đáng tin cậy càng tăng
- Vấn đề đã bắt đầu lộ rõ
- Deloitte đã hoàn lại một phần khoản phí 440.000 USD liên quan đến báo cáo cho chính phủ có chứa AI hallucination
- Vấn đề tiếp theo có thể là một hệ thống vận hành dựa trên đặc tả bị bịa ra, hoặc một kỹ sư cấp cao nhận ra rằng suốt một năm qua mình chỉ danh nghĩa rà soát những thứ mà bản thân không thể thực sự kiểm tra
- Các công ty làm việc tử tế có thể ở vị thế định giá được phần lao động đó
- Những công ty tự làm rỗng mình rồi sẽ nhận ra rằng chính phần bị họ rút bỏ ấy mới là thứ khách hàng từng trả tiền
- Việc hiểu sai và dùng sai AI ở nơi làm việc đang diễn ra tràn lan
- Chuyên môn đang chịu áp lực phải giao nhanh hơn, làm nhiều hơn, tích hợp công cụ sâu hơn và đừng cản đường những đồng nghiệp “làm được việc”
- Đầu ra chất đống, nhưng công việc thực chất thì không
- Ở đầu bên kia của những đầu ra đó, khách hàng có thể mở deliverable ra, đọc danh sách tóm tắt rồi chọn tự mình xem xét kỹ
1 bình luận
Ý kiến trên Hacker News
Tôi thực sự đồng cảm với hiện tượng đầu ra công việc bị dài dòng hóa, kiểu như tài liệu yêu cầu trước đây chỉ cần một trang thì giờ thành mười hai trang
Nó làm tôi nhớ đến thời cố tình viết dài ra để đạt mức tối thiểu 1000 từ cho bài luận trung học, và giờ thì định dạng chuyên nghiệp, độ dài, câu chữ rõ ràng không còn là tín hiệu của sự chăm chút và chất lượng nữa
Vì vậy, có vẻ nút thắt tăng năng suất hiện nay vẫn là những người còn đủ quan tâm để trực tiếp xem xét mọi thứ
Dạo này, ngay cả những tài liệu đặc tả dài 10–30 trang đầy định dạng và hình ASCII thực chất cũng rất có thể chỉ là ý tưởng nói cho có, nên cần phải tập quen với việc tiếp nhận chúng theo cách đó
Quản lý có lẽ sẽ dùng chatbot hoặc agent để tóm tắt và đánh giá thứ tôi gửi, nhưng chính tôi lại không được phép gửi sẵn bản tóm tắt đó
Cũng giống như trình kiểm tra ATS cho CV, giờ bài viết của tôi cũng sẽ cần một bộ kiểm tra AI, và cuối cùng sẽ thành AI viết để AI khác parse, một sự lãng phí năng lượng khổng lồ
Giá mà có những quy tắc, cấu trúc, tiêu chuẩn hay quy trình thống nhất nào đó để giao tiếp hiệu quả hơn
Chúng là kết quả của kiểu bài gì cũng kéo dài lê thê chỉ để leo top kết quả tìm kiếm
Người gửi mấy thứ đó đằng nào cũng sẽ không theo sát xác nhận tiếp, nên vấn đề tự nó biến mất
Tình huống được mô tả ở đây cũng rất giống trải nghiệm của tôi
Công ty tôi có nhiều quản lý đã không viết code suốt nhiều năm, và vị kiến trúc sư được tuyển 18 tháng trước đã dùng AI để thiết kế mọi thứ
Với các senior developer thì rõ ràng mọi thứ bị over-engineer nặng nề, nhưng vì ông ta dùng đúng toàn bộ thuật ngữ nên với lãnh đạo cấp trên lại trông có vẻ giỏi hơn các senior manager khác, và khi bị chỉ ra thì đáp lại bằng công kích cá nhân
Khoảng 6 tháng sau nhiều người đã rời đi, những người ở lại thì all-in vào AI, và suốt 12 tháng qua đang xây quy trình làm việc kiểu agent để lấp chỗ trống do những nhân sự giỏi bỏ đi
Kết quả là trong 18 tháng qua chẳng có gì có giá trị được phát hành, sau khi đốt rất nhiều chi phí cloud computing vào các giải pháp thiết kế sai thì giờ họ đang cắt giảm chi phí bằng cách đóng băng tuyển dụng
Khi tính kinh tế thay đổi lớn, nó gần như giống như tháo bỏ con đập, khiến phần còn lại của hệ thống chịu áp lực lớn hơn rất nhiều
Nếu lãnh đạo tổ chức không nhìn ra các tác dụng phụ và rủi ro tiềm ẩn đó thì có thể bị tổn thương nặng
Dù công nghệ này được bán như một cải tiến phổ quát, tôi nghĩ sắp tới sẽ thấy hàng loạt công ty kiểu này tăng vọt rồi lao dốc
Những công ty sống sót sẽ truyền bá cách thuần hóa con ngựa hoang này, và lý tưởng nhất là tương lai chúng ta sẽ học được điều gì đó
Chỉ là sự hưng phấn ngây thơ hiện nay thật đáng kinh ngạc, và Tháng Chín bất tận với dòng người quá khích vì mới có năng lực vibe coding sẽ còn kéo dài một thời gian
Cách đây hai công ty thì vibe coding còn chưa thực sự khả dụng, nhưng một số người đã quá mải mê dùng LLM để thổi phồng mọi thứ đến mức khó mà nhận được câu trả lời có/không cho bất kỳ câu hỏi nào
Một câu hỏi một dòng trên Slack, mất 20 giây để đọc, thì thứ trả về lại là bài blog mơ hồ dài hai trang không có kết luận, và hỏi tiếp chỉ càng tốn thời gian hơn
Ở chỗ làm gần nhất, tôi thấy PM dần trở thành quản lý vibe của các vibe coder
Họ chen vào thảo luận kỹ thuật và dùng AI để chỉ đạo hướng đi ở mọi bước, và khi chúng tôi phản biện thì hóa ra là đang vật lộn với kết quả AI được “dịch” bởi một người không hiểu chủ đề, cực kỳ mệt mỏi
Phản đối cũng không còn được chấp nhận nữa, và còn bị gây áp lực kiểu như AI đang đe dọa công việc của chúng tôi
Sau đó họ bắt buộc tất cả mọi người phải vibe code và còn theo dõi cả số lượng, còn PM đó thì vừa làm PM, vừa làm engineer, vừa làm architect nên tạo ra nhiều ticket cho cùng một việc với những yêu cầu hoàn toàn khác nhau
Thế là một thành viên trong nhóm vibe code theo một kiểu, người khác lại triển khai theo kiểu khác
Thật khó chịu khi nhìn một nhóm 20 người từng tạo gần 100 triệu USD lợi nhuận mỗi năm bị phá hỏng bởi những công việc vô dụng và vô nghĩa, nên cuối cùng tôi đã rời đi
Tôi cố không trở nên cay độc trước những thay đổi này trong ngành phần mềm, nhưng thật sự rất khó
Quản lý dùng Claude để đưa ra lời khuyên và đề xuất kiểu chuyên gia trong khi hiểu chưa đầy đủ về domain, còn nhiều nhân sự phi kỹ thuật trong công ty thì xây các công cụ phần mềm nội bộ để triển khai toàn tổ chức và cố dùng các bản demo đó để giành sự công nhận và tưởng thưởng
Lãnh đạo đúng như dự đoán đã bị ấn tượng bởi các proof of concept như vậy và phê duyệt chúng
Những đồng nghiệp hoạt động quá mức thì trình diễn các bản demo trông như chuyên gia dù hoàn toàn không hiểu bên trong, và ban lãnh đạo chấp nhận điều đó
Tôi không biết diễn đạt vấn đề này thế nào, nhưng bài viết này đã chỉ ra rất đúng
Tất nhiên, có AI thì còn giúp làm ra ít hơn nữa
Nghe đúng là một môi trường cực độc hại
Những nhóm hiệu quả nhất trong việc dùng LLM để tạo phần mềm chất lượng cao có lẽ sẽ dùng nó theo các cách như thế này
Tự động hoàn thành thông minh là cách dùng LLM nguyên bản, nơi code được sinh ra vẫn giữ được ngữ cảnh của phần code mà developer đang làm và hoạt động như phần nối dài của quá trình tư duy, chứ không phải thuê ngoài việc suy nghĩ cho LLM
Trong brainstorming, nó có thể mở rộng các khái niệm, ý tưởng, định hướng còn mơ hồ để kích thích sáng tạo
Trong giải quyết vấn đề, nó khá hữu ích khi debug những thứ như xung đột package, exception ngẫu nhiên, bug report, và có thể giúp lần ra nguyên nhân gốc khi không có đồng nghiệp ngồi cạnh
Trong code review, đôi khi nó bắt được một vài thứ con người bỏ sót nên giống một bước lint thông minh hơn, nhưng không thay thế được code review của con người
Trong proof of concept, nó có thể tạo ra nhiều cách tiếp cận khác nhau cho một vấn đề để làm nguồn cảm hứng cho lời giải được xây dựng cẩn thận hơn
Những cách dùng này tăng tốc phát triển nhưng vẫn giữ trách nhiệm rằng developer phải hiểu mình đang làm gì và tại sao
Ngược lại, các nhóm all-in vào agentic coding có vẻ rất dễ vô tình làm hỏng sản phẩm và cả đội ngũ về lâu dài
Mấy lần gần đây tôi hỏi thì kết quả hoàn toàn có vẻ hợp lý nhưng lại sai hoàn toàn, thậm chí còn lạc cả chủ đề
Trong code review thì false positive quá áp đảo, và tôi cũng không thấy lý do gì để tin chuyện đó sẽ khá hơn
Dù vậy, vẫn có khả năng nó sẽ hữu ích theo hướng này
Cá nhân tôi đã tắt nó khoảng một năm trước và quay về tự động hoàn thành truyền thống của JetBrains IDE
Theo trải nghiệm của tôi, chưa đến 1% gợi ý AI đoán đúng chính xác điều tôi muốn, khoảng 10% là hữu ích, còn lại thì hoặc sai hoặc gây phiền
Các tính năng IDE tiêu chuẩn giúp tìm kiếm và điều hướng nhanh method, variable, v.v. hữu ích hơn nhiều trong việc chuyển suy nghĩ thành code
Nhóm tôi cũng đã thử vài công cụ, nhưng phần lớn những gì chúng chỉ ra đều rất hời hợt hoặc không phải vấn đề
Khi review code của thành viên kém năng lực hơn thì chúng lại bỏ lỡ các vấn đề sâu hơn, còn reviewer con người thì bắt được những thay đổi sai cho những vấn đề vốn có thể giải quyết tốt hơn
Quản lý lại dùng kết quả đó như bằng chứng xác nhận thiên kiến của họ rằng chúng tôi không biết mình đang làm gì
Họ copy đầu ra đầy emoji của công cụ code review vào comment PR, và khi chúng tôi sửa các vấn đề nhỏ thì lại đăng “vòng code review 2”
Tinh thần xuống rất mạnh và vài thành viên trong nhóm bỏ luôn việc review mà chỉ approve PR cho xong
Tôi thấy nó ổn nếu dùng để tự kiểm tra code của mình, nhưng không nên trở thành ràng buộc bắt buộc của quy trình
Mục đích ban đầu của code review là đầu tư thời gian để giúp nhau cùng tốt hơn, và khi thuê ngoài việc đó cho máy móc thì khế ước xã hội trong nhóm sẽ sụp đổ
Hai năm trước người ta còn bảo đó chỉ là tự động hoàn thành thuần túy cộng với Google tốt hơn
Những người bi quan về AI năm nào cũng sai nhưng lại làm như chưa từng nói rằng AI sẽ không bao giờ làm được những gì nó đang làm hiện tại
Software engineering có vẻ đặc biệt dễ xảy ra chuyện này vì vài lý do
Nhiều software engineer suốt sự nghiệp chưa từng làm kỹ thuật thực sự, và ở các công ty lớn thì còn nặng hơn
Họ vào làm như một bánh răng nhỏ trong cỗ máy lớn, học một ngôn ngữ cấu hình do ai đó tạo ra để được thăng chức, dọn dẹp và refactor cấu hình đó, rồi “sửa” đầu ra của một framework nội bộ khác bằng cách chỉnh các núm cấu hình, và 5 năm sau vẫn làm đúng việc ấy
Trong ngành cũng có nhiều vai trò bán kỹ thuật
Những người thích làm việc với con người nên bỏ code, hay bị mê hoặc bởi sản phẩm và công việc của người dùng, lấp đầy các vị trí .*M ở cả công ty lớn lẫn nhỏ
Ở công ty lớn, con tàu chạy chậm đến mức phải mất nhiều tháng để một commit vào production, và 6 tháng là chuyện thường
Trong nhiều hệ thống lớn và quan trọng, code kiểu agent thậm chí còn chưa chạm tới production
Vì vậy AI thay thế một số công việc hữu danh vô thực, những người ở quanh code bỗng bắt đầu tận hưởng vibe coding, còn ở các công ty vận hành chậm thì hậu quả của những sản phẩm đó vẫn chưa phát nổ
Nhìn từ bên ngoài, nó giống như một cơn bùng nổ năng suất
Đoạn “người không biết viết code thì xây phần mềm, người chưa từng thiết kế hệ thống dữ liệu thì thiết kế hệ thống dữ liệu” làm tôi nhớ đến bài “cách phát hành dự án ở các công ty công nghệ lớn”
Đặc biệt là đoạn “ra mắt là một cấu trúc xã hội bên trong công ty. Cụ thể là, dự án được xem là đã ra mắt khi những người quan trọng trong công ty tin rằng nó đã ra mắt”
https://news.ycombinator.com/item?id=42111031
Đó là một bài hay, và cũng dẫn đến thảo luận khá tốt về việc giữ bề ngoài và chuyện được nhìn nhận luôn quan trọng, thậm chí thường còn quan trọng hơn ta nghĩ rất nhiều
Tôi nhận ra rằng ở giai đoạn đầu đưa AI vào nơi làm việc, một vài đồng nghiệp đã dùng công nghệ này để thể hiện sự chủ động quá mức
Mỗi tuần lại có TOD mới, ý tưởng refactor mới, cách giải quyết vấn đề cũ bằng thuật toán mới sáng bóng
Giờ hiện tượng này còn lớn gấp đôi, vì nỗ lực trông năng nổ hơn lại kết hợp với nỗi sợ bị AI sa thải, nên họ tạo ra giải pháp ngay cả trước khi vấn đề được xác định đầy đủ
Ví dụ, tôi được giao điều tra một vấn đề kiến trúc cụ thể trên toàn công ty và nghĩ rằng nếu đưa ra giải pháp chắc chắn thì sẽ được ghi nhận, nhưng đã quá muộn
Một thực tập sinh đã tìm ra “giải pháp” và viết TOD rồi, còn giờ tôi thì quá kiệt sức để cạnh tranh
Hôm qua tôi dành phần lớn thời gian để xóa và thay thế đoạn code do LLM sinh ra
Phần lớn thời gian thì sự trợ giúp của LLM là tốt, nhưng lần này nó tung ra cả đống mã luồng điên rồ và ứng dụng của tôi bắt đầu crash lần đầu tiên sau nhiều năm
Ứng dụng của tôi không crash
Nó có thể có nhiều vấn đề khác, nhưng crash không phải một trong số đó, và tôi là kiểu người rất dai
Theo kinh nghiệm của tôi, gần như chẳng bao giờ cần dispatch sang thread mới
Tôi thường để OS SDK tự làm điều đó và tôn trọng lựa chọn ấy, còn việc tự bật worker thread thì hiếm khi đem lại lợi ích lớn hơn nỗi đau debug
Điều này có thể không đúng với mọi loại ứng dụng, nhưng đúng với ứng dụng tôi đang viết
LLM rất thích thread, có lẽ vì trong dữ liệu huấn luyện có nhiều code do những người quá khích mê công nghệ bóng bẩy đăng lên
Cuối cùng tôi cắt bỏ code phần màn hình đó và tự viết lại thì hiệu năng cải thiện rõ rệt và crash cũng dừng hẳn
Bài học là người mua tự chịu trách nhiệm
Tôi đồng cảm với đoạn nói rằng phải cân nhắc xem có nên tranh luận với người mà rõ ràng đang copy-paste trực tiếp từ model hay không
Tôi từng thấy một niềm vui nhỏ khi đáp trả những người đó bằng đúng cách họ dùng
Tức là dán đầu ra AI của họ vào AI của tôi, rồi lại dán câu trả lời AI của tôi trở lại
Hai con người cư xử như máy móc để hai cỗ máy đóng cosplay giao tiếp như con người
Phải nói là ngoạn mục
Tôi chỉ hỏi đơn giản về định hướng senior của mình rằng vì sao với proof of concept giữa bạn bè thì nên phát hành nhanh bằng Vercel thay vì over-engineer bằng AWS, còn cậu ấy gửi lại một biểu đồ tạp pí lù do AI tạo ra
Cậu ta quá bị đóng khung trong việc anh mình dùng AWS và bản thân cũng muốn theo sự nghiệp đó, nên thay vì tự nghĩ vì sao cách đó lại đúng cho một proof of concept giữa bạn bè, cậu ấy thuê ngoài suy nghĩ cho AI
Khi cậu ấy hỏi tôi có đọc không, tôi bảo là tôi đã dùng AI để tóm tắt và đọc rồi nhưng không trả lời, và cuộc trò chuyện kết thúc rất nhanh
Ý “không giúp được chuyên gia” thì hơi thiển cận
Dù giỏi đến đâu thì ai cũng có những mảng yếu hoặc những mảng nhàm chán có thể tự động hóa
Với tôi, thứ từng là điểm nghẽn trong sự nghiệp trước đây là việc sắp xếp nhiều đầu việc cùng lúc, truyền đạt thay đổi hiệu quả trên toàn tổ chức, và xử lý tài liệu cùng quản lý ticket trên các hệ thống như Jira
Giờ thì đó không còn là nỗi lo nữa, và mức tăng hiệu quả ở phần này là rất lớn
Trong công việc cốt lõi mà tôi giỏi nhất thì ngoài chuyện gõ nhanh hơn rất nhiều, nó không giúp quá nhiều, nhưng như vậy cũng đã khá tốt
Nếu giao cho tôi việc tôi không quen, nó thường làm tốt hơn tôi hoặc ít nhất dẫn tôi đến hướng có thêm thông tin để ra quyết định
Tôi đồng ý với câu “đừng yêu cầu model tự kiểm tra. Công cụ luôn đồng ý với mọi người”
Nếu tôi tùy ý nói có gì đó sai, LLM sẽ bằng cách nào đó tìm ra lỗi ngay cả trong đoạn code mà tôi biết là đúng
Vấn đề là LLM thường tiếp nhận quá sát mặt chữ
Ngay cả khi bắt nó lập kế hoạch, LLM cũng chưa từng thành công trong việc tự chủ thiết kế toàn bộ hệ thống
Nếu để LLM viết code rồi hỏi lại theo nhiều cách xem nó có đúng không, thì khá thường xuyên nó lại tìm ra vấn đề thật