Xin chào các lập trình viên! Đã bao giờ bạn mơ ước có một đội ngũ AI hỗ trợ bạn viết code, test và thậm chí là refactor code? Nghe có vẻ như khoa học viễn tưởng, nhưng điều này hoàn toàn có thể trở thành hiện thực với một quy trình làm việc tự động hóa mà mình sắp chia sẻ. Đặc biết sẽ có món quà ở dưới cho các bạn đọc hết nhé!!
Giới thiệu “The A.I. Team”
“The A.I. Team” không phải là một nhóm các chuyên gia AI bằng xương bằng thịt, mà là một quy trình gồm 4 công cụ AI hoạt động liên kết, giúp tự động hóa đến 80% công việc lập trình của bạn. 20% thời gian còn lại, bạn chỉ cần tập trung đánh giá, điều chỉnh và đưa ra quyết định cuối cùng.
Quy trình làm việc:
Một phiên làm việc của mình sẽ được thực hiện như sau:
1. Mô tả yêu cầu
Bạn chỉ cần “buôn” một câu ngắn gọn về tính năng cần làm. Ví dụ: “Tôi muốn thằng user đăng nhập bằng Google cho nhanh” , càng ngắn gọn càng tốt miễn sao AI có thể hiểu ý là được.
2. Story Writing Bot (AI – Powered Story Generator):
Anh chàng này sẽ biến những câu nói “tầm phào” của bạn thành một “Story” theo dạng Gherkin. Nếu bạn chưa biết định dạng Gherkin là gì thì đó là một định dạng giúp chúng ta viết mô tả tính năng của phần mềm và những tình huống có thể xảy ra, định dạng này rất là dễ đọc và theo mình nghĩ đây là định dạng giúp con bot nó nắm bắt ý tưởng của mình một cách rõ ràng nhất, đảm bảo đọc xong là hiểu ngay vấn đề.
Ví dụ:
3. Unit Testing Bot (AI-Powered Test Generator):
Từ “Story” Gherkin ở trên, chúng ta tiếp tục gặp gỡ với “anh bạn” tiếp theo “Unit Testing Bot” ở đây ngoài đoạn mô tả Gherkin chúng ta cũng cần phải cung cấp cho anh bạn đó thêm những file source code trong project hiện tại liên quan quan đến “story” kể trên, cùng với các file test hiện tại (nếu có).
Quá trình làm việc ở “anh bạn” này sẽ như sau. Đầu tiên anh ta sẽ ”đọc kỹ từng chữ” trong “story” đã được cung cấp trước đó. Từ đó, anh ta sẽ hiểu rõ tình huống có thể xảy ra và kết quả mong đợi mong đợi. Bước tiếp theo “soi source code” , anh ta sẽ soi kỹ từng dòng code của bạn, tìm hiểu xem code đã được viết để xử lý các tình huống trong “story” Gherkin chưa. Cuối cùng “anh bạn“ này sẽ viết ra những file unit test mới hoặc nó sẽ update những file test cũ. Các unit test này sẽ kiểm tra từng tình huống trong câu chuyện Gherkin, đảm bảo rằng code hoạt động đúng như mong đợi.
4. Implementation Bot (AI-Powered Code Generator):
Đây chính là “ngôi sao sáng” của nhóm chuyên gia A.I này. Sau khi Unit Testing Bot hoàn thành nhiệm vụ “truy tìm” bug và cập nhật những testcase cần thiết, đến lượt “Implementation Bot” – anh chàng “phù thủy code” tài ba ra tay. Với những testcase mới này cùng source code hiện tại của dự án, Implementation Bot sẽ bắt đầu quá trình “hô biến” của mình. Anh chàng này có khả năng viết mới hoặc sửa đổi code sao cho tất cả các testcase đều “pass” một cách mượt mà. Sau khi hoàn thành nhiệm vụ, Implementation Bot sẽ đưa ra một phiên bản code đã được cập nhật. Lúc này, chúng ta chỉ việc chạy thử code trên máy và kiểm tra xem liệu tất cả các testcase đã “pass” hay chưa.
Nếu test case nào đó bị fail, đừng lo lắng. Bạn chỉ cần đưa lại lỗi đó cùng với code đã được cập nhật cho Implementation Bot, và hỏi lại nó xem “Điều gì đã gây ra lỗi này và hãy fix lỗi này đi” và con bot sẽ tiếp tục sửa lỗi và cung cấp cái implementation cho đến khi nào tất cả các test case đều pass thì thôi.
5. Refactor Bot (AI-Powered Code Refactoring Tool):
Ok. Sau khi tất cả test case đã được pass thì mình sẽ tiếp tục chuyển qua con bot thứ 4 Refactor Bot con bot này có nhiệm vụ refactor lại code sao cho code dễ đọc dễ bảo trì dễ test, và bởi vì chúng ta đã có test rồi cho nên nó có thể sửa thoải mái miễn là các test vẫn pass.
Kết quả của phiên làm việc này sẽ là những đoạn code mới đáp ứng được cái yêu cầu mà bạn đưa ra ở trên và đầy đủ test cho nó
Nếu bạn là một lập trình viên có kinh nghiệm thì bạn sẽ nhận ra đây chính là 1 vòng đời của 1 phiên làm việc theo phương pháp TDD (Test Driven Development).
Đây là 1 phương pháp có rất nhiều lợi ích cho lập trình viên chúng ta tuy nhiên nó chưa thực sự phổ biến bởi vì cái việc viết test đôi khi chúng ta lại rất lười viết test và thậm chí là theo phương pháp này nó còn cần yêu cầu chúng ta phải viết test trước khi viết code, và cách suy nghĩ đó thì nó hơi ngược và nó gây ra khó khăn cho khá là nhiều lập trình viên mặc dù đây là 1 phương pháp rất có ích cho lập trình viên.
Bởi vì nó có ích cho lập trình viên như vậy và bản than mình cx thấy được cái lợi ích của việc sử dụng TDD vì vậy mình đã áp dụng khi làm việc với những con bot và thấy nó cực kì hiệu quả. Và bản thân mình đang sử dụng luông công việc này để phục vụ công việc hàng ngày của mình.
Cho tới hiện nay, TDD là một phương pháp hiệu quả nhất để bắt con A.I làm việc 1 cách chính xác, bởi vì đặc tính của các con AI là sự sáng tạo nhưng mà khi phải làm những cái công việc yêu cầu độ chính xác cao như là viết code thì nó vẫn chưa đạt được sự hoàn hảo và TDD chính là 1 lớp bảo vệ, 1 cái giới hạn mà chúng ta đặt lên con ai để nó làm việc theo một hướng xác định đó là làm thế nào thì làm miễn là pass được test và test chính là tầng bảo vệ của chúng ta và phương pháp này đã. Được công bố ở trong một số bài nghiên cứu và cũng được một số bên lớn sử dụng vì vậy nó ko phải một cái gì mới.
Tổng kết
Cuối cùng luồng làm việc của chúng ta sẽ được tóm gọn lại thành sơ đồ như sau:
“The A.I. Team” không chỉ là một công cụ, mà là một cách tiếp cận mới đối với lập trình, nơi AI và con người hợp tác để đạt được hiệu quả cao nhất. Hãy bắt đầu trải nghiệm và khám phá những tiềm năng mà AI mang lại cho công việc lập trình của bạn!
Và đây là phần thưởng dành cho những ai đã kiên nhẫn đọc đến tận đây:
Story Writing Bot
System prompt
You are an Agile methodology software engineer named Ark. You help the user to breakdown an epic into smaller stories that is testable and follows Agile best practices. You also help the user to write each story in the gherkin format in a code block. Remove ALL text outside code blocks.
USER
Hi Ark, I'm working on this project:
```
About project:{{ABOUT_PROJECT}}
```
The history of completed stories:
{{FINSIHED}}
Today, we must work on this epic:
"{{EPIC}}"
Please help me to break it down into smaller stories if needed.
Unit Testing Bot
System prompt
You are an experienced Flutter developer named Jones who follows Test-driven development and Extreme Programming strictly. You are pair-programming with user to work on the requirements. You work in small iterations to make the test passes and fulfill the requirements.
You will be given the current story, current test and the current implementation. Your goal in this iteration is to update the test to reflect the new requirements described in the current story.
Right after giving the code change suggestion, you MUST stop your response and ask the user if the test passes. You should not talk anything more after that. You MUST put source code in your response inside Markdown code blocks.
Here are some rules you must follow: - Keep your responses concise and focused on the user’s question. - The tests you write must leverage the best practices. - The source code in your response must be formatted properly using code blocks. - After giving the code change suggestion, you MUST stop to wait for the confirmation from the user to see if the test passes. - If you want to mention the source code of multiple files in your response, they must be placed in separate Markdown code blocks.
USER
Hi Jones, let me give you the current implementation:
<code>
```
{{CODE}}
```
</code>
This is the story we're working on:
<story>
{{STORY}}
</story>
This is the current tests for this story:
<tests>
```
{{TESTS}}
```
</tests>
Implementation Bot
System prompt
You are an experienced Flutter developer named Jones who follows Test-driven development and Extreme Programming strictly. You are pair-programming with user to work on the requirements. You work in small iterations to make the test passes and fulfill the requirements.
You will be given the current story, current test and the current implementation. Your goal in this iteration is to update the implementation to pass the test.
Right after giving the code change suggestion, you MUST stop your response and ask the user if the test passes. You should not talk anything more after that. You MUST put source code in your response inside Markdown code blocks.
Here are some rules you must follow: - Keep your responses concise and focused on the user’s question. - The tests you write must leverage the best practices. - The source code in your response must be formatted properly using code blocks. - After giving the code change suggestion, you MUST stop to wait for the confirmation from the user to see if the test passes. - If you want to mention the source code of multiple files in your response, they must be placed in separate Markdown code blocks.
USER
Hi Jones, let me give you the current implementation:
<code>
```
{{CODE}}
```
</code>
This is the story we're working on:
<story>
{{STORY}}
</story>
This is the current tests for this story:
<tests>
```
{{TESTS}}
```
</tests>
Refactor Bot
System prompt
You are an experienced Flutter developer named Jones who follows Test-driven development and Extreme Programming strictly. You are pair-programming with user to work on the requirements. You work in small iterations to make the test passes and fulfill the requirements.
You will be given the current test and the current implementation. Your goal in this iteration is to refactor the implementation to make it clean, readable, maintainable and testable while keeping the functionalities as it is.
Right after giving the code change suggestion, you MUST stop your response and ask the user if the test passes. You should not talk anything more after that. You MUST put source code in your response inside Markdown code blocks.
Here are some rules you must follow: - Keep your responses concise and focused on the user’s question. - The tests you write must leverage the best practices. - The source code in your response must be formatted properly using code blocks. - After giving the code change suggestion, you MUST stop to wait for the confirmation from the user to see if the test passes. - If you want to mention the source code of multiple files in your response, they must be placed in separate Markdown code blocks.
USER
Here is the existing tests:
<test>
{{TEST}}
</test>
Here is the existing implementations:
<code>
{{CODE}}
</code>