On the morning of day three, the publicity materials were handed out as tasks: one poster, one trifold brochure. The pitch was the next morning; everything had to be finished by that night.
The job landed on O. He had just finished his other work and was planning to spend the spare time gaming — so an extra chore, naturally, was best dispatched as fast as possible. And “fast,” these days, has a ready-made answer.
A few minutes later, Doubao — a widely used Chinese AI app — turned in its work. The poster was passable; the trifold gave itself away: its three panels came out in different sizes and could not be printed at all. I asked him what he planned to do.
“Keep regenerating with AI.”
I said: open Canva and make it yourself.
He was reluctant. Understandable — why spend four or five hours on something AI can hand over in one minute?
Those four or five hours are exactly what this essay wants to talk about.
when AI should speed things up, and when a student needs to slow down.
Some background first. This July, I led a team at a four-day student hackathon: six kids, one real client, and four days to build a working product prototype. AI was everywhere in those four days — writing code, doing research, making designs — and the kids used it more fluently than many adults. Watching from that close, I accumulated some concrete thoughts about “AI literacy,” a phrase said too often and too fast. (What exactly happened over those four days is recorded in the first piece of this series.)
1. What Happened After We Slowed Down
I had my own agenda. Making O do the poster by hand was not about fixing print sizes. The real reason was this: I knew AI was too fast, and I knew what that AI poster was worth — sixty points out of a hundred, seventy at most. And I expected more from these kids. I believed they could reach eighty, even ninety. In a competition where everyone is being pushed forward by AI, someone has to be responsible for stepping on the brake.
Slowing down was not comfortable. The first version was nothing much to look at. We went over the screen spot by spot: what’s off here? Where should the text sit? How big should the image be? By the time the first panel finally looked right, he showed it to the team. Someone asked, “Did AI make this?”
He moved the mouse — every element on the page moved, and every one could be edited.
“I made it myself.”
Understand: until then, their entire poster workflow had been to have AI generate one whole image, stretch it across the canvas, done. Now he owned a poster where every element answered to him. “Look,” I said, “you have real taste. You made it better-looking than AI did.”
After that, he barely needed me. The second panel, the third — six panels across the trifold, finished one by one. He discovered the upside of handwork on his own: change anything, anytime — unlike the tug-of-war with Doubao, two minutes of waiting each round, with the parts you already liked liable to be changed along the way.
There was no single moment, no line of dialogue announcing that he had “gotten it.” The evidence hid in his behavior: he began, unprompted, to fuss over font sizes, over nudging an image a few pixels one way or another; he turned the background from a flat color into a gradient, then tried out the degree of the gradient and the angle of the light, one option at a time. When a person starts fussing over details, it means he already carries the “better version” in his head.
By late afternoon he was rubbing his eyes, saying how tired he was. But looking at the finished piece, he gave it a name — “the most powerful poster in the world.”
What was powerful wasn't the poster. It was what those four or five hours left behind in him.
2. “Ugly” Is Not a Word That Works
Throughout the hackathon, I kept walking in on the same conversation. A student tells the AI: “This icon is too ugly. Regenerate.” The new one arrives; still not right; try again. Ten or twenty rounds of this was nothing unusual — with luck, you might eventually collide with something you want.
Whenever that happened, I would call a stop: laptops closed, whiteboard pulled over.
I asked them: what kind of concept is “ugly”? I can point at this bag and call it ugly, point at this book cover and call it ugly, and you all understand me. But if you were the editor who had to actually fix that cover, would you know where to start? Change the font size, the color scheme, the layout? You don’t know. Because beauty is subjective — the word “ugly” hands over no handle at all.
Talking to AI is the same. This bird doesn’t look right — is it too fat? Does it not match the real photo I gave you? Are the feathers missing their layering? These statements may not all be objectively true, but each one hands the AI a handle: it finally knows where the problem is, instead of tearing everything down in the face of one vague “ugly.”
The interesting part is that the kids had already noticed. They knew perfectly well the generated image wasn’t what they wanted — what stuck them was not being able to say where it went wrong. Noticing that something’s off is one ability; diagnosing it and saying it clearly is another.
It begins earlier: seeing the gap, then naming it specifically.
I used to think prompt engineering was the core of AI literacy. I still think it matters — but only as one of the solutions. Closer to the core is the act of noticing something’s off, in itself. AI hands out answers too fast: an essay, a webpage, ready in a minute, and at first glance worth seventy or eighty points. But where are the missing twenty or thirty? Can you see them? This time, the problem was in the prompt; next time, it could be anywhere. And seeing the gap is the one thing AI cannot do for you.
3. Where the Line Between Fast and Slow Runs
By this point, you may have taken me for an anti-AI teacher. Quite the opposite — otherwise I would not have been at an AI hackathon at all.
Over those four days, we used AI heavily. The code was handed to AI almost entirely: these kids were not there to memorize syntax; what they needed to learn was how to build a product that someone actually needs. The client-interview transcripts were long and scattered, so AI distilled the key points first, and whenever some detail tugged at them, they went back to the original audio. And once, the mini program stubbornly kept running the wrong version; after a long round of troubleshooting, the cause turned out to be a forgotten code push — so afterward they simply had AI write a reminder into the README automatically on every update. Nobody taught them that. They came up with it themselves.
So where must things be slow?
I cannot offer a universal standard. But looking back, the line is roughly clear: ask whether the process itself is where the learning happens. Pushing code by hand holds nothing they should carry away — hand it to AI, the faster the better. But the process of making the poster held exactly what I most wanted them to carry away — judgment about beauty, care over detail — so it had to be slow, even at the cost of four or five hours.
Fast versus slow is not a judgment about the task; it is a judgment about where you want the student to grow.
And that line can usually only be drawn by a teacher. A student looks at a task and mostly sees “how do I finish this quickly”; a teacher has to look at the same task and see the growth hidden inside it.
4. The Decisions Are Mine
After the poster was finished, something happened that I had never taught.
O exported the finished poster as an image and sent it to Doubao: “Please don’t change the content — help me improve this poster.” The AI laid a gradient over the background, removed the border, added shadows. He looked at it and thought — it did seem more beautiful.
But he didn’t take it wholesale. He brought the AI’s version to me, and we went through it item by item: this gradient — keep it? This shadow? Whatever we decided to keep, he went back into Canva and made the change with his own hands.
Slow first, then fast. Work until you hit your own ceiling, then invite AI in as that jolt from outside — while the decision over every single change stays in your own hands.
Before the hackathon, I had written an “AI Ground Rules Card” (「AI 使用底线卡」) for the students. Its last rule reads: the decisions are mine. I had worried the sentence was too abstract for kids to remember. Clearly, I worried too much — once a kid has truly lived through the slowed-down four or five hours, that rule grows out of him on its own.
AI helps you do the work, but it doesn't make your decisions.
He may now understand that sentence better than I do.
Back to the series: Students and AI overview | Revisit How Niaozhen Was Made: A Full Record of a Four-Day Hackathon | The Scarcest Skills of the AI Era Don’t Have AI in Their Names
This is the third piece in Students and AI. For details and the statement on AI use, see the series overview page.