Inside Studio Haim
The systems behind the work.
Studio Haim is not just where the films are published. It is also the system used to make them, track them, learn from them and decide what happens next.
Most people talk about what agents can do.
I spend more time designing what they are not allowed to do unsupervised.
AI handles defined parts of the work. The decisions that matter stay human.
Creative work needs a workflow, not just a prompt.
A scene begins as an idea, but getting it to release means keeping writing, generation, continuity, editing, publishing and platform requirements aligned.
The studio uses a structured workflow to move a film from concept to finished release without losing track of what changed along the way.
Each project can carry its own creative DNA: how it opens, how many characters it holds, when the first punchline lands, how it ends, and the music, effects and cover choices behind it.
The goal is simple: make experimentation repeatable without making it mechanical.
I do not treat an AI agent as a person who should “figure everything out.”
Each agent or model gets a defined responsibility, enough context to do that job, and a result that can be checked.
That might mean generating a shot, reviewing code, reconciling publishing data, analysing performance or implementing a specific change.
The important part is not how autonomous the system looks.
It is whether I can tell what it did, why it did it and whether the result is safe to keep.
Anything consequential has a stopping point.
Publishing, spending money, destructive changes and decisions that cannot easily be reversed do not happen simply because an AI suggested them.
The workflow keeps a person in the loop before those actions happen.
For uploads, that stopping point is enforced in code. For spending money and destructive changes, it is a written repository rule that binds people and agents alike.
This sounds less exciting than “full autonomy”.
It is also much more useful in production.
Performance data is useful only when it answers a question.
The studio tracks releases across platforms and connects those results back to the creative decisions behind them.
Instead of treating every successful video as a new rule, experiments begin with a question.
Does opening directly with conflict hold attention better than opening with context?
The system keeps the hypothesis, the evidence and the decision apart. An experiment cannot be marked decided until both the evidence and the decision are written down.
A number is evidence.
It is not automatically a conclusion.
When an existing tool does not fit the workflow, I build the missing layer.
Studio Haim has its own internal publishing and performance system.
It connects creative work, release status, platform coverage, performance evidence, experiments and creative DNA in one place.
The publishing and performance systems were built around the same constraints: visible state, explicit approval before anything is uploaded, private as the default visibility, and evidence kept separate from decisions.
The system exists because the studio needed it.
That is generally how I approach digital products too: start with the real operational problem, then build only enough system to make that problem simpler.
AI makes building faster. It also introduces a new class of mistakes.
An agent can write perfectly valid code and still solve the wrong problem.
It can remove something because it looks redundant without knowing why it was created.
It can improve one screen while quietly breaking the workflow around it.
So part of the work is designing the environment around the agent: clear scope, repository rules, validation, observable state and checkpoints before production.
Each of the repository's working rules exists because something went wrong once.
The better the agents become, the more important this layer becomes - not less.
In practice
Three safeguards, and where they came from.
Enforced in code
An approval is bound to what was approved.
Approving a video for upload fingerprints the file and everything sent with it: platform, title, description and visibility. Just before uploading, both are measured again, and if anything changed, even only the visibility, the upload is refused. Visibility is part of what I approve, and it defaults to private: unless I choose otherwise, uploading does not publish, and making a video public stays a separate click on the platform. The upload path is built and tested.
How it is enforced
The check runs inside the uploader, not in the screen that calls it. Tests fail if an uploader could reach a platform before that check, if anything else imports an uploader, or if approving and uploading become one button. TikTok gets an inbox draft; nothing posts directly.
Enforced as a repository rule
The production rule has a date.
On 11 August 2026 the studio's internal system was deployed to production seven times from uncommitted code, then erased by the next routine merge. The next day it became a rule for every person and agent on the project: production comes only from the main branch, and code that is not in git does not really exist.
How it is enforced
No hosting setting blocks a manual production deploy, so the rule lives in the repository's written instructions. The same instructions require my explicit approval before anything acts on a live account, and do not let an agent change the rules without it.
Enforced in code
A missing number is not zero.
The first YouTube sync showed two new videos at 0 views and 0% watched; YouTube Analytics had not processed them yet. The sync now cross-checks a second YouTube source and records what it cannot measure yet as unknown, not zero. In experiments, a percentage is shown with the views behind it, and below 50 views no verdict is drafted.
How it is enforced
Each case is pinned by a test written from the failure that exposed it. It is also a written repository rule: 0 appears only when a provider returned zero, and “—” when a value is missing.
A small tool that came out of the work.
Homepage Reality Check is an open skill for a narrow question: is a homepage a clear product surface, or a polished demo?
It returns one verdict, exactly three fixes ranked by damage, and the elements that should stay locked. It is deliberately not a redesign or a full-site audit.
What I actually do
I sit somewhere between creative direction, product thinking, operations and implementation.
I take a messy process, work out what needs to stay human, what can be automated, what should be measured and where the system needs to stop and ask.
Then I build the workflow around it.
Studio Haim is the place where I keep testing that way of working in public.
Selected system principles
The constraints are part of the work.
- Give AI a defined job.
- Broad autonomy sounds impressive. Clear responsibility produces better work.
- Make state visible.
- A system should be able to tell you what is done, what is missing and what is blocked.
- Do not confuse output with evidence.
- A generated answer is something to inspect, not something to believe automatically.
- Keep irreversible actions human.
- Publishing, spending and destructive actions deserve explicit approval.
- Learn deliberately.
- One good result is interesting. A repeated result under a defined experiment can become a decision.
- Build for the actual workflow.
- Do not add infrastructure because it sounds sophisticated. Add it when the work needs it.
The films are the visible output. The system behind them is part of the work too.
I am interested in AI not as a layer added to an existing process, but as something that changes how the process itself should be designed.
That is what I am building and testing here.
If you're working on the gap between capable agents and reliable production systems, I'd be interested in comparing notes.