Tôi từng yêu cầu một AI xây dựng một trang web thương hiệu. Kết quả ban đầu trông có vẻ thuyết phục, nhưng nó lại gặp lỗi ở những điểm thực sự quan trọng. Phần header chỉ hiển thị đúng hai liên kết. Không có trang "About" ở bất cứ đâu. Một bảng điều khiển admin tồn tại ở backend, nhưng không có nút bấm hay route nào ở frontend có thể thực sự truy cập được nó. Phía server hoạt động tốt. Phía người dùng thì không.

Hầu hết những người gặp phải tình trạng này đều cho rằng AI đang lười biếng hoặc chạm giới hạn token. Thực tế không phải vậy. Vấn đề nằm ở cấu trúc. Các công cụ lập trình AI được xây dựng để kiểm soát tính nhất quán nội bộ. Chúng tự hỏi: "Mọi thứ tôi đã khai báo có khớp với nhau không?" chứ không hỏi: "Một sản phẩm bàn giao loại này có chứa đầy đủ mọi thứ nó cần phải có hay không?" Nếu bạn đề cập đến hai trang cho trang web thương hiệu của mình, mô hình sẽ tận tụy kiểm tra xem hai trang đó có liên kết ngược lại với nhau hay không. Một khi các liên kết đã hoạt động, nó coi như nhiệm vụ đã hoàn thành. Nó không có khái niệm tự thân rằng một trang web thương hiệu cần có trang Giới thiệu (About), các tín hiệu tạo niềm tin (trust signals), hoặc một lộ trình liên hệ. Không có một tiêu chuẩn nào trong đầu nó cả.

Tôi gọi giải pháp cho vấn đề này là một Baseline Hoàn thiện (Completeness Baseline).

Một baseline hoàn thiện đơn giản là một danh sách kiểm tra tiêu chuẩn về những gì một sản phẩm bàn giao nhất định phải có. Bạn tạo ra sản phẩm, sau đó bạn kiểm tra kết quả thực tế dựa trên tiêu chuẩn bên ngoài này thay vì tin tưởng vào cảm giác "đã xong" nội tại của công cụ.

Kiểm tra qua ba lớp

Không phải mọi mảnh ghép bị thiếu đều rõ ràng như nhau. Một baseline hữu ích cần kiểm tra ba lớp riêng biệt.

Sự tồn tại (Existence). Phần đó có thực sự tồn tại không? Nghe có vẻ cơ bản, nhưng một AI sẽ vui vẻ xây dựng một thanh điều hướng có tham chiếu đến một trang dashboard mà không bao giờ thực sự tạo ra trang dashboard đó. Tham chiếu thì có tồn tại. Nhưng mục tiêu thì không.

Khả năng tiếp cận (Reachability). Người dùng thực tế có thể thực sự truy cập được nó không? Các bảng điều khiển admin bị ẩn là triệu chứng điển hình. Route và component đều có thể tồn tại trong codebase, nhưng không có mục menu, nút bấm hay lệnh redirect nào hiển thị chúng lên giao diện. Nếu người dùng không thể tình cờ thấy nó trong quá trình sử dụng bình thường, thì nó coi như không tồn tại.

Sự thực chất (Substantiation). Có dữ liệu hoặc cấu trúc thực sự đằng sau bề mặt không? Một trang web tải lên được nhưng chỉ chứa văn bản giả (placeholder) và không có chỗ tải ảnh lên thì chỉ là một bộ khung đang mặc quần áo. Một trang About không có chỗ chèn ảnh hoặc trường văn bản có thể chỉnh sửa thì không được coi là hoàn thiện, ngay cả khi HTML được render mượt mà.

Ba lớp này giúp phát hiện các loại lỗ hổng khác nhau. Sự tồn tại tìm ra chiếc giày bị mất. Khả năng tiếp cận tìm ra chiếc giày bị khóa trong tủ. Sự thực chất tìm ra chiếc giày không có đế.

Baseline theo loại

Một baseline sẽ không bao quát được mọi dự án. Bạn cần phân loại những gì mình đang xây dựng và xác định các yếu tố không thể thương lượng cho danh mục đó.

Các trang web thương hiệu cần các phần cụ thể và các trang có thể truy cập được. Hãy nghĩ đến các trang About, Contact, các liên kết quyền riêng tư và thanh điều hướng thực sự hiển thị mọi chế độ xem chính.

API cần tài liệu hướng dẫn, mã lỗi đầy đủ và giới hạn tốc độ (rate limits). Một endpoint hoạt động trả về 200 OK khi thành công và một mã 500 chung chung cho mọi lỗi khác thì không phải là một API hoàn chỉnh. Đó là một mối nguy hiểm.

Các quy trình tự động hóa cần nhật ký (logs) và cảnh báo lỗi. Nếu một quy trình bị lỗi vào lúc 2 giờ sáng mà không ai biết cho đến khi con người kiểm tra lịch sử chạy, thì quy trình tự động hóa đó chưa hoàn thiện. Khả năng quan sát (Observability) không phải là một tính năng bổ sung. Nó là một phần của sản phẩm bàn giao.

Một khi bạn gọi tên được danh mục, baseline sẽ tự hình thành. Phần khó nhất là thực thi nó sau khi mã nguồn đã được tạo ra.

Các quy tắc thiết kế bền vững

Tôi đã xây dựng lại quy trình làm việc của mình xoay quanh ý tưởng này và rút ra ba quy tắc thực tế để giữ cho các dự án không bị tan rã dần dần.

Thiết kế dựa trên giới hạn năng lực (Capability-gated design). Trước khi bạn cam kết sử dụng một công cụ hoặc một module được tạo ra, hãy xác định xem nó thực sự có thể làm được gì. Nếu một thư viện component thiếu hỗ trợ menu ngăn kéo (drawer) trên di động, đừng để AI tạo ra một sơ đồ điều hướng đầy đủ dựa trên giả định rằng nó có tồn tại. Hệ thống nên giảm cấp tính năng một cách mượt mà (degrade gracefully) thay vì bị lỗi khi thiếu một năng lực nào đó. Hãy nắm rõ các ranh giới trước. Thiết kế bên trong chúng.

Công cụ công khai, giá trị riêng tư (Public engine, private values). Sử dụng một công cụ công khai cho các tác vụ nặng, nhưng hãy đưa các dữ liệu, cấu hình và quy ước riêng tư của bạn vào lúc runtime. Điều này giúp giữ cho các phương thức cá nhân hoặc của công ty bạn được an toàn và tách biệt khỏi khung sườn (scaffold) được tạo ra. AI xây dựng khung, còn bạn lắp kính vào. Điều này ngăn chặn mô hình mã hóa cứng (hard-coding) các giả định vi phạm tiêu chuẩn thực tế của bạn hoặc làm rò rỉ các mẫu nhạy cảm vào các ngữ cảnh huấn luyện công khai.

Propose, do not auto-advance. Let the AI suggest the next step, but force a human to make the choice. Automate the flow of execution, never the judgment. When a model auto-generates a database migration, an auth scheme, and a payment hook in one breath, you get convenience at the cost of oversight. Make the tool present the plan. Let the developer press the button.

Picking the Right Model for the Job

I tested this across different models and found a clear split in value. Cheaper models handle mechanical bulk shockingly well. They churn out boilerplate, repetitive components, and structural stubs faster than you can type. The expensive models earn their price only when they demonstrate restraint. You want the premium option when it refuses to invent fake fixes and instead flags a genuine gap. A model that hallucinates a workaround for a missing API endpoint is dangerous. A model that stops and says, "This workflow requires a webhook target that is not defined," is worth the cost. Pay for discernment, not volume.

Build Systems, Don't Chase Magic

Do not try to fix AI gaps by throwing bigger models or more prompting tricks at the problem. Fix them with a baseline. The gap is not a capacity problem. It is an expectations problem.

To stop the missing blocks, do three things.

Give the system a completeness baseline before any code is written. Make it a physical checklist that lives next to the task.

Bake your conventions into reusable parts. If you enforce your baseline through templates, lint rules, or pre-built scaffolds, the AI starts from a position of correctness rather than hoping it guesses your standards.

Automate the flow while keeping a human in control of judgment. Let the machines handle repetition. Reserve the decisions for people who understand the context.

Here is one last habit that changed how I work. If you make the same design decision seven times, stop treating it as a one-off choice. That is not repetition. That is a law. Name it. Turn it into a rule. Document it. When you codify the pattern, you remove the chance that an AI will drift away from it the eighth time.

The source for this framework and the original exploration can be found here.

If you want to trade notes with others working through the same problems, you can join the GyaanSetu learning community.