WEBSITE ĐANG PHÁT TRIỂN

AI trong vận hành và triển khai phần mềm: những gì tôi học được sau 1 năm dùng thật

Sau 1 năm dùng AI tools (Claude Code, Copilot, Antigravity) trong workflow thực tế - không phải để viết blog, không phải demo cho khách - tôi rút ra được vài thứ khá ngược với hype. AI không thay đổi nhiều bước viết code. Thứ nó thay đổi nhiều nhất là bước trước và sau code: planning, review, và đặc biệt là deploy + vận hành. Và đây là nơi senior engineers đang bỏ lỡ cơ hội lớn nhất.

Câu chuyện từ một ông bạn

Khoảng giữa năm 2025, có ông bạn tôi - tech lead ở một công ty fintech - gọi kể chuyện. Team anh ấy vừa được cấp Copilot toàn bộ, sếp kỳ vọng productivity tăng 30%. Hai tháng sau, quarterly review: không có con số nào đáng kể thay đổi. Sếp bắt đầu hỏi "tool có vấn đề gì không".

Anh bạn tôi thì biết vấn đề nằm ở đâu, nhưng không biết cách giải thích. Vấn đề không phải tool. Vấn đề là team dùng AI để viết code nhanh hơn, nhưng review chậm hơn, test hỗn loạn hơn, và deploy cũng không đổi.

Tôi hỏi: "Thế pipeline CI/CD của mày có gì thay đổi không?"

Im lặng.

"Deploy process? Monitoring? Incident response?"

Vẫn im lặng.

Đó là lúc tôi hiểu - đây là câu chuyện của hầu hết các team đang "adopt AI". Họ đổi một bước trong cả một chuỗi quy trình. Rồi ngạc nhiên khi throughput không tăng.


Quay lại chuyện kỹ thuật - AI đang thay đổi chỗ nào trong SDLC

Hãy nhìn thẳng vào số liệu. Q4/2025, một nghiên cứu từ DX (getdx.com) cho thấy:

  • 22% code được merge là do AI viết (không bị sửa lại đáng kể)
  • Developer dùng AI hàng ngày tiết kiệm trung bình 38 phút/ngày
  • Staff+ engineers tiết kiệm 4.4 giờ/tuần nếu dùng đều - nhưng đây là nhóm có tỷ lệ adoption thấp nhất

Con số cuối cùng mới là điều đáng nói. Senior và staff engineers - những người có scope ảnh hưởng lớn nhất - lại là nhóm ít dùng AI nhất. Tại sao?

Một phần vì ego. Một phần vì họ không thấy AI giúp được nhiều với những bài toán thực sự phức tạp mà họ đang giải. Và một phần - đây là phần quan trọng - vì họ chưa xác định đúng chỗ nào AI thực sự có giá trị với công việc của họ.

Bức tranh toàn cảnh SDLC với AI

Nếu chia SDLC ra thành 5 giai đoạn lớn:

Planning → Development → Testing → Deployment → Operations

Phần lớn attention đang đổ vào Development - AI viết code, autocomplete, refactor. Đây là phần hiển thị nhất, dễ demo nhất. Nhưng bottleneck thực sự của nhiều team không nằm ở development. Nó nằm ở deployment và operations.

Netflix dùng AI trong chaos engineering để kiểm tra tính ổn định trước khi deploy. Google dùng AI để tối ưu Kubernetes resource allocation trong CI/CD pipeline. Đây không phải "AI viết code" - đây là AI trong infrastructure và operations.


Deep-dive: AI thực sự làm được gì trong Deployment & Ops

1. Intelligent CI/CD - từ "build pass/fail" đến "tại sao fail"

Pipeline CI/CD truyền thống báo lỗi kiểu: "Build failed. Exit code 1." Bạn tự đi đọc log.

AI-powered CI/CD (Harness, một số tích hợp Azure DevOps mới) bắt đầu làm được: phân tích root cause, so sánh với lịch sử build, đề xuất fix. Không phải magic - nhưng tiết kiệm thời gian đáng kể.

Trong dự án tôi đang làm, chúng tôi thêm một bước trong pipeline: sau khi test fail, AI agent phân tích log và tóm tắt vấn đề trước khi notify developer. Thay vì nhận thông báo "pipeline failed", developer nhận: "Test OrderProcessing_ShouldHandleConcurrentRequests fail - có vẻ related đến deadlock trong transaction isolation, xem commit a3f2b1."

Khác biệt nhỏ nhưng tác động lớn - developer không cần mất 10–15 phút đọc log trước khi bắt đầu debug.

2. Deployment validation - AI làm reviewer tự động

Đây là chỗ tôi thấy giá trị rõ nhất trong 1 năm vừa rồi.

Trước khi deploy lên staging hoặc production, chúng tôi chạy AI review trên diff - không phải review code style, mà review rủi ro deployment:

  • Breaking changes trong API contract?
  • Database migration có rollback strategy không?
  • Dependency mới có security vulnerability đã report không?
  • Config thay đổi có match với environment variables hiện tại không?
// Ví dụ: Chúng tôi có một pre-deployment check script
// Gọi LLM API, truyền vào git diff + deployment checklist
// Output: risk assessment + danh sách items cần verify thủ công

var deploymentRisk = await _aiReviewer.AssessDeploymentRisk(
    gitDiff: diffContent,
    checklist: _deploymentChecklist,
    environment: targetEnvironment
);

if (deploymentRisk.Level == RiskLevel.High)
{
    await _notifier.NotifyTeamLead(deploymentRisk.Summary);
    // Không block, nhưng require explicit approval
}

Không phải tất cả mọi thứ AI nói đều đúng. Nhưng nó catch được đủ thứ mà checklist tĩnh bỏ qua - đặc biệt những edge case liên quan đến context của change cụ thể.

3. Production monitoring - từ reactive sang predictive

Đây là area đang phát triển nhanh nhất và cũng là nơi hype nhiều nhất.

Thực tế năm 2025–2026:

  • AI-powered anomaly detection (Datadog, Azure Monitor với AI) đã production-ready và đáng dùng
  • Root cause analysis tự động: tốt trong 70–80% trường hợp đơn giản, vẫn cần người trong cases phức tạp
  • Predictive scaling dựa trên patterns: tốt nếu traffic patterns tương đối ổn định

Thứ chưa làm được tốt: incident response trong chaos thực sự, khi nhiều hệ thống fail cùng lúc theo cách unpredictable.

Kinh nghiệm cá nhân: Tôi không trust AI để tự động response incident. Tôi dùng AI để rút ngắn thời gian diagnosis - từ 30 phút xuống còn 10 phút. Quyết định cuối vẫn do người.


Bài học từ dự án thực

Ông bạn fintech của tôi sau đó đã làm gì?

Thay vì tiếp tục focus vào AI code generation, team anh ấy chuyển hướng: tích hợp AI vào deployment pipelinepost-deploy monitoring. Cụ thể:

  1. Pre-deploy AI review - tất cả PR trước khi merge phải pass qua AI risk assessment
  2. AI-generated release notes - tự động tổng hợp changes, impact, rollback steps từ commit history
  3. Smart alerting - thay vì alert theo threshold tĩnh, dùng AI để phát hiện anomaly pattern

Ba tháng sau: MTTR (Mean Time to Recover) giảm 40%. Không phải vì code tốt hơn. Mà vì phát hiện sự cố nhanh hơn và team hiểu vấn đề nhanh hơn.

Sếp hài lòng. Nhưng lần này có số để nói chuyện :D


Triết lý - AI amplifies, không replaces

Câu tôi hay nói với team: AI khuếch đại thứ bạn đang có, không thay thế thứ bạn thiếu.

Nếu deployment process của bạn đang chaos - không có rollback strategy, test coverage thấp, pipeline mỏng manh - AI sẽ giúp bạn deploy code tệ nhanh hơn. Đó không phải cải tiến.

Nếu quy trình của bạn đã tương đối tốt - có staging environment, có monitoring, có on-call process - AI sẽ giúp mọi thứ chạy mượt hơn, detect vấn đề sớm hơn, tốn ít cognitive load hơn.

Đây cũng là lý do tôi thấy "believe in basic" quan trọng hơn bao giờ hết trong kỷ nguyên AI. Những nền tảng cơ bản - clean code, test coverage tốt, deployment process rõ ràng - bây giờ được AI nhân lên. Không làm tốt basics thì AI thực sự chỉ là thêm noise.


Gửi các bạn tech lead và senior dev

Nếu bạn đang evaluate hoặc đã dùng AI tools, hãy tự hỏi:

"Mình đang dùng AI ở chỗ nào trong workflow?"

Nếu câu trả lời chỉ là "viết code nhanh hơn" - bạn đang để lại 60–70% giá trị trên bàn.

Thứ đáng thử tiếp theo:

  • AI review rủi ro trước deployment (không cần fancy tool, prompt engineering đơn giản cũng được)
  • AI summarize incident report từ log - rồi so sánh với bản bạn tự viết
  • AI generate release notes từ git log - tiết kiệm 20–30 phút mỗi sprint

Bắt đầu từ một trong ba. Đo kết quả. Rồi quyết định có mở rộng không.

Đừng đổi toàn bộ workflow vì hype. Nhưng cũng đừng bỏ qua vì nghĩ "AI chỉ cho junior".


Bạn đã thử tích hợp AI vào deployment hay ops chưa?

Tôi tò mò muốn biết - các bạn đang dùng AI ở bước nào trong SDLC? Chỗ nào thấy hiệu quả thật sự, chỗ nào thấy hype nhiều hơn thực chất?

Drop comment hoặc nhắn tôi - những câu chuyện thực tế như vậy đáng giá hơn nhiều bài nghiên cứu :)


Tham khảo


/Son Do - believe in basic

#1percentbetter #AIintegration #softwarearchitecture #devops


Bài viết liên quan

Xem thêm
AI Integration — Góc nhìn Architect

LLM Wiki: Khi AI Không Còn Phải Đọc Codebase Từ Đầu Mỗi Ngày

LLM Wiki là pattern biến codebase thành "living knowledge base" – AI đọc một lần, nhớ mãi, kiến thức tích lũy theo thời gian. Khác với RAG truyền thống, LLM Wiki compound knowledge: mỗi lần hỏi đều thông minh hơn lần trước. Tôi nhớ lần đầu tiên tiếp cận một codebase e-commerce 5 năm tuổi. Hệ thống đang chạy ổn định, team cũ đã nghỉ gần hết, và tôi được giao nhiệm vụ thêm một tính năng tưởng đơn giản: hiển thị trạng thái tồn kho real-time trên trang sản phẩm. Ba ngày sau, tôi vẫn còn ngồi đọc code. Không phải vì code xấu. Mà vì không ai – kể cả những dev còn lại trong team – có thể giải thích được tại sao InventoryService lại gọi thẳng vào một endpoint của OrderService thay vì dùng shared database. Confluence có một trang wiki viết năm 2021 với nội dung "TODO: update this section." File README chỉ có hướng dẫn setup môi trường local. Đó là lần đầu tôi thực sự hiểu cái gọi là tribal knowledge – kiến thức nằm trong đầu người, không phải trong code.

AI Integration — Góc nhìn Architect

Prompt Engineering 2026: Không phải 1 góc nhìn — mà 40 góc nhìn song song

Năm 2026, AI agents đang bùng nổ và nhiều người vội vã tuyên bố "prompt engineering đã chết". Sai hoàn toàn. Chain of Thought, flipping roles — những kỹ thuật cơ bản đó vẫn còn sống, chỉ là giờ chúng ta không chạy 1 luồng nữa, mà chạy song song 40 luồng cùng lúc. Bài này là câu chuyện về sự tiến hóa đó. Hôm rồi tôi ngồi cà phê với một ông bạn — tôi gọi anh là Khoa cho tiện — senior developer 6 năm, đang chuyển sang làm AI engineer ở một startup khá hot trong nước. Anh mở màn bằng một câu khiến tôi suýt đổ cà phê: "Anh ơi, prompt engineering giờ chết rồi. Giờ phải học AI agents mới là đúng hướng." Tôi nhìn anh, hỏi: "Chết theo nghĩa nào?" Anh giải thích: "Thì giờ người ta build hệ thống multi-agent rồi, AI tự lo với nhau, mình chỉ cần thiết kế workflow là xong. Ai còn ngồi viết prompt thủ công nữa?" Tôi im lặng một lúc, rồi hỏi ngược: "Thế mấy cái agent đó nó tự nhiên biết làm việc không? Hay vẫn cần ai đó chỉ cho nó cách nghĩ?" Anh Khoa dừng lại. Ừ nhỉ.