Genie App Builder, App Spaces, and governed vibe coding

Pull-quote: “The governance boundary has to exist before the first app does, because a portfolio cannot be reviewed one app at a time.”

Genie App Builder is in private preview, and so are the two capabilities announced alongside it, App Spaces and serverless micro apps. None of this is something you can enable this week, which makes it a good moment to do the part that is entirely in your hands: deciding what the guardrails will be before anyone starts describing apps into existence.

Genie App Builder is an AI-assisted app authoring agent built into Databricks with native awareness of your data assets, Unity Catalog semantics, and workspace context. You describe the internal app you want, or supply a screenshot for context, review a generated plan, and iterate with a live preview updating beside you. Databricks calls the philosophy governed vibe coding, and the word carrying the weight is governed, not the fashionable one (Databricks blog).

This post is for platform owners and data leaders who can already see what happens next: a hundred internal apps built by people close to the business, each reading production data, each needing an owner. It assumes you run Databricks with Unity Catalog. By the end you will know what an App Space governs, why AppKit being a TypeScript SDK affects your team, what micro apps change about the economics of small tools, and which decisions a plain-language description will never make for you.

What you will be able to do

• State what Genie App Builder is, what state it is in, and what it was announced alongside.
• Define an App Space and explain why the boundary has to exist before the first app.
• Say what AppKit provides and what its TypeScript foundation means for your review path.
• Explain when a serverless micro app is the right runtime and when it is not.
• Separate what a description can decide from the five decisions that stay yours.
• Run a preparation checklist now, while all three capabilities are in private preview.

What is Genie App Builder, and can you use it today?

Genie App Builder is a Databricks-native AI app authoring agent that turns a plain-language description of an internal application into a working app, and it is in private preview, so you cannot enable it in your workspace today. It was announced at Data + AI Summit 2026 with two companion capabilities: App Spaces, a governance boundary for a group of apps, and a new class of serverless micro apps that start on demand and scale to zero when idle.

The authoring flow is short. You describe what you want to build, or hand it a screenshot for context. It generates a plan, which you review before anything is built. Then you iterate, with a live preview updating in a side pane. Because the agent runs inside Databricks, it knows the tables you have, the semantics defined in Unity Catalog, and the governance policies in place, so it can find the right data and wire it into the app without you connecting anything by hand.

Say the preview status plainly to anyone you brief. Three capabilities in private preview is a direction of travel, not a plan you can commit a quarter to, and calling it available loses you credibility with the platform team you need on your side.

What is an App Space, and why does it come before the app?

An App Space is a governance boundary that configures resources, access management, and security policies for a group of apps, and every app created inside it inherits those settings automatically. Administrators define resource and data access, the API scopes used for on-behalf-of-user access, and the security policies, once, at the space level.

It comes first because per-app governance does not survive contact with volume. Reviewing one app is a meeting. Reviewing forty makes the platform team a bottleneck, and the outcome is either a queue nobody clears or a review that degrades into a formality. Defining the environment first inverts that: the guardrails exist before the first app is created, and builders work inside a pre-approved space rather than waiting for approval afterwards.

The second thing an App Space buys you is portfolio visibility, which sounds administrative until you need it. What apps exist, who owns each one, and how they are used are the three questions that decide whether you can deprecate anything. A portfolio without those answers only grows.

Draw your space boundaries on real trust lines rather than on the org chart. Data sensitivity tier, environment, and the population an app may serve are boundaries that mean something. A space per department means the boundary changes every time the department does.

What is AppKit, and why does the SDK choice matter to you?

AppKit is a TypeScript SDK designed for production-ready Databricks applications, and apps built by Genie App Builder are built on it. It handles caching, telemetry, retry logic, and integration with Databricks data and resources, so a generated app starts with the parts of production readiness that generated code usually omits.

That standardisation is the real benefit. When every app in a portfolio shares one runtime shape, telemetry is comparable, retry behaviour is consistent, and an engineer who has debugged one app can debug the next. The alternative, which most organisations already have, is forty internal tools each with its own idea of how to cache a query.

The consequence to plan for is language. Your internal app portfolio will be TypeScript, while your data platform team is very likely Python and SQL. Somebody has to read the generated code when an app misbehaves in a way the preview did not show. Decide now whether that is a front-end engineer you borrow, a platform engineer you upskill, or a rule that generated apps reach production only after someone who writes TypeScript has read them. All three work. Not deciding is the failure.

What do serverless micro apps change about a small internal app?

They change the economics, by making a small internal app usage-priced instead of capacity-priced. Serverless micro apps run on a micro VM based runtime where each app gets its own lightweight virtual machine, so it starts quickly when needed, scales all the way down when idle, and stays isolated from the apps beside it.

The class of app this affects is specific: departmental tools and line-of-business workflows used in bursts and idle most of the time. On always-on dedicated compute those apps pay for capacity nobody is using, which is why they get deprioritised in a cost review and never built.

Choose the runtime by traffic shape rather than by novelty. A tool used twice a day by a planning team is a micro app. A dashboard a hundred people hit continuously through the working day is not a scale-to-zero workload, and treating it as one moves the cost from idle capacity to cold starts your users feel. Isolation cuts both ways as well: per-app virtual machines are a security property worth having and a reason the portfolio needs an inventory, since each app is now its own thing to patch and retire.

What can a plain-language description decide, and what stays yours?

A description can decide the layout, the flow, and which registered data the app reads, and it cannot decide any question your organisation has not already answered. That is the honest limit, and it is not a criticism of the tool. An authoring agent grounded in your workspace inherits your workspace’s clarity, including its absence.

Five decisions stay with you no matter how good the generation gets.

1. Which number is authoritative. If revenue has three definitions in your Gold layer, the app will confidently show one of them. Define the measure once, as a metric view or a Unity Catalog function, before the first app reads it. The governance work behind that is set out in ontology governance and the semantic layer.
2. Who may see what. Unity Catalog and the App Space configuration decide access, including the API scopes for on-behalf-of-user access. A prompt describing an audience is a design note, not a grant.
3. Whether the app should exist at all. Two hundred overlapping apps is a governance problem no builder solves, and the marginal app is cheapest to refuse before it has users.
4. What the app is allowed to write. An app that reads is a report. An app that writes is a system, with idempotency, a state machine, an audit trail, and an approval path. Decide the write policy at the space level and keep write capability rare.
5. Who owns it in eighteen months. Someone patches it, someone answers when it breaks, someone eventually retires it. Record the owner at creation, because nobody volunteers later.

Operations for apps is also unsolved here. Databricks describes apps as a roadmap item rather than preview scope for its operations agent, which is one more reason to keep the portfolio small and owned, as covered in Genie ZeroOps and the review-and-approve operating model.

What should you do now, while all three are in private preview?

Do the four things entirely within your control, none of which requires the product.

Start with an inventory, because you already have a shadow portfolio. Count the spreadsheets, notebooks shared as tools, and small internal apps people currently depend on, and record who owns each and what data it reads. That list is your migration candidate set and your evidence for how fast this grows once building gets easier.

Then design the space boundaries and write them down: how many App Spaces, on which trust lines, with which resource and data access, API scopes, and security policies. Next, fix the semantics the apps will read, so the first generated app inherits one definition of every contested measure. Finally, write the two policies that otherwise get written under pressure: which apps may write and to where, and who reads generated TypeScript before an app reaches production.

A useful checkpoint on the inventory: if you cannot name an owner for more than half the tools you found, ownership is your first problem and a builder would have made it worse.

Where this goes wrong

Symptom: forty apps appear in a month and nobody can say which are used. The cause is a portfolio with no boundary and no ownership record, which is the default outcome when building gets cheap. The fix is an App Space per trust boundary, an owner required at creation, and a usage review on a schedule.

Symptom: two apps show different revenue for the same month. The cause is semantics resolved at generation time instead of in the catalog, so each app picked a plausible column. The fix is a metric view or a Unity Catalog function per contested measure, and a rule that apps read measures rather than recomputing them.

Symptom: an internal tool costs more to host than the work it saves. The cause is a bursty workload on always-on compute, or a continuously used app on a scale-to-zero runtime. Choose the runtime from the traffic shape, and revisit it once real usage exists rather than at design time.

Symptom: the security review stops every app. The cause is that on-behalf-of-user API scopes and data access were never decided at the space level, so each app arrives as a novel question. Decide those once per space, and the review becomes a check that the app is in the right space.

Symptom: the app works and nobody can change it. The cause is generated code with no repository, no tests, and no reader who knows the language. The fix is unglamorous: the app lives in version control, an engineer who writes TypeScript has read it, and the person who requested it is named as its owner.

Common questions

Is Genie App Builder generally available?

No. Genie App Builder is in private preview, along with App Spaces and serverless micro apps, all three announced at Data + AI Summit 2026. Ask your Databricks account team about access rather than looking for a workspace setting, and do not commit a delivery date that depends on any of the three.

What does governed vibe coding actually mean?

It is Databricks’ name for the combination of two things that are usually in tension: describing an app in plain language and getting a working one, inside a governance boundary that was configured before the app existed. The generation part is the visible half. The App Space, which sets resource access, API scopes, and security policies that every app in it inherits, is the half that determines whether the model is safe at portfolio scale.

Do we have to write TypeScript?

You do not have to write it, because the agent generates it, but somebody on your side needs to be able to read it. Apps are built on AppKit, a TypeScript SDK for production-ready Databricks applications that supplies caching, telemetry, retry logic, and integration with Databricks resources. Decide before your first app whether the reader is a borrowed front-end engineer, an upskilled platform engineer, or a review gate.

Does an App Space replace Unity Catalog permissions?

No, it configures the layer above them. Unity Catalog still decides which rows and columns an identity may read, including row filters and column masks. The App Space decides which resources and data an app may reach, which API scopes it uses for on-behalf-of-user access, and which security policies apply. You need both, and confusing them is how a governance review ends badly.

Should a business analyst be building internal apps?

Yes for read-only tools inside a well-configured space, with a named owner and a usage review. Be much more careful the moment an app writes anything, because a write path needs idempotency, an audit trail, and an approval step, and those are engineering concerns rather than description concerns. The useful policy is permissive about reading and deliberately restrictive about writing.

Next steps

Build the inventory this week, because it is the artefact that makes every later decision concrete. List the spreadsheets, shared notebooks, and small tools your teams already depend on, and record the owner and the data each one reads. Then draft the App Space design on top of it: how many spaces, on which trust lines, with which data access and API scopes. Those two documents will survive whatever the preview turns out to look like.

While you are there, settle the money question, because a portfolio of apps and agents is a variable cost by design. What Genie costs and how to roll it out covers the pay-as-you-go model, the free monthly allowance, and the budgets an administrator should set before the second team gets access. If your engineers are also using the agent on the pipelines underneath these apps, Genie Code and agentic data engineering covers where to let that run unattended.

We publish what we test, including the governance patterns that hold up and the ones that do not, in AI Fieldwork.