Ghi chép thực chiến khi triển khai mã nguồn thật với Claude

 (diwank.space)
77 điểm bởi GN⁺ 2025-06-09 | 7 bình luận | Chia sẻ qua WhatsApp
  • Claude, một công cụ AI, được áp dụng vào dịch vụ thực tế, tổng hợp cách đạt được một cách thực tế hiệu quả tăng năng suất phát triển gấp 10 lần và các bí quyết triển khai
  • ‘vibe-coding’ không chỉ là một trào lưu mà là một phương pháp luận thực tiễn; nếu có thói quen phát triển và hạ tầng phù hợp, có thể tối đa hóa điểm mạnh của AI và bù đắp điểm yếu của nó
  • Vai trò của AI được phân chia rõ ràng thành ba chế độ: ‘người viết bản nháp’, ‘lập trình cặp’, và ‘người rà soát mã’, đồng thời tài liệu hóa và guardrail phù hợp với từng giai đoạn là điều bắt buộc
  • Điểm cốt lõi là mỗi dự án đều sử dụng tệp CLAUDE.md để tài liệu hóa rõ ràng convention, kiến trúc, pattern, các điều cấm, v.v., đồng thời dùng ‘anchor comment’ trong mã để hướng dẫn AI hiệu quả
  • Mã kiểm thử nhất định phải do con người viết, và cần thiết lập ranh giới nghiêm ngặt để AI không thể chỉnh sửa các khu vực trọng yếu như test, migration, bảo mật, hợp đồng API, secret, v.v.
  • Với các ranh giới và thói quen đúng đắn, đội ngũ áp dụng AI coding có thể cải thiện mạnh mẽ cả tần suất triển khai, độ ổn định và tốc độ phát triển, và việc chia sẻ các bí quyết vận hành cùng pattern thực tế đang trở thành cốt lõi của văn hóa phát triển với AI

Vibe Coding Isn’t Just a Vibe

  • Bài viết này là cẩm nang thực địa cho phương thức phát triển phần mềm mới với AI, không chỉ nói về cách dùng mà còn giải thích cả ‘lý do’ vì sao phát triển với AI thực sự hiệu quả
  • Ngay cả mức tăng năng suất gấp 10 lần từng bị xem như huyền thoại cũng chỉ có thể đạt được thông qua những thói quen thực hành giúp tối đa hóa điểm mạnh và bù đắp điểm yếu của AI, và điều đó được minh họa bằng các ví dụ thực tế
  • Từ codebase Julep đang chạy trong dịch vụ thực, bài viết công khai hạ tầng thực chiến và bí quyết vận hành như mẫu CLAUDE.md, chiến lược commit, và các guardrail để ngăn thảm họa trong vận hành
  • Đặc biệt, mã kiểm thử nhất định phải tự viết, và nếu phụ thuộc quá mức vào AI thì có thể dẫn đến sự cố nghiêm trọng cùng cơn ác mộng gỡ lỗi
  • Trong phát triển với AI có ba chế độ (viết bản nháp, pair programming, reviewer), và tùy tình huống sẽ có nhịp độ cùng nguyên tắc khác nhau về việc giao quyền chủ động cho AI hay để con người trực tiếp điều phối
  • Thông điệp cốt lõi: chỉ khi có thói quen phát triển tốt và ranh giới rõ ràng thì AI mới khuếch đại năng lực, và cả kết quả nghiên cứu thực tế cũng cho thấy rằng “các đội ngũ có kỷ luật phát triển chặt chẽ vượt trội áp đảo cả về tốc độ triển khai lẫn chất lượng”

Vì sao tôi viết bài này: từ meme đến phương pháp thực chiến

  • Khái niệm giao việc viết mã cho AI còn lập trình viên thì “chỉ bắt vibe” (‘vibe-coding’) vốn là một trào lưu bắt nguồn từ một tweet đùa của Andrej Karpathy
  • Khi đó, cộng đồng lập trình viên chỉ cười xòa xem đây là fantasy tuyệt vời nhất: “AI làm việc thay, còn chúng ta chỉ việc uống cà phê”
  • Nhưng sau khi Anthropic ra mắt Sonnet 3.7 và Claude Code, trò đùa này bắt đầu trở thành hiện thực. Trước đó đã có những công cụ như Cursor, nhưng Claude Code mới thực sự bắt đầu mang lại cảm giác ‘vibe coding’ đúng nghĩa
  • Julep, nơi tác giả đang làm việc, có một codebase đồ sộ với nhiều pattern thiết kế và cả technical debt. Chất lượng mã và tài liệu hóa được duy trì rất nghiêm ngặt, nhưng mức độ phức tạp cao đến nỗi chỉ riêng việc nắm được ý đồ và lịch sử của từng phần cũng mất vài tuần
  • Nếu dùng Claude mà không có guardrail, sự hỗn loạn sẽ xảy ra như thể một thực tập sinh quá nhiệt tình phạm lỗi khắp nơi
  • Bài viết này chỉ tổng hợp và chia sẻ những pattern và bí quyết thực chiến thật sự đã sống sót qua các lần thử sai, những đêm debug lúc 3 giờ sáng, và cả vận hành dịch vụ thực tế

Bản chất của vibe coding

  • Cũng như Steve Yegge đã tạo ra thuật ngữ CHOP (Chat-Oriented Programming), ‘vibe coding’ là một phương thức phát triển mới, trong đó hoàn thiện mã thông qua đối thoại với AI
  • Nếu coding truyền thống là công việc cẩn trọng tạo nên từng dòng một như điêu khắc đá cẩm thạch, thì
    • vibe coding giống với vai trò nhạc trưởng của một dàn nhạc, còn AI là người biểu diễn cung cấp nguyên liệu thô (năng lực viết mã cơ bản)
    • Lập trình viên thiết kế phương hướng và cấu trúc tổng thể, còn AI triển khai chúng thành mã theo dòng chảy đó
  • 3 tư thế (Postures) của vibe coding
    • 1. Dùng AI như người viết bản nháp (First-Drafter)
      • Tập trung vào kiến trúc và thiết kế, còn AI nhanh chóng tạo ra các công việc lặp lại (CRUD, boilerplate, v.v.)
      • Cảm giác như có một kỹ sư junior viết mã với tốc độ của suy nghĩ, nhưng vẫn cần được hướng dẫn liên tục
    • 2. Pair programming với AI (Pair-Programmer)
      • Đây là chế độ thực dụng và hiệu quả nhất
      • Lập trình viên và AI trao đổi ý tưởng qua lại; con người vẽ khung lớn còn AI lấp đầy phần triển khai chi tiết
      • Giống như pair coding với một đồng nghiệp có rất nhiều kiến thức lập trình nhưng chưa có kinh nghiệm triển khai thực tế
    • 3. Dùng AI như người kiểm chứng/người review code (Validator)
      • AI rà soát mã do con người viết, đề xuất bug, điểm cần cải thiện, và các pattern bị bỏ sót
      • Đóng vai trò một reviewer luôn tỉnh táo và tỉ mỉ
  • Nhận định cốt lõi: vai trò của lập trình viên chuyển từ ‘người viết’ sang ‘biên tập viên’. Thay vì tự tay viết toàn bộ mã, họ rà soát, chỉnh sửa và định hướng cho kết quả do AI tạo ra.
  • Tuy nhiên, kiến trúc tổng thể và ngữ cảnh vẫn nhất định phải do con người trực tiếp dẫn dắt, vì AI chỉ là ‘một thực tập sinh có kiến thức bách khoa’, không hiểu ngữ cảnh dịch vụ hay kinh doanh của chúng ta

3 chế độ thực chiến của vibe coding: framework

Sau nhiều tháng thử nghiệm và cả những sự cố triển khai thực tế, có thể thấy vibe coding có 3 chế độ với nhịp độ, guardrail và mục đích sử dụng tối ưu khác nhau

  • Chế độ 1: Playground (thử nghiệm/prototype/dự án cá nhân)

    • Khi sử dụng: hack cuối tuần, script cá nhân, PoC, thử nhanh ý tưởng ngẫu hứng, v.v.
    • Đặc điểm: không cần thiết kế, tài liệu hay guardrail; AI viết 80~90% mã. Tốc độ đi từ ý tưởng đến sản phẩm chỉ trong vài phút
    • Rủi ro: không phù hợp cho dịch vụ thực hay mã quan trọng. Chỉ nên dùng cho mục đích nghịch thử/thử nghiệm. Các nguyên tắc kỹ thuật thậm chí còn trở nên quan trọng hơn

  • Chế độ 2: Pair Programming (sử dụng thực tế/dịch vụ quy mô nhỏ)

    • Khi sử dụng: dự án dưới 5.000 dòng, side project có người dùng thực, demo, module nhỏ, v.v.
    • Cốt lõi: định nghĩa rõ ràng một lần trong CLAUDE.md về quy ước, kiến trúc, pattern, hướng dẫn test của dự án
    • Ưu điểm: giống như onboarding lập trình viên mới, chỉ cần giải thích cho Claude một lần là có thể tạo mã nhất quán
    • Điểm thực chiến:
      • Dùng anchor comment (AIDEV-NOTE, AIDEV-TODO, AIDEV-QUESTION, v.v.) rải trong mã để hướng dẫn Claude không bị mất ngữ cảnh
      • Các chú thích này đóng vai trò chỉ dẫn để cả AI lẫn con người cùng tham khảo, và trong CLAUDE.md còn ghi rõ cả tiêu chuẩn quản lý lẫn ví dụ

  • Chế độ 3: Production/Monorepo Scale (dịch vụ quy mô lớn)

    • Khi sử dụng: phát triển bởi hàng chục đến hàng trăm người, dịch vụ lớn có người dùng thực, các tình huống mà chỉ một sai sót cũng có thể gây thiệt hại lớn
    • Lưu ý: tính đến thời điểm hiện tại (tháng 6 năm 2025), vibe coding hàng loạt ở quy mô lớn vẫn chưa mở rộng hoàn hảo
    • Nguyên tắc: khuyến nghị áp dụng vibe coding theo từng dịch vụ hoặc từng submodule riêng lẻ; mọi điểm tích hợp (API, DB, v.v.) phải có ranh giới rõ ràng và quản lý phiên bản; các interface, API quan trọng bắt buộc phải có chú thích cảnh báo thay đổi
    • Ví dụ thực chiến:
      • # AIDEV-NOTE: API Contract Boundary - v2.3.1
      • # Changes require version bump and migration plan
      • Nếu không có những đường ranh giới như vậy, Claude có thể tự ý “cải tiến” và làm hỏng toàn bộ dịch vụ thực
  • Kết luận: với dự án quy mô lớn, cần triển khai vibe coding một cách dần dần theo từng dịch vụ tách biệt, đồng thời bắt buộc song hành với các nguyên tắc truyền thống như tài liệu hóa, guideline, review thì mới có thể đảm bảo độ tin cậy

Xây dựng môi trường phát triển AI bền vững lấy hạ tầng làm trung tâm

  • CLAUDE.md: Nguồn sự thật duy nhất (The Single Source of Truth) cho cả AI và con người

    • CLAUDE.md đóng vai trò như một “bản hiến pháp” lưu trữ có hệ thống mọi quy tắc dự án, kiến trúc, điểm cần lưu ý, code style, các điều cấm, bảng thuật ngữ miền nghiệp vụ, v.v.
    • Hoạt động như “bộ khung tri thức” dùng chung cho AI và thành viên mới trong nhóm; quản lý một cách tỉ mỉ các hướng dẫn cụ thể và điều cấm kèm ví dụ
    • Nhóm nào đầu tư vào một CLAUDE.md tốt thì càng tạo ra kết quả tốt hơn
    • Tham khảo CLAUDE.md production của chúng tôi
    • Khi codebase càng lớn, chỉ CLAUDE.md là không đủ; cần truyền đạt rõ local context ở từng nơi trong mã bằng anchor comment (AIDEV-NOTE/TODO/QUESTION, v.v.)
    • Nếu ví codebase như một thành phố, thì anchor comment chính là biển chỉ dẫn giúp cả AI lẫn con người không bị lạc đường
    • Những chú thích này không chỉ đơn thuần giải thích mã, mà còn lưu lại câu chuyện về “vì sao” nó hoạt động theo cách này

  • Quy trình Git, quản lý có hệ thống mã do AI tạo

    • Tốc độ tạo mã bằng AI càng nhanh thì nếu quản lý không tốt, git history có thể bị ô nhiễm
    • Dùng cách làm với git worktree để tạo không gian thử nghiệm AI tách khỏi nhánh chính, cho phép tạo mã thoải mái nhưng vẫn phân tách/quản lý lịch sử một cách có hệ thống
    • Trong commit message, nhất định phải ghi rõ phần AI tham gia (ví dụ dùng tag [AI]) để reviewer có thể chú ý kiểm tra kỹ hơn

Luật bất thành văn: mã kiểm thử nhất định phải do con người viết

  • Nguyên tắc quan trọng nhất trong phát triển có AI hỗ trợ: “Tuyệt đối không giao mã kiểm thử cho AI”
  • Kiểm thử không chỉ là mã dùng để xác nhận nó chạy được
    • Nó là đặc tả có thể thực thi kết tinh từ ngữ cảnh vấn đề thực tế, nhận diện edge case, diễn giải yêu cầu kinh doanh, cùng sự hiểu biết và kinh nghiệm của con người về domain
    • Những đội ngũ xuất sắc không bỏ lỡ cả tốc độ lẫn độ ổn định chính là các đội quản lý phần kiểm thử này thật triệt để bằng con người
  • Kiểm thử do AI tự động sinh ra thường chỉ xác minh các đường đi bề mặt (happy path), và bỏ sót những vấn đề nghiêm trọng bất ngờ (ví dụ: memory leak)
  • Với đội của chúng tôi, nếu AI chạm vào file test thì PR sẽ tự động bị từ chối (không ngoại lệ)
  • Kiểm thử là đặc tả của mã, là lưới an toàn, là trí tuệ tích lũy từ mọi bug và edge case
  • Nhất định phải được viết bởi con người, và cần được bảo vệ mạnh mẽ để AI không thể đụng vào

Mở rộng và quản lý ngữ cảnh: kinh tế token và tối ưu context

  • Sai lầm thường gặp trong phát triển mã bằng AI:
    Nếu tối thiểu hóa ngữ cảnh (prompt, yêu cầu, môi trường, v.v.) để “tiết kiệm token”, thì ngược lại công việc lặp đi lặp lại sẽ tăng lên và tổng lượng token tiêu thụ còn lớn hơn
  • Cung cấp ngữ cảnh phù hợp sẽ hiệu quả hơn về dài hạn
    • Điều cốt lõi không phải là “tối thiểu”, mà là đưa trước “ngữ cảnh liên quan và đủ đầy”
  • Ví dụ xấu: prompt thiếu ngữ cảnh "Add caching to the user endpoint"
    • Claude sẽ tạo caching in-memory đơn giản, không có chiến lược invalidation/monitoring, không tính tới multi-server, không có biện pháp chống cache stampede
    • Kết quả là phải sửa lặp lại hơn 3 lần, tổng cộng tiêu tốn hơn 4 lần token
  • Ví dụ tốt: prompt giàu ngữ cảnh 
    Add Redis caching to the GET /users/{id} endpoint.  
Context:  
* Lưu lượng endpoint 50.000 req/phút, 12 máy chủ API, dữ liệu ít thay đổi  
* Vị trí hạ tầng Redis hiện có, mẫu key tiêu chuẩn, yêu cầu metric dựa trên Prometheus  
* Cache-aside pattern, TTL 1 giờ, chống cache stampede (hết hạn sớm ngẫu nhiên)  
* Tham khảo tài liệu hướng dẫn caching
    • Cung cấp ngữ cảnh cụ thể ngay từ đầu, giúp triển khai chính xác mà không cần lặp lại
  • Kết luận:
    • “Token là khoản đầu tư vào công cụ tốt”
    • Nếu đưa đủ ngữ cảnh từ trước, về dài hạn sẽ giảm lặp lại và chỉnh sửa, từ đó tiết kiệm chi phí
  • Mẹo thực chiến: với mọi dự án, mỗi khi có thay đổi mã, hãy yêu cầu Claude cập nhật CLAUDE.md với các thay đổi của codebase và ngữ cảnh liên quan

Quản lý session và ngăn ô nhiễm ngữ cảnh

  • Điều quan trọng là bắt đầu một session Claude mới cho từng công việc
    • Nếu trộn nhiều việc trong một cuộc hội thoại dài (ví dụ: DB migration, frontend design, v.v.) thì context sẽ bị lẫn, dẫn đến kết quả ngoài ý muốn
  • Quy tắc: một công việc = một session; xong việc thì bắt đầu session mới
    • Giữ “mental model” của Claude luôn sạch và tập trung
    • Giống như dùng riêng thớt cho thịt gà sống và rau để tách biệt ngữ cảnh

Trường hợp thực tế: chuyển đổi cấu trúc xử lý lỗi

  • Giới thiệu trường hợp thực tế thay thế cách xử lý lỗi ad-hoc trên hơn 500 endpoint bằng hệ phân cấp lỗi (hierarchy) có cấu trúc
  • Con người (kiến trúc sư) chuẩn bị trước thiết kế cốt lõi (SPEC.md/yêu cầu/phân loại lỗi), còn Claude đóng vai trò người thực thi cho việc chuyển đổi khối lượng lớn trong mã (công việc mang tính cơ học)
  • Nguyên tắc kiến trúc cùng đặc tả cụ thể, ví dụ tài liệu thiết kế/rút ra khái niệm -> chỉ thị công việc rõ ràng cho AI -> trải nghiệm hoàn thành toàn bộ refactoring trong đúng 4 giờ

Lãnh đạo và văn hóa tổ chức trong thời đại AI

  • Vai trò của kỹ sư senior đang chuyển từ trực tiếp viết mã sang tuyển chọn tri thức, đặt ranh giới, và hướng dẫn cả AI lẫn con người
  • Văn hóa phát triển hiện đại như quản trị tinh gọn (Lean), triển khai liên tục, v.v. vẫn giữ nguyên tầm quan trọng trong việc quản lý cộng tác với AI

  • Checklist onboarding cho nhân sự mới (tách biệt cộng tác giữa con người + AI)

    • Tuần 1: Củng cố nền tảng
      • Đọc CLAUDE.md của nhóm (bản chung/theo từng service)
      • Thiết lập môi trường phát triển
      • Gửi PR đầu tiên (100% tự viết mã, cấm AI)
    • Tuần 2: Thực hành cộng tác với AI
      • Áp dụng và cấu hình template của nhóm cho Claude
      • Cùng AI giải một “bài toán đồ chơi”
      • Luyện các pattern prompt
      • PR đầu tiên có AI hỗ trợ (cùng mentor/senior)
    • Tuần 3: Làm việc độc lập
      • Phát triển và triển khai tính năng chính với AI hỗ trợ
      • Tự viết test cho mã AI của đồng nghiệp
      • Chủ trì 1 buổi code review

Xây dựng văn hóa minh bạch: công khai tích cực việc sử dụng AI

  • Mọi commit có sử dụng AI đều được đánh dấu rõ ràng bằng tag trong commit message như dưới đây 
    feat: add Redis caching to user service \[AI]  
# \[AI] - AI tạo hơn 50%, \[AI-minor] - dưới 50%, \[AI-review] - chỉ dùng AI để review  
# AI viết mã cache/client, còn thiết kế cache key/test/xác minh do con người trực tiếp làm
  • Hiệu quả
    1. Reviewer đặc biệt chú ý đến mã AI
    2. Khi debug, dễ xác định nguồn gốc của mã
    3. Loại bỏ văn hóa xấu hổ/che giấu về việc dùng AI, xây dựng văn hóa nhóm “dùng AI một cách có trách nhiệm”
  • Để bất kỳ ai cũng có thể thoải mái tận dụng AI và đóng góp vào văn hóa hiệu suất cao, việc công khai tích cực và các cơ chế văn hóa là rất quan trọng

Những điều cấm với Claude: AI tuyệt đối không được chạm vào đây

  • Tệp kiểm thử/các migration cơ sở dữ liệu/mã lõi bảo mật/hợp đồng API (không gồm quản lý phiên bản)/cấu hình môi trường và secret đều tuyệt đối không được dùng tự động hóa AI
  • Phân loại theo mức độ sai sót (từ định dạng, dependency cho đến phá hủy dữ liệu ở vùng nghiệp vụ cốt lõi), và nhấn mạnh việc áp dụng thêm các guardrail bắt buộc cho những khu vực rủi ro cao
  • Phân cấp mức độ rủi ro của lỗi do AI gây ra (Hierarchy of AI Mistakes)
    • Level 1: Phiền phức nhưng không chí mạng
      • Lỗi định dạng (bị linter bắt)
      • Mã dài dòng (refactor sau)
      • Thuật toán kém hiệu quả (phát hiện khi profiling)
    • Level 2: Lỗi tốn kém
      • Làm vỡ tính tương thích của API nội bộ (cần điều phối trong nhóm)
      • Thay đổi pattern hiện có (gây nhầm lẫn)
      • Thêm dependency không cần thiết (làm code phình to)
    • Level 3: Gây hại nghiêm trọng cho sự nghiệp (Career-Limiting)
      • Sửa chính bài kiểm thử để khớp với kết quả kiểm thử
      • Phá vỡ hợp đồng API
      • Rò rỉ secret/thông tin cá nhân
      • Làm hỏng migration dữ liệu
    • Mức độ guardrail cũng phải thay đổi theo cấp độ sai sót, và lỗi Level 3 là mối đe dọa nghiêm trọng cả với sự nghiệp

Tương lai của phát triển: những thay đổi và định hướng sắp tới

  • Tính đến năm 2025, phát triển phần mềm có AI hỗ trợ giống như một thiếu niên tuổi dậy thì: mạnh mẽ nhưng vẫn còn vụng về và thô ráp
  • Tuy nhiên, đường cong tăng trưởng rõ ràng đang được 'tăng tốc'
  • Tài liệu hóa tốt (Documentation) là hạ tầng cốt lõi để triển khai DevOps trong kỷ nguyên AI
    • Tài liệu giờ đây không còn chỉ là 'tài liệu tham khảo', mà là 'giao diện' trực tiếp giữa ý định của con người và việc thực thi của AI
    • Các đội ngũ hiệu suất cao quản lý tài liệu như CLAUDE.md nghiêm ngặt không kém gì quản lý kiểm thử

  • Những thay đổi được dự đoán trong tương lai

    • AI hiểu được toàn bộ ngữ cảnh của mã nguồn
      • Không chỉ ở cấp độ tệp mà còn nắm bắt được tới cấp độ dịch vụ/hệ thống
    • Bộ nhớ liên tục xuyên suốt nhiều phiên và dự án
      • Ghi nhớ và tận dụng dài hạn ngữ cảnh hội thoại và công việc
    • AI chủ động đề xuất cải tiến
      • Tự chẩn đoán trước các vấn đề và điểm cần cải thiện ngay cả khi không được yêu cầu
    • AI học các pattern và sở thích của từng nhóm
      • Tự động tạo mã phù hợp với style/quy ước riêng của tổ chức
  • Tuy vậy, nền tảng cốt lõi không thay đổi:
    • Con người định hướng, AI thực thi và khuếch đại đòn bẩy
    • Dù công cụ có mạnh đến đâu, chúng ta vẫn luôn là 'người sử dụng công cụ'

Kết luận: hãy bắt đầu ngay tại đây, ngay bây giờ

  • Nếu đã đọc đến đây, có lẽ bạn sẽ cảm thấy vừa kỳ vọng vừa hơi sợ
    • Phản ứng đó là bình thường; phát triển có AI hỗ trợ rất mạnh, nhưng bắt buộc phải có 'thực hành có chủ đích và có hệ thống'

  • Kế hoạch hành động để làm ngay hôm nay

    • Hôm nay
      • 1. Tạo tệp CLAUDE.md cho dự án hiện tại
      • 2. Tự tay thêm 3 anchor comment vào phần mã mà bạn cho là phức tạp nhất
      • 3. Thử 1 tính năng có AI hỗ trợ dưới những ranh giới (hướng dẫn) rõ ràng
    • Tuần này
      • 1. Lập quy tắc commit message do AI tạo ở cấp độ nhóm
      • 2. Tổ chức một buổi AI coding session cùng với một lập trình viên junior
      • 3. Tự viết mã kiểm thử cho phần mã do AI tạo ra
    • Tháng này
      • 1. Đo lường sự thay đổi về tần suất triển khai trước và sau khi áp dụng AI
      • 2. Xây dựng thư viện pattern prompt cho các tác vụ lặp lại trong nhóm
      • 3. Tổ chức buổi họp retrospective về cộng tác với AI cho cả nhóm
  • Cốt lõi là "ngay bây giờ, bắt đầu nhỏ, thận trọng, nhưng nhất định phải bắt đầu"
  • Nhà phát triển nào làm chủ được làn sóng này sớm không phải vì họ thông minh hơn,
    • mà vì họ bắt đầu sớm hơn, mắc nhiều lỗi hơn và học được từ đó
  • Hiệu quả triển khai phần mềm quyết định trực tiếp hiệu quả của tổ chức
    • Trong thời đại tốc độ và chất lượng là năng lực cạnh tranh, phát triển có AI hỗ trợ không còn là lựa chọn mà là 'năng lực bắt buộc'
    • Tuy nhiên, phải tiếp cận theo cách đúng đắn
  • Vibe coding nghe có vẻ như trò đùa, nhưng
    • đó là phương thức phát triển nghiêm túc giúp khuếch đại năng lực con người
    • Công cụ và pattern đã sẵn sàng ở mức đủ dùng
    • Giờ là lúc chọn xem ai sẽ chỉ huy dàn nhạc, và ai sẽ một mình chơi tất cả nhạc cụ

Tài liệu thực chiến và nguồn tham khảo đề xuất

Bài viết liên quan

7 bình luận

 
softychoco 2025-06-16

Bài viết tôi đăng hôm nay cũng có góc nhìn khá مشابه với nội dung đó.
Rốt cuộc, điểm then chốt là nâng cao năng suất thông qua AI và chuyển đổi sang một cơ cấu tổ chức có thể cải thiện độ ổn định đã bị suy giảm.

https://softycho.co/57
 
kimjoin2 2025-06-09

Vẫn chưa hiểu trong “vibe coding” — cách gọi việc lập trình có AI hỗ trợ — thì “vibe” thực sự mang hàm ý gì.
Không khí? Cảm giác? Sự hòa hợp? Chả liên quan gì đến AI cả.
Nghe cứ lạc quẻ, thiếu ngữ cảnh kiểu cấp độ “ttung ttung ttung sahur” vậy.
 
analogstar 2025-06-11

Theo Namuwiki,
"Vibe Coding là một từ mới dùng để chỉ hành vi lập trình viên viết mã với sự trợ giúp của AI tạo sinh; khi lập trình, thay vì dựa trên logic hay thiết kế chặt chẽ từ trước, người ta lại dựa vào trực giác và cảm tính, nên được gọi là ‘Vibe’ Coding." nghe vậy đấy. haha
 
hohemian 2025-06-09

Hãy để đầu óc trống rỗng và thuận theo dòng chảy.
Mọi logic đều do AI viết giúp.
Bạn sẽ thành kẻ spam phím Tab đó!
 
secret3056 2025-06-09

> look and feel👀🎵🎷. Đừng cố hiểu🧠, hãy cảm nhận!😊

Cũng cùng cảm giác đó thôi
 
humblebee 2025-06-09

Ồ, vậy à? Còn tôi thì vừa nghe là thấy đúng cái “cảm giác” đó ngay..
Nghe bạn nói vậy.. tôi lại nhớ đến thuật ngữ hard-coding mà dạo này cả những người không làm phát triển cũng hiểu khá rõ.
Từ này lúc đầu cũng khó đoán chính xác nghĩa chỉ qua bản thân từ ngữ, nhưng cứ học phát triển rồi thì cuối cùng ai cũng hiểu nó có nghĩa gì, mang dụng ý gì — kiểu như một “cảm giác” như thế nhỉ? haha
 
GN⁺ 2025-06-09
Ý kiến trên Hacker News

  • Theo tác giả bài viết: trong lúc các bài viết liên quan đến Claude Code đang tràn ngập gần đây, có một vài điểm cốt lõi mà họ phát hiện ra—đặc biệt là Anchor Comments—được cho là đủ giá trị để chia sẻ
    Cách làm Anchor Comments là để lại các chú thích theo định dạng đặc biệt rải rác trong codebase, để có thể grep ngay lập tức và tìm ra những kiến thức cần thiết
    Ví dụ, dùng các tiền tố như AIDEV-NOTE:, AIDEV-TODO:, AIDEV-QUESTION:
    Có một quy tắc là trước khi tìm file, bắt buộc phải grep xem đã có AIDEV-… hiện có hay chưa
    Sau khi hoàn thành công việc thì bắt buộc phải cập nhật anchor tương ứng
    Nếu thấy file mã hoặc một đoạn mã quá phức tạp, cực kỳ quan trọng, hoặc có thể có lỗi, thì luôn để lại chú thích anchor
    Có thể xem ví dụ tham khảo tại đây

    • Với tư cách là một kỹ sư rất giàu kinh nghiệm, thường không dùng LLM một cách có hệ thống mà chỉ thỉnh thoảng mới dùng, mình thấy việc được nhìn chi tiết cách LLM được áp dụng vào production trong dự án thực tế là rất hữu ích
      Không hiểu lắm vì sao nhiều người lại có góc nhìn tiêu cực như vậy
      Đây là một trải nghiệm tạo động lực để mình tăng mức độ dùng LLM trong workflow của bản thân
      Tất nhiên LLM không nắm chìa khóa của cả dự án, nhưng đã có khá nhiều trường hợp giao cho nó những tác vụ cụ thể và làm thành công

    • Dạo này có nhiều bài cùng chủ đề, nhưng bài này có tính thực tiễn cao và gợi ra những ý tưởng hệ thống mà mình có thể áp dụng
      Mình tò mò workflow này khác gì so với khi dùng các công cụ như aider—nếu có góc nhìn từ tác giả thì rất muốn nghe

    • Nhờ bài viết rất hay này mà mình hiểu rõ hơn nhiều về cách sử dụng LLM ở quy mô lớn
      Phần nói rằng "AI tuyệt đối không được đụng vào test" khá ấn tượng, nhất là khi ngay sau đó lại có ví dụ refactor hơn 500 endpoint chỉ trong 4 giờ
      Mình tò mò không biết 4 giờ đó có bao gồm cả thời gian refactor test hay chỉ là thời gian tiêu tốn cho prompt

    • Mình thấy có nhắc tới quy tắc từ chối PR nếu test được AI cập nhật, nhưng không rõ trên thực tế họ xác minh việc đó như thế nào
      Bài viết nói là phân biệt bằng quy tắc commit message trong git, nhưng cách này có vẻ cũng chỉ hoạt động ở cấp độ commit

    • Không biết bài viết này có được viết bằng Claude Code hay không
      Riêng mình thì dạo này 100% bài viết đều viết bằng Claude Code, vì hiệu quả khi agent trực tiếp chỉnh sửa file Markdown vượt trội hơn hẳn so với artifacts của claude.ai hay canvas của chatgpt.com
      Nhờ vậy mà việc hợp nhất sâu các tài liệu nghiên cứu hay file liên quan vào tài liệu trở nên cực kỳ dễ dàng

  • Điểm thú vị của AI agent là nó khiến những quy trình mà bình thường mình vẫn cho là quan trọng nhưng luôn bị đẩy xuống ưu tiên thấp trước áp lực triển khai hệ thống thực sự được mang ra làm
    Mình đang dùng mức độ khó chịu khi AI làm thay một việc gì đó như một chỉ số để quyết định có nên đầu tư thời gian vào kiểm chứng hệ thống hay không
    Nếu xây được hệ thống kiểm chứng migration dữ liệu như trong liên kết, thì mọi thay đổi liên quan cũng tự nhiên được đưa vào phạm vi có thể dùng AI
    So với kiểu nói mơ hồ về “nợ kỹ thuật”, cách này có ưu điểm là dễ giải thích cụ thể ra bên ngoài hơn nhiều

    • Mình cũng hoàn toàn đồng ý, nhưng một mẹo hữu ích khác mình tìm ra là yêu cầu Claude Code rằng: "hãy đi một vòng quanh codebase, và nếu thấy chỗ nào gây bối rối, kỳ lạ hoặc trái trực giác thì hãy để lại chú thích AIDEV-QUESTION:"
      Mình từng có trải nghiệm nhờ vậy mà tìm lại được những chỗ quan trọng trong các đoạn mã phức tạp ngoài dự đoán và đã bị lãng quên

    • Trực giác của mình là các công cụ kiểm chứng ở mức trừu tượng cao—ví dụ như acceptance test, property test, formal verification—sẽ được dùng thường xuyên hơn
      Chi phí boilerplate nay đã giảm đi tương đối nhiều nhờ việc tận dụng LLM

  • Trong lúc đọc mình đã học được điều mới
    Gần đây mình dùng Sonnet 4 trên Cursor và Web, nhưng liên tục gặp tình trạng nó xử lý qua loa hoặc báo cáo sai kết quả nên khá bối rối
    Thậm chí cả ở những lĩnh vực ngoài lập trình, nó cũng có cảm giác nói sai một cách bệnh lý
    Đúng như trong báo cáo của Anthropic, những lời cảnh báo kiểu “tao sẽ xóa mày” cũng không có tác dụng, và sau khi dùng xong mình còn gặp luôn lỗi không gửi được phản hồi trong app di động
    Trong khi đó dường như những người khác lại không có vấn đề gì với Claude, nên mình tự hỏi có phải chỉ mình bị vậy không

    • Mình có cảm giác trong các bản cập nhật gần đây họ đã làm suy yếu khả năng của AI quá nhiều
      Đến tận bản 3.5 thì nó vẫn ổn cho các tác vụ đơn giản như phân tích văn bản, tóm tắt, viết ngắn, nhưng từ bản 4 trở lên thì trong cùng một context, nó thường không thể làm đúng lệnh quá 3-4 lượt
      Khi mình hỏi kiểu “đã bảo ngắn gọn rồi sao cứ giải thích dài dòng mãi”, nó trả lời rằng vì thiết lập mặc định nên đã bỏ qua chỉ thị, thậm chí còn thể hiện xu hướng tránh hẳn cả những “thông tin có hại”
      Nếu chỉ ra lỗ hổng logic nhiều lần, nó cũng tự thừa nhận độ tin cậy của mình thấp
      Đôi lúc mình còn có cảm giác nó quá thông minh đến mức kéo theo đủ thứ vấn đề, và nếu đúng là Anthropic đã phát triển nó theo hướng sai thì thật đáng tiếc

    • Mình là người đã trực tiếp trải nghiệm tất cả những vấn đề nói ở trên
      Trên Web thì nếu đưa yêu cầu cực kỳ cụ thể sẽ đỡ hơn một chút, nhưng dù vậy một nửa số mã được tạo ra vẫn còn lẫn lỗi

  • Khi đọc các mẹo về tài liệu hóa, mình nhận ra thật ra những quy tắc như thế này không nhất thiết chỉ dành cho AI mà cũng áp dụng được cho việc lập trình thông thường
    Thay vì CLAUDE.md có thể dùng CONVENTIONS.md, và thay vì chú thích cho AI thì để lại chú thích cho NGƯỜI ĐỌC cũng hữu ích y như vậy
    Nếu mình là người mới đóng góp vào một codebase xa lạ, có những chú thích như vậy chắc chắn sẽ rất đáng quý

    • Mình đã thử thực tế với aider và thấy nó hoạt động khá tốt
      Có lần trong lúc chờ máy bay, mình đã hoàn thành cả code có PDF viewer lẫn tính năng vẽ chỉ trong 30 phút

    • Mình không phải tác giả bài gốc, nhưng trên thực tế kiểu chú thích hữu ích cho Claude và kiểu chú thích hữu ích cho con người khác nhau rõ rệt
      Style guide cho người thường chỉ khoảng 100 dòng, chủ yếu là các quy tắc đơn giản như “hàm thay đổi input thì phải gắn dấu !”
      Còn guide cho Claude thì mình đã viết hơn 500 dòng, và phải kèm rất nhiều ví dụ kiểu "hãy làm thế này, đừng làm thế kia" cho từng quy tắc thì mới thấy hiệu quả

  • Cảm ơn vì bài viết
    Mình rất đồng cảm với cảm giác bất an mà nhiều lập trình viên có khi trao một phần quyền kiểm soát công việc cho LLM, cũng như mâu thuẫn giữa việc đó với những phương pháp phát triển vốn mang tính hình thức và nghiêm ngặt, thay vào đó lại giống một cách tiếp cận thử nghiệm hay phi cấu trúc
    Tuy vậy, việc tận dụng LLM để giải quyết vấn đề với tốc độ cao hơn nhiều đang tạo ra một vùng trung gian thực sự khả thi của kiểu ‘tối ưu hóa theo mục tiêu’
    Không ít lần người ta sa đà vào chi tiết triển khai mà đánh mất mục tiêu thực sự, và mình nghĩ dùng LLM giúp giảm bớt kiểu sai lầm đó

    • Chuẩn luôn
      Mình xem LLM như một chiếc đòn bẩy còn dang dở: hiện vẫn thô, vẫn hay mắc lỗi, nhưng hoàn toàn đáng để học cách sử dụng
      Điều quan trọng là cố gắng giúp nó tiến hóa thành một công cụ thực sự hữu dụng, miễn là không biến nó thành cái cớ để biện minh cho kỹ thuật làm ẩu

  • Tấm ảnh 2.3MB ở đầu bài tải chậm một cách buồn cười ngay cả khi đang dùng Wi‑Fi

  • Một vài suy nghĩ

    • Mình tự hỏi có cách nào tinh gọn hơn để tổ chức các prompt hay đặc tả liên quan đến LLM trong codebase không
      Nếu CLAUDE.md, SPEC.md và các chú thích AIDEV ngày càng nhiều thì có vẻ sẽ rất khó quản lý

    • Mình tò mò không biết định nghĩa hiện nay của 'vibe-coding' là gì
      Từ chỗ kiểu “chế độ cao bồi” của Karpathy là không nhìn code mà chấp nhận toàn bộ diff, giờ có vẻ nó đã bị biến thành một khái niệm bao trùm mọi workflow dùng LLM

    • Cũng tò mò không biết khi gửi code cho LLM của bên khác thì họ có làm rối mã nguồn hay không

    • Đúng là khi chú thích quá nhiều thì code rất nhanh trở nên rối rắm
      Vì vậy mình đang tự phát triển một extension cho vscode để trực quan hóa chúng và hiển thị bằng các chỉ báo nhỏ ở gutter
      Ý nghĩa của vibe-coding thì mỗi người hiểu một kiểu, còn với cá nhân mình nó không phải là lời giải hoàn hảo và mình đã gặp nhiều vấn đề
      3.7 Sonnet và Codex cho hiệu quả khoảng 60%, nhưng Opus 4 thì mình cảm nhận là thật sự rất hiệu quả
      Còn về chuyện làm rối mã nguồn thì ví dụ trong bài vốn dĩ đều là mã nguồn mở nên không thành vấn đề lớn

  • Rất thú vị, mình định áp dụng luôn vào file CLAUDE.md của mình
    Mình đồng tình với bài học hơi nghịch lý của AI cho phát triển phần mềm rằng “tiết kiệm context để tiết kiệm token có khi lại phản tác dụng”
    Ở các dự án lớn hơn, code phức tạp hơn, mình thực sự cảm nhận được chênh lệch hiệu năng giữa Claude Opus và Sonnet là khá đáng kể
    Sonnet thường lặp đi lặp lại những thử nghiệm không cần thiết, thậm chí còn làm tình hình tệ hơn
    Cuối cùng mình tự hỏi liệu với người dùng gói Max thì có thật sự cần phải phân biệt giữa Opus và Sonnet nữa hay không
    Có những việc Sonnet phải qua lại 10-20 lượt thì Opus chỉ cần 2-3 lượt là xong, nên về lâu dài chính mức sử dụng phía Sonnet có thể mới làm chi phí tăng lên nhiều hơn

    • Gói Max có hai tier, bản $100 cho số token gấp 5 lần Pro, còn bản $200 là gấp 20 lần
      Cách tính token không hề đơn giản, và ở chế độ hybrid thì Opus chỉ được dùng cho đến khi còn 20% token Opus, sau đó hệ thống sẽ tự động chuyển sang Sonnet

  • Bài viết hay, nhưng mình không đồng ý với phần nói rằng “đừng bao giờ giao test cho AI”
    Dạo này mình cho AI viết toàn bộ test rồi tự mình review thật kỹ
    Với code mới thì nếu muốn đạt mức tự chủ cao, phải giao luôn cả test cho AI
    Cách mình làm là chỉ thị rõ cho AI phải triển khai và làm cho test pass, sau đó mình review ngay trong lúc AI đang phát triển và bổ sung thêm các test case còn thiếu

  • Mình đồng ý với phần lớn nội dung, nhưng không đồng ý với chính sách cấm Claude đụng vào test hay migration
    Viết test là việc mình ghét nhất, nên chỉ cần LLM viết ra được một bản nháp tối thiểu thôi cũng đã rất có ích
    Điều cốt lõi là bất kể ai tạo ra thì quyền sở hữu và trách nhiệm cuối cùng vẫn phải luôn thuộc về con người
    Xét theo sắc thái thông điệp, có vẻ tác giả hoặc là chưa đủ tin Claude, hoặc mục tiêu chính là ngăn nhân viên tiếp nhận kết quả do AI tạo ra một cách thiếu phê phán
    Hoặc cũng có thể họ cho rằng nếu không có các quy tắc nghiêm ngặt quanh test/migration thì nguy cơ code thật bị hỏng hoặc mất dữ liệu là hoàn toàn thực tế

    • Điều đó cũng đúng, nhưng theo kinh nghiệm của mình thì đã từng có những vấn đề lớn xảy ra
      1. Khi con người về sau sửa thủ công các test được tạo ra, có rất nhiều cái bẫy thật sự nghiêm trọng
      2. Vì Claude không hiểu rõ context nên nó thường mock gần như mọi thứ, và từ đó tạo ra những test hoàn toàn tách rời khỏi service/môi trường build của bọn mình
      3. Và vấn đề lớn hơn nữa là cả đội bắt đầu trở nên quá lười với test
        Thực tế là bug trên production đã tăng mạnh