# Từ ý tưởng tới app thật với Codex theo AI SDLC

[Alberto Moedano](https://homus.dev/speakers/alberto-moedano) · [Code with Beto](https://homus.dev/orgs/code-with-beto)

> Đi theo một lần sửa widget thật của app Oyelo qua sáu bước SDLC, từ plan, AGENTS.md, test tự động tới PR và TestFlight, dựa trên playbook của Anthropic.

Topics: Coding Agents, Workflow, Software Factory

Canonical: https://homus.dev/talks/claude-code-from-idea-to-real-app-with-codex-in-an-ai-sdlc

## 1. SDLC: quy trình bạn có thể đang bỏ sót

Beto mở đầu bằng lời nói với người đang build ứng dụng bằng AI: có một quy trình mà có thể bạn đang bỏ sót, đó là software development lifecycle, gọi tắt là SDLC. Theo anh (video đăng ngày 19/10/2026), developer đã dùng nó hàng chục năm nay để biến ý tưởng thành phần mềm chạy được, test nó, ship nó, và giữ cho nó tiếp tục chạy sau khi ra mắt.

![Sơ đồ vòng tròn SDLC với sáu bước Plan, Design, Build, Test, Deploy, Maintain](https://homus.dev/photos/6mJ-_gtB5J8-0004.jpg)

Sáu bước Plan, Design, Build, Test, Deploy, Maintain nối với nhau thành một vòng tròn khép kín (video đăng ngày 19/10/2026).

Theo lời Beto trong video đăng ngày 19/10/2026, Anthropic, team đứng sau Claude Code, gần đây đã công bố một playbook để đưa AI vào toàn bộ quy trình này. Anh nói một khi bạn có một workflow lặp lại được, bạn sẽ bớt thời gian qua lại sửa lỗi, và có thêm thời gian đưa app của mình tới tay người dùng.

Hôm nay anh sẽ cho thấy việc đó trông như thế nào trong thực tế, bằng một ứng dụng của chính anh tên là Oyelo. Cả video đi theo một cải tiến thật của app, qua từng bước của quy trình, để bạn có thể áp dụng cho ứng dụng của riêng mình (video đăng ngày 19/10/2026). Rồi anh vào việc.

## 2. Playbook AI-native SDLC của Anthropic, thu gọn cho solo developer

Beto mở trang playbook có tên "The AI-native SDLC playbook" mà Anthropic chính thức phát hành. Trên màn hình, trang nằm ở mục Claude Resources, thuộc nhóm Best practices, gắn với các sản phẩm Claude Enterprise, Claude Code và Claude Tag, có ngày August 21, 2026 và thời gian đọc 40 phút (theo trang trong video đăng ngày 19/10/2026).

![Trang The AI-native SDLC playbook trên claude.com, với tiêu đề phụ How to transform your software development lifecycle with AI, stage by stage](https://homus.dev/photos/6mJ-_gtB5J8-0043.jpg)

Trang "The AI-native SDLC playbook" của Anthropic trên claude.com, tiêu đề phụ "How to transform your software development lifecycle with AI, stage by stage"; cột bên phải ghi Category, Product, Author, ngày August 21, 2026 và Reading time 40 min (như trên màn hình trong video đăng ngày 19/10/2026).

Anh nói anh nhanh chóng nhận ra playbook này nhắm cụ thể tới các tổ chức, về cơ bản là các team lớn (nhận xét của Beto, video đăng ngày 19/10/2026). Vì vậy hôm nay anh sẽ định hình lại nó một chút, theo cách chỉ áp dụng cho solo developer đang build một app. Anh sẽ cô đọng lại thành những gì anh thấy hữu ích và giữ cho một solo developer làm việc hiệu quả.

Cụ thể, phiên bản của anh bỏ qua việc mất thời gian dựng một server để chạy continuous integration, chạy test trên cloud, hay lo API key. Anh nói những thứ đó rất hay, nhưng chúng thêm rất nhiều ma sát. Theo Beto (video đăng ngày 19/10/2026), là solo developer, bạn thực ra có lợi thế được bỏ qua chúng bằng cách làm mọi thứ ngay trên máy tính của mình.

## 3. Sáu bước, trước và sau khi có agent

Rồi Beto đi qua các mảnh của development lifecycle. Trước khi có agent, chúng ta phải plan, design, build, test, deploy và maintain. Và thật ra, theo Beto (video đăng ngày 19/10/2026), sau khi có agent, chúng ta vẫn làm đúng những việc đó.

Hình playbook mà Beto cuộn qua: trước khi có agent, Build là khối dài nhất; sau khi có agent, Build chỉ còn một vạch mỏng và phần "cycle time reclaimed" được lấy lại. Câu bên dưới trên trang: các bước chạy theo tốc độ con người giữ nguyên độ dài, còn build co lại chỉ còn vài giờ (theo playbook, đọc ngày 26/10/2026).

Điều cần hiểu ở đây, theo Beto (video đăng ngày 19/10/2026), là giờ đây mỗi bước trong development lifecycle đều chạy cùng với một AI agent. Anh nói thêm: quy trình này dùng được với Claude hoặc Codex. Hôm nay anh dùng Codex, trong khi đây là playbook của Anthropic, và điều đó hoàn toàn ổn.

Playbook có một bảng so sánh "Traditional SDLC" với "AI-native SDLC" cho từng bước, mà Beto lướt qua trong video. Ví dụ ở bước Plan, cột AI-native ghi Claude tổng hợp các điểm đau thẳng từ nguồn và ghi lại trong `intent.md`, một file người đọc được và máy hành động được; ở bước Build, kiến thức của tổ chức được giữ trong các file `CLAUDE.md` và skill có version (theo playbook, đọc ngày 26/10/2026).

## 4. Oyelo và bộ widget trông rất tệ

Đây là Oyelo, ứng dụng mà Beto chủ yếu làm cùng Codex (video đăng ngày 19/10/2026). Anh demo nhanh: đó là một app cho phép bạn nghe bất kỳ đoạn văn bản hay bài viết nào bạn thích.

Điều hay ở app, thứ anh thật sự thích, là nó có widget trên màn hình Home, và bạn có thể bấm play hay dừng ngay từ đó. Vấn đề duy nhất: widget này trông rất tệ. Ảnh bị cắt, và app chỉ xử lý hai cỡ. Beto nói thêm, phòng khi bạn chưa biết: theo lời anh trong video đăng ngày 19/10/2026, Apple giờ hỗ trợ bốn cỡ, một trong đó là full screen. Và thành thật mà nói, anh muốn hỗ trợ tất cả.

![Xcode mở file PlaybackController của Oyelo, bên phải là iPhone với widget Continue listening của Oyelo và widget Apple Music](https://homus.dev/photos/6mJ-_gtB5J8-0145.jpg)

Trước khi sửa: Xcode mở project Oyelo, bên phải là màn hình iPhone với widget "Continue listening" của Oyelo, ảnh bìa bài viết bị cắt trong một khung đứng; bên dưới là widget Apple Music (demo trong video đăng ngày 19/10/2026).

Rồi anh xem tới cỡ nhỏ (small): cái này trông không tệ lắm. Anh lưu ý rằng việc này nghe như một prompt dễ, nhưng thực ra phức tạp hơn thế, vì có nhiều view, nhiều màn hình, nhiều cỡ, và phải tính xem sẽ hiện thông tin gì nếu chọn dùng cỡ lớn (video đăng ngày 19/10/2026).

Để làm ví dụ, anh mở widget của Apple Music. Nếu bạn dùng cỡ rất lớn, bạn sẽ có hiệu ứng này: phần đang phát ở trên, danh sách "Recently played" ở dưới. Anh nghĩ mình muốn làm một thứ như vậy, và với cỡ lớn thì phần "recently played" có thể thay bằng các mục đang nằm trong hàng đợi (queue) của ứng dụng anh (demo trong video đăng ngày 19/10/2026).

## 5. Plan: intent.md, hay đơn giản là một bản plan

Giờ đã có ý tưởng về việc muốn làm. Theo Beto (video đăng ngày 19/10/2026), SDLC bảo rằng chúng ta nên tạo một file `intent.md`, và về cơ bản agent sẽ làm việc đó. Bạn có thể gọi nó là `intent.md`, nhưng anh nói thật lòng nó cũng giống như làm một bản plan đơn giản.

Trong playbook, bước 01 Plan có dòng mô tả: ý tưởng thôi không phải chờ ai đó viết chúng ra; intent được ghi lại một lần, bằng chính lời của người khởi xướng, thành một artifact có version mà bước tiếp theo hành động được. Mục "Capture as intent.md" viết rằng `intent.md` là thứ khởi động quy trình, và có thể tới từ một ý tưởng, một ticket, hay một sự cố do cảnh báo đưa lên (theo playbook, đọc ngày 26/10/2026).

Vì vậy trong Codex, anh chuyển vào plan mode rồi bắt đầu mô tả việc muốn làm. Màn hình Codex hỏi "What should we build in oyelo?", ô chat gắn với project oyelo và "This computer", nút Plan đang bật, model chọn là GPT-6 Astra Ultra (như trên màn hình trong video đăng ngày 19/10/2026). Anh đọc prompt của mình: anh muốn refactor các widget, vì lúc này UI trông không dễ chịu, và anh nghĩ có thể làm tốt hơn. Anh sẽ đính kèm vài ảnh của widget Apple Music và tình trạng hiện tại của widget trong app. Rồi nhờ agent giúp viết một plan để cải thiện chúng và hỗ trợ thêm các cỡ.

![Codex với câu hỏi What should we build in oyelo, ba ảnh chụp widget đính kèm và prompt dài, model GPT-6 Astra Ultra](https://homus.dev/photos/6mJ-_gtB5J8-0403.jpg)

Prompt trong Codex ở plan mode: ba ảnh chụp widget đính kèm (Apple Music và widget hiện tại của Oyelo), đoạn mô tả về ảnh bìa vuông và ảnh bài viết lúc ngang lúc dọc, và dòng cuối về hỗ trợ mọi cỡ widget. Bên phải là iPhone với widget Apple Music cỡ lớn có danh sách Recently Played (demo trong video đăng ngày 19/10/2026).

## 6. Phần bạn phải "nói lan man" với agent

"Đừng lo", Beto nói, đây là phần mà bạn thật sự cần nói lan man (ramble) với agent. Anh chụp một ảnh màn hình rồi kéo thả vào ô chat (demo trong video đăng ngày 19/10/2026).

Anh giải thích cho agent: ảnh ở dưới cùng là widget Apple Music, và như bạn thấy, thumbnail, tức ảnh bìa của bài hát đó, là một hình vuông. Anh nghĩ app mình cũng có thể dùng hình vuông. Nhưng anh không hoàn toàn chắc, vì trong một số trường hợp, ảnh của các bài viết trong ứng dụng là ảnh ngang (landscape), có khi lại là ảnh dọc (portrait). Nên ta không thật sự biết tỉ lệ của ảnh (video đăng ngày 19/10/2026).

Vì vậy anh viết thêm vào prompt: chúng ta cần một cách để nó trông đẹp bất kể ảnh thế nào. Và chúng ta cần hỗ trợ mọi cỡ widget. Trên màn hình, các dòng này hiện ra gần như đúng như lời anh đọc: "we need a way to make it look good regardless" và "...rt all widget sizes" (demo trong video đăng ngày 19/10/2026).

## 7. Mẹo: tự đi tìm tài liệu API trước khi nhờ agent

Tới đây Beto chia sẻ một "pro tip". Anh biết AI có thể tự đi tìm trên web cho bạn (theo Beto, video đăng ngày 19/10/2026), nhưng anh rất khuyên, và đây là việc anh làm mọi lúc: hãy tự đi tìm API và tài liệu cho thứ bạn đang muốn làm.

Trong trường hợp này, anh tìm "apple developer widget sizes". Kết quả cho anh biết nó được gọi là System family. Như bạn thấy, anh có được đúng trang tài liệu cùng các best practice về design (demo trong video đăng ngày 19/10/2026).

![Trang Widgets trong Human Interface Guidelines của Apple, mục System family widgets với các tab Small, Medium, Large, Extra large, Extra large portrait](https://homus.dev/photos/6mJ-_gtB5J8-0416.jpg)

Trang Widgets trong Human Interface Guidelines của Apple, mục "System family widgets", với năm tab cỡ trên màn hình: Small, Medium, Large, Extra large và Extra large portrait, cùng bảng các ngữ cảnh mà mỗi cỡ được hỗ trợ trên iPhone, iPad, Mac và Apple Vision Pro (như trên màn hình trong video đăng ngày 19/10/2026; lời Beto ở đoạn trước nói bốn cỡ).

"Để ý xem tôi đang làm gì", anh nói: anh thật sự tự đi tìm và cố tự học, để rồi đưa ra được một prompt và một plan tốt hơn, vì theo anh đây là phần quan trọng nhất của toàn bộ workflow, và lát nữa bạn sẽ thấy vì sao. Anh copy link trang tài liệu rồi quay lại agent (video đăng ngày 19/10/2026).

Theo Beto (video đăng ngày 19/10/2026), việc này cực kỳ hữu ích vì agent có thể fetch dữ liệu từ link đó và biết ngay cách implement nó trong ứng dụng. Anh thấy chừng đó là quá đủ, bấm Enter, và để agent tự đưa ra một plan.

## 8. Codex hỏi lại, và bước Design như một bản spec

Trước khi viết plan, agent hỏi lại anh vài câu (demo trong video đăng ngày 19/10/2026). Beto gọi model bằng tên Astra. Câu đầu tiên: muốn hỗ trợ những cỡ nào. Anh chọn tất cả các cỡ, vì ứng dụng của anh cũng chạy trên iPad.

![Codex trình bày Oyelo hiện chỉ hỗ trợ small và medium, rồi hỏi Should this refactor cover Home Screen sizes only, or also add Lock Screen widgets](https://homus.dev/photos/6mJ-_gtB5J8-0443.jpg)

Codex tóm tắt trước khi hỏi: Oyelo hiện chỉ hỗ trợ small và medium; Apple liệt kê small, medium, large cho iPhone, cộng extra large cho iPad, còn extra-large portrait chỉ có trên Vision Pro; Oyelo đã có hàng đợi Up Next. Rồi câu hỏi 1/3 với lựa chọn "All system sizes" được gắn nhãn Recommended (demo trong video đăng ngày 19/10/2026).

Câu tiếp theo: ảnh ngang và ảnh dọc nên hiện thế nào bên trong ô bìa vuông. Anh chọn giữ nguyên toàn bộ ảnh (preserve full image), vì không muốn cắt ảnh, và để xem kết quả trông ra sao. Câu cuối: widget lớn hơn nên hiện gì bên dưới hoặc bên cạnh mục đang nghe. Anh chọn Up Next, để thấy bài tiếp theo là gì (demo trong video đăng ngày 19/10/2026).

Beto nhắc: nhân tiện, chúng ta đã ở bước thứ hai của quy trình rồi, bước Design. Bạn có thể nghĩ design là UI, là thứ này sẽ trông như thế nào, và đúng là nó có thể là vậy. Nhưng design ở đây giống bản spec, bản đặc tả hơn. Bạn cũng có thể design cách thứ này sẽ được implement trong code (theo Beto, video đăng ngày 19/10/2026).

Ví dụ, bạn có thể nói design sẽ gồm một hàm xử lý kích thước widget, và tôi sẽ tạo hàm này trong một file ở đây. Nó mang tính kỹ thuật hơn: bạn sẽ viết code thế nào, xử lý việc implement ra sao bên trong codebase mà mình đã có (video đăng ngày 19/10/2026).

Trong playbook, bước 02 Design ghi rằng requirements và design gộp lại trong một phiên làm việc; mục "Requirements and design" viết rằng sau khi product owner duyệt, Claude lấy `intent.md` đã được chấp nhận và tạo ra một bản spec requirements và design, theo các skill của tổ chức (theo playbook, đọc ngày 26/10/2026).

## 9. AGENTS.md và thư mục docs của Oyelo

Với Beto, phần design này dựa trên file `AGENTS.md` của Oyelo. Về cơ bản file đó định nghĩa chúng ta đang làm gì ở đây. Theo anh (video đăng ngày 19/10/2026), mỗi lần tạo một agent mới, nó đến với zero context, nên nó cần đọc file `AGENTS.md` và biết ngay đây là một ứng dụng iOS viết bằng SwiftUI, ưu tiên màu hệ thống, ưu tiên những thứ anh thích, giữ mọi thứ đơn giản, lo accessibility.

![File AGENTS.md của project oyelo mở trong editor, cây thư mục bên trái có .claude, apps, docs, Oyelo](https://homus.dev/photos/6mJ-_gtB5J8-0538.jpg)

File `AGENTS.md` của project oyelo: một app iOS SwiftUI native, các quy tắc về bí mật và network, ranh giới mã nguồn, và một đoạn dài về localization (như trên màn hình trong video đăng ngày 19/10/2026).

Những dòng đầu của file, như trên màn hình:

```
# Oyelo

Native SwiftUI iOS app. Prefer system controls, semantic colors, Dynamic Type, accessibility labels, and short copy. Minimum iOS 26. Keep the library private and local; no audio export or shared catalogue.

Never commit API keys, downloaded user articles, generated user audio, or test credentials. User keys belong in the device Keychain. Network requests go directly to the selected provider. Do not log request bodies or credentials.

Source boundaries: Core contains models/storage/generation; Providers contains transport adapters; Import contains extraction; Playback owns media controls; Features contains SwiftUI screens. Shared files are deliberately usable in extensions.
```

Anh hỗ trợ nhiều ngôn ngữ, nên anh có một thư mục docs mà anh để agent viết mỗi khi implement một thứ quan trọng mà anh muốn theo dõi cho những lần lặp sau; anh chỉ việc nhờ agent thêm một tài liệu. Trên màn hình, thư mục docs có các file như `FIRST-LISTEN.md`, `IMPLEMENTATION.md`, `IMPORTS.md`, `LOCALIZATION.md`, `MODEL-CATALOGUE.md`, `MONETIZATION.md` và `PRO.md` (video đăng ngày 19/10/2026).

Mục đích là bảo đảm mỗi lần thay đổi, app vẫn hỗ trợ, chẳng hạn, localization, tức hỗ trợ nhiều ngôn ngữ. File `LOCALIZATION.md` trên màn hình ghi Oyelo có giao diện tiếng Anh cùng tiếng Tây Ban Nha, Bồ Đào Nha (Brazil), Pháp, Đức, Ý, Nhật, Trung giản thể và Hindi. Theo Beto (video đăng ngày 19/10/2026), mỗi khi tạo một nút, anh chỉ cần nói với agent "tạo một nút mới trong màn hình này", agent sẽ theo tài liệu localization và implement ngay cái nút bằng tiếng Anh, đồng thời hỗ trợ mọi ngôn ngữ khác của ứng dụng.

## 10. Review plan và phần Verification

Một lúc sau, plan đã xong (demo trong video đăng ngày 19/10/2026). Beto review để xem agent có đồng ý với ý của mình không. Anh đọc phần đầu: hỗ trợ mọi system widget family có trong ứng dụng iPhone và iPad của Oyelo, và tất nhiên vẫn giữ tương thích iOS 26. Anh giải thích, theo lời anh trong video đăng ngày 19/10/2026: vì trên iOS 27, iOS và iPad giờ hỗ trợ cỡ extra large portrait. Trên màn hình, plan viết: thêm extra-large portrait trên iOS/iPadOS 27 với kiểm tra availability, và tài liệu WidgetKit mới hơn của Apple xác nhận việc này, dù bảng HIG cũ hơn chưa có.

Điều quan trọng với anh trong thay đổi này là giữ nguyên tỉ lệ đầy đủ của từng ảnh bên trong một ô vuông, và dùng lại artwork làm nền như một placeholder. Plan trên màn hình có bảng "Visual design and sizes" mô tả layout cho Small, Medium, Large, Extra large và Extra-large portrait, ví dụ Large là phần header kiểu Medium phía trên tối đa ba dòng Up Next (demo trong video đăng ngày 19/10/2026).

Cá nhân anh, khi đó là một feature quan trọng, anh thích dành thời gian review plan từng bước một. Bạn thậm chí có thể sửa một chỗ ngay tại đó bằng cách gõ vào, nếu muốn chỉnh vài thứ (theo Beto, video đăng ngày 19/10/2026).

![Phần Verification và Assumptions trong plan Oyelo widget redesign của Codex](https://homus.dev/photos/6mJ-_gtB5J8-0723.jpg)

Phần "Verification" agent tự thêm vào plan: test cho snapshot, payload, quyền riêng tư, thứ tự hàng đợi; kiểm mọi family với ảnh ngang, dọc, vuông, thiếu hoặc hỏng; build và test trên simulator iPhone, iPad với iOS 26 và 27; đồng bộ String Catalog và chạy test localization. Bên dưới là "Assumptions" (demo trong video đăng ngày 19/10/2026).

Thứ anh muốn nhấn mạnh trước khi duyệt: agent đã thêm một mục Verification ở đây. Theo Beto (video đăng ngày 19/10/2026), vì agent điều khiển được máy tính của anh, về cơ bản nó sẽ tự động kiểm tra mọi cỡ widget, và bảo đảm phần localization và bản dịch của ứng dụng chạy được trên mọi ngôn ngữ. Rồi anh bảo nó: cứ implement đi.

## 11. Build: không có gì được làm khi plan chưa được duyệt

Giờ là bước Build. Như bạn thấy, không có gì được implement khi chưa chấp nhận plan, và đó chính là việc vừa làm. Trên màn hình, tin nhắn của Beto là "okay implement it", và Codex trả lời rằng nó sẽ implement layout widget, cách xử lý artwork và tương tác Up Next, rồi kiểm tra các cỡ mới và hành vi phát trên simulator. Ngay sau đó, các subagent "Widget playback", "Widget ui" và "Widget architecture" bắt đầu chạy, cùng các dòng đọc file, chạy lệnh (demo trong video đăng ngày 19/10/2026).

Agent sẽ làm phần việc: đọc codebase, thu thập thông tin và cú pháp cho phần implement. Theo Beto (video đăng ngày 19/10/2026), việc của bạn là sửa plan trước khi code được viết.

Một điều quan trọng khác ở phần build: chúng ta phải cung cấp cho agent những công cụ nó cần. Máy của anh đã cài sẵn Xcode. Anh đang dùng computer use, tức về cơ bản để agent dùng các ứng dụng trên máy, và điều đó cho phép agent tự test (video đăng ngày 19/10/2026).

Nhìn vào các ảnh nó tạo ra, nó thực ra đã đang test, và đang kiểm tra nhiều cỡ chữ khác nhau. Theo Beto (demo trong video đăng ngày 19/10/2026), việc này giúp agent bắt lỗi sớm: chỗ này lúc này trông tệ, nó bắt được và lặp lại cho tới khi thực sự xong.

## 12. Test: cho agent công cụ, và định nghĩa thế nào là "done"

Agent vẫn đang làm, nhưng tới lúc này chúng ta đã ở bước Test. Code đã được implement, và agent đang chụp màn hình. Bạn có thể thấy nó đang dùng simulator trên máy của anh, chạy app, chụp ảnh, và kiểm tra rằng UI đúng như mong muốn và khớp với plan (demo trong video đăng ngày 19/10/2026).

![Ảnh agent tự tạo: lưới widget Oyelo cỡ medium với các trường hợp Landscape cover, Portrait cover, Square cover, Missing cover, Empty library, Queue only, Accessibility](https://homus.dev/photos/6mJ-_gtB5J8-0941.jpg)

Một ảnh agent tự tạo để kiểm tra: lưới widget Oyelo cỡ medium cho từng trường hợp (bìa ngang, bìa dọc, bìa vuông, thiếu bìa, thư viện trống, chỉ có hàng đợi, tiêu đề dài, cỡ chữ accessibility). Ảnh bìa giờ nằm gọn trong ô vuông (demo trong video đăng ngày 19/10/2026).

Lý do agent đang test, theo Beto (video đăng ngày 19/10/2026), là vì plan nêu cụ thể rằng nó phải chạy được trong những tình huống này. Và đây là hình dạng của "done": agent chủ động chụp màn hình và kiểm tra công việc trước khi nói nó đã build xong. Trên màn hình, Codex báo rằng phần review hình ảnh bắt được hai lỗi layout: tiêu đề ở cỡ medium bị ép còn một dòng, và trạng thái trống kiểu compact bị tràn ở cỡ chữ lớn nhất; cả hai đã được chỉnh và nó đang chạy lại các kiểm tra layout (demo trong video đăng ngày 19/10/2026).

Chúng ta thực sự bảo agent: "done" nghĩa là localization của app vẫn chạy. "Done" nghĩa là hỗ trợ bốn cỡ. "Done" nghĩa là ảnh trông đẹp. Nó lặp đi lặp lại cho tới khi kiểm tra đạt (demo trong video đăng ngày 19/10/2026).

Beto nhấn mạnh: bạn phải cho agent một phép kiểm tra. Nếu không, theo anh (video đăng ngày 19/10/2026), nó sẽ cứ nói là xong, khi bạn không cho nó một phép kiểm tra hay định nghĩa thế nào là done. Đó là cách bạn dựng vòng lặp, và dựng vòng lặp này, tức định nghĩa thế nào là done, là việc của bạn, người kỹ sư.

Playbook có mục "Give Claude a feedback loop" nói cùng ý: luôn cho Claude một cách để tự kiểm tra công việc của nó, bằng test, bằng build, hay bằng một ảnh chụp màn hình so sánh; ở cột AI-native, Claude lặp cho tới khi kiểm tra đạt, và việc dựng vòng lặp thuộc về kỹ sư đang chạy phiên làm việc (theo playbook, đọc ngày 26/10/2026).

Nhân tiện, Beto chỉ ra: chiếc máy bạn đang nhìn thấy là iPhone thật của anh, nhưng agent thì đang làm việc trên một simulator dành cho widget test mà nó tự tạo ra (demo trong video đăng ngày 19/10/2026). Trong danh sách thiết bị trên màn hình, iPhone 17 Pro thật của anh nằm trên cùng, bên dưới là các simulator như "Oyelo Widget Tests", "Oyelo Widget Compatibility" và "Oyelo Widget Layout Tests", cùng nhiều đời iPhone, iPad chạy iOS 26 và 27 (demo trong video đăng ngày 19/10/2026). Quan trọng nhất, bạn có thể thấy nó thực sự trông ra sao: trông tốt hơn hẳn.

Và tất nhiên, lúc này anh đang ở trên máy tính, nhưng đây chưa được tính là một lần test của con người. Lý do là agent đang làm việc với các công cụ. Đó là lý do bạn cần cho agent một cách để kiểm tra công việc của nó. Trong trường hợp này, theo Beto (video đăng ngày 19/10/2026), chỉ cần cho nó quyền truy cập vào device hub. Hãy bảo đảm nó chụp màn hình; bạn có thể yêu cầu tất cả những thứ đó. Và agent tự mình kiểm tra rằng mọi thứ thực sự chạy. Như vừa thấy, bước test đã hoàn tất.

## 13. Trước khi deploy: Git, GitHub và pull request

Giờ tới phần Deploy. Một điều quan trọng khác Beto muốn nhấn mạnh: tới lúc này, con người, tức anh, chưa hề kiểm tra các thay đổi. Có thể bạn đang nghĩ: làm sao deploy được khi chưa kiểm tra? Đây là chỗ pull request vào cuộc (video đăng ngày 19/10/2026).

Trên trang playbook mà Beto mở ở đoạn này, bước 05 Deploy ghi: review chạy theo cả hai chiều, governance được áp ngay khi agent hành động, agent làm mọi thứ cho tới cổng production và không gì vượt qua nó; mục "AI in the PR review loop" viết rằng Claude vừa đưa vừa nhận review (theo playbook, đọc ngày 26/10/2026).

Nếu bạn chưa quen với Git và GitHub: theo Beto (video đăng ngày 19/10/2026), Git và GitHub cho phép bạn tách riêng và thử nghiệm các thay đổi trong codebase, như những thay đổi đang có ngay lúc này. Đây thực chất là một lần code review: bạn có thể bấm vào phần thay đổi và thấy chính xác cái gì đã đổi trong phần này. Trước khi thực sự lưu và quyết định giữ những thay đổi này, chúng ta cần review chúng.

Nếu bạn không rành kỹ thuật: một pull request, về cơ bản, là một yêu cầu từ developer hoặc từ agent đã tạo ra thay đổi, một yêu cầu merge đoạn code cụ thể đó vào ứng dụng chính (theo cách Beto giải thích, video đăng ngày 19/10/2026).

Anh hy vọng tới lúc này bạn đã gắn một repo với ứng dụng của mình. Nếu chưa, bạn có thể nhờ agent: "tạo một GitHub repo và lưu code vào đó" (lời Beto, video đăng ngày 19/10/2026). Làm xong, nó sẽ trông giống thế này: trên màn hình là repo private oyelo, với nhánh main, 3 nhánh, 97 commit, và mô tả "Oyelo: a private iOS article-to-audio reader. Bring your own voice provider API key."

Ý Beto nói về pull request: thay đổi nằm tách riêng trên một nhánh, main vẫn sạch, và bạn có thể mở một chat mới, một nhánh khác để làm tính năng khác song song (video đăng ngày 19/10/2026).

Nhưng khi app của bạn lớn lên, nhất là khi bạn có người dùng thật và họ đang thật sự trả tiền để dùng ứng dụng, bạn sẽ bắt đầu cảm thấy áp lực rằng mình không được làm hỏng nó. Trong những trường hợp đó, anh khuyến khích bạn hết sức cẩn thận khi thêm thứ mới vào app. Cách để có tự tin merge thay đổi này, dù nó là thứ mới, là phải test nó thật kỹ trước khi đưa lên production (lời khuyên của Beto, video đăng ngày 19/10/2026).

## 14. Mở PR, rồi để một agent khác review

Quay lại agent. Nó đã hoàn thành công việc, và Beto muốn giữ những thay đổi này tách riêng, vì nếu có gì không chạy, hay không khớp với thứ anh muốn ship lên production, anh muốn tiếp tục lặp. Nên anh nhờ agent: "hey please create a PR", như trên màn hình. Codex trả lời rằng nó sẽ review diff, commit các thay đổi widget và mở một pull request kèm kết quả test; bảng bên phải ghi Changes +2,157 -357 và Subagents "4 done" (demo trong video đăng ngày 19/10/2026).

Anh nói việc này chỉ để minh hoạ cách giữ thay đổi tách riêng. Lúc duyệt plan trước đó, ta hoàn toàn có thể nói luôn: khi implement xong thì cứ mở một pull request (video đăng ngày 19/10/2026).

Cách anh thích làm là chỉ nói: "hey, mở một pull request, và khi xong thì gửi cho tôi một tin nhắn Slack báo là đã xong để tôi review". Vậy là xong (video đăng ngày 19/10/2026).

Nếu bạn mới làm quen với Git và GitHub: theo Beto (video đăng ngày 19/10/2026), tạo pull request cũng giúp giữ nhánh main của codebase sạch sẽ, và cho phép làm nhiều tính năng cùng lúc. Vì ngay lúc này, anh có thể tạo một chat mới, tạo một nhánh mới, một nhánh khác tách từ main, rồi bắt đầu implement một tính năng khác, hoàn toàn tách biệt khỏi app chính.

Một lúc sau, agent báo pull request đã sẵn sàng (demo trong video đăng ngày 19/10/2026). Anh quay lại GitHub, refresh để cho bạn xem. Đây rồi: một pull request, phần thay đổi tách riêng mà chúng ta vừa làm.

![Pull request Redesign widgets and support all system sizes #1 trên GitHub, từ nhánh codex/widget-redesign vào main](https://homus.dev/photos/6mJ-_gtB5J8-1423.jpg)

Pull request "Redesign widgets and support all system sizes #1" trong repo Code-with-Beto/oyelo: một commit từ nhánh `codex/widget-redesign` vào `main`, 21 file thay đổi, +2,155 -355. Mô tả nói widget cũ cắt ảnh bài viết trong khung đứng và chỉ hỗ trợ small và medium (demo trong video đăng ngày 19/10/2026).

Một việc khác bạn có thể làm, theo Beto (video đăng ngày 19/10/2026): copy link này, quay lại agent, tạo một agent mới và nói "hãy review pull request này". Chỉ cần đưa link, agent sẽ review và cho bạn biết: agent kia đã bỏ sót chỗ này. Rồi bạn có thể bảo agent: "nếu bạn đồng ý thì sửa những lỗi này đi". Hoặc bạn có thể hỏi ngay trong cùng chat, nhờ agent tạo một sub-agent để review pull request. Khi agent review xong và hai bên thống nhất, bạn có thể merge vào main.

## 15. Merge vào main và đưa build lên TestFlight

Khi đã hài lòng với các thay đổi, bạn có thể vào đây và merge bằng tay. Hoặc, Beto nói, giả sử bạn đang làm việc từ điện thoại: bạn có thể nói "okay, ổn rồi, merge vào main và ship một phiên bản mới lên TestFlight". Trên màn hình, đoạn cuối tin nhắn anh gõ là "...erge it to main, and shipt a new version to testflight (internal)" (video đăng ngày 19/10/2026).

Anh ghi rõ internal testing, vì theo lời anh trong video đăng ngày 19/10/2026, ứng dụng này lúc đó đang ở bản beta. Rồi anh gửi cho agent.

Cập nhật nhanh: agent đang deploy, và pull request đã được merge (demo trong video đăng ngày 19/10/2026). Nghĩa là nếu vào tab Code, trước hết không còn pull request nào nữa, vì nó đã được merge. Giờ nó nằm trong nhánh main của codebase. Và agent đang dùng máy tính của anh để tạo build TestFlight mới và thêm nó vào internal testing.

Một lần nữa, tới đây Beto giả định bạn đã thiết lập sẵn credentials trong Xcode, để agent có thể dùng chúng mà deploy ứng dụng thay cho bạn (theo Beto, video đăng ngày 19/10/2026).

![App Store Connect, TestFlight của Oyelo: Text to Speech Reader, build 1.0 (35) với Test Details; bên trái Codex báo upload thành công](https://homus.dev/photos/6mJ-_gtB5J8-1523.jpg)

Agent làm việc trong App Store Connect: app "Oyelo: Text to Speech Reader", mục TestFlight, build 1.0 (35) với phần "What to Test" mô tả widget mới. Cột bên trái là Codex báo archive đã qua kiểm tra, upload thành công, Apple đang xử lý build và nó sẽ gán vào nhóm internal Oyelo testing (demo trong video đăng ngày 19/10/2026).

Anh thấy agent đang thêm build mới nhất vào nhóm internal testing, và thế là xong (demo trong video đăng ngày 19/10/2026).

## 16. Test trên iPhone thật: phần người làm

Giờ mới là phần mà con người thực sự nên review các thay đổi. Beto đang ở trong TestFlight (demo trong video đăng ngày 19/10/2026), thấy build 35, chính là build vừa làm, và cài nó. Như anh đã nói, đây là phần bạn thật sự làm việc, và thành thật mà nói, theo anh, đây là phần thoả mãn nhất: phần bạn được tự tay test các thay đổi.

![App Store Connect hiện build 35 Internal ở trạng thái Testing; iPhone bên phải với widget Oyelo mới có ảnh bìa vuông Moore's Law for Everything](https://homus.dev/photos/6mJ-_gtB5J8-1543.jpg)

Build 35 (Internal) đã ở trạng thái Testing trong App Store Connect; trên iPhone thật, sau khi cài, widget Oyelo đổi ngay sang thiết kế mới với ảnh bìa vuông và nút Play (demo trong video đăng ngày 19/10/2026).

Anh đóng app lại và thấy widget đổi ngay (demo trong video đăng ngày 19/10/2026). Anh không thật sự thích tỉ lệ khung hình của ảnh, nhưng chắc chắn nó giống với thiết kế đang nhắm tới.

Anh tìm Oyelo trong danh sách widget và thấy bản xem trước của nó. Giờ có cỡ medium, và bạn cũng thấy nền thay đổi theo ảnh; rồi cỡ rất lớn. Anh bấm Add để xem nó có thêm được không. "Okay, khá đẹp", anh nói (demo trong video đăng ngày 19/10/2026).

Anh thử thêm thứ gì đó vào hàng đợi: kéo và thêm vài mục vào queue, rồi thu nhỏ app. Giờ đã thấy chúng hiện ở đây. "Hoàn hảo." Anh bấm phát một mục, và giờ có thể chuyển qua lại giữa chúng. "Cái này rất hay", anh nói (demo trong video đăng ngày 19/10/2026).

Vẫn còn vấn đề cũ với ảnh: tỉ lệ khung hình đôi khi không thật sự ổn. Nhưng anh vui khi thấy widget đang cập nhật, và anh đổi được giữa các cỡ. "Hoàn hảo." Xuống tới cỡ small, tối giản hơn (demo trong video đăng ngày 19/10/2026). Anh nghĩ vẫn còn vài chỗ cần chỉnh. Và đây là lúc bạn thật sự được quyết định có ship lên production hay không.

## 17. Maintain: quay lại từ đầu vòng lặp

Cuối cùng là Maintain, về cơ bản là bắt đầu lại từ đầu. Như ngay lúc này, đã phát hiện vài vấn đề trong ứng dụng của anh. Theo Beto (video đăng ngày 19/10/2026), việc cần làm ở đây về cơ bản là y như cũ: định nghĩa thay đổi, làm plan, cho agent một cách để test, có thể dùng chính những bài viết anh đang dùng ở đây, build, test, và cuối cùng deploy.

Vòng lặp Beto mô tả ở phần Maintain: mỗi vấn đề tìm thấy lại đi qua đúng các bước như trước (video đăng ngày 19/10/2026). Playbook gọi bước 06 là nơi vòng lặp khép lại, với thứ tìm được quay lại pipeline dưới dạng một `intent.md` mới (theo playbook, đọc ngày 26/10/2026).

Trên trang playbook mà Beto mở ở đoạn này, mục 06 Maintain viết: vòng lặp khép lại; một trigger gọi Claude mà không có người nào trên đường gọi, và thứ nó tìm được đi vào lại pipeline dưới dạng `intent.md` (theo playbook, đọc ngày 26/10/2026).

Khi build ứng dụng của mình, anh nói bạn sẽ thấy có thể tối ưu vài chỗ theo workflow của bạn, theo tình trạng hiện tại của ứng dụng và theo mục tiêu của project. Anh hy vọng bạn đã học được điều gì đó mới (video đăng ngày 19/10/2026).

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

- Tên gốc: Claude Code: From Idea to Real App with Codex in an AI SDLC
- Sự kiện: [YouTube](https://homus.dev/events/youtube)
- Video gốc: [https://www.youtube.com/watch?v=6mJ-_gtB5J8](https://www.youtube.com/watch?v=6mJ-_gtB5J8)

- Kênh YouTube Code with Beto (Alberto Moedano): [youtube.com/channel/UCh247h68vszOMA_OWpGEa5g](https://www.youtube.com/channel/UCh247h68vszOMA_OWpGEa5g)

- Anthropic, "The AI-native SDLC playbook": sáu bước Plan, Design, Build, Test, Deploy, Maintain, các mục "Capture as intent.md", "Give Claude a feedback loop", "AI in the PR review loop" (đọc ngày 26/10/2026): [claude.com/resources/articles/the-ai-native-sdlc-playbook](https://claude.com/resources/articles/the-ai-native-sdlc-playbook)

- Apple Human Interface Guidelines, Widgets, mục "System family widgets" (đọc ngày 26/10/2026): [developer.apple.com/design/human-interface-guidelines/widgets](https://developer.apple.com/design/human-interface-guidelines/widgets)

Nguồn: https://homus.dev/talks/claude-code-from-idea-to-real-app-with-codex-in-an-ai-sdlc · cập nhật 2026-10-26