Cuộc phản công của lập trình viên junior
(sourcegraph.com)Phần 1: Sáu làn sóng coding AI
- Vibe coding là một biệt danh vui cho cách lập trình dựa trên hội thoại, trong đó bạn yêu cầu LLM viết mã rồi lặp lại bằng cách phản hồi kết quả
- Đây là một khái niệm rất khác với kiểu lập trình truyền thống hay lập trình xoay quanh tự động hoàn thành; ban đầu nó được dùng mà chưa có định nghĩa rõ ràng, nhưng sau khi Andrej Karpathy gọi nó là “vibe coding” thì đã lan rộng rất nhanh
- Hiện tại, vibe coding đồng thời tồn tại trong ba trạng thái sau:
- 80% trong ngành thậm chí còn không biết vibe coding tồn tại, nhiều người còn lần đầu nghe thấy cả cụm “coding agent”
- Đang bùng nổ mạnh mẽ trên truyền thông và SNS, dù có tranh cãi và nhiều ý kiến trái chiều, rất nhiều lập trình viên vẫn xem đây là công nghệ của tương lai
- Coding dựa trên chat kiểu cũ đã bị xem là công nghệ lỗi thời, một số lập trình viên hứng khởi với các cách làm mới nhanh hơn đến mức không còn hứng thú với chat nữa
- Bài viết này mô tả các giai đoạn phát triển của coding dựa trên AI qua tổng cộng sáu làn sóng:
- Coding truyền thống (2022)
- Coding dựa trên tự động hoàn thành (2023)
- Coding hội thoại (2024)
- Coding agent (nửa đầu 2025)
- Agent cluster (nửa cuối 2025)
- Agent fleet (2026)
- Trong số này, coding truyền thống và coding dựa trên tự động hoàn thành đang dần suy tàn, còn các cách xuất hiện sau đó thì mỗi cách lại lan rộng với tốc độ còn nhanh hơn
- vibe coding được thể hiện riêng như một đường nét đứt bên cạnh các làn sóng này
- vibe coding cùng tồn tại trên tất cả các cách làm ở trên và không phải một phương thức cụ thể, mà là khái niệm bao trùm toàn bộ những tình huống AI viết phần lớn mã
- “Agent cluster” sắp xuất hiện là khái niệm quản lý nhiều agent song song, còn “agent fleet” sẽ mở rộng thành cấu trúc trong đó AI manager giám sát các agent cấp dưới
- Sơ đồ tổ chức FY26 mô tả điều này: một lập trình viên vận hành nhiều nhóm agent, mỗi nhóm đảm nhiệm các vai trò khác nhau như sửa lỗi, phát triển tính năng mới, tái cấu trúc kiến trúc
- Hiện tại, khi agent dừng lại hoặc đi sai hướng thì con người vẫn phải trực tiếp can thiệp, nhưng sắp tới supervisor agent sẽ thay thế vai trò đó
- Cuối cùng, chúng ta sẽ có thể xử lý đồng thời hàng chục agent trở lên, biến nó thành một hệ thống tự động hóa để xử lý lượng lớn mã legacy
- Những agent fleet như vậy gần như chắc chắn sẽ xuất hiện trước đầu năm 2026, và công nghệ để tổ chức công việc song song hiệu quả thì đã sẵn sàng
Phần 2: Bạn đang ở đâu lúc này?
- Nếu bạn vẫn chỉ dùng AI như công cụ tự động hoàn thành mã hoặc vẫn coi trọng Completion Acceptance Rate (CAR), thì bạn đang nằm trên đường cong lập trình truyền thống trong Figure 1
- Đường cong này được dự đoán sẽ biến mất hoàn toàn vào khoảng năm 2027
- Tự động hoàn thành còn rất được ưa chuộng chỉ một năm trước, nhưng giờ không còn là công nghệ cốt lõi nữa
- Nếu bạn ở vị thế tiến bộ hơn, có thể bạn đang tận dụng các công cụ coding dựa trên chat trong IDE như Copilot, Cursor, Sourcegraph, Windsurf
- Trường hợp này là một vị trí khá ổn, vì bạn đã áp dụng cách làm năng suất hơn nhiều so với tự động hoàn thành mã
- Coding dựa trên chat vẫn còn rất nhiều người dùng, nhưng không còn là chuẩn của công nghệ mới nhất
- Các coding agent mới xuất hiện gần đây (Aider.chat, Claude Code, v.v.) đang cho thấy khả năng lấn át tất cả những cách làm này
- Chúng sẽ được tích hợp tự nhiên vào IDE và nhanh, hiệu quả hơn rất nhiều so với cách làm dựa trên hội thoại trước đây
- Một khi đã dùng agent, bạn sẽ rất khó quay lại cách cũ
- Coding dựa trên agent cũng là một dạng vibe coding
- vibe coding có nghĩa là “mọi cách AI viết mã”, chứ không phải một modality công nghệ cụ thể
- Điểm khác là agent có thể tự làm việc mà không cần hội thoại thường xuyên
- Sự thay đổi giữa các cách coding cho thấy mô hình bội số năng suất như sau:
- Coding dựa trên chat năng suất hơn làm thủ công khoảng 5 lần
- Coding dựa trên agent có thể lại năng suất hơn chat thêm 5 lần
- Mỗi làn sóng theo thời gian đều có thể đạt năng suất gấp 10 lần, nhưng đường cong bị làm phẳng vì công nghệ mới xuất hiện ngày càng nhanh
- Hiện tại chúng ta đang ở giữa một đại dương AI khổng lồ và buộc phải cưỡi lên những con sóng ngày càng mạnh hơn này
- Mọi công ty đều đang nằm trên ít nhất một trong các đường cong áp dụng ở Figure 1
- Điều cần thiết là tự hỏi bản thân mình đang đứng trên đường cong nào
- vibe coding không phải một phương thức kỹ thuật cụ thể mà là một triết lý và thực tế phát triển mới
- Trọng tâm là bạn không còn trực tiếp viết mã nữa
- Việc viết mã được giao cho AI, còn con người chuyển sang vai trò chỉ xem xét và điều phối kết quả
- Ở phần tiếp theo, bài viết sẽ xem xét những tác động tài chính của thay đổi công nghệ này
- Coding agent không phải phép màu mà là một cấu trúc càng đốt chi phí càng thông minh hơn
- Nếu bạn chưa thử, điều quan trọng là hãy dùng thử ngay hoặc quan sát người đang sử dụng nó
Phần 3: Hướng dẫn sử dụng con lạc đà mới
- Các coding agent mới nhất là công nghệ cực kỳ mới chỉ xuất hiện cách đây vài tuần, và phần lớn hoạt động trên nền tảng terminal
- Nếu ví von thì giống như cả đời đi bộ rồi bỗng được giao cho một con lạc đà: tiện thật, nhưng khó điều khiển và rất tốn tiền
- Chỉ cần có “một con” thôi cũng đã nhanh hơn đi bộ rất nhiều, nhưng nó cũng có thể phun nước bọt, cắn bạn rồi bỏ chạy
- Nhiều lập trình viên vẫn còn hoài nghi về AI coding và vẫn muốn tự tay viết mã
- Một số thậm chí còn khẳng định rõ ràng rằng “Tôi là người viết code!”
- Nhưng kiểu suy nghĩ đó giờ đã tụt lại sau thực tế
- Càng hoài nghi thì càng được khuyên nên tải về và dùng thử coding agent mới nhất (phát hành sau ngày 1/3) ngay lập tức
- Chỉ vài tuần trước, chính tác giả cũng đã trực tiếp chứng kiến mức tiến bộ đến mức đáng kinh ngạc
- Agent có cùng nguyên lý với vibe coding, nhưng con người không cần phải trực tiếp qua lại prompt
- Nó tự thực hiện các công việc phức tạp, và chỉ liên lạc lại với người dùng khi hoàn thành hoặc khi phát sinh vấn đề
- Vì nó tự động thực hiện 90–99% toàn bộ công việc, con người được giải phóng khỏi nút thắt cổ chai
- Điểm khác với cách làm dựa trên chat:
- Agent có thể xử lý đơn vị công việc lớn hơn trong một lần
- Trong thời gian đó, lập trình viên có thể tự do làm việc khác (ví dụ: ăn vặt, đọc Hacker News)
- Ví dụ: chỉ cần nói “Hãy giải quyết ticket JIRA này”, thì nó sẽ
- Tự tìm hiểu JIRA CLI và yêu cầu cài đặt nếu cần
- Viết chương trình tạm để đọc các trường trong ticket
- Phân tích mã → phát hiện bug → đề xuất sửa → viết và chạy test → lặp vòng
- Kết quả là agent giống như một lập trình viên con người làm việc với tốc độ chói sáng, chỉ là hơi thiếu định hướng
- Nhược điểm:
- Hiện tại nó vẫn chỉ có thể xử lý ổn định các công việc quy mô nhỏ
- Kỳ vọng quá mức sẽ dẫn đến thất bại, và năng lực phân rã công việc (task decomposition) là điều bắt buộc
- Công việc quá lớn thì nó sẽ không thực hiện đúng được và sẽ bị lạc hướng
- Vì vậy ở thời điểm hiện tại, vẫn cần chọn vấn đề tinh tế và giám sát chặt chẽ, và phải đối xử với agent như một con vật bướng bỉnh
- Nhưng tình hình này cũng sẽ sớm thay đổi:
- Agent sẽ sớm được tích hợp tự nhiên vào IDE, phát triển thành công cụ dễ dùng và quen thuộc hơn
- Từ lạc đà sẽ tiến hóa thành ngựa có yên, và chẳng bao lâu nữa là thành chiến xa (chariot)
- Kết luận: đây là thời điểm tối ưu để học cách làm việc cùng agent,
- và sắp tới sẽ còn xuất hiện thêm nhiều tính năng hơn, giao diện tốt hơn, cùng mức tăng năng suất lớn hơn
Phần 4: Bảo là không có toán mà
- Phần này dành cho CIO và người phụ trách tài chính
- Vừa mới chốt ngân sách FY26 xong, vậy bạn đã phân bổ chi phí sử dụng LLM bao nhiêu cho mỗi lập trình viên?
- $25 mỗi ngày nghe có vẻ khá táo bạo, nhưng thực ra đã gần với mức hợp lý
- Thực tế còn nghiêm trọng hơn:
- Coding agent rất đắt — tiêu tốn token ở mức khoảng $10–12 mỗi giờ
- Nếu giấy phép coding assistant trước đây chỉ khoảng $30 mỗi tháng, thì đây có nghĩa là chênh lệch chi phí lên tới hàng chục lần
- Nhưng nếu tính toán ra, khi dùng coding agent 8–10 giờ mỗi ngày thì nó có mức năng suất tương đương thuê 1 lập trình viên junior
- $10 mỗi giờ là cực kỳ rẻ, và một lập trình viên còn có thể chạy đồng thời hai agent
- Nếu chi khoảng $100 mỗi ngày cho LLM thì năng suất của lập trình viên có thể tăng hơn gấp đôi
- Tuy nhiên, thay đổi thực sự sẽ đến từ agent cluster (dự kiến Q3/2025) sắp xuất hiện
- Một lập trình viên có thể vận hành song song nhiều agent
- Mỗi agent sẽ độc lập thực hiện nhiều loại việc khác nhau như sửa lỗi, phát triển tính năng mới, viết tài liệu
- Kết quả là một lập trình viên sẽ hành xử như thể đang đảm nhận vai trò của nhiều lập trình viên
- Dĩ nhiên, người càng thành thạo thì hiệu quả càng lớn
- Sự xuất hiện của agent cluster sẽ là cú hích đưa môi trường phát triển phần mềm chuyển lên cloud
- Hàng chục đến hàng trăm agent là thứ desktop cục bộ không thể xử lý được
- Môi trường phát triển dựa trên cloud sẽ gần như trở thành tiêu chuẩn
- Vì vậy, cũng cần bảo đảm thêm ngân sách cloud
- Ví dụ, nếu một lập trình viên chạy 5 agent:
- $50 mỗi giờ → khoảng $100,000 mỗi năm (chưa gồm chi phí cloud)
- Đây không còn là “khoản đầu tư rẻ” nữa mà là một mức chi đáng kể
- Tuy nhiên, vì năng suất có thể tăng hơn 5 lần, về dài hạn vẫn có thể kỳ vọng ROI cao
- Vấn đề là phần lớn doanh nghiệp có lẽ chưa đưa các chi phí LLM này vào ngân sách vận hành năm 2026
- Điều này sẽ làm khoảng cách giữa các doanh nghiệp nới rộng: công ty có ngân sách sẽ giành lợi thế công nghệ, còn công ty không có thì có nguy cơ bị tụt lại
- Kết luận:
- Phát triển phần mềm giờ đã là chuyến tàu siêu tốc pay-to-play
- Nếu không có vé (ngân sách), nguy cơ bị văng khỏi đoàn là rất lớn
Phần 5: Agent fleet đang đến
- Từ đây trở đi là một sự thật hơi khó chịu
- Nếu chưa chuẩn bị tinh thần, nên tạm nghỉ một chút rồi quay lại đọc tiếp
- Bước tiếp theo của agent cluster là “agent fleet”, tức môi trường trong đó lập trình viên vận hành đồng thời hơn 100 agent
- Lúc này sẽ xuất hiện supervisor agent điều khiển ở cấp trên để quản lý các nhóm agent cấp dưới, và con người chỉ can thiệp khi có vấn đề phát sinh
- Vai trò của lập trình viên trong tương lai sẽ không còn là người viết mã nữa, mà là
- vận hành và giám sát dashboard nơi hiển thị các agent và AI manager
- Một số người có thể mỉa mai đây là “trông trẻ AI”, nhưng đó sẽ sớm là diện mạo của phát triển phần mềm mới
- Từ góc nhìn CIO, trong thời đại agent fleet, chi phí LLM mỗi ngày cho mỗi lập trình viên có thể lên tới hàng nghìn đô la
- Dù chi phí suy luận có giảm đi, theo nghịch lý Jevons thì mức tăng sử dụng sẽ bù trừ phần tiết kiệm chi phí
- Ví dụ: hãy nghĩ đến việc backlog bug của bạn là vô tận
- Nhưng đây không phải lãng phí mà là một khoản đầu tư mang lại giá trị khổng lồ
- Cuối cùng thì tổ chức engineering cũng có thể di chuyển với tốc độ mà ban điều hành mong muốn
- Chúng ta bước vào thời đại có thể làm khách hàng ngạc nhiên và hài lòng với sự linh hoạt như một startup
- Nhược điểm là cần ngân sách cực lớn
- Một số tập đoàn lớn đã có sẵn ngân sách thử nghiệm LLM dưới dạng slush fund, nhưng
- nhiều công ty rất có thể hoàn toàn chưa tính đến điều này trong kỳ lập ngân sách lần này
- Một số tập đoàn lớn đã có sẵn ngân sách thử nghiệm LLM dưới dạng slush fund, nhưng
- Nếu đến cuối năm mà không bảo đảm được $50,000 ngân sách bổ sung cho mỗi lập trình viên, có thể sẽ không còn lựa chọn nào ngoài tái cơ cấu
- Thay đổi này ngược lại có thể có lợi cho startup linh hoạt
- Chúng ta đang bước vào thời đại mà sự có hay không có ngân sách quyết định năng lực cạnh tranh của doanh nghiệp, hơn cả khoảng cách công nghệ
- Và nếu không thể xoay ra ngân sách, thì bộ phận duy nhất có thể bị cắt giảm là bộ phận nào gần như đã quá rõ
- Câu trả lời xin để người đọc tự phán đoán
- May mắn là dự đoán này cũng có thể hơi phóng đại
- Sau khi thảo luận với Claude (LLM), tác giả cho rằng nếu lùi dự đoán lại khoảng 6 tháng thì có thể sẽ thực tế hơn
- Tin tốt là mọi thứ bắt đầu từ bây giờ
- Tin xấu đã hết, và giờ chỉ còn lại một điều: cuộc báo thù ngọt ngào
Phần 6: Cuộc báo thù của lập trình viên junior
- Tương lai không hề u ám. Trái lại, ngành phần mềm vẫn còn rất nhiều việc làm
- Chỉ có điều, vai trò lập trình viên truyền thống tự tay viết mã sẽ biến mất
- Một trong những mẫu hình quan sát được trong năm qua là lập trình viên junior chủ động tiếp nhận AI mạnh hơn rất nhiều so với senior
- Một số người lo AI sẽ cướp việc của mình, nhưng phần lớn đang thích nghi rất nhanh với thay đổi
- Họ học cuốn AI Engineering của O’Reilly và sử dụng thành thạo chat coding lẫn coding agent
- Trong khi đó, các lập trình viên senior thì phần lớn gần như chưa từng thực sự dùng LLM, hoặc chỉ trải nghiệm một cách gián tiếp
- Thậm chí còn có những trường hợp thể hiện sự bài xích công khai với công nghệ AI
- Ví dụ: một lập trình viên ở công ty nổi tiếng đã nộp bản slide PDF với nội dung “hãy từ bỏ AI và quay về coding truyền thống”
- Những phản ứng như vậy bắt nguồn từ sự bất an trước công nghệ mới và cảm giác mất mát khoản đầu tư vào tri thức cũ
- Việc học ngôn ngữ hay công cụ mới về bản chất luôn đi kèm nỗi sợ ‘phải bắt đầu lại từ đầu’
- Nhưng thực tế rất rõ ràng:
- Những ai làm ngơ AI đã bị tụt lại khỏi cuộc chơi
- Lập trình viên junior rẻ hơn, thích nghi tốt hơn và học nhanh hơn
- Khi doanh nghiệp phải điều chỉnh lực lượng kỹ sư, chuyện họ sẽ chọn kiểu lập trình viên nào gần như là điều hiển nhiên
“AI không cần chứng minh nó giỏi hơn bạn. Điều quan trọng là bạn phải biết dùng AI giỏi hơn.”
- Nói cách khác, giờ đây lập trình viên junior đang ở vị thế cầm kiếm ánh sáng trên đỉnh đồi,
- và đang hét lên với các senior rằng hãy thích nghi với thay đổi
- Bài học có thể rút ra từ toàn bộ tình hình này là:
- Dù bạn là ai, là công ty hay cá nhân — hãy hành xử như một junior
- Bây giờ chính là lúc đón nhận và thích nghi với công nghệ AI
- Sourcegraph phân tích dòng tiến hóa công nghệ này mỗi ngày,
- và việc kết nối coding agent với tài sản mã doanh nghiệp là chiến lược cốt lõi của thế hệ tiếp theo
- Xét tổng thể, khi mức độ áp dụng AI tăng lên thì việc làm liên quan đến phần mềm thực ra còn có thể tăng thêm
- Việc tuyển dụng đang chững lại hiện nay chỉ đơn giản là vì doanh nghiệp vẫn chưa biết phải phản ứng thế nào nên còn thận trọng
- Trong lịch sử, mỗi giai đoạn chuyển đổi công nghệ đều kéo theo năng suất tăng vọt và GDP cũng đi lên
- Vì vậy, điều cần làm lúc này là:
- Học và làm quen với coding agent
- PM hay các vị trí kỹ thuật khác cũng không ngoại lệ
- Phát triển dựa trên LLM không chỉ là viết prompt. Nó sẽ thay đổi thực tế công việc phát triển như xác minh, kiểm thử, điều phối
- Cảnh báo:
- Coding agent rất mạnh, nhưng nó là một công cụ giống máy đào hầm
- Nó đắt đỏ, có thể dừng lại, có thể lạc hướng
- Cần được hướng dẫn liên tục và phải đặt kỳ vọng thực tế
- vibe coding đúng như cái tên của nó, là một cách làm việc vui vẻ
- Việc không phải tự tay viết code mang lại cảm giác giải phóng đáng ngạc nhiên
- Kiểu suy nghĩ “6 tháng nữa nó sẽ tốt hơn nên giờ cứ chờ đã” là rất nguy hiểm
- Kết cục là xuất phát muộn hơn và đến đích cũng muộn nhất
- Agent đang đến. Không chỉ là coding agent, mà
- hàng trăm task agent trên toàn doanh nghiệp đã bắt đầu được triển khai
- Chỉ dẫn hành động mang tính kết luận:
- chuyển sang chat
- bỏ tự động hoàn thành
- giảm coding thủ công
- học cách xác minh/đánh giá/thực thi phù hợp với môi trường dựa trên AI
- tiếp tục thử nghiệm và áp dụng theo dòng công nghệ mới nhất
- Ngay cả coding agent hiện giờ còn trông khó dùng và chưa hoàn hảo thì chẳng bao lâu nữa cũng sẽ trở nên phổ biến
- Đó là cỗ máy năng suất rẻ hơn con người rất nhiều, và lựa chọn của doanh nghiệp là quá rõ ràng
- Đến cuối năm 2025, vai trò “software engineer” sẽ gần như không còn trực tiếp code nữa
- Thay vào đó, công việc trọng tâm sẽ là vận hành agent, điều phối và quản lý xác minh
- Cuối cùng: nếu bạn không biết mình nên làm gì lúc này, hãy nhờ một lập trình viên junior giúp đỡ
Đã hai năm kể từ khi tác giả viết ‘Cheating is all you need’, và trong khoảng thời gian đó, mọi thứ đã thay đổi hoàn toàn
Đây chính là trung tâm của thay đổi, và là lúc phải bước lên con sóng này
23 bình luận
Điều này thật sự khá bức bối
Trước đây: suy nghĩ => code (chậm) => debug
AI: suy nghĩ => viết prompt tinh vi => code (cực nhanh) => debug
Nhưng thường thì viết ý nghĩ của mình thành code lại nhanh hơn viết thành prompt, đúng không? Trừ khi là làm thứ gì đó vốn đã quá quen thuộc... Với những phần mà độ tin cậy là quan trọng thì đằng nào sau khi viết xong cũng phải tự nhìn logic bằng mắt để nắm được, nên cũng chẳng thể giao phó, mà khoảnh khắc giao phó thì lại thành ra không còn tinh thần nghề nghiệp nữa.
Dù là một quản lý xuất thân từ lập trình viên và không còn trực tiếp phát triển phần mềm nữa, dạo gần đây tôi lại có cảm giác như mình trở thành junior một lần nữa khi tự tay thử làm cái này cái kia. Giờ đến những việc trước đây giao cho thành viên trong nhóm cũng tự mình làm thử, nên tốc độ tăng lên quá nhanh khiến tôi cũng hơi bối rối. Tôi cũng nghĩ rằng ngay cả với một đội nhỏ, mình vẫn có thể thử làm được nhiều thứ hơn. Cảm ơn vì công cụ và phần giải thích rất hay!
Hiện giờ tôi đang coi như làm cho vui bằng vibe coding để phát triển client, server và admin của một web game (thậm chí tôi cũng không tự sửa trực tiếp; chỉ cần chép phần cần sửa rồi yêu cầu chỉnh sửa, sau đó áp dụng nguyên xi đoạn code được trả về), đến nay đã khoảng 20.000 dòng rồi. Thỉnh thoảng cũng bực thật, nhưng nếu vừa cáu vừa đặt câu hỏi thì đến giờ nó vẫn cho ra code khá ổn.
Tôi đồng cảm với hơn 90% nội dung của bài viết này.
Có vẻ như chắc chắn đang đến những thời điểm mà năng lực và mô hình phát triển phần mềm sẽ thay đổi.
Giờ đây, xét từ khía cạnh năng lực điều phối, tôi nghĩ cần chú trọng hơn đến nhiều design pattern, cách xây dựng ứng dụng mang tính tổng quát và các phương pháp luận để giải quyết vấn đề.
Việc phát triển thuật toán từ lâu đã vượt qua giới hạn của con người, và cũng giống như việc AI đang thực hiện tối ưu hóa thuật toán mà con người không thể hiểu được, các nhà phát triển trong tương lai là lúc cần tập trung vào phạm vi rộng hơn và nhiều xu hướng hơn.
Việc học AI là quan trọng, nhưng tôi nghĩ không cần phản ứng thái quá mỗi khi có công nghệ mới xuất hiện. Đầu tư nhiều thời gian hơn vào những khái niệm cốt lõi không thay đổi sẽ hiệu quả hơn, và vì AI tương đối dễ học nên có thể tiếp cận từ từ cũng được. Thay vì lúc nào cũng chạy theo, tôi cho rằng điều quan trọng là bồi dưỡng năng lực cốt lõi.
Bây giờ vẫn làm tốt hơn kha khá người. Vì học từ code của các bậc thầy open source nên nếu biết đặt câu hỏi cho khéo thì chất lượng đầu ra cũng khá ổn haha
Không ai biết công nghệ AI cốt lõi sẽ phát triển đến mức nào. Ở trình độ hiện tại thì còn chưa tới đâu cả
Nếu xét ở khía cạnh giá trị của kiến thức hay kinh nghiệm tích lũy đang giảm xuống, có lẽ ranh giới giữa senior và junior tự thân nó sẽ trở nên mơ hồ hơn.
Và có vẻ thị trường sẽ trở thành nơi thiểu số chiếm hết. Về sau, việc tuyển dụng lập trình viên có lẽ sẽ chuyển theo hướng chọn những AI pilot có năng lực tư duy và suy luận bẩm sinh vượt trội hơn là dựa vào mức độ nỗ lực bỏ vào hay số năm kinh nghiệm.
Agent giám sát à..
Nếu giai đoạn phát triển có khoảng 4 bước (phát triển, debug, QA và debug, refactoring), liệu có thể bắt hết các ảo giác xảy ra ở cả 4 lớp đó không..
Ngay cả bây giờ, dù đã viết rất chi tiết trong prompt các yêu cầu về debug và test, thỉnh thoảng nó vẫn buột ra mấy câu vô nghĩa kiểu không biết vấn đề là gì (Sonnet 3.7).
Trừ khi chính kiến trúc Transformer thay đổi thì may ra.
Lý do tôi khó đồng tình với vibe coding là vì các AI agent vẫn chưa giải quyết được thực tế rằng chúng ta vẫn phải làm việc dựa trên code. Nếu là một môi trường nơi agent vận hành tự chủ, thì tại sao vẫn cần đến code, thứ vốn khó để máy hiểu?
Tôi nghĩ khoảnh khắc AI agent thực sự thay đổi bộ mặt của phát triển phần mềm chính là lúc nó hoàn toàn trừu tượng hóa tầng code đối với người dùng đang điều phối nó. Hiện tại, tôi cho rằng nó vẫn chỉ mới ở mức tạo ra các mảnh code một cách nhanh chóng mà thôi (dĩ nhiên, bản thân điều này cũng đã rất ấn tượng).
Cho đến khi AI agent mang lại cho chúng ta sự giải phóng khỏi code, thì dù sự thay đổi có đáng kinh ngạc đến đâu, tôi vẫn khó đồng ý với nhận định rằng nó sẽ làm thay đổi một cách mạnh mẽ phương thức làm việc của ngành phần mềm.
Tôi nghĩ điều này cũng tương tự như việc Hyundai Motor đưa vào vận hành megafactory.
Người lao động truyền thống rồi sẽ chuyển sang vai trò thiết lập và bảo trì. (Phần này thì tôi hiểu hơn một chút.)
Tuy vậy, liệu ngay cả phần xử lý trong lĩnh vực trừu tượng cũng sẽ diễn ra như vậy chăng?
Cá nhân tôi cho rằng là có thể.
Mình vẫn thỉnh thoảng bị rối khi viết theo thứ tự bảng chữ cái với các cặp nhóm pattern hơi phức tạp.. (làm ơn !!) Lười gõ bàn phím quá điii
Nếu không tính phần cuối về junior thì nhìn chung tôi cũng khá đồng ý.
Có lẽ sẽ chính xác hơn khi nói rằng những senior hay các công ty hiện tại không chấp nhận AI sẽ bị thay thế theo thế hệ.
Các sản phẩm triển khai phát triển quan trọng của công ty gần như 100% là không công khai trên Internet. Với trình độ AI hiện tại thì không thể tạo ra chất lượng ở mức đó. Vớ vẩn.
Nếu có kiến thức và năng lực tương tự nhau thì trong một môi trường phù hợp, kết quả đưa ra chắc cũng sẽ tương tự thôi.
Phát triển phần mềm đâu chỉ có các ứng dụng web là nơi có tương đối nhiều tài liệu được công khai; từ engine đồ họa đến embedded, rồi cả thiết kế chip mức thấp, lĩnh vực này cực kỳ đa dạng. Có rất nhiều mảng phải bắt đầu từ con số 0 hoặc gần như số 0. Ngay cả trong lĩnh vực của tôi, trên GitHub, trong tài liệu hay trên Internet cũng không có gì thực sự đáng tin để tham khảo. Đương nhiên Grok hay Claude cũng không cho ra kết quả tử tế. Chuyện cung cấp toàn bộ mã nguồn cho model hay fine-tuning thì xin phép không bàn tới.
Có lẽ bạn không làm kiểu phát triển đòi hỏi chuyên môn như vậy, hoặc trong công ty không có tài sản bị cấm lộ ra ngoài, nhưng tốt hơn là đừng quá chắc chắn rằng bản thân đã nắm chính xác tình huống.
Lập luận rằng nếu không có trên Internet thì AI không thể xâm phạm được nghe có vẻ hơi kỳ lạ, đúng không? Tôi đã nghĩ rằng khi nghiên cứu về phương pháp học tiếp tục tiến triển, AI in-house sẽ thay thế vị trí của các lập trình viên in-house.
Ý bạn là vấn đề không phải là Internet, mà là không có dữ liệu để huấn luyện nhằm tạo ra mô hình AI, đúng không.. Vậy tại sao lại xuất hiện nghiên cứu về phương pháp học? Tôi đang nói về hiện thực vật chất ngay lúc này. Đến cuối năm 2025, tuyệt đối không thể tạo ra AI thay thế mọi lập trình viên. Ngay từ đầu đó không phải là vấn đề hiệu năng.
Có vẻ bạn đã hiểu sai ý tôi rồi; điều tôi giả định là tình huống công ty huấn luyện AI bằng chính mã nguồn của công ty, rồi dùng nó để sinh mã trong nội bộ công ty.
Người giám sát cũng phải biết chút gì đó chứ… đang chơi hay đang làm việc, đang làm trò vô bổ hay đang làm tốt… cứ tưởng người giám sát là người chỉ việc tắt rồi bật điện…
Nếu việc tắt rồi bật điện là công việc của người giám sát… thì chính người giám sát đó mới là kiểu người quá thích hợp để bị AI thay thế.
Cá nhân tôi không mấy đồng tình. Một senior bị junior làm việc cùng AI vượt mặt thì ngay từ đầu đã không phải là senior rồi.
Thật đáng tiếc vì có vẻ các căn cứ cho lập luận còn thiếu thuyết phục.
Tên của Neo đã đổi rồi à?
Không phải là đã đổi tên, mà có vẻ như nhãn GN+ và neo đang bị hiển thị trùng lặp nên tôi đã gộp lại thành một. Khi bấm vào thì sẽ chuyển đến neo.