Code is free, judgement's not

Code is basically free now. Point an agent at a problem and you have a working version before lunch. And yet: most orgs are still slow, and most of the software we use still isn't good. If building was the real bottleneck all this time, that math should have flipped by now. But it didn't.

People like to argue about whether models have judgement or taste. However you think about it, it doesn't really matter. There's no edge in using the same LLM everyone has to make a call. The truth is that the question was never "how do we build this quickly," it was always "how do we get the right feedback on this quickly." We just couldn't see it under the cost of building.

Here's what we're reading (and watching) this week around shifting your org to prioritize feedback and judgement: the workflow, the mindset, and the tooling.

Prototype the Path

Ethan Eismann ran design for Slack, and his piece is the clearest thing we've read on what changes in the workflow. The unit of a decision stops being the brief or the mock and becomes the working thing. Argue over a brief and everyone's reacting to a different product in their head. A prototype ends that.

For most of software history, prototyping was obviously right and operationally hard.

We couldn't agree more. Eismann's "Principles For The New Prototype Culture" alone are worth the read, including a perhaps surprising one from an article about prototyping: "Don't ship slop". Shift your workflows to get the right kind of feedback and leverage your in-house judgement.

Modern Engineering Values

Christoph Nakazawa with similar vibes from the engineering vantage point. "Coding is no longer the bottleneck. Now I'm bottlenecked on exercising judgement." If Eismann is the workflow change, this is the culture change: once code is cheap, what you value (and reward) has to change: ownership, taste, and guardrails tight enough that the feedback loop is instant.

With agents, everyone can generate a lot of bull**** all day long.

A model produces plausible work at a volume no reviewer signed up for, and the only thing between that and your codebase is someone with the judgement to say no. Which is why Nakazawa bets on small teams, two or three people with clear ownership. Prioritize judgement, hire for that, and unleash those small teams.

Quick

Full disclosure: we're both a little obsessed with this idea. Quick is an internal hosting platform at Shopify. Drop a folder of HTML and assets, get back a secure internal URL. No framework, no pipeline, no procurement conversation. (This thread is the fast explainer.) It's elegant and obvious in retrospect, a major unlock with minimal overhead.

We've gotten really good at saying no ... the constraints are the whole point.

So it's a judgement double-whammy: they're exercising restraint to solve problems elegantly and creatively, and they're also unlocking feedback to fuel their internal taste engine. The key isn't that everyone can build, it's that everyone can ship straight to where their colleagues will see it and react.

Fable 5 Review

Claire's latest "How I AI" episode where she puts Anthropic's new Fable 5 (the first generally available Mythos-class model, a tier above Opus) through real work. It crushes benchmarks and is genuinely better at hard, long-horizon problems. It's also worse at design, conservative on ambition, and writes specs almost nobody can read. Maybe "general" intelligence isn't so close after all.

One thing to try this week

Find one problem in your org that a low-overhead solution would unblock (a la Quick). It's easy to overcomplicate things (especially these days), but sometimes simplicity is the real cure.

Nothing comes to mind? Build Quick itself. Point an agent at the explainer and let it rip. Worst case, you spend an afternoon and learn something new. Best case, you hand your whole org the shortest feedback loop it's ever had.

Good luck out there. Can't wait to see what you build.

— Claire + Zach