What AI actually changed in my week.

By Muhammad Umar·March 11, 2025·6 min read·Issue #1

I build AI features for a living, so people assume my whole week is automated. It is not. Most of the promises do not survive contact with real work.

A few do. Those are worth being precise about.

Where it genuinely helps

• Getting to a first draft of code, of a proposal, of an email I have been avoiding.
• Reading unfamiliar code and explaining what a module is doing before I change it.
• Turning messy input into structured output: notes into a scope document, a call into action items.
• Boring transformations at volume, the work that is too small to hire for and too dull to do twice.

The pattern: it is good at the middle of the work. The blank page and the final call are still mine.

Why the middle

That pattern held so consistently that it is worth asking why, because the reason predicts where else it will hold.

The beginning of a piece of work is mostly deciding what it is for. That decision comes from context nobody has written down: what this client actually cares about, what went wrong last time, what you are willing to support in a year. The end is mostly judgment about whether it is right, which needs the same context.

The middle is transformation. You know what you have and you know what you want, and the work is getting from one to the other. That is the part where the missing context matters least, so that is the part where a model performs.

Which gives a usable test before you delegate anything. Ask what a competent stranger would need to know to do this task. If the honest answer is “nothing beyond what I could write down in a paragraph”, it is a good candidate. If the answer involves anything you would struggle to explain, such as history, politics, or a preference you hold but have never justified, you are at one of the two ends, and you should do it yourself.

Briefing it like the junior it is not

The other thing that moved my results was mundane: writing the brief the way I would write it for a contractor who starts tomorrow and leaves on Friday.

• What the output is for, and who reads it. Most bad output is aimed at nobody in particular.
• What good looks like, ideally an example of a previous one you were happy with.
• The constraints that are not negotiable, stated as constraints rather than hoped for.
• What it must not do. This is the one people leave out, and it is the one that saves the rewrite.

None of that is a prompting trick. It is the same information gap that makes a briefing to a person go badly, showing up in a context where you cannot be interrupted and asked to clarify. The model will not tell you the brief was thin. It will produce something confident and wrong, and you will spend the saved time working out why.

Where it costs me time

Anything where being subtly wrong is expensive. It will produce a confident answer about a system it has not seen, and confident wrongness takes longer to unpick than an honest blank page.

It is also a poor substitute for a decision. If I do not know what I want, no model is going to tell me. That is not a prompt problem, it is a thinking problem.

It is a fast junior with no memory of your business. Brief it like one, and check its work like one.

What I tell clients

The teams getting real value are not the ones with the cleverest models. They are the ones who picked a narrow, painful, repetitive workflow and put a human check at the end.

The ones getting nothing usually started from the technology: "we need an AI strategy." That sentence has never once told me what to build.

So I ask a different question. What does your team do every week that is slow, repetitive, and mostly text? Start there. It is unglamorous, measurable, and it works.

Measuring it honestly

Everyone claims time saved. Almost nobody measures it, and the ones who do usually measure the wrong end.

The mistake is timing the generation. Producing the draft is the part that got quick, and it is the part everyone points at. The number that matters is the time from starting the task to having something you would actually send, including reading it, finding the two things that are wrong, and fixing them.

Measured that way, some tasks improve enormously and some come out worse than before, and the split is rarely where people expect. Work with a wide range of acceptable outputs (a first draft, a summary, a rewrite) improves, because verification is a read-through. Work with exactly one correct answer often does not, because verification means deriving that answer independently, and at that point you have done the task and then also read someone else’s attempt at it.

There is a second cost that never appears in anyone’s numbers: the tasks you would previously not have done at all. Some of that is real gain. The small internal tool that was never worth a day is worth twenty minutes. Some of it is invented work that exists because it became cheap. Both feel like productivity from the inside, and only one of them is.

Where the fast-junior framing breaks

The comparison above is useful, so it is worth being clear about where it stops being true. It holds for delegation. It fails on everything to do with self-knowledge.

A junior learns; this does not. Correct the same mistake on Monday and it arrives again on Thursday, unchanged. So the effort you would spend teaching a person is wasted here. The equivalent investment goes into the brief and the checks, which persist, rather than into the model, which does not.

A junior tells you when they are lost. They hesitate, they hedge, they ask. That signal is most of how you decide what to review. A model sounds identical whether it is on firm ground or inventing, so the check cannot be triggered by its tone. It has to be systematic, applied to the confident output as much as the shaky-looking output. Anyone who has learned to review by reading hesitation has to unlearn it here.

That gives a clean boundary for where the whole approach stops paying. If verifying the output takes as long as producing it, you have gained nothing. For a first draft, verification is fast and the leverage is real. For a subtle judgment about an unfamiliar system, verification means doing the work yourself, and then the model has only added a confident answer you now have to disprove.

The takeaway

Treat AI as leverage on work you already understand, not as a replacement for understanding it. Point it at one specific, boring problem, keep a human in the loop, and measure the hours you get back.