Vustech's Blog

Thẻ: Software Development

  • Trải nghiệm “Bình thường mới”: Khi AI Agent thay thế hoàn toàn đội ngũ kỹ sư phần mềm

    Trải nghiệm “Bình thường mới”: Khi AI Agent thay thế hoàn toàn đội ngũ kỹ sư phần mềm

    Bạn đã bao giờ tưởng tượng đến một ngày mình chỉ cần đưa ra ý tưởng, chụp một tấm hình lỗi giao diện, và 15 phút sau mọi thứ đã được fix sạch sẽ, có đầy đủ Unit Test, Integration Test và đã được deploy lên môi trường Production? Tại Vustech, chúng tôi không còn tưởng tượng nữa. Chúng tôi đang sống trong cái gọi là “New Normal” (Bình thường mới) của ngành phát triển phần mềm.

    Với sự hỗ trợ của một đội ngũ gồm 9 AI Agent chuyên biệt, việc xây dựng một hệ thống phức tạp từ đầu (Greenfield) hay chuyển đổi kiến trúc (Migration) đã trở nên nhàn nhã đến mức đáng kinh ngạc, nhưng cũng đầy hoang mang cho những người làm kỹ thuật lâu năm.

    15 phút cho một Bug “Blank Screen” – Không cần xem Log

    Một case study điển hình vừa diễn ra tại dự án Titan của chúng tôi. Khi truy cập vào trang Forum, hệ thống hiển thị màn hình trắng xóa (Blank Screen). Thay vì mở IDE, kiểm tra Network tab hay đọc log backend như cách làm truyền thống suốt 20 năm qua, chúng tôi chỉ cần chụp ảnh màn hình và ra lệnh cho Agent: “Report bug: User access forum page and seeing blank screen”.

    Kết quả thật kinh ngạc:

    • Trong 5 phút đầu: AI PM Agent tự tạo Bug Report và phân rã thành các task kỹ thuật.
    • 5 phút tiếp theo: AI Developer viết Unit Test và Integration Test để tái hiện lỗi (Reproduce bug).
    • 5 phút cuối: AI tìm ra nguyên nhân gốc rễ (API trả về null thay vì một mảng rỗng khi không có dữ liệu channel) và thực hiện fix lỗi, chạy test pass 100% rồi yêu cầu Merge Request.

    Toàn bộ quá trình diễn ra tự động. Con người chỉ đóng vai trò nhấn nút “Approve”.

    Dự án Titan: “Trợ lý ảo” thực thụ được xây dựng bởi Agent

    Titan không chỉ là một dự án thử nghiệm, nó là một hệ thống Data Pipeline phức tạp với các nhiệm vụ:

    • Quản lý thông tin: Đọc mail, lọc các nội dung quan trọng và tự động tạo lịch làm việc (Calendar items).
    • Ranking tin tức: Tự động crawl tin tức từ hàng trăm nguồn (cả API lẫn scraping), đánh giá độ quan trọng và gửi Daily Digest cho người dùng.
    • Tự động hóa CI/CD: Tự thiết lập GitHub Actions, tự kiểm soát Quality Gate trước khi release.

    Toàn bộ codebase hơn 20.000 dòng code Python và 30.000 dòng tài liệu kiến trúc được tạo ra chỉ trong vòng 4 ngày bởi đội ngũ Agent. Tốc độ này là không thể đạt được với bất kỳ team con người nào hiện nay.

    [img]Sơ đồ kiến trúc dự án Titan với các luồng xử lý dữ liệu tự động của AI Agent[/img]

    Nỗi sợ về sự “Ngu hóa” kỹ thuật

    Đi kèm với sự tiện lợi cực độ là một rủi ro tiềm ẩn: Sự mai một của các kỹ năng kỹ thuật lõi. Khi AI làm quá tốt việc debug, thiết kế kiến trúc và viết code, lập trình viên sẽ dần mất đi khả năng thấu hiểu bản chất của hệ thống. Ngôn ngữ lập trình tối thượng bây giờ không còn là Java, Go hay Rust, mà chính là Tiếng Anh (Spec-writing).

    Chúng ta đang dịch chuyển từ “Thợ code” sang “Người điều phối” (Orchestrator). Nếu bạn không có nền tảng kiến thức đủ sâu để giám sát AI, bạn sẽ rất dễ bị “dắt mũi” bởi những giải pháp trông có vẻ bóng bẩy nhưng rỗng tuếch bên trong.

    [img]Bảng so sánh năng suất và khả năng bảo trì giữa Code truyền thống và Agentic Code[/img]

    Kết luận: Thích nghi hay bị đào thải?

    Cuộc cách mạng AI Agent đang biến “Software Development as a Service” trở thành hiện thực. Rào cản công nghệ đang sụp đổ, nhường chỗ cho cuộc chiến về Ý tưởng và Khả năng quản trị.

    Đừng tự mãn với những kỹ năng cũ kỹ. Hãy học cách xây dựng đội ngũ Agent cho riêng mình, học cách viết Spec chuẩn chỉnh và tập làm quen với vai trò của một kiến trúc sư trưởng. Tương lai không chờ đợi bất kỳ ai, và tại Vustech, chúng tôi chọn cách dẫn đầu làn sóng này để không bao giờ bị cuốn trôi.

    Vustech – Tiên phong trong vận hành dự án bằng AI Agent Team và định hình tương lai ngành phần mềm.

  • AI Native SDLC: Khi AI đóng vai trò “Kỹ sư chính” và con người là “Kiến trúc sư trưởng”

    [img]Hình ảnh minh họa mô hình AI Native SDLC với sự phối hợp giữa AI Agent và con người[/img]

    Có một định kiến đang tồn tại trong giới lập trình: "Để AI Agent tự code và điều phối task là một sự ảo tưởng về chất lượng". Nhiều người lo ngại rằng nếu không có sự can thiệp thủ công, phần mềm sẽ đầy rẫy lỗi bảo mật, hiệu suất kém và không thể bảo trì. Tuy nhiên, thực tế tại Vustech và các doanh nghiệp phần mềm tiên phong (như MISA với 80% feature được hỗ trợ bởi AI) đang chứng minh điều ngược lại.

    Chìa khóa không nằm ở việc AI giỏi đến đâu, mà nằm ở việc chúng ta thiết lập một quy trình AI Native SDLC (Software Development Life Cycle) chuẩn chỉnh như thế nào.

    AI Native SDLC: Bản chất của sự thay đổi

    Trong mô hình truyền thống, con người là người gõ code và máy tính là công cụ thực thi. Trong mô hình AI Native SDLC, vai trò này được đảo ngược: AI Agent đóng vai trò là "Main Worker" (Người thực thi chính), còn con người dịch chuyển sang vai trò "Orchestrator" (Người điều phối) và "Architect" (Kiến trúc sư).

    Để AI có thể làm việc hiệu quả mà không gây ra thảm họa, quy trình này phải dựa trên 4 cột trụ:

    1. Specification & Definition of Done (DoD): Yêu cầu phải cực kỳ rõ ràng và có tiêu chí hoàn thành cụ thể.
    2. Architecture Decision Records (ADR): Các quyết định về kiến trúc phải được document lại để AI Agent follow, tránh việc đi sai định hướng hệ thống.
    3. TDD (Test Driven Development) bắt buộc: AI phải viết Unit Test, Integration Test và End-to-End Test trước hoặc song song với việc viết code.
    4. Human-in-the-loop: Con người đóng vai trò chốt chặn cuối cùng, review code, approve PR và ra quyết định cho các câu hỏi mở (Open questions) mà AI chưa đủ ngữ cảnh để giải quyết.

    Đảm bảo chất lượng: AI vs Con người

    Nhiều người sợ AI tạo ra bug, nhưng thực tế con người cũng tạo ra bug hàng ngày. Vấn đề không phải là "đứa nào" làm, mà là "làm sao" để phát hiện và sửa lỗi.

    • AI Agent có một ưu điểm tuyệt đối là sự tuân thủ quy trình (Strict adherence). Nếu bạn quy định quy trình migration phải nâng coverage lên 55%, AI sẽ làm đúng như vậy từng bước một mà không biết mệt mỏi.
    • Khi phát hiện bug, thay vì sửa tay, con người chỉ cần "file bug" bằng ngôn ngữ kỹ thuật chính xác cho Agent. Agent sẽ tự đọc lại requirement, đọc bug description và thực hiện fix lỗi theo quy trình: Đỏ (test fail) -> Xanh (test pass) -> Refactor.

    [img]Sơ đồ quy trình Quality Assurance trong mô hình AI Native SDLC[/img]

    Tư duy điều phối Agent: Kỹ năng sống còn mới

    Lập trình viên thời đại AI không cần phải là người gõ phím nhanh nhất, mà phải là người hiểu hệ thống sâu sắc nhất. Bạn cần có kỹ năng:

    • Phân tích yêu cầu phi chức năng (Non-functional Requirements): Bảo mật, hiệu suất, khả năng mở rộng. Đây là những thứ AI thường bỏ qua nếu bạn không nhắc tới.
    • Ra quyết định kiến trúc: Khi AI đưa ra 3 giải pháp, bạn phải biết giải pháp nào là tối ưu cho dài hạn.
    • Giao tiếp với Agent: Biết cách đặt câu hỏi, biết cách prompt để khai thác tối đa năng lực của mô hình (như Claude Opus hay GPT-4).

    [img]Bảng so sánh vai trò của Developer trong SDLC truyền thống và AI Native SDLC[/img]

    Lời kết: Đừng bịt mắt trước tương lai

    Việc phủ nhận năng lực của AI Agent chỉ khiến bạn chậm chân trong cuộc đua năng suất. Các doanh nghiệp đang âm thầm ứng dụng Agentic AI để giảm 30-50% chi phí và tăng tốc độ "Time-to-market".

    Đừng sợ AI làm hỏng code của bạn. Hãy sợ rằng bạn không đủ trình độ để thiết lập một quy trình quản trị AI đủ tốt. AI Native SDLC không làm giảm giá trị của lập trình viên, nó chỉ nâng tầm lập trình viên từ một "thợ xây" trở thành một "tổng công trình sư".

    Vustech – Chuyên gia tư vấn và triển khai quy trình AI Native SDLC cho doanh nghiệp hiện đại.

  • Agentic AI Đã Có Những Bước Tiến Vượt Trội: Kỹ Năng Làm Phần Mềm Không Còn Của Riêng Dev

    [img]Sơ đồ so sánh workflow truyền thống (1 dev = 1 output) vs AI-augmented workflow (1 dev + N agents = N outputs)[/img]

    Khi AI Agent Vượt Xa Khỏi "Công Cụ Hỗ Trợ"

    Sau một thời gian dài theo dõi sự phát triển của AI, có thể thấy Agentic AI đã có những bước tiến vượt trội – không còn là công cụ hỗ trợ coding đơn thuần, mà đã trở thành một "đồng nghiệp" thực sự.

    Google đang phát triển multimodal agent với khả năng:

    • Edit video metadata trực tiếp trong database
    • Hỗ trợ searching và analyze dữ liệu phức tạp
    • Trao đổi, đặt câu hỏi ngược lại để làm rõ yêu cầu

    Điều này đánh dấu sự chuyển dịch từ AI as a tool sang AI as a team member.

    Thực Trạng: Một Người Được Trang Bị AI = Cả Một Team

    [img]Mô hình "one man army": 1 developer điều khiển multiple AI agents song song, mỗi agent đảm nhận một vai trò cụ thể[/img]

    Từ "One Man Army" Đến "Multi-Agent Team"

    Bên Vustech có đối tác trong ngành automotive đã trang bị Cursor/Code cho toàn bộ nhân viên. Điều này mang lại lợi thế lớn, nhưng cũng là rủi ro cho developer:

    Khi một người được trang bị AI agent:

    • 1 người + AI = 1 team
    • 1 AI có thể spawn thành 4+ agent con
    • Mỗi agent đảm nhận một task riêng

    Workflow mới:

    1. Ra lệnh cho agent
    2. Cho nó làm việc
    3. Quay lui kiểm tra kết quả
    4. Ra lệnh tiếp hoặc điều chỉnh

    Điểm bottleneck giờ đây không phải là máy móc hay công cụ, mà là khả năng xử lý của con người – tốc độ review, ra quyết định, và điều phối các agent.

    Kỹ Năng Nền Tảng Developer Cần Có

    Kỹ năng cũ Kỹ năng mới
    Coding thuần túy Agent orchestration
    Debug manual Review AI output
    Làm theo task được giao Ra lệnh cho agent (prompt engineering)
    Làm việc độc lập Điều phối multi-agent workflow
    Tập trung vào implementation Tập trung vào requirement & architecture

    Foundation skills bắt buộc:

    1. Coding agent proficiency: Cursor, Copilot, Claude Code
    2. Agent skill creation: Tạo skill định trước, yêu cầu agent sử dụng
    3. MCP server: Kết nối agent với external tools
    4. Automated workflow: Phối hợp nhiều agent chạy tự động trên server

    Tương Lai Giao Tiếp Người-Máy: Không Cần Gõ Phím

    [img]Voice-first interface: developer nói chuyện trực tiếp với AI agent, AI nghe và thực thi ngay lập tức[/img]

    Hiện tại, đa số developer Tây phương đã chuyển sang nói chuyện trực tiếp với AI thay vì gõ prompt. Với tiếng Anh tốt, bạn có thể:

    • Ra lệnh bằng giọng nói
    • AI nghe, ghi lại, và thực thi
    • Loop feedback bằng voice conversation

    Điều này có nghĩa: bây giờ là thời điểm tuyệt vời nhất để làm software. Ai có ý tưởng kinh doanh, ai muốn build sản phẩm – không còn rào cản kỹ thuật quá lớn.

    Bộ Skill 5-10 Năm Tích Lũy… Không Còn Quá Cần Thiết

    Giá Trị Developer Đang Bị Tái Định Nghĩa

    Số năm kinh nghiệm Tình trạng
    10-15 năm Vẫn có giá trị (architecture, leadership)
    3-5 năm Giá trị đang giảm – AI agent làm được những gì bạn làm
    0-2 năm Cơ hội học skill mới từ đầu (AI-native)

    Yêu cầu mới: Review và ra quyết định sau khi AI hoàn thành task

    • Approve để AI làm tiếp
    • Request changes
    • Pivot direction

    Vai Trò Nào Sẽ Lên Ngôi?

    Những công việc cần con người review/approve sẽ liên quan nhiều hơn đến:

    • PO (Product Owner): Định hướng sản phẩm, priority
    • BA (Business Analyst): Phân tích requirement, business logic
    • Technical Lead/Architect: Review architecture, technical decision

    Với vai trò coder thuần túy, việc approve sẽ theo dạng "bypass":

    "Thôi mày làm đi, tao canh đến khi mày xong thì tao đồng ý."

    Tại Sao Nhiều Senior Không Tin AI Agent Làm Việc Độc Lập?

    [img]Thang đo trust level với AI: từ skepticism (critical systems) đến full autonomy (non-critical tasks)[/img]

    Nỗi Sợ Không Tên: Mất Vai Trò

    Ngay cả trong công ty Vustech, nhiều senior developer phản đối mạnh mẽ ý tưởng AI agent có thể làm việc độc lập. Đây không phải là vấn đề kỹ thuật – mà là nỗi sợ mất vai trò.

    Trường Hợp Automotive: Critical Mission Software

    Ngành automotive là ví dụ điển hình cho skepticism:

    • ECU (Engine Control Unit) điều khiển động cơ
    • Tín hiệu: tăng ga, giảm ga, đốt nhiên liệu, lấy điện từ battery
    • Nếu AI lập trình sai: xe gây tai nạn, tính mạng con người bị đe dọa

    Họ không tin AI có thể làm mission-critical software với safety requirement cao.

    Nhưng Vấn Đề Là Process, Không Phải Capability

    Hãy phân tích: capability của AI agent hiện tại cực kỳ mạnh. Vấn đề còn lại là:

    • Process: Quy trình kiểm tra, validate
    • Method: Cách thức thực hiện, testing strategy
    • Quality assurance: Ensure output quality trước khi deploy

    Minh Chứng Thực Tế: AI Tạo Slide PowerPoint

    Hôm trước, tôi có yêu cầu Claude (Anthropic) tạo slide PowerPoint:

    • Input: Hình chụp slide thô làm trước
    • Output: Slide hoàn chỉnh, đẹp, chuẩn chỉnh, mạch lạc
    • Revision: "Tông màu đậm quá, dùng màu pastel hơn được không?"
    • Time: Update toàn bộ nội dung tính bằng seconds

    "Oh my god" – Đây không còn là tương lai xa vời, mà là hiện tại.

    Use Case Thực Tế: Home Security AI Agent

    [img]Kiến trúc hệ thống security AI: Camera stream → AI agent detection → Alert/Call homeowner → Fake voice warning[/img]

    Scenario: Phát Hiện Người Lạ Đột Nhập

    Setup:

    • Raspberry Pi chạy AI agent (OpenCLAW hoặc tương đương)
    • Camera security stream video 24/7
    • AI detect người lạ xuất hiện trong nhà

    Response flow:

    1. Phát hiện chuyển động + khuôn mặt lạ
    2. Bật chế độ báo động
    3. Giả giọng người lớn (như phim "Home Alone") cảnh báo qua loa:

      "Trong vòng 5 phút nữa công an sẽ ập tới. Hình ảnh của bạn đang bị ghi lại."

    4. Nếu người đó nói "Tôi là người thân trong nhà":
      • AI gọi trực tiếp cho chủ nhà
      • Connect call để xác minh

    Impact Xã Hội

    Những nguy cơ:

    • Giết người, cướp của
    • Ăn trộm, ăn cắp

    Sẽ giảm thiểu đáng kể nếu robot AI hỗ trợ:

    • Quan sát 24/7 không mệt mỏi
    • Phát hiện người lạ real-time
    • Inform chủ nhà ngay lập tức
    • Gọi điện thoại trực tiếp để xác minh

    Tương Lai Ngành CNTT: AI-Native Solutions

    [img]Biểu đồ dự báo: Giảm 50-70% quy mô dev team, tăng 300% nhu cầu Technical PO/BA[/img]

    Xu Hướng Tất Yếu

    1. Developer/coding work suy giảm
    2. Product Owner, Business Analyst tăng
    3. Làm phần mềm dễ hơn – công ty nào cũng tự làm được
    4. Không cần thuê quá nhiều outsourcing – chi phí quá tốn kém

    Công Ty Phần Mềm Lớn Còn Cửa Không?

    Câu trả lời: Có, nếu có process chuẩn chỉnh.

    • Phần mềm lớn phụ thuộc nhiều vào quy trình
    • Process chuẩn → Quality đảm bảo → Công ty lớn vẫn cạnh tranh được
    • Process nội bộ → Công ty tự làm solution riêng

    Con Đường Sự Nghiệp: Technical Product Owner

    Định Nghĩa Technical PO

    Software developer có khả năng làm full application từ A-Z:

    • Collect requirement
    • Analysis & phân tích
    • Implementation (với AI support)
    • Deploy & maintain

    Không chừa bất cứ thứ gì – làm hết.

    Tại Sao Technical PO Là Tương Lai?

    Yếu tố Impact
    AI làm coding Dev thuần giảm giá trị
    Process quan trọng PO có technical background thắng thế
    One-person startup Cần người làm được mọi thứ
    Platform engineering Giảm nhu cầu DevOps, infra specialist

    Platform Engineering: Đòn Bẩy Cho Solo Developer

    [img]Stack platform hiện đại: Database-as-a-Service, Auth-as-a-Service, Deployment-as-a-Service[/img]

    Mọi Thứ Đều Là Service

    • Database: Không cần thuê server, chỉ cần connection string (Supabase, PlanetScale)
    • Authentication/Authorization: Đã có service (Auth0, Clerk, Firebase Auth)
    • Web application deployment: Vercel, Netlify, Laravel Forge
    • Job queue, background worker: Serverless function

    Hệ Quả

    • Không cần đội ngũ DevOps đông đảo
    • Xây dựng site lớn, chạy nhanh, tốt – với 1-2 người
    • Spend thời gian vào sales, product improvement thay vì ops

    Thế Giới Mới: Promise Và Thách Thức

    Cơ Hội Chưa Từng Có

    • One-person company: Start với 1 người, không cần thuê nhiều
    • Chi phí đầu tư thấp: Platform đã có sẵn
    • AI quá lợi hại: Làm được nhiều thứ với ít effort

    Thách Thức

    Khi người biết dùng AI tạo công cụ dễ dùng hơn cho người không biết gì:

    • Công ty control AI sẽ có sức mạnh khủng khiếp
    • Tự động hóa mọi thứ: text, meeting minute, document drafting

    Dự Báo Workforce

    "Tháng 6-7 năm ngoái tôi đã khẳng định workforce sẽ giảm. Giờ càng tin chắc hơn."

    Giảm 50-70% số lượng developer cần thiết để làm cùng một sản phẩm.

    Kết Luận: Từ Software Developer Đến Software Builder

    [img]Evolution path: Coder → Developer → Software Engineer → Technical PO → Software Builder[/img]

    Title Mới: Software Builder

    • Software Developer: Làm full con app với AI support
    • Software Engineer: Tham gia đội ngũ lớn, engineering-focused
    • Software Builder: Tự làm từ A-Z, không cần team đông

    Thách Thức Lớn Nhất

    "Không phải dùi mài kinh sử học technical problem nữa. Thách thức là: Bạn có thể làm software từ A to Z được hay không?"

    AI agent đã democratize kỹ năng làm phần mềm. Kỹ năng này không còn của riêng developer nữa – mà thuộc về bất kỳ ai có ý tưởng và biết điều phối AI.

    Câu hỏi đặt ra: Bạn sẽ ở đâu trong bức tranh này?

  • Requirement Thay Đổi Liên Tục: Làm Sao Để Sếp Không Đánh Giá Thấp Performance Team

    [img]Sơ đồ quy trình Agile với các iteration ngắn và feedback loop từ stakeholder[/img]

    Vấn đề thực tế: Vibe Coding Nhưng Team Vẫn Bị Đánh Giá Là Chậm

    Nhiều team lead và developer đang gặp phải tình huống: sếp tổng nghĩ rằng với AI và vibe coding, việc làm phần mềm phải rất nhanh chóng. Tuy nhiên, thực tế tiến độ team lại chậm – không phải do kỹ năng code kém hay không dùng AI, mà do requirement thay đổi liên tục.

    Hệ quả: team phải làm đi đập lại, xây đi phá lại nhiều lần cho từng feature. Và khi nhìn vào kết quả cuối cùng, sếp dễ đánh giá performance team không cao.

    Bài viết này phân tích giải pháp quản lý expectation và chứng minh năng lực team trong môi trường requirement bất ổn.

    [img]Biểu đồ so sánh thời gian release giữa mô hình truyền thống (vài tháng/năm) và MVP (liên tục)[/img]

    Tại Sao Rework Không Có Nghĩa Là Performance Kém

    Nature Of Work – Bản Chất Của Công Việc Phần Mềm

    Khi làm sản phẩm phần mềm, không có chuyện 100% requirement được finalize và freeze hoàn toàn từ đầu. Đây là bản chất của ngành – nature of work.

    Chính vì lý do này, chúng ta mới áp dụng các methodology như Agile, Scrum vào quá trình phát triển phần mềm – để thích nghi nhanh với:

    • Sự thay đổi về mặt requirements
    • Sự thay đổi về mặt expectation của khách hàng

    Agile khuyến khích thích ứng với thay đổi. Tuy nhiên, rework (làm đi làm lại) vẫn sẽ bị xem là yếu tố cho thấy performance không tốt trong mắt nhiều sếp.

    Điểm Mấu Chốt: Deliver Sản Phẩm Chạy Được

    Để đánh giá performance hay productivity của một nhóm có tốt hay không, cần nhìn vào khả năng deliver:

    • Tạo ra sản phẩm chạy được
    • Có thể demo được
    • Có thể xem được để lấy feedback

    Vấn đề nhiều team gặp phải: cố gắng làm cho thật tốt, thật hoàn chỉnh trước khi demo hoặc release. Kết quả: mãi không có gì để cho thấy tiến độ.

    [img]Mô hình MVP với vòng lặp Build-Measure-Learn và feedback từ user thực tế[/img]

    Giải Pháp 1: Tiếp Cận MVP Và POC

    Từ Vài Tháng Xuống Vài Tuần

    Thông thường, nhiều team mất tới vài tháng hoặc cả năm mới release được một version. Cách tiếp cận hiện đại là đi theo hướng:

    • POC (Proof of Concept): Chứng minh khái niệm khả thi
    • MVP (Minimum Viable Product): Sản phẩm tối thiểu khả dụng

    Mục tiêu: tạo ra thứ người ta có thể dùng được và feedback được ngay.

    Lợi Ích Của MVP

    Khi làm ra các MVP, bạn sẽ:

    • Kết được phản hồi trực tiếp từ sếp và người dùng
    • Người ta sẽ thấy được tiến độ – có sự thay đổi rõ ràng
    • Bạn cập nhật và làm liên tục để đáp ứng yêu cầu

    Đôi khi yêu cầu đến từ sếp – mặc dù có lúc developer nghĩ rằng "sếp chả biết gì cả". Nhưng việc có sản phẩm dùng được sẽ giúp chứng minh: tôi làm cũng ra kết quả.

    MVP có thể đem ra thử trong một lượng user nhỏ – đủ để validate direction mà không cần hoàn thiện mọi thứ.

    [img]Timeline của một iteration với requirement được freeze ở đầu sprint và change request chuyển sang sprint sau[/img]

    Giải Pháp 2: Freeze Requirement Theo Iteration

    Nguyên Tắc: Iteration Đủ Nhỏ = Kiểm Soát Được

    Khi bạn chia iteration trong software development đủ nhỏ, bạn có thể freeze requirement trong chu kỳ đó.

    Dù gì thì gì, chúng ta cũng cần có một khung thời gian hoặc một phase đủ nhỏ mà chúng ta có full control để:

    • Ensure về mặt quality
    • Ensure về mặt planning

    Vấn Đề Của Change Request Giữa Sprint

    Khi push requirement và chain requirement vào quá nhiều in between sprint hoặc iteration, sẽ dẫn tới:

    • Team bị vỡ kế hoạch
    • Phải rework hoặc làm lại
    • Additional feature làm loãng focus

    Cách Áp Dụng Thực Tế

    Ví dụ: một iteration là một tháng. Trong tháng đó, mọi người đừng đụng vô tất cả những gì về requirement development. Cái gì thay đổi thì để đó cho iteration tiếp theo fix lại.

    Trường hợp extreme: Nếu requirement thay đổi đến mức làm mà không mang lại lợi ích gì vì gần như công cốc → đóng luôn sprint đó.

    [img]Ma trận quyết định: khi nào nên đóng sprint vs khi nào nên absorb change[/img]

    Vai Trò Quan Trọng Của PO

    Mức Độ Certainty Cần Thiết

    Việc này phụ thuộc rất nhiều vào người làm PO (Product Owner). PO cần đạt tới một certain level về mức độ certainty:

    • Requirement đã collect được
    • Cảm thấy tương đối ổn, tương đối fix rồi
    • Mới cho team làm

    Thay vì bắt team làm một thứ mà khách hàng không aware và không happy khi nghe tới.

    Ngoại Lệ: Giai Đoạn VOC

    Có một giai đoạn ngoại lệ: khi cần làm VOC (Voice of Customer) để chứng minh năng lực. Lúc này bạn có thể làm ra bất cứ thứ gì bạn muốn – vì bạn cũng không được phép hoặc không có thời gian để gặp user nhiều nhằm get confirmation về một feature có nên hay không nên có trong hệ thống.

    PO Cần Học Cách Baseline Requirement

    PO nên học cách để:

    • Baseline requirement
    • Freeze requirement
    • Để cho team làm việc ổn định

    Tóm Lại: Ba Bước Chứng Minh Performance

    Bước Hành Động Kết Quả Mong Đợi
    1 Lập plan phù hợp, chia iteration đủ nhỏ (2 tuần – 2 tháng) Có khung thời gian kiểm soát được
    2 Freeze requirement theo iteration, cam kết không đổi Có demonstration thấy tiến độ rõ ràng
    3 Đi theo hướng MVP – feature gì test xài được luôn Có feedback thực tế từ user/sếp

    Nếu requirement trên quá lớn khiến việc implement của sprint gần như công cốc → close sprint đó và replan.

    Kết Luận

    Việc requirement thay đổi liên tục là bản chất của phát triển phần mềm hiện đại. Thay vì cố gắng chống lại thay đổi, team cần:

    1. Chứng minh qua deliverable: Sản phẩm chạy được giá trị hơn lời hứa
    2. Áp dụng MVP: Ra mắt sớm, feedback sớm, điều chỉnh sớm
    3. Freeze theo iteration: Tạo vùng ổn định trong chu kỳ ngắn

    Khi sếp thấy được tiến độ qua các demo liên tục và sản phẩm dùng được, perception về performance team sẽ thay đổi – ngay cả khi requirement vẫn tiếp tục biến động.

  • Vibe Coding Là Gì? Dành Cho Ai Và Cách Sử Dụng Hiệu Quả

    [img]Sơ đồ minh họa quy trình vibe coding với AI assistant từ khâu requirement đến deployment[/img]

    Mở đầu

    Vibe coding đang trở thành xu hướng phát triển phần mềm mới, cho phép tạo ứng dụng nhanh chóng với sự hỗ trợ của AI. Tuy nhiên, nhiều người vẫn hiểu lầm rằng đây chỉ là công cụ dành cho developer chuyên nghiệp hoặc ngược lại – ai cũng có thể dùng mà không cần kiến thức nền. Bài viết này phân tích chi tiết về vibe coding dựa trên kinh nghiệm thực tế từ một software builder có kinh nghiệm làm việc với nhiều ngôn ngữ và framework.

    Vibe Coding Là Gì?

    Vibe coding là phương pháp phát triển phần mềm sử dụng AI assistant để viết code thông qua các prompt (câu lệnh) bằng ngôn ngữ tự nhiên. Thay vì viết từng dòng code thủ công, developer mô tả yêu cầu và AI sẽ sinh ra code phù hợp.

    [img]So sánh năng suất giữa traditional coding và vibe coding với các con số cụ thể[/img]

    Vibe Coding Dành Cho Ai?

    Người Có Background Công Nghệ

    Vibe coding đặc biệt phù hợp với những người có nền tảng về technology, software development. Họ đã hiểu về:

    • Cấu trúc hệ thống
    • Các design pattern
    • Best practices trong lập trình
    • Cách test và debug code

    Người Không Chuyên Nhưng Có Học Căn Bản

    Điều quan trọng cần hiểu: vibe coding không dành riêng cho dân chuyên. Những người chưa có background về software development nhưng đã học những căn bản lập trình vẫn có thể sử dụng vibe coding để tạo app hiệu quả.

    Ví dụ thực tế: Có những giáo viên dạy tiếng Anh đã áp dụng vibe coding để tạo ứng dụng phục vụ chính domain của họ – giảng dạy tiếng Anh. Họ không phải developer chuyên nghiệp nhưng vẫn tạo ra sản phẩm tốt vì:

    • Hiểu rõ domain của mình
    • Biết cách viết requirement cụ thể
    • Test kỹ lưỡng sản phẩm

    [img]Biểu đồ phân loại đối tượng sử dụng vibe coding theo mức độ kinh nghiệm coding[/img]

    Những Điều Cần Tránh Khi Vibe Coding

    Tuyệt Đối Không Tạo App Chỉ Với Một Prompt

    Một trong những sai lầm lớn nhất là cố gắng tạo ra một ứng dụng hoàn chỉnh chỉ với một câu lệnh. Điều này chỉ phù hợp với:

    • Những app vô cùng đơn giản
    • Tính năng có thể thể hiện trong một câu lệnh duy nhất

    Với ứng dụng thực tế, bạn cần qua nhiều prompt khác nhau để tinh chỉnh behavior của app. Quá trình này đòi hỏi:

    1. Prompt ban đầu cho khung cơ bản
    2. Các prompt tiếp theo để thêm tính năng
    3. Prompt để fix bug và tối ưu

    Không Bỏ Qua Khâu Review Code

    Nếu bạn không có kỹ năng coding sâu, hãy sử dụng chính AI để review code. Khi review, bạn sẽ tìm ra được các điểm cần improvement và dùng chính AI để fix.

    Best Practices Khi Vibe Coding

    Document Ngay Từ Đầu

    Khi làm xong một tính năng nhỏ hoặc có thay đổi, hãy document lại ngay. Việc này giúp:

    • AI hiểu được cấu trúc ứng dụng
    • Giảm rối loạn ngữ cảnh khi codebase lớn
    • Dễ dàng bảo trì và mở rộng

    Ví dụ: Với một application có configuration phức tạp với vài chục ngàn dòng code, cần có document mô tả cấu trúc backend và configuration mechanism. Khi đó AI sẽ đọc document để hiểu trước khi thực hiện thay đổi.

    Test Kỹ Lưỡng

    Xem app như một black box, nhưng nếu test đủ kỹ thì khả năng gây lỗi sẽ giảm đi đáng kể. Cần có:

    • Unit test
    • Integration test
    • Coverage đủ để đảm bảo behavior không đổi khi code thay đổi

    [img]Quy trình test tự động trong vibe coding với các lớp test từ unit đến E2E[/img]

    Sử Dụng Cloud Code

    Nguy cơ lỗi khi sử dụng cloud code thấp hơn so với local code. Các AI hiện đại đang tăng performance và productivity đáng kể cho developer.

    Xu Hướng Phần Mềm Builder

    Với sự hỗ trợ của AI, role của software engineer đang chuyển đổi thành software builder:

    • Code trực tiếp ít hơn
    • Sử dụng AI để build software nhiều hơn
    • Tập trung vào review và architecture

    Một người có thể làm công việc của bốn năm người trong team. Tuy nhiên, điều này không có nghĩa là không cần học:

    Kỹ Năng Cần Thiết

    1. Viết requirement: Khả năng mô tả yêu cầu rõ ràng, cụ thể
    2. Tiếng Anh tốt: Hầu hết AI coding assistant hoạt động tốt nhất với tiếng Anh
    3. Hiểu kiến trúc hệ thống: Để review và đánh giá code AI sinh ra
    4. Biết best practices: Để suggest cho AI và review code quality

    Công Cụ và Chi Phí

    Các tool như Cursor, Claude Code đang được sử dụng phổ biến. Tuy nhiên, chi phí cho các subscription này không hề rẻ:

    • Cần cân nhắc mua 100% license cho team
    • Có thể cần tăng giá sản phẩm để cover chi phí

    Kết Luận

    Vibe coding là xu hướng tất yếu của phát triển phần mềm hiện đại, mang lại:

    • Năng suất cao hơn
    • Thời gian development ngắn hơn
    • Khả năng tạo app phức tạp với team nhỏ

    Tuy nhiên, thành công với vibe coding đòi hỏi:

    • Học kỹ năng viết requirement
    • Hiểu kiến trúc hệ thống để review
    • Test kỹ lưỡng trước khi deploy
    • Document đầy đủ các thay đổi

    Vibe coding không thay thế developer mà biến họ thành software builder – người điều khiển AI để tạo ra sản phẩm chất lượng cao hơn, nhanh hơn.

    FAQ

    Hỏi: Người mới bắt đầu có thể học vibe coding không?

    Đáp: Có, nhưng cần học căn bản lập trình trước để hiểu cách hệ thống vận hành và có thể review code.

    Hỏi: Vibe coding có thay thế hoàn toàn developer không?

    Đáp: Không. Developer chuyển vai trò sang software builder – tập trung vào architecture, review và quality assurance.

    Hỏi: Cần học những gì để bắt đầu vibe coding?

    Đáp: Kỹ năng viết prompt, tiếng Anh chuyên ngành, hiểu biết về kiến trúc phần mềm và best practices.