# Safe AI-Driven Development with Lakebase Branches

## Метаданные

- **Канал:** Databricks
- **YouTube:** https://www.youtube.com/watch?v=jLX5LBzEDGc
- **Дата:** 02.06.2026
- **Длительность:** 6:45
- **Просмотры:** 795
- **Источник:** https://ekstraktznaniy.ru/video/52955

## Описание

In this video, we show you how to safely leverage AI in your real-world workflows using Lakebase Branching. By creating flexible, ephemeral, and isolated data environments, you can empower AI coding agents to experiment and iterate faster without any risk to your live production data. We’ll show you exactly how to set up an agentic branching workflow using the Databricks CLI and AGENTS.md configuration. 

Learn more about Databricks Lakebase here: https://www.databricks.com/product/lakebase

## Транскрипт

### Segment 1 (00:00 - 05:00) []

Agentic coding has allowed us to move faster than ever before, but if you're still using a more traditional database setup, your database can be a serious bottleneck both in terms of speed and safety. So, today I'm going to show you how database branches with Lake Base can help remove these common bottlenecks. Database branching is exactly what it sounds like. It's the idea of branching your database the same way you branch your code. And with Lake Base, a branch captures both your schema and your data. One of the most powerful aspects of Lake Base branches is that they're created instantly. And this is regardless of database size, meaning it takes the same amount of time to branch 1 GB of data as it does 1 TB of data. The reason for this is that Lake Base branches use a technique called copy-on-write. What this means is that when you create a new branch, your data isn't actually copied over. Instead, the child branch just points to the original data in the parent branch. Data is only written to the new branch when you actually change something like inserting new rows, modifying existing data, or updating the schema. All unmodified data continues to be read from the original parent branch. That way the child branch doesn't have to store an extra copy of the data. And this technique allows Lake Base branches to be both really fast and cost-efficient, which means branches can be treated as temporary environments. So, when you want to build a new feature, you can create a new branch and test your feature without affecting production data. Then, if you like your changes, you can migrate them over to production and throw away the branch when you're done with it. So, now that we know how branches work, let's take a look at how you can actually create a new branch in the Lake Base console. So, here I've got a project for a to-do list app. You can see down here I've got a to-dos table with some to-dos inserted here. Now, to create a new branch, I'm going to head over to the branches tab and click on new branch. From here, I can give it a name. I'll just call this one example. And the first thing we can do is set how long we want the branch to last. I'll leave this at just one day. Then down here, we have an option for the data that we want to include in this branch. This data is going to be coming from the production branch, our parent branch. We can set it to be the current data in the production branch or past data from a specific point in time. I'll just keep this as current data for now. And then over here, I can click create. And when I do this, Lake Base is going to give me all of the options for connecting to my database. So, here I've got a connection string, but I can also connect with the parameters, however is best fit for your app. I'll close this out here, and now if I head on over to the tables in this branch, you'll see I have the to-do's table with all of the to-do's data. But, if I come over here and I delete one of these records, this will be gone for the example branch, but now when I come back to the production branch, you can see that data is still here. So, I can do anything that I want in our example branch, and all of my production data is going to be unaffected. Now, you can also manage your branches with the Databricks CLI. The CLI allows you to programmatically interact with your Databricks workspaces. And for all commands related to Lake Base, we're going to use the Databricks Postgres command. So, to list our branches, we can use the command list branches and then specify the name of our project. And here, we can see our two branches. If you want to create a new branch, you can use the command create branch, again specify the project, and then indicate the name of the new branch. You'll also need to pass some JSON here to indicate the source branch. That's the branch that you want to copy from. And the TTL or time to live, which tells Lake Base when to automatically delete the branch. In this case, it'll clean itself up after 7 days. And finally, if I want to delete a branch, I can just say delete branch and provide the path of the branch I want to delete. Now, because we can manage our branches using the CLI, that also means that an agent can manage our branches. So, now I'm going to show you how I set up a project to create an agentic branching workflow. The first thing we'll need to do is install the Databricks agent skills. Skills give your agent the context it needs to work with Databricks most effectively. To install the skill, run Databricks AI tools install. And when you do that, you should see your skills added to your project, and specifically, you'll see the Lakebase skill. Once we have the skill installed, the next thing we'll want to do is edit our agents. md file. If you haven't worked with this before, this is essentially a file to give your agent more context about your project. And we're going to use this to define a development workflow for our agent to follow. So, here, the first thing I'm going to do is tell my agent that when we're using the Databricks Postgres CLI, we always want to use the project called example project. After that, we're going to define our core development workflow when using Lakebase branches. The idea

### Segment 2 (05:00 - 06:00) [5:00]

being that we want our agent to follow this workflow every time it works on a new feature. Our first step is to create a new Git branch, which is pretty standard. But, on top of that, we're also going to create a new Lakebase branch for this feature as well. And just to be explicit, we're going to specify which project we're working on again. We're also going to make the Lakebase branch short-lived and give it a TTL of 7 days, unless I directly ask for something else. Now, to use the new branch we just created, we'll update our local environment variables so the app connects to the new branch instead of production. And if we're using OAuth, we'll have the agent refresh our token. At this point now, our agent would go ahead and actually make the code changes to implement the feature. Then, we you go ahead and apply the schema changes, and just to be safe, we want to make sure that we're only applying those changes to the Lake base feature branch and never the production branch. With this in place, now when you prompt your agent to build a new feature, it'll follow this workflow and build your feature in an isolated environment. And when your agent is done building out the feature, you can actually see the schema changes in the Lake base console. If you go over to your branch and click more and then compare to parent. And here you'll be able to see the diff between the production branch and your feature branch. So you can know exactly how your migration is going to affect production. From here, you can migrate these changes to your production branch via your CICD pipeline. And in terms of cleaning up the feature branch, you'll remember that we set our branch to expire in 7 days. So after a week, this branch will clean itself up. As you can see, branching is the missing piece that can bring your database into the modern development era. So if you're ready to give branching a try, you can check it out at databricks. com.