Khi AI tự viết lại ứng dụng: Bài học đắt giá từ thử nghiệm của Anthropic với Claude Code

Bài viết được dịch và tổng hợp từ tin tức gốc. Bạn có thể đọc bài viết gốc bằng tiếng Anh tại đây.

Điểm tin nhanh:

• Boris Cherny (Anthropic) thử nghiệm dùng Claude Code để chuyển đổi ứng dụng Electron sang Swift native.
• Quy trình yêu cầu AI tự xác thực bằng cách so sánh pixel giữa hai phiên bản ứng dụng.
• Thử nghiệm kéo dài hơn hai tuần và đặt ra câu hỏi lớn về thiết kế sản phẩm so với việc chỉ thay đổi framework kỹ thuật.

Trong kỷ nguyên mà các AI Agent đang dần trở thành những cộng sự đắc lực, việc đặt ra những câu hỏi táo bạo về khả năng tự vận hành của máy móc là điều tất yếu. Tuy nhiên, liệu chúng ta có đang quá kỳ vọng vào khả năng của AI khi yêu cầu nó thực hiện những tác vụ phức tạp mà không có sự định hướng về tư duy thiết kế? Câu chuyện về việc dùng Claude Code để tái cấu trúc ứng dụng Claude từ Electron sang Swift không chỉ là một bài toán kỹ thuật, mà còn là lời cảnh tỉnh về việc tại sao tư duy hệ thống trong phát triển phần mềm vẫn luôn là yếu tố sống còn.

Thử nghiệm táo bạo của Anthropic

Tại sự kiện Y Combinator Startup School 2026, Boris Cherny, người đứng đầu bộ phận Claude Code, đã chia sẻ về một thử nghiệm thú vị. Thay vì tập trung vào kỹ thuật prompt thông thường, Cherny nhấn mạnh vào tầm quan trọng của việc giao cho AI những nhiệm vụ khó và khả năng tự xác thực (verification). Để chứng minh, ông đã yêu cầu Claude Code thực hiện một tác vụ đầy tham vọng: rewrite toàn bộ ứng dụng desktop của Claude từ Electron sang Swift native.

Quy trình thực hiện được thiết lập như sau:

[Claude Code] ---> [GitHub Mac Runner] ---> [Swift Codebase] ---> [Pixel-by-pixel Verification]

Bảng so sánh tiến độ và mục tiêu

Sai lầm trong tư duy thiết kế sản phẩm

Nhiều người cho rằng việc chuyển đổi sang Swift sẽ giải quyết được các vấn đề về hiệu năng. Tuy nhiên, vấn đề cốt lõi của ứng dụng Claude hiện tại không nằm ở framework Electron, mà nằm ở tư duy thiết kế UI/UX. Việc cố gắng ép một giao diện vốn không được tối ưu cho macOS vào một framework native như AppKit hay SwiftUI chẳng khác nào việc cố gắng chải tóc ngược chiều. Dù bạn có thay đổi nguyên liệu (framework) tốt đến đâu, nếu công thức (thiết kế) vẫn tồi tệ, kết quả cuối cùng vẫn sẽ không thể làm hài lòng người dùng.

Lưu ý: Hiệu năng ứng dụng không chỉ đến từ ngôn ngữ lập trình. Một ứng dụng được thiết kế tồi trên Electron vẫn sẽ là một ứng dụng tồi khi chuyển sang Swift nếu không thay đổi tư duy UX.

Điều này tương tự như những bài học mà chúng ta đã từng thảo luận về việc tại sao Developer Experience lại trở thành nạn nhân của Backlog. Khi chúng ta quá tập trung vào công cụ mà quên mất trải nghiệm cuối cùng, chúng ta đang lãng phí tài nguyên quý giá.

Đánh giá & Lời khuyên Thực tiễn

Từ góc độ của một kỹ sư cấp cao, thử nghiệm của Cherny cho thấy tiềm năng to lớn của AI trong việc tự động hóa các tác vụ lặp lại, nhưng cũng bộc lộ những hạn chế rõ rệt:

• Ưu điểm: Khả năng tự thiết lập môi trường (runner), tự truy cập codebase và tự thực hiện vòng lặp xác thực (verification loop) là những bước tiến lớn của AI Agent.
• Nhược điểm: Thiếu tư duy phản biện về thiết kế. AI có thể thực hiện lệnh "rewrite" nhưng không thể tự đặt câu hỏi "liệu thiết kế này có phù hợp với người dùng Mac hay không?".
• Phạm vi ứng dụng: Phù hợp cho các tác vụ refactor code đơn giản, chuyển đổi syntax hoặc viết unit test. Không nên dùng cho việc tái cấu trúc toàn bộ kiến trúc sản phẩm mà không có sự giám sát của con người.

Mẹo hay: Nếu bạn đang tìm kiếm các giải pháp AI Agent hiệu quả, hãy tham khảo cách tích hợp SlopScan vào Claude Code để tối ưu hóa quy trình làm việc thay vì chỉ phó mặc cho AI.

Câu hỏi thường gặp (FAQ)

Tại sao việc rewrite ứng dụng bằng AI lại mất nhiều thời gian đến vậy?

Việc rewrite không chỉ là chuyển đổi mã nguồn mà còn bao gồm kiểm thử, xử lý các logic phức tạp và xác thực pixel-by-pixel. AI hiện tại vẫn gặp khó khăn trong việc duy trì ngữ cảnh dài hạn và xử lý các lỗi phát sinh trong quá trình build native.

Có nên dùng AI để thay thế hoàn toàn quy trình phát triển phần mềm?

Không. AI là công cụ hỗ trợ (co-pilot). Việc thiếu đi tư duy thiết kế sản phẩm và khả năng ra quyết định chiến lược khiến AI chưa thể thay thế hoàn toàn vai trò của kỹ sư phần mềm.

Làm sao để tránh việc AI tạo ra những sản phẩm "tồi"?

Luôn bắt đầu bằng việc định nghĩa rõ ràng về thiết kế và tiêu chuẩn chất lượng. Đừng yêu cầu AI "làm cho nó tốt hơn" mà hãy yêu cầu "thực hiện theo tiêu chuẩn thiết kế X".

Kết luận

Thử nghiệm của Boris Cherny là một ví dụ điển hình về việc chúng ta cần tỉnh táo trước làn sóng AI. Công nghệ chỉ là phương tiện, còn tư duy thiết kế mới là linh hồn của sản phẩm. Nếu bạn đang quan tâm đến việc tối ưu hóa quy trình phát triển, hãy tìm hiểu thêm về tư duy Prompt như Code để làm chủ AI thay vì để AI dẫn dắt sai hướng. Hãy theo dõi hi_dev để cập nhật những góc nhìn chuyên sâu nhất về công nghệ và AI Agent trong tương lai.