Studio 01 · Steven Hylands: “Build judgement, not the thing you've already got”

Studio is Okane Land’s founder interview series: builders making real things with AI, and the real numbers behind them.

Steven Hylands is a designer and co-founder of Stora, the self-storage software platform he’s spent five years building. He’s also one of the sharper voices writing on AI and work, the person behind “The Death of the Pixel Pusher” and the AI Honesty Badge. His codebase just crossed 10,000 pull requests, and nearly a quarter of them landed in the last six months. We asked him what AI actually changed, what it didn’t, and what a vibe coder should build first. He didn’t hedge.

The arc

You call yourself a founder and designer in Belfast writing about AI and work. How did interactive multimedia design lead to running self-storage software, and to some of the sharpest essays going on AI?

It started long before university. As a teenager I was just making things for fun on the internet, building websites, messing about, working out how it all fit together. Studying interactive multimedia design was really the formal version of that same instinct, a bit of everything, design and code and whatever the thing needed. Then at Stora I ended up doing all of it for real, design, code, sales, marketing, customer success, not by choice but because I had to. Starting a business has a funny way of handing you quick experience across a lot of different mediums. But the thread through all of it isn’t any one skill, it’s that I tend to be the person who spots when something’s misaligned or could be done better, and I’ve never been able to accept that something’s right just because that’s how it’s always been done. Taking a step back and asking why is a core product design skill, and it’s the same instinct behind the writing. I’ve always enjoyed writing, I just felt for years like I had nothing interesting to say. It’s only now, with enough experience behind me and enough trying to do things differently, that I feel I finally do.

The failure that taught the most

Give us the one failure that taught you the most, and the specific rule you now follow because of it.

The lesson that cost me the most: solve a problem painful enough that people will pay to make it go away, and make sure they’ve actually got a budget to spend on it. Lowdown taught me that. It got into an accelerator and every external signal looked good, and it still didn’t work, because the problem simply wasn’t painful enough for anyone to prioritise paying for. So now that’s the first thing I pressure-test on anything: is the pain real, and is there money already assigned to fixing it? If both aren’t true, you’re pushing uphill no matter how good the thing you’ve built is.

The workflow

In “The Death of the Pixel Pusher” you wrote that after twenty years you barely open Figma and shipped a whole Stora onboarding flow straight in the codebase. Walk us through the workflow: what tools, in what order, and where a reader should start.

Honestly the order of tools is the least interesting part, and I’d push back on the question a bit. The thing that actually mattered was five years of running Stora, talking to hundreds of customers, knowing what they care about, understanding what sells the product and not just what to worry about during onboarding. Even having the idea to build it the way I did came from that context. The tools only work because of what’s underneath them.

The AI side came from pushing myself to explore these tools relentlessly and never stopping shipping pull requests in the app, even when I was doing things I technically didn’t understand. Probing the limits, working out what my engineering team would accept and what they wouldn’t.

For tooling it’s mostly Claude Code, and the Claude Code Mac app has become my favourite way to work with it. I still drop into Cursor when I need to dig into the code, but I need that less and less as the tools get better at the abstract, chat level and hands-on digging matters less. Most of my time actually goes on building the plan, getting things to the point where Claude Code is ready to run. Once it produces something, it’s back to judgement: looking at the execution, judging it, iterating. One habit I’ve picked up: whenever something repetitive is worth reusing, I turn it into a skill and keep it updated for the wider team.

Where should a reader start? Not with the tools. Start with the context and the judgement, the part AI can’t hand you, then get your hands dirty and don’t stop shipping even when you don’t fully understand yet.

Which to build first

Your trifecta is thinking, judgment, and implementation. For a vibe coder who isn’t a twenty-year design veteran, which do they build first, and how, this month?

A vibe coder already has implementation. So don’t build the thing you’ve already got. Build judgement: the ability to look at what you shipped and know whether it’s actually any good, not just whether it runs. That’s the scarce one, and it’s what stops you flooding the world with plausible rubbish. There’s no real shortcut. You build it by shaping and learning, and this month that looks like shipping one real thing to real people and studying the best work in that space until you can see the choices behind it. It also helps to have experience across different domains, because they collide in useful ways and let you judge things from angles other people miss.

Don’t build the thing you’ve already got. Build judgement.

Building taste in 2026

You argue taste is what separates people who use AI well from people who just use AI. Give a reader three things they can do to build taste in 2026, when AI is removing the reps that used to build it.

Study great work like a mechanic, not a fan, take the things you admire apart until you can name the exact choices that make them good.

Ship real things to real people and watch what actually lands, not what you hoped would.

Find one or two people whose judgement you trust and let them tell you fast when your work isn’t good enough.

The catch in 2026 is that AI removes the reps that used to build all this, so you have to manufacture them deliberately. Do the hard version on purpose.

Study great work like a mechanic, not a fan.

Disclosing AI use

You built the AI Honesty Badge, and your blog is the featured site on the wall. What’s the case for a builder disclosing their AI use, and what would you tell someone who thinks staying quiet is smarter?

The case is trust. We’re already in a world drowning in AI output. Most of us are using AI to write these days whether we say so or not. A lot of the time it’s obvious, especially when someone hasn’t put much effort in. I’ve had plenty of moments where someone on my team handed me something that immediately felt off, AI output passed along without the domain knowledge to judge it first, and it made me think less of the work, not more. You can’t really hide it, so you may as well be honest about it. That’s what I built the AI Honesty Badge for, a simple way to say how much AI was actually involved. And to anyone who thinks staying quiet is smarter: being caught pretending you did it all by hand is a worse look than just owning the tools.

The more interesting question underneath is how much of your brain went into it. The words on the screen are mostly AI’s now, for most of us, most of the time, so what actually matters is the thinking that drove them. You’re really vouching for the brain behind the words, not the typing, and that’s what a reader is deciding whether to value. The label is a start. You earn the rest of that credibility in other ways.

The first task to automate

“Someone is going to automate your job, make sure it’s you.” Name the first task a reader should automate this week, how you’d build it, and how to find the time when the day job is always louder.

The first task is likely different for everyone. It might even be that you don’t have a task worth automating right now, and that’s fine too. But if you find yourself doing the same repetitive thing every day or every week, that’s where to start. For us at Stora the first real move was putting an AI support agent, Fin, onto front-line support. It showed how much AI can handle when it’s armed with the right knowledge, and it quietly flipped the job: support stops being about answering the same question for the hundredth time and becomes about the systems and documentation that feed good answers. That’s the pattern to look for, automate the repetitive answer, then move up to owning the system behind it. Start rough, one task and one hour, aiming for good enough to save you the next ten times. The point isn’t automation for its own sake, it’s freeing up time for the deep work, and the time is the hard part, because the day job is always louder and nobody hands you the hour. So you steal it.

The Stora number

Stora is in a boring, real-money industry. What has AI actually changed about the economics, and what’s one number that’s measurably different than two years ago?

It’s really only since the start of this year that we properly moved to an AI-native way of engineering across the whole org, so this is still early. The number I find striking is the shape of it. We’ve crossed 10,000 pull requests in the Stora codebase over the life of the product, and roughly 23% of them, nearly a quarter, landed in just the last six months. That recent spike is the AI part. But it hasn’t been a free win. When AI writes far more of the code, the bottleneck shifts to review, so we now spend a lot more time on the spec and the thinking up front, and a lot more on reviewing what comes out. The cost didn’t disappear, it moved onto judgement and review, which is exactly where you want your most experienced people. It helps enormously that we’ve got a lot of senior engineers who understand what they’re trying to do. Try this with a less experienced team and I don’t think it goes nearly as well.

The cost didn’t disappear, it moved onto judgement and review, which is exactly where you want your most experienced people.

Do the side projects earn?

Your side projects are out in the open: the AI band, the Honesty Badge, the blog. Do any of them make money, and should a builder expect projects like these to earn, or is the point something else?

None of them earn, and honestly none even have a mechanism to earn. Here’s the funny part: my number one rule is to validate that a problem is painful enough, and funded, before you build anything, and with these I break that rule completely, on purpose. They’re not businesses, they’re creative exploration, following my curiosity, keeping my skills sharp, having fun seeing what’s possible. If I were freelancing or out of work I’d snap straight back to the rule and obsess over proving someone would pay before I built a thing. But my money-earning time already goes to Stora, so these get to just be fun. I know the trap, that building is enjoyable enough to let you dodge the hard question of whether anyone actually wants it. With a side project, that’s allowed. That’s the whole point of it.

The more interesting thing I’ve noticed is with the tools I build just for myself and never publish. I’ll start out thinking maybe this could be a product, and then as I keep tailoring it to exactly how I work it becomes hyper-personalised, useless to anyone but me and perfect for me. I’ve got several little Mac apps like that. I think personalised software is in its infancy, and once you get in the habit of building your own tools it genuinely changes how you think about build versus buy. I still buy plenty of software, but for some things a tailored alternative I’ve built myself is just better. I’m curious how that shifts over the next few years.

A wrong take on AI

What’s a popular take on AI right now that you think is flat wrong, and what should people do instead?

That AI levels the playing field, that now anyone can build or write or design and expertise doesn’t matter any more. It’s backwards. AI makes taste and deep domain knowledge more valuable, not less, because it’ll happily hand you something plausible and confidently wrong, and only experience can tell the difference. Give these tools to someone without the foundations and they don’t produce great work faster, they produce work slop faster, and everyone around them can tell. AI is going to make people who aren’t great at their work still look not great at their work, just faster. Use it to go deeper in the thing you actually know, and treat judgement as the skill worth protecting. It’s the one thing the model can’t hand you.

AI is going to make people who aren’t great at their work still look not great at their work, just faster.

---

Steven Hylands co-founded Stora. He writes about AI and the future of work at shylands.com, built the AI Honesty Badge, and posts on X as @shylands.