[Samsung Electronics] Có khả thi kịch bản AI phát triển 100% firmware MCU cho thiết bị gia dụng?

Tiêu đề: Có khả thi kịch bản AI phát triển 100% firmware MCU cho thiết bị gia dụng?

Bài gốc: Samsung Tech Blog - https://techblog.samsung.com/blog/article/90

• Samsung Electronics đã áp dụng “Harness Engineering” vào phát triển firmware MCU cho thiết bị gia dụng (máy hút mùi) để kiểm chứng liệu AI agent có thể tự chủ lặp lại quy trình lập kế hoạch - triển khai - kiểm chứng và tạo ra 100% firmware mà không cần con người can thiệp vào việc viết code hay không

• Ở đây, “harness” không phải là làm cho model thông minh hơn, mà là thiết kế môi trường làm việc (thông tin cần thiết, điều cấm, vòng lặp tự kiểm chứng, cấu trúc thư mục, tài liệu đặc tả, chuẩn coding, build/linter) để AI tạo ra kết quả đúng như dự định. Vai trò của developer chuyển từ “người viết code” sang “người thiết kế đặc tả và harness”

• Nguyên tắc cốt lõi là “đặc tả mà AI không thể kiểm tra thì coi như không tồn tại”. Những yêu cầu không được tài liệu hóa không thể trở thành tiêu chí triển khai hay tiêu chí kiểm chứng, nên tương đương với “yêu cầu không tồn tại” (ví dụ: nếu không cho biết lưu lượng gió là Low-Mid-High hay On-Off thì AI sẽ tự phán đoán). Điểm khởi đầu là “thiết kế đặc tả”: hệ thống hóa tài liệu đặc tả legacy và “tri thức ngầm” của developer thành dạng AI có thể sử dụng

• Các đặc tả rải rác được tái tổ chức xoay quanh thư mục docs/. Hành vi sản phẩm được đặt trong behavior/, căn cứ thiết kế trong design/, thông tin cấu hình và khởi tạo phần cứng trong hardware/, còn đặc tả truyền thông, state machine và giao thức truyền thông cũng được sắp xếp vào các thư mục tương ứng. Bổ sung AGENTS.md chứa quy tắc làm việc của AI và ARCHITECTURE.md định nghĩa cấu trúc layer cùng quy tắc phụ thuộc để hoàn thiện nền tảng harness. Kết quả là tài liệu đóng vai trò “nguồn chân lý duy nhất (Single Source of Truth)”

• Ngoài 3 loại harness cho đặc tả/triển khai/kiểm chứng, nhóm còn cung cấp dưới dạng “skill” các đặc tả MCU riêng của Samsung, cách dùng MCU debugger, USB Switch để tắt/bật vật lý nguồn 220V, v.v. Phạm vi triển khai được kiểm soát bằng SDD/TDD/BDD, và chỉ khi vượt qua các quality gate Build/Test/Lint mới được đi tiếp sang bước sau

• Vòng lặp AUTOPILOT bắt đầu từ code Zero-Base và tự chủ lặp lại lập kế hoạch - triển khai - kiểm chứng. Khi đó, “agent tạo ra” và “agent đánh giá/kiểm chứng” được tách riêng để ngăn tình huống AI đánh giá quá dễ dãi sản phẩm của chính mình

• Thách thức khó nhất là xây dựng môi trường để AI trực tiếp kiểm tra kết quả trên “MCU thực tế”. Môi trường kiểm chứng gồm Codex AI trên PC + MCU debugger dựa trên JTAG + USB Switch điều khiển nguồn, trong đó Codex AI điều khiển debugger và switch. Debugger trực tiếp đọc/ghi trạng thái MCU, còn USB Switch bật/tắt nguồn 220V để AI có thể tự khởi tạo lại bộ thiết bị ngay cả khi rơi vào trạng thái không thể phục hồi

• AI được cung cấp đặc tả sản phẩm, thông tin protocol/packet, datasheet MCU, cách dùng debugger, mã nguồn/cấu trúc biến, phương pháp bật/tắt nguồn. AI phân tích tài liệu đặc tả để tự “có ý chí” suy ra kịch bản test, dùng debugger tiêm key input vào thiết bị thực tế (memory Write), rồi đọc giá trị trạng thái dưới dạng biến (memory Read) để tự phán định Pass/Fail theo từng kịch bản. Nói cách khác, kiểm chứng tự động tự chủ được hình thành khi ba yếu tố “kịch bản hoạt động + memory Write + memory Read” phối hợp với nhau

• Kết quả: cả 5 lần đều tự chủ hoàn thiện mà không cần con người can thiệp (mỗi lần khoảng 4,5~5,5 giờ), mức hoàn thiện chức năng cơ bản khoảng 95%. Khoảng 5% còn thiếu chủ yếu phát sinh ở HAL (UART, Timer, WatchDog, Clock và các vùng cần kiểm chứng HW thực tế), và có thể được bổ sung bằng 1~4 giờ debugging cùng con người

• Xác nhận khả năng rút ngắn trung bình 50~70% thời gian phát triển. Tuy nhiên, đây là ước tính của AI dựa trên thời gian phát triển thuần túy, không bao gồm phê duyệt/review/release; thách thức để mở rộng là khoản đầu tư ban đầu và việc thiết lập “tiêu chí kiểm chứng hoàn hảo đến mức con người không cần review code”