Two Days a Week

You have seen the video. A screen recording, a prompt typed into a box, a progress bar, and then a finished thing — a layout, a cut, a deck, a logo. Caption: “fully automated”. Tens of thousands of likes. I have watched a hundred of these in the last year and I could not tell you what a single one of them saved anybody.

Look at what is in the frame: one event, the happy path, a clean input and an output nobody has to deliver to a client on Friday afternoon.

Now what is never in the frame. The baseline — how long did this take before? The after, on real work, with real feedback. The method. What it cost to build. What broke. What it still cannot do.

A demo shows that a thing can happen once. It tells you nothing about a schedule — and a schedule is the only unit that matters, because a week is what I invoice and what I pay people out of.

So here is ours, with the weaknesses showing.

The expensive part was never the work

In graphics, video, photography and audio the output is subjective by nature. A hundred people, a hundred tastes. Revision cycles are not a defect in the process — they are the process.

Which means the expensive part was never the creative work. It was the loop that starts after “done”.

A note arrives. The logo is the previous one. The headline should say partners, not clients. The grade is a shade too cold. Each note is trivial on its own. Then somebody reopens the project, waits for it to load, and reloads its entire state into their own head: which layer, which version, which export preset, what the client asked for three weeks ago. They make a five per cent change, then re-export everything downstream of it.

Trivial, times a lot, is not trivial. In aggregate it was eating the week.

The number, and what it is not

At least 20% of our working week was going into comments and small details — the ones that arrive after the work is already considered finished.

After the tooling: one to two working days a week back, depending on where a project sits in its lifecycle. Early, while everything is still moving, closer to two. Late, less.

Now the caveats, in the same breath, because the entire argument of this article is that an unverified productivity claim is worth nothing — and I am not going to quietly become the thing I am complaining about:

• One team. Mine.
• Measured against their own previous schedule. There is no control group, because there is no second team doing the same work the old way.
• n=1. No randomisation, no blinding, no independent observer.
• It is a disclosure, not a study. Treat it exactly as sceptically as you should treat everybody else’s numbers, including the ones further down this page.

What I will defend is the shape of the saving rather than its precision. It recurs. It is not a one-time cleanup — the revision loop happens every week, on every project, forever, because subjective work is reviewed subjectively. That is why automating it compounds, and automating the fun parts would not have.

Customer feedback on the change has been strong. Also mine, also n=1.

What we actually built

Tooling that drives the applications we already live in — Photoshop, Illustrator, InDesign, Blender and DaVinci Resolve — through those applications’ own official scripting interfaces, exposed to an AI assistant over MCP, an open standard for connecting assistants to tools [1]. Roughly five months of evenings, one person, alongside a day job. It is in daily production use.

The platform facts are the part you can check without taking my word for it. Adobe publishes supported, documented scripting for Photoshop, Illustrator and InDesign [2]. Blender exposes a full Python API and is scriptable by design [3]. Resolve ships an official scripting API, and external scripting is a Studio feature — the free version does not expose it [4]. Worth knowing before you plan anything: that ceiling is set by a licence tier, not by your cleverness.

The kind of thing it does, in production language:

• A note comes back on wording and on a logo, and the whole mockup set regenerates with the new copy and the new asset — instead of someone reopening the file and redoing every export by hand.
• A catalogue is rebuilt across its variants, then preflighted for overset text and missing links before anything leaves the building.
• A client asks for a grade that is slightly warmer; the look is reapplied across the timeline, every deliverable is re-rendered, and each one is checked back against its delivery spec.

Two properties matter more than the feature list.

The tools are deterministic. The model decides what to do. The tools do it, through documented APIs, and report what actually happened. This is not a model clicking around a picture of a user interface and hoping.

The pipeline verifies its own output. A delivered video master is checked back against its spec — resolution, frame rate, codec, loudness, true peak — rather than assumed correct. Design edits are read back after being applied.

That second property is the whole difference between automation and theatre. A demo ends when the render finishes. Production ends when somebody can show the render is right.

The one we have not solved yet: Lightroom Classic

Lightroom Classic is still open. It is not wired into the same system, we are still working out how it should be, and I am not going to pretend otherwise in an article complaining about people who gloss over exactly this.

The reason, at the level you can verify yourself: its only published automation surface is the Lightroom SDK, which is Lua-based and plugin-shaped [5]. There is no documented general script-execution entry point comparable to the other three — it is a plugin the application calls, rather than an interface a tool can drive. Different shape, different problem.

What I did not expect is how much that stopped mattering in practice.

A large part of the photo work never needed Lightroom to be the thing holding the automation. Photoshop is already in the system, and the repetitive, mechanical end of image work runs there perfectly well regardless of where a file started its life. The tasks are the tasks; which application is nominally the library does not change them.

And selection — culling, picking, deciding what is worth finishing at all — turned out to be better served by a different approach outside Lightroom entirely, rather than something to bolt onto it. That was not a workaround. On reflection it is the more sensible architecture: the library is where photographs live, not where decisions about them have to be made.

So the honest status is: unsolved, actively being worked on, and a smaller blocker than it looked at the start. I am naming it because an article attacking happy-path demos has to name the parts that are still open, or it becomes the thing it complains about.

Right tool, right job

The win did not come from pointing AI at everything. It came from finding one repeating, well-bounded, universally disliked task and automating it against documented APIs, with verification on the output.

Most of the creative work was not touched, and should not be. Taste, framing, the decision about what the thing is for — none of that was ever the bottleneck, and none of it is where the week was going.

The evidence base everybody is deciding on

I publish my arithmetic with its caveats because the public ground here is remarkably thin.

The 2025 DORA report is the most honest thing I have read on the subject, and its headline is that “higher AI adoption is associated with an increase in both software delivery throughput and software delivery instability” [6]. Faster and shakier, at once. Adoption at 90%, a median of two hours a day with AI tools, and only 24% reporting substantial trust in it.

And the single most-quoted number in this entire argument — METR’s randomised trial measuring experienced open-source developers 19% slower with AI while they believed they were faster — has been retired by the people who produced it, who say the finding is outdated and their newer results unreliable [7]. It is still quoted weekly, usually without that sentence attached.

That is the evidence base organisations are signing contracts against — which is exactly why I would rather publish a flawed, labelled n=1 than another demo video.

We have done this before, in the other direction

I have spent twenty years around digital media. In that time it went fully digital and became enormously powerful — things that were flatly impossible are one click now, and colour work that needed a suite needs a laptop.

The work did not shrink. Expectations and volume grew into the new capacity, immediately and completely. Nobody went home earlier; everybody delivered more, in more formats, faster.

Code is getting the same compression of time-to-market. So the question is not whether capacity gets freed — it does, I measured some of mine. It is what happens to it: handed back as shorter weeks, or absorbed, with the bottleneck simply moving somewhere else? In software I think I know where it moved, and I wrote about that already — to review and accountability. I am not re-arguing it here.

The thing I now think is worth building

Here is what five months of evenings actually taught me, and it is not about efficiency.

The thing worth investing in may not be efficiency at all. It may be the flexibility to adopt — treated as an organisational capability in its own right, built, resourced and measured like one. We are early on a steep curve, and an AI adoption programme risks being obsolete on the day leadership signs the contract for it.

That is the subject of the next piece, and I am not going to develop it here.

In the meantime, one genuine question: has anyone measured their own revision-loop cost? Not the demo — the arithmetic. What the notes-after-done cycle costs you in a normal week, before and after whatever you adopted. If you have a number, even a scruffy one, I would like to compare it with mine. My day job at WANTED.solutions is where I make these calls with money attached, and I would rather not make them against my own measurement alone.

References

1. Model Context Protocol — open standard for connecting assistants to tools
2. Adobe — Photoshop UXP developer documentation, and the Adobe Developer Console; Adobe publishes supported scripting interfaces for Photoshop, Illustrator and InDesign
3. Blender — Python API documentation
4. Blackmagic Design — DaVinci Resolve; the scripting API is documented in the README that ships in Resolve's Developer/Scripting folder, and external scripting is a Studio feature
5. Adobe — Lightroom Classic SDK; Lua-based and plugin-shaped
6. DORA, 2025 — Balancing AI tensions, and Google, 2025 — DORA State of AI-assisted Software Development report
7. METR, 10 July 2025 — Measuring the impact of early-2025 AI on experienced open-source developer productivity, and the authors' later statement that the finding is outdated and their newer results unreliable