The last year in web development has been crazy. We have seen an exponential rise in AI capabilities and adoption. AI now plays a central role in our industry's business processes, software development practices and strategic focus. Despite that, there is still one area where most companies are lagging behind: actually creating customer value with AI features.
There is a big gap between what AI makes possible and what ends up in production. In this post, I want to look at why that gap exists and what technology companies can do to bridge it by changing their systems and constraints, not just by building more demos.
The Prototype to Production Gap
The acceleration of AI capabilities has given us a new superpower that can be used by technical and non technical people alike. We can turn concepts and ideas into usable prototypes in a very short amount of time. What took months to build a few years ago is now doable in hours or days.
This has been a huge benefit for organizations. Product Owners, Engineers and UX designers are now able to prototype concepts quickly by using platforms like Lovable, V0 or Replit. Innovative concepts and new ways of solving problems are now part of our day to day. So why are we not seeing this translated into real features and customer value in our organizations?
Because most of our systems, processes and constraints were designed before this kind of iteration speed existed. They are built for stability and predictability. AI work needs systems that are stable but can also change shape. The problem is not just “fitting AI into the existing box”. The box itself needs to evolve.
When Prototypes Meet Reality
Picture the following scenario. Your production environment is built using micro frontends with Angular and multiple microservices built in Java. You have formal processes around the introduction of new technologies, mainly driven by security, compliance and past incidents.
A group of PMs and UX designers build multiple prototypes with AI tools. They use Next, React, whatever the tool generates. Stakeholders like what they see. When it is time to ship, Engineering explains that it does not fit: wrong framework, no way to integrate, no way to observe, no path through the existing processes.
Engineering is not wrong. The current constraints were never designed for fast AI work. They are static and hard to change. Good prototypes are not enough. You need constraints, interfaces and processes that can flex and be updated as AI capabilities and use cases change.
Making Constraints Evolvable
If you want AI features in production, you have to accept that parts of your architecture and governance will become moving pieces. The goal is not to remove constraints, but to make them explicit, adjustable and reusable.
Architectural constraints that can change
Take the Angular micro frontend and Java microservice setup. Instead of treating that as a fixed environment, introduce a small number of integration surfaces that you are willing to evolve over time:
- In the frontend, define a standard way to host new UI surfaces that can be built with different stacks. Early on, this might be a simple iframe slot. As you learn, you can move to a Web Component contract or a remote module pattern. The important part is that this hosting contract is allowed to change when AI use cases demand it.
- In the backend, introduce an AI service layer or gateway. At first it might be a thin wrapper around a single model provider. Over time it can grow to handle multiple providers, prompt templates, safety checks and usage limits. Again, the expectation is that this layer will evolve quickly compared to the rest of the system.
Existing services and frontends do not have to be rewritten. They just need clear integration boundaries where you accept that change will be more frequent. AI work then happens at those boundaries.
Code practices that don’t fight change
AI features and integration surfaces will shift a lot at the beginning. At that stage, trying to enforce perfect reuse and purity at the code level can actually slow you down:
- It is okay to have some redundant code in early AI features. You do not yet know which patterns will repeat and which experiments will die. Optimize for clarity and speed of change, not for having one abstract helper to rule everything.
- Only reach for DRY when you have actually discovered a repeated use case that is stable across features. Let duplication be a signal that something is ready to become a shared abstraction.
- Avoid premature optimizations that lock in today's assumptions. Overly abstracted gateways, shared libraries or “AI core modules” based on version 1 of your understanding will quickly become friction instead of leverage.
On top of that, embrace KISS as a default principle, especially with AI generated code:
- Treat AI output as a starting point, not a finished product. If the generated code is clever but hard to follow, refactor it to something simpler and more explicit.
- Favour straightforward, boring solutions over “magic” helpers and deeply nested abstractions. When constraints and integration surfaces are still evolving, simple code is much easier to adapt.
- Make it a rule that someone on the team must actually understand what the AI produced before it goes anywhere near production. If you cannot explain it, you cannot safely evolve it.
You still care about code quality. But the primary goal is to keep your integration surfaces and AI layer easy to evolve, even if that means living with a bit of duplication and very simple code while the dust settles.
Governance that can be recalibrated
Governance is another form of constraint. Today, many organizations treat it as fixed. For AI to be useful, you need governance that can be adjusted without putting the company at risk. A practical approach is:
- Start with a minimal AI change description. It captures which data is used, which external providers are involved and how the feature can be disabled. Use it for every AI experiment that might reach production.
- Use this description as input to refine your rules over time. When you see the same patterns appear, you can move them from “special case” to “approved path”. When you see repeated risk, you can update the guardrails.
The important shift is to treat governance itself as a system that iterates. You are not stuck with the first set of rules you wrote.
Risk controls that reflect AI behaviour
AI features behave differently from traditional ones. Output quality is probabilistic, model latency can vary, and providers change beneath you. Your risk and rollout mechanisms need to reflect that and be changeable too:
- Make feature flags, rollout rules and kill switches standard for AI related work.
- Watch not only classic metrics like errors and latency, but also simple quality metrics that can be tracked automatically or sampled.
As you learn, you will change which metrics matter and which thresholds are acceptable. The controls stay, their configuration evolves.
Team Setup That Supports Change
Changing constraints and architecture is hard if teams are organized only for delivery of fixed requirements. You do not need a new org chart, but you do need clear responsibilities.
Keep teams small and processes lean
Small, cross-functional teams with the right level of autonomy are far better suited to evolving constraints than large groups that spend most of their time in coordination meetings.
- Aim for teams that can own a slice of the system end to end: from prototype to integration surface to production rollout.
- Keep the process surface area as small as possible. Fewer standing meetings, fewer handoffs, more direct conversations around concrete prototypes and integration notes.
- Use lightweight rituals (short demos, quick tech notes, async updates) instead of heavy review ceremonies for every AI related change.
The more time teams spend actually building, testing and refining AI features against your evolving constraints, the faster your system will adapt.
Product, UX and Engineering together
The earlier Engineering is involved in prototype discussions, the easier it is to align ideas with evolving integration surfaces and constraints. A useful practice is that every serious prototype has a short companion note that answers three questions:
- Where would this live with our current integration surfaces.
- What needs to change in those integration surfaces to support it.
- What the expected impact is if we make that change.
This shifts the conversation from “can we ship this yes or no” to “what do we need to change in our system to make this kind of feature easier in the future”.
Red and blue teams as a feedback loop
Splitting work into a more exploratory group (red) and a more delivery focused group (blue) can work well if both sides are involved in evolving constraints. Red does not only explore product ideas. It also probes where the current constraints are in the way. Blue does not only ship features. It also updates integration surfaces, gateways and governance based on what keeps coming out of red work. Over time, this loop is what turns one painful integration into a standard pattern.
Organize around friction, not just roles
AI transformations introduce a specific kind of friction: not everyone is equally comfortable with the pace of change, with probabilistic systems, or with evolving constraints.
Instead of pretending this does not exist, organize your work around it:
- Identify where resistance to change is creating unproductive friction: repeated objections to experiments that are already low risk, endless debates about tools that will not be used in production, or constant attempts to freeze evolving interfaces too early.
- Assign people in a way that aligns with their strengths and comfort zones. Let those who enjoy exploration and ambiguity take the lead on prototypes and new integration surfaces. Let those who prefer stability focus on hardening the AI gateway, improving monitoring, and refining governance once patterns are established.
- Make it explicit that both roles are valuable. The goal is not to force everyone into the same mindset, but to ensure that friction is channelled into useful tension instead of slow, demoralizing stalemates.
When you design around the human side of AI change, your constraints evolve faster and with less drama.
The Target Flow
A healthy flow from prototype to production in an AI context looks like this:
- A team creates a prototype using AI tools.
- They map the prototype to current integration surfaces and note where those are lacking.
- They validate the idea with a small set of users.
- In parallel, the platform and delivery teams decide which changes to make to those integration surfaces, AI services and governance to support this idea and similar ones in the future.
- The feature is implemented against the updated constraints and rolled out with standard risk controls.
The important part is that steps 2 and 4 are about evolving the system itself, not just forcing the prototype into whatever is there today.
Small, focused teams with lean processes, pragmatic code practices and clear ownership of constraints make this flow much easier to sustain.
How This Looks In Real Life
Here is a simple, realistic scenario. You notice that your users spend a lot of time searching internal documentation.
You start as usual. You ask an AI assistant to help you design a quick prototype of an AI based search assistant. You describe your idea in natural language, generate a small app or component using a tool like Lovable or V0, and plug in an LLM and some basic context from your docs. This runs in a separate environment and a few users try it.
Now comes the important part. Instead of asking “how do we bolt this onto Angular and Java”, you ask “what needs to change in our system so this type of feature is easy to ship”.
You might decide on two changes:
- In the frontend, you introduce a documented way to host an assistant panel. For the first iteration this is a Web Component with a simple contract for props and events. The assistant prototype is adapted to that contract.
- In the backend, you stand up an AI gateway that can call the chosen model and your document index. You define how it authenticates, how it logs prompts and responses and how it can be switched off.
These are not one off hacks for this search assistant. They are the first version of your AI integration layer. You then move the feature to production using those new pieces. It is behind a feature flag, it uses the AI gateway, and it is wired into your existing monitoring. As you operate it, you will discover new constraints you need, and you will update the gateway, the panel contract and the governance rules.
Because your teams are small and crossfunctional, they can do most of this work without a long chain of approvals. Because you have accepted some code duplication at the edges, they can adapt the assistant quickly as you learn. Because you have organized around friction, the people who are uncomfortable with fast-moving AI pieces are not blocking the work; they are improving the stability of the parts that need it.
The next AI prototype does not start from zero. It targets the same integration layer and, if it needs something new, that becomes another explicit evolution of your system.
If your organization is great at building AI prototypes but bad at turning them into real features, the problem is not that AI does not fit your existing constraints. The problem is that your constraints were never designed to change at the speed AI demands.
The way forward is to accept that some parts of your architecture and governance need to become living components. Start with one or two well defined integration surfaces, one AI service layer and a simple way to describe AI related changes. Pair that with small, crossfunctional teams, pragmatic code practices and an honest look at where human friction slows you down. Use all of that on a real feature, evolve it based on what you learn, and keep repeating that loop. That is how you close the gap between “this demo looks amazing” and “this feature is quietly creating value in production”.
Top comments (0)