Khi nào không nên sử dụng Claude Code?

Các lập trình viên đang sống trong thời đại nơi AI có thể viết code nhanh hơn họ tự gõ. Claude Code, GitHub Copilot và những người anh em AI của chúng đã trở thành người bạn đồng hành hàng ngày của chúng ta, đôi khi là những người đồng đội hữu ích, đôi khi lại là những thực tập sinh quá tự tin cần được giám sát.

Nhưng đây là điều bất ngờ mà không ai nhắc đến: Khi nào không nên sử dụng một công cụ cũng quan trọng không kém.

Sau khi làm việc nhiều với các công cụ lập trình AI (và học hỏi từ một số sai lầm đắt giá), mỗi người sẽ vạch ra những vùng nguy hiểm, những tình huống mà việc sử dụng Claude Code giống như mang súng phun lửa đến một buổi lễ thắp nến. Chắc chắn nó vẫn sẽ hoạt động, nhưng liệu có nên như vậy không?

Bài viết hôm nay sẽ chỉ cho bạn khi nào không nên sử dụng Claude Code.

1. Khi học một framework hoặc ngôn ngữ mới

Câu chuyện: Sarah là một chuyên gia Angular đang chuyển sang React. Cô ấy đã sử dụng Claude Code để tạo ra mọi thứ, hook, quản lý trạng thái, các mẫu component. 3 tuần sau, một lập trình viên junior hỏi tại sao cô ấy lại đặt các lệnh gọi `fetch` trực tiếp trong `useEffect` thay vì một custom hook.

Sarah có thể triển khai các tính năng nhưng không thể gỡ lỗi chúng. Cô ấy đã bỏ qua giai đoạn khó khăn để xây dựng kiến thức.

Vấn đề: Khi Claude Code viết điều này cho bạn ngay từ ngày đầu tiên, bạn sẽ bỏ lỡ việc hiểu tại sao mảng phụ thuộc lại trống, tại sao chúng ta không thể làm cho chính `useEffect` trở thành async, và cách các hàm dọn dẹp hoạt động.

useEffect(() => {
  const fetchData = async () => {
    const response = await fetch('/api/users');
    setUsers(await response.json());
  };
  fetchData();
}, []); // Why empty? What if it's not?

Cách tiếp cận tốt hơn: Trước tiên hãy tự viết code, mắc lỗi, gỡ lỗi, sau đó sử dụng Claude Code để xem xét giải pháp của bạn và đề xuất cải tiến.

Bài học rút ra: Hãy sử dụng Claude Code như một gia sư kiểm tra bài tập về nhà của bạn, chứ không phải là đứa trẻ cho phép bạn sao chép.

2. Khi làm việc với mã nguồn cũ mà bạn không hiểu

Câu chuyện: Một lập trình viên tìm thấy đoạn code “thừa” này trong một mô-đun thanh toán:

private sanitizeInput(value: string): string {
  return value.trim()
    .replace(/\s+/g, ' ')
    .replace(/\u200B/g, '')     // Zero-width space
    .replace(/ /g, ' ')    // Non-breaking space
    .trim();
}

Claude Code đề xuất một phiên bản “sạch hơn” chỉ với một lệnh trim() và một lệnh replace(). Ba ngày sau, lỗi thanh toán đối với người dùng quốc tế xuất hiện. Hóa ra các cổng thanh toán chèn các ký tự ẩn như một biện pháp chống gian lận. Đoạn code "thừa" đó đang giải quyết một vấn đề thực tế trong môi trường sản xuất từ ​​năm 2019.

Rủi ro: Mã nguồn cũ thường chứa các giải pháp được tìm ra một cách khó khăn. Giải pháp tạm thời kỳ lạ đó có thể đang khắc phục một trường hợp ngoại lệ quan trọng chỉ xuất hiện trong môi trường sản xuất trong những điều kiện cụ thể.

Cách tiếp cận tốt hơn:

1. Sử dụng lệnh git blame để tìm hiểu ai đã viết nó? Khi nào? Tại sao?
2. Tìm kiếm các ticket liên quan
3. Viết các bài kiểm tra cho hành vi hiện có TRƯỚC KHI thay đổi bất cứ điều gì
4. Tái cấu trúc từng bước

Bài học rút ra: Mã nguồn cũ vô tội cho đến khi bị chứng minh là có vấn đề. Mớ code rối rắm đó có thể là mớ hỗn độn.

3. Khi xây dựng các tính năng xác thực hoặc bảo mật quan trọng

Câu chuyện: Một công ty khởi nghiệp SaaS về chăm sóc sức khỏe của một người bạn đã sử dụng Claude Code để xác thực JWT. Nó trông hoàn hảo, bản demo diễn ra tuyệt vời, họ đã nhận được vốn đầu tư. Ba tháng sau, một chuyên gia tư vấn bảo mật đã phát hiện ra: Các lỗ hổng tấn công dựa trên thời gian, không có cơ chế thu hồi token, token refresh không bao giờ hết hạn, không có giới hạn tỷ lệ và các bí mật được mã hóa cứng. Việc khắc phục mất 3 tuần và 15.000 USD phí tư vấn.

Rủi ro: Các mô hình AI được huấn luyện trên mã nguồn công khai, thường bao gồm những mẫu phản bảo mật. Chúng tạo ra code hoạt động được, nhưng bảo mật đòi hỏi code phải hoạt động và không thể bị khai thác.

// Những gì bạn thực sự cần (đơn giản hóa)
app.post('/login', rateLimiter, async (req, res) => {
  const user = await User.findOne({ email: req.body.email });
  if (!user) {
    await bcrypt.compare(req.body.password, 'dummy'); // Constant-time
    return res.status(401).json({ error: 'Invalid credentials' });
  }
  
  const isValid = await bcrypt.compare(req.body.password, user.password);
  if (!isValid) {
    return res.status(401).json({ error: 'Invalid credentials' });
  }
  
  const token = jwt.sign({ id: user.id }, getRotatingSecret(), { expiresIn: '15m' });
  await AuditLog.create({ action: 'login', userId: user.id, ip: req.ip });
  
  res.json({ token });
});

Cách tiếp cận tốt hơn: Sử dụng các thư viện đã được kiểm chứng (Passport.js, NextAuth, Auth0), tuân theo hướng dẫn của OWASP và nhờ chuyên gia bảo mật xem xét. Chỉ sử dụng Claude Code cho các đoạn mã mẫu sau khi đã đưa ra những quyết định quan trọng.

Bài học rút ra: Trong bảo mật, những gì bạn không biết có thể hủy hoại doanh nghiệp của bạn. AI biết các mẫu; bảo mật là về việc biết những mẫu nào ẩn chứa các lỗ hổng.

4. Khi tối ưu hiệu năng là yếu tố quan trọng

Câu chuyện: Một dashboard thương mại điện tử load trong 8 giây. Claude Code đề xuất sử dụng cơ chế phát hiện thay đổi OnPush và hàm trackBy. Họ đã triển khai mọi thứ. Kết quả mất 7,8 giây. Vẫn chậm.

Sau đó, họ thực sự phân tích hiệu năng bằng Chrome DevTools. Vấn đề thực sự: 47 lệnh gọi API liên tiếp, hình ảnh 5MB được thu nhỏ thành hình thu nhỏ 100px và rò rỉ bộ nhớ từ các observable chưa được đăng ký. Sau khi khắc phục các vấn đề thực sự: 0,7 giây.

Vấn đề: Claude Code không thể chạy các công cụ phân tích hiệu năng. Nó đề xuất những tối ưu hóa chung mà không biết các điểm nghẽn thực sự của bạn.

// Nếu không sử dụng công cụ phân tích hiệu năng, bạn có thể tối ưu hóa điều này như sau:
@Component({ changeDetection: ChangeDetectionStrategy.OnPush })

// Nhưng vấn đề THỰC SỰ nằm ở đây:
chartData$ = this.api.getData().pipe(
  map(data => data.items) // ❌ 10,000 items crash the chart
);

// Giải pháp thực tế:
chartData$ = this.api.getData().pipe(
  map(data => this.aggregateData(data.items, 100)) // ✓ Aggregate to 100
);

Cách tiếp cận tốt hơn: Phân tích hiệu năng trước (Chrome DevTools, Angular DevTools, Lighthouse), xác định các điểm nghẽn bằng dữ liệu, sau đó sử dụng Claude Code để triển khai những tối ưu hóa cụ thể.

Bài học rút ra: “Làm cho nó nhanh hơn” mà không có dữ liệu chỉ là phỏng đoán. Claude Code có thể triển khai các bản sửa lỗi, nhưng nó không thể xác định được những gì cần sửa.

5. Khi thiết kế kiến ​​trúc hệ thống phức tạp

Câu chuyện: Một phó chủ tịch đã xây dựng kiến ​​trúc microservices phức tạp dựa trên các đề xuất của Claude Code: 12 dịch vụ, Kafka, cổng GraphQL, cơ sở dữ liệu riêng biệt, Kubernetes. Sau 6 tháng và chi 2 triệu USD, họ đã gặp khó khăn. Nhóm 3 người của họ không thể quản lý 12 dịch vụ. Độ trễ P99 là 3 giây. Tính nhất quán dữ liệu là một cơn ác mộng.

Điều đáng chú ý nhất là họ có 1.000 người dùng hàng ngày. Họ đã xây dựng kiến ​​trúc quy mô Netflix cho một vấn đề kinh doanh nhỏ.

Những gì họ cần là một hệ thống nguyên khối dạng mô-đun, hàng đợi công việc đơn giản, API REST, PostgreSQL. Chi phí sẽ là 50.000 USD thay vì 2 triệu USD.

Vấn đề: Kiến trúc đòi hỏi phải hiểu khả năng của nhóm, các ràng buộc kinh doanh, yêu cầu về quy mô và sự đánh đổi. Claude Code có thể triển khai bất kỳ mô hình nào, nhưng không thể quyết định mô hình nào phù hợp với bối cảnh của bạn.

Cách tiếp cận tốt hơn: Đưa ra các quyết định kiến ​​trúc thông qua thảo luận nhóm, bằng chứng về khái niệm và xem xét những ràng buộc. Ghi lại các quyết định trong ADR. Sau đó sử dụng Claude Code để triển khai một cách nhất quán.

6. Khi gỡ lỗi sự cố sản xuất dưới áp lực

Câu chuyện: Vào ngày Black Friday, 3:22 sáng, trang web thương mại điện tử sập. Mọi API đều bị lỗi thời gian chờ. Kỹ sư trực ca đã dành 8 phút để giải thích vấn đề cho Claude Code, định dạng nhật ký, chờ phân tích. 500 USD bị mất đi mỗi giây.

Cuối cùng đành bỏ cuộc và kiểm tra trực tiếp việc giám sát cơ sở dữ liệu. Tìm thấy vấn đề trong 90 giây: Lỗi CROSS JOIN vô tình tạo ra 47 tỷ hàng, làm cạn kiệt nhóm kết nối. Đã hủy các truy vấn, sửa mệnh đề WHERE, triển khai lại. 3 phút. Khủng hoảng qua đi.

Tổng thời gian ngừng hoạt động: 11 phút. Có thể chỉ là 3 phút nếu không có Claude Code.

Vấn đề: Trong các cuộc khủng hoảng sản xuất, bạn cần truy cập trực tiếp vào công cụ, số liệu thời gian thực và khả năng lặp lại nhanh chóng. Mỗi chu kỳ phải diễn ra trong vòng 0 giây. Việc giải thích cho AI sẽ tạo ra sai lầm chết người.

Cách tiếp cận tốt hơn: Sử dụng trực tiếp các công cụ giám sát, tuân theo quy trình vận hành, tin tưởng vào trực giác gỡ lỗi của bạn. Sau khi khủng hoảng xảy ra, hãy sử dụng Claude Code để xây dựng các biện pháp phòng ngừa.

Bài học rút ra: Trong lúc xảy ra sự cố, bạn cần tốc độ và công cụ. Hãy để dành Claude Code cho việc phân tích sau sự cố và phòng ngừa.

7. Khi xử lý các API độc quyền hoặc không được ghi chép đầy đủ

Câu chuyện: Một người đã dành hai tuần để tích hợp API webhook của đối tác. Tài liệu nói rằng chỉ cần xác thực Bearer đơn giản. Thực tế là người này cần tiền tố code công ty, môi trường sản xuất yêu cầu tiêu đề X-Tenant-Context, cấu trúc dữ liệu hoàn toàn khác và các phản hồi thành công đôi khi bao gồm những trường lỗi.

Không có thông tin nào trong số này được ghi trong tài liệu. Điều này được phát hiện thông qua các cuộc trò chuyện trên Slack, thử và sai, và gỡ lỗi trong môi trường sản xuất.

Vấn đề: Kiến thức của Claude Code đến từ các kho lưu trữ công khai, tài liệu và Stack Overflow. API nội bộ/của đối tác của bạn không có bất kỳ nguồn nào trong số này.

// Những gì tài liệu thể hiện so với thực tế
// Đã được ghi nhận:
{ event: 'user.created', url: 'https://...' }

// Mã nguồn hoạt động thực tế (sau 2 tuần):
{
  evt: 'user.created',              // Not "event"
  target_url: url,                  // Not "url"
  options: {
    include_metadata: true,
    retry_policy: 'exponential'     // Required but undocumented
  }
}

Cách tiếp cận tốt hơn: Thử nghiệm trực tiếp với curl, trao đổi với nhóm API, xây dựng các bộ sưu tập Postman, ghi lại những phát hiện của bạn. Sau đó sử dụng Claude Code để triển khai một cách gọn gàng.

Bài học rút ra: Các API không được ghi lại cần phải điều tra, chứ không phải AI. Hãy ghi lại những phát hiện để các nhà phát triển tương lai có thể tham khảo.

8. Khi viết code quan trọng, có rủi ro cao

Câu chuyện: Một công ty khởi nghiệp fintech đã sử dụng Claude Code để tái cân bằng danh mục đầu tư. Mã nguồn trông hoàn hảo. Đã triển khai lên bản beta. Sau đó: lỗi làm tròn số đã gây ra 47 giao dịch có vấn đề, khiến một người dùng phải trả 375 USD phí để sửa lỗi giá chỉ 3 xu. Vi phạm quy định về giảm thuế và thu hoạch lỗ đã khiến một người dùng khác mất 3.400 USD. Lỗi giờ giao dịch dẫn đến giá thực thi lệnh tệ hại. Vi phạm quy định về bán lỗ.

Tổng thiệt hại: 47.000 USD tiền hoàn trả, 125.000 USD phí pháp lý, điều tra của cơ quan quản lý.

Vấn đề: Mã nguồn có rủi ro cao cần kiến ​​thức chuyên môn, khả năng xử lý các trường hợp ngoại lệ, tuân thủ quy định và nhật ký kiểm toán. Thiếu một chi tiết nhỏ cũng có thể khiến người dùng mất hàng nghìn USD và phá hủy doanh nghiệp của bạn.

Cách tiếp cận tốt hơn: Thuê chuyên gia trong lĩnh vực, kiểm thử rộng rãi, kiểm toán mọi thứ, xem xét thủ công, triển khai dần dần, có đảm bảo. Claude Code có thể hỗ trợ giao diện người dùng và báo cáo, nhưng logic cốt lõi cần chuyên môn của con người.

Bài học rút ra: Khi code có hậu quả thực tế về tài chính, y tế, pháp lý, các lỗi không chỉ gây khó chịu. Chúng có thể dẫn đến kiện tụng. Những tình huống này đòi hỏi sự chú ý tỉ mỉ đến các trường hợp ngoại lệ.

9. Khi đó chỉ là một lỗi đơn giản, chỉ cần 2 giây để sửa

Câu chuyện: Một người phát hiện ra lỗi chính tả: API_ENDPIONT thay vì API_ENDPOINT. Dù có thể nhấn Ctrl+H và sửa nó trong 3 giây, nhưng thay vào đó, người này đã khởi chạy Claude Code. Nó đã phân tích dự án, quét các dependency, kiểm tra những file kiểm thử, lên kế hoạch thay đổi, xác minh mọi thứ. Thời gian: 42 giây.

Chi phí phát sinh: Claude Code hoạt động tự động, nó load ngữ cảnh, phân tích, lập kế hoạch, thực thi và xác thực. Nó hoàn hảo cho việc tái cấu trúc phức tạp, nhưng vô lý đối với các lỗi chính tả.

Một vài ví dụ về việc thao tác quá mức cần thiết:

• Thay đổi hằng số màu: Thủ công 2 giây, Claude 35 giây
• Đổi tên biến: Thủ công 5 giây (Cmd+D), Claude 38 giây
• Thêm dấu chấm phẩy: Thủ công 1 giây, Claude 30 giây

Kết luận: Khi chi phí kích hoạt vượt quá thời gian hoàn thành tác vụ, bạn đang sử dụng sai công cụ. Đôi khi công cụ hiệu quả nhất chính là bàn phím của bạn.

10. Khi đã đạt đến giới hạn sử dụng

Câu chuyện có thật:

Hai lập trình viên tại một công ty khởi nghiệp đang phát triển nhanh chóng đang cùng trao đổi. Họ đã đầu tư toàn lực vào các trợ lý lập trình AI. Mọi lập trình viên đều sử dụng Claude Code rất nhiều, đôi khi hàng giờ mỗi ngày. Nó được ghi trong tài liệu quy trình làm việc của họ. Nhân viên mới được đào tạo để sử dụng nó. Các yêu cầu kéo (PR) được xem xét với giả định rằng Claude Code sẽ phát hiện ra hầu hết mọi vấn đề.

Rồi đến tuần lập kế hoạch sprint. Mọi người đều đang thử nghiệm các tính năng mới. 5 lập trình viên, tất cả đều sử dụng Claude Code rất nhiều.

Chiều thứ Ba, 3 lập trình viên đã đạt đến giới hạn sử dụng của họ. Sáng thứ Tư, thêm hai người nữa cũng vậy. Đến chiều thứ Tư, toàn bộ nhóm kỹ thuật đều bị giới hạn tốc độ truy cập.

Tốc độ làm việc của nhóm giảm khoảng 40% trong tuần đó. Họ đã không đạt được mục tiêu sprint. Người quản lý dự án rất bối rối. Các lập trình viên đã trở nên phụ thuộc vào sự hỗ trợ của AI, và khi không có AI, kỹ năng của họ đã bị mai một.

Tóm lại: Trợ lý lập trình AI là những công cụ mạnh mẽ, nhưng không thể thay thế hoàn toàn con người. Giới hạn sử dụng không chỉ là những hạn chế kỹ thuật mà còn là lời nhắc nhở bạn cần duy trì các kỹ năng phát triển cốt lõi của mình. Những nhà phát triển giỏi nhất biết cách lập trình cả khi có và không có AI. Hãy xây dựng những thói quen bền vững không bị phá vỡ khi AI không khả dụng.