Lập trình viên kinh nghiệm chia sẻ thực tế về công cụ coding LLM sau những khó khăn trong sản xuất

Nhóm Cộng đồng BigGo
Lập trình viên kinh nghiệm chia sẻ thực tế về công cụ coding LLM sau những khó khăn trong sản xuất

Sự phản ánh thẳng thắn của kỹ sư phần mềm Alberto Fortin về việc sử dụng các Mô hình Ngôn ngữ Lớn (LLM) để lập trình đã gây tiếng vang trong cộng đồng lập trình viên trên toàn thế giới. Sau khi ban đầu đón nhận các công cụ AI với sự nhiệt tình, Fortin đã gặp phải những thách thức đáng kể khi xây dựng lại hạ tầng với Go và ClickHouse, khiến anh phải đánh giá lại cách tiếp cận phát triển có hỗ trợ LLM một cách căn bản.

Ảo tưởng về năng suất

Nhiều lập trình viên trải qua giai đoạn tuần trăng mật ban đầu với LLM. Những gợi ý tự động hoàn thành đầu tiên và các tính năng nhỏ tạo cảm giác kỳ diệu, tạo ra ảo tưởng về năng suất được nâng cao đáng kể. Tuy nhiên, sự phấn khích ban đầu này thường che giấu những vấn đề sâu xa hơn xuất hiện khi làm việc trên các dự án lớn hơn, phức tạp hơn.

Cộng đồng đã xác định một mô hình lặp lại: LLM xuất sắc trong việc tạo code nhanh chóng, nhưng codebase kết quả trở nên khó bảo trì. Không giống như code được viết bởi các lập trình viên con người, code được tạo bởi LLM thiếu quyền sở hữu nhận thức đến từ việc xây dựng giải pháp từng bước một. Điều này tạo ra một vấn đề cơ bản - các lập trình viên thấy mình đang quản lý những codebase mà họ không hiểu hoàn toàn.

Vấn đề mô hình tư duy

Một hiểu biết quan trọng nổi lên từ các cuộc thảo luận của lập trình viên tập trung vào khái niệm lập trình như xây dựng lý thuyết. Khi các lập trình viên tự viết code, họ xây dựng các mô hình tư duy về cách các thành phần khác nhau tương tác và tại sao những quyết định nhất định được đưa ra. Sự hiểu biết sâu sắc này trở nên quan trọng khi debug các vấn đề hoặc thêm các tính năng mới.

Code được tạo bởi LLM làm gián đoạn quá trình tự nhiên này. Các lập trình viên nhận được các giải pháp hoạt động mà không trải qua hành trình giải quyết vấn đề để xây dựng sự hiểu biết. Khi các lỗi không thể tránh khỏi xuất hiện, việc sửa chúng trở nên khó khăn hơn theo cấp số nhân vì lập trình viên thiếu kiến thức nền tảng về cách code được xây dựng.

Tìm kiếm sự cân bằng phù hợp

Cộng đồng lập trình viên đang hội tụ về một cách tiếp cận tinh tế hơn đối với việc sử dụng LLM. Thay vì coi những công cụ này như các trợ lý lập trình tự động, những người thực hành thành công đang định vị lại chúng như những người trợ giúp tinh vi cho các nhiệm vụ cụ thể.

Tôi là kỹ sư phần mềm, kỹ sư phần mềm senior, tôi là kiến trúc sư. LLM là trợ lý. Trợ lý phản hồi với tôi; tôi lập kế hoạch.

Sự thay đổi tư duy này chứng tỏ là quan trọng. Các lập trình viên báo cáo kết quả tốt hơn khi họ duy trì quyền kiểm soát kiến trúc trong khi sử dụng LLM cho các nhiệm vụ nhỏ hơn, được xác định rõ như tạo boilerplate code, viết unit test, hoặc xử lý công việc refactoring thường xuyên.

Các trường hợp sử dụng LLM được khuyến nghị:

  • Tạo các đoạn code nhỏ
  • Tạo boilerplate code
  • Viết unit test
  • Các tác vụ refactoring thường xuyên
  • Tăng cường tìm kiếm tài liệu
  • Giải thích khái niệm và học tập

Không được khuyến nghị:

  • Triển khai tính năng hoàn chỉnh
  • Các quyết định kiến trúc quy mô lớn
  • Debug phức tạp mà không có sự hiểu biết của con người
  • Các dự án vượt quá giới hạn context window

Phổ thành công

Thú vị là, hiệu quả của LLM dường như tuân theo mô hình đường cong chuông. Ở một đầu, các lập trình viên trước đây không thể viết code nhất định thấy mình được mở khóa và có thể tạo ra các chương trình hoạt động. Ở đầu kia, các lập trình viên có kinh nghiệm học cách coi LLM như đội quân các coder junior, duy trì quyền kiểm soát thuật toán cấp cao trong khi ủy thác các chi tiết triển khai.

Khó khăn xảy ra ở vùng giữa, nơi các lập trình viên có đủ kỹ năng để nhận ra các vấn đề chất lượng nhưng chưa phát triển các chiến lược hiệu quả để quản lý code được tạo bởi LLM. Những lập trình viên này thường thấy mình bị choáng ngợp bởi các mẫu code không quen thuộc và các quyết định kiến trúc mà họ không đưa ra.

Mô hình sử dụng LLM theo kinh nghiệm của nhà phát triển:

  • Người mới bắt đầu: Được LLM hỗ trợ vượt qua rào cản, có thể tạo ra các chương trình hoạt động mà trước đây không thể làm được
  • Trung cấp: Thường gặp khó khăn với các mẫu code không quen thuộc do LLM tạo ra
  • Nâng cao: Sử dụng LLM thành công như "đội quân các lập trình viên junior" với sự giám sát về kiến trúc

Bài học thực tế rút ra

Cộng đồng đã xác định một số chiến lược thực tế để sử dụng LLM hiệu quả. Sử dụng những công cụ này như các công cụ tìm kiếm nâng cao hoặc các lựa chọn thay thế Stack Overflow được cá nhân hóa chứng tỏ bền vững hơn so với việc dựa vào chúng để triển khai tính năng hoàn chỉnh. Nhiều lập trình viên hiện giới hạn việc sử dụng LLM để tạo các đoạn code nhỏ, sau đó họ cẩn thận xem xét và tích hợp thủ công.

Các hạn chế về context window cũng đóng vai trò quan trọng trong hiệu quả của LLM. Khi các dự án phát triển vượt quá những gì có thể vừa trong context của mô hình, AI mất dấu kiến trúc hệ thống rộng hơn, dẫn đến các gợi ý không nhất quán hoặc không tương thích.

Nhìn về tương lai

Trong khi các LLM hiện tại có những hạn chế rõ ràng, công nghệ tiếp tục phát triển nhanh chóng. Một số lập trình viên dự đoán một tương lai nơi LLM trở nên tinh vi đủ để xử lý kiến trúc code và refactoring tự động. Những người khác đặt câu hỏi liệu các mô hình dự đoán next-token có thể thực sự hiểu được lý luận phức tạp cần thiết cho phát triển phần mềm quy mô lớn hay không.

Hiện tại, cách tiếp cận thành công nhất dường như là coi LLM như những công cụ mạnh mẽ nhưng có hạn chế, đòi hỏi sự giám sát cẩn thận của con người. Chìa khóa nằm ở việc hiểu cả khả năng và hạn chế của chúng, sau đó cấu trúc quy trình làm việc để tối đa hóa lợi ích trong khi giảm thiểu rủi ro của code không thể bảo trì.

Cuộc thảo luận đang diễn ra phản ánh sự trưởng thành rộng hơn trong cách cộng đồng phát triển phần mềm tiếp cận các công cụ AI - chuyển từ sự cường điệu ban đầu hướng tới các chiến lược tích hợp thực tế và bền vững hơn.

Tham khảo: Why I'm Dialing Back My LLM Usage