4 questions we ask before we let AI generate code

AI can write you a working feature in the time it takes to read this sentence. What it can't do is decide whether it should. And that call doesn't belong to the model but rather to the Product Owner.

At Hotovo, we've made peace with a slightly uncomfortable position: we want to be an AI leader, not an AI follower. That might sound strange when half the industry is racing to bolt AI onto everything. But for us, leading means adopting AI code generation deliberately, with our eyes open. Not because a client asked for “the AI thing.” And not just because it’s 2026 and everyone else is doing it.

So before a single prompt turns into a pull request, we run every request through four questions. This has genuinely become part of how I think as a PO, and honestly, part of how most people at Hotovo who work directly with clients think, whether that's a business analyst, a PO, or a delivery lead. Here they are, and why each one matters more than it looks.

1. WHAT problem are we really solving?

Before we ask "can AI build this?", we ask "should anyone build this?" It's tempting to reach for AI the moment a client says "can you add AI to this?" or "can we build it faster with AI?", but that's a feature request, not a problem statement. A good PO pushes back gently: what's the actual user pain? Would a clearer UI, a shortcut, or an existing tool solve it just as well, without writing a line of new code?

Part of this question is also watching how the client reacts and being ready to gently educate them. We're living through a moment where everything feels like it deserves AI just because it's the AI era, and clients feel that shift too. They see how fast the market is moving, and it naturally raises what they expect from us as developers. We don't push back on that shift. It's real, and we want to be leading it, not chasing it. But we're honest that "AI can build it fast" and "this actually adds business value" are two different claims. So we try to explain, plainly, that the whole market's delivery pace has genuinely sped up thanks to AI, but that speed often comes at the cost of quality, and that's the one trade-off we refuse to make.

This matters even more on complex projects, where a single change can have a massive impact, for example on how a wastewater treatment plant actually runs, like in our WTR Automation project. That's exactly where "let's just generate it" can quietly introduce complexity nobody asked for. So before we generate anything, we make sure we can explain, in one sentence, what real problem it solves. If we can't it doesn’t get built yet.

2. HOW fast can we deliver MVP value to validate the result?

Speed used to be the whole pitch: "We'll build it fast." That's not really a differentiator anymore because, in 2026, almost everyone can ship fast. So the more useful question is: how quickly can we validate whether it's worth building?

Interestingly, clients often pull in the opposite direction. Once a project starts, there's a real temptation to want the product delivered exactly to their imagined spec, down to the smallest detail, before anyone's willing to call it "real" and put it in front of users. That instinct is understandable, but it works against the biggest advantage AI gives us right now.

That advantage is this: the "unknown" period, the stretch where nobody actually knows if an idea works, used to last months by default. A standard MVP could take three to six months to build the traditional way before you learned anything real from it. With AI in the loop, a focused MVP can go from an idea to something testable in a matter of weeks, sometimes days for a narrow feature. That means we can validate an investment fast, learn from real usage, and iterate again just as fast, instead of committing months of budget to an assumption nobody has tested yet. That's a huge advantage of this era, and one we actively push clients to use.

We stay careful with that speed, though. Shipping fast isn't the same as building the right thing. Teams that ship without a clear read on what they're learning can end up with, as one industry analysis put it, "high logins, zero outcomes." Plenty of usage data but no real validation behind it. So for us, the question is: "How fast can we learn whether it's worth building?” Then we scope the smallest, fastest version of the product that can give us the answer.

3. WHO owns this code six months from now?

AI-generated code ships fast, but somebody has to live with it. Can our team explain what it does, test it, extend it, and debug it at 2 a.m. when a client's alarm system misfires? Or did it arrive as a black box nobody fully reviewed?

Something bigger is shifting underneath this question too. This isn't the same world where developers wrote every line by hand and control simply meant knowing the code inside out. Right now, developers, and honestly most people working close to code, are struggling to keep pace with how much of it AI can produce. So the center of control is moving. Instead of coming from knowing the code line by line, it increasingly comes from knowing the plan behind it, then reviewing both that plan and the resulting code several times before it ships. We still need to know exactly what's changing and what impact it will have. 

But the real shift, the one that defines this decade, is psychological: developers learning to trust that AI has generated good code. That trust has to be earned carefully, never assumed, because this is basically a butterfly effect: one small, unchecked assumption at the plan stage, one moment where someone skips a review because "the AI probably got it right," can quietly ripple all the way through to a very different, and sometimes much worse, final product. That's exactly why we've built several layers of control into how we work, and why we review them regularly inside Hotovo's own AI transformation stream.

This is where "vibe coding" quietly turns into technical debt. Why? Because it feels productive in the moment but gets expensive a quarter later. So we treat AI output the same way we'd treat any code we didn't write ourselves: read it, understand the assumptions baked into it, and make sure someone on the team can own it before it ships. If we can't answer "who owns this," then the answer is: not us, not yet.

4. Quality assurance: who owns what goes into production?

Speed and ownership only get us so far if quality quietly slips through the cracks along the way. So the last question we ask is blunt: what's holding the line on quality here, and is a human part of that line, or just standing next to it?

This is where we borrow a term that's been spreading through developer circles this year: "meat proxy." It describes someone, a developer, a PO, anyone, who takes AI output and forwards it along without reading it properly. Prompt goes in, answer comes out, human hits forward. No judgment applied in between.

It's an easy trap for a PO specifically: relaying a client's request straight into an AI tool and then relaying the AI's output straight back to the client, contributing nothing but the copy-paste. If that's our role in the loop, the client does not need us. They need a subscription. 

So quality assurance for us isn't just automated tests and CI checks. We run plenty of those too. It is a standing rule that a human reads, questions, and takes responsibility for what ships. Is someone really validating this before it goes out, or are we just the meat between two machines? If nobody can honestly say, "I reviewed this and I stand behind it," it doesn't go out. That's not a slogan. It’s literally how we avoid becoming a meat proxy for our clients.

How this shapes the way we work with clients

This is also why we've been leaning into something closer to the Forward Deployed Engineer (FDE) model for AI work, a role that's become one of the buzziest jobs in AI over the past few months. An FDE doesn't sit behind a ticket queue generating whatever's requested; they embed with the client, learn the actual workflow and constraints, and build (or generate, with AI as a tool) software that fits the real environment, not a generic version of what was asked for.

That's the approach we want with every client relationship, whether AI-assisted or not. To be close enough to the problem to push back on a bad request, and close enough to the code to stand behind a good one.

Nowadays, the best AI leaders aren’t the fastest to say yes. They’re the ones with teams that can say, “Yes, and here’s what we checked first,” and mean it.