Tôi đã ngừng viết code. Ứng dụng của tôi vẫn được ra mắt chỉ trong 3 ngày.

Ba tháng trước, tôi đã xây dựng một dashboard SaaS full-stack. Tôi chỉ viết khoảng 200 dòng code. Phần còn lại là do AI tạo ra, AI kiểm duyệt và AI tái cấu trúc (refactor).

Ứng dụng hiện đã đi vào hoạt động (production). Người dùng đang trả tiền cho nó. Tôi không còn phải thức khuya lo lắng về lỗi (bugs) nữa.

Đây không phải là lời khoe khoang. Đây là một lời cảnh báo.

Vai trò của lập trình viên đang thay đổi nhanh chóng. Những lập trình viên chiến thắng không phải là những người đối đầu với AI. Họ là những người hiểu được sự chuyển dịch này.

Phát triển theo hướng AI-native là một mô hình tư duy mới. Nó không chỉ đơn thuần là tính năng tự động hoàn thiện (autocomplete). Đó là việc coi AI như một cộng sự. AI đảm nhận phần thực thi (implementation). Bạn nắm giữ kiến trúc (architecture), ý đồ (intent) và sự phán đoán (judgment).

Sự chuyển dịch này diễn ra như sau:

  • Mô hình cũ: Bạn viết code. AI giúp bạn viết nhanh hơn.
  • Mô hình mới: Bạn xác định cái gì (what) và tại sao (why). AI xử lý cách thức (how). Bạn xác thực và điều hướng.

Nếu AI viết code, kỹ năng lập trình sẽ không khiến bạn trở nên không thể thay thế. Chính các kỹ năng bổ trợ (meta-skills) mới làm được điều đó.

AI rất giỏi về các khuôn mẫu (patterns). Nhưng nó lại kém trong việc lựa chọn chúng. AI không biết:

  • Liệu bạn cần một server action hay một API route.
  • Liệu state nên nằm trong Zustand hay một URL param.
  • Liệu bạn có cần một monorepo hay không.

Đây là những quyết định mang tính phán đoán. Chúng đòi hỏi bối cảnh về đội ngũ và quy mô của bạn. Bạn có bối cảnh đó. AI thì không.

Khoảng cách giữa một lập trình viên AI cấp junior và senior chính là prompt.

  • Prompt yếu: Viết một rate limiter.
  • Prompt mạnh: Viết một middleware rate limiter sử dụng Redis cho một Next.js API route. Giới hạn 10 yêu cầu mỗi phút cho mỗi IP. Trả về lỗi 429. Bỏ qua giới hạn tốc độ cho người dùng admin. Ghi lại các yêu cầu bị giới hạn (throttled requests) vào một bảng Prisma.

Prompt thứ hai cung cấp cho bạn mã nguồn sẵn sàng để triển khai (production-ready). Sự chính xác hiện là một kỹ năng kỹ thuật hàng đầu.

Bạn cũng phải chú ý đến các kịch bản lỗi (failure modes). Code do AI viết thường trông có vẻ đúng nhưng lại sai một cách tinh vi. Nó có thể vượt qua các bài kiểm tra nhưng lại ẩn chứa lỗ hổng bảo mật hoặc lỗi tranh chấp (race condition). Hãy xem xét kết quả của AI với cùng một con mắt khắt khe mà bạn dành cho một lập trình viên junior.

Những lập trình viên sợ AI đang tập trung sai chỗ. Họ lo lắng về việc viết ít code đi. Rủi ro thực sự là việc không nâng cấp được các kỹ năng xoay quanh việc viết code.

Mục tiêu không phải là ngừng làm lập trình viên. Mà là trở thành một lập trình viên giỏi hơn.

Ứng dụng được ra mắt trong 3 ngày vì tôi đã dành thời gian cho:

  • Mô hình dữ liệu (data model).
  • Luồng người dùng (user flow).
  • Các trường hợp biên (edge cases).
  • Logic nghiệp vụ (business logic).

Đó chính là công việc hiện nay.

Tỷ lệ code do AI viết so với code tự viết của bạn hiện tại là bao nhiêu? Hãy cho tôi biết dưới phần bình luận.

Tôi ngừng viết code, ứng dụng của tôi vẫn được ra mắt trong 3 ngày: đây là những gì điều đó cho chúng ta biết về việc trở thành một 2GHP

Tôi từng nghĩ rằng trở thành một lập trình viên giỏi đồng nghĩa với việc viết ra những dòng code thanh thoát, phức tạp và tối ưu. Tôi dành hàng giờ đồng hồ để tinh chỉnh từng hàm, tranh luận về kiến trúc hệ thống và tự hào về khả năng giải quyết các thuật toán hóc búa.

Nhưng tuần trước, tôi đã làm một điều cực kỳ táo bạo: Tôi đã ngừng viết code.

Không, tôi không nói là tôi không còn sử dụng code nữa. Tôi nói là tôi đã ngừng việc tự tay viết từng dòng code. Thay vào đó, tôi đã chuyển sang một vai trò mới: Người điều phối (Orchestrator).

Và kết quả là? Tôi đã ra mắt một ứng dụng hoàn chỉnh chỉ trong vòng 3 ngày.

Điều này không chỉ là về việc sử dụng AI; đó là về một sự thay đổi tư duy sâu sắc. Nó cho thấy sự chuyển dịch từ tư duy "Ưu tiên Code" (Code-First) sang tư duy "Ưu tiên Sản phẩm" (Product-First), và đây chính là chìa khóa để trở thành một 2GHP (2x Growth High Performer - Người làm việc hiệu suất cao với mức tăng trưởng gấp đôi).

Cái bẫy của sự hoàn hảo trong code

Là những lập trình viên, chúng ta thường rơi vào một cái bẫy: Chúng ta nhầm lẫn giữa việc "viết code" và "xây dựng sản phẩm".

Chúng ta dành quá nhiều thời gian để lo lắng về việc liệu một đoạn code có tuân thủ đúng nguyên tắc SOLID hay không, hoặc liệu cấu trúc thư mục có thực sự "chuẩn" hay không. Trong khi đó, người dùng thực tế thì không quan tâm đến việc code của bạn đẹp thế nào; họ chỉ quan tâm đến việc ứng dụng có giải quyết được vấn đề của họ hay không.

Khi tôi tập trung quá nhiều vào việc viết code, tôi đang làm việc như một công nhân xây dựng. Nhưng khi tôi tập trung vào việc ra mắt sản phẩm, tôi đang làm việc như một kiến trúc sư.

Sự trỗi dậy của Người điều phối (The Orchestrator)

Với sự hỗ trợ của các công cụ AI như Cursor, Claude và các mô hình ngôn ngữ lớn (LLM), rào cản giữa ý tưởng và thực thi đã bị xóa bỏ.

Thay vì ngồi gõ từng dòng if-else, quy trình làm việc của tôi hiện tại là:

  1. Xác định mục tiêu: Tôi biết chính xác mình muốn xây dựng cái gì và tại sao.
  2. Mô tả kiến trúc: Tôi sử dụng ngôn ngữ tự nhiên để mô tả logic và cấu trúc cho AI.
  3. Kiểm soát và Điều phối: Tôi xem xét các đoạn code mà AI tạo ra, kiểm tra tính logic và yêu cầu điều chỉnh nếu cần.
  4. Tích hợp và Kiểm thử: Tôi tập trung vào việc kết nối các thành phần lại với nhau để đảm bảo chúng hoạt động như một hệ thống thống nhất.

Tôi không còn là người trực tiếp cầm búa và đục; tôi là người cầm bản thiết kế và chỉ đạo đội ngũ (trong trường hợp này là đội ngũ AI) thực hiện nó.

Trở thành một 2GHP

Vậy, 2GHP là gì?

Một 2GHP không phải là người viết được nhiều dòng code nhất trong một giờ. Một 2GHP là người tạo ra nhiều giá trị nhất trong một đơn vị thời gian.

Sự khác biệt nằm ở chỗ:

  • Lập trình viên truyền thống: Tập trung vào cách thức (How) — Làm thế nào để viết đoạn code này?
  • 2GHP: Tập trung vào cái gì (What) và tại sao (Why) — Chúng ta đang xây dựng cái gì và tại sao nó lại quan trọng?

Khi bạn ngừng ám ảnh với việc viết code và bắt đầu ám ảnh với việc giải quyết vấn đề, tốc độ của bạn sẽ tăng lên gấp bội. Bạn không còn bị giới hạn bởi tốc độ gõ phím hay khả năng ghi nhớ cú pháp, mà được mở rộng bởi khả năng tư duy hệ thống và khả năng sử dụng công cụ.

Kết luận

Việc tôi ra mắt ứng dụng trong 3 ngày không có nghĩa là kỹ năng lập trình của tôi đã trở nên vô dụng. Ngược lại, nó đòi hỏi một kỹ năng cao cấp hơn: Kỹ năng tư duy sản phẩm và khả năng điều phối công nghệ.

Thế giới đang chuyển dịch. Nếu bạn vẫn chỉ tập trung vào việc viết code, bạn sẽ bị bỏ lại phía sau. Nhưng nếu bạn học cách trở thành một người điều phối, một người xây dựng sản phẩm thực thụ, bạn sẽ thấy rằng giới hạn duy nhất của mình chính là trí tưởng tượng của chính mình.

Đã đến lúc ngừng viết code và bắt đầu xây dựng.