Suy ngẫm về tương lai của phát triển phần mềm

• Các mô hình ngôn ngữ lớn (LLMs) đã tạo ra làn sóng lớn trong lĩnh vực sáng tạo khi có thể tạo ra hình ảnh, văn bản và mã nguồn
• Ban đầu có rất nhiều kết quả buồn cười như vẽ sai bàn tay người hay nói sai sự thật, nhưng chúng đang dần được cải thiện
• Trước khi các mô hình này xuất hiện, lập luận phản đối tự động hóa chủ yếu là máy móc không thể suy nghĩ sáng tạo, nhưng giờ đây lập luận đó ngày càng yếu đi
• Vậy bây giờ chúng ta nên đi đâu tiếp theo?

Framework: Các cấp độ năng lực phát triển phần mềm

• Phát triển phần mềm không chỉ đơn giản là viết mã
• Hình ảnh quen thuộc về lập trình viên là một người ngồi trong căn phòng tối, nhìn chằm chằm vào máy tính và gõ mã liên tục, nhưng trên thực tế họ dành nhiều thời gian cho những công việc khác hơn là viết mã
  • Thu thập yêu cầu từ người dùng nghiệp vụ
  • Tinh lọc yêu cầu để có thể mô hình hóa chúng thành mã
  • Hình dung giải pháp và lập kế hoạch cùng các thành viên như nhà thiết kế, quản lý sản phẩm
  • Thiết kế kỹ thuật và tinh chỉnh cùng các nhà phát triển khác
  • Thiết lập hạ tầng, cấu hình, boilerplate, v.v.
  • Viết mã thực tế
  • Gỡ lỗi, hiểu mã của người khác, viết tài liệu, v.v.
  • Triển khai lên production
  • Ứng phó với sự cố production
  • Và nhiều công việc khác
• Nói rằng "AI sẽ thay thế lập trình viên" có nghĩa là AI phải thành thạo tất cả các công việc ở trên
• Nhưng nhìn vào danh sách này, có vẻ một số việc trong đó có thể sẽ được tự động hóa trong tương lai, còn hiện tại thì vẫn chưa thể

Phân loại mức độ tự động hóa của xe tự lái

• Lĩnh vực xe tự lái đã phát triển một cách để phân loại các mức độ tự động hóa
• Cách phân loại này mô tả rõ ràng công nghệ hiện tại làm được gì và tránh tư duy trắng đen
• Nếu áp dụng cách phân loại này cho phát triển phần mềm dựa trên AI thì
  • Mức thấp nhất là trạng thái trước đây của chúng ta, tức AI không tham gia vào công việc. Tất nhiên khi đó vẫn có những dạng tự động hóa khác như compiler, build process, v.v., nhưng đó không phải AI mà là tự động hóa quyết định luận do con người viết ra
  • Mức tiếp theo là những gì chúng ta đang có hiện nay
    • Các lập trình viên sử dụng ChatGPT hoặc GitHub Copilot để được hỗ trợ
    • Họ dùng chúng để viết test, mã boilerplate, refactor, và hiểu mã/lỗi
    • Có thể trò chuyện như với một đồng nghiệp để đặt câu hỏi và nhận trợ giúp, nhưng vì không có quyền truy cập vào máy tính nên chúng không thể tạo file, chạy lệnh build hay triển khai lên production
  • Mức cao nhất là giao một phần hoặc toàn bộ dự án cho một "AI coder"
    • AI coder nhận yêu cầu, viết mã, sửa lỗi rồi triển khai sản phẩm cuối cùng lên production
    • Trước đây tôi nghĩ phải mất thêm vài tháng nữa điều này mới xảy ra, nhưng bản demo của Devin đã cho thấy hiện tại dù mới chỉ làm được các tác vụ phát triển đơn giản, nó vẫn có khả năng tiếp tục cải thiện trong tương lai Devin, kỹ sư phần mềm AI đầu tiên
• Ngoài năng lực của mô hình AI, chúng ta cũng phải nghĩ tới độ chính xác của giải pháp
  • Những mô hình này dễ bị hallucination hoặc có xu hướng phải được prompt theo một cách nhất định mới cho ra điều mình muốn
  • Điều đó tạo ra ma sát trong việc áp dụng và khiến đa số mọi người từ bỏ trợ lý AI ở thời điểm này
  • Nhưng điều này cũng đang được cải thiện, và ở các mô hình mới nhất thì mức độ prompt engineering như vậy không còn cần thiết nữa
• Ngoài ra, thay vì chỉ phụ thuộc vào dữ liệu huấn luyện, mô hình cũng cần có khả năng duyệt web để "học"
  • Điều này quan trọng khi các phiên bản mới của thư viện và ngôn ngữ lập trình liên tục được giới thiệu

Framework: Phát triển phần mềm được thuê ngoài

• Giờ khi đã xây dựng được khung năng lực, điều đó sẽ ảnh hưởng thế nào tới cấu trúc đội ngũ hay tổ chức? Doanh nghiệp phát triển phần mềm theo nhiều cách khác nhau:
  • Hoàn toàn in-house
  • Chủ yếu in-house với một số ít vendor
  • Chỉ một phần nhỏ in-house với nhiều vendor
  • Hoàn toàn dựa vào vendor
• Có thể xem AI coder như một vendor/tư vấn phát triển phần mềm được thuê ngoài
• Việc đội ngũ nội bộ của công ty giám sát công việc của vendor là rất quan trọng
  • Có thể xử lý phần nào bằng hợp đồng, nhưng hợp đồng thường chỉ áp dụng cho một nhà cung cấp hay một dự án cụ thể và không thể ép buộc các mục tiêu dài hạn bằng cách này
  • Sẽ tốt hơn nếu có dù chỉ là một nhóm nội bộ nhỏ có thể định hướng cho vendor
  • Tương tự, ngay cả khi có thể thuê AI coder như thuê một EC2 instance, thì việc có một đội nội bộ gồm các lập trình viên để giám sát công việc vẫn là điều có lợi

Framework: Phát triển phần mềm là mô hình hóa sự phức tạp

• Khi nói về việc giải quyết bài toán kinh doanh, có thể lấy Excel làm ví dụ
• Excel có rào cản gia nhập rất thấp nên có thể dùng nó để sắp xếp dữ liệu, phân tích dữ liệu hoặc tự động hóa một số quy trình
• Nhưng nó không phù hợp với các quy trình nghiệp vụ phức tạp vì thiếu các tính năng như kiểm soát truy cập chi tiết, tích hợp với các hệ thống không được hỗ trợ, khả năng kiểm thử, khả năng tái sử dụng, phụ thuộc nhà cung cấp, v.v.
• Các giải pháp "low-code" như Power Automate cũng tương tự
• "Liệu người dùng nghiệp vụ có thể dùng AI coder để tạo ra những workflow phức tạp này mà không cần sự trợ giúp của lập trình viên không?"
• Nghĩ kỹ thì Excel và các công cụ low-code đã tồn tại hàng chục năm, vậy tại sao nghề phát triển phần mềm vẫn còn tồn tại?
• Đó là vì chúng ta nghĩ về phát triển phần mềm như thể nó chỉ là viết mã
• Những bài toán phức tạp cần những người có thể quản lý hiệu quả sự phức tạp đó và chuyển đổi vấn đề kinh doanh từ miền thực tế thành mô hình số
• Nói cách khác, việc bạn có thể dựng một cái chòi gỗ nhờ tutorial trên YouTube mà không cần kỹ sư xây dựng không có nghĩa là bạn cũng có thể, và nên, xây một tòa nhà 10 tầng theo cách tương tự
  • Trong quá trình học cách làm việc đó cho đúng, bạn có thể dần trở thành một kỹ sư xây dựng
  • Chỉ là vấn đề bạn có muốn đầu tư thời gian để học cho bài bản hay thuê một kỹ sư lành nghề
• Vì vậy, dù dùng Excel hay AI coder hiện đại nhất, nếu bạn đang mô hình hóa logic phức tạp thì tôi vẫn xem đó là phát triển phần mềm
• Chỉ khác ở công cụ để biểu đạt yêu cầu nghiệp vụ, có thể là công thức bảng tính, mã, prompt, v.v.

Framework: Kích thước của chiếc bánh

• Phần lớn sự lo lắng quanh chủ đề này dựa trên giả định rằng quy mô thị trường phát triển phần mềm sẽ giữ nguyên, tức AI coder sẽ dần lấy đi "thị phần" từ con người
• Vì quy mô của thị trường "giải quyết vấn đề kinh doanh" lớn hơn rất nhiều so với phát triển phần mềm, nên phát triển phần mềm sẽ không sớm biến mất

Framework: Định nghĩa hình thức của logic nghiệp vụ

• Logic nghiệp vụ luôn phải được định nghĩa bằng một hình thức rõ ràng
• Đó là lý do ngôn ngữ lập trình, dù dùng các từ tiếng Anh như 'if', 'switch', v.v., vẫn định nghĩa ý nghĩa của chúng một cách cực kỳ nghiêm ngặt và sẽ không hoạt động nếu dùng sai từ. Nghĩ kỹ thì công thức Excel hay luồng low-code ngày nay cũng vậy
• Trong tương lai, ngay cả khi AI coder có thể tạo ra sản phẩm phần mềm thông qua các chỉ thị được đưa ra bằng tiếng Anh hội thoại, tôi nghĩ vẫn sẽ tồn tại một định nghĩa hình thức nền tảng cho logic nghiệp vụ được tạo ra ở backend
• Nó có thể trông rất khác so với ngôn ngữ hay framework mà chúng ta đang dùng ngày nay, nhưng định nghĩa hình thức của logic nghiệp vụ nghe rất giống với "mã"
• Chừng nào AI coder còn chưa thể tạo ra logic nghiệp vụ này theo cách quyết định luận từ tiếng Anh hội thoại, thì vẫn sẽ cần những người có thể hiểu đoạn mã được tạo ra ở backend và chỉnh sửa nó khi cần. Đó chính là các lập trình viên

Kết luận

• Bản chất công việc sẽ thay đổi và các công cụ chúng ta dùng sẽ rất khác hiện tại, nhưng tôi tin rằng trong tương lai gần, thị trường dành cho các nhà phát triển phần mềm vẫn sẽ tiếp tục tồn tại

[xguru]

Devin, kỹ sư phần mềm AI đầu tiên
OpenDevin - bản triển khai mã nguồn mở của Devin, kỹ sư phần mềm AI

[dhlee0305]

Ngay cả trước khi OpenAI trở nên nổi tiếng, khi nhìn thấy AI mở rộng phạm vi sang cả lĩnh vực nghệ thuật vốn từng được cho là tiếp nhận AI chậm nhất hoặc thậm chí là bất khả thi, tôi chợt nghĩ rằng những điều mà hiện tại chúng ta cho rằng chỉ có “con người” mới làm được có thể không còn “an toàn” nữa.

[edunga1]

Giống như bài viết này và bài https://vi.news.hada.io/topic?id=13557,
rõ ràng quy mô miếng bánh dành cho lập trình viên sẽ thu hẹp lại, và điều đó sẽ còn tăng tốc nữa, đúng không?

[ahwjdekf]

Khi tầm quan trọng của AI prompt ngày càng được nhấn mạnh, sẽ có nhiều người dùng nhận ra rằng việc xác định spec rõ ràng và sắp xếp yêu cầu bài bản đang dần trở nên thiết yếu hơn, và điều này cuối cùng có vẻ sẽ tác động theo hướng có lợi cho các developer trong công việc sau này.

[colus001]

Tôi cho rằng code là để phục vụ con người, và việc máy móc viết code cũng có nghĩa là con người vẫn còn cần thiết, nên đó không phải là hướng phát triển của tương lai xa. Tôi nghĩ nó sẽ phát triển theo dạng như thử nghiệm ban đầu backend-GPT (https://github.com/RootbeerComputer/backend-GPT), tức là chúng ta ném vào một kiểu hộp đen những câu hỏi mình muốn, rồi nó truy cập DB để xử lý dữ liệu, còn ở phần trải nghiệm trước và sau đó thì con người can thiệp một phần.

[kaistj]

Có vẻ như trong số nhiều điều mọi người bàn về chat GPT và Copilot, phần prompt engineering thường được nhắc đến. Tôi cũng nghĩ rằng một yếu tố quan trọng là làm sao có thể truyền đạt và giao tiếp hiệu quả với AI coder về những quá trình mà chúng ta vốn thường thực hiện để lập trình, như họp bàn, nhanh chóng truyền đạt bằng lời, rồi sắp xếp và xác nhận lại ^^.

[vbmania]

> Câu nói "AI sẽ thay thế lập trình viên" có nghĩa là AI phải thành thạo tất cả những công việc ở trên.

-> Có thể đó là những quy trình cần thiết vì do con người làm, và rốt cuộc khi đã trải qua hết các quy trình đó, mình nghĩ kết quả đầu ra là đoạn mã có thể mang những mẫu hình nhất định. Giống như trong cờ vây, người ta từng nghĩ những thứ như bố cục khai cuộc hay các thế cờ chuẩn là cần thiết, nhưng rồi hóa ra đó chỉ là cách bất khả kháng để xử lý thông tin trong phạm vi nhận thức của con người mà thôi.