Every studio claims to be “AI-forward” right now, and almost none of them say specifically what that means. We’d rather be specific, because the specific claim is the only one that’s actually checkable. So here’s where AI tools genuinely change how we work, and where we deliberately keep them out.
Where it helps: the first draft of anything
The clearest win is anywhere we’re producing a first draft that a human then has to evaluate critically anyway: a first pass at test cases for a function, a first pass at API documentation, a first pass at migration scripts for a well-understood schema change. In all of these cases, a person was always going to review the output line by line before it shipped. AI tools make that first draft faster to produce, which means more of the time budget goes to the review — which is the part that actually catches problems.
The failure mode we watch for here is skipping the review because the draft looks plausible. Plausible is not the same as correct, and AI-generated code is very good at plausible.
Where it helps: pattern-matching across a large, unfamiliar codebase
When we’re doing an architecture review or fractional advisory work on a system we didn’t build, the first week is mostly reading. AI-assisted code search and summarization genuinely speeds this up — finding every place a particular pattern is used, getting a first-pass explanation of an unfamiliar module before we verify it against the actual code. It doesn’t replace reading the code. It changes where we spend the reading time, from finding the relevant parts to verifying them.
Where we don’t use it: architecture decisions
We don’t ask an AI tool what the service boundary should be, whether to build or buy a capability, or how to structure a team around a system. These decisions depend on context that isn’t fully written down anywhere — the client’s actual constraints, the politics of their organization, judgment calls about risk tolerance that come from having made similar calls before and seen how they played out. An AI tool has no access to any of that, and confident-sounding output on a question like this is actively dangerous, because it’s the kind of answer that’s hardest to independently verify before you’ve committed to it.
Where we don’t use it: anything client-facing without disclosure
If a client is reading something we wrote — a scope document, a strategy recommendation, an email — they’re reading it because they trust the judgment behind it, not because they want fluent prose. We don’t generate client-facing strategic content and pass it off as-is. Where AI tools assist with drafting, a person is accountable for every claim in the final version, and we don’t blur that line to move faster.
Judge us on what we ship, not what we say
Talk is cheap here, which is why we’re deliberately not writing a broad “AI strategy” claim on this site. What we will do is build one small, real, narrowly scoped AI tool of our own — the same way we’d scope one for a client — and let it speak for itself once it’s live, rather than describing it in advance. If you’re evaluating whether a studio’s AI claims are substance or marketing, “show me the thing you actually built” is a better question than “what’s your AI strategy,” and it’s the standard we’re holding ourselves to here.