3 Java Champion dùng GitHub Copilot như thế nào để tăng năng suất làm việc

Công cụ lập trình bằng AI có thể sinh mã rất nhanh, nhưng tốc độ đơn thuần không giải quyết được những bài toán kỹ thuật khó nhất. Lập trình viên vẫn phải cung cấp ngữ cảnh, xác minh kết quả, bảo vệ khả năng bảo trì và chịu trách nhiệm cho sản phẩm cuối cùng.

Để hiểu cách những lập trình viên dày dạn kinh nghiệm cân bằng giữa tốc độ và chất lượng, GitHub đã trò chuyện với ba Java Champion — những người có hơn một thập kỷ gắn bó với Java. Họ chia sẻ ví dụ cụ thể khi dùng GitHub Copilot trong môi trường sản xuất và dự án mã nguồn mở, cùng những thực hành giúp biến sản phẩm AI thành phần mềm đáng tin cậy.

Lập trình viên làm việc với GitHub Copilot trong IDE

Vlad Mihalcea: AI như một thành viên mới trong nhóm

Vlad Mihalcea dùng Copilot để phân tích, thiết kế và triển khai nhiều tính năng trong hai dự án Hypersistence Utils và Hypersistence Optimizer. Điển hình là một ứng dụng web hiển thị lịch sử sự kiện của Optimizer — việc mà trước đây ông liên tục trì hoãn vì mất hàng tuần. Với Copilot, công việc này chỉ mất hai ngày thay vì vài tuần.

Ông thường dùng GitHub Copilot ngay trong IntelliJ IDEA, thuận tiện khi rà soát mã nguồn hoặc trong phiên gỡ lỗi. Tuy nhiên, ông nhấn mạnh vẫn phải xem lại kế hoạch và mã do AI sinh ra, bởi mục tiêu của công cụ là tăng năng suất chứ không thay thế con người.

Một điểm đáng chú ý là ông tự xây dựng các skill để văn bản Copilot tạo ra giống với phong cách của chính mình. Skill này được huấn luyện từ 65 bài viết đã xuất bản, giúp bản nháp mang giọng văn của blog cá nhân thay vì giọng điệu chung chung của mô hình ngôn ngữ. Ông cũng phát triển kỹ năng giúp AI mô phỏng cách viết mã hiện có, tuân theo nguyên tắc ít bất ngờ nhất — điều quan trọng vì thời gian bảo trì luôn nhiều hơn thời gian tạo mã.

Một mẹo là thay đổi loại mô hình theo loại tác vụ. Với việc cần suy nghĩ kỹ, tôi dùng Opus với cửa sổ ngữ cảnh 1 triệu token và chế độ suy luận cao nhất. Với tác vụ đơn giản như tạo báo cáo, ghi chú phát hành hay kiểm tra tài liệu, tôi dùng mô hình nhẹ hơn để tiết kiệm token.

Patrick Baumgartner: Ủy quyền thực thi, không ủy quyền trách nhiệm

Patrick Baumgartner làm việc với các nhóm phát triển, huấn luyện họ trong khi công việc kinh doanh vẫn diễn ra bình thường. Ông chia sẻ ba câu chuyện rất khác nhau về cách Copilot thay đổi tư duy làm việc của mình.

Câu chuyện thứ nhất là việc chuyển khoảng 900 slide bài giảng trong 15 bộ trình chiếu từ Reveal.js sang Marp. Nhiều slide chứa mã, hoạt ảnh và cả ví dụ tương tác có thể chỉnh JavaScript trực tiếp khi giảng dạy. Thay vì làm thủ công mất cả tuần, ông xử lý theo hướng có kỷ luật: phân tích tài liệu hiện có, xác định mục tiêu, lập kế hoạch chuyển đổi, đặt ra ràng buộc và yêu cầu những gì phải giữ nguyên.

Điểm quan trọng nhất là xác minh. Nhóm tạo ảnh chụp từ cả hai phiên bản để so sánh bằng mắt và bằng thuật toán, dựng một ứng dụng nhỏ chạy song song hai bộ slide để kiểm tra hoạt ảnh, thậm chí so sánh cả file PDF xuất ra.

Agent không chỉ nói "đã chuyển đổi xong". Chúng tôi có bằng chứng.

Toàn bộ quá trình mất khoảng 8 đến 10 giờ. Ông vẫn nắm quyền quyết định về nội dung, ý đồ giảng dạy và mọi thay đổi có ý nghĩa. Từ đó rút ra nguyên tắc: ủy quyền việc thực thi, nhưng không ủy quyền trách nhiệm.

Câu chuyện thứ hai liên quan đến một ứng dụng giao diện dòng lệnh viết bằng Tamboui, chạy hoàn hảo trên Linux nhưng bị lỗi khi người dùng thật chạy trên Windows CMD hay PowerShell — phím Enter bị bỏ qua trong một số biểu mẫu. Copilot giúp biến phản hồi đó thành các bài kiểm thử giao diện có thể tái lập. Đáng chú ý, khi mô tả kiểm thử trở nên quá dài so với ngữ cảnh, Copilot đề xuất một ký pháp mũi tên gọn hơn: bước → bước → đầu vào, chỉ thêm thông tin khi thật cần thiết.

Câu chuyện thứ ba là một ứng dụng học toán nhỏ cho trẻ lớp 1 đến lớp 4. Copilot đóng vai trò đối tác phản biện, thách thức giả định ban đầu rằng ứng dụng nên dùng chung cho trẻ mọi nơi. Qua nghiên cứu chương trình học thực tế, họ quyết định tập trung vào Thụy Sĩ trước, với giao diện tiếng Đức, Pháp, Ý và Anh. Ứng dụng không có backend để tránh thu thập dữ liệu cá nhân của trẻ, dữ liệu lưu trên thiết bị và có thể triển khai đơn giản qua GitHub Pages.

Bảng điều khiển Copilot hỗ trợ lập trình viên

Bốn nguyên tắc thực hành đáng học hỏi

Baumgartner hiện gần như đã chuyển hẳn sang quy trình làm việc dạng agent thay vì dùng tính năng tự động hoàn thành cổ điển. Ông dùng VS Code khi cần vòng phản hồi trực quan chặt chẽ, và dùng agent trong terminal cho những tác vụ thực thi lớn hơn. Có lần, trên chuyến tàu bốn tiếng đến JavaLand, ông điều khiển agent từ điện thoại và đến nơi đã có một plugin Maven hoạt động, pipeline CI, kiểm thử hiệu năng và báo cáo chứng minh tối ưu hóa thực sự có tác dụng.

Ông đúc kết bốn nguyên tắc:

• Đừng "prompt một phát". Với việc không đơn giản, hãy yêu cầu agent phỏng vấn mình trước để lộ ra những giả định còn ẩn. Một agent giỏi có thể thực thi sai ý tưởng cực nhanh, và đường vòng thì rất tốn kém.
• Đặt cổng xác minh theo từng tác vụ. "Xong" không có nghĩa là mô hình tự nói đã xong. Với refactor, đó là test pass, chứng minh mọi file dự kiến đã xử lý, cập nhật tài liệu và không còn TODO nào.
• Biến bài học thành skill tái sử dụng. Khi phát hiện agent hiểu sai quy ước hay thiếu một bước kiểm tra hữu ích, hãy cập nhật skill để lần sau bài học đã có sẵn.
• Bọc mô hình xác suất bằng công cụ kỹ thuật tất định. Ông có bộ kiểm tra chất lượng riêng gói các công cụ như Checkstyle, PMD và kiểm tra kiến trúc Spring Modulith, tạo báo cáo hợp nhất để agent đọc và lặp: thay đổi → chạy kiểm tra → đọc kết quả → sửa → chạy lại.

Yêu cầu làm tất cả cùng lúc vì "AI làm được" thường là ý tồi. Đặc tả lớn và chung chung tạo ra triển khai lớn và chung chung — và dọn dẹp sau đó có thể khó hơn nhiều so với xây dựng từng bước nhỏ cho đúng.

Frank Delporte: Copilot là người bạn đồng hành khi gỡ lỗi

Frank Delporte bắt đầu mê máy tính từ chiếc Commodore 64 năm 11 tuổi. Với ông, Copilot là công cụ hoàn hảo để đánh giá pull request và điều tra báo cáo lỗi. Câu chuyện nổi bật là lỗi trong thư viện Pi4J — thư viện cho phép viết ứng dụng Java tương tác với linh kiện điện tử trên Raspberry Pi.

Sau khi phát hành phiên bản V4 dùng plugin mới với Foreign Function & Memory API, có người báo lỗi: cấu hình 5 nút bấm thì 4 nút đầu hoạt động, nút thứ năm hoàn toàn im lặng. Không ngoại lệ, không cảnh báo trong log. Plugin cũ trên cùng phần cứng lại chạy tốt, nên lỗi nằm ở phần mã FFM mới.

Ông giao issue cho Copilot coding agent, chỉ cung cấp hai đường dẫn file làm điểm khởi đầu. Khoảng nửa giờ sau có một pull request kèm lời giải thích không ngờ tới. Mỗi đầu vào chạy một bộ theo dõi sự kiện bị chặn trong lệnh gọi poll() gốc chờ kernel báo thay đổi trên đường GPIO. Các bộ theo dõi này chạy trên virtual thread, và một virtual thread bị chặn trong lệnh gọi gốc sẽ không thể tách khỏi luồng mang nó — nó bị ghim ở đó suốt thời gian gọi. Raspberry Pi 4 có 4 lõi, nên bộ lập lịch có 4 luồng mang. Đăng ký 4 đầu vào, cả 4 luồng mang bị giữ trong poll() vĩnh viễn; bộ theo dõi thứ năm được tạo nhưng không bao giờ được lập lịch.

Điều ông thích nhất không phải bản vá mà là cuộc trao đổi sau đó trong phần review, khi Copilot giải thích chi tiết tại sao mục tiêu của virtual thread lại vướng vào giới hạn luồng nền tảng trên phần cứng 4 lõi.

Lời khuyên từ thực tế

• Chỉ cho nó nơi cần tìm: hai đường dẫn file là một chút công sức nhỏ giúp loại bỏ rất nhiều thời gian dò tìm trong mã nguồn lớn. Bạn thường có linh cảm về khu vực chứa lỗi dù chưa biết chính xác.
• Yêu cầu bằng chứng và kiểm thử: "Thêm unit test để kiểm chứng thay đổi" giờ đã thành một quy tắc trong file hướng dẫn của ông. Nó cũng phát hiện trường hợp chẩn đoán sai, vì test sẽ không thất bại trên mã cũ.
• Hỏi tại sao: nếu không hiểu bản vá, hãy nói ra và hỏi. Bản giải thích cũng là một sản phẩm cần bàn giao, nên được đưa vào tài liệu hoặc ticket.
• Giữ quyền kiểm soát: mọi pull request của agent trong Pi4J đều được người bảo trì xem xét và phê duyệt trước khi hợp nhất. Agent điều tra, con người chịu trách nhiệm về thứ được phát hành.

Bạn có thể đi rất nhanh với lập trình có AI hỗ trợ, đồng nghĩa bạn cũng có thể tạo ra một mớ hỗn độn rất nhanh. Đừng làm thế — hãy giữ mã dễ quản lý, đồng nghiệp và chính bạn trong tương lai sẽ biết ơn.

Bài học chung cho lập trình viên Việt Nam

Cả ba chuyên gia đều đồng tình rằng AI đang đưa kỹ thuật trở lại với nghề kỹ thuật phần mềm. Sinh viên không nên chỉ hướng tới việc trở thành cỗ máy sinh mã, mà cần trở thành người giải quyết vấn đề giỏi: hiểu người dùng, khám phá vấn đề thật sau mỗi yêu cầu, đặt câu hỏi với giả định, cân nhắc đánh đổi kiến trúc và tư duy phản biện.

Với các nhóm phát triển tại Việt Nam đang đẩy mạnh ứng dụng AI, thông điệp khá rõ ràng: hãy dùng Copilot như một đối tác phản biện chứ không phải cỗ máy thực thi mù quáng, thiết lập cổng xác minh trước khi tăng tốc, và luôn giữ người thật ở khâu quyết định cuối cùng.