I asked AI to help me write an article about productivity. It returned a complete draft, references, and an audit of the writing. I read it and asked for another version. The subject was how AI could finish a task while leaving work for somebody else. In this case, that somebody was me.
The draft had useful points. It explained how a quick answer could create a long checking job. It brought in ideas from Andrew Ng, Andrej Karpathy, and Ethan Mollick. There were headings, practical suggestions, and important sentences in bold. I had asked for a personal story too, but that part hadn’t come through. Still, I couldn’t see myself sharing it with readers of this publication. It sounded like advice assembled for an audience, and I wanted to share something I was thinking through with them.
My feedback was that it still felt written by AI. I was repeating a requirement already in the brief. The next version needed to show that the request for a personal story had been understood.
I could ask for more natural sentences. I could keep changing the paragraph lengths. Across the articles I’ve been working on, I’ve asked for both: fewer tiny paragraphs, then a better balance when the writing became a wall of text. A tidier page still left me looking for the story I had asked for.
I went back to what I had wanted from the beginning: a story that showed my thinking, gave the reader something they could picture, and helped them act. That is what I want AI Manager Academy to do, whether the subject is technical or something from everyday life.
The draft needed a different starting point before another round of editing could help.
There was already plenty on the page
The earlier opening asked the reader to imagine an AI-generated comparison of two vendors. One price was out of date; the other used a different billing period. Someone would have to repeat the research before trusting the recommendation. It was a reasonable example. But I was trying to explain unfinished work through an imaginary situation while sitting with an actual draft I wasn’t satisfied with.
That gave me a place to begin again. The research could stay. The point about checking could stay. The opening needed to show why I cared about that point, and the rest of the article needed to follow from it. Asking for a story was a decision about the article, not just a request to make its sentences sound friendlier.
This exchange doesn’t tell me how many hours AI saved, or whether writing alone would have been faster. What I can say is that receiving the draft did not finish the job. I still had to read it, decide what I could stand behind, and work out why parts of it weren’t doing what I wanted.
Those decisions are easy to leave out when describing how quickly AI produced something. The file is visible. The thought needed to make it useful is harder to point to.
In his conversation with Harrison Chase, Andrew Ng describes how faster software development can move the constraint elsewhere: deciding what to build, reaching customers, or getting the right review. The slow part changes as other parts improve.
My writing problem is much smaller, but I recognise that movement. Once the draft arrived, I still had to check whether it met the request. It hadn’t. Another version would help only if it addressed the missing story.
Where did the saved time go?
Imagine sending an AI-assisted report to a colleague. You’ve finished your part and they open it before a meeting. They need to know whether the recommendation is safe to use. If the sources are missing or the assumptions are unclear, they now have to reconstruct the reasoning. You may have saved time preparing the report while adding to their checking job.
Here is a small made-up example, just to make that transfer visible:
The draft took 50 minutes less. The whole job took 15 minutes less. Both statements are true, but they describe different things. The second person had 35 minutes more work to do.
There may also be a wait that neither number captures. If the decision still needs Friday’s approval meeting, the result may arrive on exactly the same day. Saving someone effort is valuable even then. I just want to know whether we reduced the effort, brought the result forward, or did both.
When I say AI saved time, I need to include the person who receives its output.
With this article, I was also the person receiving the work. The audit covered voice and structure as well as factual accuracy. Yet I was still asking for the story I had requested at the start. That requirement had been missed, and the audit hadn’t caught it.
This is the part I want to check more carefully: does the result actually do what I asked? In this case, the headings and references were there. My experience and thinking were much harder to find.
Make the next decision easier
Andrej Karpathy talks about the loop between generating work and verifying it. If a system can produce a large amount of work, the way we inspect that work matters. His discussion makes me think about the size of the thing I ask AI to do next.
For this article, I want to compare the opening with the request I made. I asked for a story drawn from my experience. Can I point to that experience in the draft? Can I follow how it led to the argument? Checking a few paragraphs against those questions is more manageable than assessing another complete rewrite all at once.
I can use the same approach outside writing. If I’m reviewing a code change, I want to see the problem it addresses and a test that exercises it. If I’m comparing vendors, I want the source beside the price and the same billing period used for both. The useful thing to provide depends on the decision the next person has to make.
For a piece of work that keeps coming back, I’d start with three questions:
- What is the recipient trying to do? Make a decision, answer a customer, approve a change, or learn something?
- What will they have to check before they can do it?
- Which missing detail could send the work back to me?
There will still be work I can’t remove with a clearer request. A colleague may need approval from someone else. A customer may not have supplied the information we need. Finding that out is useful too: I can stop polishing a document while the unanswered question sits elsewhere.
Some of this work is worth keeping
There is a part of this process I don’t want to rush past. Reading a draft and explaining why I don’t like it makes me be more precise about my own judgment. If I accept a version just because it looks complete, I miss that chance.
Ethan Mollick raises a related concern in his conversation with Sana: when AI takes over work people used to learn from, organisations need to think deliberately about how expertise develops. He also discusses AI that supports learning Using AI and developing understanding can happen together; getting an answer alone doesn’t tell us whether learning happened.
For me, the useful question is whether I can explain my choice. Why does this opening belong here? What does this example show? What would make me remove it? I can use AI to explore those questions and still take responsibility for the answers.
The same applies to someone learning to review code or assess a recommendation. They need opportunities to try, explain, and get feedback. Some time spent on the work is how we become able to judge the next piece of work.
I’m still using AI to help write this. The change I want to make is to notice more carefully what remains unresolved when a draft arrives. For the next piece, I want to check the opening against the original request before going further. If the story is missing there, I want to catch it there.
You may have a different version of this sitting in your work today: a report that still needs explaining, a code change waiting for context, or an answer you can’t yet send to a customer. Pick one. Before asking AI to produce another version, write down the thing you still need to decide.
What was the last AI output you had to send back, and what was missing?