Từ quảng cáo đến kỹ thuật: Bài học kỹ thuật từ việc xây dựng DIALØGUE

*Đây là bài đi sâu kỹ thuật đi kèm với bài giới thiệu DIALØGUE. Nếu bạn chưa đọc về DIALØGUE là gì và tại sao tôi xây dựng nó, hãy bắt đầu từ đó!*

Hành trình: Từ chuyên gia quảng cáo đến kỹ sư Full-Stack

Được rồi, hãy nói về con voi trong phòng — vâng, tôi đến từ ngành quảng cáo. Đúng, media plan và creative brief, không phải data structures và algorithms. Nhưng điều buồn cười là: hiểu cách hệ thống hoạt động, dù là phễu marketing hay kiến trúc phân tán, đều cần cùng tư duy phân tích. Khác biệt? Trong kỹ thuật, khi bạn sai, máy tính cho biết ngay. Không cần đợi kết quả chiến dịch haha.

Xây dựng DIALØGUE thật sự... căng thẳng. Không chỉ viết code (dù có rất nhiều). Mà là kiến trúc một hệ thống phức tạp phải phối hợp nhiều dịch vụ AI, xử lý workflow bất đồng bộ, và không sụp đổ khi người dùng làm điều bất ngờ. Hãy để tôi chia sẻ hành trình này thực sự dạy tôi điều gì — những điều tốt, khó chịu, và "sao không ai nói cho tôi?"

Quyết định kiến trúc: Tại sao sự phức tạp là kẻ thù

Đây là điều không ai nói cho bạn khi mới bắt đầu: sự phức tạp không phải bạn của bạn. Tôi học điều này theo cách khó. Rất khó. Hình dung tôi chìm trong CloudWatch logs, cố tìm hiểu tại sao hệ thống được kiến trúc đẹp đẽ... không hoạt động. T.T

Kiến trúc ban đầu (Quá phức tạp)

Tôi bắt đầu với LangGraph cho orchestration. Tại sao? Vì cách tiếp cận dựa trên đồ thị có vẻ rất thanh lịch! Nó sẽ cho tôi sự linh hoạt! Nó sẽ mở rộng tuyệt đẹp!

Kiểm tra thực tế: Nó chậm kinh khủng. Ngay cả chạy local. Ngay cả với cloud deployment của họ. Tất cả abstraction đẹp đẽ chỉ là... overhead. Rất rất nhiều overhead.

Kiến trúc cuối cùng (Thực dụng đơn giản)

Sau nhiều suy nghĩ (và debug), đây là thứ thực sự hoạt động:

```
Frontend (Next.js) → API Gateway → Cloud Run Services → Cloud Workflows → Cloud Storage
                ↓
            Supabase (Auth + Real-time + PostgreSQL + Edge Functions)
```

Lưu ý: Chúng tôi chuyển từ AWS Lambda/Step Functions sang GCP Cloud Run/Workflows tháng 7/2025, đạt giảm 92% chi phí và cải thiện hiệu suất 10 lần.

Phát hiện lớn: Khi chuyển sang truy vấn Supabase trực tiếp thay vì bọc mọi thứ trong API, tôi đạt cải thiện hiệu suất 10 lần (450ms → 45ms). Tất cả lớp API "đúng cách" đó? Chỉ làm mọi thứ chậm đi. Kiến trúc database-first này trở thành nền tảng cho việc chuyển đổi GCP.

Lựa chọn model AI: Vượt qua hype

Thực tế về các model

Được rồi, hãy nói về model AI. Tôi đã thử tất cả. Thực sự thử — không chỉ nghịch một buổi chiều. Sau nhiều tháng test (và đốt nhiều API credit hơn tôi muốn thừa nhận), đây là thứ thực sự hoạt động khi bạn xây dựng thứ gì đó thực:

Stack hiện tại:

- Claude (qua Claude Code) & Gemini 2.5 Pro (qua Gemini CLI): Bộ đôi phát triển cốt lõi. Hai model này đã trở nên mạnh đến mức thay thế mọi thứ khác trong workflow.

- Claude Sonnet 4 API: Vận hành tạo kịch bản DIALØGUE với temperature 0 cho độ tin cậy JSON

Stack trước đây:

DeepSeek: Tôi từng dùng để debug lỗi khó, đặc biệt những phiên khắc phục sự cố đêm muộn. Nhưng khi Claude 4 và Gemini 2.5 Pro ra mắt? Chúng xử lý edge case tốt ngang, nếu không muốn nói tốt hơn. Sự tiến hóa về khả năng model khiến model debug chuyên biệt trở nên thừa cho workflow của tôi.

Thực sự hiệu quả:

Đây là chỗ thú vị: Mỗi model đã cực kỳ mạnh khi đứng một mình. Claude xuất sắc trong tư duy kiến trúc và suy luận phức tạp. Gemini 2.5 Pro? Tuyệt vời trong triển khai và duy trì context qua codebase lớn. Bước nhảy từ Gemini 2.0 lên 2.5 điên rồ — tôi có thể cảm nhận sự khác biệt. Phản hồi nhanh hơn, context window 1M token (vâng, thật), và nó thực sự hiểu tôi đang cố xây gì.

Nhưng phép thuật thực sự nằm ở đây: khi bạn cho chúng phê bình công việc của nhau. Tôi để Claude thiết kế cách tiếp cận, rồi hỏi Gemini xem xét và đề xuất cải thiện. Hoặc Gemini tạo giải pháp, và tôi nhờ Claude phân tích edge case hay lo ngại kiến trúc. Sự trao đổi qua lại đó, quá trình phê bình cộng tác đó — là nơi bạn tìm ra giải pháp đột phá mà không model nào đạt được một mình.

Không hiệu quả (dù được hype):

OpenAI o1/o3: Mọi người nói về chúng, nhưng cho phát triển thực tế? Quá chậm, quá đắt, và thành thật không tốt hơn nhiều cho trường hợp của tôi.
GitHub Copilot Workspace: Ý tưởng hay, nhưng giới hạn token... Tôi liên tục chạm trần khi thử làm bất cứ thứ gì đáng kể

Insight thực sự: Bạn biết không ai nói cho bạn? Các model fail khác nhau. Gemini trước đây bị kẹt trong vòng lặp kỳ lạ với một số lỗi — không thể thấy vấn đề. Claude phát hiện ngay. Nhưng Claude lại overthink triển khai đơn giản mà Gemini giải quyết trong vài giây. Bí quyết không phải tìm model "tốt nhất" — mà biết khi nào chuyển đổi.

Phát triển Full-Stack: Đội nhiều mũ

Chiến lược Terminal

Đây là thứ thực tế cứu sự tỉnh táo của tôi: cửa sổ terminal riêng cho context khác nhau. Nghe đơn giản? Nó thay đổi cuộc chơi.

```bash
# Terminal 1: Tôi - Frontend Developer
cd podcast_generator_frontend_v2
npm run dev
# Đây là nơi tôi nghĩ về React components và trải nghiệm người dùng

# Terminal 2: Tôi - Backend Developer
cd gcp_services
./deploy/deploy-service.sh [service-name]
# Đây là nơi Cloud Run services sống (vui hơn Lambda nhiều!)

# Terminal 3: Tôi - Database
supabase start --workdir supabase
# Local Supabase cho test, production cho công việc thực
```

Tôi biết nghe nực cười, nhưng việc chuyển đổi vật lý giữa terminal giúp não chuyển context. Tôi frontend và tôi backend là hai người khác nhau, và họ cần không gian riêng.

Giao tiếp Cross-Stack

Làm việc solo trên full-stack thật kỳ lạ. Bạn cơ bản nói chuyện với chính mình. Nên tôi bắt đầu để lại ghi chú:

```
// Ghi chú từ Tôi Frontend gửi Tôi Backend
/**
 * BACKEND TODO:
 * - Cần endpoint GET /api/podcasts/:id/segments
 * - Cần trả về: { segments: Array<{id, title, status, content}> }
 * - Phải xử lý: 404 (không tìm thấy), 403 (không có quyền)
 * - Cập nhật real-time qua Supabase subscription thì tuyệt
 * - Tôi tương lai sẽ cảm ơn bạn vì error handling!
 */
```

```
## Tóm tắt Backend Developer cho Frontend Integration
Trạng thái hiện tại:
- Endpoints đã triển khai: POST /podcasts, GET /podcasts/:id
- Authentication: Bearer token qua Supabase JWT
- Real-time: Supabase channel "podcast-updates"

Task Frontend tiếp theo:
1. Triển khai form tạo podcast
2. Subscribe real-time updates
3. Xử lý error states (401, 403, 404, 500)
```

Những ghi chú nhỏ này? Cứu tinh tuyệt đối khi quay lại code sau một tuần và không biết tôi quá khứ đang nghĩ gì.

Bài học kỹ thuật chính

1. Tư duy hệ thống vượt qua lĩnh vực

Background quảng cáo dạy tôi tư duy hệ thống — hành trình người dùng, phễu chuyển đổi, mô hình attribution. Các mô hình tư duy này dịch trực tiếp sang:

Thiết kế hệ thống phân tán
Luồng trải nghiệm người dùng
Tối ưu hiệu suất
Chiến lược xử lý lỗi

2. Tư duy Production-First

# Tôi đã học ưu tiên gì

if works_in_production and meets_user_needs:

ship_it()

else:

fix_only_blockers()

# Hoàn hảo là kẻ thù của hoàn thành

3. Năng lực Full-Stack là thật

Xây dựng DIALØGUE đòi hỏi:

Frontend: React 19, Next.js 15, TypeScript, real-time subscriptions, quản lý WebSocket (sửa rò rỉ bộ nhớ!)
Backend: Python 3.12, Cloud Run (14 microservices), Cloud Workflows, PostgreSQL (qua Supabase)
Infrastructure: GCP (chuyển từ AWS), API Gateway, Cloud Storage, Vercel cho frontend
AI/ML: Claude 4.0, Perplexity API, OpenAI TTS, tối ưu temperature (0 cho JSON)
DevOps: Docker containers, Cloud Build, monitoring, bảo mật JWT (migration P-256)
Database: PostgreSQL với RLS, Edge Functions, atomic operations để ngăn race condition

4. Tầm quan trọng của đào tạo cổ điển

Có đào tạo kỹ thuật phần mềm chính quy (system design, data structures, algorithms) vô cùng giá trị. Không chỉ là nhờ AI viết code — mà biết yêu cầu gì và kiến trúc ra sao.

Suy nghĩ cuối

Đây là nơi tôi đã đến sau tất cả: Xây dựng DIALØGUE đã hoàn toàn thay đổi cách tôi nhìn nhận bản thân chuyên nghiệp. Trước đây tôi là người quản lý đội kỹ thuật. Giờ? Tôi thực sự có thể xây dựng cùng họ. Và thành thật, cảm giác khá tuyệt. :D Sự tiến hóa đó tiếp tục khi tôi bắt đầu xây dựng ứng dụng iOS native mà không biết Swift — hóa ra kỹ năng quảng cáo (gu thẩm mỹ, định hướng sáng tạo, biết cảm giác "tốt" là gì) quan trọng hơn kỹ năng lập trình.

Hành trình từ quảng cáo sang kỹ thuật không chỉ về học syntax hay framework. Mà về tái cấu trúc não để tư duy hệ thống, debug có phương pháp, và chấp nhận rằng đôi khi bạn sẽ mất 3 giờ cho một dấu chấm phẩy thiếu (được rồi, TypeScript bắt những thứ đó, nhưng bạn hiểu ý).

Bạn biết gì buồn cười không? Tư duy phân tích từ quảng cáo — hiểu hành trình người dùng, tối ưu phễu chuyển đổi — dịch trực tiếp sang kỹ thuật. Khác biệt là trong code, khi thứ gì đó không hoạt động, máy tính cho biết ngay. Không đợi báo cáo chiến dịch. Chỉ là feedback tức thì, thẳng thắn.

"Sản phẩm" đang chạy tại podcast.chandlernguyen.com. Nó hoạt động. Không hoàn hảo, nhưng là của tôi. Và mỗi lần sửa bug, thêm tính năng, mỗi khoảnh khắc "aha!" — tất cả đều là phần của hành trình đang diễn ra.

Bạn đã bao giờ chuyển hướng lớn như thế này — từ một lĩnh vực sang thứ hoàn toàn khác chưa? Tôi rất muốn nghe điều gì khiến bạn ngạc nhiên nhất về sự chuyển đổi. Hãy cho tôi biết!

Thân mến, Chandler

P.S: Nói về học điều theo cách khó — muốn biết cách một thay đổi tham số AI nhỏ khiến tôi tốn $54/tháng? Xem Một thay đổi tham số AI khiến tôi tốn $54/tháng. Đó là câu chuyện cảnh báo về chuyện gì xảy ra khi tin tưởng trợ lý AI với code production mà không rõ ràng về ràng buộc production. Spoiler: "làm cho nó hoạt động" và "làm cho nó sẵn sàng production" là hai yêu cầu rất khác.

P.P.S: Tôi vẫn đang tìm hiểu ngành kỹ thuật này, mỗi lần một bug. Hiện đang xây dựng ứng dụng AI và cố không phá production. Quay lại blog này để xem thêm nhé.