Yesterday, a client pushed for delivery. I nearly let AI submit the answer.
It was 10 p.m. Tuesday, and I was remotely updating a client’s website from Hangzhou. The most impatient client asked, “Can it go live tomorrow?” My first instinct was to let AI finish the code. But when I opened the old project, I couldn’t even understand why the original developer had put the button there. I’d learned that lesson before: generating code quickly does not make delivery reliable.
Stanford took a straightforward approach in CS146S: drop students into unfamiliar open-source projects, make them understand the code before proposing changes, then explain their work to maintainers who may merge it. Mihail Eric, who leads the course and also works on AI at Monaco, says that once AI can complete last year’s assignments, the real skill to practice is judgment: which existing conventions must remain untouched, and why a change deserves to be merged.
The approach also fits non-technical founders. Xiaolin, who runs a WeCom bot in Shenzhen, doesn’t buy tools first. Each week, he picks one real customer problem and asks AI to organize the workflow. Xiaolin then confirms which messages can be sent automatically and which still require a human reply. Monaco works similarly: each AI assistant gets a separate workspace with its own permissions and tools. A code-review tool can be purchased, but the team still has to preserve explanation and judgment.
Not “let AI write more,” but “leave results AI can explain”
There are two moves here. First, put old materials, FAQs, and delivery rules into one workspace so AI can answer against that context instead of improvising. Second, require every output to include the reason for the change, its impact, and the points a human must check. Mihail repeats one principle in the course: AI explores; people confirm context and final responsibility.
If I wanted to try this now, I’d avoid taking on a complex system. I’d create a “client delivery handbook” in a Feishu doc or Notion, add the contract scope, previous change records, and FAQs, then ask AI for proposals using that template. The first step would be to open my usual AI tool, start a blank conversation, upload three recent project documents, and write: “Summarize the existing rules first. Don’t make the decision for me.”
Today’s replication: about 30 minutes, $0
Money: Use existing AI chat features, usually $0; if I already pay for a subscription, I don’t need another purchase. Time: 30 minutes to organize the materials and one hour for the first validation run. Technical barrier: I don’t need to code, but I must be able to say what the client wants and what I can’t promise. First step: Click “New Chat” or “Add File” in my AI tool.
The first time I uploaded five documents together, it mixed up two clients’ requirements. I switched to handling one client at a time and asking it to restate the requirements and list uncertainties first. It became much more reliable. This tool isn’t for everyone; if I have no code and don’t take on technical projects, there’s no urgency to try it.
Match the setup to my current stage—don’t build it all at once
At the starting stage: Pick one customer problem for a 30-minute exercise. Have AI return a “recommendation, rationale, and items to confirm,” without rushing to automate anything.
With one or two clients: Collect each request, promise, and delivery note in a dedicated workspace. Require AI to cite the relevant rules before answering every time.
While scaling: Only then consider separating data and permissions for different assistants while keeping human review. First prove the process can deliver reliably, then add tools and people. The goal isn’t to replace a team; it’s to let AI speed up exploration so I can spend more time on judgment and communication.