AI is a tool. A very good one. But it doesn't know what my team should build next, which tradeoff we can live with, or when something is good enough to ship. Someone still has to make those calls, and that someone is a person.
I'm not going to tell you I'm "10x more efficient" or that AI has "unlocked my potential." Those framings irritate me, and I suspect they irritate you too. What I can tell you is where it saves me time. For me that comes down to three things: digging through data, prototyping and ideation.
Digging through data
A lot of product work starts with a pile of material and a question. The answer is usually in there somewhere. Finding it is the slow part.
We talk to users regularly, and turning interview notes into insight used to be a careful, manual process. Now I paste in transcripts, ask targeted questions, and get a first-pass synthesis in minutes. I still read everything myself. I don't trust a model to replace that. But the synthesis gives me a frame to react to rather than a blank page to fill.
It works the same way with numbers. I ask a question, look at the answer, and ask the next one straight away. I can follow a thread much further before I run out of energy for it.
The model is good at finding patterns. It can't tell me which one matters. I still have to check that a pattern is real, and decide what it means for the product.
Prototyping
I've always built things in the evening: small websites, experiments, tools that scratch an itch. But the gap between idea and working thing used to be painful. Setting up infrastructure, wrestling with configuration, writing boilerplate I'd written a hundred times before. It wasn't hard, but it was slow and draining, and it ate into the time available to think about the actual problem.
With Claude Code, that gap nearly disappeared. I describe what I want, it writes the scaffolding, I steer the decisions, it executes.
When iteration is cheap, you iterate more. The best ideas tend to come when you're building something, not before. So a prototype is no longer the thing you make after you've decided. It's how you decide.
The same approach works on real work problems. Our sales and marketing team regularly needs visual assets: images for proposals, presentations, campaigns. The usual process involved requests, waiting, revisions, more waiting. One evening I built a small internal tool, a Brand Image Generator, a simple interface on top of an AI model tailored to our brand inputs and use cases. Nothing technically impressive. And now the team uses it every week without involving anyone else.
A tool like that used to be a proper project, with requirements and timelines and a ticket in Jira. The threshold for trying something has dropped a long way. Whether it was worth building was still a call I had to make.
Ideation
My day job is Head of Product. The work is mostly thinking, writing and conversations. It turns out AI is useful there too.
I talk through a feature, messily, the way you'd think out loud, and then work with the model to structure it into something usable. The back-and-forth surfaces gaps in my thinking that I would have missed. The model asks logical follow-up questions. It generates edge cases I hadn't considered. It acts like a smart rubber duck that occasionally has better ideas than me.
It's also a quick way to get more options on the table. I can ask for directions I wouldn't have thought of and throw most of them away. Some are bland. A few open up the problem. Picking the one worth pursuing is the part that stays with me.
It all comes down to context
The quality of the output is almost entirely determined by the quality of the input. A short prompt produces something that could work for anyone, which usually means it's not quite right for you. The model doesn't know who you are, what you're building, or what good looks like in your context.
The thing that changed my results the most was writing proper context files: structured documents with the goals, decisions, tone of voice, conventions and constraints of a project. For this portfolio, that means a file describing the colour system, the typography, the copy voice, even what not to do.
Don't write these files yourself from scratch. Have a conversation with the AI first, then ask it to produce the file based on that conversation. Then read it, correct what's wrong and fill in the gaps it couldn't know. That last step forces you to own every line.
What speed costs you
None of this is free.
When execution is cheap, you can move faster than your judgment can keep up with. I've caught myself approving AI-generated code I didn't fully understand, or accepting a first-pass spec because it looked complete. You have to build habits around slowing down at the right moments, even when momentum wants you to keep going.
There's a question I find myself asking more often now: do I actually know how this works? When a model writes it, you have to actively reach for the understanding. At work I'm deliberate about making sure I can explain every decision, not just approve it.
AI is also fast at rough. Getting from nothing to something demonstrable is where it shines. The last 20% (the edge cases, the polish, the things that make a product actually good rather than merely working) still takes most of the time. And inside a legacy codebase, with years of decisions baked in and business logic living in places no one remembers why, it confidently produces code that looks right and integrates wrong.
A person still decides
AI doesn't make hard calls.
It will give you a well-structured analysis of a complex decision. It will surface tradeoffs clearly. It will even make a recommendation if you ask for one. But it doesn't understand your team, your stakeholders, the history behind the current architecture, or the risk of shipping something half-baked. The part where someone has to weigh incommensurable things and commit is still entirely human.
AI also doesn't have taste. It tends toward the reasonable. The best design decisions are often slightly off by conventional standards. They break a pattern on purpose.
And AI doesn't know what to work on. Given a problem, it's excellent. Deciding which problems are worth solving is still the hardest part, and it's still yours.
So I use it for what it's good at: getting through the data, getting to a first version, getting more ideas on the table. It gets me to the decision faster. Making the decision is still my job.