Quy trình đơn giản để dùng Claude Code trong dự án Laravel

Table of Contents

1. Bối cảnh

Có một giai đoạn mình làm một dự án Laravel dạng “đã chạy được nhưng bắt đầu nặng nợ”:

Feature mới vẫn phải build liên tục
Codebase không nhỏ nhưng cũng chưa đủ lớn để có team rõ role
Test gần như không có
Tài liệu = 0
Mỗi lần thêm chức năng là copy + sửa + pray

Deadline không quá gấp, nhưng có một áp lực khác:
mọi thứ đang chậm lại một cách âm thầm

Không phải vì mình code chậm.
Mà vì mỗi lần bắt đầu một task, mình phải:

đọc lại code cũ
đoán logic
tìm chỗ sửa
test thủ công

Lúc này mình bắt đầu thử đưa AI vào workflow, cụ thể là Claude Code.

2. Vấn đề

Cách mình (và nhiều Laravel dev) thường làm trước đó:

Case: thêm một chức năng mới

Tạo Controller
Tạo Request
Tạo Service
Tạo Model nếu cần
Viết migration
Copy logic từ feature cũ
Sửa lại chút chút

Nghe có vẻ quen đúng không?

Nhưng vấn đề là:

❌ Rất dễ copy nhầm logic cũ (bug tiềm ẩn)
❌ Naming không consistent
❌ Mỗi feature có structure hơi khác nhau
❌ Tốn 30–60 phút chỉ để “dựng khung”

Với performance, test, docs… thì còn tệ hơn:

Optimize = mò query
Test = viết nếu còn thời gian
Docs = “để sau”

Tóm lại:
Mình đang dùng thời gian cho những việc lặp lại + không tạo ra nhiều giá trị.

3. Suy nghĩ

Điểm mình nhận ra không phải là:

“AI giúp code nhanh hơn”

Mà là:

AI giúp giảm chi phí “khởi động suy nghĩ” (cognitive load)

Trước đây mỗi task đều có friction:

bắt đầu từ đâu?
structure thế nào?
có thiếu gì không?

Sau khi dùng Claude Code một thời gian, mình thấy rõ một pattern:

Nếu input đủ rõ → output dùng được 70–80%

Và 20–30% còn lại là phần dev nên làm:

hiểu business
chỉnh lại logic
tối ưu theo context

Một cái “aha moment” khá rõ:

Không nên dùng AI để “viết code thay mình”
→ mà dùng nó để generate version đầu tiên đủ đúng

4. Giải pháp

Mình không build workflow phức tạp.
Chỉ giữ một quy trình đủ đơn giản để không bị over-engineer.

4.1 Claude Code “hiểu project” trước

Sai lầm ban đầu của mình:

hỏi trực tiếp: “viết feature X”
→ kết quả generic, không khớp project

Cách mình làm sau đó:

👉 Luôn bắt đầu bằng context

Ví dụ:

This is a Laravel 10 project using:
- Service layer pattern
- Form Request for validation
- Repository for data access

Here is an example feature:
[Paste 1 feature hoàn chỉnh]

Now create a similar feature for: Order Refund

Insight:

Claude không “đọc repo của bạn”
Nó chỉ hiểu những gì bạn đưa vào

→ Vì vậy, 1 example tốt > 10 câu prompt

4.2 Setup đủ dùng (không cần cầu kỳ)

Mình không dùng setup gì phức tạp.

Chỉ cần:

1–2 file mẫu (feature chuẩn của project)
1 template prompt cơ bản

Ví dụ template:

Create a new feature with:
- Controller
- Request
- Service
- Repository (if needed)
- Migration (if needed)

Follow the coding style from the example.
Keep code simple and readable.

Thế là đủ.

Không cần build system prompt dài dòng.

4.3 Case 1: Tạo feature mới (dùng nhiều nhất)

Before:

30–60 phút dựng khung
Copy paste từ feature cũ
Dễ miss validation / edge case

After:

5–10 phút có full skeleton
Code consistent hơn
Ít copy sai

Workflow:

Copy 1 feature chuẩn
Mô tả feature mới
Generate
Review + chỉnh lại

👉 Quan trọng: không merge code ngay

Luôn:

đọc lại
check naming
validate logic

4.4 Case 2: Tối ưu performance (đúng chỗ mới dùng)

Không phải lúc nào cũng hỏi AI:

“optimize query này”

Cách mình dùng hiệu quả hơn:

This query is slow (~2s):
[query]

Context:
- table size: ~1M rows
- indexes: [list]
- usage: API list endpoint

Suggest improvements and explain why.

Insight:

Claude khá tốt ở việc đề xuất hướng
Nhưng không thay thế được profiling thật

👉 Dùng để:

gợi ý index
phát hiện N+1
refactor query

👉 Không dùng để:

“tin tuyệt đối”
optimize production mà không test

4.5 Case 3: Viết PHPUnit (cái mình từng lười nhất)

Trước đây:

Viết test = tốn thời gian
Hay skip

Sau khi dùng Claude:

Write PHPUnit tests for this service:
[code]

Cover:
- success case
- validation fail
- edge cases

Cover: – success case – validation fail – edge cases

Kết quả:

Có test base nhanh
Coverage tốt hơn

Nhưng:

❗ Test do AI viết thường “đúng syntax, sai logic”
→ luôn cần review

4.6 Case 4: Tạo tài liệu từ code

Đây là thứ mình không expect mà lại rất hữu ích.

Explain this module in simple terms:
- purpose
- main flow
- important classes

Dùng cho:

onboard người mới
tự hiểu lại code cũ

Insight:

AI rất hợp để “dịch code → ngôn ngữ con người”

4.7 Case 5: Review code từ tài liệu thiết kế

Một trick khá hay:

Here is the design:
[design doc]

Here is the implementation:
[code]

Check if the implementation matches the design.
List mismatches.

Giúp phát hiện:

thiếu flow
sai logic
over-engineer

Before / After (thực tế nhất)

Trước:

Code nhanh nhưng thiếu structure
Lười viết test
Mỗi feature hơi khác nhau
Tốn năng lượng cho việc lặp lại

Sau:

Feature có skeleton nhanh
Code consistent hơn
Test không còn bị bỏ qua
Có thêm layer “review thứ 2” từ AI

Trade-off (quan trọng nhất)

Không có gì miễn phí.

1. Dễ bị “lười suy nghĩ”

Nếu lạm dụng:

copy code AI
không hiểu

→ technical debt sẽ tăng nhanh hơn

2. Output không luôn đúng

sai subtle logic
thiếu edge case

→ luôn cần review

3. Phụ thuộc context

prompt kém → output kém
example sai → nhân bản lỗi

Kết luận

Thứ thay đổi lớn nhất không phải là tốc độ code.