- Trợ lý lập trình AI đã trở thành công cụ cốt lõi của phát triển thực chiến trong suốt năm 2025, và để tận dụng hiệu quả thì quy trình làm việc có cấu trúc cùng sự can thiệp có trách nhiệm của con người là điều bắt buộc
- Thay vì yêu cầu tạo mã ngay lập tức, việc xác lập spec và kế hoạch rõ ràng trước, rồi triển khai từng bước dựa trên đó, sẽ đồng thời nâng cao chất lượng và năng suất
- Càng chia nhỏ công việc thành các đơn vị nhỏ và cung cấp đầy đủ ngữ cảnh cùng ràng buộc, càng có thể giảm đáng kể lỗi và vấn đề thiếu nhất quán của LLM
- Thay vì phụ thuộc vào một mô hình duy nhất, xu hướng đang lan rộng là chọn nhiều LLM và công cụ phù hợp với từng mục đích, đồng thời sử dụng AI như công cụ hỗ trợ xuyên suốt toàn bộ vòng đời phát triển
- Cuối cùng, khi con người duy trì quyền kiểm soát thông qua kiểm thử, review, quản lý phiên bản, AI sẽ hoạt động như một bộ khuếch đại năng suất mạnh mẽ
Tổng quan
- Trong suốt năm 2025, trợ lý lập trình AI đã bắt đầu được sử dụng ở quy mô lớn để viết mã cho sản phẩm thực tế
- Các kỹ sư Anthropic đã tích cực áp dụng Claude Code, đến mức hiện tại khoảng 90% mã của Claude Code được chính Claude Code viết ra
- Việc sử dụng LLM cho lập trình không phải là phép màu chỉ với một cú nhấn nút, mà đòi hỏi học các mẫu làm việc mới và tư duy phản biện
- Hãy tận dụng AI một cách chủ động, nhưng trách nhiệm đối với phần mềm được tạo ra vẫn thuộc về chính lập trình viên
- Cốt lõi là xem LLM không phải như một thực thể tự đưa ra phán đoán, mà là một pair programmer mạnh mẽ cần định hướng rõ ràng, ngữ cảnh và giám sát
Bắt đầu với kế hoạch rõ ràng (spec trước, code sau)
- Đừng đưa ra những yêu cầu mơ hồ cho LLM; hãy bắt đầu từ định nghĩa vấn đề và kế hoạch giải pháp
- Với dự án mới, hãy mô tả ý tưởng và yêu cầu LLM đặt câu hỏi lặp lại để làm rõ yêu cầu và các edge case
- Cuối cùng, tổng hợp thành spec.md bao gồm yêu cầu, quyết định kiến trúc, mô hình dữ liệu và chiến lược kiểm thử
- Đưa spec vào mô hình có khả năng suy luận để tạo kế hoạch dự án chia việc triển khai thành các tác vụ logic và nhỏ
- Theo cách diễn đạt của Les Orchard, việc trải qua giai đoạn lập kế hoạch nhanh nhưng có cấu trúc kiểu "waterfall trong 15 phút" sẽ giúp quá trình code sau đó trơn tru hơn nhiều
- Khi có spec và kế hoạch rõ ràng, cả con người lẫn LLM đều hiểu chính xác mình đang xây cái gì và vì sao, từ đó tránh làm lại và lãng phí chu kỳ làm việc
Chia công việc thành các chunk nhỏ và lặp lại
- Đừng yêu cầu LLM tạo ra một đầu ra khổng lồ trong một lần; hãy chia dự án thành các bước hoặc ticket có thể lặp lại để xử lý tuần tự
- Ví dụ: dùng prompt ở mức như “triển khai Step 1 của kế hoạch”, sau khi code xong thì kiểm thử rồi mới chuyển sang Step 2
- Nếu giao phạm vi quá lớn trong một lần, mô hình sẽ dễ rối hoặc tạo ra kết quả lộn xộn, khiến chi phí khắc phục tăng vọt
- Khi để nó tạo nguyên cả khối lớn của ứng dụng, sự nhất quán bị sụp đổ và mã trùng lặp chồng chất, thậm chí có nhận xét rằng “trông như 10 người làm mà không hề trao đổi với nhau”
- Ở mỗi vòng lặp, hãy kế thừa ngữ cảnh đã xây dựng và bổ sung dần dần; cách này cũng rất hợp với phương pháp TDD (phát triển hướng kiểm thử)
- Một số công cụ coding agent hỗ trợ rõ ràng quy trình chunk này, cho phép tạo file prompt plan để chạy tuần tự
Cung cấp ngữ cảnh và hướng dẫn rộng rãi
- LLM chỉ phát huy tốt trong phạm vi ngữ cảnh được cung cấp, vì vậy cần đưa vào đầy đủ mã liên quan, tài liệu và các điều kiện ràng buộc
- Claude ở chế độ Projects có thể nạp toàn bộ repo GitHub vào ngữ cảnh, còn các trợ lý IDE như Cursor và Copilot thì tự động bao gồm các file đang mở
- Cách làm kiểu brain dump để truyền trước mọi thông tin mô hình cần biết là rất hiệu quả, bao gồm cả mục tiêu cấp cao, ví dụ về lời giải mong muốn và những cách tiếp cận cần tránh
- Có thể dùng các công cụ như gitingest hoặc repo2txt để dump phần cần thiết của codebase thành file văn bản rồi cung cấp cho LLM
- Claude Skills là cách tiếp cận vượt lên trên việc phụ thuộc vào prompt lặp đi lặp lại, bằng cách đóng gói chỉ dẫn, script và chuyên môn miền thành các mô-đun bền vững và có thể tái sử dụng
- Cũng có bộ sưu tập Skills được cộng đồng tuyển chọn
- Skill frontend-design thậm chí còn có thể chỉnh lại thẩm mỹ thiết kế thiên tím thường thấy ở các UI do LLM tạo ra
- Việc chèn trực tiếp comment và quy tắc vào prompt để hướng dẫn AI mang lại hiệu quả lớn
- Ví dụ: “Đây là phần triển khai hiện tại của X. Hãy mở rộng nó thành Y nhưng không được làm hỏng Z”
- LLM có đặc tính làm theo chỉ dẫn một cách rất literal, nên chỉ dẫn càng chi tiết và ngữ cảnh càng rõ ràng thì càng giảm được ảo giác và các đề xuất lệch hướng
Chọn mô hình phù hợp (khi cần thì dùng nhiều mô hình)
- Không phải mọi LLM dùng cho lập trình đều ở cùng một mức, nên việc chủ đích chọn mô hình hoặc dịch vụ phù hợp với tính chất tác vụ là rất quan trọng
- Trong một số trường hợp, sử dụng song song từ hai LLM trở lên để đối chiếu chéo các cách tiếp cận khác nhau cho cùng một vấn đề sẽ rất hiệu quả
- Mỗi mô hình có thiên hướng và điểm mạnh riêng, vì vậy khi một mô hình bị bí hoặc chỉ cho kết quả tầm thường, cần biết lúc nào nên chuyển sang mô hình khác
- Có thể tránh điểm mù của một mô hình cụ thể bằng cách thử nguyên prompt đó trên dịch vụ khác theo kiểu “model musical chair”
- Nếu có thể, nên dùng các mô hình pro tier mới nhất vì chúng mang lại lợi thế rõ rệt về chất lượng
- Khi hợp tác trong thời gian dài, “vibe” của AI pair programmer — tức giọng điệu phản hồi và cảm giác tương tác có hợp với mình hay không — cũng là một tiêu chí chọn lựa quan trọng
Sử dụng AI coding trên toàn bộ vòng đời phát triển
- Trong môi trường dòng lệnh, các agent AI như Claude Code, OpenAI Codex CLI, Google Gemini CLI đã xuất hiện, có thể đọc file, chạy test và thực hiện các chỉnh sửa nhiều bước ngay trong thư mục dự án
- Jules của Google và Copilot Agent của GitHub được dùng như coding agent bất đồng bộ, sao chép repo vào cloud VM để làm việc rồi mở PR
- Những công cụ này vẫn chưa hoàn hảo, và việc sử dụng chúng trong khi hiểu rõ giới hạn là điều bắt buộc
- Chúng tăng tốc mạnh ở các tác vụ mang tính cơ học như tạo boilerplate, áp dụng thay đổi lặp lại, chạy test tự động, nhưng chất lượng vẫn phụ thuộc vào mức độ hướng dẫn của con người
- Khi dùng agent, việc cung cấp sẵn kế hoạch hoặc danh sách việc cần làm ngay từ đầu sẽ giúp chúng nhận diện đúng thứ tự công việc
- AI agent vẫn chưa ở giai đoạn có thể tự triển khai trọn vẹn cả một tính năng và cho ra kết quả hoàn hảo mà không cần người giám sát; cách tiếp cận thực tế vẫn là dùng dưới dạng có giám sát
- Các thử nghiệm đang diễn ra với công cụ điều phối như Conductor, nơi nhiều agent được chạy song song để xử lý đồng thời các tính năng khác nhau
Duy trì human-in-the-loop - xác minh, kiểm thử, review kỹ lưỡng
- AI có thể không ngần ngại tạo ra những đoạn code trông rất thuyết phục, nhưng trách nhiệm về chất lượng và kết quả hoàn toàn thuộc về lập trình viên
- Như cách Simon Willison diễn đạt, cần xem LLM pair programmer là một thực thể quá tự tin và dễ mắc sai lầm, vì nó vẫn có thể viết bug hoặc code vô nghĩa với sự chắc chắn tuyệt đối
- Các đoạn code do AI tạo ra nên được đối xử như code của một lập trình viên junior: tự đọc, tự chạy và kiểm thử khi cần
- Hãy đưa kiểm thử vào workflow một cách tự nhiên, đồng thời thiết kế danh sách test và kế hoạch kiểm thử cho từng giai đoạn ngay từ bước lập kế hoạch
- Với các công cụ như Claude Code, hãy chỉ thị rõ ràng việc chạy test suite sau khi hoàn thành task, và nếu fail thì tiếp tục phân tích nguyên nhân rồi sửa
- Những đội ngũ và cá nhân tận dụng coding agent tốt nhất thường là những người có văn hóa kiểm thử vững chắc
- Trong môi trường không có test, agent rất dễ cho rằng không có vấn đề gì dù trên thực tế đã làm hỏng nhiều phần của hệ thống
- Ngoài kiểm thử tự động, hãy giữ code review như một bước bắt buộc, kết hợp review thủ công với review bằng AI
- Có thể dùng một phiên AI riêng hoặc một model khác để yêu cầu nó phê bình hay review đoạn code do AI đầu tiên viết ra
- Ví dụ: sau khi Claude viết code, nhờ Gemini kiểm tra lỗi hoặc khả năng cải thiện của hàm đó
- Dùng Chrome DevTools MCP như công cụ cốt lõi cho vòng lặp debug và đảm bảo chất lượng, giúp lấp khoảng cách giữa phân tích tĩnh và việc chạy thực tế trên trình duyệt
- Cấp quyền để AI agent trực tiếp quan sát cấu trúc DOM, performance trace, console log và network request
- Có thể thực hiện kiểm thử UI tự động dựa trên LLM mà không cần thủ công chuyển ngữ cảnh qua lại
- Từ dữ liệu runtime thực tế, có thể chẩn đoán và sửa lỗi một cách chính xác
- Một lập trình viên cho biết kết quả của việc quá phụ thuộc vào nội dung AI sinh ra trong một dự án gấp rút là một mớ hỗn độn thiếu nhất quán
- Logic trùng lặp, tên method không đồng nhất và kiến trúc không được tích hợp cứ tích tụ dần
- Họ tự nhìn lại rằng mình chỉ liên tục tạo thêm mà không lùi lại một bước để kiểm tra toàn bộ cấu trúc do AI chắp nối
- Cuối cùng đi đến kết luận rằng phải đại tu bằng một đợt refactor lớn và sẽ không bao giờ giao phó trong trạng thái không giám sát nữa
- Bất kể dùng AI nhiều đến đâu, lập trình viên vẫn phải là kỹ sư chịu trách nhiệm đến cùng
- Trong thực tế, chỉ merge hoặc deploy sau khi đã hiểu code; nếu AI đưa ra phần triển khai quá phức tạp thì hãy yêu cầu thêm comment giải thích hoặc viết lại theo cách đơn giản hơn
Commit thường xuyên và dùng quản lý phiên bản như lưới an toàn
- Càng làm việc với AI có khả năng tạo ra lượng lớn code rất nhanh, càng cần thói quen quản lý phiên bản chặt chẽ hơn
- Mỗi khi hoàn thành một task nhỏ hoặc một lần sửa tự động thành công, hãy git commit với thông điệp rõ nghĩa để có checkpoint quay lại ngay nếu thay đổi tiếp theo gây ra sự cố
- Hãy xem commit như save point trong game để khi phiên làm việc với LLM đi chệch hướng, bạn luôn có thể quay về trạng thái ổn định gần nhất
- Quản lý phiên bản cũng giữ vai trò quan trọng trong cộng tác với AI; khi cửa sổ ngữ cảnh có giới hạn khiến nó không thể nhớ mọi thay đổi, git history sẽ trở thành nhật ký công việc đáng tin cậy
- Có thể lướt qua các commit gần đây để nhanh chóng briefing thay đổi cho AI hoặc cho chính mình
- Nếu đưa git diff hoặc commit log vào prompt, LLM sẽ nắm được chính xác code mới và trạng thái trước đó
- LLM rất giỏi đọc diff và dùng các công cụ như git bisect, nên có thể bám theo commit history để kiên trì truy ra điểm bug được đưa vào
- Các commit nhỏ và thông điệp rõ ràng sẽ ghi lại quá trình phát triển một cách tự nhiên, rất hữu ích cho code review
- Ngay cả khi AI agent thực hiện nhiều thay đổi cùng lúc, nếu các thay đổi được tách theo từng commit thì sẽ dễ xác định chính xác điểm gây ra vấn đề
- Dùng branch hoặc worktree để cô lập các thử nghiệm AI khỏi code chính
- Theo cách lấy cảm hứng từ Jesse Vincent, hãy tạo fresh git worktree cho từng tính năng mới hoặc subproject
- Có thể chạy song song nhiều phiên AI coding trên cùng một repo mà không gây nhiễu lẫn nhau, rồi chọn lọc kết quả để merge
- Mỗi task AI giống như nằm trong sandbox branch riêng, nên có thể bỏ hẳn các thử nghiệm thất bại mà không ảnh hưởng tới main
- Giữ nguyên tắc tuyệt đối không commit code mà bạn không hiểu hoặc không thể giải thích
Tùy biến hành vi AI bằng quy tắc và ví dụ
- Đừng chấp nhận nguyên xi phong cách hay cách tiếp cận mặc định của AI; chỉ cần đưa ra guideline rõ ràng cũng đã tác động lớn đến chất lượng và độ nhất quán của đầu ra
- Hãy duy trì định kỳ file CLAUDE.md để ghi rõ các quy tắc quy trình và sở thích mà Claude phải tuân theo, và khi dùng Gemini CLI cũng áp dụng tương tự với GEMINI.md
- Ví dụ: viết code theo style của dự án, tuân thủ quy tắc lint, cấm dùng một số hàm nhất định, ưu tiên phong cách hàm hơn OOP, v.v.
- Khi bắt đầu phiên làm việc, cung cấp file đó cho Claude để toàn bộ công việc bám theo các quy ước đã định
- Theo Jesse Vincent, cách tiếp cận này giúp giảm tần suất AI lệch sang hướng không mong muốn hoặc đưa vào các pattern lạ
- Ngay cả khi không có file quy tắc riêng, vẫn có thể thiết lập tone và hành vi tổng thể bằng custom instructions hoặc system prompt
- Cả GitHub Copilot và Cursor đều cung cấp chức năng cấu hình hành vi AI ở cấp độ toàn dự án
- Có thể mô tả ngắn gọn coding style bằng một đoạn ngắn: “Dùng thụt lề 4 khoảng trắng, tránh arrow function trong React, dùng tên biến mang tính mô tả, code phải pass ESLint”
- Ben Congdon nói rằng ông ngạc nhiên vì tính năng custom instructions của Copilot gần như không được sử dụng, và chỉ ra rằng chỉ cần đưa trước vài ví dụ cùng sở thích là đã có thể khiến code đầu ra phù hợp với cách viết quen dùng của cả đội
- Cung cấp ví dụ inline là một kỹ thuật đặc biệt mạnh
- Nếu muốn một hàm được triển khai theo cách cụ thể, hãy cho nó xem trước một hàm tương tự đã có sẵn trong codebase rồi hướng dẫn “X được triển khai như thế này, vậy Y cũng hãy dùng cùng cách tiếp cận”
- Nếu muốn đồng bộ phong cách comment, hãy tự viết trước một dòng rồi yêu cầu nó tiếp tục theo đúng phong cách đó
- Về bản chất, đây là cách priming model bằng các pattern cần noi theo, và LLM đặc biệt mạnh ở kiểu bắt chước này
- Trong cộng đồng, nhiều rule set khác nhau để tinh chỉnh hành vi LLM đang được chia sẻ rộng rãi
- Chẳng hạn quy tắc "Big Daddy" hoặc cách thêm điều khoản “cấm hallucination và lừa dối” vào prompt
- Đây là những biện pháp nhằm giảm hành vi AI bịa ra code không tồn tại hoặc tỏ ra chắc chắn quá mức
- Ví dụ: thêm vào đầu prompt câu “Nếu không chắc chắn hoặc thiếu ngữ cảnh từ codebase, đừng bịa câu trả lời mà hãy yêu cầu làm rõ” để giảm hallucination
- Một quy tắc khác như “Khi sửa bug, luôn giải thích ngắn gọn lý do bằng comment” sẽ khiến AI để lại các comment dạng “// Fixed: changed X to Y to prevent Z according to the spec” cùng với phần sửa đổi
Đón nhận kiểm thử và tự động hóa như một bộ khuếch đại sức mạnh
- Càng tận dụng mạnh mẽ CI/CD, linter và bot review code, AI càng hoạt động tốt nhất trong môi trường tự động lọc lỗi
- Repository có tỷ trọng code do AI viết càng lớn thì môi trường tích hợp liên tục vững chắc càng trở nên thiết yếu
- Tự động chạy test cho mọi commit hoặc PR, bắt buộc kiểm tra style code như ESLint·Prettier, và nếu có thể thì bao gồm cả triển khai staging theo từng nhánh
- Có thể thiết lập để AI trực tiếp kích hoạt các bước này và đánh giá kết quả
- Ví dụ: khi Jules hoặc GitHub Copilot Agent mở PR, CI chạy test và báo lỗi → chuyển log lỗi cho AI để nối tiếp thành “bài kiểm thử tích hợp đã thất bại ở XYZ, hãy cùng debug”
- Quá trình sửa bug được chuyển thành một vòng lặp cộng tác với phản hồi nhanh, và AI đặc biệt xử lý tốt kiểu này
- Kiểm tra chất lượng code tự động cũng đóng vai trò như bánh lái cho AI
- Đưa nguyên văn đầu ra của linter vào prompt; nếu AI viết ra code bị lint báo lỗi thì chỉ cần sao chép thông báo lỗi và yêu cầu “hãy sửa những vấn đề này”
- Hiệu ứng giống như có một người thầy nghiêm khắc luôn đứng sau vai AI quan sát
- Khi nhận biết đầu ra từ công cụ như test thất bại hoặc cảnh báo từ linter, AI sẽ kiên trì thử sửa
- Bản thân các AI coding agent cũng ngày càng tích hợp hook tự động hóa
- Một số agent thậm chí không công nhận công việc là “hoàn thành” cho đến khi tất cả test đều vượt qua
- Bot review code, dù là AI hay con người, cũng có thể được dùng như một lớp lọc bổ sung
- Có thể dùng nguyên bình luận review làm prompt để cải thiện
- Ví dụ: nếu CodeRabbit hoặc một reviewer khác để lại nhận xét “hàm này đang làm X nhưng không lý tưởng”, có thể yêu cầu AI “hãy refactor để phản ánh phản hồi này”
- Khi kết hợp AI và tự động hóa, một vòng tuần hoàn tích cực sẽ hình thành
- AI viết code → công cụ tự động hóa phát hiện vấn đề → AI sửa → lặp lại, còn lập trình viên chỉ giám sát định hướng ở cấp cao
- Cảm giác như công việc của một junior developer cực kỳ nhanh được một QA engineer không biết mệt xác minh ngay lập tức
- Tuy nhiên, môi trường này phải do chính lập trình viên xây dựng, và trong các dự án không có test hay tự động hóa, bug tinh vi hoặc suy giảm chất lượng do AI gây ra có thể chỉ lộ diện rất lâu sau đó
- Một trong những mục tiêu hướng tới năm 2026 là siết chặt các cổng kiểm soát chất lượng xung quanh phần đóng góp code của AI
- Nhiều test hơn, nhiều giám sát hơn, và nếu cần thì cả cấu trúc AI review AI
- Đã có những trường hợp được quan sát thực tế, khi vấn đề mà một model bỏ sót lại được model khác phát hiện
Học hỏi và thích nghi liên tục (AI khuếch đại kỹ năng)
- Nếu coi mọi phiên lập trình cùng AI là một cơ hội học hỏi, sẽ hình thành một vòng tuần hoàn tích cực trong đó kiến thức càng tăng thì AI càng hỗ trợ tốt hơn
- Khi dùng LLM trong phát triển phần mềm, bạn tự nhiên được tiếp xúc với ngôn ngữ, framework và kỹ thuật mới mà bình thường có thể đã không thử
- Khi có nền tảng software engineering vững chắc, AI có thể khuếch đại năng suất lên nhiều lần, nhưng nếu nền tảng yếu thì sự hỗn loạn cũng bị khuếch đại theo
- Một quan sát chung từ các lập trình viên giàu kinh nghiệm là LLM có xu hướng củng cố các best practice sẵn có
- Viết spec rõ ràng, có test đầy đủ và review code đều đặn sẽ phát huy hiệu quả còn lớn hơn khi AI tham gia
- Trong khi AI xử lý phần boilerplate, lập trình viên có thể tập trung vào các tầng trừu tượng cấp cao như thiết kế, giao diện và kiến trúc, nhưng để làm được điều đó thì năng lực tương ứng phải có sẵn từ trước
- Như Simon Willison đã chỉ ra, gần như mọi yếu tố tạo nên một senior engineer—thiết kế hệ thống, quản lý độ phức tạp, phán đoán giữa tự động hóa và làm thủ công—giờ đây đều dẫn đến kết quả tốt nhất khi kết hợp với AI
- Việc tận dụng AI trên thực tế còn thúc đẩy sự cải thiện năng lực kỹ thuật
- Trở nên nghiêm ngặt hơn ở giai đoạn lập kế hoạch và suy nghĩ có chủ đích hơn về kiến trúc
- Đảm nhận vai trò quản lý một AI coder rất nhanh nhưng đôi khi ngây thơ, từ đó rèn luyện khả năng phán đoán
- Trước lo ngại rằng AI có thể làm suy giảm năng lực, nếu dùng đúng cách thì kết quả thực ra lại ngược lại
- Học được các thành ngữ lập trình và cách giải quyết mới thông qua review code do AI tạo ra
- Đào sâu hiểu biết về ngôn ngữ và miền bài toán bằng cách debug lỗi của AI
- Yêu cầu AI giải thích code hoặc lý do sửa đổi, liên tục đặt câu hỏi như đang phỏng vấn ứng viên để rút ra insight
- Khi chưa rõ về thư viện hoặc cách tiếp cận, dùng AI như một trợ lý nghiên cứu để so sánh các lựa chọn và trade-off
- Ở bức tranh lớn hơn, công cụ AI khuếch đại chuyên môn
- Khi tiến tới năm 2026, thay vì lo sợ bị cướp mất việc, có nhiều kỳ vọng hơn rằng con người sẽ thoát khỏi công việc lặp lại, đơn điệu để dành nhiều thời gian hơn cho các vấn đề sáng tạo và phức tạp
- Ngược lại, nếu không có nền tảng vững, AI cũng có thể dẫn đến một phiên bản hiệu ứng Dunning-Kruger được tiêm steroid
- Lời khuyên là cần một sự cân bằng có chủ đích: tiếp tục mài giũa kỹ năng trong khi dùng AI để tăng tốc học tập và năng suất, đồng thời định kỳ lập trình không có AI để giữ nền tảng cơ bản luôn sắc bén
- Cuối cùng, sự kết hợp giữa lập trình viên và AI mạnh hơn rất nhiều so với khi chỉ có một bên, và ở trong sự kết hợp đó, phía con người phải thực hiện đầy đủ vai trò của mình
Kết luận
- AI đã được đưa vào toàn bộ workflow phát triển một cách tích cực, nhưng vẫn giữ cách làm thận trọng và do chuyên gia dẫn dắt
- Cách tiếp cận được hướng đến không phải là phát triển để AI tự động hóa mọi thứ, mà là “software engineering được AI tăng cường”
- Kết quả tốt nhất xuất hiện khi áp dụng nguyên vẹn kỷ luật software engineering cổ điển vào việc cộng tác với AI
- Tất cả những thực hành được xây dựng công phu như thiết kế rồi mới code, viết test, quản lý phiên bản, duy trì tiêu chuẩn code vẫn hoàn toàn còn giá trị, và trong bối cảnh AI viết ra một nửa lượng code thì chúng thậm chí còn quan trọng hơn
- Công cụ sẽ tiếp tục phát triển, và workflow cũng được dự báo sẽ tiến hóa cùng với chúng
- Những “AI thực tập sinh phát triển phần mềm” hoàn toàn tự chủ sẽ đảm nhận nhiều việc đơn giản hơn, còn con người tập trung vào các vấn đề cấp cao
- Có thể sẽ xuất hiện những phương thức debug và các mô hình khám phá code mới
- Dù thay đổi thế nào, vẫn cần luôn ở trong vòng lặp
- Hướng dẫn AI, xác minh kết quả, học hỏi trong quá trình đó và mở rộng năng suất một cách có trách nhiệm
- Kết luận cuối cùng rất rõ ràng: AI coding assistant là một bộ khuếch đại mạnh mẽ, nhưng đạo diễn của sân khấu đến cuối cùng vẫn là kỹ sư con người
1 bình luận
Có vẻ như khi mức độ trừu tượng hóa càng cao thì kỹ thuật càng trở nên quan trọng.