Không ai chủ đích quên cách viết code. Chuyện đó xảy ra giống như phần lớn các trường hợp mai một kỹ năng khác: từng chút một, mỗi lần một lối tắt tiện lợi. Trước đây bạn tự viết regex; giờ bạn mô tả điều mình muốn rồi dán vào bất cứ thứ gì mô hình đưa ra. Trước đây bạn dò từng dòng stack trace; giờ bạn thả nó vào cửa sổ chat rồi đọc bản tóm tắt. Xét riêng lẻ, mỗi lần thay thế như vậy đều hợp lý. Nhưng cộng dồn lại, sau một năm làm việc với sự hỗ trợ của AI, kết quả là một lập trình viên có thể ra tính năng nhanh khi bật công cụ, nhưng lại hơi khựng lại khi tắt nó đi.

Đó chính là mạch ngầm khó chịu ẩn dưới làn sóng "vibe-coding" bùng nổ trong tháng này — Lovable được cho là đang tiến sát mức định giá 13,2 tỷ đô la, Replit và Factory đều gọi vốn lên đến hàng tỷ, SpaceX hạ giá cạnh tranh với các mô hình tiên phong bằng Grok 4.5 được xây dựng cho "các tác nhân tự hành". Tất cả những điều đó đều được tối ưu cho một mục tiêu duy nhất: khiến bạn tự viết ít code hơn. Đó chính là mục đích, và với nhiều loại công việc, đây là một sự đánh đổi chính đáng. Nhưng điều đó cũng có nghĩa là cả ngành đã dành hai năm qua để chạy một thí nghiệm không kiểm soát về việc bạn có thể "thuê ngoài" bao nhiêu năng lực viết code thủ công trước khi phải trả giá cho điều đó, và hóa đơn đang bắt đầu đến hạn theo những cách rất cụ thể, có thể kiểm chứng được.

Khoảng trống đó thực sự "cắn" ở đâu

Sự mai một không phải là một nỗi lo mơ hồ — nó thể hiện rõ trong ba tình huống cụ thể, và bạn nên thành thật với chính mình về việc mình đang phơi nhiễm với tình huống nào trong số đó:

  • Phỏng vấn. Ngoại trừ các bài take-home, phần lớn các buổi phỏng vấn kỹ thuật vẫn hạn chế hoặc cấm sử dụng AI hỗ trợ. Nếu sự thành thạo hàng ngày của bạn đã âm thầm chuyển từ "tôi có thể tự viết cái này" sang "tôi có thể chỉ đạo mô hình viết cái này", thì một vòng viết bảng hay lập trình trực tiếp sẽ phơi bày khoảng trống đó ngay lập tức, ngay trước mặt người đang quyết định có tuyển bạn hay không.
  • Sự cố ngừng hoạt động. Khi hệ thống production sập, con đường nhanh nhất để khắc phục thường là đọc code lạ dưới áp lực và tự mình suy luận trực tiếp — chứ không phải soạn một prompt thật hay về một hệ thống mà bạn không có thời gian để giải thích. Việc ứng phó sự cố đòi hỏi chính xác những kỹ năng (đọc code nhanh, debug trong đầu, thuộc lòng bề mặt API) vốn ít được rèn luyện nhất khi ngày ngày bạn để mô hình xử lý thay mình.
  • Không có kết nối, không có trợ lý. Một chuyến bay, một địa điểm khách hàng có mạng bị khóa chặt, một sự cố ngừng dịch vụ từ phía nhà cung cấp mô hình — bất kỳ điều nào trong số này cũng đẩy bạn trở về với việc code không có trợ giúp trong một khoảng thời gian. Nó không cần phải kéo dài mãi mãi mới đáng lo; nó chỉ cần xảy ra đúng vào ngày bạn cần ra sản phẩm là đủ.

Không cái nào trong số này là tình huống giả định được nghĩ ra để bán sản phẩm cả. Đó đều là những điều kiện bình thường của một sự nghiệp đi làm. Vấn đề là liệu bạn có nhận ra sự mai mòn đó trước khi một trong những tình huống này đẩy bạn vào thế bí hay không.

Sự xuất hiện của các công cụ luyện tập

Đó chính là khoảng trống mà một công cụ mới có tên Atrophy CLI đang nhắm tới, theo một bài viết trên The Register trong tháng này. Cách tiếp cận của công cụ này rất thẳng thắn: coi năng lực viết code giống như chỉ số Elo trong cờ vua, thay vì một trạng thái nhị phân "biết code / không biết code". Bạn bắt đầu bằng một bài kiểm tra nền để xác định mình đang ở đâu, sau đó công cụ sẽ luyện tập cho bạn qua một loạt các nhóm kỹ năng riêng biệt — khả năng nhớ cú pháp, debug, đọc code, ghi nhớ API, và phân rã vấn đề — rồi theo dõi chỉ số của bạn theo thời gian, giống hệt cách một công cụ cờ vua theo dõi xem bạn có thực sự tiến bộ hay chỉ đang cảm thấy như vậy. Câu khẩu hiệu gói gọn toàn bộ luận điểm chỉ trong một câu: "Nếu sự hỗ trợ của AI đang âm thầm bào mòn khả năng viết code không cần trợ giúp của bạn, biểu đồ sẽ cho bạn biết điều đó — trước khi một buổi phỏng vấn, một sự cố ngừng hoạt động, hay một ngày không có wifi cho bạn biết.

Điểm thiết kế đáng chú ý ở đây là việc chia nhỏ thành các nhóm riêng biệt thay vì gộp thành một điểm số tổng hợp duy nhất. Vibe coding không bào mòn mọi kỹ năng lập trình một cách đồng đều — bạn vẫn có thể giữ được sự sắc bén trong khâu phân rã vấn đề (chia nhỏ một bài toán thành từng bước) vì đó phần lớn vẫn là việc của bạn ngay cả khi có trợ lý AI, trong khi khả năng nhớ cú pháp và cơ bắp debug thuần túy không cần copilot lại âm thầm yếu đi, bởi đó chính xác là những phần bạn đã "giao khoán" cho AI. Một điểm số duy nhất sẽ che giấu điều đó. Một chỉ số theo từng nhóm kỹ năng ít nhất cũng cho bạn biết cụ thể cơ bắp nào cần rèn lại, và đó là một tín hiệu hữu ích hơn nhiều so với cảm giác chung chung rằng mình đang "rỉ sét".

Một lời rào trước cần thiết

Cần nói thẳng: Atrophy CLI còn khá mới, và tôi chưa thấy dữ liệu độc lập nào cho thấy chỉ số của nó thực sự dự đoán được kết quả phỏng vấn hay xử lý sự cố, hay liệu việc luyện tập đều đặn có thực sự đảo ngược được sự suy giảm kỹ năng hay chỉ khiến bạn giỏi lên ở chính các bài luyện tập đó mà thôi — đây là rủi ro có thật với bất kỳ công cụ luyện tập nào không phải là công việc thực tế. Hãy coi nó như một công cụ chẩn đoán đáng thử, chứ không phải một giải pháp đã được chứng minh. Cái hạng mục mà nó đang khoanh vùng ra — đo lường sự suy giảm kỹ năng do AI hỗ trợ, tách biệt khỏi năng suất do AI hỗ trợ — mới là ý tưởng hữu ích ở đây, bất kể bản thân công cụ này có phải là thứ tồn tại lâu dài hay không.

Nên làm gì với vấn đề này mà không phải từ bỏ năng suất

Bạn không cần phải từ bỏ hoàn toàn việc lập trình có AI hỗ trợ để tự bảo vệ mình; làm vậy tức là từ bỏ một mức tăng năng suất thực sự chỉ để phòng ngừa một rủi ro mà bạn hoàn toàn có thể quản lý với chi phí thấp hơn nhiều. Một vài thói quen cụ thể sẽ giải quyết phần lớn vấn đề:

  • Định kỳ tự mình giải quyết một việc mà bình thường bạn sẽ giao cho mô hình — một lỗi, một hàm nhỏ, một phép biến đổi dữ liệu — hoàn toàn không có trợ giúp, và bấm giờ chính mình. Chú ý xem mình khựng lại ở chỗ nào.
  • Trước một vòng phỏng vấn hay một ca trực on-call, hãy chủ động dành một khoảng thời gian code mà không dùng AI, giống như cách bạn ôn gấp trước một kỳ thi mà đã nhiều tháng không đụng đến kiến thức đó.
  • Khi bạn sử dụng AI hỗ trợ, hãy đọc kỹ đoạn code được tạo ra đến mức có thể giải thích lại cho người khác, thay vì chỉ dán vào rồi đi tiếp — đây chính là bước quyết định nhiều nhất việc trải nghiệm đó có thực sự xây dựng sự hiểu biết của bạn hay chỉ đang "tẩy trắng" xung quanh nó.
  • Nếu một công cụ theo kiểu chấm điểm như Atrophy CLI phù hợp với bạn, hãy dùng nó như một máy báo khói, chứ không phải một chương trình luyện tập tự thân — kiểm tra định kỳ, và nếu một nhóm kỹ năng nào đó đang tụt xuống, hãy đi làm công việc thực sự không có trợ giúp trong lĩnh vực đó, thay vì chỉ luyện flashcard cho nó.

Cách nhìn nhận trung thực nhất là: lập trình có AI hỗ trợ và năng lực lập trình không cần trợ giúp giờ đây là hai kỹ năng tách biệt mà bạn phải quản lý, chứ không phải một kỹ năng duy nhất có thêm lối tắt. Các nhà tuyển dụng, hội đồng phỏng vấn, và các kênh xử lý sự cố lúc 3 giờ sáng chưa hoàn toàn bắt kịp điều đó, nhưng họ sẽ nhận ra ai là những ứng viên đã giữ cho cả hai kỹ năng đều còn sống.