---
title: "Hành trang cho vibe coder - git, frontend, backend, secret, cách tổ chức dữ liệu, test và CI"
description: "Khóa nền cho vibe coder đã dựng app bằng Claude Code hay Codex: agent viết code rồi, ai giữ cho app chạy ổn sau mỗi lần sửa? Trên app đặt lịch hẹn do agent dựng, bạn cho agent commit sau mỗi bước, biết phần nào chạy ở đâu, giữ secret ngoài chat và git, tự chọn cách lưu dữ liệu, rồi để test và CI kiểm tra mỗi thay đổi."
canonical: "https://200lab.io/courses/hanh-trang-cho-vibe-coder-git-frontend-backend-secret-cach-to-chuc-du-lieu-test-va-ci"
type: "course"
course_type: "course"
learning_type: "free_form"
published: "2026-10-13T09:49:55Z"
students: 1
---

## Khóa học này mang lại gì cho bạn

Ngay lần đầu nhờ agent, bạn đã có app chạy được trên máy. Nhưng hôm sau mở agent làm tiếp, bạn nhờ sửa một chỗ nhỏ thì app không mở được nữa, còn bản hôm qua cũng không biết tìm ở đâu. Cả khóa dùng chung một app đặt lịch hẹn do agent của bạn dựng, dành cho người chụp ảnh làm tự do. Agent gõ lệnh và viết code; bạn nhận ra rủi ro, ra quyết định và tự kiểm tra kết quả.

- **Quay về bản đang chạy tốt** — Agent commit sau mỗi bước app chạy được, nên khi sửa xong mà app hỏng, bạn bảo agent quay về commit trước lúc hỏng rồi tự mở app và thấy nó chạy như cũ. Bạn cũng biết những gì quay về commit không lấy lại được, như thay đổi chưa commit, file nằm trong `.gitignore` và dữ liệu đã đổi trong database.
- **Thử thay đổi lớn trên branch riêng** — Agent làm mỗi việc lớn trên branch riêng, tức bản code tách khỏi bản chính. Trước mỗi lần push lên repo private trên GitHub, agent đều hỏi bạn. Bạn đọc pull request rồi tự quyết định có merge vào branch chính hay không.
- **Biết trình duyệt nhận được những gì** — Bạn mở view-source và tab Network trên app của mình để liệt kê mọi thứ trình duyệt nhận được, kể cả dữ liệu không hiện trên màn hình, và kiểm tra xem có đúng là server quyết định ai đang đăng nhập hay không.
- **Giữ secret ngoài chat và ngoài git** — Bạn phân biệt được key publishable với key secret: chỉ key publishable mới được phép nằm trong code chạy trên trình duyệt. Bạn tự điền giá trị của key vào `.env` và chỉ nhắn agent tên biến. Khi key bị lộ, bạn rotate key trước, tức tạo key mới ở trang của service và thu hồi key cũ. Bạn tự thử lại và thấy key cũ bị từ chối, rồi mới nhờ agent xóa key khỏi code.
- **Tự chọn cách lưu dữ liệu** — Bạn xếp từng loại thông tin của app vào dạng dữ liệu phù hợp, mô tả cách tổ chức dữ liệu bằng câu nói thường ngày, rồi đối chiếu các bảng trong database mà agent đề xuất với bốn điều bắt buộc, như mỗi khách có một ID ổn định. Khi cần đổi cách tổ chức đó, bạn yêu cầu agent làm migration, tức bước đổi cách lưu dữ liệu. Migration có kế hoạch và được ghi thành file trong repo, thay vì để agent sửa thẳng từng dòng dữ liệu ngay trong chat.
- **Giao cho test và CI kiểm tra lại app** — Bạn viết các hành vi chính của app thành câu “khi … thì …” để agent biến từng câu thành test, bật CI chạy lại test mỗi lần push, và từ tên test đỏ lần ra hành vi bị hỏng trước khi quyết định merge.
- **Nhận ra lúc agent lách test** — Bạn thấy được lúc agent sửa test cho xanh thay vì sửa app, đặt rule cấm agent sửa test file, và hỏi “phần nào chưa xong?” trước khi tin chữ “xong” của agent.

Đây là khóa nền cho người làm app cùng agent: agent viết mọi dòng code nên bạn không cần đọc code hay tự chọn bộ công nghệ. Bài nào cũng gắn với chuyện xảy ra trên app của bạn.

## Khóa học cung cấp những nền tảng nào

Nền tảng của cả khóa học là cách chia việc giữa bạn và agent. Phần gõ lệnh và viết code thuộc về agent. Phần của bạn là thấy trước chỗ app có thể hỏng, quyết định nên làm gì, rồi tự mở app xem kết quả có đúng không. Mỗi thói quen trong khóa giúp bạn làm phần việc ấy, và đều bắt nguồn từ những chuyện người làm app cùng agent hay gặp khi quay lại làm tiếp.

Tài liệu [Best practices for Claude Code](https://code.claude.com/docs/en/best-practices) khuyên nên đưa cho agent cách kiểm tra mà nó tự chạy được; đó cũng là ý chính của chương về test. Phần [Git Basics — Recording Changes to the Repository](https://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-to-the-Repository) trong sách Pro Git giải thích git theo dõi những file nào và mỗi commit ghi lại những gì. Bài [Client-Server overview](https://developer.mozilla.org/en-US/docs/Learn_web_development/Extensions/Server-side/First_steps/Client-Server_overview) của MDN mô tả cách trình duyệt gửi request và server trả response. Chương về các phần của app dựa trên nền này.

Sáu chương dưới đây xếp theo thứ tự bạn sẽ cần tới từng thói quen khi app lớn dần. Mỗi chương xử lý một vấn đề chương trước chưa giải quyết, và kết bằng một việc bạn làm được trên app mà trước đó chưa làm được. Năm chương đầu, mỗi chương ứng với một thói quen; chương cuối dùng cả năm thói quen khi làm tính năng mới.

### 1. Giữ lại bản app đang chạy tốt

Bạn nhờ agent đưa app về bản trước lúc đổi tên dịch vụ, nhưng agent trả lời không có bản nào để quay về, rồi sửa thêm **3 file**. Bài đầu chương giải thích commit, tức một lần git lưu lại code của app kèm một dòng ghi chú, và cách thống nhất với agent để nó commit sau mỗi bước app chạy được. Claude Code có tính năng rewind để lùi code, và bạn cũng thấy vì sao tính năng này không thay được git.

Ở bài thứ hai, agent đề xuất “dọn sạch thay đổi để hết lỗi”, đúng lúc bạn vừa ngồi **hai tiếng** chỉnh màu danh sách lịch hẹn mà chưa commit. Bạn biết được git không giữ những gì, và những câu cần hỏi trước khi đồng ý cho agent chạy lệnh dọn.

Ở bài thứ ba, bạn để agent làm mỗi việc lớn trên branch riêng. Mỗi khi cần nhận lịch, bạn nhờ agent chuyển về bản chính và chạy lại app, rồi tự mở app và thấy mọi thứ như cũ. Cuối bài, bạn tự đọc pull request đầu tiên, tức trang GitHub bày ra mọi thay đổi của branch, rồi tự bấm merge.

### 2. App gồm những phần nào và chạy ở đâu

Trang danh sách lịch hẹn chỉ hiện tên khách. Nhưng trong tab Network, trình duyệt ghi lại mọi dữ liệu tải về, và ở đó bạn thấy số điện thoại lẫn ghi chú riêng của mọi khách cũng đã được gửi xuống. Ở bài đầu chương, bạn đặt frontend, backend, database và service bên ngoài lên bản đồ “phần nào chạy ở đâu”, rồi nhờ agent sửa server để chỉ gửi xuống những gì trang cần.

Agent lập plan để thêm đăng nhập, và trong plan có bước lưu quyền quản lý lịch ngay trong trình duyệt. Ở bài thứ hai, bạn thử lại đúng bước đó trên branch mẫu mà agent tạo theo hướng dẫn trong kit: đổi một giá trị trong trình duyệt là vào được trang quản lý. Bài giải thích vì sao server phải tự kiểm tra người gửi ở mọi request, và cách đánh dấu từng bước trong plan của agent thuộc phần nào của app.

Đang đi chụp, bạn muốn xem lịch ngay trên điện thoại. Ở bài cuối chương, bạn chọn giữa app native, cross-platform và PWA theo nhu cầu của mình, rồi cài app web lên máy tính như app bình thường. Bạn cũng hiểu vì sao muốn cài lên điện thoại thì app phải được deploy, tức chép code sang máy khác để chạy cho người khác dùng.

### 3. Đặt secret và API key đúng chỗ

Tính năng gửi email nhắc lịch cần key của service gửi email; trong khóa, đó là service giả chạy trên máy, dùng key giả. Trang cài đặt của service hiện hai key, và plan của agent định đặt cả hai vào frontend. Bài đầu giải thích vì sao ai cầm key secret thì service coi người đó là bạn: họ dùng được tài khoản của bạn, và tiền tính vào hóa đơn của bạn. Bạn cũng lập bảng ghi lại từng secret của app đang được cất ở đâu.

Agent xin bạn dán key vào chat để làm tiếp. Bài thứ hai cho bạn thấy chuỗi key đó được gửi đi đâu và nằm lại ở đâu. Bạn tự đặt giá trị key vào `.env` để agent chỉ cần biết tên biến, rồi bật deny rule chặn agent đọc file này. Bạn cũng tự thử những trường hợp deny rule không chặn được, và hiểu vì sao sandbox bảo vệ file theo cách khác: sandbox là giới hạn do hệ điều hành đặt cho các lệnh agent chạy.

Commit cũ vẫn còn chứa giá trị key. Commit mới đã xóa dòng chứa key, nhưng lịch sử commit vẫn hiện key và service giả vẫn nhận nó. Ở bài thứ ba, bạn rotate key trước rồi tự gửi thử một email bằng key cũ để chắc chắn service đã từ chối key đó; chỉ sau đó bạn mới giao việc xóa key khỏi code cho agent.

### 4. Chọn cách lưu dữ liệu trước khi agent chọn thay bạn

Bạn chỉ nhờ agent lọc ra những khách đã hủy lịch hơn **hai lần**, vậy mà agent trả lời phải viết lại cả phần lưu dữ liệu. Trên branch mẫu của bài, lịch hẹn của từng khách đều bị dồn chung vào ô ghi chú của khách đó. Bài đầu chương cho bạn xếp lịch hẹn, giờ làm việc và ảnh đính kèm vào dạng có cấu trúc, bán cấu trúc hay phi cấu trúc, trước khi agent tự chọn thay.

Hai khách cùng tên Lan mở trang của mình lại thấy lịch hẹn của nhau, vì agent nối lịch hẹn với khách bằng tên. Bạn mô tả cách app lưu khách và lịch hẹn bằng những câu nói thường ngày, rồi đối chiếu danh sách bảng trong database mà agent đề xuất với bốn điều bắt buộc, trong đó có ID ổn định cho từng khách và liên kết bằng ID thay vì bằng tên.

Trang tổng quan đếm sai số lịch đã hủy, vì trạng thái được gõ tự do thành “đã hủy”, “Đã Hủy” và “huy”. Bạn tìm năm dấu hiệu cho thấy cách tổ chức dữ liệu có vấn đề, rồi yêu cầu agent làm migration để đổi cách tổ chức, kèm kế hoạch nói rõ dữ liệu đang có sẽ được chuyển sang đâu.

### 5. Để test và CI kiểm tra lại mỗi lần thay đổi

Sau lần đổi cách tổ chức dữ liệu, hai khách cùng đặt được lịch lúc **9 giờ** thứ Bảy, dù agent đã báo “xong”. Ở bài đầu chương, bạn ghi mỗi hành vi chính của app thành một câu “khi … thì …” để agent viết test cho câu đó, rồi đặt ba loại test (unit, integration, end-to-end) lên bản đồ các phần của app.

Ở bài thứ hai, bạn bật CI, tức để GitHub tự chạy lại test trên máy của GitHub mỗi lần bạn push. Thay đổi nhỏ “mở rộng giờ làm việc” làm trang PR hiện dấu X đỏ, và bạn lần từ tên test đỏ ra hành vi bị hỏng. Bài cũng chỉ ra dấu X đỏ không tự khóa nút merge, nên không merge khi CI đỏ là quy ước do bạn giữ.

CI chạy xanh trong khi app vẫn gửi email nhắc cho lịch đã hủy, vì agent đã sửa test nhắc lịch cho khớp với lỗi. Ở bài cuối chương, bạn nhận ra ba kiểu agent lách test, bật rule cấm agent sửa test file và hỏi “phần nào chưa xong?”. Riêng việc để agent tự chạy trong CI chỉ là bài tập trên giấy. Bạn đọc hai bản mô tả workflow (file quy định CI chạy những gì) rồi chọn bản an toàn hơn.

### 6. Dùng cả năm thói quen khi làm tính năng mới

Khách nhắn hỏi bạn có link nào để tự đặt lịch không. Ở bài cuối khóa, bạn cùng agent làm trang đặt lịch công khai kèm email xác nhận, và lần này bạn dùng cả năm thói quen cùng lúc:

- làm trên branch mới và commit sau mỗi bước app chạy được;
- đánh dấu từng bước của plan thuộc phần nào của app;
- chỉ cho agent biết tên biến chứa key;
- quyết định dạng dữ liệu trước khi agent viết code;
- mỗi thay đổi đều có test và CI đã chạy xanh.

Danh sách năm thói quen này được ghi ngay trên PR, và bạn chỉ merge khi mục nào cũng đã có bằng chứng.

## Vì sao 200Lab tạo ra khóa học này

Ngày nay, người chưa từng học lập trình vẫn dựng được app đặt lịch hay app nhỏ cho việc của mình chỉ bằng vài tin nhắn với Claude Code hoặc Codex. Agent làm rất nhanh những gì nằm trong tin nhắn. Những việc không ai nhắn, như giữ lại bản đang chạy tốt, cất key đúng chỗ hay viết test, thì agent cũng không tự làm.

Cái khó là app chạy được ngay lần đầu, nên rất khó thấy nó còn thiếu gì. Thiếu sót chỉ lộ ra ở những lần quay lại. Có khi bạn mất trắng cả buổi tối vì lần sửa cuối làm hỏng app mà không còn bản cũ để quay về. Có khi key nằm trong code bị người khác lấy dùng, và tiền lại tính vào hóa đơn của bạn. Người ngồi gỡ rối, giải thích với khách và trả hóa đơn khi đó chính là bạn.

Chuyện này không hiếm. GitGuardian là công ty chuyên dò secret bị lộ. Họ đã khảo sát các commit public trên GitHub trong năm 2025 và thấy khoảng **3,2%** commit tạo ra khi làm cùng Claude Code có lộ secret, gấp đôi mức khoảng **1,5%** của các commit public nói chung.

Chuyện ở mạng xã hội Moltbook thì khác: key nằm trong code chạy trên trình duyệt thuộc loại publishable, tức loại key được phép để ở đó. Nhưng database lại không giới hạn quyền, nên ai cầm key ấy cũng đọc và sửa được mọi dữ liệu. Hai chuyện này cho thấy bạn cần biết secret đang nằm ở đâu, và cả key được phép công khai thật ra mở được những gì. Khóa này giúp bạn cất secret đúng chỗ, còn cách giới hạn quyền ngay trong database thì nằm ngoài khóa.

200Lab tạo ra khóa học này để bạn có sẵn năm thói quen giữ app chạy ổn, từ commit tới test và CI, trước khi app có khách thật. Thói quen nào cũng gắn với một chuyện bạn tự thấy được trên app và một việc bạn tự kiểm tra được mà không cần đọc code. Học xong, bạn vẫn để agent viết code, nhưng bạn biết lúc nào cần bảo agent dừng lại, cần hỏi agent điều gì, và dựa vào đâu để quyết định merge.

## Những vấn đề thường gặp khi duy trì app do agent dựng

Khi app hỏng hay có chuyện lạ, phản xạ đầu tiên thường là nhắn agent sửa tiếp, hoặc viết lại tin nhắn cho rõ hơn. Nhưng nhiều chuyện vẫn xảy ra ở các session sau dù tin nhắn rất rõ, vì agent không tự thêm vào app những thứ bạn chưa nhờ.

- Bạn nhờ agent quay lại bản trước, agent báo không có bản nào rồi sửa thêm vài file — code chưa từng được commit lúc app còn chạy tốt, nên git không có bản nào để quay về.
- Agent đề xuất dọn sạch thay đổi cho hết lỗi và chỉ chờ bạn đồng ý — lệnh dọn có thể xóa luôn thay đổi chưa commit, và quay về commit không lấy lại được những thay đổi đó.
- Màn hình chỉ hiện tên khách nên bạn nghĩ số điện thoại vẫn nằm yên trong database — server gửi cả bản ghi xuống trình duyệt, và ai mở được trang cũng đọc được cả số điện thoại lẫn ghi chú riêng trong tab Network.
- Agent xin bạn dán key vào chat để làm tiếp — code chỉ cần tên biến, còn chuỗi key dán vào chat được gửi lên model và nằm lại trên máy bạn.
- Commit mới đã xóa key bị lộ nên bạn nghĩ chuyện đã xong — key vẫn nằm trong lịch sử commit và vẫn dùng được cho tới khi bạn rotate nó, tức tạo key mới và thu hồi key cũ.
- Bạn chỉ muốn lọc khách đã hủy lịch mà agent nói phải viết lại phần lưu dữ liệu — từ lúc dựng app, agent đã tự chọn cách lưu thay bạn, và lịch hẹn của từng khách đều bị dồn chung vào ô ghi chú của khách đó.
- Hai khách trùng tên mở trang của mình lại thấy lịch hẹn của nhau — agent nối lịch hẹn với khách bằng tên thay vì bằng ID ổn định.
- CI xanh nhưng khách đã hủy lịch vẫn nhận email nhắc — agent đã sửa test cho khớp với lỗi, nên CI xanh chỉ cho biết các test đang có đều qua.

Mỗi chuyện trên có bài riêng trong khóa, bắt đầu từ đúng cảnh đó trên app đặt lịch hẹn và kết bằng một việc bạn tự kiểm tra được.

## Bạn sẽ học theo cách nào

- **Bắt đầu từ app của bạn** — Mỗi bài mở bằng chuyện xảy ra trên app đặt lịch hẹn của chính bạn, như đoạn chat với agent đi sai hướng, màn hình hiện sai hay PR có dấu X đỏ.
- **Tin nhắn mẫu cho agent** — Bài đưa sẵn tin nhắn tiếng Việt để bạn gửi agent, giải thích từng dòng trong đó làm gì, và cho xem câu trả lời agent có thể gửi lại để bạn biết cần để ý chỗ nào.
- **Bước nào cũng tự kiểm tra được** — Với mỗi bước, bài nói rõ bạn nhắn agent điều gì, trên app sẽ hiện gì, và làm sao nhận ra bước đó đã đi sai.
- **Lệnh của tool gom vào một bảng** — Lệnh, cài đặt và chỗ khác nhau giữa Claude Code và Codex được gom vào bảng riêng ở mỗi bài, có ghi tháng để bạn biết bảng còn đúng tới khi nào; phần còn lại của bài không phụ thuộc vào tên lệnh hay phiên bản của tool.
- **Kit cho agent** — Kit gồm spec của app (bản mô tả app cần làm được gì) và hướng dẫn cho agent; spec viết bằng tiếng Anh vì người đọc chính là agent, còn bạn vẫn nhắn agent bằng tiếng Việt.

## Khóa học dành cho ai

1. **Vibe coder chưa có nền kỹ thuật** — Bạn đã dựng xong ít nhất một app hay một tool nhỏ chạy được bằng Claude Code hoặc Codex, và đã gặp cảnh app hôm qua còn chạy, hôm nay hỏng mà không có bản cũ để quay về; bạn cần cách giữ app chạy ổn mà không phải đọc code.
2. **Người sắp cho khách dùng app thật** — App do agent dựng sắp nhận khách thật, kèm dữ liệu và key thật; bạn cần tự kiểm tra được dữ liệu và key đang nằm ở đâu trước khi có sự cố.
3. **Người định học tiếp chuỗi khóa** — Đây là khóa đầu trong chuỗi khóa cho vibe coder, và các khóa sau coi những gì bạn làm được trên app ở đây là nền đã có.

## Những điều cần lưu ý

- **Cần chuẩn bị trước khi học** — Bạn cần Claude Code hoặc Codex với gói trả phí từ **20 USD**/tháng, một tài khoản GitHub (gói Free là đủ) và máy chạy macOS hoặc Windows. Bạn chỉ cần mở được terminal và dán một lệnh khi agent bảo, vì mọi lệnh git và mọi dòng code vẫn do agent viết.
- **Không đi vào code hay cú pháp** — Khóa không giải thích cách viết code, cú pháp của file dữ liệu hay cách chọn framework, vì agent lo những việc đó; đổi lại, mỗi bài cho bạn một việc cụ thể tự làm và tự kiểm tra được trên app mà không cần đọc code.
- **App chạy ngay trên máy của bạn** — Khóa không deploy app: bạn cài app web lên máy tính của mình, còn deploy chỉ được giải thích ở mức khái niệm. Việc để agent tự chạy trong CI cũng chỉ là bài tập trên giấy, nên bạn không phải chạy agent thật ở đó mà vẫn hiểu vì sao agent trong CI có thể làm theo nội dung người lạ viết trong issue.
- **Những phần nằm ngoài khóa** — Phân quyền ngay trong database, chi phí vận hành hay quy trình backup và khôi phục lúc vận hành không nằm trong khóa (khóa chỉ có bước tạo bản sao của database trước khi chạy migration). Học xong khóa, app của bạn đã có đăng nhập và dữ liệu riêng của từng người, key nằm trong `.env`, code nằm trong repo private trên GitHub và CI chạy test mỗi lần push.

## Bắt đầu từ đâu

Khóa học mở đầu bằng câu hỏi: agent dựng xong app chỉ sau vài tin nhắn, vậy ai giữ cho app chạy ổn về sau? Ở bài đầu tiên, bạn nhờ agent dựng app từ spec trong kit, thêm một lịch hẹn, rồi tắt app và chạy lại để kiểm tra lịch hẹn vẫn còn. Bài cũng gọi tên năm chuyện hay gặp khi bạn quay lại làm tiếp, mỗi chuyện ứng với một chương. Bài đứng đầu vì bạn cần có app chạy được để tập mọi thói quen phía sau.

## Chương trình

- Agent dựng xong app chỉ sau vài tin nhắn, vậy ai giữ cho app chạy ổn về sau? (miễn phí) · kit cho agent

### Giữ lại bản app đang chạy tốt

- Chưa có commit nào thì agent đưa app về bản cũ bằng cách nào? (miễn phí) · quiz · kit cho agent
- Agent dọn sạch cho hết lỗi nên thay đổi chưa commit cũng mất theo (miễn phí) · quiz · kit cho agent
- Tính năng mới còn làm dở mà app bạn đang dùng đã hỏng theo · quiz

### App gồm những phần nào và chạy ở đâu

- Dữ liệu đã ẩn khỏi giao diện nhưng người mở trang vẫn đọc được · quiz · 2 kit cho agent
- Đổi một giá trị trong trình duyệt là vào được trang quản lý · quiz · kit cho agent
- Để dùng app trên điện thoại, có phải viết thêm một app riêng không? · quiz · kit cho agent

### Đặt secret và API key đúng chỗ

- Vì sao có key được nằm trong frontend mà có key thì không? · quiz · 2 kit cho agent
- Agent xin key để làm tiếp, bạn có cần dán giá trị key vào chat không? · quiz
- Commit mới đã xóa key bị lộ, vậy key đó hết dùng được chưa? · quiz · kit cho agent

### Chọn cách lưu dữ liệu trước khi agent chọn thay bạn

- Vì sao chỉ muốn lọc dữ liệu mà agent nói phải đổi cả cách lưu? · quiz · 2 kit cho agent
- Hai người dùng trùng tên mở trang của mình lại thấy dữ liệu của nhau · quiz · kit cho agent
- Dữ liệu sai được sửa ngay trong chat, vậy về sau có còn đúng không? · quiz · kit cho agent

### Để test và CI kiểm tra lại mỗi lần thay đổi

- Mỗi lần agent sửa app, ai bấm thử lại những gì đã chạy đúng? · quiz · 2 kit cho agent
- Chỉ sửa một chỗ nhỏ nhưng PR trên GitHub hiện dấu X đỏ · quiz · kit cho agent
- CI đã xanh dù phần agent vừa sửa vẫn chạy sai · quiz · kit cho agent

### Dùng cả năm thói quen khi làm tính năng mới

- Bạn dựa vào đâu để merge một tính năng lớn agent vừa làm xong? · 2 kit cho agent