29 điểm bởi GN⁺ 2026-02-05 | 8 bình luận | Chia sẻ qua WhatsApp
  • Sự xuất hiện của các công cụ lập trình AI đã làm trải nghiệm suy nghĩ sâu giảm mạnh, khiến tôi cảm thấy sự trưởng thành của mình với tư cách một kỹ sư đang chững lại
  • Trong tôi có hai khuynh hướng là "Builder" và "Thinker", trong đó Builder được thỏa mãn nhờ AI nhưng Thinker thì đang bị bỏ đói
  • Với "vibe coding", có thể nhanh chóng chuyển từ ý tưởng sang hiện thực, nhưng cơ hội giải quyết vấn đề một cách sáng tạo đã giảm đi đáng kể
  • Khi AI đưa ra một lời giải ở mức 70% đủ tốt, vì xu hướng thực dụng nên rất khó để từ chối nó
  • Tôi đã thử tìm cảm giác thỏa mãn từ việc suy nghĩ sâu bên ngoài chuyện lập trình nhưng không thành công, và hiện không chắc liệu có thể đồng thời thỏa mãn cả hai nhu cầu hay không

Nêu vấn đề về sự thiếu hụt tư duy

  • Trước khi đọc bài viết này, hãy thử nghĩ xem "lần gần nhất bạn thực sự suy nghĩ nghiêm túc là khi nào"
  • Bài viết này không phải giải pháp hay lời khuyên, mà chỉ đơn thuần là lời bộc bạch về sự bức bối tôi cảm thấy gần đây

Hai khuynh hướng: Builder và Thinker

  • Builder: khuynh hướng muốn tạo ra thứ gì đó, phát hành nó và tạo ra kết quả thực dụng
    • Được thúc đẩy bởi tốc độ và tính hữu ích
    • Có được dopamine từ việc triển khai thành công, cảm giác thỏa mãn khi xây dựng hệ thống giải quyết vấn đề thật, và niềm vui khi biết có người đang dùng công cụ mình làm ra
  • Thinker: khuynh hướng cần đến cuộc vật lộn trí tuệ sâu và kéo dài
    • Khi còn học đại học chuyên ngành vật lý, tôi từng nhận những bài tập khó vượt xa mức trung bình
    • Có những bài toán mà dù đã hiểu khái niệm, vẫn rất khó nghĩ ra cách tiếp cận ngay từ đầu

Ba kiểu sinh viên khi đối mặt với bài toán khó

  • Kiểu 1 (đa số): thử vài lần rồi bỏ cuộc, sau đó nhờ giáo sư hoặc trợ giảng giúp
  • Kiểu 2 (kiểu nhà nghiên cứu): vào thư viện tìm bài tương tự hoặc gợi ý để biến bài toán thành thứ có thể giải được, và nhìn chung sẽ đi đến lời giải
  • Kiểu 3 (kiểu Thinker): chỉ tiếp cận bằng cách suy nghĩ
    • Gần như dành toàn bộ thời gian não bộ ở trạng thái non-I/O trong nhiều ngày hoặc nhiều tuần cho khả năng giải quyết vấn đề
    • Ngay cả khi ngủ, quá trình suy nghĩ vẫn tiếp diễn
    • Cách này chưa từng thất bại, và tôi nhận ra suy nghĩ sâu và bền bỉ là thế mạnh của mình
    • Tôi không nhanh như top 1% hay có tài năng bẩm sinh, nhưng tin rằng nếu có đủ thời gian thì mình có thể giải được bất kỳ vấn đề nào

Xung đột với AI

  • Lý do khiến kỹ nghệ phần mềm ban đầu thỏa mãn đến vậy chính là cảm giác thỏa mãn kép này
  • Cả Builder (làm ra thứ hữu ích, cảm thấy năng suất và thực dụng) lẫn Thinker (giải những bài toán thật sự khó) đều được đáp ứng
  • Những dự án giúp tôi trưởng thành nhất với tư cách kỹ sư luôn chứa rất nhiều bài toán khó đòi hỏi lời giải sáng tạo
  • Nhưng gần đây, số lần tôi nghiêm túc bám lấy một vấn đề trong hơn vài tiếng đã giảm mạnh
  • Tôi nghĩ nguyên nhân của toàn bộ chuyện này là do AI
  • Tôi đang viết nhiều phần mềm hơn bao giờ hết, phức tạp hơn bao giờ hết, nhưng lại không hề có cảm giác mình đang trưởng thành thêm với tư cách kỹ sư
  • Khi lần lại lý do của cảm giác "chững lại" đó, tôi nhận ra rằng mình đang bỏ đói Thinker
  • "Vibe coding" rõ ràng làm Builder thỏa mãn
    • Có một khoái cảm tức thì khi ý tưởng được hiện thực hóa gần như ngay lập tức trong thời gian cực ngắn
    • Ngược lại, những khoảnh khắc phải tự mình nghĩ ra lời giải sáng tạo cho vấn đề kỹ thuật đã giảm đi rất nhiều
  • Với những người thuần khuynh hướng Builder, đây là thời đại tối ưu
  • Nhưng với tôi, rõ ràng vẫn thiếu một điều gì đó

Cái bẫy của chủ nghĩa thực dụng

  • Tôi đoán sẽ có phản biện rằng "nếu vibe coding giải được thì vấn đề đó vốn dĩ không phải vấn đề khó"
    • Nhưng đó là một lập luận lệch khỏi trọng tâm
  • AI không hẳn đặc biệt giỏi với bài toán khó, và cũng không phải lúc nào cũng đưa ra lời giải tốt ngay cả với bài toán dễ
    • Nếu tự mình viết lại cùng một module lần thứ ba, tôi tin chắc kết quả sẽ tốt hơn bất kỳ thứ gì AI tạo ra
  • Nhưng đồng thời, tôi cũng là một người thực dụng
  • Nếu chỉ cần bỏ ra một phần rất nhỏ thời gian và công sức để có được một lời giải "đủ gần", thì không chọn AI lại trở nên phi lý hơn
    • Vấn đề thật sự là tôi không thể chủ động tắt đi chủ nghĩa thực dụng này
  • Về bản chất tôi là Builder, và tôi thích chính hành vi tạo ra thứ gì đó. Nếu có thể làm nhanh hơn thì lúc nào tôi cũng thấy cách đó tốt hơn
  • Dù có muốn từ chối AI và quay về thời mà nhu cầu của Thinker được đáp ứng một cách tự nhiên qua việc lập trình, Builder vẫn rất khó chấp nhận sự kém hiệu quả đó
  • AI gần như chắc chắn không đưa ra lời giải khiến tôi hài lòng 100%, nhưng lời giải ở mức 70% mà nó đạt được thường vẫn đáp ứng tiêu chí "đủ tốt"

Rồi phải làm gì tiếp theo?

  • Thành thật mà nói, tôi vẫn chưa tìm ra câu trả lời và vẫn đang tiếp tục suy nghĩ
  • Tôi không chắc liệu hai khuynh hướng này còn có thể được thỏa mãn đồng thời trong cùng một lĩnh vực là lập trình hay không
  • Có một lựa chọn là nhắm tới những dự án khó hơn để cố tình tìm những bài toán mà AI hoàn toàn thất bại
  • Thỉnh thoảng tôi vẫn gặp những bài toán như vậy, nhưng cảm giác là số bài toán cần lời giải sáng tạo sâu đang giảm rất nhanh
  • Tôi cũng đang thử lấy lại cảm giác phát triển trí tuệ từ bên ngoài việc lập trình
    • Tôi đã mở lại những giáo trình cũ để kết nối lại với vật lý
    • Nhưng điều đó không dẫn tới sự thỏa mãn thực sự
    • Khi hoàn toàn có thể đi làm ra thứ gì đó, tôi rất khó tự biện minh cho việc dùng thời gian và năng lượng tinh thần vào những bài toán vật lý không liên quan trực tiếp tới hiện tại, cũng chẳng còn mới nữa
  • Khuynh hướng Builder không cho phép tôi chỉ ngồi đó bám lấy một vấn đề chưa được giải quyết và suy tư
  • Khuynh hướng Thinker thì vẫn tiếp tục bị bỏ đói chừng nào vibe coding còn tiếp diễn
  • Tôi không chắc liệu thời điểm cả hai nhu cầu cùng được đáp ứng có quay trở lại hay không

> "Giờ đây chúng ta đã có quyền gọi thực thể này bằng cái tên quen thuộc mà từ trước tới nay luôn được dùng để chỉ thứ mà không sức mạnh tưởng tượng nào, không cú nhảy táo bạo nào của huyễn tưởng, không lòng sùng tín thành kính nào, không tư duy trừu tượng sâu sắc đến đâu, thậm chí không cả tâm trí trong cơn xuất thần, từng có thể chạm tới: Thượng đế (God). Nhưng sự thống nhất căn bản này thuộc về quá khứ, và giờ đây không còn tồn tại nữa. Trong tiến trình biến đổi sự tồn tại của chính mình, nó đã tự nghiền nát bản thân một cách hoàn toàn, triệt để. Thượng đế đã chết, và chính cái chết của ngài là sự sống của thế giới."
> — Philipp Mainländer

8 bình luận

 
winmain 2026-02-06

Loại 1 và 2 thì từ lâu đã hết hy vọng rồi,
đó là những lập trình viên không có tố chất,
và chỉ những người đơn thuần dừng lại ở ý thức làm nghề
mới cảm thấy khủng hoảng thôi... ngay từ đầu đã là kiểu lười
suy nghĩ rồi mà..

Với kiểu thứ 3 thì đây lại là món quà đáng mừng.
Kiểu thứ 3 vốn đã tận dụng rất tốt rồi mà?

Có công cụ mới ra thì chẳng phải họ hào hứng dùng rất giỏi sao?

Lúc đầu tôi đã thử nghiệm với mã win32.
Nhưng đúng như dự đoán... nó chỉ ở mức
Automation Interface
thôi.
Tôi đã nghĩ rằng với thứ kiểu này thì thiết kế phần mềm chất lượng cao vốn đã không còn hy vọng.
Rồi tôi nghĩ xem làm sao để tận dụng nó nhiều nhất có thể.
Nhưng ở mức này vẫn có rất nhiều thứ để dùng.

Cái này cũng vậy, nếu chịu suy nghĩ và trăn trở thì chẳng khác nào mọc thêm tay chân... vấn đề là người ta thậm chí còn không buồn nghĩ đến điều đó.

 
savvykang 2026-02-05

Trong 5 ngày làm việc, tôi dành một ngày không dùng LLM trong giờ làm, còn Chủ nhật thì hoàn toàn không dùng LLM, và thấy cũng ổn.

 
hpark 2026-02-06

Có vẻ đây không phải là một bình luận thể hiện sự tôn trọng.

 
ahwjdekf 2026-02-05

Nếu muốn làm cho đoạn mã do AI tạo ra tốt hơn, chẳng phải chỉ cần kết hợp thêm bước build và suy nghĩ song song sao?

 
aeolian21 2026-02-05

Trong các hệ thống khổng lồ cấp doanh nghiệp, quá trình chọn mô hình xử lý phù hợp và chọn cách xây dựng pipeline vẫn cho thấy AI còn khá đáng tiếc về độ hoàn thiện, nên có lẽ tốt hơn là chuyển sự chú ý sang việc thiết kế kiến trúc.
Tất nhiên, điều đó cũng sẽ kéo dài được bao lâu thì chưa biết...

Hoặc là giải tỏa nhu cầu bằng cách giải những bài toán thuật toán khó, còn với business thì tiếp cận theo hướng thực dụng thôi, chứ cũng chẳng còn cách nào khác.

 
pencil6962 2026-02-05

Giống như đan len vẫn tồn tại như một sở thích ngay cả trong thời đại máy móc dệt quần áo, có lẽ lập trình như một thú vui cũng vẫn có thể tồn tại.

 
pluto 2026-02-05

Theo suy nghĩ rất cá nhân của tôi
Có lẽ ta có thể “cherry-pick” niềm vui của cả builder lẫn thinker.

Giờ đây đã có thể tạo ra thứ gì đó hoạt động với chi phí hoàn toàn thấp (ít thời gian),
và vẫn có thể tận hưởng niềm vui khi người dùng sử dụng nó, niềm vui vì đã giải quyết được vấn đề trong đời sống thực.

Nếu dùng khoảng thời gian tiết kiệm được để dồn vào những vấn đề cần suy nghĩ sâu (thực ra tôi cũng đang làm như vậy)
thì điều đó tự nó cũng có ý nghĩa, và có lẽ cũng mang lại niềm vui theo cách riêng của nó.

 
GN⁺ 2026-02-05
Ý kiến trên Hacker News
  • Bài viết của Aral Balkan vào tháng 3/2025 rất ấn tượng
    Việc lập trình giống như quá trình nặn một cục đất sét thành hình dạng mình mong muốn. Trong quá trình đó, ta học được giới hạn và đặc tính của vật liệu.
    Trước khi bắt tay làm, đó cũng là lúc ta ít biết nhất về thứ mình muốn tạo ra. Thiết kế không chỉ là giải quyết vấn đề mà còn là phát hiện đúng vấn đề.
    Nếu bỏ qua quá trình sáng tạo, ta sẽ đánh mất yếu tố rất con người của việc học hỏi và khám phá. Một tác phẩm do tự tay mình gọt giũa thì ta hiểu tường tận, còn kết quả lấy từ máy bán hàng tự động chỉ là một bản nhái có hình thức tương tự mà thôi

    • Khi lập trình bằng các công cụ dạng agent, phải liên tục thúc đẩy để ý tưởng không bị thoái hóa thành dạng trung bình
      Ý tưởng càng mới, công cụ càng có xu hướng “bình thường hóa” nó, nên cần nỗ lực vượt qua sự kháng cự đó.
      Trong quá trình ấy, ta sẽ xác định rõ ý tưởng của mình là gì và không phải là gì. Khoảnh khắc ngừng thúc đẩy, LLM sẽ phủ lấp tính độc đáo của dự án
    • Tôi nghĩ tất cả chuyện này là một chuỗi các lớp trừu tượng hóa. Không cần tự tay làm OS, compiler hay standard library cũng không sao.
      Công việc của tôi là kết hợp những công cụ đã có để tạo ra thứ mới.
      Việc bỏ qua một phần quá trình sáng tạo không có nghĩa là giá trị của tác phẩm giảm đi.
      Ví dụ, Zelda dùng Havok physics engine, hay một game làm bằng Unreal, đâu vì thế mà kém xuất sắc
    • Trong 30 năm làm việc ở 10 công ty, điều công ty kỳ vọng ở tôi không phải là “viết code” mà là tạo ra giá trị kinh doanh
      Tôi cảm thấy tự hào về thành quả tạo ra trong 3 tuần gần đây khi kết hợp Codex, Claude và các phiên test.
      Trước đây mục tiêu là hiện thực hóa ý tưởng, còn bây giờ mục tiêu là làm khách hàng hài lòng và đảm bảo tiến độ, ngân sách
    • Ta cũng có thể bước lên một tầng cao hơn. Thay vì tự nặn đất sét, ta có thể đặc tả (specify) từng bộ phận và để máy móc tạo ra chúng
      Làm vậy có thể xây dựng những hệ thống phức tạp gồm hàng nghìn bộ phận.
      Trước đây vai trò này từng do cơ cấu công ty đảm nhiệm — tầng trên đưa ra đặc tả, tầng dưới làm ra các bộ phận
    • Như Michelangelo từng nói ông “gọt bỏ những phần không phải David”, công việc luôn bị ảnh hưởng bởi chính phương tiện thể hiện
      Trước đây người ta có thể nhận ra rất nhanh một website làm bằng Ruby on Rails.
      Nếu giao việc cho con người hay agent mà không hiểu đặc tính của phương tiện, sẽ sinh ra khác biệt giữa code sạch và code không thể bảo trì
      Cuối cùng trách nhiệm vẫn thuộc về người ra chỉ thị. Nếu không có kinh nghiệm với phương tiện đó thì tức là chưa sẵn sàng để đánh giá kết quả
  • Với tôi chỉ là giảm bớt việc gõ phím, còn cách suy nghĩ thì vẫn y như cũ
    Công cụ đã tốt hơn, nhưng lập trình vẫn là lập trình.
    Dù băng qua sa mạc bằng lạc đà hay bằng trực thăng, cuối cùng hành trình vẫn là hành trình.
    Công cụ có tiến bộ cũng không làm bản chất thay đổi

    • Nhìn các bình luận dưới bài này, tôi ngạc nhiên vì thái độ thậm chí không hề cố gắng thấu hiểu trải nghiệm của nhau
      Có vẻ mọi người quên rằng những trải nghiệm khác nhau hoàn toàn có thể cùng tồn tại.
      Bình luận kiểu “tôi không muốn suy nghĩ” đặc biệt gây ấn tượng
    • Bay qua sa mạc bằng trực thăng không sai, nhưng đó không phải cùng một trải nghiệm với người tự mình đi bộ
      Tiến lên lớp trừu tượng hóa tiếp theo là điều tốt, nhưng cũng phải thừa nhận những giá trị bị mất đi trong quá trình đó
    • Tôi hiểu điều tác giả muốn nói. Chúng ta nhớ thời còn phải cân nhắc từng chi tiết nhỏ
      LLM chỉ là một bước tiến hóa của công cụ, nhưng việc mất đi quá trình tư duy tinh vi vẫn khiến người ta tiếc nuối
    • Nhưng lập trình bằng LLM không chỉ là trừu tượng hóa đơn thuần.
      Nó gần với việc sai người khác làm rồi kiểm tra lại hơn.
      Những người vốn ghét lập trình có thể sẽ hoan nghênh, nhưng khó mà gọi đây là “lập trình”
    • Sau khi code bằng agent, tôi có cảm giác mô hình tinh thần bị yếu đi
      Khi tự tay viết code, các cấu trúc dữ liệu hiện lên rõ ràng trong đầu, còn khi agent làm thay thì cảm giác đó biến mất.
      Với tôi, commit code mà không hiểu nó thì không có giá trị
  • Việc xem coding bằng LLM là tương đương với các lớp trừu tượng hóa cũ là một phép so sánh sai
    Compiler hay framework hướng tới trừu tượng hóa không rò rỉ, còn LLM về bản chất là có rò rỉ
    Cuối cùng việc tìm và sửa bug vẫn là phần việc của con người.
    LLM đã đưa trở lại chính sự bất định và rủi ro mà ta từng muốn tránh

    • LLM coding rốt cuộc là quá trình giải nén prompt thành code
      Nếu không nêu rõ mọi biến số trong prompt, kết quả sẽ chỉ là thứ trung bình.
      Tôi nghi ngờ liệu ngôn ngữ tự nhiên có thực sự phù hợp để chứa loại thông tin này hay không
    • LLM hiện nay giống một thực tập sinh còn vụng về. Nhưng nếu chuyên gia con người có thể tạo ra code không rò rỉ, thì biết đâu một ngày nào đó LLM cũng làm được
    • LLM là phi định tính, nên thứ cần quản lý phiên bản không phải đầu vào mà là kết quả đầu ra
      Đây không phải trừu tượng hóa mà là sinh code phi định tính
    • Nếu C compiler thỉnh thoảng không hoạt động, có lẽ chúng ta cũng chỉ tiếp tục nhấn nút build mà thôi
      Ở điểm này, LLM cũng tác động khác đến cách con người suy nghĩ
    • Có vẻ nhiều lập trình viên chưa thực sự hiểu đúng ý nghĩa của “trừu tượng hóa”
  • Tôi là kiểu “người thích suy nghĩ” (thinker) nên không quá hứng thú với AI coding
    Tự tay làm OS kernel hay graphics engine mới là niềm vui của tôi.
    Với tôi, quá trình giải bài toán mới là sở thích và phần thưởng, hơn cả kết quả cuối cùng
    Trong khi đó, những builder lại phấn khích vì AI giúp họ tạo ra thứ gì đó nhanh hơn

    • Nhưng cách phân loại “builder = không suy nghĩ” là sai
      Mọi kỹ sư đều là người suy nghĩ. Chỉ là mục đích dùng công cụ khác nhau mà thôi
  • Với góc nhìn của người đã code suốt nhiều thập kỷ, công cụ AI mang lại sự tự do
    Có thể nhanh chóng thử nghiệm những ý tưởng trước đây thậm chí còn chưa dám bắt đầu.
    Nhờ đó có thể tận dụng những khoảng thời gian ngắn rời rạc để làm dự án cá nhân

    • Tôi thấy chuyện làm dự án bằng điện thoại khá thú vị. Không biết họ làm thế nào
    • Trong cuộc sống có gia đình, khả năng biến những khoảnh khắc ngắn ngủi thành tiến độ thực sự là điều cực kỳ giá trị
    • Tôi cũng đồng ý với ý kiến này. Phần lớn việc lập trình trước đây chỉ là lãng phí vào boilerplate
      Nhờ AI, giờ ta có thể tập trung vào tư duy thực sự.
      Giờ tôi cảm thấy singularity đang đến gần
    • Chỉ trong nửa ngày buổi chiều cũng có thể thử nhiều cách tiếp cận khác nhau.
      Thất bại thì vẫn là học được điều gì đó, còn nếu thành công thì có thể tập trung vào kiểm chứng chất lượng
  • Suy nghĩ” cũng có nhiều dạng khác nhau
    Có kiểu tư duy tập trung cao độ, và có kiểu suy nghĩ chín dần chậm rãi ở hậu cảnh.
    Cả hai đều là dạng đắm chìm sâu, và đều là thứ rất dễ mất đi trong thời đại AI

    • Với tôi cũng có nhiều kiểu ‘hard thinking’ khác nhau
      Giải toán, suy tư triết học, hay các ràng buộc phức tạp trong công việc thực tế đều mang lại những kiểu căng thẳng trí tuệ khác nhau
      Cuối cùng điều quan trọng là, dưới bất kỳ hình thức nào, đó vẫn là trải nghiệm đắm chìm ở chiều sâu
  • Nhìn những kỹ sư senior quanh tôi, tôi thấy có hai nhóm
    Một số người có tăng năng suất đôi chút, nhưng cũng có người bị giảm độ sâu trong tư duy
    Họ thường copy-paste nguyên câu trả lời do LLM đưa ra.
    Vấn đề thật sự là thiếu khả năng đặt câu hỏi cho đúng

    • So với implementation, chi phí giao tiếp mới là vấn đề lớn hơn.
      Với những hệ thống đã trưởng thành, tỷ lệ này thường chiếm hơn 90%
  • Tôi thấy tiếc khi các đồng nghiệp kỹ sư mê mẩn AI đến mức bán rẻ bản chất nghề nghiệp của mình
    Chúng ta từng nắm trong tay tư liệu sản xuất, vậy mà giờ lại tự nguyện từ bỏ

    • Trong ngắn hạn có thể sẽ có thất nghiệp, nhưng nhu cầu phần mềm là vô hạn
      Nhờ AI mà phát triển phần mềm rẻ hơn và nhanh hơn, thị trường ngược lại còn có thể mở rộng hơn
    • Vừa tin AI vừa phản đối nó là một thái độ mâu thuẫn.
      Tiến bộ công nghệ lúc nào cũng khiến một số nghề bất lợi hơn, nhưng lại mang đến tiến bộ cho toàn xã hội
      Cũng như trước đây chính chúng ta dùng tự động hóa để làm giảm việc làm ở các ngành khác, giờ chỉ là đến lượt mình mà thôi
    • Vấn đề nằm ở những kẻ thực dụng chỉ theo đuổi hiệu suất mà không có giá trị
      Kết quả của nó chỉ là sự trống rỗng. Nhưng có lẽ với họ thì chính điều đó cũng đã là mục tiêu
    • Tầng lớp này giống như quá trình tiểu tư sản bị tầng lớp tư sản lớn hơn hấp thụ
    • Đây là hệ quả của chủ nghĩa kỹ trị thiếu vắng đạo đức và triết học
      Lối nghĩ “làm được thì cứ làm” khiến con người đánh mất tính người
  • Không phải AI làm biến mất tư duy. Vấn đề là những công ty tầm thường và lối suy nghĩ tầm thường
    Cần tìm đến những công ty thực sự coi trọng tư duy thực sự

  • Tôi cũng code với LLM nhưng vẫn suy nghĩ sâu
    Tôi vẫn cân nhắc thiết kế, rủi ro, ràng buộc, technical debt, các phương án thay thế

    • Nhưng suy nghĩ cùng LLM là một kiểu suy nghĩ khác
      Nó gần với dạng tư duy quản lý, phải qua lại giữa nhiều ngữ cảnh và điều phối chúng,
      khác với kiểu tư duy của nhà khoa học có thể đắm mình vào một vấn đề trong nhiều ngày
    • Tôi cũng có trải nghiệm tương tự. Nhờ LLM mà việc code dễ hơn, nhưng việc xác minh và review lại khó hơn nhiều
      Đặc biệt, các PR của junior dùng AI ngày càng dài và phức tạp hơn,
      và giờ phần lớn công việc của tôi đã chuyển sang lấy review làm trung tâm
    • LLM hiệu quả nhất khi dùng cho các tác vụ lặp lại ở đơn vị nhỏ
      Nó hữu ích cho prototyping nhanh, helper function, code autocomplete, khám phá thư viện, v.v.
    • Dù dùng Claude Code để sinh 100% code, tỷ lệ tư duy sâu của tôi vẫn cao
      Thậm chí vì các việc đơn giản giảm đi nên tôi còn suy nghĩ nhiều hơn
    • Nhưng sau LLM, vòng lặp phản hồi với bản thân code đã biến mất
      Trước đây việc viết code buộc ta phải nhìn lại tư duy thiết kế ở tầng cao hơn,
      còn bây giờ quá trình đó giảm đi, khiến ta suy nghĩ ‘ít sâu hơn’