Chuyên môn miền nghiệp vụ 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 đời thực như lương thưởng hay giao thông để tạo ra mô hình miền nghiệp vụ; code là sản phẩm 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ề miền nghiệp vụ, đẩy nút thắt cổ chai từ “có thể tạo ra hay không” sang “có thể đánh giá nó có đúng hay không”
- Các chuyên gia miền nghiệp vụ như điều phối vận tải, nhân viên mã hóa lâm sàng, chuyên viên đị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ó đúng 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 giỏi 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 tri thức miền như mã hóa lâm sàng, họ có thể bỏ sót những lỗi trông rất hợp lý
- Năng lực có giá trị nhất là phán đoán để cùng lúc xác minh độ lành mạnh của code được sinh ra và tính đúng đắn của đầu ra; với kỹ sư dày dạn, đầu tư vào chuyên môn miền nghiệp vụ trở nên quan trọng hơn
Bản chất không phải viết code mà là hiểu miền nghiệp vụ
- Trong phát triển phần mềm, phần khó không phải là viết code mà là trước hết phải dựng được mô hình vận hành của miền nghiệp vụ trong đầu
- Code chỉ là sự chép lại (transcription) của hiểu biết đó; bản thân quá trình đạt được hiểu biết mới là công việc thực sự
-
Ví dụ cụ thể
- Trước khi ra mắt hệ thống tính lương, cần hiểu khấu trừ do cưỡng chế (garnishment), khấu trừ trước thuế, và cách xử lý khi kỳ lương cắt qua thời điểm thay đổi mức lương
- Trước khi ra mắt ứng dụng giao thông công cộng, cần học GTFS feed là gì, vì sao trip và route khác nhau, và vì sao một xe buýt “đúng giờ” vẫn có thể sai
Agentic AI đã cắt đứt mắt xích đó
- Agentic AI cắt đứt mối liên kết giữa việc xây dựng mô hình và sản xuất phần mềm, khiến việc tạo phần mềm trở nên khả thi ngay cả khi không có mô hình
- Điều này làm sụp đổ tiền đề mà cả nghề nghiệp này từng được tổ chức dựa trên đó
- Quan điểm năm ngoái cho rằng công cụ này khuếch đại các lập trình viên senior có năng lực phán đoán; điều đó đúng nhưng chưa đầy đủ
- Thay đổi thực sự được quan sát là ràng buộc cốt lõi đã chuyển từ “có thể tạo ra hay không” sang “có thể xác định nó có đúng hay không”
So sánh hai kiểu người
-
Chuyên gia miền nghiệp vụ (không có nền tảng phần mềm)
- Là những người như điều phối vận tải, nhân viên mã hóa lâm sàng, chuyên viên định phí bảo hiểm; họ không đọc được stack trace và cũng không giải thích được sự khác nhau giữa hashmap và list
- Nhưng khi nhìn vào lịch do tác tử tạo ra, họ có thể lập tức nhận ra không tài xế nào có thể làm ca đó một cách hợp pháp, hoặc khoản thanh toán theo bộ mã đó sẽ không bao giờ được chi trả
- Vì đã sống 10 năm giữa đầu vào và đầu ra, họ biết đầu ra đúng cho một đầu vào nhất định là gì, và tác tử bù đắp chính xác phần năng lực sản xuất code mà họ còn thiếu
- Điều họ mang lại là ground truth mà tác tử không thể cung cấp
-
Kỹ sư generalist mạnh nhưng không có kinh nghiệm miền nghiệp vụ
- Có thể thiết kế mọi thứ, hiểu cách đảm bảo độ tin cậy, kiểm thử, và giữ cho hệ thống không sập lúc 2 giờ sáng
- Nhưng khi bị đưa vào mã hóa lâm sàng, họ không thể phân biệt đáp án sai nhưng có vẻ hợp lý với đáp án đúng
- Tác tử tạo ra một quy tắc thanh toán sai (billing rule) tinh vi và tốn kém nhưng vẫn biên dịch được và vượt qua các bài test mà nó tự viết
- Kỹ sư không có oracle, nên có thể xác minh phần mềm được xây tốt hay không nhưng không thể xác minh nó có chính xác hay không — vì tính chính xác được định nghĩa bởi một miền nghiệp vụ mà anh ta không có trong đầu
Sự bất đối xứng khi chỉ một con đường bị sụp đổ
- Trước thời tác tử, kỹ sư có một con đường mà điều phối viên không có — họ có thể theo chân chuyên gia, đọc đặc tả và va vấp trong môi trường vận hành để từ từ lĩnh hội mô hình miền nghiệp vụ
- Trong nhiều lĩnh vực, con đường này chính là nấc thang sự nghiệp (career ladder), còn chuyên gia miền nghiệp vụ thì không có một con đường tương đương để học cách xây phần mềm đáng tin cậy trong nhiều năm
- Công cụ tác tử chỉ làm sụp đổ một trong hai con đường đó
- Thế mạnh của kỹ sư trong việc chuyển mô hình miền sang code giờ đã trở nên rẻ (cheap)
- Thế mạnh của chuyên gia miền nghiệp vụ trong việc biết điều gì là đúng thì không như vậy, và không thể đạt được chỉ bằng prompt
- Không tồn tại tệp kỹ năng nào chứa tri thức ngầm (tacit knowledge) của một người đã xử lý hàng nghìn bảng lương
Nhân sự có thể kiểm chứng cả hai tầng
- Trong thế giới mới, người có giá trị nhất là người sở hữu cả hai kỹ năng để kiểm chứng ở cả hai tầng
- Họ biết code được sinh ra là vững chắc, đồng thời biết câu trả lời mà code đó đưa ra là đúng
- Vì biết quy tắc, họ có thể viết test mã hóa điều kiện “tài xế không được vượt quá 11 giờ”, và vì biết mình đang test điều gì nên cũng phân biệt được bài test đó có ý nghĩa hay không
- Tác tử đảm nhận việc chép lại, còn con người đảm nhận hai lần phán đoán (judging, twice)
Hướng đặt cược cho các kỹ sư giàu kinh nghiệm
- Với những kỹ sư dày dạn đang suy nghĩ nên đầu tư vào đâu trong vài năm tới, đây là hướng đặt cược
- Kỹ năng cơ học (mechanical skill) trong việc biến ý tưởng rõ ràng thành code sạch sẽ sẽ sụt giảm giá trị một cách mạnh mẽ
- Thứ vẫn còn khan hiếm là mô hình sâu và đã được kiểm chứng về một miền thực tế nào đó, và đó là thứ cần giành lấy
- Hãy chọn một trong các lĩnh vực như ngành công nghiệp, sản phẩm tài chính, khung pháp lý, hay quy trình vật lý, rồi học miền đó như cách trước đây từng học ngôn ngữ lập trình hay framework
- Đây là phần mà tác tử không thể làm thay, và giờ cũng là phần mang giá trị lớn nhất
7 bình luận
Nhưng tôi cũng nghĩ điều này hơi xem nhẹ code quá mức.
Bản thân việc phát triển phần mềm cũng là một lĩnh vực chuyên môn, và làm tốt việc đó cũng là một kỹ năng chuyên môn.
Dù phần mềm do AI tạo ra có thể giải quyết được về mặt chức năng, nó vẫn không thể hoàn thiện trọn vẹn, và cũng như vẫn cần có người lấp đầy phần đó vậy
Tôi có phần hơi phản đối quan điểm của xguru.
Lấy Excel làm ví dụ nhé. Thông thường khi làm việc ở công ty sẽ có một mức độ thành thạo cần thiết, và khi vượt qua mức đó thì phần lớn mọi người sẽ không còn muốn học thêm nữa. Dĩ nhiên cũng có những người dùng Excel cực kỳ điêu luyện, nhưng đó thực sự là trường hợp rất ngoại lệ.
Với code cũng vậy — dù hiện tại chưa phải thế — tôi từng nghĩ có lẽ rồi nó cũng có thể tách thành hai nhánh như vậy: một nhóm nhỏ làm ra những sản phẩm thực sự phức tạp, và số đông còn lại thì sử dụng nó như đi xe đạp.
Hửm? Đâu phải người giỏi dùng Excel bị xem thường.
Nhưng nói rằng bản thân việc viết code đã trở nên kém giá trị thì lại mang cảm giác coi nhẹ đấy.
Tôi nghĩ không nên nói với những người làm ra sản phẩm phức tạp rằng chỉ vì dùng nó như đi xe đạp nên giá trị của bạn chẳng đáng bao nhiêu.
Tôi đồng ý với điểm bạn nêu,
đó là câu chuyện về việc kỹ thuật và mã nguồn đủ để được gọi là phần mềm phức tạp sẽ giảm đi. Nếu những thứ có thể được AI viết nhanh một cách nhẹ nhàng ngày càng nhiều.
Mượn cách diễn đạt trong bản tóm tắt của GeekNews: có vẻ như lượng mã mà agent không thể thay thế sẽ ngày càng giảm.
Giống hệt với ý kiến trong phần bình luận trên Hacker News:
Phần đó là trạng thái mà tri thức ngầm gần như đã biến mất, và khi các chuyên gia domain hàng đầu thiết kế agent rồi nhúng vào mô hình,,, nên dù hiện tại tầm quan trọng của tri thức domain đang được nhấn mạnh, tôi cũng không chắc sau 1 năm nữa người ta có còn đưa ra lập luận như vậy không. Rốt cuộc tri thức ngầm đang dần được chuyển thành prompt, và các mô hình sẽ chọn lọc phần tri thức ngầm được người dùng thêm vào prompt rồi lại đưa nó vào mô hình. Các mô hình agent có tri thức ngầm được nhúng sẵn thì sẽ có giá trị, nhưng tôi nghĩ ngay cả thứ này cũng sẽ được giao dịch trên thị trường. Những agent có tri thức domain phong phú hơn nhiều trong lĩnh vực đó.
Có lẽ sau 1 năm nữa, vượt qua cả orchestration, việc “quản trị agent” (như một công ty) sẽ trở thành tiêu chí đánh giá.
Ý 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