We Generate Art With AI. We Don't Generate Code With It.

Two things are true about how we work, and side by side they can look kind of contradictory.

The background art on the Ostium site came from Midjourney. The hero visuals on 43's site were also generated, then animated in After Effects and finished in Photoshop. That's not hidden, it's in both case studies.

Our dev work is written by senior engineers. We don't put generated code into a client's repo without someone owning it.

People read that as a double standard. It's not. It comes down to how you actually check each kind of output, and once you see that, the whole policy makes sense on its own.

You can check one instantly. Not the other.

You can look at an image and just know if it's right. A visual asset either looks good or it doesn't, and you know that in a second, no tools needed. If a Midjourney output is off, you know right away. Fix it or toss it.

That's also why it never ships raw. On Ostium those generations became background pieces inside a system we designed, art-directed against a brand we built. On 43 they got composited and animated frame by frame. The tool made raw material, a person made every real decision.

Code doesn't work that way. You can't just look at a function and know it's right. Whether code is correct only shows up when you run it, across different inputs, states, browsers, and time. Reading it tells you if it looks reasonable, and "looks reasonable" is exactly what these models are good at faking.

Here's the real problem: broken generated code usually looks totally fine. It compiles. It works for the obvious case. It handles exactly what you asked for. Then four months later, something breaks in a path nobody tested, in a live product, with real users and real money running through it.

A bad image, you notice that afternoon. Bad code, you notice next year.

Checking someone else's generated code can take longer than just writing it

The pitch for AI-assisted coding assumes checking the output is easy. For anything real, it's not.

When an engineer writes something themselves, they're carrying all the reasoning as they go, why this structure, what it assumes, where it'll break, what it's not built to handle. That understanding is the actual value. The code itself is just the output.

Reviewing code you didn't write means rebuilding all of that thinking from scratch, without having made any of the calls yourself. Fine for a small function. For anything with real structure, doing that review properly can take longer than just writing the thing, so in practice, it gets skimmed. What ends up shipping is code nobody fully understands, sitting in a repo someone still has to maintain.

There's a worse version of this too. A junior dev can't actually review generated code, because reviewing it requires being able to have written it yourself. Teams leaning on generation with junior staff aren't moving faster. They're just piling up code that has no one behind it.

That's part of why we don't put juniors on client work. It's not just about quality. What you're actually paying for is judgment, and generating code without judgment gives you exactly the mess it's supposed to prevent.

We hand the code back

Most of what we build gets handed off to a client's own team. That changes everything.

If we were the ones maintaining this stuff forever, we'd eat the cost of anything sloppy ourselves. We're not. A client's engineers inherit the repo and they're the ones working in it long after we're gone. When someone opens a file six months later and asks why it was done a certain way, there needs to be a real answer, not "it was generated."

Code with no real author is a risk you're handing over along with the invoice.

For bigger companies especially, this isn't just about how it looks. Generated code raises real questions, where dependencies came from, licensing on anything derived from training data, whether it'll pass a security review. Those questions have answers, but they're way easier to answer when a real engineer wrote every line.

What this doesn't mean

It doesn't mean the tools are useless. Any studio claiming they've banned them completely is either lying or wasting everyone's time.

The line is about ownership, not about avoiding the tools. Nothing goes into a client's repo unless a senior engineer either wrote it or fully understood it and takes responsibility for it. Inside that, there's plenty of room to use tools for the genuinely mechanical stuff, one-off scripts, poking around an API you don't know yet, boilerplate a person would've typed the exact same way anyway.

What stays human is anything involving an actual decision, architecture, data modeling, state management, anything touching auth, payments, or user data. Basically, anything where the right answer depends on understanding the actual product, not just recognizing a pattern.

It's not about how complicated something is. It's about whether the output needs real judgment about this specific product, and whether someone's going to have to explain it later.

Why we say this out loud

Putting "no AI slop" on our services page is kind of a bold move, and we've thought about toning it down.

We keep it because everyone else just leaves this unsaid, and buyers have no way to tell the difference. A studio that generates most of its code and a studio that writes all of it look exactly the same in a proposal. Same numbers, same case studies. The difference shows up eighteen months later, in maintenance costs, how long it takes a new engineer to get up to speed, whether anyone can actually change anything safely.

By then, whoever made the buying decision has moved on, and the client's team is stuck living with it.

So we put it on the page. If you're checking out studios, ask the question straight up, and ask it in a way that's hard to dodge. Not "do you use AI," everyone can answer that comfortably. Ask: who actually wrote the parts of the code you'll be maintaining, and can they still explain it.