What AI Agents Taught Me About Building Databricks Apps

Most of that time on the frontend: React, components, the part of the product people actually touch.

Then AI agents started writing code. A lot of it, and faster than me.

And I had the same question I think a lot of us have right now: if the code writes itself, what am I here for?

My answer so far is to make the job bigger. I'm working toward what I call a "Super Engineer": software engineering, data engineering and AI engineering under the same belt.

I'm sharing it while it happens, wrong turns included:)

This is one of those turns. We built a production Databricks App with AI coding agents doing a big part of the work. The code showed up fast. Getting it to run correctly took way longer.

And every one of those extra hours went into knowledge the agents didn't have.

The agent types faster than I ever will. So what do I bring to the table now?

Databricks Apps let you host a web app right next to your data.

Users sign in with the identity they already have, every query can run as that user, and Unity Catalog decides what each person can see. For an internal tool on top of governed tables, that's pretty close to ideal.

Ask an agent for "a React app with an Express API that edits these tables" and you'll have working code in an afternoon.

Whether it runs is a different story. That part depends on configuration: a bundle file, user API scopes, a warehouse binding and three separate permission systems.

Most mistakes there are one line long. Many fail silently, or with an error that points somewhere else -> and an agent that reads the error and searches the code will confidently fix the wrong thing.

Our app: React plus Node/Express in one container, reading and writing Unity Catalog tables through a SQL warehouse, deployed with a Databricks Asset Bundle and promoted from dev to sqa to prd through CI.

One request, five hops, and a trap waiting at almost every one of them

The design is on-behalf-of-user (OBO) authentication.

The Databricks proxy forwards the signed-in user's token in X-Forwarded-Access-Token. The API opens a SQL session with it on every request. The app's own service principal gets CAN_USE on the warehouse and nothing else.

First deploy: blank user names, empty tables.

The code was fine. The sql scope was sitting under config: in the bundle, where it's silently ignored. It belongs at the app level:

resources: apps: my_app: name: ${var.deploy_app_name} source_code_path:./ user_api_scopes: [ sql ] # app level, not under config: Enter fullscreen mode Exit fullscreen mode Declaring the scope only requests it. The workspace has to allow it and have user-token passthrough enabled, and the only real proof is the deployed app:

databricks apps get <app> # effective_user_api_scopes must include "sql" Enter fullscreen mode Exit fullscreen mode Configuring environments We promoted to sqa and saw dev data.

A committed app.yaml was overriding the bundle's per-target settings, so every environment was running against the dev catalog. We deleted it and kept every environment value in the bundle targets.

Then a bare warehouse id made every query return 404 (the driver needs /sql/1.0/warehouses/<id> ). And a catalog typo ( _qa instead of _sqa ) gave us empty screens and no error at all.

These days the app logs its effective catalog, schema and warehouse at boot. That one line catches this kind of bug in seconds.

Our first deployment pulled the code from a git branch and never started: "App process did not start within 10 minutes."

A git snapshot only has tracked files, and our build output was gitignored. So we switched to the bundle and built at start:

command: [ " sh", " -c", " npm ci && npm run build && node server/dist/index.js" ] Enter fullscreen mode Exit fullscreen mode Next one: the pipeline went green and the app didn't change.

With Asset Bundles, bundle deploy uploads the code and bundle run starts the new version. BUT our CI template only ran the second step for resource keys that matched its naming convention. Ours didn't.

databricks bundle deploy -t dev databricks bundle run <app-resource-key> -t dev Enter fullscreen mode Exit fullscreen mode The npm install had its own surprises: a corporate registry pinned in.npmrc that Databricks can't reach, an omit=optional setting that dropped native binaries, and a missing package-lock.json.

Three permissions have to line up: app CAN_USE (who can open the app), warehouse CAN_USE (who can run queries), and Unity Catalog grants on each table, including USE CATALOG and USE SCHEMA. Each one fails on its own, and different teams usually own them.

Our group check was also rejecting the right people. The workspace SCIM /Me endpoint leaves out account-level groups synced from the identity provider. Running SELECT is_account_group_member(:group) with the user's own token fixed it.

And the first request after a quiet period sometimes failed with "Failed to open new session" while the warehouse woke up (30 seconds to five minutes on a classic one). Nothing had run yet, so retrying with backoff was safe. We added retries and a small "warehouse is starting" banner, and moving to a serverless warehouse removed most of those errors.

Each of these failures was easy to fix and took hours to find.

The agents hit every single one. And they kept hitting them after we wrote the fixes down. They only stopped when a check failed on the mistake.

That changed how I see my own role. I think the most valuable work in this project was knowing where the traps were, and turning that into something the agent has to pass.

Set up four things before your agent writes its first line.

Put short rules in an AGENTS.md (or CLAUDE.md ) at the repo root, where the agent reads them first:

Turn each trap into a lint rule in a script that exits non-zero on errors: user_api_scopes under config:, git_source, an app.yaml with environment values, a missing lockfile, a pinned registry, omit=optional, a personal /Workspace/Users/... root path, secrets in plain env values, two targets sharing one workspace.

The script should also list what it can't check (secret bindings, scope passthrough, the three grants), so the agent tells you who owns each one.

Generating the app from a reviewed spec is way more reliable than asking an agent to remember forty rules.

Ours asks for the app name, the catalog, warehouse and groups per environment, and the entities and fields. Then it generates an app with OBO sessions, group checks, cold-start retries, auditable writes, a bundle with dev, sqa and prd targets, grant scripts for the data owner, and tests that pass on day one.

Check app access, then the OBO scope, the warehouse, the Unity Catalog grants, the data, and only then the UI.

Most fixes in the first four are admin actions, so the agent should pass them to the owner and leave grants alone.

After this setup, our deploys passed on the first run, and every "no data" report went through the same steps. The agents stopped asking "why won't it start?" and started asking "which admin owns this grant?"

This project touched all three parts of the path I'm on: a software app, on governed data, built with AI agents.

The agents did write most of the code. What made it work was understanding the platform underneath and writing that down in a way the agents had to follow.

I find that really encouraging. It's work I can learn, and I believe you can too.

If you're feeling that same fear about AI right now, I get it. I think there's still a lot of room for us. The job just looks a bit different.

Huge thanks to the team I built this with - you know who you are:)

Let me know in the comments: what are you learning next? Or which Databricks trap got you the worst?

PS: everything from this article lives in bricksmith, the skill I built so my agents stop re-learning these traps. If it saves you a deploy or two, a ⭐ helps a lot:) github.com/dcoferraz/bricksmith