Hầu hết developer dùng AI như một cái Google thông minh hơn - hỏi, nhận câu trả lời, paste vào. Đó không phải workflow. Workflow thực sự trong thời đại AI đòi hỏi một mental model hoàn toàn khác về cách bạn cấu trúc công việc của mình.
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.
Trọng lực tổ chức là cái lực vô hình kéo team về phía "những gì đã quen rồi". Để bay lên (antigravity), bạn phải hiểu rõ nó, đo lường nó, rồi mới có thể chống lại nó.
Google Antigravity là một bước nhảy vọt về cách chúng ta nhìn nhận AI trong dev - không phải tool gợi ý code nữa, mà là agent tự chủ chạy cùng bạn. Nó gây ấn tượng 60% và gây thất vọng 30%, nhưng lúc nhìn thẳng vào nó, đây là tương lai.
Sau 20 năm trong ngành và 7+ năm làm tech lead, tôi nhận ra: mentoring junior developers không phải là dạy code, mà là dạy cách suy nghĩ. Nếu bạn chỉ giải quyết các vấn đề cho họ, bạn đang cướp đi cơ hội để họ trở thành independent engineer. Thực ra cách lớn nhất để giúp junior phát triển là cùng học cách giải quyết vấn đề, chứ không phải đưa câu trả lời sẵn.
Không có database "tốt hơn". Có database phù hợp hơn với context của bạn. Tôi dùng SQL Server 20 năm và PostgreSQL 5 năm - cả hai đều excellent, nhưng chúng khác nhau ở những trade-off quan trọng mà architect cần hiểu rõ. Năm 2019, tôi nhận một project mới - một startup fintech đang xây MVP. Họ hỏi tôi: "Anh Son, chúng tôi nên dùng database gì?" Câu hỏi đơn giản. Nhưng tôi không trả lời ngay. Thay vào đó, tôi hỏi lại: "Tech stack của team là gì? Ai sẽ maintain database này sau khi tôi đi? Infrastructure của các bạn là on-premise hay cloud? Budget cho licensing là bao nhiêu?" Họ nhìn tôi hơi ngớ ngẩn. Họ expected một câu trả lời technical - benchmark performance, feature comparison. Tôi lại hỏi về organization và budget. Vì đó mới là thứ thực sự quyết định.
Cache thì dễ thêm vào. Nhưng khi product price thay đổi lúc 11:59 PM trước flash sale lúc 12:00 AM, bạn mới biết cache invalidation khó như thế nào. Bài này đi sâu vào các pattern thực tế và code C# cho product catalog. Phil Karlton có câu nói nổi tiếng: "There are only two hard things in Computer Science: cache invalidation and naming things." Tôi thêm vào: cache invalidation trong e-commerce còn khó hơn cache invalidation ở chỗ khác. Vì trong e-commerce, data thay đổi liên tục - price, stock, promotion - và mỗi inconsistency đều có thể cost bạn money (hoặc cost khách hàng).
