Cách tôi làm việc hiệu quả với Claude Code

Nghe bài viết:

Đã khoảng 6 tuần kể từ khi tôi gia nhập Tano, và đây là lịch sử commit của tôi:

commit-history-graph-260417233705

Commit là một thước đo rất tệ để đánh giá năng suất, nhưng đó là tín hiệu dễ thấy nhất mà tôi có. Có điều gì đó thực sự đã thay đổi trong cách tôi làm việc, và số lượng commit chỉ là hệ quả.

Vậy điều gì đã thay đổi?

Tự động hóa công việc lặp lại

Khi mới vào Tano, tôi tạo mọi pull request thủ công: stage thay đổi, viết commit message, viết mô tả PR, push, rồi tạo PR trên GitHub. Quy trình tiêu chuẩn — cũng ổn.

Mất một thời gian tôi mới nhận ra đây là công việc lặp lại, nhàm chán. Tôi quen làm đến mức không còn nhận ra nó vô nghĩa.

Đó là bước chuyển đầu tiên: tôi không còn là người trực tiếp triển khai nữa. Tôi là người quản lý các agent đang triển khai. Và người quản lý thì sẽ tự động hóa những việc lặp lại của đội.

Sau đó tôi viết kỹ năng Claude Code đầu tiên: /git-pr.

Nó làm mọi thứ tôi từng làm — nhưng tốt hơn. Mô tả PR chi tiết hơn vì nó đọc toàn bộ thay đổi và tóm tắt chính xác. Tôi đã quá quen với việc làm thủ công đến mức không nhận ra nó tốn công như thế nào.

Thời gian tiết kiệm được là một chuyện, nhưng quan trọng hơn là giảm tải suy nghĩ. Trước đây mỗi PR là một lần chuyển ngữ cảnh: ngừng suy nghĩ về code, chuyển sang nghĩ cách mô tả code. Giờ chỉ cần gõ /git-pr và tiếp tục việc khác.

Loại bỏ thời gian chờ

Việc review code trước đây có một vòng lặp khó chịu.

Xem trước thay đổi, rời khỏi công việc đang làm, tắt dev server, chạy lại trên branch mới, kiểm tra hoạt động, rồi review code.

Thời gian build server khoảng một phút — đủ lâu để mất tập trung, nhưng lại quá ngắn để làm việc khác.

Tôi chuyển sang dùng SWC, và thời gian khởi động lại server giảm xuống dưới 1 giây. Cảm giác rất “đã”.

Nghe có vẻ nhỏ, nhưng không hề. Khi restart gần như tức thì, bạn không bao giờ mất “flow”. Lưu file, server đã sẵn sàng, kiểm tra ngay. Không có khoảng trống để mất tập trung.

Để Claude tự kiểm tra giao diện

Trước đây, tôi kiểm tra mọi thay đổi giao diện thủ công. Xem trước, đánh giá bằng mắt, quyết định đúng hay sai. Nó hoạt động — nhưng khiến tôi trở thành điểm nghẽn.

Sau khi extension Chrome hay bị crash, tôi chuyển sang dùng tính năng preview trong Claude Code. Nó cho phép agent tự dựng môi trường, giữ trạng thái phiên và nhìn thấy giao diện thực tế.

Tôi đưa nó vào quy trình: một thay đổi chưa “xong” cho đến khi agent tự kiểm tra giao diện. Điều này cho phép tôi giao việc kiểm tra, và chỉ tham gia ở bước review cuối.

Kết quả: agent có thể làm việc lâu hơn mà không cần giám sát. Chúng tự phát hiện lỗi. Điều này quan trọng hơn tôi nghĩ.

Song song hóa mọi thứ

Khi build nhanh và preview tự động, một vấn đề mới lộ ra: tôi chỉ có thể làm một việc tại một thời điểm.

Việc review PR trở nên khó chịu: checkout branch, build lại, test. Nhưng điều này phá vỡ thay đổi chưa commit. Tôi phải stash, chuyển branch, build, test, rồi quay lại — rất phiền.

Ứng dụng của tôi có frontend và backend, mỗi cái cần một cổng. Tất cả worktree dùng chung biến môi trường nên bị xung đột cổng. Chạy song song là một cuộc chiến.

Tôi xây dựng lại hệ thống: mỗi worktree được cấp một dải cổng riêng. Không còn xung đột. Tôi có thể chạy 10 preview cùng lúc.

Tôi chuyển từ việc quá tải với 2 branch song song sang chạy 5 worktree cùng lúc. Quy trình làm việc thay đổi: khởi chạy nhiều agent trên các worktree khác nhau, mỗi cái xây một tính năng.

Tôi tập trung vào lập kế hoạch, rồi biến mất cho đến lúc review code. Việc agent tự bắt lỗi trở nên cực kỳ quan trọng khi chạy song song.

Review cũng mượt hơn: không cần setup, không cần build lại. Chỉ đọc, kiểm tra, merge. Xong.

Điểm mấu chốt là hạ tầng, không phải AI

Vai trò của tôi đã thay đổi. Trước đây tôi thích giải bài toán khó và tối ưu giao diện. Giờ thì ít hơn.

Điều thú vị hơn là xây dựng hạ tầng để agent hoạt động hiệu quả. Giống như quản lý một đội 10 người thay vì làm một mình. Và giống mọi manager, bạn được “nhận công” cho toàn bộ kết quả của đội.

Những vấn đề này không hào nhoáng — chúng giống như hệ thống ống nước. Nhưng chính nó quyết định bạn có làm việc trơn tru hay không.

Những gì mang lại hiệu quả lớn nhất cho tôi không phải là viết tính năng, mà là xây dựng hạ tầng giúp số lượng commit tăng vọt.

Vòng lặp làm việc

Mỗi bước cải tiến loại bỏ một loại ma sát khác nhau:

  1. /git-pr loại bỏ ma sát trong việc trình bày — biến code thành PR hoàn chỉnh.
  2. SWC loại bỏ ma sát trong thời gian chờ.
  3. Preview loại bỏ ma sát trong việc kiểm tra.
  4. Worktree loại bỏ ma sát trong chuyển ngữ cảnh.

Mỗi lần loại bỏ một điểm nghẽn, điểm nghẽn tiếp theo lại lộ ra. Đúng theo lý thuyết điểm nghẽn: giải quyết một chỗ, hệ thống sẽ lộ ra chỗ tiếp theo.

Bản chất công việc cũng thay đổi. Tôi không còn “dùng tool để viết code”. Tôi ở trong một vòng lặp chặt chẽ: giao việc → agent viết code → xem preview → đọc thay đổi → phản hồi hoặc merge → lặp lại.

Vòng lặp nhanh đến mức không còn khoảng trống để mất tập trung.

Việc xây dựng sản phẩm trở thành một kiểu “niềm vui” khác — nhanh đến mức trò chơi là làm sao nhanh hơn nữa. Khi vòng lặp đủ nhanh, lập trình trở thành một dạng giải trí.

claude-260417234304