Three project types. Three different relationships with AI. One question every product team is asking right now.

Almost every week, someone I’m talking to about a new product asks me some version of the same question: can we build this with AI? Sometimes it means “can it go faster?”, sometimes “can it cost less?”, and in medtech, often “will it put our certification at risk?” It’s rarely a yes-or-no answer, even when it’s expected to be.

I spent 13+ years inside RomSoft’s delivery engine before moving into Business Development: QA, product ownership, project management, people leadership. Each seat came with the same underlying questions: what does it actually take to get software right, and where do things quietly go wrong?

So before giving prospects my own answer, I went to three colleagues who face the question every day, from very different positions. Not to settle it – I don’t think it settles – but to understand how each of them draws the line, and why they don’t draw it in the same place.

George works on a research team inside a long-running product partnership, moving ideas from concept to prototype as fast as the tooling allows. Sebastian works in regulated software projects, where a single unreviewed line of code becomes a compliance exposure. Cristina works in between: a project that isn’t under IEC 62304 but follows the same AI rules anyway. Talking to all three, a pattern emerged that none of them would have described on their own. The skill that matters most isn’t using AI agents. It’s knowing how much autonomy a given piece of work can afford, and how much discipline has to sit around it. For anyone choosing a development partner, that’s the thing worth looking at.

How the AI bet looks inside a research-oriented SaaS development team

George works in a team that has evolved, over more than a decade, into something considerably more ambitious than it started out as. That growth changed the shape of the engineering problem: fewer things now have an obvious solution, so the team restructured around exploration – define the problem space, identify candidate approaches, build and evaluate prototypes, and only then decide what is worth carrying into full development.

George believes any project can bring AI into day-to-day development under the same baseline rules that apply to whoever writes the code: intellectual property, data confidentiality, and approved corporate tooling. Past that baseline, the team can use AI more broadly, with oversight matched to the task and the client’s requirements.

Using AI broadly, though, doesn’t mean using it everywhere from day one. In George’s world, one concept comes up constantly: the AI harness, the engineering north star for any agent. It explains the purpose of the area the agent is working in, what it’s allowed and not allowed to do, and how far it can go before it needs to check with a human.

George is open about how the team came to their current process. On one project, they drew up the architecture plan, started developing with AI against it, and gave the agent rules. But the harness wasn’t strict enough, and the rules weren’t followed with full consistency. Development accelerated, and for a while that looked like a win. Then, the team found the codebase had drifted from the plan and had to go back and correct it with human-built layer patterns, rules per layer, smaller agent tasks and review checkpoints.

Part of the reason an agent slips, it turns out, is context – or the lack of it. With a rich codebase and existing patterns to follow, AI tends to respect and replicate what’s already there. Dropped into an empty, greenfield layer with nothing to imitate, it gets “creative” instead, and mistakes creep in.

That lesson is now assimilated to every new project. The foundation is built with humans in the loop: the technical analysis, the concept and the core architecture stay with people, and AI gets a structure to validate against rather than a blank page to fill in. Only once the architecture is in place is the agent set up, with explicit rules and a harness for each architectural layer, defining what it’s responsible for there and what it isn’t allowed to touch. Acceleration comes after the foundation holds, not a moment before.

George is also careful to flag the limit of his own observation: the tooling changes quickly, so teams need to revisit their practices as capabilities improve. Three to six months, as he points out, is a long horizon in AI.

What hasn’t changed is the economics of testing an idea at all. If you can invalidate an idea in six weeks instead of six months, you can test four ideas in the time it used to take to test one. Real usage of the product – with telemetry inside – adds evidence that interviews and market research cannot provide on their own.

For a product team, this is where AI pays off first: not in writing more code, but in finding out sooner which ideas deserve to be built.

When every line needs an owner

If your software will one day face an auditor, this is the part that matters most. A partner who uses AI is only an asset if every line it touches can still be accounted for.

On regulated projects like medical software under IEC 62304, the standards were written on a premise that predates AI entirely: every line of code should trace back to a requirement. Every design decision should carry a documented rationale. Every review should leave a record an auditor can follow. This mechanism lets a team answer the one question regulators always come back to: “who decided this, and on what basis?”

Sebastian’s world shows why regulated teams set the line where they do – and it isn’t mainly a technology gap. As he puts it, agents can contribute to a wide range of development tasks; what makes project owners hesitate comes down to two reasons.

The first is the uncertainty around what happens to the code an AI model reads, and the context it has access to along the way. Corporate accounts are there to close the gap on approved tools, contractual terms, data-handling settings, and project-specific rules – but are they enough?

The second constraint is more concrete, and it gets stricter as the risk grows. Any tool used to build medical device software has to be validated for its intended use: you need to know where it comes from, what it does, and that it behaves predictably in the situations it will meet. For the higher-risk classes under IEC 62304 (B and C), the scrutiny is heavier. Which raises a question the industry is still working out: how do you qualify a tool that is non-deterministic by design? The friction, as he puts it, comes from what the standard requires of tools, not from engineers, management or project owners being closed to the idea.

So instead of trying to validate the model, the team controls everything around it. Only the approved tool is used, and only on the corporate license. Agent mode is off: the assistant answers questions in the chat window, but it doesn’t carry out tasks on its own. Every suggestion, whether an inline completion or a single question-and-answer exchange, is reviewed and accepted individually by a person. What gets accepted then goes through the same review, testing and traceability as code written by hand.

And every repository the assistant touches carries its own instructions file, so even a narrow suggestion stays anchored to that specific project’s standards rather than generic best practice.

That file doubles as a privacy filter. It defines what may and may not be shared with the assistant, so that proprietary code and client-confidential data never reach the vendor’s servers or end up in future model training. (Patient data was never in play – it sits encrypted in the database).

Within those limits, the assistant still earns its place: in defining requirements, in project documentation, and in searching for solutions to specific technical problems. And Sebastian sees clear room for more – in code review, technical spikes, proofs of concept, and finding problems in existing code – all areas where a person still signs off on the outcome.

Questions worth asking any development partner about AI

• Which AI tools do your engineers use, and under what license and data-handling terms?
• Can our code or data end up in a vendor’s model training?
• Who decides how much autonomy AI gets on our project, and who signs off on the output?
• How do you handle AI on modules that fall under IEC 62304, or under our auditor’s rules?
• Where have you measured a real gain, and where did AI not help?

Strict rules, measurable gains

Cristina’s team shows what strict rules look like on a project that doesn’t strictly need them. Her project isn’t under IEC 62304 and doesn’t touch patient data, but it is destined for medical laboratory management, so the team applies the same AI procedure regardless, even where some steps could probably be skipped.

It’s George’s point about context, seen from the other side: on a mature codebase, the assistant has patterns to follow.

Cristina’s own rule is simple: apply every suggestion by hand and let no line of code go unchecked. She doesn’t gloss over the trade-off either. The assistant helps less experienced developers move faster, but the more code comes out of it, the heavier the review becomes: AI tends to reach for solutions more elaborate than the problem requires, and someone still has to read every line.

But there are areas where the benefits are measurable.

One of the testers in Cristina’s team, when working with the assistant on automated tests under the same instruction rules, got a suggestion from the assistant for improving them, and then implemented it with its help. The nightly regression – several hundred Selenium tests that used to run for around eight hours – now finishes two to three hours sooner.

Same procedure, same one-suggestion-at-a-time review, and still a gain anyone can measure. Where the line sits is decided by the customer and the project type, not by what the tool could technically do.

What I’ll bring to the next conversation

Put side by side, George’s, Sebastian’s and Cristina’s workflows look very different. Underneath, they aren’t. Each is the same instinct sized to a different context: rules calibrated to how much a mistake costs. George’s harness is the proof that even the fast-moving side isn’t “no rules, move quickly.” Sebastian’s one-suggestion-at-a-time review is the same principle with almost no tolerance for drift. Cristina’s team shows that strict rules and real gains can coexist.

So whether you’re building a SaaS product that needs to find its market fast, or medical software that needs to pass an audit, here is what I’d want you to take from my colleagues’ experience.

The real question is how much autonomy the work can afford. AI can usually write the code. What sets the line is what a mistake would cost, who has to answer for it, and what the standards require of the tools. That conversation belongs before the first sprint, not after the first surprise.

Structure comes before speed. AI does its best work on top of something people have built and understood: a validated architecture, a mature codebase, patterns to follow. Skip that step, and the time saved early gets paid back later, in drift.

Strict doesn’t mean slow, and the line isn’t fixed. Even under the narrowest rules, with every suggestion reviewed by hand, our teams see measurable gains. And with tools changing every few months, where the line sits is something we revisit as the tools mature and as each client’s context allows, not something we settle once.

If you’re asking yourself “can we build this with AI?” about a product of your own, bring me the question. In a short conversation, we’ll look at which parts of your project could take more AI autonomy, which need tighter oversight, and what that means for your timeline and your audit trail. Send me a message here, or reach me at email.