From Developer to Product Owner: How Building Tilores Studio Changed My Mind About LLMs | by Stefan Berkner | Jun, 2026 | MediumSitemapOpen in appSign up<br>Sign in

Medium Logo

Get app<br>Write

Search

Sign up<br>Sign in

From Developer to Product Owner: How Building Tilores Studio Changed My Mind About LLMs

Stefan Berkner

6 min read·<br>Just now

Listen

Share

Press enter or click to view image in full size

I’m a CTO, but I’ve spent most of my career as an engineer, and I have the opinions to prove it. So let me start with a confession: for a long time, I was the guy in the room who was quietly unimpressed by LLMs.<br>It’s not that I hadn’t tried them. I had. I’d reach for one to help with real work, look at what it produced, and feel that familiar itch: that’s not how I’d write it. The variable names were off. The structure wasn’t the structure I had in my head. The abstractions were the ones I would have argued against in code review. So I’d rewrite it. And after rewriting it a few times, I concluded the obvious thing — that for someone with strong opinions about code, the tool cost more than it saved.<br>The flaw in that reasoning took me embarrassingly long to see. My benchmark wasn’t “is this good?” It was “is this mine?” I was holding a machine to the standard of producing code in my personal style, and then declaring it a failure when it didn’t read my mind.<br>The crack in the armor<br>What finally got to me wasn’t another developer. It was Hendrik, a coworker who isn’t a developer at all.<br>In his spare time, Hendrik built papahilft.de — a genuinely nice, genuinely working project — with Claude Code. Not a toy. Not a screenshot of a toy. A real thing that real people could use.<br>That bothered me in a productive way. My entire objection had been about code quality, craftsmanship, how the thing was built. But here was someone who couldn’t have cared less about any of that, and he had shipped something I hadn’t. While I was busy defending my standards, he was busy having outcomes. It started to dawn on me that I might be optimizing for exactly the wrong variable.<br>Taking off the developer glasses<br>So I decided to run an experiment on myself: build something real, the way Hendrik did, and deliberately leave my developer instincts at the door.<br>The thing I picked was Tilores Studio — a desktop app to put a polished, human-friendly face on Tilores, our entity-resolution engine. Person matching, company matching, batch deduplication, entity exploration. A real product with real users in mind.<br>And then I made myself follow some uncomfortable rules:<br>- Stop judging how. Optimize for what. If it worked and the user couldn’t tell what the code looked like underneath, the code was, by definition, good enough.<br>- Let the assistant choose the stack. Electron, React, TypeScript, the GraphQL client, the router — I didn’t relitigate any of it. I stated the constraints that actually mattered and let the tooling decide the rest.<br>- Stop reading every diff to understand how each problem was solved. I kept a firm grip on the architecture — the parts where a wrong decision is expensive to undo — and let go of the line-by-line.<br>The first thing that happened is that I had an ugly, working prototype within a few hours. Ugly. But working. And it turns out “ugly but working in an afternoon” rewires your brain in a way that “beautiful but theoretical in three weeks” never does.<br>The role switch<br>Here’s the part I didn’t see coming.<br>Once features were being built more or less automatically, I had something I’d never really had as an engineer: spare attention. So while one feature was being implemented, I’d open Claude Design and design the next one. Or I’d write the requirements for the feature after that. Or I’d go test the thing that had shipped twenty minutes earlier. I was running three roles in parallel, and none of them was “type the code.”<br>And my internal monologue changed completely.<br>The old monologue was the engineer’s monologue, and it was fundamentally a monologue of constraint: “That feature would take too long.” “That’s a nice-to-have, cut it.” “We don’t have time to make that part good.” Every idea got immediately taxed by its implementation cost, and most of them didn’t survive the tax.<br>The new monologue was a product owner’s monologue, and it was a monologue of ambition: “That would actually be impressive.” “Users would love that.” “Why don’t we just… do the good version?”<br>That sounds like a small shift. It is not a small shift. It changes which ideas you even allow yourself to have.<br>The features that used to be “too expensive”<br>Let me make that concrete, because this is where the change stopped being a feeling and started being a product.<br>A dozen different ways to visualize a single entity? As an engineer, I’d have built one — the obvious node-and-edge graph — and called the rest scope creep. As a product owner, I asked the better question: what’s the best way to show how a cluster of records resolves into one identity? The answer is...