How to Vibe Code Successfully: Make Your Agents Love Databricks

Summary

Agent Experience (AX) is a new engineering discipline focused on giving coding agents the platform context they need to work effectively — analogous to Developer Experience (DX) — and is essential for building production Databricks Apps and AI agents without hitting capability ceilings.
The approach combines an agent.md context file for platform-specific quirks, AppKit templates from developers.databricks.com, and Databricks MCP tools to equip agents with maximum knowledge about the platform's APIs, patterns, and configuration requirements.
Choosing the right agent harness — Claude Code, Codex, or others — and using TDD skills plus iterative style refinement enables developers to build complex agentic systems on the Databricks Data and AI platform with consistent, repeatable results.

How to Vibe Code Successfully: Make Your Agents Love Databricks

To get the most out of your coding agents, you need to set them up for success, especially when letting them loose against a large platform like Databricks. In this talk, we will dive deep into Agent Experience (AX) for building Databricks Apps and Agent. We will discuss AX as a new discipline similar to Developer Experience (DX) and review the most effective tools and best practices for successfully steering agents. We'll discuss how to set up your local development environment for building on Databricks. From agent skills and MCP to reference codebases and AppKit, we will see how these components compose together. By the end, your agents will know Databricks inside and out, allowing you to vibe code more successfully on top of the Databricks platform.
Talk By: Andre Landgraf, Staff Developer Advocate, Databricks ;

Chapters

FAQs

What is Agent Experience (AX) and why does it matter for Databricks development?

Agent Experience (AX) is a discipline focused on equipping coding agents with the right context, tools, and platform knowledge to work effectively — similar to how Developer Experience (DX) helps human engineers be productive. For Databricks development, AX matters because AI coding agents lack platform-specific knowledge about Databricks Apps, APIs, and configuration quirks they need to avoid failing on complex tasks.

What is agent.md and how should developers use it?

Agent.md is a context file that provides platform-specific knowledge, quirks, and constraints to coding agents at the start of each session. As explained in this video, developers should write observed platform behaviors and common failure modes into agent.md so agents carry that knowledge into future runs rather than needing to rediscover the same issues repeatedly.

What is AppKit and where can Databricks developers find it?

AppKit is a collection of Databricks application templates available at developers.databricks.com that give coding agents working reference code and starting points for Databricks Apps. This video demonstrates using AppKit templates as a way to provide maximum context about the expected structure, patterns, and dependencies for production applications on the Databricks Data and AI platform.

When should developers choose Claude Code versus Codex for building on Databricks?

This video discusses both Claude Code and Codex as valid agent harnesses for building on Databricks, with the key decision factor being the system complexity of the task rather than a universal preference for one tool. As complexity grows, what matters most is the quality of context provided through agent.md, AppKit, and MCP tools — not which harness is used.

Full transcript

[00:08] Hey everybody. This is the first silent disco that I'm ever like running. So, this is fun. My name is Andre and I'm a developer advocate here at Databricks. And in the next 20 minutes we're going to talk about vibe coding and maybe how vibe coding is kind of turning into more like
[00:21] you know, steering an agent and becoming a little bit more of a engineering industry. And what I want to do is just share my vibe coding secrets with you and how I think you can be successful vibe coding Databricks apps and building operational
[00:34] systems on the Databricks platform. So, first off, you're all in San Francisco right now. It's working?
[00:48] Working? Confused? Yes. All right. Sounds good. This We're in San Francisco right now and you can just literally say this to your computer with our tool like WhisperFlow. You can dictate it in and you will get a working application
[01:00] out on the other side, which is still mind-blowing to me. Like the the fact that we live through this time and that we can be part of this revolution is super exciting to me that we're all here together in San Francisco Data and AI Summit and it's it's happening right
[01:12] now. I always thought I was too young for mobile, too young for early cloud, too young for the early days of the internet and my whole career would just be building React applications and like
[01:24] fighting Python versus JavaScript and now we're here. It's just such a cool time. But, obviously the tools still have their boundaries. If you want to build something more complicated, let's say like an agentic internal support
[01:36] console, you will hit you will hit some ceilings, right? Um and that's where steering agents comes in, right? If you just put in a prompt and hope for the best, at some at some point the agent will struggle and that's where you have to
[01:49] learn how to steer them successfully, right? And that is both you uh learning the competence of or like getting better at understanding the agents, what they need, how you have to prompt them, but also it's about like providing them with
[02:01] the right tools and context. And that's what I want to talk about in this in this little 20-minute talk. So, it's all about system complexity. The more complicated the system, the more complicated what you want to build,
[02:13] the harder it gets for the agent, and the more you have to support them. And system complexity is kind of derived out of two things, right? It's like what do you want to build and how are you going to build it? What's the platform that you're using?
[02:25] And you're all building really cool things. I just talked to someone who works at Paramount, and earlier there was someone from Rivian here, right? Like you're building incredibly thing incredible things. And for those things, you are the domain expert, right? It's
[02:37] your knowledge, your expertise that you have to kind of bring to the agent. And you do that by, you know, taking your time, writing good prompts, by writing documentation and context that the agent can read, by writing them as much access
[02:50] to its environment as possible. Um but then there's also the platform. And since you're all here, I assume to some extent you're building on the Databricks platform. And maybe like show of hand,
[03:03] who of you has built a Databricks app already? Uh so that's like 20%. Okay. So, if you want to be successful building on a platform, you have to understand the platform a little bit, right? Like the
[03:15] terminology, what are the high-level concepts. Otherwise, you will have a hard time like just telling that to the agent, right? Like I want to build a Databricks app. If you don't know what a Databricks app is, your agent will have a hard time figuring that out, too. Um
[03:28] but uh uh on the other hand, it's also on the platform to set you up for success, right? Um and that's what I think about a lot in my day-to-day. It's called agent experience. It's the experience an
[03:40] agent has interacting with a system. So, as a developer advocate at Databricks, I play around with agents. I figure out why they're failing operating on Databricks with the Databricks CLI and our Databricks agent skills, and why
[03:53] they're failing and what can't they figure out and try to just make it as easy as possible for agents to interact with the Databricks platform. So, it's it's not just you guys, it's also us and we have to work together and steer the agents together.
[04:05] So, let's talk about understanding the platform. If you want to write code on Databricks, you can obviously write code a notebook with Genie or you can write code a pipeline, but most of the time if you're
[04:18] building something it's an operational system, right? You're building an agent, you're building an application and there's three main components that are important. The first one is Databricks apps, the Databricks apps platform. We deploy
[04:31] applications. That's like a a Python server, a Node.js server and then there's Lakehouse Postgres, which is the application that the So, that's the database that the application is querying because in an application you
[04:43] usually don't query a Lakehouse directly. You have something like an operational database in between and I know you've probably heard way too much about Lakehouse already in the last few days. And then the last component is Agent Bricks. And Agent Bricks is just a
[04:55] term we use for anything that is for building agents and making applications agentic. So, that's our AI gateway, it's our model serving endpoints and we just All of that we put into the Agent Bricks
[05:07] bucket. Um because most of the time in 2026 you maybe you want to build an application, but very likely you want to build an agentic application that has some kind of chat functionality or you're able to interact with some agents and that's
[05:20] when you would need all three of those components. All right. So, how do I or the DevRel team or we at Databricks try to make it easier to work with Lakehouse, Databricks apps and Agent Bricks? Uh there's three exciting things I have to
[05:32] share here today. The first one is AppKit. And AppKit is a brand new SDK uh that our engineering our apps engineering team has released. Uh it's built on TypeScript, built on Node.js.
[05:44] It comes with a React front end. It's built with Shaka and Tailwind. So, it's really set up um based like on open open standards that agents are already good very good in. So, like agents love Shaka and
[05:56] agents love Tailwind. So, we're building on top of those standards and just like wrapping them in a nice little SDK that comes with plugins for Lake Base and comes with plugins for Genie and and just makes developing Databricks apps a tiny bit easier.
[06:10] Um then all the way on the right side we have our Databricks agent skills and those are marked down files that we are maintaining that explaining to agents how to use the Databricks CLI to communicate with the Databricks workspace, how to use
[06:23] App Kid successfully, what templates are around, what a dev workflow with App Kid and the Databricks platform looks like. And then finally and that's what I'm most excited about what I will show you in a second is Dev Up. So, if you turn
[06:35] around there's a Dev Up space just behind you and there on the side is the booth and right after this talk I will be right there. So, if you have any questions you can you can find me there. So, we just released
[06:48] developers.databricks.com which is the new hub for builders and developers on Databricks that has all the documentation and resources around App Kid, our agent skills, how to get started and a lot of really good prompts
[07:00] and templates to get started building applications. So, Okay, so we have a a rough understanding of the platform that is Databricks. You all are the masters of your own use cases and what you want to build. You have all that domain
[07:12] expertise, but you also have to understand how agents work, right? So, if you want to steer People always say if you want to manage something, right? Like you can't manage something that you don't understand. So, you have to understand the agents kind of how they flow in order to steer them
[07:24] successfully. Luckily, it isn't that hard. There's just a few standards that you can kind of learn and grasp very easily and the rest is just practice practice practice, right?
[07:36] I would say models or harnesses are like instruments. They're all a little bit different, but in the end of the day you play music with all of them, so you just have to like play the guitar for a little bit and try it out. And maybe you like the bongos more, but in the end of the day, right? Like each harness, each
[07:49] model has their quirks, but in the end of the day, they all serve you to do the same thing. And they all luckily follow the same standards, more or less. There's the agent.md file. That's like the readme or
[08:01] contributing.md file of your repository. You write all your agent rules in there. They're the primary rules of your code base. And anytime an agent does something you don't like, write it into the agent.md. It's like, "Do not do this again. That pissed me off, right?" And
[08:14] that's something you share with all your colleagues, and you can all contribute together. Then you have agent skills. There's this great website called skills.sh, where you can find like hundreds of thousands of agent skills. And there's a bunch of
[08:27] Databricks agent skills now as well that we're maintaining. And those are like secondary workflows and best practices for agents that the agent is aware of. And whenever the agent thinks now it's a good time to like apply that workflow or
[08:39] read through that agent skill, they can also take access there. So, how to work with a Databricks app would be an agent skill. But you can also totally build your own skills. So, if you love test-driven development,
[08:51] maybe you write yourself a TDD skill. And then your in your agent.md file, you write, "Every time you do feature development, read the TDD test-driven development skill and follow it for our development."
[09:04] So, that's static context. The other thing is tools. And I would say tools is even more important because tools influences how your agent can actually autonomously interact with the environment. So, if you don't give your
[09:16] agents any tools, the agent will be able to write some code, but will not really be able to verify that it works or format it or just like, you know, interact with it any other way. So, if you don't want to be the manual tester
[09:28] that always like tells the agent what it's still not working. It's still not working. It's still not working. If you want to skip that, you have to provide them as much tools and access to the platforms that you're operating on. So, the best
[09:40] example is the Databricks CLI. If you have the Databricks CLI installed on your machine and authenticated, and you and your agent sort of D file, you tell the agent that it has access to the Databricks CLI, that means the agent will now be able to query what's already
[09:54] in your workspace, the shape of your data, what lake based databases you already have available, what are the app logs, why is the deployment failing, right? So, the the agent is able to unblock itself, query additional context, and that's really really really
[10:07] important. I usually tell my agent to not stop until it verified that everything works in production, right? And that goes all the way to going into the browser I didn't do anything. I goes into the
[10:19] browser with a tool called agent browser, go through every flow, test it out itself, and then only after it verified that everything works, tells me it's done, right? I don't want to be the tester for my agent. My agent has to
[10:31] test for itself, and then I just go in afterwards. Okay. So, by coding one on one, get a high level understanding of the platform, install the tools that the platform provides to you, right? The agent skills
[10:43] that we just talked about, the the CLI, the command line interface, maybe MCP servers, then start with a starting point. Never start from scratch. This just gives the agents way more options to mess things up, right? If you have a good starting
[10:55] point that already creates a good abstraction that the agent can build on top of, and then finally, practice, practice, practice, which means you just iterate, you develop, and anytime you run into an issue, you you do what your developers and builders
[11:08] already do, right? You debug it, you freak out why it didn't work. You do that together with your agent. You tell your agent, "Ah, I didn't like what you did there. Can you update the agent sort of D file for us, and next time you know not to do it this way, or can you
[11:20] remember this, write it in an agent skills for next time when we run into this issue, you don't make the same mistake twice?" And just like that, your agent loop will become more performant and more efficient over time. All right.
[11:32] A lot of talking, Let's do a quick time check. Fantastic. We're good in time. Let's jump into a little demo. So, as I mentioned, we just launched developers.databrics.com. And mind I say, I think it looks really awesome.
[11:44] And it has a few things that I'm very excited about. The first one is it just has good old documentation. So, this is mostly for you, right? You kind of have to understand how the platform works, what are the high-level moving pieces,
[11:57] what's a Databricks app, what's lakehouse, the terminology, right? So, this is very, very high-level docs. They're very simple to read. You can probably take them to the toilet in a 20-minute session, get done with them,
[12:09] and just get a good understanding about all the pieces you need as a developer building on Databricks. Um once you have done that, um or in parallel, you'll go to templates. So, we built a bunch of cool templates that are great
[12:22] starting points for you and your agents, and it shows kind of the capabilities that Databricks apps have. Uh what's an AI chat app that you can build, an app that like saves some data in lakehouse, and so on and so forth.
[12:34] And then the coolest thing here is if you click on one of those templates, there's no GitHub link. We're not sharing any repositories with you. Just an agent prompt. And if you don't know what to build at all, just go to landing page
[12:48] and copy the top-level agent prompt. Is it kind of mind-blowing, right? Like in the past I would have shared some GitHub repositories with you like, "Hey, yeah, I I built an example. Like have fun like trying to translate that into whatever you're building."
[13:00] But we live in the future. So, I'm just copying the prompt, and then I go to my favorite coding agent, which obviously today has to be Omni Omni agent, but you can do this in Cursor, Cloud Code, Codex. Um you start a new session, you
[13:13] paste in the prompt, you hit enter, and everything we talked about today is part isn't already in this prompt, and the agent will do it together with you. So, um
[13:25] I don't think we have time to wait on the agent. Uh so I'm going to go to an existing run run that actually didn't go super well, so which I think is also really interesting. I just go over uh
[13:37] over the prompt and how the agent what the agent did afterwards. So, it's a very long prompt, but that's on purpose, right? Like we Databricks try to help you steal your agent. We try to give you as much give the agent as
[13:49] much context as possible. So, we tell the agent about the website that you just copied the prompt from. How it can work with that website and get additional context if it needs it to. Uh in general how we think it should
[14:01] build applications. How it should talk to you and engage in a conversation so you both explore and figure out together what to build. Uh how to ask questions in different tools.
[14:13] How to like workflow and work together on an application. Make it look great. Right? The first thing the agent gives you, it should already look nice. If it looks ugly, it didn't do a good job. And then run and deploy the app and really
[14:25] do everything end-to-end. Um and you can see it goes on and on and on. And then the great thing here is that the action the agent actually comes and just ask
[14:37] you questions. Like, what app do you want to build today? I have some options for you or you just tell me whatever you want to build. And then you engage in a conversation, right? Like you get a high-level understanding um of what you want to build. You bring in your domain
[14:49] expertise, right? You know best what to build, right? Not us. Um and you can see here it's doing all the things that I I told you is are needed, right? Like it's setting up, making sure the Databricks CLI is installed. It makes sure the Databricks agent skills
[15:02] are installed and up to date. It and then based on what you told it to build, it will pick one of the templates that we have and use that as a starting point. It will build with App Kit the SDK that I told you to, and it's
[15:14] really all bundled already in here. But the fun thing is if you want to explore this and do this step-by-step if you go back to the docs, you start here, set up your environment. All the
[15:26] steps that the agent guides you through are also in the docs. So, if you want to understand better what's happening behind the scenes, you can totally also do it from here. Awesome. So, we go down and it asked me what
[15:38] folder I want it built the app in. It tells me, "Well, you want So, what I wanted it to build is an internal tool to manage internal tools because I'm building too many internal tools with my coding, so I
[15:50] need to kind of start keeping track of them. So, I wanted to build it myself, an internal tool to track internal tools. Um and it says like, "Okay, sounds cool, bro. Uh let's create a Lakehouse database to track all of that data." It asked me if I already have a
[16:03] Lakehouse instance. And then it says, "Okay, let's let's start building. I'm going to build you the front end." You can see here it's using TypeScript and React for that. And you can see it's asking a bunch of step uh there's bunch of steps here. It goes back and forth.
[16:16] And then I finally had the the app running locally and I could try it out and get like a feeling for it. And that's where steering comes in, right? The agent will never be 100% doing what you want it to do unless you give it
[16:28] like a really precise prompt in the beginning. So, this is already like a good point where you could just like stop the agent and like interrupt it and say like, "Um fam, I don't like what you did here. Can we go in this direction instead? Don't
[16:40] make it Databricks red. I saw too much red last last week at Data and AI Summit. Like, let's make it green, please, right?" So, always just interrupt the agent and it's really good in 2026 now like to take your feedback
[16:52] into account and then just continue. And then you can see here it did something silly that I haven't seen before. Uh which is interesting. So, this is a run that didn't go 100% well because it ran
[17:04] the application locally, which is good, but then it said, "If you want to run If you want to deploy the app to Databricks, you have to run this command." And I don't want to do that. I I the agent to do that, right? So, like I was
[17:16] annoyed. So, as a DevRel employee, as a Databricks employee, I will go back to our agent skills and make sure it goes better next time and we run like nightly eval's on our prompts to make sure this doesn't happen again. But, as a user, if
[17:28] you see any quirks in our platform, you can just write that in your agent.md file. Always deploy the application to this workspace in this app and like just copy the app name in there and just steer the agent, right?
[17:41] And then it did some weird stuff here where it tried it and you can see here the first time I tried it was the agent didn't actually work. So, it was just it it told me like an error when I opened the app and I was like, "Bro, you're supposed to fix this and don't tell me."
[17:53] So, I was annoyed and just told it to check the app logs. So, what does that mean checking the app logs? And that's like that's the power of the Databricks CLI. I work mostly on Lakehouse. Um and I think the last time I've
[18:05] actually gone into the Lakehouse console to like do something there was like 2 months ago. Because all I do is tell agents to use the Databricks CLI and do it for me. Like that's how powerful the Databricks
[18:18] CLI is. You can literally do anything that you can do in the UI with the CLI. So, an application, if it fails, it gives you usually logs. It show it shows you an error stack trace why it failed. In the past, I would have gone to the
[18:30] app like the Databricks app UI right we have here our workspace. We can go to Databricks apps.
[18:42] We can find the app that we built right like our internal tool management. And then here you see logs. And uh we could look in here earlier and and find the error. But, I don't want to do that anymore. I want my agent to do this, right? And so, we take a lot of
[18:55] effort to put everything that you can do in the UI in our CLI. So, you and then in our agent skills it's documented for the agent how to do it. So, as long as you know the agent can do it and has that uh capacity, you can just tell the agent to
[19:08] try it out, right? Just look at the app logs and fix it. And I may actually just write in my agent file every time we deploy an application, I want you to use this tool called agent browser.
[19:22] It's a fantastic tool. It's by Vercel. It's documented in our agent skills. So this should already like the agent should already prompt you to use this. But it's basically a great headless
[19:34] browser for agents to interact with your websites. So it I would tell my agent to use agent browser, try to look at the website. If it looks broken, look at the logs and fix it. And only tell me you're done
[19:46] until you confirm that all the new flows that we together said we want to implement are actually working end to end, right? Um So that to me is successful live coding. And that is the end of my talk.
[19:59] Thank you so much for listening and for your time. I hope you're building many many data applications. And if you have any questions again, you can find me just over there.

Learn more about the Databricks Data and AI platform.

The information provided herein is for general informational purposes only and may not reflect the most current product capabilities or configurations.