# Dùng REA để xem các team thật build phần mềm thế nào

[Nate B Jones](https://homus.dev/speakers/nate-b-jones) · [AI News & Strategy Daily | Nate B Jones](https://homus.dev/orgs/ai-news-strategy-daily-nate-b-jones)

> REA cho Claude Code hay Codex mổ xẻ phần mềm có sẵn (Aegis, Notion, Windows Calculator, QuickBooks) để bạn hiểu requirement thật trước khi build.

Topics: Coding Agents, Dev Tools, Workflow

Canonical: https://homus.dev/talks/your-vibe-coded-app-can-look-right-and-fall-apart-after-launch-rea-shows-you-how-real-teams-build

## 1. REA và khoảng cách giữa yêu cầu và cách phần mềm được build

Nate mở đầu: có thể bạn đã thấy REA bùng nổ trong tháng này, cũng có thể bạn đã bỏ lỡ, nhưng dù sao thì đây là thứ đáng để ý. REA là viết tắt của Reverse Engineer Anything. Project này lên tới hơn 100.000 sao trên GitHub chỉ trong vài ngày, và những ý kiến ồn ào nhất thì nói rằng phần mềm thế là xong rồi. Nate không nghĩ vậy.

Theo anh, bạn biết chính xác mình muốn phần mềm làm gì. Thứ bạn chưa bao giờ nhìn thấy được là một team thật đã biến loại mong muốn đó thành một thứ thực sự chạy được như thế nào. Khoảng cách giữa business requirement và cách một thứ được ráp lại với nhau là một trong những bài toán khó nhất của ngành công nghệ. Đó là lý do rất nhiều thứ người ta vibe-code trông thì đúng nhưng vỡ ra ngay sau khi launch.

![Nate B Jones bên cạnh thẻ giới thiệu REA: Reverse Engineer Anything, Open Source, Claude Code và Codex](https://homus.dev/photos/PseF3LyXQ04-0043.jpg)

Thẻ giới thiệu trên màn hình: REA (Reverse Engineer Anything) là open source, dùng với Claude Code và Codex, repo trên GitHub là morluto/rea.

REA lấp một mảng lớn của khoảng cách đó. Nó cắm vào Claude Code hoặc Codex, và cho AI của bạn mở một phần mềm trên máy tính ra để chỉ cho bạn thấy nó thực sự được build thế nào. Nate nhấn mạnh: bạn không clone của ai cả. Bạn đang học từ những người đã làm phần suy nghĩ khó, để bạn học cách build phần mềm tốt hơn.

Có hai cách dùng rất khác nhau. Nếu bạn build phần mềm, REA là một máy tăng tốc (accelerator). Nếu bạn không build phần mềm, nó là một máy chụp X-quang (x-ray machine). Nate hứa sẽ cho xem cả hai, và bắt đầu với cách mà đa số mọi người đang bỏ sót.

Hãy nghĩ tới app authenticator trên điện thoại, chắc bạn cũng có một cái. Sáu chữ số hiện ra, đồng hồ đếm ngược nhỏ chạy hết, rồi các con số đổi. Có lẽ bạn dùng thứ như vậy để đăng nhập tài khoản công việc. Nhưng con số đó từ đâu ra? Cái gì làm nó đổi? Nếu muốn làm một công cụ như thế, bạn thực sự phải build những gì?

## 2. Ví dụ đầu tiên: mã sáu số của app authenticator Aegis

REA có một cuộc điều tra (investigation) đã công bố về Aegis, một app authenticator cho Android. Họ lấy gói ứng dụng đã phát hành (application package) và lần theo đoạn code sinh ra các con số đó. Phép tính kết hợp một account key với thời gian hiện tại, được gom thành các khoảng 30 giây. Về cơ bản, nó cho bạn thấy cách mọi thứ vận hành: cùng một key trong cùng một khoảng thời gian có thể cho ra cùng một mã. Sau đó họ làm một bản demo nhỏ, trong đó bạn có thể dịch chuyển đồng hồ và nhìn kết quả thay đổi.

![Slide How The Code Works: Account Key, Time 30-Second Blocks, 6-Digit Code](https://homus.dev/photos/PseF3LyXQ04-0143.jpg)

Slide tóm cơ chế mà cuộc điều tra Aegis tìm ra: account key cộng với thời gian chia thành từng khối 30 giây cho ra mã sáu số; dòng dưới ghi cùng key và cùng khối thì cùng mã.

Nate nói rõ: điểm chính ở đây không phải là bạn muốn build một app authenticator. Điểm chính là bạn có thể lấy những ví dụ phần mềm tầm thường nhất, những thứ bạn vẫn luôn thắc mắc "cái này chạy thế nào", "mình muốn làm một cái giống vậy nhưng chỉn chu hơn" hay "giống vậy nhưng hơi khác một chút", và giờ thì bạn hiểu nó vận hành ra sao.

Bạn có thể đi từ chỗ nhìn sáu chữ số bí ẩn tới chỗ thực sự hiểu và mổ xẻ được mối quan hệ sinh ra sáu chữ số đó. Bạn có thể hỏi phần nào phụ thuộc vào đồng hồ, phần nào phụ thuộc vào tài khoản (trên màn hình lúc này có thẻ "Key + Time": đồng hồ đổi thì mã đổi, tài khoản thì giữ nguyên key). Bạn có một implementation thật của bất cứ thứ gì bạn muốn. Không nhất thiết phải là app authenticator, không nhất thiết phải là app lịch, mà có thể là bất cứ thứ gì trên web để bạn xem xét trong lúc agent giúp bạn hiểu nó.

## 3. X-ray cho mọi phần mềm, và chuyện "death of software"

Đó là thứ Nate thấy hứng thú. Nó giống như có được tầm nhìn X-quang (x-ray vision) cho toàn bộ phần mềm trong thế giới máy tính. Mọi thứ bạn tương tác hằng ngày đều chứa những quyết định mà ai đó đã đưa ra. Và giờ bạn có cách để bắt đầu nhìn thấy những quyết định đó một cách chi tiết. Bạn có thể đặt câu hỏi về chúng, bạn có thể học từ chúng. Nate nhấn mạnh: đúng, là bạn, kể cả khi bạn chưa từng viết một dòng code nào.

Và đã có người dùng REA cho những project lớn hơn rất, rất nhiều. App authenticator chỉ là một ví dụ ngớ ngẩn. Bạn có thể đi lớn hơn nhiều: một developer đã dùng REA để điều tra một số phần của QuickBooks Desktop, rồi build một ứng dụng kế toán độc lập. Nate hẹn sẽ quay lại xem việc đó thực sự gồm những gì, vì phần thú vị nằm ở chỗ cuộc điều tra đã giúp nối hành vi của phần mềm với công việc build một thứ khác ra sao.

Người ta đang gọi REA là cái chết của phần mềm (the death of software). Nate than: chúng ta đã nghe câu đó bao nhiêu lần rồi, anh phát mệt với nó. Anh cho rằng cách nói đó bỏ qua một sự thật: rất ít người hiểu phần mềm họ đang dùng, nói gì tới phần mềm họ đang cố build. Cho nhiều người hơn một cách để có được sự hiểu biết đó là một điều tích cực.

## 4. Hai việc REA làm cho non-developer, một câu hỏi cho developer

Đây là chuyện lớn, nhất là bây giờ khi một agent có thể viết rất nhiều code thay bạn. Bạn vẫn cần một cách nào đó để biết code nên làm gì. Và với một non-developer, REA cho bạn một lợi thế lớn.

Nate còn đi xa hơn: với non-developer, anh thấy REA làm hai việc then chốt. Thứ nhất, hiểu phần mềm bạn muốn build: các thành phần là gì, bên trong cần xảy ra những gì (phần anh vừa nói ở trên). Thứ hai, hiểu vì sao một implementation lại đưa ra những lựa chọn engineering như vậy, để bạn quyết định lựa chọn nào nên có trong implementation của mình.

Với developer, câu hỏi thường hẹp hơn: họ làm cái đó bằng cách nào? Cách đó có giải quyết được vấn đề của mình không? Mình có đi nhanh hơn được nhờ học cách đó không? "Được rồi, giờ mình hiểu rồi, bắt đầu thôi", hoặc như cách mọi chuyện diễn ra trong năm 2026, "bảo AI của mình bắt đầu thôi".

Cùng một công cụ, nhưng điểm xuất phát về kiến thức khác nhau thì cách dùng khác nhau: hai việc cho non-developer, một câu hỏi hẹp cho developer.

Bài học rút ra, theo Nate: cùng một công cụ là REA, nhưng với lượng kiến thức ban đầu khác nhau, bạn dùng nó khác nhau. Như mọi nhạc cụ, bạn phải học cách dùng nó cho tốt.

## 5. Một công cụ research của riêng bạn: bốn câu hỏi chưa có lời đáp

Để cụ thể hơn về REA trong thực tế, Nate đưa ra một tình huống. Giả sử bạn muốn làm một công cụ cho việc research của chính mình. Bạn muốn gom các đoạn trích từ nhiều tài liệu khác nhau, đặt ghi chú của mình bên cạnh, và tìm lại được mọi thứ khi ngồi xuống viết. Bạn không muốn một cái bàn bừa bộn. Bạn hiểu công việc đó. Bạn biết những công cụ đang dùng làm mình bực ở chỗ nào. Như vậy là đủ lý do chính đáng để build một thứ.

Nhưng hiểu công việc không tự động cho bạn biết nó nên được biểu diễn (represented) trong phần mềm như thế nào. Nate nói anh không thể nhấn mạnh điều này đủ. Một đoạn trích có phải chỉ là chữ trên một trang không? Hay nó là một object riêng có gắn nguồn? Khi bạn copy nó sang một project khác, những gì phải đi theo nó? Nếu bạn sửa bản copy, bản gốc có đổi theo không?

![Slide Four Questions: Just text, An object with a source, What travels when you copy, Edit the copy](https://homus.dev/photos/PseF3LyXQ04-0503.jpg)

Bốn câu hỏi trên slide: chỉ là text? một object có nguồn? copy thì cái gì đi theo? sửa bản copy thì bản gốc có đổi không?

Đó là những technical requirement thật mà bạn sẽ phải tự khám phá, và mỗi câu trả lời sẽ đẩy bạn về một hướng lựa chọn kỹ thuật khác nhau. Nate kể đây là chỗ mà nhiều người, khi anh đứng nhìn qua vai họ làm việc, bị sa lầy. Nó thực sự khó, cực kỳ khó.

Bạn không phải lúc nào cũng có thể nghĩ xong hết mình muốn gì rồi giao bộ requirement hoàn chỉnh cho người khác, vì đôi khi bạn khám phá ra nó trong lúc làm. Đôi khi chính việc nhìn thấy một hệ thống vận hành ra sao mới giúp bạn nhận ra requirement ngay từ đầu. Bạn không biết một sự phân biệt nào đó quan trọng, cho tới khi bạn thấy nó mở ra khả năng gì, và lúc đó nó mới trở nên quan trọng. Nate nói chính anh đã là người như vậy suốt hơn mười năm, đứng nhìn qua vai các developer, và REA là thứ mà ngày đó anh sẵn sàng đánh đổi mọi thứ để có.

## 6. Notion copy và paste như thế nào

Cuộc điều tra Notion của REA cho một ví dụ rất cụ thể. Nó bắt đầu từ một thao tác bình thường: bạn copy một thứ gì đó. REA giúp tìm ra giao diện clipboard mà ứng dụng desktop để lộ ra (exposed clipboard interface), rồi đọc phần code xung quanh để xem giao diện đó nối vào hệ thống thế nào. Cuộc điều tra cũng xem xét phần code web editor đã lưu, để hiểu một lần copy có thể giữ lại cấu trúc block phong phú hơn của Notion ra sao.

Trong phần code đó, Notion gửi text và HTML lên clipboard. Nó cũng giữ dữ liệu block có cấu trúc (structured block data) ở local, và đặt một identifier vào trong HTML. Vì vậy khi bạn bấm paste, identifier đó có thể nối lại nội dung nhìn thấy được với cấu trúc đã lưu. Bài test module được ghi lại cho thấy dữ liệu block phong phú quay về khi các identifier khớp nhau. Tất cả những điều này có được là vì đã dùng REA để hiểu Notion làm việc đó thế nào.

![Slide What A Copy Keeps: Clipboard Text + HTML + ID, Notion Block Data Kept Locally, Paste ID Matches, Block Data Comes Back](https://homus.dev/photos/PseF3LyXQ04-0623.jpg)

Slide tóm ca Notion: clipboard nhận text, HTML và một ID; Notion giữ block data ở local; khi paste mà ID khớp thì block data quay về.

## 7. "Copy paste phải chạy" thật ra nghĩa là gì

Giờ hãy xem điều đó dạy bạn gì về cái app research đang nói tới. Trước đây, có thể bạn đã bảo agent của mình: "make sure copy and paste works", hãy đảm bảo copy và paste chạy được. Một yêu cầu cực kỳ hợp lý, nhưng nó nghĩa là gì? Đoạn trích có tới nơi không? Đường link về nguồn có tới nơi không? Ghi chú bạn gắn kèm có tới nơi không? Bạn quan tâm tới những chi tiết đó đến mức nào?

Chính những chi tiết này làm phần mềm có cảm giác chỉn chu (polished). Bạn có thể có đủ chữ trên màn hình mà vẫn thiếu một thứ bạn quan tâm sâu sắc, và có khi bạn không hề biết cho tới khi đã build xong. Nate gọi đó là lời nguyền của dân vibe coder suốt hơn một năm nay. Giờ bạn có thể có một cuộc trò chuyện phong phú hơn nhiều, trước khi build xong cả cái editor. REA làm điều đó thành khả thi.

Bạn đang khám phá thông tin của mình cần có những gì để hoạt động hiệu quả trong môi trường máy tính. Nếu mối quan hệ giữa một đoạn trích và nguồn của nó là quan trọng, bạn sẽ cần tìm cách giữ mối quan hệ đó. Bạn có thể nhờ agent chỉ cho một cách đơn giản để biểu diễn nó, rồi hỏi tiếp việc copy biểu diễn đó sẽ đòi hỏi những gì.

Tất cả những điều đang nói ở đây đều ảnh hưởng tới technical stack bạn chọn. Một editor xử lý một trang text thuần cho bạn một điểm xuất phát. Một editor cần giữ riêng các đoạn trích, ghi chú và các mối quan hệ cho bạn một điểm xuất phát hoàn toàn khác, phức tạp hơn nhiều. Cách bạn lưu thông tin phải hỗ trợ được những gì bạn muốn làm với nó. Nate gọi đó là một bài học lớn hơn của năm 2026: bạn đang học cùng lúc nên yêu cầu gì và công nghệ cần hỗ trợ gì.

![Slide Two Editors: Plain Text, one starting point; Quotes + Notes + Relationships, a different starting point](https://homus.dev/photos/PseF3LyXQ04-0743.jpg)

Hai editor, hai điểm xuất phát: text thuần là một chuyện, còn đoạn trích cộng ghi chú cộng các mối quan hệ là một điểm xuất phát khác hẳn.

## 8. Mọi thành phần trong ý tưởng của bạn đều đã có người làm

Nếu bạn nghĩ không có thành phần nào trong ý tưởng của mình giống với phần mềm có trước, Nate có tin cho bạn: chúng có giống. Có thể bạn có một tổ hợp nhu cầu rất riêng. Workflow của bạn có thể khác thường. Nhưng anh cam đoan rằng đã có người làm về editor, về lưu trữ tài liệu, về search, về copy, về liên kết, về chuyển thông tin giữa các nơi, bất cứ thứ gì trong môi trường máy tính. Đã có người làm về nó. Bạn có thể học từ những lời giải đó trong lúc tìm ra lời giải của mình, dù chủ đề của bạn là gì. Nate nói anh rất tự tin về điều này.

Hãy để ý rằng bạn không cần đến với hiểu biết đầy đủ mọi chi tiết, hay biết cụm từ "structured block data" nghĩa là gì. Tất cả những gì bạn cần mang theo là: "tôi tò mò, và tôi muốn hiểu thứ mình đang làm và đang build". Rồi bạn tiếp tục chất vấn bằng REA cho tới khi tự hiểu được mối liên hệ.

## 9. Việc thứ hai: hỏi vì sao, và những hidden cost

Đó thực sự là việc thứ nhất của bạn: hiểu thứ mình đang cố build. Việc thứ hai bắt đầu khi bạn hỏi vì sao ai đó lại sắp xếp mọi thứ theo cách này, và kiên trì tò mò, vì điều đó dẫn bạn tới insight của riêng mình, tức là thứ bạn muốn làm khác đi.

Lấy luôn thiết kế clipboard làm ví dụ. Vì sao lại có text và HTML thông thường, đồng thời có thêm một biểu diễn riêng, phong phú hơn? Hãy nghĩ xem mỗi thứ cho phép làm gì. Các ứng dụng khác có thể làm được gì đó với text. Còn ứng dụng của bạn có thể biết về các mối quan hệ và các tính năng chỉnh sửa. Nếu bạn đang thiết kế một công cụ research, bạn phải tìm ra trong tất cả những requirement khác bạn đã nghiên cứu, bao nhiêu phần sống sót qua một thao tác copy paste.

Nate kể copy paste đang rất nóng trong đầu anh, vì vài tuần trước anh vừa kể với khán giả chuyện anh đã build một active clipboard manager, nên anh đã nghĩ kỹ về những chuyện này. Anh ước gì lúc đó REA đã ra mắt, chắc hẳn sẽ vui lắm.

Sau đó REA cũng giúp chúng ta hỏi về những chi phí ẩn (hidden cost) của phần mềm. Nếu thông tin phong phú hơn của bạn phụ thuộc vào một mục dữ liệu được lưu ở local, chuyện gì xảy ra khi mục đó mất đi? Chức năng delete là gì? Thông tin chết này đi đâu? Chuyện gì xảy ra khi nội dung được chuyển sang một máy khác? App của bạn có cần nhét thêm thông tin vào nội dung được copy không? Một bản export riêng có phải lựa chọn tốt hơn không?

![Slide Hidden Costs: Saved entry gone, Another computer, Put more in the copy, A separate export](https://homus.dev/photos/PseF3LyXQ04-1003.jpg)

Bốn câu hỏi hidden cost trên slide: mục đã lưu bị mất thì sao, sang máy khác thì sao, có nhét thêm vào bản copy không, hay làm một bản export riêng.

Về cơ bản, bạn có thể tìm ra những ngõ cụt trong phần mềm, hoặc thậm chí cái Nate gọi là bug trong phần mềm mà bạn không muốn lặp lại. Đó đều là những câu hỏi để bạn suy nghĩ qua trong thiết kế của mình, được gợi ra từ một implementation đã quan sát được.

## 10. Bạn đang tham gia một cuộc trò chuyện engineering

Lần đầu tiên, chúng ta có thể lập luận về hệ quả mà không phải giả vờ rằng mình biết hết mọi thứ từ trước. Nếu team gốc có công bố một bài giải thích, điều mà họ gần như không bao giờ làm, thì tuyệt. Nhưng chúng ta không cần điều đó. Chúng ta chỉ cần nhờ agent hiểu code và cùng mình diễn giải nó. Bạn có thể làm việc đó với Codex, với Claude.

Dù muốn hay không, giờ bạn đang tham gia một cuộc trò chuyện engineering. Bạn có thể nói: "tôi cần nguồn được giữ lại khi gửi đoạn trích này cho một đồng nghiệp, kể cả khi họ không dùng app của tôi". Hoặc bạn có thể nói: "cái này chỉ cần chạy trong workspace của tôi, một cách đơn giản hơn là quá đủ". Cách nào cũng được, tùy bạn. Bạn hiểu rõ hơn mình đang yêu cầu gì và implementation phải giữ lại những gì.

Hai câu bạn có thể nói với agent sau khi hiểu cơ chế copy của Notion; mỗi câu dẫn tới một implementation khác nhau.

Nate tóm lại: bạn trở nên thông minh hơn trong vai trò người dẫn dắt AI (a leader for AI), một chủ đề lớn khác của năm nay.

## 11. Nút phần trăm của Windows Calculator

Có một ví dụ REA khác làm vấn đề này rõ tới mức gần như buồn cười: nút phần trăm trong Windows Calculator. Nhập 200 cộng 10%, bạn được 220. Nhập 200 nhân 10%, bạn được 20. Cùng một nút, ngữ cảnh khác nhau.

![Slide Same Button, Different Context: 200 + 10% = 220, 200 × 10% = 20](https://homus.dev/photos/PseF3LyXQ04-1123.jpg)

Cùng một nút phần trăm cho hai kết quả: 200 + 10% = 220 và 200 × 10% = 20.

Nếu điều tra chuyện đó, và REA đã làm, bạn sẽ thấy thư viện calculator đã cài và nhánh code khôi phục được (recovered branch) đứng sau hành vi đó giúp bạn hiểu nó đang làm gì. Sau một phép cộng, 10% trở thành 10% của số thứ nhất. Sau một phép nhân, nó dùng phép toán bạn đã chọn để quyết định theo ngữ cảnh nút đó nghĩa là gì khi bạn bấm.

Hãy tưởng tượng bạn đặc tả tính năng đó cho một AI builder, với một thứ đơn giản như máy tính bỏ túi. "Tôi cần một nút phần trăm." Được thôi, agent có thể cho bạn một cái. Nhưng cho tới khi bạn nghĩ qua những tình huống khác nhau đó, bạn chưa thực sự đặc tả hành vi thật. Một tấm screenshot sẽ không sửa được chuyện đó. Nhìn vào một implementation đang chạy có thể cho bạn biết mình đang thiếu gì: rằng phần trăm có ý nghĩa theo ngữ cảnh, và bạn phải nối khả năng nhận biết ngữ cảnh đó vào máy tính.

Và điều này áp dụng cho những quyết định lớn hơn nhiều. Khi bạn nói "gửi một reminder", đồng hồ bắt đầu chạy từ lúc nào? Nate kể anh đã thấy những ví dụ thật về chuyện này, các agent gửi reminder bị trễ vì đồng hồ bắt đầu chạy muộn, nên đây không phải lý thuyết, người ta đang gặp nó trong năm 2026. Hay khi bạn nói "phê duyệt một yêu cầu", những quyền nào thay đổi? Khi bạn nói "undo", bao nhiêu phần công việc nên biến mất?

Hiểu một implementation thật giúp bạn vượt qua cái tính năng kiểu teaser trailer ở mức high level, để đi vào những quyết định làm cho tính năng đó hữu ích. Nate ví nó như việc chúng ta xem teaser trailer của phim Odyssey mà chưa thực sự xem cả bộ phim. Đó là lý do anh không muốn đánh giá thấp những gì đang diễn ra với REA: chúng ta được xem cả bộ phim, được thấy toàn bộ phần mềm.

Đi từ "tôi muốn cái này" tới một bản mô tả khớp với một hệ thống kỹ thuật là một trong những việc khó nhất trong phần mềm. Nếu làm sai, bạn có thể tốn rất nhiều thời gian làm ra một thứ rất chỉn chu nhưng không xử lý được tình huống bạn cần. Một agent có thể giúp bạn khám phá những requirement đó bằng cách nghiên cứu kỹ cách một ứng dụng có sẵn xử lý một bài toán liên quan.

## 12. Ledger Reborn: điều tra QuickBooks Desktop rồi tự build lại

Như đã hứa, Nate quay lại ví dụ QuickBooks, vì chuyện này đang xảy ra vượt xa những bản demo dạy học nhỏ. Một developer trong cộng đồng đã công bố một project tên là Ledger Reborn (Nate khen: tên hay đấy), sau khi điều tra QuickBooks Desktop for Mac bằng REA.

Bài viết của tác giả mô tả công việc tập trung vào số học tồn kho (inventory arithmetic), dấu của ngân sách (budget signs), số dư đối soát (reconciliation balances), và các nhánh code liên quan tới báo cáo theo cash basis. Sau đó họ tự implement độc lập một ứng dụng làm được tất cả những việc đó bằng Python và SQLite. Bản preview mà developer công bố lưu hóa đơn và các payment đã ghi nhận trong một sổ cái local, quản lý tồn kho và tính các báo cáo, tất cả những thứ như vậy.

![Thẻ Python + SQLite về Ledger Reborn: A Preview No Payroll, No Live Bank Connections, REA Evidence + Pseudocode → Independent Build](https://homus.dev/photos/PseF3LyXQ04-1403.jpg)

Thẻ về Ledger Reborn trên màn hình: bản preview viết bằng Python và SQLite, chưa có payroll, chưa kết nối ngân hàng trực tiếp; REA cung cấp evidence và pseudocode, còn phần build là độc lập.

Về cơ bản, REA cung cấp evidence và pseudocode để cho thấy mọi thứ vận hành thế nào, rồi họ làm một implementation độc lập theo đúng những pattern mà họ quan tâm.

Điều làm Nate thích thú là loại câu hỏi họ đã điều tra. Nếu tất cả những gì bạn làm là copy một màn hình kế toán, bạn có thể tái tạo chỗ con số xuất hiện mà không hiểu con số đó được tạo ra thế nào. Trong ca này, cuộc điều tra đi vào các phép tính, đi vào hành vi của sổ cái, và đó là nơi ý nghĩa thật của phần mềm nằm. Đó cũng là phần bạn cần hiểu nếu muốn làm ra một phiên bản dùng được.

## 13. Ghi nhận một payment, domain knowledge, và vì sao đây không phải clone

Hãy nghĩ tới một requirement bình thường như ghi nhận một payment. Payment đó có trả hết cả hóa đơn không? Một payment có thể trả cho nhiều hóa đơn không? Phần nào còn nợ? Báo cáo nên hiển thị gì? Đó đều là những quyết định liên kết với nhau. Bạn cần một cách biểu diễn thông tin có thể hỗ trợ hành vi đó, và bạn cần những bước kiểm tra cho biết kết quả có đúng không.

Khác biệt Nate nhấn mạnh trong ca Ledger Reborn: chép màn hình chỉ cho biết con số xuất hiện ở đâu, còn điều tra hành vi cho biết con số được tạo ra thế nào.

Từ đây có thể thấy vì sao domain knowledge quan trọng đến vậy. Một người xử lý hóa đơn mỗi ngày có thể biết tình huống nào hay gặp và lỗi nào sinh thêm việc. REA cho người đó thêm một cách để nối hiểu biết của mình với những quyết định kỹ thuật bên dưới. Họ có thể điều tra cùng agent và tiếp tục đặt câu hỏi cho tới khi hệ thống được đề xuất thực sự tính tới công việc thật.

Ứng dụng gốc có thể dùng một stack rất, rất khác với stack bạn chọn. Bạn không nhất thiết muốn toàn bộ kiến trúc của nó. Bạn muốn hiểu hành vi quan trọng với mình, và theo Nate thì đó là điều tất cả chúng ta đều muốn.

Chúng ta không nhất thiết cố làm clone ở đây. Chúng ta đang cố làm phần mềm cá nhân quan trọng với mình, hoặc phần mềm cho một nhóm người dùng nhỏ. Đó là lý do bước chuyển từ một sản phẩm desktop được kiểm tra sang một ứng dụng Python và SQLite riêng biệt lại thú vị đến thế: cuộc điều tra dẫn tới một bộ lựa chọn engineering mới. Và bạn có thể làm công việc hữu ích đó mà không đặt mục tiêu thay thế sản phẩm kế toán kia. Nate nói anh cứ nhắc đi nhắc lại điều này vì người ta hiểu sai khi nghĩ rằng đây chỉ là sao chép.

Sản phẩm của bạn có thể chỉ xử lý đúng một việc mà bạn cần trong business. Cơ hội ở đây là hiểu việc cụ thể đó tới mức bạn giải thích được điều gì nên xảy ra, chọn được một implementation phù hợp với nhiều hiểu biết nền, và nhận ra được nó có chạy đúng hay không. Bạn quyết định mình cần build bao nhiêu, và giờ bạn có những lăng kính kỹ thuật để xem xét phần mềm và hiểu cách làm.

## 14. Cho developer: tốc độ của game khủng long

Với developer, chúng ta có thể zoom vào sâu hơn nhiều. Có thể bạn đã biết các cấu trúc dữ liệu, framework, các ràng buộc. Bạn nhìn một tính năng và nghĩ: chính xác thì họ làm ra hành vi đó bằng cách nào? Cho tôi các cơ chế liên quan là tôi đi tiếp được.

Nate thấy ví dụ game khủng long của REA là một minh họa rất hay cho chuyện này. Họ kiểm tra một phiên bản chạy trên trình duyệt, dựng lại từ game khủng long của Chromium, và lấy ra phần JavaScript thực sự được trang web nạp. Câu hỏi là: vì sao game cứ nhanh dần lên? Code bắt đầu với giá trị tốc độ là 6, và cộng thêm một phần nghìn ở mỗi lần update không có va chạm, trong khi tốc độ còn dưới 13. Điều này cho bạn một quy tắc gọn để làm việc, và giải thích được cảm giác khi chơi game.

![Slide The Speed Rule: Start 6, +0.001 Per Update](https://homus.dev/photos/PseF3LyXQ04-1703.jpg)

Quy tắc tốc độ trên slide: bắt đầu ở 6, cộng 0,001 mỗi lần update không có va chạm, với thanh tiến trình minh họa tốc độ tăng dần.

Project dùng quy tắc đó trong một game nhỏ mới có thanh điều chỉnh tốc độ, và bạn thực sự có thể implement nó ngay. Bạn có thể giữ đúng mức tăng tốc đã khôi phục được, hoặc cho nó nhanh hơn để game khó hơn. Dù thế nào, phần so sánh của project thực sự đào vào hành vi nằm bên dưới tấm screenshot, tức hành vi tương tác ở mức code mà bạn cần có, để bạn dùng cho chính mình nếu đang build game riêng. Điều đó cho phép bạn thay đổi chính xác hơn nhiều: có thể bạn muốn tốc độ tăng nhẹ nhàng hơn, có thể không, nhưng bạn được quyết định vì bạn đã nhìn vào bên dưới nắp capo.

## 15. Engineering shift và ca DX-Ball

Câu hỏi cuối ở đây là về chính công việc engineering. Engineering đang ngày càng ít là chuyện "tôi có hiểu được hệ thống không", và ngày càng nhiều là chuyện "tôi muốn cấu hình hệ thống thế nào". REA chỉ làm cho điều đó nhanh hơn. Agent có thể giúp lần theo các dependency, giải thích các quy tắc, implement phiên bản bạn chọn, và cả cuộc điều tra giờ được tăng tốc cho bạn. Nhưng bạn vẫn phải quyết định mình muốn build cái gì.

Phiên bản native code của chuyện này là ca nghiên cứu DX-Ball của REA. Họ lần ra cách vị trí ngang của một viên gạch trở thành giá trị sound pan trái phải bên trong game đã compile. Output ban đầu của decompiler không đầy đủ. Vì vậy cuộc điều tra lần theo các instruction, các caller và các ràng buộc, và bản tái dựng được công bố đã tìm ra một hàm khôi phục được (recovered function) thực sự khớp với bản gốc.

![Slide Horizontal Position → Sound Pan với trục Left, Right](https://homus.dev/photos/PseF3LyXQ04-1823.jpg)

Slide về ca DX-Ball: vị trí ngang của viên gạch trên trục từ trái sang phải được ánh xạ thành sound pan trái phải.

Đó là một câu hỏi cực kỳ tập trung. Bạn không cần tái dựng cả một game để hiểu mối quan hệ đó vận hành ra sao. Nhưng nếu một developer có thể cầm REA và đi tới mức chi tiết đó, thì bạn thực sự có thể hỏi bất cứ điều gì mình muốn. Một non-developer có thể hỏi một câu đơn giản hơn nhiều và vẫn nhận được một lời giải thích tuyệt vời.

## 16. Bảo REA đi sâu tới đâu

Một trong những điều Nate sẽ cân nhắc khi dùng công cụ này là bạn bảo nó đi sâu tới đâu. Nếu bạn đòi một lời giải thích đầy đủ về cả một ứng dụng, bạn sẽ nhận về một lượng tài liệu khổng lồ không giúp gì cho quyết định tiếp theo của bạn. Hãy cho agent một lý do để điều tra, kiểu: "tôi thích hành vi đó, tôi chỉ muốn hiểu kết quả, giúp tôi lần theo phần liên quan".

Lời đề nghị của Nate cho người dùng REA: hãy nói cho nó biết đi sâu tới đâu, hãy bảo cái kính hiển vi của bạn tập trung vào cái gì. Với một non-developer, anh sẽ bắt đầu bằng việc mô tả công việc mà mình muốn phần mềm hỗ trợ, rồi nhờ agent nhận diện các thành phần quen thuộc và đào sâu vào chúng giúp mình. Bạn có thể tiếp tục đào quanh và hiểu dần các thuật ngữ, thậm chí nhờ nó vẽ diagram cho mình.

![Slide How To Ask: Non-developer và Developer](https://homus.dev/photos/PseF3LyXQ04-1943.jpg)

Cách hỏi trên slide: non-developer mô tả công việc, tìm các thành phần quen thuộc rồi đào sâu; developer mô tả ràng buộc của mình, tìm implementation rồi implement.

Với developer, bạn có thể mô tả tình huống trong các ràng buộc của mình chính xác hơn: tìm implementation này, giúp tôi hiểu các dependency này, đây là chỗ tôi đang kẹt, giúp tôi tìm vài ví dụ ở đây, rồi giúp tôi implement. Đó có thể là một cuộc điều tra rất ngắn và sắc khi câu hỏi hẹp. Về cơ bản, đừng đốt token nếu không cần, và Nate nói đó là lời khuyên lúc nào cũng đúng của anh.

## 17. Bắt đầu: setup chính thức và giới hạn client-side

Để bắt đầu, bạn chỉ cần kết nối REA với một coding agent như Claude hoặc Codex, như anh đã nói từ đầu. Bạn cũng nên biết là có một bước setup chính thức. Nó dùng Node.js, dùng npm, và các loại mục tiêu khác nhau cần các công cụ kiểm tra (inspection tools) khác nhau. Thẻ trên màn hình ghi lệnh setup chính thức và dòng "Needs Node.js + npm":

```
npx rea-agents@latest setup
```

![Thẻ Official Setup với lệnh npx rea-agents@latest setup, Needs Node.js + npm](https://homus.dev/photos/PseF3LyXQ04-2003.jpg)

Thẻ Official Setup: một lệnh npx để cài REA vào agent, kèm ghi chú cần có sẵn Node.js và npm. README của repo ghi dạng ngắn `npx rea-agents setup`.

Trong lúc cài, sẽ có những chỗ nó hỏi bạn có muốn thêm thứ này không. Nate nói điều này nghe có vẻ ngớ ngẩn, nhưng hãy hỏi AI của bạn xem việc thêm nó sẽ tạo khác biệt gì cho project bạn đang có. Có lúc bạn cần, có lúc không. Và Node.js không phải thứ gì đáng sợ nếu bạn cần cài nó.

Hãy nhớ khi đào vào, bạn sẽ không thấy code phía server. Công cụ này chỉ cho bạn thấy code phía client. Vì vậy có những trường hợp một công ty có code server-side riêng tư của họ mà không bao giờ lộ ra ngoài. Bạn có thể suy ra phần nào code đó làm gì từ các tương tác trên ứng dụng, nhưng bạn sẽ không nhìn thấy nó, và cũng không nên cố, vì làm vậy là hacking. Nate nói rõ: đừng làm. (Thẻ trên màn hình lúc này ghi lưu ý của REA: chỉ kiểm tra những app bạn sở hữu hoặc được phép kiểm tra.)

## 18. Một người thầy không biết mệt cho phần mềm

Nếu bạn bắt đầu cài và dùng REA vì "Nate bảo dùng", thì đây là điều đầu tiên anh sẽ làm: hãy chắc rằng bạn đang dùng nó để học. Đây là một công cụ học cực kỳ mạnh. Kể cả là kỹ sư, bạn có thể trò chuyện với một ứng dụng, hiểu nó vận hành ra sao, rồi thử giải thích lại bằng lời của chính mình. Đó là cách rất nhiều việc học diễn ra.

Giờ về cơ bản chúng ta có một người thầy không biết mệt, hiểu phần mềm trên internet, có thể đi tới độ sâu kỹ thuật mà trước đây khó chạm tới hơn, và chúng ta thực sự có thể đào vào và học. Nate nghĩ đó là cách mối quan hệ của chúng ta với phần mềm bắt đầu thay đổi: ta nhìn một thứ quen thuộc, nhận ra có một câu hỏi mình vẫn luôn muốn theo đuổi, và cứ thế đi làm.

Nếu bạn đang thắc mắc Codex hay Claude trước đây có làm được việc này không, thì câu trả lời là có, nếu bạn prompt chúng thật cẩn thận và kiên nhẫn với chúng. Nhưng REA cho chúng ta tất cả những điều đó ngay khi cài, và cực kỳ đơn giản. Với non-developer, với tất cả những ai không phải người build kỹ thuật, đây là một con đường để hiểu phần mềm mà trước đây ta chưa từng có. Ta khó mà làm được kiểu prompt cầu kỳ kia. Giờ ta thực sự có thể vào trong, hiểu nó, và có được tầm nhìn X-quang vào phần mềm mà trước đây không thể có.

Có một lượng khổng lồ công sức giải quyết vấn đề của con người nằm bên trong những ứng dụng bạn đang dùng. Dù bạn là developer hay không, giờ bạn có thêm một cách để xem xét nó, cùng một agent giúp giải thích những gì bạn đang thấy. Vậy hãy chọn một thứ bạn tò mò, bắt đầu đào vào và nhìn. Có thể bạn sẽ khám phá ra mình có khả năng đặt và trả lời những câu hỏi thú vị hơn nhiều so với mình tưởng. Nếu bạn là dân mê phần mềm, REA rất hợp với bạn.

Còn nếu bạn đang tự hỏi bắt đầu với REA thế nào, ngoài phần cài đặt vừa nói, Nate sẽ viết một bài trên Substack chỉ ra những điểm cụ thể để bắt đầu đào vào với REA, dành cho ai đang nghĩ "tôi có sức mạnh này mà không biết dùng ở đâu". Anh mời mọi người tham gia, nói cộng đồng đang rất sôi nổi, và chào tạm biệt.

## Nguồn và liên kết

- Tên gốc: Your Vibe-Coded App Can Look Right And Fall Apart After Launch. REA Shows You How Real Teams Build.
- Sự kiện: [YouTube](https://homus.dev/events/youtube)
- Video gốc: [https://www.youtube.com/watch?v=PseF3LyXQ04](https://www.youtube.com/watch?v=PseF3LyXQ04)

- Kênh YouTube AI News & Strategy Daily | Nate B Jones (Nate B Jones): [youtube.com/channel/UC0C-17n9iuUQPylguM1d-lQ](https://www.youtube.com/channel/UC0C-17n9iuUQPylguM1d-lQ)

- REA, Reverse Engineer Anything, repo chính thức (README có lệnh setup, danh sách agent hỗ trợ như Claude Code và Codex, các loại mục tiêu phân tích được): [github.com/morluto/rea](https://github.com/morluto/rea)

- Trang web REA, hướng dẫn và các showcase: [rea.tools](https://rea.tools/)

- Ca nghiên cứu Aegis (mã đăng nhập sáu số, bản dựng lại với đồng hồ chỉnh được): [rea.tools/showcase/aegis](https://rea.tools/showcase/aegis/)

- Ca nghiên cứu Notion (clipboard qua Electron và định dạng clipboard phong phú): [rea.tools/showcase/notion](https://rea.tools/showcase/notion/)

- Ca nghiên cứu DX-Ball (sound panning theo vị trí ngang): [rea.tools/showcase/dx-ball](https://rea.tools/showcase/dx-ball/)

- Bài viết đầy đủ của Nate về REA trên newsletter: [natesnewsletter.substack.com/p/rea-reverse-engineer-anything](https://natesnewsletter.substack.com/p/rea-reverse-engineer-anything)

Nguồn: https://homus.dev/talks/your-vibe-coded-app-can-look-right-and-fall-apart-after-launch-rea-shows-you-how-real-teams-build · cập nhật 2026-10-16