Mục lục
Sự Trỗi Dậy Của AI Trong Lập Trình Và Vai Trò Mới Của Kỹ Sư
Trong kỷ nguyên số hóa hiện nay, Trí tuệ Nhân tạo (AI) đã và đang tạo ra những bước đột phá ngoạn mục, đặc biệt là trong lĩnh vực phát triển phần mềm. Các công cụ AI như Claude Code, GitHub Copilot không chỉ đơn thuần là trợ lý mà còn trực tiếp tham gia vào quá trình viết mã, giúp tăng tốc độ sản xuất code một cách chưa từng có. Từ việc tự động hoàn thành dòng mã, tạo ra các hàm phức tạp, cho đến việc viết toàn bộ thành phần dựa trên mô tả, AI đã chứng minh khả năng giảm đáng kể thời gian phát triển.
Tuy nhiên, liệu tốc độ có đồng nghĩa với chất lượng? Và liệu sự gia tăng này có làm giảm giá trị của các kỹ năng kỹ sư truyền thống? Kinh nghiệm thực tế từ các nhà phát triển hàng đầu cho thấy, mặc dù AI có thể đẩy nhanh quá trình viết mã, nhưng việc cho ra đời một phần mềm chất lượng cao, ổn định và đáng tin cậy vẫn yêu cầu những phán đoán, tư duy sâu sắc và kinh nghiệm vững vàng từ con người. Tốc độ mà không đi kèm với kỷ luật kỹ thuật chỉ đơn thuần là cách nhanh hơn để đưa lỗi vào hệ thống.
Bài viết này sẽ đi sâu phân tích vai trò không thể thay thế của kỹ sư phần mềm trong thời đại AI, đồng thời cung cấp các chiến lược và kỹ thuật để tối ưu hóa sự hợp tác giữa con người và AI nhằm đảm bảo chất lượng sản phẩm cuối cùng.
Bạn Là Chủ Sở Hữu Của Mã Nguồn, Chứ Không Phải AI
Hãy hình dung AI như một công cụ mạnh mẽ trong bộ công cụ của bạn, tương tự như một trình biên dịch (compiler), công cụ kiểm tra cú pháp (linter), hay hệ thống chạy kiểm thử (test runner). Nó là một phần mềm hỗ trợ, không phải là thực thể chịu trách nhiệm cuối cùng. Trong môi trường phát triển phần mềm, bạn – người kỹ sư – chính là chủ sở hữu thực sự của mã nguồn.
Khi một lỗi nghiêm trọng xảy ra trên môi trường production, không ai sẽ hỏi: “Con AI nào đã tạo ra đoạn mã này?”. Thay vào đó, câu hỏi luôn là: “Ai là người đã triển khai nó?”. Yêu cầu kéo (Pull Request – PR) mang tên bạn. Việc xem xét mã (code review) là trách nhiệm của bạn. Quyết định hợp nhất (merge) mã vào nhánh chính thuộc về bạn.
AI là một công cụ nhân rộng. Nếu kỹ năng kỹ thuật của bạn vững chắc, nó sẽ nhân lên hiệu quả công việc của bạn gấp nhiều lần. Nhưng ngược lại, nếu kỹ năng của bạn còn yếu kém, AI cũng có thể nhân rộng những điểm yếu đó, dẫn đến việc sản xuất ra nhiều mã kém chất lượng hơn một cách nhanh chóng. Trách nhiệm cuối cùng về chất lượng và sự ổn định của phần mềm luôn thuộc về kỹ sư, không phải công cụ.
Những Giới Hạn Của AI Mà Kỹ Nư Không Thể Thiếu
Mặc dù AI có thể viết mã nhanh chóng và hiệu quả, nhưng vẫn có những khía cạnh quan trọng mà khả năng tư duy và kinh nghiệm của con người là không thể thay thế. Các kỹ năng này là yếu tố cốt lõi để đảm bảo chất lượng và sự phù hợp của phần mềm với mục tiêu kinh doanh.
Tư Duy Về Các Trường Hợp Biên (Edge Cases)
AI thường được huấn luyện để xử lý “happy path” – những kịch bản hoạt động bình thường và phổ biến nhất. Tuy nhiên, phần mềm thực tế phải đối mặt với vô số trường hợp biên, các điều kiện bất thường hoặc dữ liệu không hợp lệ.
- Ví dụ: AI có thể dễ dàng tạo ra một hàm xử lý đầu vào số dương. Nhưng liệu nó có tự động nghĩ đến trường hợp đầu vào là số âm, số 0, chuỗi rỗng, giá trị null, hay tràn số?
- Vai trò của kỹ sư: Kỹ sư có khả năng phân tích, dự đoán và thiết kế các giải pháp để xử lý các trường hợp biên này một cách mạnh mẽ, đảm bảo ứng dụng không bị lỗi hoặc hoạt động sai lệch trong các tình huống không mong muốn.
Hiểu Biết Toàn Diện Hệ Thống (System Architecture)
AI có thể nhìn thấy một tập tin hoặc một đoạn mã cụ thể. Nó có thể tối ưu hóa từng phần nhỏ đó. Nhưng nó không có khả năng tự động nhìn thấy bức tranh toàn cảnh của kiến trúc hệ thống, mối quan hệ phức tạp giữa các microservices, database, API, và các thành phần khác.
- Ví dụ: AI có thể viết một module mới. Nhưng nó có biết module đó sẽ ảnh hưởng đến hiệu suất của một dịch vụ khác vốn đang chịu tải cao? Hoặc nó có phù hợp với chiến lược mở rộng của toàn bộ hệ thống?
- Vai trò của kỹ sư: Kỹ sư với kinh nghiệm về kiến trúc phần mềm, mô hình thiết kế và các nguyên tắc như SOLID, DRY, KISS mới có thể đưa ra quyết định về cấu trúc mã nguồn sao cho phù hợp với tầm nhìn dài hạn và khả năng bảo trì của toàn bộ hệ thống.
Đánh Đổi Và Ưu Tiên (Trade-offs) Trong Phát Triển
Việc phát triển phần mềm luôn đòi hỏi những sự đánh đổi: giữa tốc độ và chất lượng, giữa tính năng và hiệu suất, giữa phát triển mới và xử lý nợ kỹ thuật (tech debt). AI không có khả năng hiểu các ưu tiên kinh doanh, thời hạn dự án hay mức độ chấp nhận nợ kỹ thuật của nhóm.
- Ví dụ: AI có thể đề xuất một giải pháp “hoàn hảo” về mặt kỹ thuật, nhưng đòi hỏi thời gian phát triển gấp đôi so với một giải pháp “đủ tốt” đáp ứng thời hạn thị trường.
- Vai trò của kỹ sư: Kỹ sư là người cân bằng các yếu tố này, đưa ra quyết định tối ưu dựa trên ngữ cảnh dự án, mục tiêu kinh doanh và nguồn lực hiện có.
Ngữ Cảnh Của Nhóm Và Lịch Sử Dự Án (Team Context)
Bạn đã từng tham gia cuộc họp mà cả nhóm quyết định loại bỏ một dịch vụ cũ? Bạn nắm rõ các quy ước đặt tên (naming conventions) đặc trưng của dự án, các quyết định kiến trúc quan trọng, và những bài học xương máu từ các lần thử nghiệm thất bại trong quá khứ (“chúng tôi đã thử X nhưng không hiệu quả”). AI không hề có những thông tin quý giá này trừ khi bạn cung cấp cho nó một cách tường minh và đầy đủ.
- Vai trò của kỹ sư: Kỹ sư duy trì bộ nhớ tập thể của nhóm, đảm bảo rằng mã mới được tạo ra không đi ngược lại với các quyết định quan trọng trong quá khứ và phù hợp với văn hóa phát triển của đội ngũ.
Hướng Dẫn AI Bằng Kiểm Thử: Phương Pháp TDD Vượt Trội
Kiểm thử (testing) là một trụ cột không thể thiếu để đảm bảo chất lượng phần mềm. Khi kết hợp với AI, các phương pháp kiểm thử trở nên mạnh mẽ hơn bao giờ hết, đặc biệt là Phát triển Hướng Kiểm Thử (Test-Driven Development – TDD).
TDD: Đỏ – Xanh – Tái cấu trúc (Red-Green-Refactor)
TDD không chỉ là một kỹ thuật kiểm thử, mà còn là một quy trình thiết kế mã nguồn. Trong quy trình này, kỹ sư là người định nghĩa CÁI GÌ cần được kiểm thử và hành vi mong muốn, còn AI sẽ chịu trách nhiệm triển khai NHƯ THẾ NÀO để đáp ứng các kiểm thử đó.
1. Red (Đỏ): Viết các kiểm thử thất bại
Bạn bắt đầu bằng việc viết các kiểm thử thất bại (failing tests) bao gồm hành vi mong đợi và các trường hợp biên. Đây là bước mà kỹ sư định nghĩa hợp đồng của thành phần, các trường hợp sử dụng chính và các tình huống ngoại lệ. AI không thể làm điều này một cách hiệu quả nếu không có hướng dẫn từ con người.
describe('SearchFilter', () => {
it('renders input with placeholder', () => {
render(<SearchFilter onSearch={vi.fn()} />);
expect(screen.getByPlaceholderText('Tìm kiếm sản phẩm...')).toBeInTheDocument();
});
it('gọi onSearch sau khi người dùng ngừng gõ', async () => {
const onSearch = vi.fn();
render(<SearchFilter onSearch={onSearch} debounceMs={300} />);
await userEvent.type(screen.getByRole('searchbox'), 'giay');
expect(onSearch).not.toHaveBeenCalled();
await waitFor(() => expect(onSearch).toHaveBeenCalledWith('giay'));
});
it('không gọi onSearch cho input rỗng', async () => {
const onSearch = vi.fn();
render(<SearchFilter onSearch={onSearch} debounceMs={300} />);
await userEvent.type(screen.getByRole('searchbox'), 'a');
await userEvent.clear(screen.getByRole('searchbox'));
await waitFor(() => expect(onSearch).not.toHaveBeenCalled());
});
it('hiển thị spinner loading khi đang tìm kiếm', () => {
render(<SearchFilter onSearch={vi.fn()} isLoading />);
expect(screen.getByRole('status')).toBeInTheDocument();
});
it('cắt khoảng trắng trước khi gọi onSearch', async () => {
const onSearch = vi.fn();
render(<SearchFilter onSearch={onSearch} debounceMs={300} />);
await userEvent.type(screen.getByRole('searchbox'), ' giay ');
await waitFor(() => expect(onSearch).toHaveBeenCalledWith('giay'));
});
});
Bạn không viết bất kỳ dòng mã triển khai nào ở đây, nhưng bạn đã định nghĩa hợp đồng của thành phần, các trường hợp biên và hành vi của nó. Đó chính là tinh hoa của kỹ thuật.
2. Green (Xanh): AI triển khai mã tối thiểu
Sau khi có các kiểm thử thất bại, bạn yêu cầu AI triển khai đoạn mã tối thiểu cần thiết để tất cả các kiểm thử đó chuyển sang trạng thái “pass” (xanh). AI rất giỏi trong việc này, vì nó có thể nhanh chóng tạo ra nhiều biến thể mã cho đến khi tìm thấy giải pháp thỏa mãn các điều kiện kiểm thử.
3. Refactor (Tái cấu trúc): Kỹ sư hướng dẫn AI làm sạch
Mã do AI tạo ra có thể hoạt động đúng, nhưng chưa chắc đã tối ưu về cấu trúc, dễ đọc hoặc dễ bảo trì. Đây là lúc kỹ sư can thiệp để hướng dẫn AI tái cấu trúc:
- Trích xuất các hàm trợ giúp (helper functions).
- Áp dụng nguyên tắc trách nhiệm đơn nhất (Single Responsibility Principle).
- Đặt tên biến và hàm rõ ràng, dễ hiểu.
Mục tiêu cuối cùng là làm cho mã dễ dàng hơn cho kỹ sư tiếp theo (hoặc phiên AI tiếp theo) khi họ cần chỉnh sửa hoặc mở rộng.
Không có kỷ luật kiểm thử, AI sẽ cung cấp cho bạn mã chưa được kiểm thử mà “có vẻ đúng”. Với TDD, AI làm việc trong các ràng buộc mà bạn đã định nghĩa, đảm bảo chất lượng từ gốc.
Kiểm Thử Từ Đầu Đến Cuối (E2E Tests): Bảo Vệ Luồng Kinh Doanh Quan Trọng
Trong khi kiểm thử đơn vị (unit tests) giúp xác minh các thành phần nhỏ, kiểm thử từ đầu đến cuối (End-to-End – E2E tests) lại xác minh toàn bộ luồng làm việc của ứng dụng một cách mạch lạc.
AI có thể giúp tạo khung sườn cho các kiểm thử E2E, nhưng chính bạn là người phải xác định những luồng nào là quan trọng đối với doanh nghiệp. Đó có thể là một quy trình thanh toán (checkout flow), một chuỗi xác thực người dùng (authentication sequence), hoặc một quy trình xuất dữ liệu phức tạp. Đây là những quyết định đòi hỏi sự hiểu biết sâu sắc về nghiệp vụ kinh doanh, không chỉ đơn thuần là mã nguồn.
test('người dùng hoàn tất quy trình thanh toán', async ({ page }) => {
await page.goto('/san-pham');
await page.click('[data-testid="them-vao-gio-hang"]');
await page.click('[data-testid="thanh-toan"]');
await page.fill('#email', 'test@example.com');
await page.fill('#so-the', '4242424242424242'); // Số thẻ thử nghiệm
await page.click('[data-testid="dat-hang"]');
await expect(page.locator('.xac-nhan')).toBeVisible();
});
Bạn đã định nghĩa đường dẫn quan trọng. AI có thể điền các chi tiết, thêm các xác nhận (assertions), xử lý thiết lập/dọn dẹp (setup/teardown). Nhưng quyết định CÁI GÌ cần được kiểm thử E2E là của bạn. Điều tương tự cũng áp dụng cho các trường hợp biên: Điều gì xảy ra khi thanh toán thất bại? Khi phiên làm việc hết hạn giữa chừng quy trình thanh toán? Khi giỏ hàng trống? Bạn là người định nghĩa những kịch bản đó, và AI sẽ viết các xác nhận.
Thực Thi Tiêu Chuẩn Chất Lượng Trước Khi Mã Được Triển Khai
Các tiêu chuẩn chất lượng chỉ có ý nghĩa khi chúng được thực thi một cách nghiêm ngặt. Để đảm bảo chất lượng mã nguồn, đặc biệt khi AI tham gia vào quá trình viết mã, việc thiết lập các “rào chắn” (guardrails) tự động là cực kỳ quan trọng.
Quy Tắc Linting
Thiết lập các quy tắc linting tùy chỉnh để mã hóa các quy ước và tiêu chuẩn viết code của nhóm bạn. AI có thể tuân thủ các quy tắc này khi được cấu hình đúng cách, nhưng bạn cần biết những quy tắc nào là quan trọng và phù hợp với cơ sở mã của bạn. Ví dụ:
- Quy ước đặt tên biến (camelCase, PascalCase).
- Quy tắc về độ dài dòng mã.
- Yêu cầu sử dụng ES6 thay vì var.
Git Hooks
Sử dụng Git hooks, chẳng hạn như `pre-push` hooks, để tự động chạy linting và tất cả các kiểm thử trước khi mã được đẩy lên repository. Bất kỳ mã nào không vượt qua các kiểm tra này sẽ không được chấp nhận.
// Ví dụ về cấu hình husky cho pre-push hook
// .husky/pre-push
#!/bin/sh
. "$(dirname "$0")/_/husky.sh"
npm test
npm run lint
Không có ngoại lệ, ngay cả đối với mã do AI tạo ra. Điều này đảm bảo rằng mọi mã nguồn mới đều đáp ứng mức chất lượng tối thiểu trước khi đến giai đoạn xem xét mã.
AI Tool Hooks
Một số công cụ AI tiên tiến như Claude Code hỗ trợ các hook cho phép bạn chặn các hành động và thực thi các tiêu chuẩn một cách tự động. Bạn có thể cấu hình để chạy linter trước mỗi commit, hoặc chạy tất cả các kiểm thử trước mỗi push.
Việc này giúp AI hoạt động trong khuôn khổ các quy tắc và tiêu chuẩn mà bạn đã định nghĩa, biến nó thành một công cụ tuân thủ thay vì một nguồn tạo ra sự hỗn loạn. Công việc của kỹ sư là định nghĩa các rào chắn này, và AI sẽ làm việc trong giới hạn đó.
Tối Ưu Hóa Vòng Lặp Phản Hồi Với Công Cụ Xác Minh
Mọi thay đổi do AI tạo ra đều cần được xác minh. Nguyên tắc cốt lõi là: bạn càng phát hiện vấn đề nhanh chóng, AI càng có thể sửa chữa chúng nhanh hơn. Việc thiết lập các vòng lặp phản hồi hiệu quả là chìa khóa để tận dụng tối đa tiềm năng của AI trong quy trình phát triển.
Các Công Cụ Xác Minh Tích Hợp
Vòng lặp phản hồi xác minh tồn tại ở mọi cấp độ:
- CI/CD Pipelines: Tự động chạy các kiểm thử hồi quy trực quan (visual regression tests), kiểm tra sự thay đổi giao diện người dùng.
- Browser Automation: Chụp ảnh màn hình tự động để phát hiện lỗi hiển thị.
- Performance Audits: Các công cụ như Lighthouse tự động gắn cờ các vấn đề về hiệu suất hoặc khả năng tiếp cận (accessibility).
Nguyên tắc chung là: mỗi đầu ra của AI hoặc của hệ thống sẽ trở thành đầu vào cho lần lặp tiếp theo.
Phản Hồi Trực Tiếp Trong Phiên AI
Trong một quy trình làm việc tối ưu, bạn có thể đóng vòng lặp phản hồi trực tiếp trong phiên làm việc với AI:
- Ảnh chụp màn hình hiển thị bố cục bị hỏng? AI có thể sửa lỗi CSS ngay lập tức.
- Lỗi console do thiếu prop? AI bổ sung prop còn thiếu.
- Kiểm tra Lighthouse gắn cờ lỗi khả năng tiếp cận? AI thêm nhãn `aria-label` cần thiết.
- Tab Network hiển thị cuộc gọi API dư thừa? AI tái cấu trúc việc tìm nạp dữ liệu.
Điều này biến quá trình sử dụng AI từ “tạo ra và hy vọng” thành “tạo ra, xác minh, và lặp lại”. Kỹ sư nào thiết lập được vòng lặp này sẽ đạt được kết quả tốt hơn nhiều so với người chỉ đơn thuần đưa ra lệnh và triển khai.
Kỹ năng ở đây không phải là viết mã, mà là biết CÁI GÌ cần xác minh và LÀM THẾ NÀO để cung cấp thông tin phản hồi đó trở lại AI một cách hiệu quả.
Đánh Giá Mã Do AI Tạo Ra Như Một PR Của Kỹ Sư Junior
Mã nguồn do AI tạo ra có thể biên dịch, vượt qua các kiểm thử bạn đã viết, và nhìn chung có vẻ hợp lý. Nhưng điều đó không có nghĩa là nó đã tốt hoặc tối ưu. Vai trò của kỹ sư là phải thực hiện việc xem xét mã (code review) một cách cực kỳ cẩn thận, giống như bạn đang xem xét một PR của một kỹ sư mới vào nghề.
Những Điều Cần Tìm Kiếm Khi Review Mã AI
Hãy đọc từng dòng mã do AI tạo ra và tự hỏi:
- Phức tạp không cần thiết (Unnecessary complexity): AI thường “yêu thích” sự trừu tượng hóa. Mã này có thực sự cần một mẫu thiết kế (design pattern) phức tạp như Factory Pattern, hay một hàm đơn giản là đủ? Sự phức tạp không cần thiết làm tăng chi phí bảo trì và rủi ro lỗi.
- Lỗi nhỏ tinh vi (Subtle bugs): Lỗi lệch một đơn vị (off-by-one errors), thiếu kiểm tra null (missing null checks), điều kiện tranh chấp (race conditions). AI tạo ra mã “có vẻ đúng”, không phải mã “đúng một cách chứng minh được”.
- Lệch lạc khỏi các mẫu thiết kế chung (Deviations from patterns): Cơ sở mã của bạn có thể sử dụng một mẫu xử lý lỗi cụ thể. AI có thể tự động tạo ra một mẫu khác, gây ra sự thiếu nhất quán và khó hiểu cho những người bảo trì sau này.
- Lỗ hổng bảo mật (Security holes): Đầu vào không được làm sạch (unsanitized input), các bí mật bị lộ (exposed secrets), thiếu kiểm tra xác thực (missing auth checks). AI thường không có tư duy phòng thủ theo mặc định. Kỹ sư phải có trách nhiệm đảm bảo mã an toàn.
Kỹ năng đọc mã một cách có phê phán trở nên quan trọng hơn bao giờ hết khi người khác (hoặc một thứ gì đó) viết nó. Bạn không thể review những gì bạn không hiểu. Hãy đầu tư vào việc đọc mã nhiều như việc bạn viết mã.
Bình Luận Mã: Giải Thích “Tại Sao”, Không Phải “Làm Thế Nào”
AI có xu hướng bình luận mã quá nhiều. Nó thường giải thích những điều hiển nhiên mà mã nguồn đã tự nói lên:
// Lặp qua mảng và lọc các mục
const filtered = items.filter(item => item.active);
// Đặt trạng thái với các mục đã lọc
setItems(filtered);
Những bình luận như vậy chỉ làm tăng thêm “nhiễu” cho mã nguồn. Mã đã tự nói lên CÁCH nó hoạt động.
Bình luận tốt giải thích TẠI SAO một đoạn mã tồn tại, hoặc nó đại diện cho logic nghiệp vụ nào:
// Các mục đã lưu trữ được xử lý bởi một job hàng đêm, không hiển thị trên UI
const filtered = items.filter(item => item.active);
Trước khi viết bất kỳ bình luận nào, hãy tự hỏi: Mã có thể tự giải thích được không? Một hàm hoặc biến được đặt tên tốt thường loại bỏ hoàn toàn nhu cầu về bình luận. Bình luận chỉ nên tồn tại khi mã không thể tự kể toàn bộ câu chuyện của nó.
Đó chính là sự khác biệt giữa “tiếng ồn” do AI tạo ra và “phán đoán kỹ thuật” của con người.
Chia Nhỏ Mã Thành Các Phần Nhỏ Hơn Để Kỹ Sư Tiếp Theo Dễ Dàng Bảo Trì
AI có khả năng tạo ra 500 dòng mã chỉ trong vài giây. Tuy nhiên, công việc của bạn là phải chia nhỏ những khối mã lớn đó thành các phần có thể xem xét và dễ hiểu. Đây là một phán đoán của con người mà AI khó có thể thực hiện một cách tối ưu.
Nguyên Tắc Chia Nhỏ Mã
- Trích xuất hàm (Extract functions): Chia nhỏ các khối logic lớn thành các hàm nhỏ hơn, tập trung vào một nhiệm vụ cụ thể.
- Áp dụng nguyên tắc trách nhiệm đơn nhất (Single Responsibility Principle): Đảm bảo mỗi hàm, mỗi lớp chỉ có một lý do để thay đổi.
- Đặt tên rõ ràng: Đặt tên biến, hàm, lớp một cách minh bạch, phản ánh đúng mục đích và chức năng của chúng.
Kỹ sư tiếp theo (hoặc phiên AI tiếp theo) khi tiếp xúc với mã này sẽ được hưởng lợi rất nhiều từ một cấu trúc sạch sẽ và dễ hiểu.
AI tối ưu cho prompt hiện tại của bạn. Bạn tối ưu cho vòng đời của toàn bộ dự án. Một hàm làm tốt một việc sẽ dễ kiểm thử, dễ tái sử dụng và dễ thay thế hơn nhiều so với một khối mã khổng lồ “hoạt động”.
Các Pull Request (PR) nhỏ luôn tốt hơn các PR lớn, ngay cả khi AI là người viết chúng. Điều này giúp quá trình review code nhanh chóng, giảm thiểu lỗi và cải thiện khả năng bảo trì tổng thể của cơ sở mã.
Kết Luận: Nắm Vững Tương Lai Phát Triển Phần Mềm Với AI
Sự xuất hiện và phát triển mạnh mẽ của Trí tuệ Nhân tạo trong lập trình không hề làm cho các kỹ năng kỹ sư trở nên lỗi thời hay không cần thiết. Ngược lại, nó đã biến chúng thành yếu tố then chốt, là điểm khác biệt quyết định giữa một sản phẩm phần mềm nhanh chóng nhưng đầy lỗi và một sản phẩm chất lượng cao, bền vững.
Những Bài Học Chính Cần Nắm Vững:
- Bạn là chủ sở hữu của mã nguồn: AI là một công cụ hỗ trợ mạnh mẽ, không phải là một cái cớ để thoái thác trách nhiệm. PR mang tên bạn, và chất lượng là trách nhiệm của bạn.
- TDD là kim chỉ nam cho AI: Viết các kiểm thử thất bại trước, để AI triển khai, sau đó bạn tái cấu trúc. Đây là cách tốt nhất để định hướng AI tạo ra mã đúng hành vi.
- Kiểm thử E2E bổ sung cho kiểm thử đơn vị: Xác định các luồng kinh doanh quan trọng và các trường hợp biên để đảm bảo toàn bộ hệ thống hoạt động chính xác.
- Thực thi tiêu chuẩn bằng linting và hooks: Xây dựng “rào chắn” chất lượng tự động trước khi mã được triển khai.
- Đóng vòng lặp phản hồi: Tận dụng các công cụ xác minh như ảnh chụp màn hình, lỗi console, và các báo cáo kiểm toán hiệu suất để cung cấp phản hồi nhanh chóng cho AI, giúp nó lặp lại và cải thiện.
- Đánh giá mã AI như PR của kỹ sư junior: Đọc kỹ từng dòng, đặt câu hỏi về sự phức tạp, lỗi tiềm ẩn, sai lệch pattern và lỗ hổng bảo mật.
- Bình luận giải thích “tại sao”, không phải “làm thế nào”: Cung cấp ngữ cảnh nghiệp vụ quan trọng thay vì chỉ mô tả lại những gì mã đã làm.
- Chia nhỏ mã thành các phần nhỏ: Biến các khối mã lớn do AI tạo ra thành các đơn vị dễ hiểu, dễ review và dễ bảo trì.
AI là một công cụ. Một công cụ vô cùng mạnh mẽ. Nhưng các công cụ không tự triển khai phần mềm, các kỹ sư mới là người làm điều đó. Hãy tiếp tục nghiên cứu các nguyên tắc cơ bản, thành thạo kiểm thử, hiểu rõ kiến trúc hệ thống và định nghĩa các tiêu chuẩn của bạn. Sau đó, hãy sử dụng AI để thực thi công việc với tốc độ mà bạn không thể đạt được một mình.
Viết mã là công việc của AI. Nhưng chất lượng phần mềm, mãi mãi là trách nhiệm và niềm tự hào của bạn.
