The first time a client pushed for delivery, I learned that “knowing how to code” wasn’t the same as shipping
Last Tuesday at 10 p.m., I was fixing a client’s website from my rental in Hangzhou. The page loaded, but the button didn’t respond. I asked an AI tool to find the cause. It quickly gave me a pile of suggestions. I copied them, tested them, and kept changing things until 1 a.m. I still missed a mobile issue before delivery. I used to think automation meant “letting AI do more.” Now I know the real time saver isn’t generating more answers; it’s reducing the repetitive checks I have to do for the tool.
Stanford’s course change: humans take part more like a conversation
Mihail Eric teaches The Modern Software Developer at Stanford and leads the AI team at Monaco. He changed the course assignment from “have AI finish a feature” to “have AI help implement it, then have the project maintainer review the code.” The point wasn’t prettier code. People still have to ask: Does the maintainer actually want this feature? Why is the existing logic written this way? What else could this change affect?
I’ve used a similar method. I ask AI to explain which files the change will touch, confirm each item, then run the key workflow myself. For a nontechnical founder like me, that’s more practical than expecting myself to understand every line of code from the start.
Starting today costs almost nothing: $0, about 90 minutes, and the ability to explain the business goal
Money: I didn’t need to buy a new tool; the conversational AI tool I already had was enough. Budget: $0. Time: about 90 minutes—20 minutes to organize the requirements, 45 minutes to have AI explain the impact, and 25 minutes for manual verification. First step: Open the AI tool I already use, start a new conversation, and enter: “I’m planning to change [feature name]. Don’t write code yet. List the requirements I need to confirm, the files affected, and the acceptance steps.” If the tool can’t read my project files, I paste in the relevant page or code first instead of dumping in the entire folder.
Here’s how I’d arrange it by stage
If I’m just starting out and mostly doing content or manual services, I try a small, low-risk task first and stay away from core systems. There’s no rush to try this now; writing the client’s requirements clearly may be the better investment. If I have one or two stable clients, I use this “requirements—impact—acceptance” conversation to let AI produce a first draft, then ask someone I trust or a developer to review it. If they can’t explain what “done” means, I hold off on automating the work.
If I’m scaling and already have developers on the team, I turn it into a regular retrospective: every change leaves behind requirements, risks, and acceptance records before we decide which steps are worth handing to a tool. This isn’t about making everyone learn to code. It’s about making AI output easier to inspect, deliver, and review.