You Don't Need to Code Like a Developer — You Need to Think Like a Product Owner

I used to sit in product meetings watching engineers debate architecture decisions and secretly feel like I was only getting half the conversation. Now I'm shipping my own ideas. I'm not going to pretend I became a developer. But I'm not not one either.

Why this matters

There's a version of this story that's about AI being democratising and the future being now. That version is boring and also slightly dishonest. The real version is that I spent years building a very specific frustration: I could see what needed to be built, I understood users, I could write a product spec that would make a senior engineer nod, but the moment I was alone with a blank screen I was stuck.

My background is operations and product. I scaled a food delivery business across Austria, then moved into a more structured product ownership role at a national rail freight company. Two very different environments, one shared limitation: speed was always somebody else's ceiling, not mine. That's a hard place to be if you're wired the way I am.

So I started learning. A frontend course in Vienna. Experimenting with ChatGPT and Claude to generate code. Picking up just enough HTML and CSS to know what I was looking at. But without a real infrastructure layer, without understanding how the pieces actually connect, I kept hitting the same wall. Prototype. Impress myself. Immediately get stuck on something backend.

Then Claude Code happened.

What changed when AI moved into the infrastructure layer

This is the answer to one of the most searched questions in this space right now: can you actually build something real with AI coding tools if you're not a developer?

Short answer: yes, with an important caveat. The shift that made it real for me wasn't the AI getting smarter at writing code in isolation. It was Claude Code integrating directly into the development environment, specifically Visual Studio Code. That's the difference between someone writing you a recipe and someone standing in your kitchen with you.

Before that integration, I'd generate code in a chat window, paste it somewhere, watch it break, not know why, and start over. With Claude Code inside the IDE, the feedback loop collapsed. The model can see the file structure, understand what's broken, and suggest fixes in context. For someone who understands what they want but not always how to get there, that context is everything.

I describe it as getting 200 extra horsepower. The car was already mine. I just finally had an engine that matched what I was trying to do.

Claude Code vs OpenAI Codex: what I actually use them for

This is the other question people search for constantly, and most answers either read like a spec sheet or come from people who have never actually tried to build something with their own idea on the line.

Here's where I've landed, at least for now.

Claude Code is my primary driver. Its ability to hold context across a project, to understand what I'm trying to build conceptually, not just syntactically, is still the thing I value most. It's also genuinely good at front-end architecture, which is where most of my work lives. The limitation I keep running into is subscription-based: there are rate limits, and when you're deep in a build session, hitting a wall mid-flow is a specific kind of pain.

Codex entered my stack as an emergency backup when Claude hits its limit. What surprised me is that it earned a permanent spot. It's particularly sharp in debugging scenarios, catching logical errors and edge cases that sometimes slip through during faster generation. It handles isolated, well-defined tasks cleanly. Where it's weaker, at least in my experience so far, is in the bigger picture. Give it a full feature to architect from scratch and it starts to feel like it's thinking about the current file, not the whole system.

The honest summary: Claude Code thinks about your project. Codex solves your problem. Right now I need both.

I'll also mention Gemini here briefly, because I did try it. The integration into my current stack was rough and its ability to hold context across a longer build felt noticeably behind. I gave up faster than I expected to. That could change, and I'll keep an eye on it.

The next thing I'm genuinely curious about is improving the communication between Claude and Codex within the same workflow. Right now they're two separate conversations. The goal is something more like a handshake. Still testing. Will report back.

The real edge: thinking like a product owner, not a developer

Here's the argument I don't see made enough, and it's the one that actually changed how I work.

Most people trying to build with AI tools are trying to impersonate a developer. They're learning syntax, memorising patterns, trying to approximate what a software engineer does. That's the wrong frame entirely. And it's also exhausting.

The real unlock isn't replacing the developer. It's understanding that you don't need to.

What you need is to be a very good product owner. And if you've spent any time working in an agile or scrum environment — writing user stories, running sprint planning, defining acceptance criteria, grooming a backlog — then you already have most of the toolkit. You just haven't pointed it at an AI yet.

Think about what a product owner actually does in a functioning team. They translate business goals into clear, scoped, testable requirements. They prioritise ruthlessly. They communicate across functions — engineering, design, stakeholders — and make sure everyone is building the same thing. They ask the question "what does done actually look like?" before a single line of code gets written.

That's exactly what you need to do with AI. The tools that used to serve your engineering team now serve you. Claude Code is your dev team. Codex is the specialist you bring in for tricky bugs. You write the brief. You define the sprint. You review the output. You decide what ships.

The AI doesn't care if you can write a for-loop. It cares whether you can tell it precisely what to build, why, and how you'll know when it's working. That's product thinking. And if you've been doing product work in any serious capacity, you're closer to this than you realise.

There's also a deeper business advantage here that I think gets underestimated. Understanding how a business actually runs — unit economics, user flows, operational constraints, what matters to a customer versus what matters to an investor — gives you an edge that no amount of syntax knowledge can replicate. The AI can write the code. It can't tell you whether the feature you're asking for is the right one to build. That judgment, the business judgment, is still yours. And in a one-man setup, it's everything.

This is how you become a one-man company sooner than you think. Not by becoming a full-stack developer. By becoming the combining force: the person who understands the business well enough to direct an AI development team, who knows enough about the technology to have an intelligent conversation with the tools building it, and who doesn't need to wait for a sprint review to unblock themselves.

You don't need to replace the developer. You need to be the product owner who finally has a dev team that never sleeps and never needs onboarding.

What most people get wrong about AI-assisted development

They treat it as autocomplete. As a faster way to write the code they already knew they needed to write.

That framing undersells it and also sets you up for disappointment, because when you treat it as autocomplete it fails in very autocomplete-like ways. It confidently finishes sentences you didn't quite start right.

The better frame, the one that's actually working for me, is thinking of the AI as a technical co-founder who is infinitely patient, available at 2am, and needs you to know what you want to build even if not how. You still have to think. You still have to understand the output well enough to know when something is wrong. The frontend course I did wasn't wasted just because I'm not writing all my own code. It gave me enough vocabulary to be a useful collaborator instead of just a passenger.

There's also a practical architecture lesson here that took me longer than I'd like to admit: knowing enough about databases, API logic, and backend structure doesn't mean you have to write that layer yourself. It means you can have an intelligent conversation with the tool that's writing it for you. That distinction matters.

My personal website, ceylan.co.at, is itself the result of this stack. It's not a static template. It's a living thing I'm building and iterating, often at unusual hours, using exactly the tools I'm writing about here. That feedback loop, where the project and the learning are the same thing, is something I wrote more about in the context of building Fleamio, my startup, where the stakes of getting the architecture right are considerably higher.

What to actually do

• Start with the infrastructure layer, not the chat window. If you're serious about building, get Visual Studio Code set up and connect Claude Code to it. Generating code in isolation and pasting it somewhere is a frustrating and slow way to learn.
• Dust off your product owner toolkit and point it at AI. User stories. Acceptance criteria. Backlog grooming. Sprint scoping. If you've worked in agile environments, you already know how to brief a team. That's the skill. Apply it here.
• Learn just enough of the fundamentals to be a useful collaborator. A frontend basics course, a weekend with SQL, one solid read-through of how APIs work. You don't need to be able to build from scratch. You need to recognise when something is broken and ask the right question about why.
• Build your own stack in layers, not as a single bet. Claude Code as primary, Codex for debugging and when limits hit. Add tools when you have a specific reason, not because someone on Reddit said it's better.
• Treat the subscription limits as a forcing function. When Claude hits its ceiling, switch to Codex. The interruption is annoying but it also trains you to write better, more complete prompts the first time so you need fewer follow-ups.
• Let your business understanding be the moat. The AI can write the code. It cannot tell you which problem is worth solving, what users will actually pay for, or when a feature is a distraction. That's the judgment you bring. It's not a soft skill — it's the whole strategy.
• Document as you go. I'm doing this publicly on the site. You can do it privately. Either way, writing down what worked, what broke, and what you still don't understand is the fastest way to actually retain any of this rather than just producing output.
• Don't wait until you understand everything. The gap between what I know and what I'm building has been present the entire time. That's not a bug. That's how you learn faster than a classroom ever taught you to.

The stack will change. The tools will get better, or be replaced by something I haven't tried yet. What won't change is the underlying principle: if you understand the business, know what you want to build, and are willing to stay curious about how — the distance between a product idea and a working product is smaller than it has ever been. You might not need a dev team. You might just need to start acting like the product owner you already are.