# Cách Owain Lewis code với AI agent bằng spec-driven development

[Owain Lewis](https://homus.dev/speakers/owain-lewis) · [Owain Lewis](https://homus.dev/orgs/owain-lewis)

> Viết spec ngắn có why, what, constraint và task nhỏ trước khi giao cho agent, rồi chạy từng task trong session mới, review và commit.

Topics: Product Spec, Coding Agents, Workflow

Canonical: https://homus.dev/talks/how-i-code-with-ai-agents-spec-driven-development

## 1. Một cách làm spec-driven development đơn giản hơn

Owain Lewis mở đầu: nếu bạn viết code với AI, có lẽ bạn đã nghe tới cụm từ spec-driven development. Trong video này (đăng ngày 30/01/2026), anh muốn giải thích nó chính xác là gì, và bạn có thể đưa nó vào workflow của mình ra sao để nâng chất lượng code sinh ra khi làm việc với AI agent.

Một trong những khó khăn lớn mà anh gặp khi tìm hiểu chủ đề này là có quá nhiều framework khác nhau, quá nhiều thuật ngữ khác nhau, và không ai thật sự thống nhất cách implement spec-driven development. Theo Owain (video đăng ngày 30/01/2026), mỗi người đang làm theo một kiểu hơi khác nhau.

Vì vậy, anh đưa ra một cách nhìn có chính kiến riêng (opinionated) và đơn giản hơn nhiều: cách chính anh dùng spec-driven development trong workflow của mình (video đăng ngày 30/01/2026).

![Owain Lewis nói trước camera, góc dưới có nhãn Spec Driven Development](https://homus.dev/photos/RhaF4LVAVng-0003.jpg)

Owain Lewis ngồi trước micro ở phần mở đầu video đăng ngày 30/01/2026, với nhãn "Spec Driven Development" ở góc dưới bên trái.

## 2. Spec là gì: một bản hợp đồng cho code

Anh bắt đầu bằng một định nghĩa ngắn. Theo Owain (video đăng ngày 30/01/2026), spec-driven development là ý tưởng rằng thay vì prompt trước rồi vừa làm vừa tính, bạn định nghĩa một specification ngay từ đầu. Specification ở đây là một tài liệu mô tả ý định (intent) của bạn về thứ bạn muốn build.

Đó là một tài liệu ngắn, định nghĩa ba thứ: bạn đang build cái gì; các constraint: những gì bạn không build và không làm; và các quyết định quan trọng (key decisions). Anh ví nó như một bản hợp đồng (contract) mà bạn có thể dùng để quy định code của mình nên hoạt động thế nào (theo video đăng ngày 30/01/2026).

Ba thứ một spec định nghĩa, theo định nghĩa Owain đưa ra trong video đăng ngày 30/01/2026.

## 3. Ví dụ "add authentication": từ prompt mơ hồ đến spec rõ ràng

Anh lấy ví dụ: khi bạn bảo một AI agent đi thêm authentication cho ứng dụng, có rất nhiều thứ cần cân nhắc khi build một feature như vậy. Theo Owain (video đăng ngày 30/01/2026), Claude khá tốt trong việc chủ động hỏi bạn vài câu để làm rõ, nhưng rốt cuộc vẫn có quá nhiều quyết định bạn phải đưa ra về cách implement feature này.

Nếu bạn để agent tự làm một mình, theo anh (video đăng ngày 30/01/2026), nó sẽ đoán xem bạn thực sự muốn gì, và nó sẽ đưa ra những quyết định có thể không khớp với cách feature lẽ ra phải được build.

Cách sửa, theo Owain (video đăng ngày 30/01/2026), là dùng spec-driven development. Thay vì bảo AI "add authentication", bạn làm việc cùng agent để viết một specification, là một bản kế hoạch cho thứ bạn muốn. Bạn định nghĩa mình đang build gì và các constraint: không muốn thêm library nào, feature nên được implement ra sao, có nên thêm test không, thêm test thế nào, nên dùng library nào. Khi đó AI không phải đoán bạn muốn gì.

Trước đây, bạn có thể có một prompt mơ hồ kiểu "add authentication to the app". Với một spec, anh nói bạn có thể rất, rất rõ ràng: bạn muốn JWT token, bạn không muốn password reset, không muốn OAuth, không muốn cài dependency mới. Theo Owain (video đăng ngày 30/01/2026), lúc đó bạn đang nói với AI agent rõ ràng hơn nhiều về điều bạn muốn và điều gì nằm trong scope.

Trang README trong repo mà anh mở trong video đăng ngày 30/01/2026 có hai khối mẫu "Before (Vague Prompt)" và "After (Spec)":

```
Before (Vague Prompt)

Add authentication to the app

After (Spec)

Email and password auth using the existing user table.
JWT tokens stored in httpOnly cookies.
Login and signup pages only.
No password reset for v1.
Don't add OAuth.
Don't install new dependencies.
```

![README trên GitHub với hai khối Before (Vague Prompt) và After (Spec)](https://homus.dev/photos/RhaF4LVAVng-0103.jpg)

README của thư mục spec-driven-development trong repo youtube-tutorials, ở hai khối "Before (Vague Prompt)" và "After (Spec)" mà Owain đang giải thích (video đăng ngày 30/01/2026).

## 4. PRD, design doc và AI spec

Owain nói thêm một điều: có rất nhiều nhầm lẫn quanh thuật ngữ. Anh nghe những từ như PRD, technical design doc, spec, và tất cả có thể hơi gây rối. Theo anh (video đăng ngày 30/01/2026), mọi người đang dùng các thuật ngữ này theo những cách rất khác nhau.

Trong đầu anh, cách ngành software engineering vẫn vận hành là thế này (theo Owain, video đăng ngày 30/01/2026). Thường có một product requirements document (PRD). Tài liệu này dành cho con người đọc: product manager, stakeholder, để quyết định chúng ta đang build gì, vì sao build, feature này mang lại giá trị kinh doanh gì.

Tiếp theo, ở phần lớn các công ty công nghệ, với bất kỳ feature đáng kể nào, sẽ có một dạng tài liệu architecture hay design doc. Theo anh (video đăng ngày 30/01/2026), tài liệu này dành cho kỹ sư, và nó xoay quanh việc chúng ta build thứ gì đó như thế nào: nghĩ về architecture, về constraint, về scalability, security và mọi thứ quan trọng mà kỹ sư phần mềm phải cân nhắc khi build bất cứ thứ gì.

Tài liệu thứ ba là AI spec, chủ đề của video. Theo Owain (video đăng ngày 30/01/2026), đây là tài liệu được thiết kế riêng cho AI agent. Những gì đưa vào đó không nhất thiết được thiết kế cho con người, mà giống một tài liệu thực thi (execution document) cho agent hơn.

Anh cho rằng (video đăng ngày 30/01/2026) một spec cho agent có lẽ nên có một ít why và how, một ít context về thứ đang build và lý do, vì điều đó giúp AI agent khi nó cần lấp chỗ phải đoán hoặc phải tự quyết. Nhưng nó không phải một cuộc tranh luận; nó giống một bản kế hoạch mà agent sẽ thực thi cho bạn.

![Mục This Isn't a PRD với bảng Document, Audience, Purpose](https://homus.dev/photos/RhaF4LVAVng-0223.jpg)

Mục "This Isn't a PRD" trong README: bảng ba dòng PRD (PMs / Stakeholders, define the business value), Design Doc (Engineers, define the architecture) và AI Spec (Agents, define exact boundaries & tasks), như repo hiển thị trong video đăng ngày 30/01/2026.

## 5. Một spec điển hình: why, what, constraints và tasks

Tiếp đó Owain mở một ví dụ về một spec điển hình. Nó có phần what và why, khá giống các phần tử của PRD: vì sao chúng ta build thứ này, chúng ta đang cố giải quyết điều gì (theo video đăng ngày 30/01/2026).

Nhưng quan trọng hơn, theo anh (video đăng ngày 30/01/2026), chúng ta còn muốn định nghĩa các constraint cho thứ đang build. AI agent, hay coding agent nói chung, khá hăng hái giải quyết vấn đề: chúng sẽ cố implement thứ được giao, cố làm cho nó chạy. Nhưng có thể có những yêu cầu nhất định ta muốn áp đặt, như không dùng library bên ngoài, hoặc không dùng một số design pattern. Một số thứ có thể nằm ngoài scope.

Quay lại ví dụ add authentication, anh nói (video đăng ngày 30/01/2026) có quá nhiều thứ có thể được coi là trong scope ở đó. Bạn muốn thu hẹp công việc lại đúng vào thứ mình muốn.

Rồi cuối cùng, ta muốn chia công việc thành một số task rời rạc (discrete task). Task một: build gì, động vào file nào, và làm sao để kiểm chứng task đó đã xong. Theo Owain (video đăng ngày 30/01/2026), đây cũng là cách một team kỹ sư chia task: chia công việc thành nhiều task, giao cho kỹ sư làm; xong một task, kỹ sư thường test, đưa lên code review, và vòng lặp ở đây với agent cũng vậy.

Template spec trong README, như repo hiển thị trong video đăng ngày 30/01/2026, có dạng sau (một đoạn của template, phần sau còn tiếp các task khác):

```
# Feature Name

## Why

[1-2 sentences: What problem this solves. Why it matters now.]

## What

[Concrete deliverable. Specific enough to verify when done.]

## Constraints

### Must
- [Required patterns, libraries, conventions]

### Must Not
- [No new dependencies unless specified]
- [Don't modify unrelated code]

### Out of Scope
- [Adjacent features we're explicitly not building]

## Current State

[What exists now. Saves agent from exploring.]

- Relevant files: `path/to/file.ts`
- Existing patterns to follow

## Tasks

### T1: [Title]
**What:** [What to build]
**Files:** `path/to/file`, `path/to/test`
**Verify:** `command to run` or manual check
```

![Template spec với các mục Why, What, Constraints, Current State, Tasks](https://homus.dev/photos/RhaF4LVAVng-0343.jpg)

Template spec trong README: Why, What, Constraints (Must, Must Not, Out of Scope), Current State và Tasks với What, Files, Verify cho từng task, như repo hiển thị trong video đăng ngày 30/01/2026.

## 6. Workflow: generate, review, chạy từng task, commit

Owain chuyển sang một cái nhìn high level về cách làm việc với spec workflow. Bước đầu là generate một spec. Theo anh (video đăng ngày 30/01/2026), nếu bạn có một khối việc đủ lớn, cần chia thành nhiều task, có thể bạn sẽ làm nó qua nhiều coding session.

Bạn generate spec bằng một meta prompt: bạn mô tả với AI agent thứ mình muốn build, và agent viết ra một spec ban đầu. Sau đó bạn review spec, iterate trên nó, kiểm tra mọi chi tiết trong spec đều đúng, và bảo đảm agent không phải đoán các chi tiết implement (theo Owain, video đăng ngày 30/01/2026).

Tiếp theo bạn chia công việc thành một số task bên trong spec, và agent cũng có thể giúp bạn làm việc này. Rồi bạn chạy từng task một cách độc lập, review công việc, iterate, và commit. Theo anh (video đăng ngày 30/01/2026), điều này hay ở chỗ bạn có thể đi dần qua từng task, từng bước một.

Anh nói (video đăng ngày 30/01/2026) đây cũng là cách ta vẫn luôn build phần mềm: bạn không bắt đầu bằng việc đưa cho một kỹ sư cả một tài liệu feature rồi bảo đi build; bạn thường giao cho kỹ sư đó một task, và kỹ sư làm dần qua vấn đề, từng bước một.

![Sơ đồ Excalidraw Spec-Driven Development Workflow với bốn bước và khối Spec File](https://homus.dev/photos/RhaF4LVAVng-0452.jpg)

1. Generate Spec (metaprompting), 2. Review & Refine (your decisions), 3. Run Task (fresh session), 4. Review, Iterate, Commit (human review), lặp lại cho mỗi task; khối SPEC FILE liệt kê Why, What, Constraints, Current State, Tasks (video đăng ngày 30/01/2026).

## 7. Spec mẫu: thêm JWT authentication

Anh mở một ví dụ specification: một spec giả định cho việc thêm JWT authentication vào app. Spec bắt đầu bằng Why: user hiện đang dùng chung một tài khoản; cần tài khoản riêng để theo dõi mức dùng của từng user cho việc tính tiền (billing) và để bật các thiết lập cá nhân (spec mẫu trong video đăng ngày 30/01/2026).

Rồi phần What: user có thể register, log in và refresh token; auth dựa trên JWT với access token một giờ và refresh token bảy ngày. Owain chỉ ra (video đăng ngày 30/01/2026) rằng ở đây đã có khá nhiều chi tiết thực sự quan trọng cho việc implement: access token một giờ, refresh token bảy ngày. Theo anh, đây là loại chi tiết sẽ bị bỏ sót nếu bạn để AI agent tự thực thi một task định nghĩa lỏng lẻo hơn.

Spec cũng nói rõ cách cấu trúc API. Theo Owain (video đăng ngày 30/01/2026), khi AI agent nhận được specification này, nó hoàn toàn rõ ràng và không mơ hồ về thứ phải build, nên agent không phải đoán bạn muốn gì.

![File jwt-authentication.md với các mục Why, What và Constraints](https://homus.dev/photos/RhaF4LVAVng-0603.jpg)

File ví dụ jwt-authentication.md: Why, What với bốn endpoint /auth/register, /auth/login, /auth/refresh, /auth/me, và phần đầu của Constraints, như repo hiển thị trong video đăng ngày 30/01/2026.

Spec còn định nghĩa constraint: dùng những library cụ thể, lưu dữ liệu user trong Postgres qua Prisma, và quy định cách xử lý lỗi. Nó cũng nói bạn không được thêm dependency mới và không được lưu token trong database. Rồi có phần out of scope, những thứ mà AI agent có thể sẽ tự implement nếu không được dặn vì, như anh nhắc lại (video đăng ngày 30/01/2026), chúng rất hăng hái build. Một đoạn của phần Constraints trong file:

```
Must
- Use existing Express app structure in src/server.ts
- Use jsonwebtoken library (already in package.json)
- Store users in existing Postgres via Prisma
- Follow error handling pattern in src/lib/errors.ts

Must Not
- Add new dependencies
- Modify existing user-facing routes
- Store tokens in database (stateless JWT)

Out of Scope
- Password reset flow
- Email verification
- OAuth / social login
```

Sau đó công việc được chia thành nhiều task. Theo Owain (video đăng ngày 30/01/2026), đây là cách một senior engineer có thể chia bất kỳ khối việc nào: bắt đầu bằng thêm user model; implement task đó, verify bằng vài test, review code, commit thay đổi, rồi chuyển sang task kế. Kế đó là thêm các endpoint: tạo login endpoint, tạo refresh endpoint, cứ thế đi qua cả feature cho tới khi xong. Sau khi hoàn tất từng phần riêng, có thể bạn muốn thêm vài test để kiểm tra luồng end-to-end và bảo đảm mọi thứ chạy đúng.

Anh nói (video đăng ngày 30/01/2026) có rất nhiều chi tiết ở đây để AI agent tiếp nhận, nên khi agent implement, nó rất rõ phải làm gì.

## 8. Spec không phải waterfall

Owain lưu ý (video đăng ngày 30/01/2026): khi đi qua specification, có thể bạn implement task một, review code, và thấy có gì đó sai trong code, hoặc muốn đổi một thứ. Bạn luôn có thể quay lại sửa spec.

Theo anh (video đăng ngày 30/01/2026), đây không phải kiểu thiết kế waterfall, nơi bạn phải biết mọi thứ từ đầu. Bạn muốn đưa cho agent đủ chi tiết về việc nó cần làm. Bạn có thể tinh chỉnh spec, cho agent thực thi, thấy có gì sai, rồi quay lại sửa. Anh nói điều đó hoàn toàn ổn.

Vòng sửa spec Owain mô tả trong video đăng ngày 30/01/2026: spec được tinh chỉnh dần sau mỗi lần agent thực thi, không phải viết xong một lần như waterfall.

## 9. Spec mẫu thứ hai: hybrid search với pgvector

Ví dụ tiếp theo là thêm hybrid search với pgvector. Theo Owain (video đăng ngày 30/01/2026), đây là một feature phức tạp, có rất nhiều chi tiết.

Anh nói (video đăng ngày 30/01/2026) nếu bạn đưa việc này cho một AI agent, hoặc vibe code nó, cứ để agent build mà bạn không góp ý gì, thì có rất nhiều thứ agent có lẽ sẽ làm sai. Có quá nhiều thứ phải nghĩ: dùng bao nhiêu dimension cho text embedding; dùng FastAPI; dùng library của OpenAI cho embedding. File hybrid-search.md trong repo ghi ở phần Must: "Use pgvector extension (1536 dimensions for text-embedding-3-small)", "Use existing FastAPI app structure", "Follow async patterns throughout", "Use OpenAI for embeddings" (repo trong video đăng ngày 30/01/2026).

Một lần nữa, công việc được chia thành nhiều task, bắt đầu bằng việc thêm extension pgvector. Theo anh (video đăng ngày 30/01/2026), đây đúng là việc bạn sẽ làm với tư cách kỹ sư phần mềm: lấy một bản design, một senior engineer hay tech lead chia công việc thành nhiều task, bạn làm từng task riêng, từng bước, và review công việc dọc đường. Và đó đúng là điều đang làm với agent.

## 10. Demo: app YTIQ và feature phân tích video

Owain chuyển sang xem cách làm này trong thực tế. Anh đang build một ứng dụng tên là YTIQ, một phần mềm anh tự build cho chính mình. Ý tưởng của ứng dụng là bạn có thể theo dõi các kênh cụ thể, và nó sẽ hướng dẫn, coach bạn, đưa ra insight về các video và cách cải thiện nội dung video nói chung (demo trong video đăng ngày 30/01/2026).

Anh cho xem (demo trong video đăng ngày 30/01/2026) một loạt video đang được theo dõi; một chức năng nhận coaching cho kênh của bạn, nơi app đưa ra feedback; và chức năng ideate: bạn có thể nghiên cứu một chủ đề, tìm các video đang trending về chủ đề đó, và nhận gợi ý tiêu đề cùng những thứ tương tự. Bây giờ anh muốn thêm một feature mới cho ứng dụng này.

![Trang Ideate của app YTIQ với ô nhập Spec driven development và danh sách gợi ý tiêu đề](https://homus.dev/photos/RhaF4LVAVng-1003.jpg)

Trang Ideate của YTIQ chạy trên localhost: ô "Generate Title Ideas" với chủ đề "Spec driven development" và danh sách tiêu đề gợi ý chia theo nhóm (demo trong video đăng ngày 30/01/2026).

Chuyển sang terminal, anh mô tả feature muốn build: một feature phân tích video. Ý tưởng là dán vào một URL YouTube, rồi AI sẽ phân tích video đó: kéo lời thoại của video về và sinh ra một loạt insight về video, về phần mở đầu, các ý chính, nhịp độ (pacing), để hiểu được video đó (demo trong video đăng ngày 30/01/2026).

## 11. Slash command /spec sinh ra spec đầu tiên

Cách anh làm (theo Owain, video đăng ngày 30/01/2026): anh có một slash command tên là `spec`, và anh mô tả thật ngắn thứ mình muốn build. Lệnh anh gửi, hiện lại trong terminal Claude Code:

```
/spec Help me design a feature that allows a user to paste in a YouTube URL. The idea is that AI will analyse that video, it'll pull down the transcript, and tell us all about the video - what made it work. We're going to analyse the hook, the pacing, and the key points of the video. And then you're going to give suggestions about how to improve the video. I want you to do this in a new tab. This is going to be a new UI feature. We're going to have it under an Ideate tab. Help me design this back.
```

Như vậy anh để AI giúp build specification. Theo Owain (demo trong video đăng ngày 30/01/2026), command này dùng một template. Anh đã có sẵn một spec cũ và sẽ ghi đè lên nó. Claude hỏi lại feature phân tích video nên nằm ở đâu trong UI; anh chọn một trang Analyze mới.

![Terminal Claude Code: lệnh /spec và câu hỏi Where should this Video Analysis feature live in the UI](https://homus.dev/photos/RhaF4LVAVng-1123.jpg)

Claude Code sau lệnh /spec: nó báo đã có spec tại .ai/specs/video-analysis.md và hỏi "Where should this Video Analysis feature live in the UI?", với lựa chọn đầu là trang "Analyze" mới, gắn nhãn Recommended (demo trong video đăng ngày 30/01/2026).

Spec được sinh ra và chia thành một số task (demo trong video đăng ngày 30/01/2026). Task một là build một service lấy lời thoại, lấy caption qua package `youtube-transcript`; tiếp theo là prompt cho việc phân tích video; rồi tới các route; các UI component cần build; và cuối cùng là đưa feature vào sidebar. Spec được tạo dưới dạng một file markdown. Theo Owain, việc còn lại để bắt đầu làm feature này là đi thực thi task một.

## 12. Review spec và đổi cách lấy lời thoại video sang Supadata

Nhưng trước khi thực thi các task, anh nói (video đăng ngày 30/01/2026) việc cần làm là review spec và bảo đảm mọi thứ ổn. Spec vừa sinh tên là Video Analysis Feature. Why: creator muốn học từ những video thành công. What: phân tích bất kỳ video YouTube nào qua URL, trả về feedback có cấu trúc về phần mở đầu, các ý chính, pacing và những điểm cần cải thiện. Constraints: theo các pattern có sẵn, và dùng package `youtube-transcript` để lấy lời thoại (demo trong video đăng ngày 30/01/2026).

![File video-analysis.md mở trong editor với các mục Why, What, Constraints](https://homus.dev/photos/RhaF4LVAVng-1207.jpg)

File .ai/specs/video-analysis.md mà Claude Code vừa sinh, mở trong editor: Why, What, và phần Must có dòng "Use youtube-transcript package for transcript fetching" (demo trong video đăng ngày 30/01/2026).

Theo Owain (video đăng ngày 30/01/2026), đây là chỗ spec-driven development phát huy tác dụng. LLM đã đề xuất cách dùng package `youtube-transcript`. Anh muốn một cách khác, vì anh thấy một số library bên thứ ba loại này không đáng tin cậy. Thay vào đó anh muốn dùng Supadata API.

Anh nói (video đăng ngày 30/01/2026) anh thấy dịch vụ này khá tốt: bạn có 100 request miễn phí, và nó khá tốt trong việc lấy lời thoại từ video YouTube. Theo anh, đó là một API rất đơn giản, và anh thấy nhìn chung nó đáng tin cậy hơn một số package khác, những package mà anh cứ liên tục gặp vấn đề rate limiting.

Vậy là anh sửa spec: thêm yêu cầu dùng Supadata API để lấy lời thoại (demo trong video đăng ngày 30/01/2026). Theo Owain, bạn đang sửa spec dần dần trong lúc làm, và bạn có thể chỉnh bất cứ thứ gì ở đây. Bạn có thể muốn review lại bất kỳ task nào. Bạn cũng có thể generate lại spec, iterate với AI, cải thiện nó, và bảo đảm mọi thứ đúng y như bạn muốn.

Điều hay của cách tiếp cận này, theo anh (video đăng ngày 30/01/2026), là bạn có thể đi dần qua feature: implement task một, commit task đó, đi làm việc khác, mở một session Claude Code mới tinh rồi implement task hai. Bạn không bị kẹt trong một session duy nhất và có thể quay lại việc này sau.

## 13. Session mới, implement task T1

Anh khởi động Claude Code trong một session mới và yêu cầu nó implement task đầu tiên. Lời anh nói: "read the spec and implement T1". Theo Owain (demo trong video đăng ngày 30/01/2026), cách làm là đi từng bước: build task đầu, rồi làm phần còn lại của spec từng chút một.

Agent làm task và báo task một đã xong (demo trong video đăng ngày 30/01/2026): nó đã tạo service lấy lời thoại và implement những gì anh muốn. Anh chỉ ra rằng agent cũng đã verify build, một trong những yêu cầu đã định nghĩa trong task: làm xong task thì kiểm tra mọi thứ đều pass. Anh nói bạn cũng có thể yêu cầu chạy test, v.v.

![Terminal: bun run build, T1 is complete, service lấy lời thoại dùng Supadata API](https://homus.dev/photos/RhaF4LVAVng-1423.jpg)

Kết quả task T1: Claude Code chạy `bun run build`, báo "T1 is complete", tạo src/lib/youtube/transcript.ts với extractVideoId(), fetchTranscript() dùng Supadata API, transcriptToText(), và "The build passes" (demo trong video đăng ngày 30/01/2026).

## 14. Review code và cho Claude tự test service

Implement xong, anh nhanh chóng review code agent vừa sinh. Theo Owain (video đăng ngày 30/01/2026), đây là một bước quan trọng để bảo đảm mọi thứ ổn. Anh không thích logic `extractVideoId`: nó trông rất đáng ngờ với anh, vì đang dùng regular expression, và đây là loại thứ anh có thể muốn đào sâu (demo trong video đăng ngày 30/01/2026).

Anh nói (video đăng ngày 30/01/2026) agent đã implement một giải pháp nhiều khả năng chạy được, nhưng có thể không phải giải pháp tối ưu; nó có thể đã đưa ra những quyết định mà bạn, với tư cách kỹ sư, không đồng ý. Bạn có thể xem code, tất nhiên có thể bảo agent cải thiện đoạn code đó, có thể tự sửa, hoặc đơn giản là kiểm tra mọi thứ chạy được.

Trước khi sang bước hai, anh nói có lẽ sẽ có vài thay đổi muốn làm với code, nhưng anh cũng muốn kiểm tra nó chạy. Anh bảo Claude test xem service có chạy không bằng cách lấy một URL YouTube cụ thể, để xem Claude có thực thi được service và nó có làm đúng việc cần làm không (demo trong video đăng ngày 30/01/2026).

Claude gọi được service mới, và theo anh nó có vẻ đang chạy (demo trong video đăng ngày 30/01/2026): tách được video ID từ URL dài hơn, lấy được lời thoại với 18 segment, và chuyển nó thành text thuần để AI xử lý. Nó nhận ra video đó nói về gì; Claude ghi tên là "CloudBot", và anh sửa lại: thật ra là Claude bot (theo cách anh đọc), không phải cloud bot. Nhưng nó có vẻ đã lấy được lời thoại để phân tích, nên anh thấy vậy là tốt.

![Terminal: service lấy lời thoại đang chạy, Segments: 18](https://homus.dev/photos/RhaF4LVAVng-1603.jpg)

Kết quả test: dòng báo service đang chạy, Language: en, Segments: 18, và dòng "The video appears to be about "CloudBot"" mà Owain sửa lại tên (demo trong video đăng ngày 30/01/2026).

## 15. Có nên dùng framework? OpenSpec, Spec Kit và Kiro

Một câu hỏi bạn có thể đang nghĩ tới, theo Owain: có nên dùng framework để implement spec-driven development không? Anh nói (video đăng ngày 30/01/2026) có nhiều công cụ đang phổ biến. OpenSpec là một trong số đó: một framework tương đối nhẹ, bạn cài một CLI và nó sẽ generate một số file kiểu này cho bạn.

Một công cụ phổ biến khác là GitHub Spec Kit. Anh thấy (video đăng ngày 30/01/2026) nó khá nặng nề (heavyweight): nó generate rất nhiều file.

Anh đi qua workflow của Kiro (theo trang docs anh mở trong video đăng ngày 30/01/2026): bạn bắt đầu với giai đoạn requirements, định nghĩa user story và acceptance criteria. Rồi sang technical design. Anh chỉ ra rằng một lần nữa, nó ánh xạ sang product requirements doc, technical design, rồi các implementation task. Bạn chia việc thành nhiều task rời rạc, theo dõi được, rồi sang giai đoạn execution, nơi bạn đi qua hết các task và giao chúng cho agent implement.

![Trang docs Kiro mục Workflow với bốn phase và sơ đồ requirements.md](https://homus.dev/photos/RhaF4LVAVng-1632.jpg)

Trang docs Specs của Kiro, mục Workflow: Requirements Phase (user stories và acceptance criteria theo EARS notation), Design Phase, Implementation Planning, Execution Phase, kèm sơ đồ bắt đầu từ requirements.md, như trang hiển thị trong video đăng ngày 30/01/2026.

Theo Owain (video đăng ngày 30/01/2026), anh thấy nhiều thứ trong số này là quá mức cần thiết (overkill). Anh không nghĩ bạn cần định nghĩa user story trong markdown; anh cho rằng những thứ đó nên được làm theo cách truyền thống, nơi bạn định nghĩa một product requirements doc tách khá riêng khỏi phần agent thực thi. Anh cảm thấy các framework này đang thêm vào cả đống độ phức tạp. Anh không nghĩ product manager nên phải sửa file markdown; với anh điều đó không hợp lý lắm.

Với giai đoạn design cũng tương tự, theo anh (video đăng ngày 30/01/2026): anh cảm thấy có nhiều chi tiết hơn nhiều cần đưa vào một tài liệu architecture, và theo ý anh, việc đặt nó trong một file markdown không thật sự hợp lý.

## 16. Không có gì mới: các team kỹ sư vẫn luôn làm vậy

Kết lại, theo Owain (video đăng ngày 30/01/2026): nếu bạn đang build bất cứ thứ gì không tầm thường (non-trivial) với AI agent, workflow này ngăn agent tự đi implement những thứ bạn không muốn. Nó cho bạn nhiều quyền kiểm soát hơn với thứ mình đang build, và sẽ dẫn tới code chất lượng cao hơn.

Anh nói (video đăng ngày 30/01/2026) làm việc theo cách tăng dần (incremental) chắc chắn đáng chọn hơn so với để một AI agent implement 10.000 dòng code rồi bạn phải review tất cả ở cuối. Càng đi xa, càng rất khó gỡ lại mọi thứ. Vì vậy theo anh, làm việc theo cách tăng dần là cực kỳ hợp lý.

Và nếu nghĩ về spec-driven development, anh cho rằng (video đăng ngày 30/01/2026) chẳng có gì mới ở đây. Trong các team software engineering, theo anh, mọi người vẫn luôn làm việc theo cùng một cách. Với bất kỳ khối việc non-trivial nào, một product manager hay ai đó sẽ đưa ra requirement cho thứ cần build, thường trong một PRD; tài liệu này để con người thống nhất sẽ build gì. Kỹ sư thường chia công việc ra trong một technical design doc, gồm phân rã architecture và chi tiết feature sẽ hoạt động thế nào; tài liệu này thường được nhiều kỹ sư review. Rồi công việc được chia thành nhiều task rời rạc và giao cho từng developer.

Theo Owain (video đăng ngày 30/01/2026), khác biệt thật sự duy nhất ở đây là ta đang giao task cho agent.

Quy trình quen thuộc của team kỹ sư mà Owain mô tả trong video đăng ngày 30/01/2026: PRD, technical design doc, rồi task rời rạc; điểm khác là người nhận task là agent.

Vì vậy, theo anh (video đăng ngày 30/01/2026), nếu bạn đang làm bất cứ việc gì non-trivial, thì viết specification trước, lưu nó trên ổ đĩa local thành một file lâu dài (persistent), review file, chỉnh sửa, bảo đảm mọi task đều đúng và agent có đủ thông tin để implement chính xác, là một cách làm thật sự tốt. Và làm việc theo cách tăng dần sẽ nâng chất lượng code khi bạn làm việc với các AI coding agent này.

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

- Tên gốc: How I Code With AI Agents (Spec-Driven Development)
- Sự kiện: [YouTube](https://homus.dev/events/youtube)
- Video gốc: [https://www.youtube.com/watch?v=RhaF4LVAVng](https://www.youtube.com/watch?v=RhaF4LVAVng)

- Kênh YouTube Owain Lewis (Owain Lewis): [youtube.com/channel/UC08YjBHjjPFu8T1KbHGomnQ](https://www.youtube.com/channel/UC08YjBHjjPFu8T1KbHGomnQ)

- Thư mục spec-driven-development trong repo youtube-tutorials của Owain Lewis; khi đọc ngày 08/11/2026, thư mục có LESSON.md giải thích cách làm, resources/examples với các spec mẫu jwt-authentication.md và hybrid-search.md, và resources/commands với các command spec.md, task.md: [github.com/owainlewis/youtube-tutorials/…/spec-driven-development](https://github.com/owainlewis/youtube-tutorials/tree/main/tutorials/spec-driven-development)

- OpenSpec, trang chính thức tự mô tả là một spec framework nhẹ (đọc ngày 08/11/2026): [openspec.dev](https://openspec.dev)

- GitHub Spec Kit, repo chính thức (đọc ngày 08/11/2026): [github.com/github/spec-kit](https://github.com/github/spec-kit)

- Kiro, docs về Specs, có mô tả requirements với user story và acceptance criteria (đọc ngày 08/11/2026): [kiro.dev/docs/specs](https://kiro.dev/docs/specs/)

Nguồn: https://homus.dev/talks/how-i-code-with-ai-agents-spec-driven-development · cập nhật 2026-11-08