AI đang âm thầm ăn mòn não mình — teo tư duy, bottleneck mới, và 5 rule mình đang sống theo
AI đang âm thầm ăn mòn não mình — teo tư duy, bottleneck mới, và 5 rule mình đang sống theo
Một pattern khó chịu mình nhận ra ở chính mình sau 18 tháng dùng AI dày đặc — và cái protocol mình đang chạy để đảo chiều nó.
Trong 12–18 tháng qua mình quan sát thấy một pattern khó chịu ở chính mình, và mình khá chắc không chỉ mình bị.
Mình ship code nhanh hơn 2–3 lần so với 2023. Dựng một service mới trong một buổi chiều. Vứt vào một codebase chưa từng thấy, mười phút sau đã có model khá về nó. Theo mọi chỉ số bề mặt, AI đang làm mình năng suất hơn.
Nhưng nếu thành thật với bản thân, mình cảm được một thứ khác đang diễn ra bên dưới. Mình không nhớ đoạn code viết hai ngày trước. Phản xạ đầu tiên khi gặp error là paste vào Claude thay vì ngồi đọc stack trace. Những concept từng thuộc lòng — isolation level, consistency model, memory barrier thực ra làm gì — giờ mờ đi, vì “lúc cần mình cứ hỏi”. Ngồi xuống viết tay 500 từ văn kỹ thuật, câu cú cứng và chưa chín so với hai năm trước.
Đó là cognitive atrophy. Teo cơ, nhưng cho não. Gần như không ai nói về nó — và đó chính là lý do nó nguy hiểm.
1. Triệu chứng, nói thẳng
Trước khi gạt đi, làm self-test trước đã. Năm câu, trả lời thật:
- Lần cuối bạn viết 500 từ suy nghĩ kỹ thuật liền mạch không AI là khi nào?
- Không nhìn gì cả, bạn giải thích được Raft consensus, isolation level của DB đang dùng, và tại sao TCP cần congestion control không?
- Tuần qua, bao nhiêu lần bạn paste error/code vào AI trước khi dành 3 phút đọc tay?
- Bạn còn tóm được luận điểm của một paper/cuốn sách đã đọc 3 tháng trước không?
- Mạng hỏng 8 tiếng, bạn tiếp tục làm được hay đóng băng?
Mỗi câu “không” là một dấu atrophy. Ba câu trở lên là khẩn cấp. Có những tháng mình ăn bốn.
Các triệu chứng mình thấy ở mình và quanh mình:
- Viết code nhanh hơn 2–3× nhưng không nhớ đã viết gì sau 2 ngày.
- Debug chậm hơn so với 2 năm trước, vì không còn thói quen ngồi với code, chỉ paste.
- Mất khả năng tư duy từ zero — tắt mạng là đứng hình trước vấn đề mà 2 năm trước giải được trong đầu.
- Nhớ ít lý thuyết hơn — consistency model, indexing strategy, allocator pattern — vì “cần thì tra”.
- Viết kém hẳn đi — khi không có AI, câu cú lủng củng rõ rệt.
- Đọc ít source gốc hơn — thay bằng AI summary, cảm giác “đã hiểu” nhưng không hiểu thật.
Nếu bạn thấy mình trong 2–3 điểm trên, xin chào, welcome to the club. Atrophy không đau, không có tín hiệu rõ ràng. Nó chỉ lặng lẽ biến bạn thành phiên bản yếu hơn của chính bạn, mỗi 12 tháng một nấc.
2. Tại sao nó xảy ra
AI tốt đến mức nó xoá đi productive struggle — cuộc vật lộn có sinh lực mà não cần để học. Cuộc vật lộn chính là cơ chế học. Khi não tự tổ chức thông tin, nó tạo connection. Khi AI tổ chức hộ, không connection nào được tạo. Bạn “biết” concept theo nghĩa truy cập được, không biết theo nghĩa đã nội hoá.
Tệ hơn, AI tạo false sense of mastery. Đọc AI summary của DDIA cảm giác như đã đọc DDIA. PR xanh test cảm giác như một PR bạn hiểu. Cả hai đều là ảo giác, và sự thoải mái của ảo giác chính là thứ làm nó nguy hiểm — bạn không có áp lực nào để đối chiếu.
Tin tốt: atrophy đảo ngược được, y hệt cơ bắp không dùng, với điều kiện tập chủ động và có cấu trúc. “Dùng AI ít lại” không phải fix. Một protocol mới là.
3. Bottleneck đã dịch chuyển
Trước 2023, bottleneck của senior engineer là execution — tốc độ và chất lượng. Viết nhanh hơn, ship sạch hơn, đọc codebase nhanh hơn, deploy ít incident hơn. Đó là trò chơi, và ai thắng trò chơi đó là ai thắng ở execution.
Sau 2023, execution gần như miễn phí cho ai biết lái AI. Một junior có động lực với Claude Code có thể đạt 80% output của senior trong ba tháng. 80% đó không còn là chỗ có leverage.
20% còn lại — phần AI chưa commodity hoá — là:
- Judgment. Biết cái gì đáng làm, cái gì không.
- Taste. Nhận ra cái gì tốt, cái gì xấu — không cần checklist.
- Synthesis. Ghép 5 nguồn trái chiều thành 1 view mạch lạc.
- Framing. Đặt lại câu hỏi để mở ra solution chưa ai thấy.
- Navigating uncertainty. Ra quyết định tốt với thông tin không đủ.
Đây là scarcity mới của ngành. Có, AI làm bạn 10×. Không có, AI làm bạn cảm giác có — trong lúc bạn đang đều đều mất giá.
Một bài test cụ thể. Giao cùng một prompt cho hai engineer: “Xây rate limiter cho public API.”
Engineer A mở chat và trước giờ ăn trưa đã có 200 dòng token-bucket middleware trên Redis. Chạy được.
Engineer B hỏi ngược lại: “API này dùng cho ai? Thất bại rate limit trông như thế nào từ phía caller? Có sống được với eventually consistent count không? Scale hiện tại bao nhiêu? Cost của một false positive so với false negative?”
Hai năm trước cả hai đều có giá trị — A ship nhanh, B ship an toàn. Bây giờ B đáng giá gấp năm A, vì A đã bị AI commodity hoá, còn B thì chưa. Nước đi không phải thành B và vứt AI đi. Nước đi là là B và vẫn có tốc độ của A, bằng AI.
4. Lợi thế ngầm của dân backend
Đây là phần mình nghĩ đa số backend dev bỏ lỡ: công việc hàng ngày đã và đang rèn chúng ta đúng các kỹ năng của bottleneck mới — miễn phí. Chỉ là không ai gọi tên chúng ra.
Công việc xây hệ thống backend ép bạn phải tư duy theo:
- Dependencies. Call này trigger gì, ở đâu?
- Failure modes. Cái gì hỏng nếu timeout này bắn, partition xảy ra, queue dồn lại?
- Invariants. State nào không được vi phạm, kể cả giữa lúc crash?
- Time. Ordering, causality, concurrency, clock skew.
- Tradeoffs. Consistency vs availability, latency vs throughput, read vs write.
Đây chính là systems thinking. Theo mình, đây là kỹ năng trí tuệ dễ chuyển giao nhất của thế kỷ 21, và frontend dev, data scientist, PM không tự nhiên có nó như backend engineer. Bản thân mình không nhận ra mình đã có nó, cho đến khi bắt đầu chủ động viết về nó.
Khoảng trống là hầu hết chúng ta chạy reflex này vô thức, và chỉ trên code. Cơ hội là chạy nó có ý thức, và trên mọi thứ — quyết định sản phẩm, tổ chức, sự nghiệp.
5. Năm rule mình đã tự ép vào
Đây là các thói quen mình đang cài đặt. Không cái nào clever. Cái nào cũng khó chịu trong 2 tuần đầu. Sau 60 ngày, chúng không còn là rule nữa — chúng thành reflex.
Rule 1 — Viết trước, prompt sau
Trước khi hỏi AI bất cứ thứ gì quan trọng, mình viết 200 từ suy nghĩ của riêng mình trước. Vấn đề, cách tiếp cận hiện tại, alternatives đã reject kèm lý do, câu hỏi mở mình chưa chắc. Rồi mới đưa cho AI.
Viết ép articulation. Chỗ nào mình ngập ngừng, chỗ đó tư duy còn mờ. AI summary của vấn đề giấu chuyện này đi; viết tay làm nó lộ ra.
Hiệu quả lớn hơn: khi đã viết rồi mới đưa cho AI, AI trở thành sanity check + critic thay vì oracle. Đây là khác biệt giữa học và tra.
Thay vì hỏi “thiết kế cache layer cho X như nào?”, mình viết:
Vấn đề: cache cho GET /users/:id, hot path, ~10k rps.
Suy nghĩ hiện tại: Redis LRU, TTL 5m, key "user:{id}", invalidate qua
event Kafka user-updated.
Reject: in-memory LRU (không share giữa instance), write-through
(+15ms cho register flow, không chấp nhận được).
Mở: cache stampede khi expire đồng loạt? cold cache sau deploy?
split theo region hay không?
Rồi: “attack design này như một hostile staff engineer đã thấy 5 production incident.” Câu trả lời của AI lúc này giá trị gấp 10 lần, vì nó đang bắn vào một mục tiêu cụ thể, không phải ngồi trước trang giấy trắng.
Rule 2 — Đối đầu, không hợp tác
Mặc định, mình reframe prompt từ “help me do X” sang “attack X” hoặc “argue against X.”
Claude, ChatGPT mặc định quá nice. Chúng được RLHF để hợp tác, không phải để cãi. Nếu mình hỏi “design này ổn không?”, 90% thời gian câu trả lời là “ổn, chỉ vài điểm nhỏ…” — kể cả khi design thật sự tệ. Mình nghĩ đây là tác động phá tư duy critical âm thầm nhất của AI, và gần như không ai nhận ra.
Khi ép AI vào thế đối đầu, mình nhận được feedback thật sự hữu ích, và luyện được emotional resilience với criticism. Phép thử thật của một senior engineer không phải là họ bảo vệ design nhanh ra sao; mà là họ đón cái “design này sai vì X, Y, Z” bình tĩnh đến đâu.
Prompt mình dùng liên tục:
- “Đây là design của tôi. Đóng vai hostile staff engineer đã thấy 5 production incident — tìm 5 cách cái này hỏng ở production."
- "Argue against approach của tôi. Cho tôi counter-argument mạnh nhất anh dựng được."
- "Nếu tôi ship cái này, 18 tháng sau nó trông ra sao? Liệt kê 3 failure mode."
- "Giả sử tôi đã sai. Khả năng cao nhất là tôi sai ở đâu?”
Cảnh báo: hỏi AI “argue against” rồi ignore hết còn tệ hơn không hỏi. Đọc từng argument, tự cãi lại trong đầu. Nếu không cãi được — design có lỗ thật.
Rule 3 — Delayed synthesis
Với bất kỳ chủ đề nào mình thật sự cần hiểu sâu, mình đọc 3–5 source gốc trước khi chạm AI summary. Tự hình thành view trước, rồi mới đối chiếu.
AI summary là pre-digested thinking — tốt để quyết định “cái này có đáng đọc sâu không”, tệ để học. Nếu mình bắt đầu bằng summary, opinion của mình bị anchor vào nó, và mình mất khả năng disagree — vì mình chưa bao giờ build view khác.
Làm ngược lại thì một thứ thú vị xảy ra: delta giữa summary của mình và summary của AI chính là chỗ học thật. Một trong hai đang đơn giản hoá quá, hoặc sai tinh vi ở đâu đó. Tìm ra ai đúng — đây là bài tập trí tuệ giá trị nhất mình biết.
Không cố làm mỗi ngày — sẽ kiệt. Một chủ đề/tuần là đủ.
Rule 4 — Feynman, với AI làm người phỏng vấn hoài nghi
Mỗi tuần một lần, mình chọn một concept mình tin là mình hiểu, viết giải thích như cho một đứa trẻ 12 tuổi, rồi yêu cầu AI đóng vai staff engineer hoài nghi và phỏng vấn mình — 5 câu, độ khó tăng dần, kiểu câu catch đúng người chỉ học thuộc định nghĩa.
Tôi sẽ giải thích [concept] cho bạn. Sau đó, đóng vai một staff engineer
hoài nghi, hỏi tôi 5 câu clarifying ngày càng khó — kiểu câu mà người chỉ
học thuộc định nghĩa sẽ không trả lời được. Đừng cho tôi câu trả lời,
chỉ hỏi.
Concept: [tên]
Giải thích của tôi: [200–500 từ]
Luận điểm của Feynman đã biết từ thập niên 60: hiểu thật = giải thích được cho người không biết. Phiên bản AI có lợi thế hơn bản gốc: AI không bao giờ mệt, không bao giờ nể nang, không xấu hổ khi mình ngập ngừng.
Danh sách 12 tuần cho backend dev, mỗi tuần một concept, 60 phút, một mình, không mạng trong lúc giải thích:
- CAP, và tại sao chữ “C” không có nghĩa như đa số người nghĩ.
- Isolation level của DB bạn đang ship — phantom read, non-repeatable read, write skew xảy ra thật khi nào.
- TCP congestion control — tại sao mạng ổn định đến từ thuật toán, không từ protocol rigid.
- Raft/Paxos — quorum, log replication, điều kiện split-brain.
- Garbage collection — generational, concurrent, stop-the-world tradeoff.
- B-tree vs LSM — tại sao PostgreSQL chọn cái này, RocksDB chọn cái kia.
- Event sourcing vs CRUD — không phải “tốt hơn”, mà “đúng hơn cho domain nào”.
- Eventual consistency trong production — thật sự có nghĩa gì, failure mode ra sao.
- Load balancer — L4 vs L7, sticky session, weighted round-robin thật ra giải quyết gì.
- OAuth 2.0 — tại sao có nhiều flow, authorization code vs implicit vs PKCE.
- TLS handshake — trong 10 round-trip đầu tiên thật sự xảy ra gì.
- Memory model của ngôn ngữ bạn ship — JMM cho Java, Go memory model, C++ memory order.
Làm xong 12 cái này, mình cam đoan bạn sẽ hiểu backend sâu hơn đa số người có chữ “senior” trong title.
Rule 5 — Một domain liền kề mỗi quý
Mỗi quý mình chọn một domain liền kề backend và đi sâu, dùng AI như tutor cá nhân. Quan trọng: có bài tập, không chỉ đọc.
Liền kề mới quan trọng. Distributed systems, ML fundamentals (đủ để ra quyết định sản phẩm, không đủ để thành ML engineer), security, infra, database internals, một chút compiler — tất cả đều compound với backend work mình đang làm. Học một quý luật hoặc tài chính thì tốt cho cuộc sống, nhưng không compound.
Protocol đơn giản: một primary source tốt (sách, khoá học, paper series — không phải AI summary); 30–60 phút mỗi ngày; một Feynman session/tuần trên một concept từ domain đó; một project nhỏ/2 tuần thực sự dùng cái vừa đọc; một blog post 800 từ/tháng.
6. Năm cái bẫy mình hay rơi vào
Đây là các failure mode mình rơi vào lặp đi lặp lại. Gọi tên chúng ra giúp mình bước ra nhanh hơn.
Autocomplete trap. Accept suggestion của Copilot/Cursor mà chưa đọc kỹ. Codebase dần đầy code chính mình không hiểu. Fix: tắt autocomplete cho critical path (auth, payment, migration). Chỗ khác, đọc mọi suggestion như đang review PR của đồng nghiệp. Rule cứng: nếu không giải thích được 1 dòng vừa commit trong 30 giây, mình đang ở trong bẫy.
Summarization trap. “Đã đọc” 10 paper trong tháng mà không giải thích được cái nào. Summary OK để screening — cái này có đáng đọc sâu không? — nhưng bất cứ thứ gì quyết định của mình phụ thuộc vào, mình đi đến source. Không ngoại lệ.
Authority trap. AI articulate và confident, não tự động gán authority cho nó — một bias đã được nghiên cứu kỹ. Fix: triangulate với claim quan trọng, và chủ động hỏi “khi nào claim này sai? counter-example đáng chú ý là gì?”
Infinite information trap. AI đẩy cost tiếp xúc content gần về 0. Cost não hấp thụ thì không đổi. Kết quả: overflow input, zero output. Fix: 80% produce, 20% consume, timebox cứng cho consumption.
Outsourced-thinking trap. Chạy tới AI trước khi ngồi với vấn đề dù chỉ 1 phút. Struggle khó chịu, AI xoá khó chịu tức thì. Nhưng khó chịu đó chính là tín hiệu cơ hội học đang mở. 5 phút tư duy trước mọi prompt về vấn đề mới, không thương lượng.
7. Một điểm bắt đầu 90 ngày
Nếu đống lý thuyết trên là quá nhiều, đây là commitment nhỏ nhất có ích:
- Tuần 1–4. Cài Rule 1 (write first, prompt second). Thêm adversarial prompting cho mọi design quan trọng. Chủ nhật review bản thân — 30 phút, append vào file
blind_spots.md. Làm Feynman session đầu tiên với một concept trong list trên. - Tuần 5–8. Bắt đầu một cuốn Tier 1 — Designing Data-Intensive Applications là đáp án đúng nếu bạn không quyết được — 30–60 phút/ngày, không AI summary trước. Tiếp Feynman hàng tuần. Publish một blog post 800 từ về concept đã Feynman.
- Tuần 9–12. Bắt đầu juxtaposition: một chủ đề/tuần, so 3 approach cạnh nhau. Dạy một người một concept trong 45 phút. Publish thêm một post. Viết một retrospective 1000 từ cho riêng mình và plan quý tới.
Sau 90 ngày, các habit tự chạy. Trước 90 ngày, bạn sẽ thấy mình ngu đi trong 2 tuần, rồi nhanh hơn một chút, rồi sắc bén hơn rõ rệt. Đó là đường cong.
8. Ba điều mình muốn khắc vào não chính mình
- Cognitive atrophy là real, đang xảy ra ngay lúc này, và reverse được — nhưng chỉ bằng protocol, không phải ý chí. “Dùng AI có trách nhiệm” không phải là protocol.
- Bottleneck đã dịch từ execution sang judgment, taste, synthesis. Dành ~70% năng lượng học vào bottleneck mới, ~30% cho execution. Đa số dev làm ngược lại — vì execution dễ đo hơn.
- Nâng cấp tư duy là hệ thống thói quen hàng ngày, không phải tia chớp insight. Năm rule trên là đủ. Đừng đợi framework hoàn hảo. Bắt đầu với Rule 1 ngay tuần này.
Mình sẽ biết mình đã trung thực với bài này nếu 6 tháng sau, đọc lại nó mà không có AI trong vòng lặp, mình vẫn nhận ra người đã viết ra nó.