A new AWS partnership with Superblocks points toward a future in which anyone in a company can create software with AI—but the applications, data, models, and controls remain inside the corporate cloud.
Imagine a finance manager at a manufacturing company noticing that a routine process is wasting hours every week. Employees copy figures from one system into another, email spreadsheets for approval, and wait for someone in IT to build a better workflow. In the near future, that manager might open a browser, describe the problem in ordinary language, and ask an AI system to create an internal application.
The first version could appear in minutes: a dashboard, a form, an approval queue, and a database behind it. The manager could adjust the interface by continuing the conversation. Add a field. Change the permissions. Send an alert when a purchase order exceeds a threshold. Show regional totals. Make the application available to the procurement team.
But in a large company, the most important part of that scenario would happen behind the scenes. The application would not necessarily send sensitive data to an unfamiliar external service. It would not live in an unmonitored corner of the internet. Its database, encryption keys, network rules, identity controls, audit logs, and model access could remain inside the company’s own private cloud environment.
That is the promise behind a multiyear joint marketing agreement between Amazon Web Services and Superblocks, a startup building AI-powered tools for creating business applications. Superblocks’ software will be able to run inside AWS customers’ private clouds, while applications created through the platform can use Amazon Aurora databases in those environments. The product will also integrate with Amazon Bedrock for access to different AI models and inference services. AWS plans to help sell Superblocks through its enterprise channels.
The arrangement is significant because it addresses the central contradiction of enterprise “vibe coding.” AI can make software creation accessible to people who are not professional developers. Yet the easier it becomes to create applications, the harder it can be for technology departments to know what has been built, where company data is going, who can access it, and whether anyone is maintaining it.
Superblocks is offering a compromise. Let employees build quickly, but put the resulting software inside the company’s existing systems of control.
That compromise could become one of the defining patterns of enterprise AI adoption. The next phase may not be about companies choosing between centralized IT and uncontrolled experimentation. Instead, it may involve building a managed layer where employees can experiment freely enough to be productive, while the organization retains authority over data, identity, infrastructure, models, and risk.
The office application that never reaches public cloud
The phrase “vibe coding” describes a style of software creation in which a person explains what they want in natural language and an AI system generates much of the underlying code or application structure. The user may not know which programming language is involved, how the database schema is designed, or how the interface is assembled. They judge the result by describing changes and observing what happens.
For individuals and small teams, this can feel almost magical. A founder can build a prototype without hiring a full engineering department. A designer can turn a concept into an interactive demo. A marketer can create an internal calculator. A developer can delegate repetitive work to an AI assistant and spend more time on architecture or product decisions.
Inside a large enterprise, however, a useful application is not just a screen that works. It is also a collection of obligations.
The application may contain customer information, employee records, financial data, health details, intellectual property, or operational secrets. It may need to comply with industry regulations and internal policies. Its users may need different levels of access. Every change may need to be recorded. The system may have to connect to databases that cannot be exposed to a public service. It may need to remain available during an outage or be removed cleanly when the project ends.
A consumer-oriented AI app builder often begins with a simple question: Can the system produce something useful? An enterprise platform must answer a longer list.
Where does the data reside? Which model processes it? Is the prompt retained? Who can see the output? What happens if the model makes a mistake? Can administrators inspect the application? Can security teams block a particular connection? Can a company control the versions of the models used in production? What happens when the employee who built the tool leaves?
These questions are not peripheral to the product. They determine whether a company can use it at all.
By enabling Superblocks to operate inside an AWS customer’s private environment, the partnership aims to make those questions easier to manage. The application-building experience can remain conversational and accessible, while the deployment model resembles the infrastructure enterprises already use for other critical workloads.
That distinction matters. An employee may experience the process as asking an AI to make a tool. The company may experience it as provisioning a governed software system in a controlled environment.
From shadow IT to supervised creation
For years, businesses have struggled with shadow IT: employees adopting software without formal approval because the official process is too slow or the available tools do not fit the problem.
A team might create a spreadsheet that becomes a mission-critical planning system. A department might subscribe to a web service with a corporate credit card. An employee might paste confidential material into an AI chatbot because it is the fastest way to summarize a document. None of these actions necessarily begins with bad intentions. They begin with a gap between what people need and what the organization can provide quickly.
AI app builders could widen that gap dramatically. If a person can create a functioning tool in an afternoon, waiting months for a formal development queue will feel increasingly unreasonable. Employees will experiment whether IT departments approve in advance or not.
The corporate response could be to prohibit such tools. That may reduce visible risk, but it is unlikely to eliminate experimentation. Workers may continue using consumer services, private accounts, or unofficial scripts. The organization would then face the worst of both worlds: more AI-generated software and less visibility into it.
A governed platform offers another path. Rather than telling employees that they cannot build, the company can give them an approved environment in which building is observable and constrained.
The employee might still describe an application in plain language, but the platform could automatically apply the company’s identity policies. It could restrict which databases are available. It could route model requests through approved services. It could maintain logs of changes and interactions. It could require review before an application moves from a personal experiment to a team-wide system.
This is the difference between removing friction and removing boundaries. Enterprise software cannot remove every boundary. It can, however, move those boundaries into the background so that responsible experimentation feels less like a compliance exercise.
Superblocks’ pitch depends on making governance compatible with speed. If each generated application triggers a long review by multiple departments, employees will return to informal tools. If the platform can apply sensible defaults automatically, it has a chance to become the place where experimentation naturally happens.
The private-cloud version of an AI playground
The private-cloud deployment is the most consequential element of the AWS relationship.
Many companies use cloud infrastructure but do not treat the public internet as a single undifferentiated space. They divide systems into networks, accounts, regions, and security zones. Some workloads are isolated from external traffic. Some databases can be accessed only by particular applications. Some encryption keys are controlled directly by the company. The architecture reflects the belief that not every piece of information should travel through every service.
An AI application builder that sits outside this architecture can create a difficult exception. It may offer a beautiful interface, but connecting it to internal systems can require special permissions, data transfers, and security reviews. Even if the vendor promises not to misuse the information, the company must still evaluate the technical and legal implications of sending it elsewhere.
Running Superblocks inside the customer’s AWS environment changes that conversation. The product can be placed closer to the company’s existing applications and data. Network policies can apply in familiar ways. Security teams can use established tools and procedures. The organization can decide which services are reachable and which are not.
This does not make the system automatically secure. A private cloud can still contain misconfigured permissions, vulnerable code, excessive access, or poorly designed workflows. Keeping an application inside a corporate environment is not the same as making it trustworthy.
But location and control matter. A company that owns the surrounding environment has more options for monitoring and intervention than one that must rely entirely on a vendor’s external hosting model.
The ability to create Amazon Aurora databases within the customer’s private cloud is part of the same story. A generated application needs somewhere to store information. If that storage is automatically hosted outside the enterprise’s preferred architecture, the convenience of the builder can be undermined by the deployment model. Allowing applications to use Aurora inside the customer environment gives IT teams a database option that fits into existing AWS operations.
For the employee, this may be invisible. They may simply ask for a system to track vendor onboarding. For the infrastructure team, it means the data can be managed through familiar controls, including access policies, backups, monitoring, and encryption practices.
That invisible infrastructure is the product’s real enterprise value. The conversational interface attracts users, but the surrounding controls determine whether the tool can survive procurement.
Why Bedrock and model choice matter
The Superblocks integration with Amazon Bedrock also reflects a broader shift in how companies think about AI models.
The early consumer AI market often encouraged a direct relationship between users and a single model provider. A company built its product around one powerful model, and customers learned to adapt to its capabilities, pricing, limitations, and update schedule.
Businesses are increasingly wary of making that dependence absolute. Models differ in cost, speed, context capacity, reasoning performance, privacy terms, and suitability for specific tasks. A model that is excellent at summarizing documents may not be the best option for generating code. A lightweight model may be preferable for high-volume classification. An open-weight model might be attractive for organizations that need more control over deployment.
Amazon Bedrock is designed to provide access to models from multiple providers through an AWS-managed service. For an enterprise application builder, that can create a layer of flexibility between the application and the model underneath it.
Superblocks’ chief executive has argued that many chief information officers increasingly view model flexibility as necessary. That flexibility can include frontier systems from major AI labs, open-source models, and Chinese open-weight models, depending on a company’s policies and the task involved.
The practical implication is that an internal application should not have to be rebuilt every time the preferred model changes. A company might begin with a high-performing model for a pilot, switch to a lower-cost model for routine production tasks, and reserve the most capable system for complex cases. It might keep certain workloads within a particular jurisdiction or prevent sensitive information from reaching a model provider that does not meet its requirements.
The model becomes one component in a larger system rather than the entire product.
This is also where enterprise AI gets more complicated than a chatbot. A chatbot can appear to have one intelligence. A business application may use several models behind a single interface, routing requests according to sensitivity, urgency, cost, or task type. The user sees a response. The organization manages a network of model relationships.
Superblocks’ integration with Bedrock positions it within that network. AWS, in turn, gains another route for making Bedrock part of everyday business software—not merely an experimental service used by machine-learning teams.
The hyperscaler wants the control plane
The partnership also reveals how cloud companies are repositioning themselves in the AI economy.
The most visible contest has been over models. Companies have spent enormous sums developing systems that can write, reason, interpret images, generate video, and act on behalf of users. Those models attract attention because they are the part of AI that people can see directly.
But models are only one layer of an enterprise system. Around them sit identity management, storage, networking, monitoring, billing, security, application deployment, data governance, and integration with existing software.
That surrounding layer is sometimes described as the control plane. It determines which models can be used, by whom, with what information, and under which rules. It also determines how an AI-generated action becomes part of a company’s real operations.
AWS has a natural interest in owning as much of that layer as possible. If a company uses AWS for its infrastructure, Aurora for its databases, Bedrock for model access, and partner applications for business workflows, AWS becomes more than a provider of raw computing capacity. It becomes the environment in which enterprise AI is assembled and governed.
The Superblocks deal strengthens that position in two ways.
First, it connects AWS to a category of software aimed at nontechnical business users, not only professional developers. Second, it allows AWS to participate in the distribution of that software through its enterprise sales channels. The relationship is therefore not just an infrastructure integration. It is also a route into business processes where employees decide what tools they need.
This is a strategically important audience. Developers have long influenced cloud adoption, but AI app builders promise to expand software creation to operations managers, analysts, finance teams, customer support leaders, and other employees. If those users begin creating applications on top of AWS-controlled services, the cloud provider’s reach inside the organization grows.
The risk for AWS is that it could become invisible plumbing while another company owns the user relationship. The opportunity is to make that plumbing so useful and secure that customers prefer to keep their experiments—and eventually their production applications—within it.
Superblocks’ unusual moment
For Superblocks, the relationship is unusually consequential because the company remains relatively small. It had 50 employees and had raised $60 million as of its May 2025 Series A.
A partnership with a hyperscaler can give a startup credibility that would otherwise take years to build. Enterprise customers are often reluctant to place sensitive workflows in the hands of a young company, even when the product is compelling. An AWS relationship can signal that the software fits within a familiar commercial and technical ecosystem.
AWS’s enterprise channels may also help Superblocks reach buyers that would be difficult to find independently. Selling to large companies is not just a matter of demonstrating a good interface. It involves security assessments, procurement processes, architecture reviews, legal negotiations, and internal champions. A cloud provider already present in those conversations can shorten the path.
But the arrangement will test whether Superblocks can preserve the qualities that made its product attractive. AI app builders succeed partly because they reduce the distance between an idea and a working result. Enterprise sales can add layers of customization, permissions, documentation, and support. Each may be necessary, but together they can make a product feel like traditional corporate software.
Superblocks will need to serve two users at once. The first is the person who wants to build an application without understanding every technical detail. The second is the administrator who must understand exactly what that application is doing.
Those needs can conflict. The builder wants a blank canvas and immediate feedback. The administrator wants standardized components, approved connectors, predictable behavior, and the ability to shut down a project. The builder may value flexibility; the administrator may value limits.
The strongest products in this category will not treat those groups as opposing camps. They will design a system in which governance is embedded in the experience. A user can move quickly because the safe paths are the easy paths.
Vibe coding versus developer coding
Superblocks will also operate in a market that includes AI tools designed for professional developers. AWS’s Kiro, for example, is aimed at a different kind of software creation: helping developers work with code, specifications, and application projects. General business assistants such as Amazon Quick address another layer of interaction, helping users ask questions, analyze information, or perform tasks using business data.
These products may appear to overlap, but they represent distinct relationships with software.
A developer-oriented system begins with code as the primary medium. The AI helps a person who is already responsible for architecture, testing, deployment, and maintenance. It may generate functions, explain errors, write tests, or translate requirements into implementation details. The human remains close to the structure of the software.
A business-oriented app builder begins with outcomes. The user may care about a workflow rather than a codebase: tracking inspections, routing requests, comparing budgets, or managing a queue. The generated application is valuable because it makes a process visible and repeatable.
A general assistant begins with questions and tasks. It may summarize data, produce a report, or answer a request without creating a persistent application at all.
The boundaries will blur. A manager may start by asking an assistant a question, then decide to build a dashboard. A developer may use a vibe-coding interface to create the first version of an internal tool before taking over the code. A business application may eventually become important enough to require professional engineering.
This suggests that enterprises will not choose one universal AI product. They will build a layered environment. Assistants will handle short-lived interactions. App builders will create lightweight and medium-complexity workflows. Developer tools will support systems that need deeper customization and long-term maintenance.
The challenge will be moving work safely between those layers. An experiment should be able to become a governed application without being rebuilt from scratch. A generated workflow should be capable of entering a professional development process when it becomes important. An assistant’s output should not quietly turn into an operational decision without appropriate review.
The cost of making software too easy
The optimistic vision of vibe coding is that it gives more people the ability to solve problems. The cautionary vision is that it gives more people the ability to create systems nobody understands.
Ease of creation can produce an abundance of applications. Some will be useful for a few days and then abandoned. Others will quietly become essential. A team may build a small tool to coordinate a temporary project, only to discover months later that the entire department depends on it.
This creates a new form of technical debt. In traditional software development, technical debt often comes from rushed code, weak architecture, or deferred maintenance. In AI-generated software, it may also come from unclear ownership. Who knows how the application works? Who approves changes? Can the system be tested? What happens when the model generates a different result after an update?
The private-cloud model can address some governance concerns, but it cannot answer all of them. A company still needs policies for application lifecycles, data classification, human approval, testing, and retirement. It must decide which kinds of apps employees can create independently and which require professional oversight.
There is also the question of model behavior. If an AI system generates logic that appears correct but mishandles an unusual case, the resulting error may not be obvious. A procurement workflow could approve the wrong request. A customer-service tool could expose information to the wrong employee. A reporting dashboard could present an attractive but misleading summary.
The more approachable the tool, the more important it becomes to communicate limits clearly. Users should know when the system is generating code, when it is querying data, when it is making a recommendation, and when an action will affect a real business process.
Good design can help. The interface might show which data sources were used, which model handled a request, and what permissions the application requires. It might distinguish between a preview and a live deployment. It might require a human confirmation before sending an external message or changing a financial record.
These are not merely technical safeguards. They are psychological ones. People tend to trust systems that respond fluently and confidently. An AI-built application can appear more reliable than it is because its creation feels effortless. Enterprise design must make the invisible uncertainty visible without making the whole experience unusable.
What success would look like
The success of private-cloud vibe coding will not be measured simply by how many applications employees generate. A company could produce thousands of prototypes and gain little value.
A more meaningful measure would be whether organizations can solve small operational problems faster without creating uncontrolled risk.
Consider a regional logistics company. A warehouse manager needs a tool for reporting damaged shipments. The manager describes the workflow, connects the approved inventory system, and creates a form that routes cases to the right team. The application stores its records in an Aurora database inside the company’s AWS environment. Employees sign in through existing corporate identities. Security staff can review access and activity. If the workflow proves useful, the company can expand it. If it fails, the application can be retired without leaving data in an unknown service.
Or consider a hospital administration team that needs to coordinate equipment maintenance. A staff member can build an initial dashboard without waiting for a full software project, while sensitive clinical information remains outside the application’s permitted scope. The system can be useful precisely because its boundaries are defined.
In these examples, AI does not replace the people who understand the business. It gives them a faster way to express what they know. The human contribution is the judgment about what should be built, which exceptions matter, and how the process should work. The AI helps turn that understanding into an interface and a set of connected actions.
That is a more realistic future than the idea that every employee will become a software engineer. Most people will not want to understand every implementation detail. They will want tools that behave like adaptable colleagues: capable of taking instructions, showing progress, asking clarifying questions, and working within organizational rules.
The enterprise will still need developers and infrastructure teams. Their roles may shift toward setting the boundaries within which others create. They may build reusable components, maintain data connections, evaluate models, establish testing systems, and intervene when an application becomes too important for informal ownership.
The firewall is not the destination
The phrase “inside the firewall” evokes a clear boundary: trusted systems on one side, an unpredictable outside world on the other. Modern cloud environments are more complicated than that image. Data may move between regions, vendors, models, employees, and applications. Security depends on identity, permissions, encryption, monitoring, and continuous evaluation—not just physical or virtual location.
Still, the firewall remains a powerful symbol because it captures what enterprises are asking for. They want the speed of open consumer software without surrendering control of their information. They want employees to explore AI without turning every experiment into an unreviewed data pipeline. They want access to a changing field of models while preserving a stable operational foundation.
The AWS-Superblocks arrangement is an early expression of that demand.
It suggests that the future of AI application creation may be less like downloading a clever tool and more like entering a managed studio. Inside that studio, employees can sketch ideas with words. Approved data sources are available. Models can be selected according to the job. Databases appear within the company’s existing environment. Administrators can inspect what has been made. Successful prototypes can move toward production, while abandoned experiments can be removed.
The experience may feel informal at the surface, even playful. Underneath, it will be governed by the same institutional machinery that protects other enterprise systems.
That balance will determine whether vibe coding becomes a lasting business practice or remains a novelty associated with quick prototypes. If governance is too weak, companies will fear the tools. If governance is too heavy, employees will avoid them. The winning platforms will make the safe and useful path feel natural enough that people choose it without being forced.
For AWS, the opportunity is to become the infrastructure and control plane for this new style of software creation. For Superblocks, it is a chance to turn a young product into a standard enterprise doorway for AI-built applications. For companies, the promise is more practical: a way to let ideas travel from an employee’s imagination to a working internal system before the original problem has become obsolete.
The next generation of business software may begin not with a requirements document or a developer ticket, but with a sentence typed into an empty window. The important question will not be whether the AI can build the application. It will be whether the organization can make that act of creation visible, secure, maintainable, and worth trusting.