In defense of not understanding your codebase

Please stop the AI Confidence Theater

Bài viết chỉ trích "AI Confidence Theater" – xu hướng thổi phồng khả năng và quy trình AI trên mạng xã hội lẫn trong doanh nghiệp, gây hại bằng cách bóp méo kỳ vọng, tạo FOMO, khó khăn trong tuyển dụng và áp lực giả vờ thành thạo AI. Tác giả đề xuất thay đổi bằng cách chia sẻ kết quả thực tế, thừa nhận giới hạn và tập trung vào công việc duy trì hệ thống AI vốn ít hào nhoáng nhưng mang lại giá trị thực.

Nếu bạn đang tìm hiểu về cách xây dựng dự án AI thực tế và tránh bị lừa bởi hype không có cơ sở, bài viết này giúp bạn phân biệt giữa tuyên bố hype và kiến thức thực sự để đưa ra quyết định sáng suốt về việc đầu tư thời gian và nguồn lực.

What is the future of software engineering with Adam Bender, Principal Software Engineer at Google

Adam Bender, kỹ sư phần mềm chính tại Google, cho rằng cuộc tranh luận về AI coding quá tập trung vào tốc độ và sinh code, bỏ qua những thách thức kỹ thuật rộng lớn hơn. Ông phân biệt lập trình (một cá nhân viết code) với kỹ thuật phần mềm (duy trì code sống, tích hợp và dễ bảo trì trong nhiều năm), nhấn mạnh AI thúc đẩy phần trước nhưng hầu như không ảnh hưởng đến phần sau. Những lo ngại chính bao gồm hệ sinh thái nhà phát triển như một hệ thống thích ứng phức tạp, nguy cơ mất kiểm soát trí tuệ khi codebase phát triển nhanh hơn khả năng hiểu của con người, lỗ hổng kiểm thử tích hợp khi AI tạo ra quá nhiều unit test, các API nội bộ trở nên công khai vô tình do AI bỏ qua ranh giới không chính thức, và khó khăn trong việc dạy phán đoán kỹ thuật cho lập trình viên mới sử dụng AI. Ông khuyến nghị bắt đầu bằng cách xác định chất lượng phù hợp với doanh nghiệp, sau đó lập bản đồ toàn bộ hệ sinh thái nhà phát triển để dự đoán hậu quả cấp hai và cấp ba từ việc tăng đột ngột sản lượng code.

Lập trình viên nên đọc bài này để hiểu cách AI không chỉ thay đổi cách viết code mà còn làm thay đổi toàn bộ quy trình và văn hóa của software engineering, từ việc quản lý codebase lớn đến việc đào tạo kỹ năng quyết định cho đội ngũ mới.

You get what you hire

Khi tuyển dụng, kỹ sư thường giải quyết vấn đề theo chuyên môn của họ—backend developer sẽ tập trung vào backend, frontend developer vào frontend. Bài viết minh họa qua hai ví dụ thực tế về dashboard logistics, cho thấy quyết định tuyển dụng ảnh hưởng trực tiếp đến định hướng kỹ thuật sản phẩm. Do đó, việc phân công đúng người phù hợp với yêu cầu là yếu tố quan trọng quyết định kết quả cuối cùng.

Lập trình viên nên đọc bài này để hiểu cách quyết định đội ngũ kỹ thuật sẽ quyết định hướng phát triển kỹ thuật của dự án, từ đó giúp họ có thể chọn người phù hợp nhất cho từng vấn đề để tối ưu hóa kết quả.

A return to two-pizza culture

Werner Vogels cho biết các AI coding agent như Kiro đang thay đổi quy trình phát triển sản phẩm tại Amazon bằng cách rút ngắn thời gian từ ý tưởng đến nguyên mẫu hoạt động, khiến phương pháp "build first, document later" trở nên khả thi. Ông nhấn mạnh vai trò của các nhóm nhỏ (two-pizza teams) với quyền sở hữu toàn diện, phản hồi nhanh và quyết định đảo ngược dễ dàng vẫn là nền tảng cho phát triển sản phẩm nhanh và chất lượng.

Lập trình viên nên đọc bài này để hiểu cách AI và tổ chức nhỏ, tự chủ có thể thay đổi nhanh chóng quy trình phát triển sản phẩm từ lý thuyết sang thực hành trong một thời gian ngắn, giúp tối ưu hóa tốc độ và chất lượng.

How Meta Sets Up Super IC Teams

Super IC teams — small, cross-functional incubation squads led by experienced individual contributors — are gaining traction, but most companies fail to set them up correctly. Drawing on experience at Instagram and Meta, four conditions are identified as essential: executive-level sponsorship with company-wide influence, full team self-sufficiency with dedicated members, a clearly defined large customer problem with a grounded business impact hypothesis, and early planning for how the team's work will eventually scale into the broader organization. Beyond project delivery, top Super ICs also model high-performance behaviors and spread influence across org lines in ways traditional managers cannot.

Adopting the product operating model at Priceline

Priceline's CTO Sejal Amin and Senior Director Pedro Gutierrez share how the company transitioned from a project-based to a product operating model, using developer experience (DX) metrics to uncover organizational bottlenecks and drive structural change. Key lessons include treating DX as a strategic capability, empowering engineering managers to own DX improvements quarterly, building trust through transparent communication, and using cross-functional product teams to reduce handoffs. The product operating model also positioned Priceline to adapt to AI-driven development by maintaining visibility into shifting bottlenecks as code generation accelerated.

The 2026 engineer paradox: more capable, but more alone

AI coding tools are making individual engineers dramatically more productive while quietly eroding the collaboration and knowledge transfer that keep teams healthy. The 'AI hero' who ships the whole stack alone becomes the team's biggest single point of failure, and the friction AI removes — asking colleagues, pairing, code review — was also how knowledge spread and culture formed. Drawing on DORA 2024 data, a Microsoft remote-work study, and research on open-source bus factors, the author argues that AI is more isolating than remote work because it replaces the human on the other end entirely. The prescription is deliberate human pairing around AI, synchronous code review, and measuring knowledge spread — not less AI, but intentional structures that put two people back on the same problem.