Something changed. Business-side teams started building things. Not requesting things from engineering, not waiting for IT approval.
The barrier dropped fast. AI removed the need to know syntax. No-code platforms powered by AI removed the need to understand APIs. The question shifted from “can we build this?” to “should we?”
That shift is real. Over the past few months, seven challenges have come up clearly and consistently. Here is what they are.
1. Not everyone starts equal in vibe coding
The promise is real. A business-side professional with no development background can now quickly build a Python script, a dashboard, or a working prototype.
But developers bring something that AI cannot transfer overnight: knowledge of what is possible, and what is not. They know when an architecture decision will be too costly later on and how to scope a project before writing a single line. They know when code will break under load. Business-side builders learn these things by running into them.
Tools like v0 and Softr exist precisely to close this gap. They abstract the complexity upfront and let non-developers ship faster. That abstraction has a cost. What gets built is rarely fully optimised for the specific needs of the organisation. It may be good enough now. On a longer time horizon, the cost of migrating away from a tool that no longer fits tends to be higher than anticipated.
The gap has not closed. It has shifted. Business-side teams are now capable of building things they could not touch before. Developers are still better at building things that last.
2. Security is an unfamiliar risk for functions that never had to think about it
For years, business-side teams operated with a layer of protection they rarely noticed. IT managed access. Engineering handled credentials. No one in business teams had to think about what lived in a .env file.
That separation no longer holds. When a business-side team member deploys an automation or connects an API, they are now responsible for things they have never been taught. API keys. Environment variables. Files that should never be committed.
The risk is not incompetence, it is unfamiliarity. A developer who accidentally exposes a credential knows immediately how serious it is. A business-side builder may not realise that a key pushed to a public GitHub repository can be scraped within minutes.
The cost of deployment has fallen. The cost of a security mistake has not.
3. Collaboration doesn’t come naturally when building was always a solo act
AI makes it easy to build alone. It does not make it easy to build together.
A business-side professional who has found their footing with Claude Code and n8n can move fast. When a colleague needs to pick it up, or a manager wants to understand what was built, the cracks appear.
Version control, shared repositories, documentation: these are not instincts. They are disciplines that development teams have spent decades establishing because building in isolation does not scale. Business-side builders are arriving at the same problems, without the same institutional knowledge to draw on.
The tools exist. GitHub is not technically difficult. The challenge is that no one has told most business-side builders that this part of the job exists. The focus is on shipping. Collaboration infrastructure and documentation often comes later, usually when something breaks.
4. What you ship in hours may not survive the week
AI lowers the cost of building. It does not lower the cost of maintaining what you built.
Open LinkedIn and the same content appears. An AI agent built in two hours that automates everything. Fast to build, impressive in a screenshot, silent about what happened sixty days later. Building systems that hold up looks different. It involves running the same process repeatedly, finding where it fails, correcting it, and running it again. That version of the story does not perform well on LinkedIn.
What survives is what was built to be maintained: readable logic, documented decisions, a clear owner.
The question before shipping is not “does this work?” It is “who fixes this when it breaks at 9am on a Monday?“
5. AI amplifies confusion when there is no shared objective
A team that knows what it needs to build will move faster with AI than without it. A team still figuring out what it wants to achieve will produce more, faster, and with less clarity. The output will be harder to evaluate, harder to prioritise, and harder to stop.
A motivated team member with a clear brief can ship something useful in a day. The same person without a clear brief will spend the same day building something that answers the wrong question.
The fundamentals have not changed. What problem are we solving? Who owns the output? What does success look like in three months? AI does not make these questions easier to skip. It makes the cost of skipping them higher.
Direction first. Tools second.
6. The real cost of deploying AI is rarely what you think
The subscription fee is the easy part.
What accumulates alongside it is harder to see. API calls on every form submission and webhook. Usage-based tools that scale silently with volume. Token prices that shift from one quarter to the next with no change to the workflow. Hours spent learning tools that get abandoned. Time invested in something a native feature replaces three months later.
AI tools and process can grow fast. Who is spending the most? On what? With what return? These questions tend to surface at budget review, not before.
The teams that deploy AI well treat it like any other operational system: track usage, set limits, and make deliberate decisions about what to keep running.
7. Betting on one model is a strategic risk
Most teams choose one model and build around it. Switching costs are real, prompts are tuned to specific behaviours, and managing multiple integrations adds complexity. Standardising on one provider feels like the practical decision.
The risk becomes visible over time. AI models are not stable utilities. Pricing changes without warning. Quality shifts between versions. Outages happen. Recent examples of price increases, rate limit issues, capability regressions, and service interruptions are sufficient reason to treat single-model dependency as a genuine operational risk.
The landscape is still young. The practical response is not to use every model for everything. It is to avoid building in a way that makes switching impossible. Keeping model-specific logic isolated and staying familiar with more than one provider are habits that cost little now and matter considerably later.
How to respond: back to fundamentals
Seven challenges. None of them new. What is new is the speed at which they surface.
AI has not changed the fundamentals of building on the business side. For any automation, workflow, or tool, the following are worth asking at every stage:
- Is it auditable? Can someone trace what happened and why?
- Is it scalable? Will it hold up as volume grows?
- Are costs controlled? Including API usage, token spend, and maintenance time?
- Are tool choices documented? Does the team know why a specific platform was chosen?
- Are process steps reproducible and interruptible?
- Is data handling compliant?
- Is input quality sufficient to reproduce the process consistently?
- Is output quality consistent? Is there a way to detect when it degrades?
These questions applied to a CRM workflow in 2018. They apply to an AI automation in 2026. What has changed is the cost of building. What has not changed is what makes the result worth keeping.