6 changes you need to make when building products with AI

AI-led development feels like a rupture with everything that came before. In many ways, that’s true. But the goals of product engineering haven’t fundamentally changed. Product-market fit, adoption, and engagement are still the outcomes we optimize for. What has changed significantly are the constraints and how we need to respond to them.

Engineering capacity is the obvious example. 84% of developers already use or plan to use AI tools in their development process. I won’t be surprised if that number approaches 100% by next year.

Software methodologies tend to follow economics. So when speed of delivery is no longer the primary constraint, organizations naturally start looking for new ways to structure how work gets done.

AI-led development requires fundamental changes to how we build products. Here are six changes teams need to make.

1. Replace backlog tickets with work contracts

Even the most well-written user stories leave plenty unsaid. That was not a huge problem in the hands of an experienced engineer, who would intuitively know how to fill in the gaps.

AI agents, however, don’t have that institutional judgment unless we share it with them. And as the amount of agent-generated work grows, small ambiguities can add up and allow flawed assumptions to influence the development cycle.

That’s why I find it much more useful to think of a backlog item as a work contract — a precise agreement between the people defining the work and the agents executing it. Along with the expected outcome and business objective, the contract captures the constraints an experienced engineer would normally carry in their head, such as:

• Architectural boundaries
• Acceptance criteria
• Evaluation criteria
• Explicit definition of done

As frontier models improve, the amount of detail we need to encode in that contract will likely decrease. But for now, better contracts are one of the most practical ways to give agents more autonomy without giving up control.

2. Move from sequential delivery to parallel experimentation

Parallel agentic work can speed up development by splitting large implementations across sub-agents. But more interestingly, it can also let teams pursue several plausible solutions to the same product problem in parallel.

Product development has traditionally forced teams to make consequential decisions early. You could debate onboarding approaches in a meeting, but eventually someone had to choose because building several plausible options was too expensive.

AI agents can take the same product brief and pursue several credible approaches in parallel. I am seeing teams push several prototypes much further, sometimes using the same code, tests, and infrastructure that would eventually support the product.

The decision can therefore incorporate evidence that was previously available only after the team had committed, such as user behavior, implementation complexity, latency, edge cases, integration problems, and operating cost. Also, product teams, with the help of agentic coding, can now create live production A/B tests much faster and capture real end-user engagement metrics.

Parallel work does not mean every problem suddenly takes a third of the time. Well-specified work can compress dramatically, but ambiguous problems may still require several rounds of iteration. The gain is that those iterations no longer have to happen one after another. You can learn from several plausible answers and optimize for speed of learning.

3. Convert architectural judgment into enforceable constraints

Senior engineers have traditionally maintained architecture primarily through experience and informal guidance. But as agents take on more work, more of that judgment should become enforceable.

Policy-as-code, dependency rules, design systems, and coding standards can turn decisions that once lived in people’s heads into constraints that apply automatically.

AI has lowered the marginal cost of creating tests, which changes how ambitious teams can be about coverage. Modern suites can combine unit, integration, functional, performance, and property-based tests, giving agents far more signals about whether their work meets the system’s standards. When AI has sufficient and well-thought-out boundaries, it can move quickly without requiring constant supervision.

4. Move from static wireframes to coded prototypes

Designers and engineers have usually worked in completely different environments. Designers explored a product in Figma, then engineers translated those screens into working software. The handoff has always been a critical part of the process.

One way many designers are removing friction from the handoff process is to use many of the same AI coding tools as engineers to turn an idea into an interactive prototype, complete with real interactions, sample data, and edge cases. Instead of explaining how a design should behave, they can demonstrate it in action. That makes prototyping useful for more than communicating requirements, as teams can put functioning experiences in front of users earlier and deliver to engineers something much closer to the intended experience.

5. Retain AI infrastructure in-house

I occasionally see organizations treat AI like any other SaaS category. They’d let an external vendor buy seats, drive the implementation, and handle all the complexity.

The problem is that this complexity is increasingly what determines your AI capabilities. Your model accounts, prompts, skills, agents, tools, configurations, embeddings, and organizational knowledge collectively determine what AI can do inside your company. The same infrastructure also tells you what is being used and how much it costs to run.

There is nothing wrong with bringing in an agency or vendor to accelerate the journey. But I would draw a clear line between getting outside help and outsourcing the foundation itself. Companies should control the privacy and retraining policies that govern how frontier model providers handle their data.

The accounts should be yours, the knowledge should remain in your environment, and the prompts, agents, skills, and configurations your teams develop should become organizational assets. The same applies to inference costs and usage data — you want direct visibility into both. That way, partners and models can change, but the capability you have built stays with you.

6. Shift security and governance all the way left

Shifting security and governance to the left has been popular in the pre-AI era as well. However, what was once a best practice is now absolutely table stakes. If AI is actively involved in product development, you simply can’t afford a checkpoint approach to security and compliance, where reviews happen late in the product life cycle. You need to embed oversight into product development from the very beginning rather than reviewing solutions when they are ready to launch.

Shifting left starts at the proof-of-concept (PoC) stage. While working on the PoC, ask these five questions:

1. Which data platforms are you using?
2. What access controls have you implemented?
3. Is your data stored securely?
4. Is your data infrastructure compliant with relevant regulatory frameworks?
5. Do you have clear owners of datasets and data pipelines?

Settling these questions early allows you to design within known governance boundaries, avoiding costly surprises as the PoC approaches production.

AI should sharpen human judgment at scale

When you look across all the above changes, there’s a common thread running through them. It’s the promise of sharpening human judgment at scale. Ultimately, that’s what I believe AI should do.

That is why blanket promises of 10x productivity can be counterproductive. Some tasks will collapse from days to hours; others will barely move until teams learn a better way to approach them. When teams feel pressured to prove those gains, quality and security can quickly become tempting places to cut corners. The better investment is helping engineers spend less time on implementation and more time making the decisions that require ingenuity and experience.

We’ve been developing the Modus Agentic Framework™ to help teams put these ideas into practice, embedding AI across all product roles throughout the development process while keeping human judgment at the center.

The Modus Agentic Framework™ gives product teams a structured way to define work, use agents to explore and execute, evaluate outputs against evidence and business goals, and decide what to do next. It is grounded in what we’ve learned from active work with Global 2000 enterprises. You can learn more here.