- Càng tạo ra đầu ra có vẻ thuyết phục nhanh, càng dễ lặp lại một cách thiếu hiểu biết; nếu bỏ qua việc rèn luyện năng lực phán đoán thì năng lực dài hạn sẽ suy yếu
- AI rất hữu ích trong những mẫu quen thuộc, nhưng với vấn đề lạ, điều kiện mơ hồ, thông tin không đầy đủ và các ràng buộc xung đột, sự bắt chước hời hợt sẽ dễ sụp đổ và năng lực thực sự sẽ lộ ra
- Kỹ sư giỏi giao cho AI các công việc mang tính cơ học như boilerplate, tóm tắt, dựng khung kiểm thử, tăng tốc nghiên cứu; nhưng vẫn tự mình chịu trách nhiệm cho việc định nghĩa vấn đề, rà soát, lựa chọn và loại bỏ
- Giá trị cao nhất của kỹ nghệ phần mềm không nằm ở việc sản xuất code mà ở khả năng phán đoán; khả năng nhìn ra các ràng buộc ẩn, nhận ra mình đang giải sai vấn đề và biến tranh luận mơ hồ thành các trade-off ngày càng quan trọng hơn
- Đặc biệt ở giai đoạn đầu sự nghiệp và trong vận hành tổ chức, tiêu chuẩn để bảo vệ sự hiểu biết thực chất càng quan trọng hơn; càng phân biệt rõ thứ gì nên ủy quyền và thứ gì phải tự làm, AI càng trở thành công cụ nâng cao giá trị con người
Các kiểu thất bại khi thuê ngoài tư duy
- A.I. xử lý rất nhanh các việc như sinh code, tóm tắt cuộc họp, giải thích khái niệm, viết nháp thiết kế, soạn cập nhật trạng thái; nhưng nó cũng dễ tạo ra thói quen chỉ đưa ra kết quả có vẻ hợp lý mà không có hiểu biết
- Nếu lặp lại câu trả lời do máy tạo ra như thể đó là sự hiểu biết của chính mình, bạn sẽ chỉ bắt chước trạng thái trông có năng lực mà không thực sự xây dựng năng lực
- Càng dùng đầu ra được tạo ra để thay thế hiểu biết của bản thân, bạn càng bỏ qua việc rèn luyện khả năng phán đoán và đánh đổi năng lực dài hạn lấy vẻ ngoài ngắn hạn
- Trong những tình huống không thể xử lý bằng template như vấn đề lạ, điều kiện mơ hồ, thông tin không đầy đủ hay các ràng buộc xung đột, sự bắt chước hời hợt sẽ nhanh chóng sụp đổ
-
Phép ví von chép đáp án bài thi
- Bạn có thể chép đáp án để giữ điểm số tốt, nhưng khi bước vào tình huống thực sự đòi hỏi sự hiểu biết, nền tảng trống rỗng sẽ lộ ra
- Nếu không có trực giác được tích lũy qua việc tự mình làm, sẽ rất khó suy luận về vấn đề không quen thuộc hoặc thích ứng khi điều kiện thay đổi
- Cứ lặp đi lặp lại việc mang đáp án AI đưa ra đi dùng thì bạn chỉ đang mượn vẻ ngoài của sự thành thạo, chứ không tích lũy được tay nghề thật sự
-
Phép ví von máy tính cầm tay
- Máy tính cầm tay là công cụ tốt giúp tiết kiệm thời gian, nhưng nếu phụ thuộc vào nó mà không có cảm nhận về con số, bạn sẽ không còn khả năng kiểm tra xem kết quả có hợp lý hay không
- Kỹ sư có nền tảng sẽ rà soát đầu ra của AI, lọc lỗi, chỉnh sửa hoặc loại bỏ nó
- Kỹ sư không có nền tảng thì không phải đang dùng A.I. mà đang bị A.I. kéo đi, và điều này còn nguy hiểm hơn trong những công việc coi trọng độ chính xác và trách nhiệm với kết quả
-
Phép ví von xe tự lái
- Xe tự lái giúp giảm mệt mỏi và xử lý các tình huống thường ngày, nhưng nếu phụ thuộc vào nó trước khi hiểu cách lái xe, bạn sẽ gần như chỉ là hành khách có quyền điều khiển
- Trong các tình huống phi tiêu chuẩn như tầm nhìn kém, đường sá phức tạp, phương tiện khác khó đoán, hệ thống thất bại hay nguy hiểm bất ngờ, năng lực thực sự sẽ lộ ra
- A.I. cũng mạnh với các mẫu phổ biến và cấu trúc quen thuộc, nhưng kỹ nghệ phần mềm liên tục lệch khỏi điều đó với thay đổi yêu cầu, lỗi tinh vi, quyền sở hữu không rõ ràng, mục tiêu kiến trúc cạnh tranh, dữ liệu thiếu, ma sát tổ chức và những trade-off không có đáp án hoàn hảo
Cách kỹ sư xuất sắc dùng A.I.
- Kỹ sư xuất sắc không phải dùng A.I. ít hơn mà là dùng tích cực hơn, nhưng không giao phó luôn việc tư duy
- Họ sẵn sàng giao các công việc mang tính cơ học như viết boilerplate, tóm tắt tài liệu, tạo scaffolding kiểm thử, đề xuất refactor, khám phá khả năng thất bại, tăng tốc nghiên cứu và nén các tác vụ lặp lại
- Nhưng đổi lại, họ tạo ra những câu hỏi sắc bén hơn, định nghĩa vấn đề thực sự chứ không chỉ yêu cầu trước mắt, và ưu tiên sự rõ ràng và ngắn gọn hơn là câu chữ mượt mà nhưng rỗng nghĩa
- Họ không chỉ tái tổ hợp tri thức sẵn có trong hệ thống mà còn tạo ra tri thức mới có giá trị cao
- Và họ đầu tư lại quãng thời gian giành được đó vào tư duy và phán đoán ở cấp độ cao hơn
Nguồn gốc thực sự của giá trị
- Từ lâu người ta đã đồng nhất kỹ nghệ phần mềm với sản xuất code, nhưng giá trị cao nhất không nằm ở đó
- Nếu cốt lõi chỉ là tạo ra code đúng cú pháp thì A.I. hẳn đã trực tiếp thay thế phần lớn công việc; nhưng trọng tâm thực sự nằm ở khả năng phán đoán
- Kỹ sư có giá trị là người nhìn ra các ràng buộc ẩn trước khi chúng gây sự cố, nhận ra cả đội đang giải sai vấn đề, biến tranh luận mơ hồ thành các trade-off rõ nét, tìm ra lớp trừu tượng còn thiếu, và không debug code mà debug thực tại
- A.I. có thể hỗ trợ các công việc đó, nhưng không thể gánh thay chúng
- Trong tương lai, những kỹ sư tạo ra giá trị lớn hơn sẽ là những người tạo nên nguyên tắc thiết kế, hiểu biết miền, pattern, ngữ cảnh và framework ra quyết định để AI trở nên hữu dụng hơn
- Trong môi trường này, thay vì bị A.I. thay thế, kỹ sư sẽ có đòn bẩy lớn hơn khi làm việc ở tầng phía trên đầu ra thô
Rủi ro lớn hơn với kỹ sư đầu sự nghiệp
- Vấn đề này đặc biệt quan trọng với những người mới ở giai đoạn đầu sự nghiệp
- Vài năm đầu là giai đoạn hình thành các năng lực nền tảng như cảm giác debug, trực giác hệ thống, sự chính xác, gu nghề, khả năng rà soát hoài nghi, năng lực phân rã vấn đề và khả năng giải thích vì sao thứ gì đó hoạt động
- Những năng lực này được tích lũy qua ma sát, thử và sai, sửa lỗi, truy vết nguyên nhân gốc rễ và những lần va chạm với thực tế rồi bị thực tế bẻ gãy
- Nếu trong quá trình học, A.I. loại bỏ mọi khó khăn, bạn có thể được hiệu quả ngắn hạn nhưng lại bỏ qua giai đoạn tôi luyện năng lực
- Có thể bạn trông hiệu quả trong một hai quý, nhưng lại âm thầm đánh mất năng lực sẽ nâng đỡ tương lai của mình
- Hệ thống hỗ trợ có thể khiến bạn trông như đang làm việc ổn, nhưng không thể thay bạn tạo ra năng lực thực sự
Không có đường tắt tới khả năng phán đoán
- Chỉ đọc các lời giải thích được sinh ra không thể khiến sự thành thạo tự chuyển vào đầu bạn nếu bạn không tự mình làm việc
- Không có con đường nào mà sau khi thuê ngoài suy luận trong thời gian dài, bạn vẫn có được năng lực suy luận mạnh mẽ
- Có thể và nên thuê ngoài các công việc cơ học, tăng tốc nghiên cứu và nén các tác vụ lặp lại
- Nhưng bạn không thể bỏ qua chính quá trình hình thành kỹ năng mà vẫn trở thành người sở hữu kỹ năng đó
- Sai lầm cốt lõi của cách dùng A.I. ngây thơ nhất là tưởng mình đang tiết kiệm thời gian, trong khi thực ra chỉ đang hoãn lại hóa đơn của khả năng phán đoán yếu, hiểu biết nông và năng lực thích ứng thấp
Ranh giới phân định và hàm ý ở cấp tổ chức
- Nếu A.I. giúp bạn tạo ra hiểu biết nhanh hơn, suy nghĩ sâu hơn và làm việc ở cấp độ cao hơn, thì giá trị con người tăng lên
- Nếu A.I. giúp bạn né tránh hiểu biết, né tránh khó khăn và né tránh quyền sở hữu đối với suy luận, thì giá trị con người giảm đi
- Một con đường tích lũy như lãi kép, còn con đường kia sẽ rút ruột bên trong và đẩy bạn về trạng thái dễ trở nên không còn liên quan
- Tương lai sẽ ưu ái những kỹ sư không chỉ đơn giản là dùng A.I., mà biết phân biệt chính xác điều gì nên ủy quyền và điều gì phải tự mình sở hữu, rồi biến thời gian tiết kiệm được thành tư duy tốt hơn
Vì sao điều này tác động mạnh hơn tới sức khỏe tổ chức
- Quản lý kỹ thuật cũng đứng trước chính ranh giới đó: phân biệt giữa việc sử dụng để tăng tốc hiểu biết và việc sử dụng để bắt chước hiểu biết
- Lãnh đạo mạnh phải phân biệt được giữa đầu ra trơn tru và khả năng phán đoán thực sự; nếu chỉ thưởng cho tốc độ, độ lưu loát và khả năng trình bày thì sẽ bỏ lỡ các tín hiệu của chiều sâu kỹ thuật
- Khi công việc có mức hiểu biết thấp nhưng độ lưu loát cao lan rộng, không chỉ chất lượng đầu ra cá nhân giảm mà chính môi trường tri thức của tổ chức cũng suy yếu
- Việc review sẽ yếu đi
- Thảo luận thiết kế sẽ nông hơn
- Tài liệu sẽ mượt hơn nhưng kém hữu ích hơn
- Theo thời gian, tổ chức sẽ mất dần năng lực tạo ra sự rõ ràng và phán đoán kỹ thuật mà chính nó đang phụ thuộc vào
- Vì vậy, điều cốt lõi không phải là bản thân việc đưa công cụ A.I. vào, mà là bảo vệ những điều kiện để tư duy thật, học tập thật và tay nghề thật có thể sống sót
- Ngay từ khâu tuyển dụng cũng cần có cách phân biệt sự hiểu biết thực chất chứ không phải vẻ ngoài lưu loát
- Phỏng vấn phải kiểm tra quá trình suy luận hơn là polished answer
- Đánh giá phải tưởng thưởng sự rõ ràng, chiều sâu, phán đoán lành mạnh và đóng góp kỹ thuật bền lâu hơn là sản lượng đầu ra
- Điều này cũng ảnh hưởng lớn tới thiết kế đội nhóm và văn hóa
- Không nên để kỹ sư giỏi phải dành quá nhiều thời gian dọn dẹp công việc có vẻ thuyết phục nhưng hời hợt do những người thuê ngoài tư duy tạo ra
- Nếu không ngăn được điều đó, người có hiệu suất cao sẽ bị bào mòn như bộ khuếch đại cho tất cả mọi người khác, và kết cục rất dễ dẫn tới thất vọng, hạ thấp tiêu chuẩn và rời đi
- Chất lượng tổ chức trong thời đại A.I. rốt cuộc sẽ phụ thuộc nhiều hơn vào việc ban lãnh đạo có thể liên tục phân biệt giữa đòn bẩy và sự phụ thuộc, tăng tốc và bắt chước, năng lực thực sự và đầu ra có sức thuyết phục hay không
1 bình luận
Ý kiến trên Hacker News
Càng đọc đi đọc lại lập luận này, tôi càng thấy độ trau chuốt trong cách diễn đạt tốt lên rõ rệt, nhưng vẫn chưa tới mức của một cách ngôn
Để thành được những câu chỉ vài từ mà cắm thẳng vào đầu số đông như "the medium is the message", "you ship your org chart", hay "9 mothers can't make a baby in a month", thì phải mất nhiều năm, thậm chí hàng chục năm, để gọt bớt ý nghĩa
Mà chúng ta còn chưa biết cách xử lý việc hình thành ý nghĩa bằng RL, nên AI cũng không thể làm thay chuyện đó
Bản gốc đúng phải là "9 women can't make a baby in one month"
Học bằng cách tự tay làm. Câu này có vẻ gần với một cách ngôn hơn
Intelligence amplification, not artificial intelligence nghe khá ổn
Viết tắt lại thành IA, not AI, mà dịch sang tiếng Tây Ban Nha thì lại thành "AI, no IA", nên còn thú vị hơn
AI không thể sinh ra gu thẩm mỹ và khả năng phán đoán cho bạn
Nếu hỏi 100 người Mỹ câu cách ngôn này nghĩa là gì, có lẽ gần như chẳng ai nắm đúng ý gốc của McLuhan
Tôi nghĩ nhìn chung có hai cách dùng AI
Một là dùng nó để hỗ trợ viết thứ code mà tôi sở hữu và hiểu rõ, hai là dùng AI như một lớp trừu tượng hóa rồi giao luôn việc viết và bảo trì code cho nó
Cách sau ổn với những thứ sống ngắn như prototype, ví dụ mẫu, tài liệu tham chiếu, nơi tuổi thọ ngắn và chất lượng code hay mức độ hiểu của tôi không quá quan trọng
Vấn đề nảy sinh khi người ta mang cách 2 áp vào những việc thật ra cần 1, rồi tự lừa mình và lừa cả người khác
Trông thì nhanh và dễ, nhưng rốt cuộc là đem cả codebase đi cầm cố, và từ lúc đó năng lực của bạn cũng bắt đầu teo lại
Tính năng vẫn ra đều, bề ngoài vẫn ổn, nhưng đến lúc có gì đó nổ tung thì mới nhận ra rằng nếu không hỏi lại model, bạn còn chẳng debug nổi chính code của mình
Cũng có nhiều kỹ sư không thể làm việc nếu thiếu IDE hiện đại, ngôn ngữ có quản lý bộ nhớ, hay thư viện từ GitHub hoặc package manager
Nên với tôi, sự phụ thuộc vào AI không có vẻ khác biệt quá bản chất
Ý nghĩa của từ Engineer cũng có thể thay đổi, và thực tế thì những "web developer" chỉ dùng Webflow hay WordPress đã tồn tại rồi
Nếu xét theo định nghĩa nghiêm ngặt thì trong giới Software Engineering, người thật sự là kỹ sư được cấp chứng chỉ gần như chẳng có bao nhiêu, mà ở vài nước còn gắn với cả tư cách hành nghề lẫn chức danh
Hồi đầu sự nghiệp, nếu có đủ thời gian thì có lẽ tôi làm được gần như mọi thứ, nhưng giờ thì danh sách những việc tôi có thể làm mà không làm chỉ vì không thấy thú vị đã dài ra rất nhiều
Không rõ AI sẽ có giá như một gói đăng ký Slack, như chi phí của một thành viên trong nhóm, hay rồi dịch vụ biến mất khiến ta phải thuê riêng người có quyền truy cập AI
Vì vậy, phụ thuộc vào AI khá khác với phụ thuộc vào một IDE vốn có thể là công cụ chạy local hoặc mã nguồn mở
Người có khoảng 10 năm kinh nghiệm thì tự hiểu được luồng và logic của code, nên dù dùng AI vẫn có thể tạo ra code và cải thiện cách làm của chính mình
Ngược lại, người mới dễ chẳng hiểu luồng hay logic mà chỉ copy-paste, nên tôi không nghĩ AI sẽ cho họ thêm nhiều khoảng trống để suy nghĩ
Cách dùng AI hiện giờ khiến tôi thấy mệt hơn cả 20 năm làm lập trình trước đây
Quá trình ném ra vấn đề, đánh giá đề xuất, chọn hướng đúng, gạt bỏ đề xuất kỳ quặc, rồi gọt giũa tiếp để nó gần đúng là phần đặc biệt mệt
Sau đó để nó chạy code 1 đến 5 giờ, và đôi khi cho ra kết quả mà nếu tự làm thì tôi phải mất ít nhất 2 đến 3 tuần
Nhưng chỉ cần làm kiểu thiên về lập kế hoạch như vậy chừng 5 giờ là tôi kiệt sức hoàn toàn, và kiểu mệt này khác với khi chỉ lập trình thuần túy
Có vẻ như tôi vẫn đang học được gì đó, nhưng thành thật mà nói, cảm giác nó gần với công việc quản lý hơn
Muốn chậm rãi cùng LLM định nghĩa vấn đề và tìm một lời giải nghe hợp lý thì phải liên tục giữ trạng thái tập trung, nên cái dòng chảy nhập tâm như trước rất khó xuất hiện
Phải xử lý liên tục cả núi đầu ra, lặp đi lặp lại việc gạn lấy phần cốt lõi, mà dù nhìn chung khá tốt thì lúc nào cũng có gì đó lệch nhẹ, rất khó chịu
Vì những lỗi kỳ quặc và khuyết tật suy luận rất riêng của LLM, bạn cũng phải duy trì mức cảnh giác cao liên tục, và bản thân việc giải mã kiểu giao tiếp phi nhân tính đó cũng đã đủ làm mệt người
Nhưng tôi cũng nghĩ pacing hay procrastination đôi khi lại là một kiểu van xả áp đối với con người
Ngay từ đầu đã có rất nhiều kỹ sư vốn không suy nghĩ tốt, và AI không thể thay đổi bản thân sự thật đó
Đó là một trong những lý do khiến lĩnh vực Software Engineering xuống cấp khá nhiều, và AI có khi không giải quyết được gì mà chỉ tạm hoãn một mớ hỗn loạn lớn hơn
Kể cả những người sống sót ở đại học nhờ gian lận, muốn không bị phát hiện và thoát được thì cuối cùng vẫn cần tư duy phản biện
Dù có thể nhiều người không thích nghe, nhưng ngay cả gian lận cho giỏi cũng đòi hỏi khá nhiều năng lực tư duy
Tôi nghĩ ai mà ở bất kỳ mức độ nào cũng giao việc suy nghĩ cho AI thì vốn dĩ chưa từng coi trọng nó
Giống như câu "use it or lose it", ngày càng có nhiều nghiên cứu ủng hộ điều này, vậy mà trong phát triển phần mềm vẫn liên tục xuất hiện các bài kiểu dùng LLM là ổn thôi và giá trị của chúng ta nằm ở năng lực tư duy
Một trong những vẻ đẹp của công việc này là khoảnh khắc một lời giải bất chợt hiện ra dù bạn đang hoàn toàn chìm trong việc khác
Giờ thì AI trở thành công cụ biến suy nghĩ đó thành hành động thật nhanh
Trước đây có lúc tôi đánh mất mạch trước khi kịp lần ra manh mối, còn bây giờ chỉ trong vài phút trên điện thoại tôi đã có thể biến ý nghĩ đó thành thứ gì đó hữu hình dù mới một phần, rồi quay lại việc đang làm
Điểm đặc biệt lớn là tôi không còn phải lo chỉ cần rời mắt đi một chút là sẽ đánh rơi ý tưởng
Tôi đang làm lại numba, và thật khó tưởng tượng nếu phải làm việc này hoàn toàn bằng tay
Lần thử vài năm trước cực kỳ đau đớn, chậm chạp và bừa bộn
Có vô số thứ nhỏ nhặt chồng lên trên các tầng trừu tượng tích lũy suốt nhiều năm nên lại càng vậy
Lần này tôi làm lại với LLM, và có việc vốn mất vài tuần thì chỉ qua một đêm là xong
Dù vậy tôi vẫn trực tiếp xem code, xem cả đầu ra C được sinh ra, và vẫn giữ chặt quyền kiểm soát kiến trúc để sau này cả tôi lẫn LLM đều dễ xử lý hơn
Tôi không chắc như vậy có phải là nó đang thay thế tư duy của tôi hay không
Nếu tôi cố bám trụ nhiều tháng chỉ để tự tay viết và sửa, có lẽ tôi sẽ học được nhiều hơn về compiler hay transpiler, nhưng như thế thì tôi cũng chỉ mắc kẹt với mỗi việc này
Thay vào đó, giờ tôi còn dư thời gian để tự viết thêm cả phần hỗ trợ NFS server cho filesystem tùy biến bằng Golang
Giờ tôi đã dựng ra những hệ thống mà agent có thể tự tìm các thay đổi cần thiết cho cả một tính năng, bung nó ra cực kỳ chi tiết ngay ở bước lập kế hoạch, rồi phần triển khai thì gần như đúng ngay từ lần đầu
Trong một năm qua, lượng code tôi tự đọc trực tiếp ngày càng ít đi, và tôi thường tự hỏi liệu cảm giác quá thoải mái của mình với hệ thống hiện tại có đang đi quá xa không
Tôi đã thấy độ chính xác và tỷ lệ thành công cao lặp đi lặp lại đến mức giờ bản năng không còn nghi ngờ nữa
Tôi cứ chờ đến ngày bị một cú đau thật lớn, vậy mà kỳ lạ là khoảnh khắc đó mãi chưa tới
Dĩ nhiên cũng có những thiếu sót nhỏ và những lần phải quay đầu, nhưng chuyện đó trước đây cũng từng có
Khác biệt là ngày trước đó là code tôi đã vất vả viết ra nên tôi có mối quan hệ mang tính cá nhân với nó hơn rất nhiều
Bây giờ khi có vấn đề, thay vì trách code, tôi lại đào sâu xem vì sao hệ thống không tự tìm ra đáp án đúng, hoặc vì sao ngay ở bước lập kế hoạch nó đã không bộc lộ toàn bộ vấn đề trước khi triển khai
Ưu điểm lớn nhất của AI trong phần mềm là giúp tạo code nhanh hơn
Nhược điểm lớn nhất là nó cám dỗ bạn muốn tạo code nhanh hơn nữa một cách khủng khiếp
Vì vậy tôi không dùng AI cho dự án cá nhân
Vì tôi muốn giữ cho đầu óc luôn sắc bén
Nếu là dự án có AI trong bản thân nó thì có thể là ngoại lệ, nhưng tôi không dùng AI để viết phần code đó
Còn việc công ty thì tôi không bận tâm
Nếu quản lý muốn hoàn toàn vibe coding bằng Claude thì cứ thế thôi, vì chi phí nợ kỹ thuật phát sinh từ đó đâu phải do tôi trả