Trong không gian ấm cúng tại trụ sở Công ty đào tạo lập trình CodeGym, một chương mới đã mở ra cho cộng đồng cựu học viên/học viên với sự ra mắt chính thức của CodeGym Alumni Club – Nơi các cựu học viên cùng nhau chia sẻ kiến thức, kinh nghiệm và hỗ trợ nhau trong công việc lập trình.
Mở ra chương đầu tiên cho CLB, giữa làn sóng AI đang làm đảo lộn mọi quy trình nghiệp vụ, buổi chia sẻ của Mr. Nguyễn Văn Đức (Technical Leader – NTT Data VDS) không chỉ dừng lại ở việc giới thiệu công cụ. Đó là một cuộc đối thoại thẳng thắn, đầy “mồ hôi và nước mắt” về cách chúng ta làm chủ AI, thay vì để nó dẫn dắt vào những “ảo giác” tai hại.
Trước khi đến với buổi chia sẻ của anh Đức, chị Châu – đại diện Ban lãnh đạo CodeGym – đã gửi gắm một thông điệp xúc động: “CLB này sinh ra từ mong muốn kết nối những cựu học viên – những người đã đi làm 5 – 10 năm, những người đang nắm giữ những vị trí then chốt trong nghề, để cùng nhau học hỏi và phát triển, mở rộng hỗ trợ lẫn nhau không chỉ trong cộng đồng cựu học viên mà còn rộng ra là những học viên/bạn trẻ có niềm đam mê với công việc lập trình”
Tiếp lời, anh Thế từ Ban điều hành CLB đã nhấn mạnh một thực tế khắc nghiệt: “Ngày xưa anh em mình chỉ cần code là xong, nhưng bây giờ AI lên rồi, công việc khác đi rất nhiều”. Anh Thế và anh Tuấn cũng khẳng định, việc mở rộng kết nối (connection) không còn là lựa chọn mà là bắt buộc để chúng ta không bị tụt hậu trong kho tàng tri thức khổng lồ mà AI đang tạo ra. Buổi chia sẻ về IDE AI-native chính là phát súng đầu tiên để anh em cùng nhau “update” tư duy.
Mở đầu buổi chia sẻ tại CodeGym Alumni Club, diễn giả Nguyễn Văn Đức đặt ra một tình huống thực tế: Điều gì xảy ra nếu một ngày server AI bị sập hoặc kết nối bị gián đoạn? Câu trả lời rất đơn giản: Bạn phải quay lại làm một lập trình viên thuần túy.
Nhiều người lầm tưởng rằng trong kỷ nguyên AI, các tính năng truyền thống của IDE không còn quan trọng. Nhưng sự thật hoàn toàn ngược lại. Một IDE được gọi là “tinh hoa” trước hết phải chiến thắng ở những giá trị cốt lõi nhất: Tốc độ phản hồi không làm đứt gãy tư duy, khả năng điều hướng file mượt mà và một trình gỡ lỗi tin cậy
Để giúp các anh em cựu học viên dễ hình dung, diễn giả đưa ra một ví dụ về chiếc ô tô. Một chiếc xe muốn chạy được cần có hai thành phần là động cơ và bộ khung kèm các linh kiện điều khiển. Để cộng tác thành công, chúng ta cần thay đổi thế giới quan về công cụ. Trong khi mô hình ngôn ngữ lớn (LLM) đóng vai trò là động cơ cung cấp khả năng suy luận, thì IDE chính là bộ khung điều phối (Harness Engine).
Một IDE tốt là một hệ thống biết cách “nén” hàng nghìn dòng code vào cửa sổ ngữ cảnh hẹp, biết cách “mớm” thông tin thông minh cho AI và quản lý các công cụ bổ trợ một cách an toàn” .
4 nhóm tiêu chí để đánh giá một IDE trong kỷ nguyên AI
Session & Context
IDE phải có khả năng đọc hiểu toàn bộ kho mã nguồn, bao gồm cả trạng thái Git và các thay đổi chưa commit. Khi cửa sổ ngữ cảnh bị lấp đầy, IDE phải biết tự động tóm tắt mà không làm mất đi các quyết định quan trọng. Khả năng khôi phục hoàn hảo phiên làm việc sau khi đóng máy hoặc crash, đảm bảo AI không bị “mất trí nhớ” tạm thời.
Hỏi: “Tại sao chat quá dài thì bị lag và AI trả lời ngày càng kém?”
Đáp: Dù các nhà cung cấp quảng cáo cửa sổ ngữ cảnh lên tới 1 triệu token, nhưng thực tế khi vượt quá 300.000, AI bắt đầu “đần” đi hoặc tự ý tóm tắt làm mất các chi tiết quan trọng.
Giải pháp được đề xuất:
– Đừng chat quá dài trong một phiên làm việc.
– Sử dụng lệnh Summarize/Compaction để lấy lại các highlight quan trọng rồi mở một chat mới hoàn toàn “sạch sẽ”.
– Lưu lịch sử chat quan trọng ra file .md để làm “bộ nhớ cứng” cho AI đọc lại khi cần, tránh bị bias bởi các phiên làm việc cũ.
Control & Customization
IDE phải cho phép tạm dừng và điều hướng Agent ngay giữa task hoặc quay lại các điểm kiểm tra khi AI bắt đầu ảo giác. Có khả năng giao nhiều task khác nhau cho nhiều Agent hoạt động độc lập mà không gây xung đột. Cho phép người dùng mã hóa các quy ước riêng của team thông qua các file như agent.md hoặc .cursorrules.
Hỏi: “Tại sao AI đôi khi trả lời vòng vo và đưa ra code rất khó hiểu?”
Đáp: AI vòng vo thường là dấu hiệu của việc nó đang “mù mờ” về môi trường chạy hoặc đang cố đoán ý người dùng do prompt không rõ ràng. Khi đó, AI sẽ tự khám phá, tự suy luận sai hướng và tạo ra một mớ hỗn độn.
Hãy dừng ngay khi thấy dấu hiệu sai. Điều này không chỉ tiết kiệm token mà còn ngăn chặn việc lưu những dữ liệu ‘rác’ vào bộ nhớ của model. Một số IDE như Cloud Code cho phép bạn “vỗ vai” Agent ngay khi nó đang chạy để điều hướng lại: “Đừng đi hướng đó nữa, hãy làm theo hướng này”.
Safety & Observability
Niềm tin trong cộng tác được xây dựng trên sự minh bạch. Một “hộp đen” không thể là đồng nghiệp tin cậy. IDE có chức năng ngăn AI tự ý thực hiện các lệnh nguy hiểm hay thay đổi dữ liệu ngoài. Có khả năng nhìn thấu từng bước tư duy của AI để biết tại sao nó sai.
Extended Capabilities
Sức mạnh vượt ra ngoài màn hình editor – từ đặc tả hệ thống đến cloud agent chạy ngầm khi bạn ngủ. IDE có hỗ trợ quản lý nhiều Agent chạy song song không? Nó có cho phép bạn giao việc qua Cloud Agent để bạn có thể theo dõi tiến độ ngay trên điện thoại khi đang đi ngoài đường không?
Anh Đức kể về một lần sử dụng AI Agent được cấp quyền truy cập vào hệ thống Jira thông qua giao thức MCP (Model Context Protocol). Anh chỉ muốn AI đọc ticket để thực hiện task, nhưng vì vô tình bật hết các công cụ (tools) mà không giới hạn quyền, AI đã tự suy luận rằng yêu cầu trong ticket chưa rõ ràng và… tự cập nhật lại description trên Jira của khách hàng bằng chính tài khoản của anh.
“Sáng hôm sau, khách hàng nhắn tin hỏi tại sao tôi lại sửa yêu cầu của họ. Tôi đã phải viết một email xin lỗi rất dài và cam kết không để chuyện đó xảy ra nữa,” Đức chia sẻ. Bài học rút ra: Đừng bao giờ thỏa hiệp với các nguyên tắc an toàn. Một IDE tốt phải có cơ chế phê duyệt (approval gates) cho những hành động có tính phá hủy hoặc tác động ra bên ngoài.
Một thành viên trong đội của Đức đã loay hoay suốt 5 ngày vì AI Agent hoạt động không hiệu quả, trả lời sai lệch hoặc luôn tìm kiếm thông tin ở những nguồn công cộng thay vì kho code nội bộ. Chỉ đến khi Đức mở trình quan sát trong IDE ra, anh mới phát hiện ra lỗi cực kỳ đơn giản: Member đó chưa cấu hình Token để AI truy cập vào repository riêng tư.
Nếu IDE không cung cấp khả năng quan sát (Observability) – cho phép chúng ta nhìn thấy AI đang nghĩ gì, nó gọi công cụ nào và tại sao nó thất bại – thì chúng ta sẽ mãi kẹt trong một “hộp đen” mù mịt.
Công cụ không phải là vấn đề, giải quyết được công việc mới là vấn đề. Để chọn được IDE phù hợp nhất với phong cách cá nhân, lập trình viên nên:
Thực hiện Self-Benchmark: Dành ra 1-2 tiếng để giải quyết một bài toán thực tế (đa file, đa tầng) trên các IDE khác nhau với cùng một prompt.
Đánh giá sự thoải mái: Chấm điểm dựa trên chất lượng điều phối (Harness Quality) thay vì chỉ nhìn vào số dòng code AI tạo ra,.
Thước đo cuối cùng: Lựa chọn IDE giúp rút ngắn khoảng cách từ Ý định (Intent) đến Kết quả (Outcome) nhanh nhất mà vẫn giữ được sự kiểm soát tuyệt đối.
Trong cuộc cộng tác này, Mindset quan trọng hơn Tool. IDE xuất sắc nhất là công cụ “biến mất” nhanh nhất khỏi tầm mắt khi bạn làm việc, nhưng luôn sẵn sàng để bạn giành lại quyền kiểm soát bất cứ lúc nào.
Công cụ không
phải là vấn đề
Buổi TechTalk đầu tiên của CodeGym Alumni Club khép lại không phải bằng một danh sách công cụ nên dùng, hay một IDE được chọn là “winner”. Nó khép lại bằng một tư duy: Kỷ nguyên AI không cần lập trình viên biết dùng nhiều tool nhất — nó cần những người biết đặt câu hỏi đúng, thiết lập quy tắc an toàn, và không bao giờ nhường ghế phi công.
Hẹn gặp lại — Thứ Bảy, tuần thứ 2 mỗi tháng — tại CodeGym
Xem chi tiết buổi tecktalk tại video và slide dưới đây
