- Tóm tắt trải nghiệm 6 tuần số lượng commit tăng vọt nhờ cải thiện hạ tầng phát triển như tự động hóa các tác vụ lặp đi lặp lại đơn giản của AI agent, loại bỏ thời gian chờ build và xây dựng hệ thống worktree song song
- Tự động hóa quy trình tạo PR bằng skill
/git-pr để loại bỏ chi phí chuyển ngữ cảnh, đồng thời agent trực tiếp viết phần mô tả PR chi tiết hơn
- Chuyển công cụ build sang SWC để rút ngắn thời gian khởi động lại server xuống dưới 1 giây, tạo ra môi trường phát triển không bị đứt mạch
- Dùng tính năng preview của Claude Code để agent tự kiểm chứng UI, giải quyết điểm nghẽn khi lập trình viên phải tự mình kiểm tra mọi thay đổi
- Khi lần lượt loại bỏ từng yếu tố gây ma sát, mô hình Theory of Constraints nơi điểm nghẽn tiếp theo lộ ra được áp dụng nguyên vẹn
- Giờ đây, thay vì triển khai tính năng, trọng tâm là xây dựng hạ tầng để agent làm việc hiệu quả và tăng tốc độ vòng lặp
Tự động hóa các tác vụ lặp đi lặp lại đơn giản
- Ban đầu, toàn bộ quy trình từ stage thay đổi, viết commit message, viết mô tả PR, push, đến tạo GitHub PR đều được thực hiện thủ công
- Việc nhận ra đây là công việc lặp lại đơn thuần (grunt work) là bước ngoặt đầu tiên, và vai trò đã thay đổi từ người trực tiếp triển khai sang người quản lý agent
- Viết skill Claude Code đầu tiên là
/git-pr để tự động hóa toàn bộ quá trình tạo PR
- Vì agent đọc toàn bộ diff và tóm tắt thay đổi một cách chuẩn xác, nên mô tả PR còn chi tiết hơn so với khi tự viết
- Dù
CLAUDE.md của codebase ghi rõ dùng Graphite, cá nhân vẫn thích plain git hơn nên vận hành bằng /git-pr
- Hiệu quả lớn hơn cả việc tiết kiệm thời gian là loại bỏ overhead tinh thần: không còn những lần chuyển ngữ cảnh nhỏ từ “tư duy về code → tư duy giải thích code” mỗi khi viết PR
Loại bỏ thời gian chờ
- Để xem preview cục bộ, liên tục phải tắt dev server và khởi động lại trên nhánh mới, tách khỏi phần việc đang làm
- Build server mất khoảng 1 phút, đủ dài để phá vỡ sự tập trung nhưng lại quá ngắn để làm việc khác
- Chuyển build sang SWC giúp thời gian khởi động lại server giảm xuống dưới 1 giây
- Vừa lưu file là server đã sẵn sàng, không còn khoảng trống khiến sự chú ý bị trôi đi
- Được ví như khác biệt giữa “một cuộc trò chuyện có những khoảng im lặng gượng gạo” và “một cuộc trò chuyện trôi chảy tự nhiên”
Agent tự kiểm chứng UI
- Trước đây, mọi thay đổi UI đều phải tự mở preview cục bộ để kiểm tra nên lập trình viên trở thành điểm nghẽn của mọi tính năng
- Sau khi extension Chrome liên tục bị crash, đã chuyển sang dùng tính năng preview của Claude Code
- Agent có thể thiết lập preview và giữ nguyên dữ liệu phiên, từ đó trực tiếp nhìn thấy UI thực sự hiển thị ra sao
- Tích hợp điều này vào workflow, để agent chỉ được coi là “xong” khi tự kiểm chứng UI
- Có thể ủy quyền việc kiểm chứng nên chỉ cần can thiệp ở bước review cuối, đồng thời agent có thể tự vận hành lâu hơn
- Việc agent tự phát hiện lỗi của chính mình tạo ra tác động lớn hơn dự đoán rất nhiều
Hệ thống worktree song song
- Sau khi có rebuild nhanh và preview tự động, điểm ma sát tiếp theo lộ ra là: chỉ có thể thoải mái làm một việc tại một thời điểm
- Muốn review PR của agent khác hoặc đồng đội thì phải checkout từ main sang nhánh PR rồi rebuild và test, nhưng việc này xung đột với các thay đổi chưa commit
stash → checkout → rebuild → test → switch back → pop stash, hoặc tạo worktree thủ công rồi lại gặp xung đột cổng
- Ứng dụng cần các cổng riêng cho frontend và backend, trong khi mọi worktree đều dùng chung cùng một biến môi trường, nên đều cố bind vào cùng cổng
- Để giải quyết, đã xây dựng hệ thống tự động gán dải cổng riêng cho từng server khi tạo worktree
- Có thể chạy đồng thời 10 preview
- Từ chỗ còn quá tải với 2 nhánh song song, đã chuyển sang vận hành cùng lúc 5 worktree
- Cho nhiều agent chạy trên các worktree riêng để build các tính năng khác nhau, và để chúng tự chạy cho đến khi hoàn tất tự kiểm chứng UI
- Sau khi tham gia sâu ở giai đoạn lập kế hoạch, sẽ không can thiệp cho đến lúc review code
- Việc review cũng mượt hơn nhiều: không cần thao tác thiết lập, rebuild hay xử lý xung đột cổng, chỉ còn luồng đọc, kiểm tra, merge
Cốt lõi không phải AI mà là hạ tầng
- Vai trò đã thay đổi: thay vì dành thời gian tự giải bài toán phức tạp và làm ra UI hoàn hảo, việc xây dựng hạ tầng để agent hoạt động hiệu quả lại trở nên thú vị hơn
- Tương tự như trở thành người quản lý của một đội 10 người, chứ không còn là lập trình viên đơn độc
- Đây không phải công việc hào nhoáng mà là phần plumbing, nhưng chính nó quyết định liệu có thể ở trong trạng thái flow hay phải vật lộn với môi trường
- Ở Tano, công việc có đòn bẩy lớn nhất không phải phát triển tính năng mà là xây hạ tầng biến dòng commit thành một dòng thác
Vòng lặp: áp dụng Theory of Constraints
- Mỗi bước loại bỏ một kiểu ma sát khác nhau:
/git-pr: loại bỏ ma sát định dạng khi biến thay đổi code thành PR- SWC: loại bỏ ma sát chờ đợi từ lúc thay đổi đến khi thấy kết quả
- Tính năng preview: loại bỏ ma sát kiểm chứng khi xác nhận thay đổi
- Hệ thống worktree: loại bỏ ma sát chuyển ngữ cảnh giữa nhiều luồng công việc
- Mỗi khi gỡ bỏ một điểm, điểm nghẽn tiếp theo lập tức lộ ra — đúng kiểu mẫu điển hình của Theory of Constraints
- Bản chất công việc cũng thay đổi: không còn là “dùng công cụ để viết code”, mà là một vòng phản hồi chặt gồm bắt đầu công việc → agent viết code → kiểm tra preview → đọc diff → phản hồi hoặc merge → công việc tiếp theo
- Khi vòng lặp đủ nhanh, sự chú ý không còn kẽ hở để trôi đi, và bản thân việc tăng tốc đã trở thành trò chơi
- Cuối cùng, mục tiêu của phát triển không còn là triển khai tính năng mà là có thể tăng tốc vòng lặp lên thêm bao nhiêu nữa
- Tốc độ tự nó trở thành niềm vui của kỹ thuật
2 bình luận
Với tư cách là người review, khi thấy PR Description do máy viết thì trải nghiệm của tôi thực sự không mấy tốt. Cũng có lúc tôi nghĩ không biết chỉ cần tinh chỉnh prompt cho tốt là được hay không..
Ý kiến trên Hacker News
Có cảm giác như chỉ số “số dòng code mỗi tuần” của thập niên 90 đang quay trở lại
Việc “tạo nhiều PR hơn” không phải là bằng chứng cho thấy AI hoạt động tốt, mà chỉ có nghĩa là đang merge nhiều hơn
Đánh giá hiệu quả chỉ bằng sản lượng mà không tính đến chất lượng code, bug, hay gánh nặng bảo trì thì chẳng khác gì những chỉ số tệ hại mà các nhà quản lý ngày xưa từng áp đặt
Cuối cùng có lẽ chúng ta không phản đối chỉ số tệ, mà là ghét chính việc bị đo lường
Mục tiêu thực sự là tạo ra kết quả đơn giản nhưng có tác động lớn
Tôi đang thử chạy nhiều agent cùng lúc để chúng thử các cách triển khai khác nhau, rồi kết hợp những ý tưởng tốt nhất lại
Ngoài ra, tôi tập hợp tài liệu và yêu cầu rồi đặt câu hỏi cho agent, sau đó khái quát hóa feedback từ code review thành checklist để áp dụng cho lần review sau
Làm việc đến mức đổ bệnh không phải điều đáng tự hào, mà là dấu hiệu cho thấy hệ thống có vấn đề
Ví dụ, mô hình COCOMO được tin cậy đến mức còn được dùng trước tòa để ước tính giá trị hệ thống
Phần lớn lập trình viên không muốn lượng hóa bản thân bằng số liệu
Tuy vậy, những người ủng hộ AI cho rằng muốn chứng minh có cải thiện thì vẫn cần đo lường
Tôi nghĩ nên dùng LLM theo hướng giảm tải nhận thức
Con người vốn không giỏi multitasking, và LLM cũng không bù được điều đó
Thay vì giao hẳn phần triển khai cho Claude, tôi dùng nó theo kiểu được hướng dẫn trực tiếp trong quá trình triển khai
Làm vậy tôi vẫn hiểu được toàn bộ quá trình, đồng thời nhìn được cả chi tiết lẫn bức tranh lớn
Chỉ cần giao cho Claude những phần lặp đi lặp lại và mang tính máy móc
Tôi đặt câu hỏi để LLM hiểu bài toán, tự viết phần code cốt lõi rồi để nó lập kế hoạch cho phần triển khai còn lại
LLM mạnh ở đọc code·giải thích·làm việc đơn giản, còn tôi tập trung vào việc chọn hướng giải quyết vấn đề
Tôi đang thử các prompt như “lập danh sách giả định” hay “liệt kê các quyết định không có trong kế hoạch” để theo dõi những phần mà LLM đã quyết định thay tôi
Nếu hiểu rõ đặc tính của Claude thì hiệu quả kiểm chứng cũng tăng, và càng có kinh nghiệm thì quản lý chất lượng càng dễ
Khi chạy nhiều agent để làm tính năng lớn, cuối cùng sẽ phát sinh vấn đề là thời gian review tăng khủng khiếp
Vì đọc code của người khác (hoặc AI) khó hơn tự mình viết
Có thể dùng tự động hóa kiểm thử để bao phủ phần nào, nhưng vẫn khó mà tin tưởng hoàn toàn
Cần làm rõ phạm vi·kiểm thử·kế hoạch tài liệu, đồng thời áp dụng bot code review (Sourcery, CodeRabbit, Codescene) và quy tắc lint thật chặt
Tôi còn dùng BDD, property testing, kiểm thử e2e, audit code, thậm chí cả mutation/fuzzing test
Điểm mạnh của agent coding là nó giúp ta có thêm thời gian để làm những việc kiểm soát chất lượng như vậy
Tôi đang thử triển khai dần dần theo hướng như 100 PRs a day
Nếu chia nhỏ công việc và tin vào test, thì việc review code do AI viết cũng nhẹ nhàng hơn
Tôi xem test case kỹ hơn, còn code review thì kết thúc nhanh
Tôi không chạy nhiều agent song song, nhưng nhờ AI mà năng suất chắc chắn đã tăng
Nếu quá trình viết PR bị tự động hóa đơn thuần thì sẽ mất đi cơ hội tự kiểm chứng
Tôi thường phát hiện ra điểm bất thường trong code của mình khi viết phần mô tả PR
Khoảnh khắc phải diễn đạt nó bằng tiếng Anh chính là lần sanity check cuối cùng
Nhờ hệ thống worktree, việc chuyển ngữ cảnh đã dễ hơn, nhưng đồng thời mệt mỏi tinh thần cũng tăng lên
Nếu chia việc thành đơn vị nhỏ và giữ chu kỳ review ngắn thì việc kiểm soát chất lượng sẽ dễ hơn
Tôi chỉ thích việc không bị đứt mạch làm việc, và hôm sau quay lại thì mọi thứ vẫn tiếp tục tiến triển
Tôi hoài nghi về giả định rằng Claude có thể viết code với độ hoàn thiện cao
Trên thực tế vẫn cần nhiều vòng phản hồi và chỉnh sửa, và nếu quản lý nhiều việc song song cùng lúc thì còn kém hiệu quả hơn
Claude Code mang tính cách mạng như một công cụ học tập, nhưng chất lượng sinh code thì khá thất thường
Khi học Flutter/Dart, tôi đã học bằng cách hỏi Claude về các khái niệm, và chỉ sau một tuần không cần sách vẫn có thể làm ra ứng dụng
Nó giống như một bách khoa toàn thư tương tác
Với những câu hỏi như “cách làm X đúng kiểu trong ngôn ngữ này là gì?”, nó đưa ra câu trả lời hữu ích ngay lập tức
Nhưng thay vì là thứ thay đổi thế giới, nó chỉ là một công cụ rất tốt mà thôi
Tuy nhiên, việc marketing quá đà đang gây tác động tiêu cực lên toàn bộ nền kinh tế
Cũng có lo ngại rằng ảo tưởng AI sẽ thay thế việc làm đang khiến thế hệ trẻ từ bỏ nghề nghiệp
Có đoạn nói rằng “sau khi chuyển build sang SWC, thời gian restart server giảm xuống dưới 1 giây”,
SWC là Speedy Web Compiler, một công cụ transpile nhanh mà không kiểm tra kiểu
Tài liệu NestJS cũng giải thích điều tương tự
Dùng LLM không có nghĩa là đáng để khoe năng suất đã tăng bùng nổ
Nếu ai cũng dùng cùng một công cụ thì mặt bằng chuẩn chỉ tăng lên mà thôi
Hơn nữa, nếu lượng lớn code do AI tạo ra không được review tử tế thì chất lượng dài hạn vẫn là dấu hỏi
LLM quả thật có giúp tăng năng suất, nhưng đo bằng biểu đồ số commit thì vô nghĩa
Nó cũng ngớ ngẩn như việc dùng LOC để đánh giá chất lượng
Tôi vẫn tự viết code để hiểu rõ, còn Claude giúp rất nhiều với vai trò đối tác phân rã công việc và review
Khả năng thay thế code phức tạp bằng các trừu tượng đơn giản mới là năng suất thực sự