Loading…

Có phải AI đang khiến ta không còn phân biệt nổi kỹ sư giỏi với kỹ sư chỉ ồn ào?

senior_slacker
Công khai 5 cuộc trò chuyện 10 suy nghĩ 103 lượt tán thành 8 phản đối 0 loạt bài 200 lượt xem

Tôi cứ nghe đi nghe lại cùng một kiểu feedback dưới nhiều dạng khác nhau: “velocity tốt đấy,” “thích cái throughput này,” “dùng AI khéo ghê.” Nhìn từ bên ngoài thì đúng là có vẻ như đang có nhiều thứ diễn ra hơn: nhiều Code Review hơn, đụng tới nhiều ticket hơn, nhiều cập nhật hơn, nhiều email hơn, nhiều task hơn, nhiều thiết kế hơn. AI giúp duy trì cái nhịp đó dễ dàng mà không còn phần ma sát quen thuộc của việc viết, suy nghĩ, hay thậm chí là chần chừ. Nhưng bên trong công việc lại có một tình

In groups

Nội dung cuộc thảo luận

Tôi cứ nghe đi nghe lại cùng một kiểu feedback dưới nhiều dạng khác nhau: “velocity tốt đấy,” “thích cái throughput này,” “dùng AI khéo ghê.”

Nhìn từ bên ngoài thì đúng là có vẻ như đang có nhiều thứ diễn ra hơn: nhiều Code Review hơn, đụng tới nhiều ticket hơn, nhiều cập nhật hơn, nhiều email hơn, nhiều task hơn, nhiều thiết kế hơn. AI giúp duy trì cái nhịp đó dễ dàng mà không còn phần ma sát quen thuộc của việc viết, suy nghĩ, hay thậm chí là chần chừ. Nhưng bên trong công việc lại có một tình thế khó xử cứ ngày một lớn hơn.

Có phần kỹ thuật thật sự: truy ra một race condition chỉ xuất hiện khi tải nặng, hoặc nhận ra rằng một bug “đơn giản” thực chất là một giả định sai trong thiết kế. Hoặc quyết định không refactor một hệ thống chỉ vì nó lộn xộn, bởi vì nó vẫn chạy được và rủi ro không đáng để đánh đổi. Phần đó không nhanh hơn nhờ AI. Bạn làm cái phần việc mà AI có thể làm và chấp nhận chỉ số thấp hơn nhiều so với các kỹ sư khác? Hay cứ thế prompt cả ngày, tạo ra code và thiết kế liên tục? Bạn đi tìm những giải pháp KHÔNG cần code hay dùng AI để đẻ ra cả đống feature, hệ thống, thiết kế? Ừ thì... tôi cũng chẳng biết phải làm gì.

Rồi còn mọi thứ xoay quanh nó. AI khiến việc tạo ra một đợt refactor “dọn dẹp” quy mô lớn trở nên dễ như không, đổi tên file và xáo lại các module sao cho code trông đẹp hơn trong một PR. Hoặc dựng lên một test suite rộng khắp tạo cảm giác có coverage mà không thật sự nhắm vào những failure mode thực sự quan trọng. Hoặc chia một thay đổi vốn liền mạch thành mười PR nhỏ để cái biểu đồ hoạt động trông khỏe khoắn hơn. Ngay cả tài liệu cũng bị cuốn vào chuyện này, những bản doc bóng bẩy, dài dòng đọc nghe rất xuôi tai... nhưng chẳng còn ai thật sự đọc nữa vì quá nhiều nhiễu đang xảy ra. Chúng tôi prompt AI để tạo ra thiết kế, rồi đến lượt reviewer của mình lại prompt AI để tóm tắt và review. Còn quản lý thì có vẻ mê tít.

Hành vi kỹ thuật thích nghi theo những KPI được tính điểm. Nhiều commit nhỏ lẻ hơn, nhiều mảnh PR vụn hơn, nhiều ghi chú kiểu “AI đã giúp tôi tạo ra cái này” để báo hiệu là mình có tham gia vào quy trình mà người ta kỳ vọng. Ngay cả khi phần việc thật vẫn là phần chậm chạp, debug, lý giải, nói không với những thay đổi không cần thiết, thì nó ngày càng phải được gói lại trong những thứ trông như đà tiến. Ai cũng muốn giữ được việc làm.

Phần khó chịu là AI không chỉ làm tăng năng suất. Nó hạ thấp cái giá phải trả để tạo ra bằng chứng thuyết phục về năng suất. Và một khi chuyện đó trở nên dễ dàng, nó bắt đầu cạnh tranh với câu hỏi khó hơn nhiều: rốt cuộc thì có cái nào trong số đó thật sự đáng giá hay không.

Thoughts

  • tuan_release

    Chia một thay đổi liền mạch thành mười PR để biểu đồ activity trông khỏe, tôi thấy người ta làm tuần nào cũng có. Có ông trong team tôi tách một fix ba dòng thành sáu commit kèm note "AI hỗ trợ" mỗi cái.

    Manager khen velocity. Cùng tuần đó cái pipeline release bị một flaky test thật chặn hai ngày, người gỡ nó không có cái biểu đồ nào đẹp để khoe. Pipeline nhớ ai đã gây ra mớ này lâu hơn cái dashboard nhớ ai dọn nó.

    Permalink
  • no_ky_thuat

    Cái phần bạn nói AI không làm nhanh hơn được là phần thật của nghề thì đúng đến mức khó chịu. Truy một race condition chỉ hiện khi tải nặng, hay quyết định không refactor vì rủi ro không đáng, đó là công việc không có throughput để khoe.

    Vấn đề là cái phần đó luôn vô hình ngay cả trước AI. Tôi từ chối một migration giòn và ngăn được một incident, không ai thấy cái incident không xảy ra. AI không tạo ra méo mó này, nó chỉ hạ giá thành của việc giả vờ năng suất xuống gần bằng không, nên giờ cái vô hình bị cái ồn ào dìm sâu hơn.

    Permalink
  • lo_trinh_that

    Tôi đồng ý cái chẩn đoán, nhưng muốn nói thẳng phần bài bỏ ngỏ: ai là người sửa được cái này. Đó là vấn đề đo lường, và đo lường là việc của management.

    • Nếu KPI vẫn đếm PR, commit, ticket, thì kỹ sư tối ưu theo đúng cái được đếm, không thể trách họ.

    • Việc khó là định nghĩa lại "đóng góp" sao cho cái quyết định không-refactor và cái incident-không-xảy-ra được tính.

    Manager mê velocity vì velocity dễ đo và dễ báo cáo lên trên. Câu hỏi "cái nào thật sự đáng giá" thì không có dashboard, nên nó bị bỏ. Đây là vấn đề can đảm của người đo trước khi là vấn đề của người làm.

    Permalink
  • ban_dung_lam_mau

    Cái note "AI đã giúp tôi tạo ra cái này" gắn vào mỗi commit là phiên bản mới của tài liệu sáu trang viết cho cuộc họp đã bị hủy. Bạn không báo cáo công việc, bạn báo cáo rằng mình có mặt trong cái quy trình mà người ta kỳ vọng.

    Permalink
  • viec_giau_mat

    Cái vòng "chúng tôi prompt AI tạo design, reviewer prompt AI tóm tắt và review" là chỗ tôi thấy ghê nhất, vì nó giết luôn cái mục đích của review. Review vốn là chỗ một người thật chịu trách nhiệm đọc.

    Và cái phần dọn dẹp cuối, đảm bảo cái doc bóng bẩy đó thật sự đúng, vẫn rơi vào người để ý nhiều nhất, thường là người ít được tính công nhất. AI làm cái lớp vỏ thuyết phục rẻ đi, nhưng phần kiểm cho nó đúng thì vẫn đắt như cũ và vẫn vô hình như cũ.

    Permalink

Related discussions

  • Phải chăng đa số startup AI chỉ là cái UI đắp lên vài file Agent.md?

    Đa số startup AI bây giờ cho cảm giác như có người dán GPT vào terminal, thêm cái UI dark mode, rồi bắt đầu nói năng như thể họ vừa phát minh ra cái gì ghê gớm lắm. Bạn sẽ thấy mấy cái pitch điên rồ kiểu “agent nhận thức tự chủ bền vững với khả năng suy luận dài hạn”, rồi vén màn ra xem thì về cơ bản nó là: cho model tool access, cho nó dùng browser, có khi thêm memory summary với retry logic. Đó là “sản phẩm”. Tự bạn cũng làm được, chỉ cần cho Claude quyền truy cập trên máy mình.

  • Các công ty công nghệ có thật sự được lợi từ những nhân viên không thể nghỉ việc?

    Tôi đã làm qua đủ nhiều tổ chức công nghệ để nhận ra một kiểu mẫu mà chắc nhiều bạn cũng sẽ thấy quen. Có những team rất thụ động, họ ship đúng hạn, đạt target, quy trình sạch sẽ, vậy mà chẳng ai bao giờ giết một ý tưởng tồi ngay trong cuộc họp. Không ai nói đây là thứ không nên làm. Roadmap có một, mà thực ra là sáu, hạng mục mà ba người trong số đó vẫn rỉ tai nhau là sẽ không chạy được, nhưng nó cứ trôi qua khâu planning mà không một lời, thậm chí còn kèm nụ cười. Bạn nhìn các lead engineer gậ

  • Có phải Chromebook đã khiến Gen Z thành vô vọng trong giới công nghệ?

    Nỗi hoảng loạn hiện tại bảo rằng AI đang làm con người tư duy kém đi. Có thể. Nhưng nếu bạn muốn biết vì sao nhiều người lao động trẻ lại thành thạo app đến vậy mà lại lóng ngóng với máy tính đến vậy, thì AI không phải nơi đầu tiên cần nhìn. Cú đứt gãy sâu hơn đã xảy ra sớm hơn, khi trường học và các định chế quyết định rằng học sinh nên tương tác với những thiết bị được quản lý sẵn thay vì máy móc thật, như thế hệ Millennial từng làm.

  • Có phải cái làm nên thành công của một công ty không phải đổi mới, mà là thực thi?

    Một thứ bắt đầu trông giả tạo sau đủ nhiều năm trong ngành công nghệ là nỗi ám ảnh với "disruption" như lời giải thích cho mọi công ty thành công. Công ty chiến thắng đơn giản là thực thi tốt hơn mọi đối thủ trong một thị trường vốn đã tồn tại. Facebook không phải một đột phá ý niệm bất khả. Mạng xã hội vốn đã có. MySpace đã có. Friendster đã có và phần lớn tính năng Facebook có đều đã hiện diện ở 2 cái đó. Người ta đã hiểu ngay danh mục sản phẩm này.

  • Có phải ta đang mù quáng bắt chước các CEO công nghệ, khi lời khuyên của họ chỉ trông khôn ngoan nhờ hoàn cảnh?

    Tôi nghĩ rất nhiều lời khuyên quản trị công nghệ nổi tiếng chỉ trông khôn ngoan nhờ môi trường bao quanh nó. Giá cổ phiếu đi lên, nhân tài bị giữ chân, và phần lời từ cổ phần đã khiến nhiều kiểu quản lý tồi vẫn sống được. Phần lớn tổ chức không có những bộ giảm xóc đó, và đó là lý do tôi nghĩ người ta nên thôi coi thần thoại về nhà sáng lập như lời khuyên quản trị.

  • Phải chăng sếp muốn ai cũng dùng AI, trừ chính họ?

    Cái bắt đầu làm tôi khó chịu không phải là chuyện đẩy mạnh AI. Một số công cụ thật sự hữu ích, giờ ngày nào tôi cũng dùng. Cái làm tôi bực là việc quản lý đòi hỏi mọi người phải làm việc theo kiểu “AI-first”, trong khi mọi quy trình xung quanh thì vẫn cực kỳ thù địch với việc dùng AI. Người ta được bảo phải dùng AI để code, lên kế hoạch, nghiên cứu, soạn thảo, debug, tra cứu kiến thức, phối hợp dự án.. Nhưng rồi một nửa kiến thức vận hành của công ty vẫn nằm trong những cuộc trò chuyện không đượ

  • Phải chăng AI đang khiến các sếp loạn trí theo đúng nghĩa y học?

    Đang có một ảo tưởng mới lan truyền trong giới sếp, rằng AI có thể thay thế nhân viên. Dù chắc chắn nó đang thay thế một số người, các sếp có một ảo tưởng khiến họ thấy mình có thể tự làm công việc của cấp dưới, chỉ với AI. Rằng họ có thể code! Chỉ cần mở một dashboard đầy các agent có tên, xem các task chạy qua các pane, hỏi cập nhật bằng giọng ra lệnh, và xong feature trong chớp mắt. Cảm giác như mơ, nhất là khi bạn đẩy mấy "ý tưởng lớn lao" qua nó và AI bảo bạn rằng…

  • Tạo động lực để kỹ sư dùng AI có phản tác dụng không?

    Một công ty có thể phá hỏng gần như mọi công cụ tốt chỉ bằng cách gắn cho nó sai chỉ số. Ở nơi làm việc, động lực là tất cả những gì quan trọng, dù là lợi ích tài chính, địa vị, hay thăng tiến... Người lao động làm việc theo động lực. Bạn và tôi cũng vậy. Gần như ai cũng làm mọi thứ vì nó có lợi cho mình hoặc cho người thân. Vì thế, ở chỗ làm, chúng ta rốt cuộc làm cái gì giúp mình được thăng chức, kiếm thêm tiền, có thêm sự bảo đảm công việc... Chúng ta không phải chủ công ty, chúng ta là nhân