Công cụ mã hóa AI vẫn đang trong giai đoạn R&D

Theo khảo sát năm 2024 của Stack Overflow , 76% nhà phát triển đang sử dụng hoặc có kế hoạch sử dụng các công cụ AI—giờ đây chúng chỉ là một phần của công việc. Chúng giúp ích cho các nhiệm vụ tầm thường nhưng có thể gây khó chịu khi chúng tự tin tạo ra những điều vô nghĩa. Trong khi những người dùng YouTube xây dựng "các công ty khởi nghiệp trị giá hàng tỷ đô la" bằng lời nhắc ChatGPT và các tác nhân AI đang chiếm lĩnh thế giới mỗi tuần, thì các nhóm thực sự vẫn đang tìm cách sử dụng các công cụ này một cách hiệu quả. Ngày nay, việc thành thạo trợ lý AI cũng cơ bản như mã hóa hoặc thiết kế hệ thống—chúng ta cần phải thích nghi và nhanh chóng.

Vấn đề là các công cụ này về cơ bản vẫn đang trong giai đoạn R&D—chúng liên tục thay đổi, sao chép lẫn nhau và xứng đáng được ghi nhận vì đã giải quyết được các vấn đề trước đây chưa được giải quyết. Tất cả chúng đều thiếu hướng dẫn sử dụng rõ ràng. Ngay cả Copilot, mặc dù đã thành danh hơn, cũng thiếu hướng dẫn rõ ràng và các biện pháp thực hành tốt nhất. Giải pháp là gì? Chúng tôi sẽ làm những gì các nhà phát triển làm tốt nhất—tự tổ chức và tạo ra một khuôn khổ.

Người thay đổi cuộc chơi

...và cả " Bước nhảy vọt lượng tử ", " Chuyển đổi mô hình ", " Các tác nhân đang đến ", bạn cứ nói đi. Mặc dù các công cụ này thực sự đang chuyển đổi quy trình làm việc của chúng ta, nhưng sự thay đổi này thực tế hơn: các nhà phát triển hiện hoạt động như các trưởng nhóm, quản lý trợ lý AI thay vì viết mã trực tiếp. Các kỹ năng cốt lõi đã chuyển sang thiết kế, lập kế hoạch, mô tả và đánh giá.

Các khái niệm UX chính mà các công cụ này giới thiệu là:

1. Gợi ý nội tuyến - mô hình tích hợp tự nhiên nhất. Khi chúng hoạt động, chúng liền mạch—nhưng khi chúng làm gián đoạn mã của bạn, năng suất sẽ bị gián đoạn ngay lập tức.
2. Trò chuyện - phương pháp cổ điển trong đó LLM tương tác với cơ sở mã của bạn thông qua lời nhắc có hướng dẫn
3. Composer (" Copilot Edit ", " Cline act ") - khái niệm mới mà nhiều người thấy khó hiểu . Đây là sự chuyển dịch sang các tác nhân tự động. Composer hoạt động trên nhiều tệp và có thể áp dụng các thay đổi và lặp lại tự động dựa trên lỗi, sự cố kiểm tra lỗi, v.v.
4. Agent - bước tiến hóa tiếp theo được mong đợi - trợ lý AI hoàn toàn tự động và được cá nhân hóa, tích hợp trực tiếp vào IDE của bạn.

Làm quen với " gợi ý " không phức tạp. Trợ lý AI bắt đầu với chúng, điều đầu tiên thu hút sự chú ý của chúng tôi. Trò chuyện rất đơn giản: chèn tệp vào ngữ cảnh, lặp lại, áp dụng và xác thực kết quả.

Các công cụ kiểu Composer có nhiều thách thức hơn để thành thạo, đòi hỏi đường cong học tập và một số cách tiếp cận không rõ ràng. Hiện tại, trình chỉnh sửa Cursor cung cấp công cụ "composer" dễ tiếp cận nhất, trong khi Copilot theo sát với " Copilot Edits ", gần đây đã giới thiệu quy trình làm việc dựa trên tác nhân.

Để trở nên thành thạo với các nhà soạn nhạc, bạn cần hiểu ba khái niệm chính:

1. Hướng dẫn
2. Quy tắc
3. Bối cảnh

Chúng ta hãy cùng xem xét từng điều này.

Hướng dẫn

Với tư cách là người đứng đầu nhóm chứ không chỉ là nhà phát triển, chúng ta nên bắt đầu bất kỳ dự án mới hoặc tính năng chính nào bằng cách tạo Tài liệu thiết kế hoặc Tài liệu yêu cầu sản phẩm rõ ràng. Thực hành này phát triển tư duy kỹ thuật và sản phẩm mạnh mẽ trong khi tiết kiệm đáng kể thời gian triển khai. Phần tốt nhất là các tài liệu này có thể:

1. Được tạo ra bằng AI
2. Và sau đó được sử dụng như một hướng dẫn cho các nhà soạn nhạc

Để tạo ra các tài liệu này, trước tiên hãy thu thập các yêu cầu từ con người , sau đó tham khảo mô hình lý luận trong Chat. Cả Copilot và Cursor đều có các mô hình lý luận tích hợp phù hợp cho nhiệm vụ này. o1 và o3-mini của OpenAI có sẵn theo mặc định, trong khi Chat của Cursor hỗ trợ DeepSeek-R1 (mặc dù chưa có trong Composer ) – tất cả đều là những công cụ tuyệt vời cho mục đích này.

Một cách thực hành tốt là lưu trữ các tài liệu thiết kế ở cấp cao nhất của kho lưu trữ (chúng ta sẽ sử dụng thư mục requirements ) được sắp xếp theo tính năng, với ProjectOverview.md ở gốc. Sau đây là cấu trúc ví dụ cho các yêu cầu của ứng dụng web Twitter:

 requirements/ ├── ProjectOverview.md # Core product description └── Features/ ├── Authentication.md # User registration ├── Tweet.md # Tweet CRUD ├── UserProfile.md # Profile management ├── Engagement.md # Likes, retweets ├── Infrastructure.md # Storage, caching, etc └── ...

Nếu mọi thứ được thiết lập đúng cách, việc thêm tài liệu thiết kế cho tính năng mới cũng đơn giản như viết lời nhắc này:

Lưu trữ hướng dẫn trong cơ sở mã của bạn mang lại những lợi thế rõ ràng: kiểm soát phiên bản, bảo trì dễ dàng và quy trình làm việc PR chuẩn. Tuy nhiên, các thành viên nhóm không chuyên về kỹ thuật như Chủ sở hữu sản phẩm, quản lý và nhà thiết kế UX có thể cần truy cập mà không cần sử dụng git. Sau đây là ba giải pháp:

1. Lưu trữ mọi thứ trong Notion, xuất bản các trang hướng dẫn và đưa chúng vào dưới dạng tài liệu bằng phím tắt @Docs

2. Tạo một đường ống chuyển đổi các trang Notion thành các tệp .md và lưu trữ chúng trong kho lưu trữ
3. Dạy nhóm của bạn cách sử dụng git - lựa chọn có lợi nhất cho toàn bộ nhóm

Khi hướng dẫn của bạn có thể truy cập được trong trình soạn thảo, hãy chuyển sang trình soạn thảo và bắt đầu triển khai. Điều này dẫn chúng ta đến việc sắp xếp các Quy tắc .

Quy tắc

Hiện tại, chỉ có Cursor hỗ trợ " quy tắc " - hướng dẫn triển khai trực tiếp cho các tệp/thư mục cụ thể. Tính năng này có thể sẽ lan sang các trình soạn thảo khác, bao gồm VSCode Copilot, hiện chỉ cung cấp " tệp nhắc " không thể đính kèm trực tiếp vào cơ sở mã.

Các quy tắc của Cursor toàn diện hơn - hãy tưởng tượng CONTRIBUTING.md kết hợp với các quy tắc linter và được tăng cường bởi các khả năng của LLM. Các quy tắc này không phụ thuộc vào sản phẩm, có thể chia sẻ và chuyển giao hiệu quả kiến thức, các phương pháp hay nhất và chi tiết triển khai giữa các nhóm và người dùng thư viện.

Có thể tạo quy tắc thông qua bảng lệnh và được lưu trữ trong thư mục .cursor/rules của dự án với phần mở rộng .mdc . Định dạng này cho phép các tính năng nâng cao như @mentioning các tệp cụ thể trong cơ sở mã của bạn. Rất khuyến khích bạn cam kết các quy tắc này vào kho lưu trữ của mình và cộng tác để cải thiện chúng. Sau đây là quy trình làm việc để sử dụng quy tắc:

1. Nghiên cứu các quy tắc con trỏ dành riêng cho công nghệ của bạn, bắt đầu bằng các danh sách được tuyển chọn làm tài liệu tham khảo. Ví dụ, bạn có thể tìm thấy các quy tắc con trỏ được viết tốt cho Next.js và React đóng vai trò là các mẫu tốt.
2. Cập nhật các quy tắc chủ động trong quá trình phát triển. Khi bạn nhận thấy một mẫu có thể được chính thức hóa thành một quy tắc trong khi viết mã, hãy ghi lại ngay trong tệp quy tắc của bạn.
3. Học hỏi từ những người giỏi nhất trong lĩnh vực này. Một cách tiếp cận mới để những người sáng tạo thư viện chia sẻ kiến thức và tăng cường áp dụng là tạo ra các quy tắc chuyên biệt cho trợ lý AI. Tôi biết có rất ít công ty làm như vậy - Convex nổi bật với việc tạo ra các quy tắc cho cả mô hình OpenAI và Anthropic và chia sẻ chúng trong tài liệu của họ . Mặc dù tôi chưa sử dụng sản phẩm của họ, nhưng việc họ tập trung vào việc cải thiện trải nghiệm của nhà phát triển thông qua tích hợp AI là rất hấp dẫn. Supabase là một ví dụ tuyệt vời khác.

Nhiều thư viện đang rất cần các quy tắc AI. Theo quan điểm của một nhà phát triển front-end, tôi sẽ được hưởng lợi khi có chúng cho TanStack Query , React Spring , Firebase và nhiều-nhiều hơn nữa. Các quy tắc này sẽ tiết kiệm đáng kể thời gian và giúp ngăn ngừa những sai lầm thường gặp mà các nhà phát triển mắc phải khi học các công nghệ mới.

Bối cảnh

Hãy nhớ bao gồm tất cả ngữ cảnh có liên quan - bạn cung cấp càng nhiều dữ liệu chất lượng thì kết quả bạn nhận được càng tốt. Trình chỉnh sửa con trỏ có lợi thế hơn Copilot ở đây bằng cách cho phép một số loại ngữ cảnh:

1. Tài liệu - hoạt động thực sự tốt, chỉ cần cung cấp cho nó điểm vào bất kỳ tài liệu nào, nó sẽ tải xuống, phân tích cú pháp và lưu lại cho các nhu cầu trong tương lai
2. Tìm kiếm trên web - không chỉ theo ngữ cảnh, mà còn cung cấp quyền truy cập nhanh vào các tài nguyên trực tuyến
3. Nhiều công cụ phát triển khác nhau - các cam kết git cụ thể, lỗi lint, Notepad và các hiện vật khác
4. Máy chủ MCP có thể cung cấp ngữ cảnh thời gian thực. Mặc dù thiết lập hơi khó khăn, nhưng chúng rất có giá trị khi bạn cần truy cập dữ liệu trực tiếp.

Sau khi thành thạo các công cụ này, bước tiếp theo của bạn là tối ưu hóa hiệu suất của cả cá nhân và nhóm. Nhưng con đường phía trước từ đây là gì?

Cline và Roo-Code. Kiểm soát

Bạn sẽ luôn phải đối mặt với sự đánh đổi giữa tính đơn giản và khả năng kiểm soát, giữa các giải pháp tự động và việc ra quyết định thủ công. Nếu bạn sẵn sàng tìm hiểu sâu và không sợ phải đối mặt với lỗi, thách thức về hiệu suất và các khía cạnh thô, hãy cân nhắc dùng thử Cline (hoặc nhánh Roo-Code của nó, có triết lý hơi khác một chút).

Cả hai công cụ đều được thiết kế để cung cấp càng nhiều thông tin về những gì thực sự đang diễn ra bên trong càng tốt:

1. Chúng là mã nguồn mở và không cần đăng ký. Thay vào đó, bạn sử dụng khóa API LLM hoặc dịch vụ của riêng mình như OpenRouter , chỉ trả tiền cho những gì bạn sử dụng.
2. Cline hiển thị rõ ràng tất cả các hoạt động của nó, bao gồm cả những tập tin nó đọc và sửa đổi.
3. Cline cung cấp thông tin chi tiết về giao tiếp LLM, trạng thái cửa sổ ngữ cảnh và chi phí của mỗi phiên trò chuyện.
4. Nó có chế độ Kế hoạch/Hành động trực quan - một cách tiếp cận hợp lý mà các công cụ khác nên cân nhắc áp dụng.

Tính năng tuyệt vời nhất là Cline thực sự có thể chạy và gỡ lỗi ứng dụng của bạn - nó thực sự hữu ích và có thể hoạt động được, như bạn sẽ thấy khi dùng thử.

Nếu bạn quan tâm đến tất cả những điều này, hãy xem bài viết gần đây của Addy Osmani , trong đó có phần giới thiệu tuyệt vời về những biên tập viên này.

Phần kết luận

Việc áp dụng các công cụ này không phải là một hành trình đơn giản và đừng mong đợi có thể "viết toàn bộ dự án từ đầu trong vòng chưa đầy 5 phút". Tuy nhiên, đây là một con đường rõ ràng để tiến về phía trước.

Công nghệ đã có, nhưng chúng ta đang thiếu một quy trình làm việc tích hợp AI mạnh mẽ, quy trình này sắp xếp toàn bộ nhóm - không chỉ các nhà phát triển, mà quan trọng hơn là các nhà quản lý và nhà thiết kế - xung quanh các công cụ mới này. AI có thể gây cảm giác sợ hãi và việc chia sẻ tác động của nó có thể có vẻ không thoải mái lúc đầu (giống như nói với người đứng đầu nhóm của bạn rằng AI đã viết 80% tính năng thông qua cấu hình cẩn thận). Tuy nhiên, phát triển phần mềm sẽ chỉ phát triển khi các công cụ này trở thành một phần không thể thiếu trong quy trình làm việc của nhóm. Những quá trình chuyển đổi thành công nhất xảy ra trong các nhóm thúc đẩy thảo luận cởi mở về trải nghiệm AI, khám phá công cụ cộng tác và tích cực đóng góp các phương pháp hay nhất đã học được của họ cho cộng đồng phát triển rộng lớn hơn.