- Việc từ chối đồng nhất mình với bản sắc kỹ sư phần mềm bắt đầu từ nhận xét cách đây 23 năm: “là một hacker giỏi nhưng không phải kỹ sư”
- Mô hình agent tạo cảm giác như một cách dùng các chương trình phi quyết định để tạo ra những chương trình lẽ ra phải có tính quyết định
- Niềm tin vào code nằm ở tính dễ đọc, khả năng hiểu, hiệu quả, khả năng suy luận và tính tái lập cho ra cùng đầu ra với cùng đầu vào
- agentic user flows ở nơi làm việc và KPI sử dụng AI được tiếp nhận như một cách đặt chỉ số và đầu vào ngôn ngữ tự nhiên lên trước code tốt
- Hình dung về tương lai của ngành AI trông như không chỉ thay thế phát triển phần mềm mà còn muốn đắp hào quanh chính tư duy
Kỹ nghệ phần mềm và mô hình agent
- Thái độ tự loại mình ra khỏi bản sắc kỹ sư phần mềm bắt nguồn từ trải nghiệm cách đây 23 năm khi được một đồng nghiệp nhận xét là “một hacker giỏi” nhưng không phải kỹ sư
- “Mô hình agent mới” gần đây trông như việc yêu cầu một cỗ máy kiểu Waylon Smithers đừng mắc lỗi, rồi đóng gói kết quả đó như kỹ nghệ phần mềm ở cấp độ chuyên gia
- Cách viết những chương trình lẽ ra phải có tính quyết định bằng các chương trình tạo ra đầu ra phi quyết định đang được đưa ra như tương lai của kỹ nghệ phần mềm
- Niềm tin nền tảng vào code vẫn nằm ở tính dễ đọc, khả năng hiểu, hiệu quả, đủ khả năng suy luận và tính tái lập cho ra cùng đầu ra với cùng đầu vào
- Vì trong các hệ thống thực tế, tính tái lập vốn đã khó, nên bản thân việc viết code không thể được dựng trên “cát lún”
- Những chi tiết như tác động của view gồm các subquery kết hợp và biểu thức tổng hợp lên hiệu năng truy vấn, Inversion-of-Control, hay thiết kế tách chức năng khỏi method để có thể kiểm thử độc lập vẫn rất quan trọng
Sự bất tín với luồng phát triển lấy AI làm trung tâm
- agentic user flows được yêu cầu ở nơi làm việc không có ý nghĩa rõ ràng, và cũng khó bị thuyết phục rằng ô nhập văn bản ngôn ngữ tự nhiên lại tốt hơn cách chọn từ một tập tùy chọn nhỏ
- Có một xu hướng muốn dùng agent ở mọi giai đoạn của vòng đời phát triển phần mềm, và thậm chí còn nói rằng việc tự tay viết code sẽ bị đối xử như viết COBOL
- Agent trông giống như các lớp bọc prompt LLM đánh giá đầu ra theo ngữ cảnh, và đầu ra thực tế thường tạo cảm giác còn thiếu sót
- Mức sử dụng AI bị theo dõi bằng KPI, nhưng trong 23 năm qua, viết code tốt luôn quan trọng hơn KPI
- Từng có nhận xét rằng code đã viết “trông như của một người học toán viết”, và điều đó được xem là một lời khen lớn
- Một triển khai của một staff software engineer trong cùng công ty không có interface tường minh, để lộ DI container dưới dạng thành viên public static, và dùng cấu hình CSV không phải vì nó phù hợp với dữ liệu dạng bảng mà vì “người dùng nghiệp vụ dễ dùng hơn”
- Khi nói triển khai đó là rất tệ thì đã phát sinh rắc rối, và chuyện này dẫn tới kết luận đầy mỉa mai rằng bản thân không phải là kỹ sư phần mềm
- Đã hai lần nghe lời khuyên từ những người mình cho là thông minh rằng AI là tương lai của việc viết phần mềm và của cả ngành, nên cần chấp nhận nó, nhưng thái độ đó trông rất cẩu thả
- Phần mềm AI đã thử dùng tạo cảm giác không giúp quá trình suy nghĩ mà còn cản trở hoặc chủ động chiếm lấy nó, và sự chiếm dụng đó gây lo ngại
- Các lãnh đạo công ty AI lớn nói đầy hào hứng về tương lai của ngành phát triển phần mềm, công bố rằng sản phẩm của họ sẽ gây ra devastating effects lên việc làm, và dùng cụm từ “intelligence too cheap to meter”
- Tương lai đó đáng sợ không phải vì máy móc sẽ biến mọi người thành kẹp giấy, mà vì họ đang tưởng tượng ra việc đắp hào quanh chính tư duy
1 bình luận
Ý kiến trên Lobste.rs
Trong sách của Mary Walton về W. Edwards Deming có một giai thoại như thế này. Một công nhân nhà máy gặp sự cố máy móc khiến chỉ tạo ra hàng lỗi, anh đã báo cáo nhưng việc bảo trì bị chậm, nên đang định tự sửa thì người giám sát tới và bảo cứ tiếp tục chạy máy
Rốt cuộc đó là chỉ thị kiểu “hãy làm ra hàng lỗi”, và anh ấy đã nói: “Lòng tự hào của tôi với tư cách người lao động ở đâu rồi? Giá mà người giám sát tôn trọng tôi ít nhất bằng cái máy thì tốt hơn.” Anh ấy không muốn làm ra hàng lỗi rồi nhận tiền vì việc đó
Có đáng đọc không?
Dù kinh nghiệm của tôi ít hơn tác giả rất nhiều, nhưng ở giai đoạn đầu sự nghiệp, vì nhiều vấn đề của CSV nên tôi đã cố gắng chuyển một phần quy trình công việc ra khỏi CSV, và khi đó nhận được câu trả lời rằng “CSV dễ hơn cho quy trình nghiệp vụ”
Lúc ấy tôi cũng thấy câu trả lời đó rất tệ như tác giả, nhưng theo thời gian tôi lại nghĩ rằng nhận định đó gần với sự thật hơn
Nếu bạn vẫn còn bị ám ảnh bởi mấy ý kiến ngớ ngẩn kiểu “23 năm trước có người bảo tôi không phải kỹ sư phần mềm”, thì giải pháp là đừng bận tâm đến ý kiến của người khác đến thế
Nếu bạn thấy khó chịu vì chính sách ngu ngốc của chủ lao động hay vì đồng nghiệp thiếu nghiêm túc, thì cứ tìm công ty khác. Trên thế giới có 8 tỷ người, rất nhiều người trong số đó muốn máy tính làm gì đó cho họ, và cũng rất nhiều người trong số đó sẵn sàng trả tiền cho việc lập trình
Nó nghe giống kiểu “lần đầu tôi làm ở tiệm bánh, một đồng nghiệp bảo bánh croissant là âm mưu của Big Dairy để bán thêm bơ, nên tôi lấy đó làm nền tảng thế giới quan và kết luận rằng từ nay không bao giờ có thể làm ở tiệm bánh nữa”. Nếu không biết tuổi của tác giả thì tôi đã đoán là học sinh cấp ba, nhưng nếu đang nói về chuyện từ 23 năm trước thì chắc chắn đã qua cái tuổi đó từ lâu rồi
Ý chính không phải là tác giả thật sự không phải kỹ sư phần mềm — có lẽ tác giả đã làm việc với chức danh đó trong thời gian dài. Ý chính gần hơn với việc thái độ tự loại mình ra khỏi chức danh ấy là một phản ứng trước việc ngành này đã thay đổi như thế nào
Kiểu như đang nói: “Đây không phải kỹ thuật, đây là trò nhảm nhí. Nếu làm kỹ sư phần mềm có nghĩa là thế này, thì tôi không phải như vậy”
Cá nhân tôi đồng cảm với cảm xúc đó. Nhiều lần tôi thấy việc gọi những gì chúng ta làm với tư cách nhà phát triển phần mềm là “kỹ thuật” gần như là một sự xúc phạm với các ngành kỹ thuật khác. Đặc biệt là vì trong khi gọi như vậy, chúng ta lại chẳng mấy quan tâm đến thứ mình tạo ra
Kỹ sư xây dựng thực sự xem việc cầu sập là chuyện cực kỳ nghiêm trọng, và khi có một vụ sụp đổ lớn, cả ngành sẽ phản ứng, rút kinh nghiệm để chuyện đó không lặp lại nữa. Trong khi đó, những “kỹ sư” phần mềm tự xưng có thể làm hệ thống production sập hết lần này đến lần khác vì những lý do hoàn toàn có thể phòng tránh, rồi vẫn ghi chuyện đó vào CV như một thành tích
Còn về xu hướng kỹ thuật phần mềm hiện nay — tức là không quan tâm đến đoạn mã thực sự được triển khai và giao việc viết nó cho một “trí tuệ” khác — thì chắc bạn cũng đoán được tôi nghĩ gì
Tôi không muốn nói rằng mình hiểu hết vì sao chuyện này xảy ra, hay rằng mình có đầy đủ câu trả lời cho việc phải làm gì. Nhưng ít nhất, đừng giả vờ rằng đây là công việc nghiêm túc, rằng đây là “kỹ thuật”