Vibe coding và luận điệu ngày tàn của lập trình viên: Suy nghĩ về hướng phát triển của lập trình viên junior
(stdy.blog)- Khi Vibe coding nổi lên, cuộc tranh luận kiểu "giờ thì không còn cần lập trình viên nữa" vs "vẫn còn quá sớm để nói vậy" cũng trở nên rất sôi nổi
- Cả hai bên đều có lý. Trong lúc theo dõi sự phát triển của AI và làm việc với vai trò product engineer, tôi đã sắp xếp lại những suy nghĩ mình tích lũy được
- Tuy vậy, tôi không phải chuyên gia AI mà chỉ là một lập trình viên. Kinh nghiệm với Vibe coding của tôi cũng không nhiều. Dù vậy, tôi viết bài này vì muốn nghe thêm ý kiến từ mọi người, đồng thời hy vọng nó có thể giúp ích cho những lập trình viên junior đang cảm thấy bất an
Trải nghiệm trực tiếp với Vibe: đến mức này rồi vs mới chỉ đến mức này thôi
Tôi đã thử làm một trò chơi bắn bi cuối tuần bằng Vibe coding. Tôi làm để chơi cùng con gái 7 tuổi. 90% phần code được thực hiện chỉ bằng prompt, thời gian triển khai giảm mạnh (hoàn thành trong 4 giờ với chất lượng không tệ)
Trong quá trình đó, tôi luân phiên cảm thấy thất vọng kiểu "cái đơn giản thế này mà cũng không làm được à?" và ngạc nhiên kiểu "chỉ với chừng này yêu cầu mà cũng làm ra tốt đến vậy sao?". Đặc biệt, cảm giác đầu tiên xuất hiện nhiều vì việc khiến AI "làm đúng theo ý mình" không hề dễ
Nhưng dù sao đi nữa, nếu tiếp tục tinh chỉnh prompt và công nghệ tiến bộ hơn, phần "ngạc nhiên" chắc chắn sẽ lớn hơn rất nhiều, và tôi nghĩ điều này sẽ thực sự dẫn tới việc tuyển dụng lập trình viên junior giảm mạnh
Tôi sẽ nói về cảm giác này thông qua nguyên lý Pareto và khái niệm độ trưởng thành của sản phẩm
Góc nhìn bi quan: 96% mã nguồn có thể sẽ do AI viết
Nếu xem độ trưởng thành của sản phẩm theo 3 giai đoạn (zero-to-one, one-to-ten, và cao hơn nữa), thì điều khiến tôi sốc là phần lớn coding ở mức zero-to-one nay đã có thể bị AI thay thế
Nhìn theo nguyên lý Pareto, tôi nghĩ có lẽ 80% mã mà lập trình viên tạo ra để phát triển sản phẩm vốn là đầu ra phục vụ cho zero-to-one.
- Những đoạn code xuất hiện trong quá trình hiện thực hóa ý tưởng và tìm PMF. Và cả những đoạn code mà người không phải lập trình viên cũng có thể dễ dàng tạo ra bằng Vibe coding.
Tiến thêm một bước, nếu giả định rằng 80% phần việc cần thiết ở giai đoạn one-to-ten có thể được định nghĩa rõ ràng, chia nhỏ, rồi xử lý ở mức zero-to-one thì...
- Một cách cực đoan, tôi tự hỏi liệu khoảng 96% lượng code được tạo ra (= 0.8 + 0.2 * 0.8) có thể bị AI thay thế hay không
- Trong video của Y Combinator giới thiệu Vibe coding, nghe nói cũng có vài founder nói rằng "95% codebase của sản phẩm được AI viết", con số này khớp một cách kỳ lạ
Điều này nhiều khả năng sẽ nâng mặt bằng kỳ vọng đối với năng lực của lập trình viên, cũng như đối với các sản phẩm ở mức MVP.
- Tương tự như sau Bootstrap và TailwindCSS, việc "style UI ở mức ổn" đã trở thành kỹ năng cơ bản mặc định với frontend developer
Nếu vậy, việc số lượng vị trí tuyển dụng dành cho những lập trình viên trước đây chỉ cần biết tạo sản phẩm ở giai đoạn zero-to-one cũng đã được coi trọng nay bị thu hẹp đi là điều có vẻ rất tự nhiên. Vì thế câu nói "giờ thì không còn cần lập trình viên nữa" không còn là cường điệu nữa....
...thật sự là vậy sao?
Góc nhìn lạc quan: Dù vậy vẫn còn rất nhiều việc cho lập trình viên
1) Quy mô thị trường lớn hơn rất nhiều, nên việc cũng nhiều hơn
Ý nghĩa lớn nhất của Vibe coding là hạ thấp rào cản gia nhập trong phát triển sản phẩm
- Phần lớn công việc trước đây lập trình viên phải tự tay làm để đạt zero-to-one nay được các coding agent thay thế với chi phí cực thấp (thời gian/tiền bạc/nhân lực).
- Tức là ngay cả khi không có lập trình viên, người ta vẫn có thể quay vòng nhanh chu kỳ thực thi-kiểm chứng ý tưởng
Vì vậy, số lượng sản phẩm ở mức zero-to-one (hoặc thấp hơn nữa) vốn trước đây không thể xuất hiện sẽ bùng nổ, và số người muốn "tự hiện thực hóa ý tưởng của mình" cũng sẽ tăng lên rất nhiều.
Tất cả những điều này sẽ có tác dụng mở rộng quy mô thị trường mà "lập trình viên có thể kiếm tiền". Những người vốn không phải khách hàng của lập trình viên nay sẽ trở thành một tệp khách hàng mới. Ví dụ như
- Dạy Vibe coding để giúp người không phải lập trình viên, PM, designer có thể hiện thực hóa ý tưởng của họ
- Làm dịch vụ ngắn hạn để giúp hoàn thiện những sản phẩm đã làm được 90% cùng Cursor nhưng vẫn chưa thể hoàn tất
- Tư vấn để biến một sản phẩm "bằng mọi cách cũng làm ra được" thành thứ có thể vận hành thực tế và tạo doanh thu bền vững
- Phát triển nhiều công cụ trả phí giúp Vibe coding tốt hơn và dễ hơn
Dù là kiếm thêm thu nhập bên ngoài công ty nhờ những việc này, hay là có những doanh nghiệp mới ra đời để làm các việc đó, tôi cho rằng những người hưởng lợi nhiều nhất từ thay đổi của thị trường vẫn sẽ là lập trình viên
2) Lập trình viên có thể và cần làm rất nhiều việc ngoài coding
Dù AI thay thế 90% "coding" đi nữa thì cũng không thể sa thải 90% lập trình viên
- Vì tỷ trọng của coding trong phát triển sản phẩm, và rộng hơn là product engineering, không lớn như nhiều người nghĩ
Chỉ cần nhìn vào quy trình để thêm đúng một tính năng vào sản phẩm cũng đã có rất nhiều bước như sau.
- Nhận diện vấn đề
- Đưa ra ý tưởng giải pháp
- Ước tính hiệu quả kỳ vọng và chi phí, quyết định mức ưu tiên phát triển
- Lập kế hoạch để biến nó thành một tính năng trong sản phẩm
- Thiết kế UI/UX
- Thiết kế kiến trúc
- Triển khai backend + frontend + hạ tầng
- Code review, kiểm thử tự động, QA
- Triển khai phát hành, giám sát, quảng bá tính năng, A/B testing
- Thu thập phản hồi người dùng, vận hành, cải thiện
Vibe coding ở đây chỉ thay thế một phần của bước 7 và 8 mà thôi.
- Một product engineer xuất sắc cần can thiệp ở mức độ nhất định vào tất cả các bước này
- Khi AI thay việc coding, giá trị của những người làm tốt phần còn lại lại càng tăng lên
3) Ngay cả nếu chỉ nhìn vào coding thì vẫn còn rất nhiều việc đáng kể để làm
Ngay cả khi chưa bàn tới product engineering thì việc vẫn rất nhiều
- Còn rất nhiều việc để hoàn thiện vài phần trăm cuối cùng của coding giai đoạn one-to-ten
- Nếu lập trình viên hỗ trợ thiết kế spec, thiết kế cấu trúc, chia nhỏ công việc..., thì chi phí cho Vibe coding cũng sẽ giảm đi
Và với các sản phẩm vượt qua mức one-to-ten, Vibe coding còn có nhiều giới hạn
- Codebase càng lớn -> context window bị giới hạn
- Muốn giữ mức bảo mật cao và cải thiện hiệu năng thì vẫn cần chuyên gia can thiệp trực tiếp
- Khi coding bằng thư viện hoặc ngôn ngữ mà AI chưa học tốt thì cũng vậy
- https://vi.news.hada.io/topic?id=19923 cũng nói về các vấn đề tương tự
Vậy bây giờ lập trình viên junior nên làm gì?
Dù thế giới đi theo kịch bản bi quan hay lạc quan thì có một điều chắc chắn là mọi thứ đang thay đổi quá nhanh. Đặc biệt trong bối cảnh cánh cửa tuyển dụng đang thu hẹp rất mạnh, junior nên học tập/phát triển như thế nào?
Sau khi đọc bài nghiên cứu <Điều gì tạo nên một lập trình viên xuất sắc?>, tôi thử định nghĩa 5 năng lực cốt lõi của một lập trình viên xuất sắc như sau
- Viết code tốt
- Luyện tập ra quyết định dựa trên căn cứ
- Giúp đồng đội đưa ra quyết định hiệu quả
- Tối đa hóa giá trị hiện tại của công việc
- Học tập hiệu quả và bền bỉ
Những điều này trong thời đại AI vẫn còn nguyên tầm quan trọng. Có thể liên hệ chúng với góc nhìn lạc quan như sau
1) Chủ động tận dụng thị trường đang mở rộng
Nếu là tôi, tôi sẽ thử những việc như sau
- Học prompt engineering
- Dùng thử từng ứng dụng AI mới xuất hiện
- Học và thử nghiệm cách chia nhỏ công việc để coding agent hiểu đúng yêu cầu của mình
- Dùng Vibe coding để làm và phát hành một ứng dụng giải quyết vấn đề nhỏ của chính mình
- Nếu bạn bè/người quen không phải lập trình viên muốn thử Vibe coding thì nhận dạy kèm (có thu phí)
- Thử hỗ trợ họ hoàn thiện việc triển khai, phát hành và vận hành sản phẩm (cũng có thu phí)
2) Xây dựng năng lực như một product engineer
Nếu là tôi, tôi sẽ thử những việc như sau
- Quan tâm tới toàn bộ vòng đời sản phẩm như nhận diện vấn đề, ý tưởng, lập kế hoạch, thiết kế, kiểm thử, vận hành...
- Nếu tự làm và vận hành ứng dụng như một solo founder, năng lực product engineering có lẽ sẽ tự nhiên phát triển
- Cải thiện sản phẩm thông qua làm việc nhóm để đồng thời nâng cao năng lực cộng tác + product engineering
Khi tuyển lập trình viên và viết offer letter, tôi luôn đưa vào một ý như thế này: "Tôi mong bạn làm việc với tư duy mình là một mini CTO"
- Ít nhất trong dự án mà bạn phụ trách, bạn là người chịu trách nhiệm cuối cùng cho các quyết định kỹ thuật
- Hãy can thiệp vào mọi bước cần thiết để đưa dự án đó tới thành công
- Dù là vấn đề kỹ thuật hay phi kỹ thuật, hãy giúp đồng đội có thể ra quyết định và hành động hiệu quả
3) Hiểu sâu từng công nghệ và rèn coding sense
Những lập trình viên hiểu sâu từng công nghệ vẫn luôn có nhu cầu ổn định. Vì để đi xa hơn PMF và vươn tới các công ty unicorn/decacorn, Make it Right & Fast là điều bắt buộc.
Không có đường tắt ở đây. Cần đầu tư thời gian và nỗ lực (có thể tận dụng sự hỗ trợ của AI).
- Tìm hiểu bên trong framework/library, hiểu bối cảnh lịch sử, đóng góp cho mã nguồn mở, tự làm library, theo dõi/sửa bug, chuẩn web/cải thiện hiệu năng, v.v.
Đồng thời, việc xây dựng tiêu chuẩn riêng về code tốt và rèn "coding sense" để nhận ra code tốt sẽ càng quan trọng hơn. Vì bạn cần nhận ra khi Vibe của AI đi sai hướng, biết dừng lại và can thiệp.
Muốn rèn coding sense thì cần luyện tập có chủ đích. Ở đây cũng phải bỏ thời gian và công sức
- Xem thật nhiều code tốt, nhận nhiều phản hồi về code mình viết từ AI hoặc senior developer, đọc code do AI hay đồng đội viết và dự đoán "nếu cứ đi tiếp như thế này thì có thể phát sinh vấn đề gì", rồi so sánh với thực tế
11 bình luận
Dù sao thì công việc thực tế của kỹ nghệ phần mềm sẽ thay đổi rất nhiều. Những cỗ máy viết mã sẽ kém cạnh tranh hơn, nhưng tôi đang đặt cược rằng những kỹ sư thực sự có thể tạo ra sản phẩm End-to-End sẽ sống sót.
Việc gõ bàn phím đã giảm đi, nhưng lại xuất hiện thêm việc tìm những đoạn mã bẫy do AI tạo ra.
Cảm ơn bạn rất nhiều vì bài viết rất ý nghĩa và hay!
Tôi gõ nhầm rồi. hu hu
Đặc biệt, lý do lớn là vì việc khiến AI 'làm theo lời tôi' không hề dễ -> câu trước
Việc hiểu sâu về product engineering mà startup cần cũng rất tốt, nhưng tôi nghĩ con đường theo đuổi công nghệ đến cực hạn và không ngừng mài giũa nó vẫn còn rất có ý nghĩa. Việc phát triển để tạo ra các ứng dụng web đơn giản sẽ bị AI thay thế, nhưng tôi cho rằng vẫn phải có ai đó nghĩ ra Kubernetes và thiết kế ElasticSearch.
Vì số lượng những người thiết kế các thành phần cốt lõi như vậy là có hạn, nên rốt cuộc tôi cho rằng việc nhu cầu đối với vị trí nghề nghiệp gọi là "lập trình viên" giảm đi là điều đúng.
Khi viết bình luận, tôi thấy thông điệp mà mình muốn truyền tải trong bài đã được sắp xếp rõ hơn.
Tôi nghĩ rằng ở từng doanh nghiệp riêng lẻ, nhu cầu tuyển lập trình viên dù thế nào đi nữa cũng có vẻ sẽ giảm, nhưng số lượng doanh nghiệp hoặc các đơn vị/cá nhân tương đương cần đến "công việc phát triển" sẽ tăng lên nhiều hơn, nên việc để lập trình viên làm vẫn còn rất nhiều.
Tất nhiên, AI cũng có thể thay thế cả những việc đó, nhưng nếu đến mức ấy thì có lẽ sẽ chẳng còn ngành nghề nào là không bị thay thế nữa...
Lời hay quá!
Tôi đồng ý. Có vẻ như từ nay sẽ được chia thành phần việc do AI coding đảm nhiệm và phần thiết kế, rà soát do con người phụ trách, và cho đến khi xuất hiện AI có thể hiểu toàn bộ dự án thì có lẽ hai bên sẽ còn cùng tồn tại.
Tôi đồng ý! Tất nhiên ở đó AI cũng sẽ hỗ trợ, nhưng có lẽ sẽ khó nếu chỉ làm theo kiểu vibe.
Tham khảo thêm, đây là trò chơi được tạo bằng vibe coding. https://www.stdy.blog/vibe-go-stone/