Chuyên môn lĩnh vực luôn là hào lũy thực sự
(brethorsting.com)- Phần khó của phần mềm không nằm ở việc gõ code mà ở việc hiểu các quy tắc ngoài đời thực như lương bổng hay giao thông để xây dựng mô hình lĩnh vực, và code là kết quả của sự thấu hiểu đó
- AI tác tử cho phép tạo ra phần mềm ngay cả khi không có hiểu biết về lĩnh vực, chuyển nút thắt từ “có thể làm ra được không” sang “có thể đánh giá nó có đúng không”
- Các chuyên gia lĩnh vực như điều phối vận tải, mã hóa lâm sàng, chuyên gia định phí bảo hiểm có thể không biết code nhưng vẫn phân biệt được đầu ra có phù hợp với quy định pháp lý, quy tắc thanh toán hay vận hành hay không
- Kỹ sư tổng quát có thể kiểm chứng kiến trúc và độ tin cậy, nhưng ở những lĩnh vực mà đáp án gắn chặt với kiến thức chuyên ngành như mã hóa lâm sàng, họ có thể bỏ sót các lỗi trông có vẻ hợp lý
- Năng lực giá trị nhất là phán đoán để cùng lúc xác minh tính lành mạnh của code được sinh ra và tính đúng đắn của đầu ra, khiến việc đầu tư vào chuyên môn lĩnh vực trở nên quan trọng hơn với các kỹ sư giàu kinh nghiệm
Nút thắt của phần mềm đang chuyển từ triển khai sang kiểm chứng
- Phần khó của việc viết phần mềm không phải là bản thân việc gõ code, mà là trước hết phải xây dựng mô hình lĩnh vực trong đầu
- Hệ thống tính lương phải bao gồm xử lý khấu trừ cưỡng chế, khấu trừ trước thuế và các kỳ lương cắt qua thời điểm thay đổi mức lương
- Ứng dụng giao thông phải phản ánh GTFS feed, sự khác nhau giữa trip và route, và lý do một xe buýt “đúng giờ” vẫn có thể sai
- Code là kết quả của việc chuyển tải sự hiểu biết đó, còn việc có được sự hiểu biết mới là công việc thực sự
- AI tác tử làm suy yếu mối liên kết giữa hiểu biết lĩnh vực và năng lực tạo ra phần mềm
- Giờ đây có thể tạo phần mềm mà không cần tự xây dựng trực tiếp mô hình lĩnh vực
- Tiền đề mà toàn bộ nghề nghiệp phần mềm từng dựa vào đang bị lung lay
- Như góc nhìn năm ngoái đã nói, việc các công cụ này khuếch đại các lập trình viên cấp cao có năng lực phán đoán là đúng, nhưng chưa đủ
- Thay đổi cụ thể hơn là nút thắt đã chuyển từ “có thể làm ra được không” sang “có thể đánh giá nó có đúng không”
Ai là người dùng tốt công cụ tác tử
-
Chuyên gia lĩnh vực có thể phân biệt đáp án đúng ngay cả khi không biết code
- Những người như điều phối vận tải, mã hóa lâm sàng hay chuyên gia định phí bảo hiểm có thể không đọc được stack trace và không giải thích được sự khác nhau giữa hash map và list
- Nhưng khi nhìn vào lịch do tác tử tạo ra, họ có thể biết ngay tài xế nào về mặt pháp lý không thể làm ca đó
- Họ cũng có thể nhận ra tổ hợp mã nào trong yêu cầu bồi hoàn bảo hiểm sẽ không được thanh toán
- Họ đã dành 10 năm sống trong đầu vào và đầu ra của công việc, nên họ biết đầu ra đúng cho một đầu vào nhất định là gì
- Điều tác tử mang lại cho họ là khả năng tạo code còn thiếu, còn điều họ mang lại cho tác tử là chuẩn sự thật (ground truth) mà tác tử không có
-
Kỹ sư tổng quát có thể không phân biệt được phần mềm làm tốt với phần mềm đúng
- Một kỹ sư tổng quát giỏi hiểu về kiến trúc, độ tin cậy, kiểm thử và cách để hệ thống không sụp lúc 2 giờ sáng
- Nhưng trong những lĩnh vực như mã hóa lâm sàng, họ có thể không phân biệt được câu trả lời trông hợp lý nhưng sai với câu trả lời đúng
- Tác tử có thể tạo ra thứ biên dịch được, vượt qua các bài kiểm thử mà kỹ sư nghĩ ra, nhưng vẫn mắc lỗi tinh vi và tốn kém trong quy tắc thanh toán
- Kỹ sư có thể xác minh phần mềm có được xây dựng tốt hay không, nhưng khi tính đúng đắn được định nghĩa hoàn toàn bởi một lĩnh vực không nằm trong đầu họ, thì rất khó xác minh độ chính xác
-
Trước thời đại tác tử, kỹ sư có một lộ trình học tập thuận lợi hơn
- Kỹ sư có thể theo sát chuyên gia, đọc đặc tả và dần học lĩnh vực qua những sai lầm trong môi trường vận hành
- Ở nhiều ngành, quá trình đó là cốt lõi của nấc thang sự nghiệp
- Chuyên gia lĩnh vực thì không có một con đường đối xứng như vậy
- Để học cách tạo ra phần mềm đáng tin cậy cần nhiều năm, và đó là con đường mà trên thực tế họ khó đi được
-
Công cụ tác tử chỉ phá vỡ một phía của lộ trình đó
- Lợi thế của kỹ sư là khả năng chuyển mô hình lĩnh vực thành code chạy được nay đã trở nên rẻ hơn
- Lợi thế của chuyên gia lĩnh vực là biết điều gì đúng thì không hề trở nên rẻ hơn
- Không thể có được năng lực đó chỉ bằng prompt, và cũng không có skill file nào chứa được tri thức ngầm của người đã xử lý đúng hàng nghìn kỳ tính lương
-
Người giá trị nhất là người có thể kiểm chứng ở cả hai tầng
- Người vừa biết code sinh ra có lành mạnh không, vừa biết câu trả lời mà code đó đưa ra có đúng hay không sẽ trở nên quan trọng nhất
- Lý do họ có thể viết bài kiểm thử như “tài xế không được vượt quá 11 giờ” là vì họ biết quy tắc
- Lý do họ có thể đánh giá chính bài kiểm thử đó có ý nghĩa hay không là vì họ biết mình đang kiểm thử điều gì
- Tác tử làm phần việc chuyển chép, còn con người thực hiện phán đoán ở cả tầng code lẫn tầng lĩnh vực
- Với kỹ sư giàu kinh nghiệm, khoản đầu tư quan trọng là có được một mô hình sâu và đã được kiểm chứng về lĩnh vực thực tế
- Giá trị của năng lực cơ học biến một ý tưởng rõ ràng thành code gọn gàng đã giảm đi đáng kể
- Thứ vẫn còn khan hiếm là sự hiểu biết sâu về ngành thực tế, công cụ, hệ thống quy định và các quy trình vật lý
- Cần chọn một lĩnh vực và học nó theo cách từng học ngôn ngữ lập trình hay framework
- Phần mà tác tử không thể thay thế, và cũng là phần đang tăng giá trị mạnh nhất lúc này, chính là chuyên môn lĩnh vực
Muốn tiếp tục nhận các chủ đề công nghệ được tuyển chọn?
Theo dõi kênh Telegram. @GeekNewsVN
1 bình luận
Ý kiến trên Hacker News
Không biết còn cần bao nhiêu bài diễn giải dài dòng nữa mới chịu thừa nhận rằng không ai biết phải dùng AI thế nào ở cấp độ cá nhân
Ban đầu người ta nói chỉ cần là lập trình viên giỏi rồi học cách dùng AI là đủ, rồi sau đó lại bảo năng lực thiết kế kiến trúc mới là thứ quan trọng, tiếp theo thì nói gu mới là yếu tố quyết định tất cả, còn giờ lại thành chỉ chuyên gia miền lĩnh vực mới quan trọng
Chừng nào việc AI sẽ tiếp tục cải thiện hay chững lại chưa trở thành một trạng thái ổn định và có thể dự đoán được, thì những cách diễn giải kiểu này sẽ tiếp tục vô nghĩa và phần lớn có khả năng sai
Nó làm ngưỡng của những gì có thể làm được tăng lên rất nhiều, nên mọi thứ khó hơn. Lập trình viên cá nhân giờ có thể nhận những dự án khó hơn rất nhiều, và rốt cuộc giới hạn xưa nay luôn là thời gian; AI giúp bạn làm được nhiều việc hơn trong quỹ thời gian đó
Nhưng bản thân những việc có thể hoàn thành trong quỹ thời gian ấy giờ lại khó hơn rất nhiều. Bạn phải hiểu nhiều thứ hơn rất nhiều, và phải bước ra xa khỏi vùng an toàn quen thuộc từ trước thời AI
Trước đây, việc dành vài ngày để refactor codebase hoặc chuẩn bị phát hành một tính năng nhỏ vì phải học một vùng hệ thống không quen thuộc hay một thư viện mới là điều có thể chấp nhận được
Nhờ các coding agent, bạn có thể leo đường cong học tập đó nhanh hơn nhiều, nhưng vẫn phải tự mình leo. Và lượng thông tin đổ vào cũng lớn hơn rất nhiều
Nếu lo sẽ bị các vibe coder không có nền tảng kỹ thuật cướp việc, thì phản ứng đúng là làm phần mềm tốt hơn họ rất nhiều. Mà như vậy thì cần kỹ năng cao hơn, tham vọng lớn hơn, kinh nghiệm nhiều hơn, và điều đó không hề dễ
Phép so sánh mà đến giờ tôi thấy phù hợp nhất là giữa máy khoan/vặn vít điện hiện đại và các dụng cụ kiểu cũ như tua vít hay khoan tay
So với đồ nghề cũ, nó có thể cho ra kết quả đáng kinh ngạc trong thời gian rất ngắn
Ví dụ kiểu những giai thoại ấn tượng như “Tôi cố định xong sàn trong 1 tiếng, việc mà bình thường phải mất cả ngày, còn tranh thủ hút thuốc mấy lần ở giữa”. Nếu dùng súng bắn đinh thì có khi còn xong trong nửa thời gian, nhưng sau này sẽ khó nhấc cái sàn đó lên dễ dàng, và chi phí cũng có thể gấp đôi
Tôi cũng dùng nhiều LLM on-premises và có quyền truy cập các model khác, nên có lẽ một lúc nào đó tôi sẽ còn mở rộng phép so sánh này đến mức khác biệt theo từng thương hiệu
Nhưng tôi không nghĩ nó sẽ đi tìm việc mới. Máy khoan/vặn vít điện không phải là thợ mộc hay công nhân công trường, và nếu không có con người thì nó vô dụng
20 năm nữa, tôi đoán chúng ta sẽ lại dọn rác do đồng tác giả với Claude tạo ra
https://mastodon.gamedev.place/@JeremiahFieldhaven/116654345...
Năm 2018, tôi từng thấy một người hoàn toàn không có kinh nghiệm lập trình kiếm được khoản tiền khá ổn chỉ sau một tháng viết code, chỉ vì họ hiểu một thị trường ngách cụ thể và làm ra một công cụ giải quyết được nhu cầu đó
Người đó có cho tôi xem một phần mã nguồn; nó tệ chẳng khác gì chương trình đầu tiên của tôi, nhưng nó giải quyết được vấn đề thực tế
Ví dụ họ nói kiểu “Muốn giỏi thể thao thì cần tính đối xứng hoàn hảo, mà điều đó tương quan mạnh với sự ổn định phát triển từ thời bào thai. Càng đối xứng thì càng phát triển hoàn hảo”
Rồi vài năm sau lại xuất hiện thông tin Bruce Lee có một chân ngắn hơn chân kia khá nhiều, còn Usain Bolt cũng có kiểu phát triển bất đối xứng tương tự
Thế là họ quay sang bào chữa rằng đó chỉ là ngoại lệ nên không ảnh hưởng gì đến quy luật chung ban đầu
Cứ làm thứ gì đó thú vị là được, rồi có khi nó sẽ thành công
Gần đây tôi đã review một ứng dụng gần như được làm xong bằng vibe coding. Chủ ứng dụng nói gần như đã sẵn sàng phát hành và chỉ cần kiểm tra nhanh thôi
Nhưng khi xem thì thiết kế cơ sở dữ liệu rất tệ. Có chức năng chạy, có chức năng không. Tôi giải thích những phần còn thiếu và vì sao nó bị hỏng. Giống như bài viết gốc, người đó là một chuyên gia miền lĩnh vực
Chỉ riêng tháng trước họ đã dùng tới hàng tỷ token, và công cụ thì đang cải thiện rất nhanh. Nhưng đưa AI cho chuyên gia miền lĩnh vực không có nghĩa là kỹ sư phần mềm trở nên không cần thiết
Chuyên gia miền lĩnh vực có thể dùng AI để làm phần mềm, còn kỹ sư phần mềm có thể dùng AI để học về lĩnh vực. Hai bên mang đến những chuyên môn khác nhau
Tức là xây dựng guardrail, kiểm chứng, thư viện prompt, agent và quy trình review thủ công để bảo vệ an toàn khi các chuyên gia miền lĩnh vực bắt đầu dùng coding agent
Nó hơi giống bộ phận hỗ trợ khách hàng nội bộ cấp T2/T3 hoặc kỹ sư hỗ trợ. Vai trò này không phải lúc nào cũng trực tiếp giải quyết 100% các vấn đề thường nhật, mà là bắt các điểm nguy hiểm, các edge case kỳ lạ và đảm bảo mọi cấu hình đều đúng
Tất nhiên cũng sẽ phải xử lý nhiều mối quan tâm xuyên suốt
Dù vậy, nó là công cụ tuyệt vời để thử nhanh và đào sâu các ý tưởng mới. Nếu có sự tò mò, nó thậm chí có thể trở thành bộ tăng tốc học tập rất mạnh
Tôi dùng Claude Code cả ngày (Opus 4.6, thiết lập nỗ lực tối đa) mà vẫn không hiểu điều đó làm sao có thể xảy ra. Tôi cũng tò mò không biết mức sử dụng đó có thực sự mang lại hiệu quả tương xứng không
Rất có thể là do tôi chưa biết rõ, nhưng thực sự tôi không hiểu làm sao lại đến mức đó được
Gần đây tôi có một ví dụ rất hay từng trải qua
Tôi đang đi câu cá và hỏi một vị thuyền trưởng liệu ông ấy có muốn xem thử ứng dụng miễn phí mà tôi đang làm (https://oceanconnect.ca) có thể giúp ích cho công việc của ông ấy không
Tôi không thực sự biết mọi người sử dụng dữ liệu hàng hải như thế nào ngoài khơi. Tôi cũng không rõ họ muốn biết điều gì, hay vì sao lại muốn biết điều đó. Câu hỏi và thông tin cứ dồn dập đổ ra về cách mọi người dùng dữ liệu, và chúng tôi có thể làm gì với dữ liệu, đến mức tôi hoàn toàn không chuẩn bị trước, và việc có được góc nhìn đó thực sự rất tuyệt và thú vị
Nó nhắc tôi nhớ lại rằng mô hình không giống với hệ thống mà nó trừu tượng hóa, và kiến thức để phát triển mô hình hầu như không liên quan đến kiến thức để sử dụng nó
Người này có lượng kiến thức khổng lồ về cách dùng dữ liệu thời tiết trên biển. Theo một nghĩa nào đó, ông ấy hiểu dữ liệu còn hơn cả tôi, và dù bản thân có thể không nhận ra điều đó hoặc không hiểu cách biểu diễn bằng kỹ thuật số, nếu biết lập trình thì có lẽ ông ấy sẽ làm được một ứng dụng hữu ích cho những người như mình tốt hơn rất nhiều
Tôi đã nghĩ rằng nếu những người như vậy có LLM ở trước mặt để đưa ý tưởng của họ lên màn hình thì họ có thể tạo ra những thứ thực sự đáng kinh ngạc. Nếu một ngày nào đó có kinh phí, tôi muốn phỏng vấn những người ra khơi hằng ngày để mài giũa sản phẩm. Kiến thức miền đó cực kỳ đặc thù, và những người đã sống hàng chục năm trong các miền phức tạp biết những điều mà người khác sẽ không bao giờ ngờ tới
Nhà tổng quát phần mềm được mô tả trong bài này cũng có chuyên môn miền. Miền đó là phần mềm
Nếu hiện giờ là một kỹ sư phần mềm tổng quát xuất sắc, bạn sẽ không nhảy bừa sang một miền ngẫu nhiên nào đó chỉ để né AI. Phần mềm là miền của bạn, và bạn sẽ tiếp tục ở trong đó khi miền này mở rộng và biến đổi
Có lẽ tin tốt là ngay cả một kế toán bậc thầy về bảng tính giỏi nhất miền Tây thì cuối cùng vẫn cần một mức độ kinh nghiệm lập trình nào đó để xác minh
Bạn có thể hỏi LLM rằng “đoạn mã này làm gì, và khi Y thì có luôn ra X không”, nhưng như vậy chỉ là lồng một bài toán xác minh vào bên trong một bài toán xác minh khác
Vấn đề cốt lõi ngay từ đầu chưa bao giờ là mã
Sau 5 năm xây phần mềm cho venture capital và private equity, tôi thực sự thấy bài này rất đúng. Viết mã cho đến nay là phần dễ nhất trong công việc của tôi; phần khó là kỹ thuật tài chính và bối cảnh tinh tế cần để hiểu điều mà khách hàng doanh nghiệp thực sự cần
Chúng tôi thường đùa rằng nếu có thể thì muốn tuyển một kế toán quỹ cấp cao rồi dạy họ lập trình. Vấn đề là gần như không có người như vậy. Cũng rất khó để khiến kỹ sư hiểu đủ chi tiết của kế toán quỹ để biến nó thành phần mềm
Thực tế là khoảng một nửa sự nghiệp của tôi là xử lý những thứ kiểu “đủ hiểu miền để đóng ticket hay epic, nhưng rốt cuộc để lại rất nhiều nợ kỹ thuật”
Ví dụ, ngay cả khi có kiến thức miền, con người vẫn mắc sai lầm, không biết cách tốt hơn, không phản ánh được phản hồi, hoặc tệ hơn là không kiểm tra lại những gì coding agent đã viết, nên tôi đã phải review PR rất kỹ
Tôi cũng đã nhiều lần phải refactor những thứ “đúng về mặt kỹ thuật nhưng viết tệ đến mức bị timeout hoặc khiến manager/DBA nổi điên”
Một kỹ sư phần mềm thực sự giỏi có năng lực và ý chí để học miền, nhưng phải có cách để học. Có nơi công ty, đội ngũ hoặc đồng nghiệp tạo điều kiện cho điều đó; cũng có nơi chỉ nói miệng rằng nó quan trọng, còn bạn rốt cuộc chỉ có thể suy đoán từ JIRA và những câu buột miệng của các bộ phận không phải IT trong các cuộc họp
Tôi cho rằng thay đổi mô thức lớn trong 5 năm qua là phần lớn công ty mong mọi người làm việc đến giới hạn, nhưng lại phản tác dụng vì không chừa ra khoảng trống cho những cuộc trao đổi quan trọng
Văn hóa là một biến số rất lớn. Có nơi ít nhất bạn có thể tranh thủ nói chuyện nhanh với người ngồi bên cạnh hoặc dễ dàng đặt lịch họp, nhưng cũng có nơi muốn xin thời gian để thảo luận cho ra hồn thì cứ như phải lập kiến nghị trên change.org vậy
Dù vậy, ý chính vẫn đúng. Cuối cùng thì yêu cầu quan trọng hơn mã. Đã có nơi mọi yêu cầu đều được đáp ứng và đội ngũ đã phê duyệt quyết định thiết kế, nhưng rồi một người vắng mặt suốt quá trình triển khai quay lại và làm chậm tính năng chỉ vì không thích cách nó được viết
Rồi đến lúc nào đó bạn chợt nhận ra “quy trình batch” đang thực hiện %numberOfRecord%*10 lần chèn, cộng thêm các truy vấn bổ sung vì mô hình dữ liệu thiết kế tệ, rồi làm SQL upsert theo cách tệ nhất có thể. Tức là lấy từ DB ra trước, sau đó nếu không có thì thêm bản ghi để chèn. Và trong khi đó, thay vì suy nghĩ lại pattern truy vấn của tầng dữ liệu, người ta cứ tiếp tục làm những việc ngày càng đáng ngờ hơn dưới cái tên “cải thiện hiệu năng”. Tôi đã thấy chuyện đó hơn một lần trong sự nghiệp
Mỗi khi đọc những bài rất chung chung có vẻ như đang đưa ra lời khuyên để ứng phó với AI, tôi lại nghĩ rằng ngành phần mềm giống ngành xây dựng
Nó sẽ không bao giờ thực sự ngăn nắp, cũng không bao giờ được tối ưu hóa hoàn toàn, và luôn buộc phải mang tính tùy biến. Vì nó phải thích ứng với một thực tế nơi gu thẩm mỹ, bối cảnh và tính địa phương khác biệt đến cực đoan
Thỉnh thoảng có thể xuất hiện công cụ hay nguyên vật liệu tốt hơn
Tôi từng nghĩ hào lũy thực sự của phần mềm nằm ở chỗ nó trên thực tế không đòi hỏi kiến thức hay kinh nghiệm quá rộng về cả hệ thống lẫn miền
Khó sao chép hơn nhiều là gu thẩm mỹ và hiệu ứng mạng lưới. Thực tế là ngay cả trước thời vibe coding, các startup được VC rót vốn với rất nhiều nhân lực và tài nguyên cũng hiếm khi giành được chỗ đứng trên thị trường
Vì thế những người ở độ tuổi 20 vẫn có thể cạnh tranh với các chuyên gia trong nhiều lĩnh vực. Tôi cho rằng phản ứng ngược hiện nay là do sự xuất hiện của kiểu người “có X năm kinh nghiệm trong ngành”, vốn rất thường thấy ở các ngành đã trưởng thành khác
Tôi làm nhà phân tích, và trong nhóm của chúng tôi khoảng 20% là các nhà phân tích có năng lực kỹ thuật mạnh, tức năng lực kỹ thuật phần mềm, còn lại là các nhà phân tích truyền thống hoặc chuyên gia miền
Trong năm qua, tôi đã thấy các nhà phân tích không có nền tảng kỹ thuật tận dụng mô hình AI cho phần phát triển và nhờ đó nâng cao năng suất xây dựng công cụ nội bộ
Trước đây gần như mọi thứ đều được phát triển bằng Tableau. Đó là cách dễ tiếp cận nhất để người không phải developer có thể làm ra công cụ chạy được
Mới vài ngày trước, một nhà phân tích trong nhóm chúng tôi đã trình bày công cụ mà anh ấy đang làm, về cơ bản là chuyển một báo cáo Tableau thành một ứng dụng linh hoạt hơn
Tôi nghĩ các công ty BI kiểu này sẽ gặp rắc rối lớn. Đặc biệt là những công ty như Tableau, nơi gần như khiến ngay cả việc vẽ một thứ đơn giản như histogram cũng trở nên bất khả thi, lại càng như vậy
Bạn tôi là kỹ sư điện, gần đây vừa vượt mốc FIDE chess rating 2000. Anh ấy đã chơi cờ suốt 30 năm và còn lập cả câu lạc bộ cờ vua khi học trung học. Ở đại học, anh ấy có đụng đến vi điều khiển nên chỉ học lập trình một chút thôi
Còn tôi thì gần giống một tay làm hạ tầng/quản trị kiêm việc vặt có bằng khoa học máy tính, và đã lập trình như một sở thích suốt 30 năm. Rating Lichess của tôi kể cả vào ngày đẹp trời cũng chỉ là 1000
Chúng tôi từng thi đấu bot cờ vua. Đó là một cuộc đấu tự do: open-book, được phép lập trình bằng AI, và muốn dùng opening book hay endgame table gì cũng được. Tôi đã áp đảo anh ấy hoàn toàn, nhưng ở cờ bàn thực tế thì trong 20 năm tôi chỉ thắng anh ấy đúng hai lần
Ngoài đời, anh ấy sẽ đánh bại 99% người chơi ngẫu nhiên, còn tôi chắc chỉ thắng được khoảng 20%
Tôi cũng không chắc chính xác mình đang muốn nói gì, nhưng có cảm giác rằng giờ đây kiến thức miền có thể không còn là tất cả nữa. Hoặc cũng có thể chính cái miền đó đã thay đổi
Bạn đã thách anh ấy một cuộc đấu lập trình, và bạn — người là lập trình viên giàu kinh nghiệm hơn nhiều — đã thắng. Kể cả có thể dùng AI thì trong trường hợp này, tôi vẫn cho rằng kiến thức miền của chính bạn mới là yếu tố mang tính quyết định