From Prompt to Production: How to use AI Code Assistants for Python Data Systems

Speaker 1 [00:06]

and welcome to the session. Today's tutorial, from prompt to production, how to use AI code assistant for Python data systems, explores a topic that's rapidly reshaping how we build software, the collaboration between engineers and AI. And our speaker, Sergey Sokolenko, brings deep experience from companies like Databricks, Snowflake, and Google, and now is co-founder of Tower, a platform focused on Python data flows and agents. Whether you're already using AI tools or just starting to explore them, this session will give you concrete production-ready insights. Yeah, please join me in welcoming Sergey Sokolenko.

Speaker 2 [00:59]

Hello everyone. I'm one of the co-founders of Tower. This is not a session about Tower, this is a session about what happened after November 2025. A show of hands, who knows what happened in November 2025? Remember that day? Okay, I see a few hands raising. Of course, Opus 4.5 came out, and since that day, the life of data engineers have changed dramatically because before November, LLMs were crap, and after November, suddenly we were able to build pretty sophisticated data pipelines. So today's session is about, not about how awesome Cloud Code is. It's pretty awesome, and we have concerns, but it's still pretty awesome. This session is about what else do we need as a profession, as data engineers, people who need to process data, who need to provide good quality data to their end users. else do we need in addition to cloud code to write good software? I'm going to do a little bit of a switcheroo. I'll apologize for this. The majority of the content of this session was developed by Simon Rosenberger, who I, at this point, would like to invite to the stage. Simon is one of my friends and early employees of Tower. Actually, if you look at some of our product environments documents in Tower, you'll see Simon's name mentioned because he was the original user of Tower. He basically was the reason why we started the startup. By the way, for those of you who don't know what Tower is, we are a startup in the Berlin area, hiring, building a platform as a service for Pythonic data apps. So I would like at this point, maybe start transitioning the mic to Simon. He is going to lead you through three parts. He's going to explain what these three parts are. It's going to be a demo portion of the session and a hands-on version of this tutorial. My co-founder, Brad, is in the back of the room. I am also going to stay in the room and help all of you. So the three of us, Simon on stage, me in the room, Brad in the room, we'll all be helping you with the hands-on portion of this tutorial. At this point, Simon, why don't you take away and tell us more how to get from prompt to production.

Speaker 3 [03:50]

Thank you for the kind introduction. As people are still coming in, yeah, I think there's still plenty of space over there. Yeah. We're going to talk about code agents in data engineering today. And really my goal for this session for the next 99 minutes, 90 minutes, is for all of you to walk out here and have the feeling you've got some more tools at your fingertips to be more effective using AI coding agents. We're going to divide the section into three parts. For one, this is going to be very short, we're going to dive into some of the underlying concepts that we'll be working with today, then I'll spend some time walking through a specific example of how to apply these. And then the third part of the session, which is like the last 45 minutes, is actually meant for you to apply these skills and the techniques to a specific problem. So I hope you brought your laptop. We do have all the tools ready for you, so don't worry. And let's dive straight in. Before we get going with the content, I want to get a quick show of hands. Who of you is in the data engineering space or considers themselves a data engineer? That is about half of it, a bit more probably. Who of you sympathises very well with this image and the experience that is depicted in this image? That is definitely even more than the data engineers in the room. This is a clear problem, right? AI coding agents are super powerful. They allow us to get from zero to one in no time. It all looks fancy and bright, but at the end of the day, we still find ourselves spending almost as much time as we've always did until we arrive here at the right at something that really works. And today, we'll hopefully learn how to change that. How can we move from prompt to something that is actually resilient, reliable, and production-ready? With a few tweaks. Serhii already covered this part. I'm a forward-deployed engineer at Tower. I used to be a data engineer before that. And Tower itself is something that we're quickly going to look into now. I'm briefly going to give you a demo of the platform, not to advertise it, but to give you a sense of why it makes sense to use Tower in conjunction with coding agents. So let's jump over here. This is the platform. You will create an account, a free account, later to participate in the actual coding part. we have here? Tower is a platform to run Pythonic data apps, so we have apps in here, they run, some of them errored, some of them were successful, looks a bit like GitHub Actions if you've used that, but it is much more than that. We have built-in storage, so you can run your your Python data pipelines, data transformations, dashboards, and query data from a storage repository directly adjacent to your runtime. We have different environments, we have secrets built in, and the beauty of that is, we will see that later. All of these apps run locally just as if they run on tower in the cloud because it's all bundled into the same runtime. Like the secrets vault, the log streaming observability, it's all bundled together. So it's literally a one-line CLI command to deploy what's just been running on your machine into the cloud. Obviously, it comes with a CLI that agents understand really well. So that works. That was the platform intro. Before we get into how we actually work with it, some conceptual background. So coding agents make us faster, but how can they make us better? How can we transform Claude and all the worktrees from a team of workhorses to a team of experts that doesn't make us faster, but that gets us to the moon, literally. So the cool thing is, we do have the plumbing that we need already in place. We have code generation from the LLM. We have memory and context from the agent memory. The agent can take actions on our operating system using tools. And we can even give specific instructions to the agent using skills. So what's missing on this is this is all very linear, right? We can chain those tools and those skills together to get from A to B. But the reality isn't as linear. We run into issues that we didn't expect. We have to take different turns in our development workflow. And all of this is not really built for that. And it's also kind of like very, it captures our own perspectives on how we're going to solve things. so there's two tweaks to look at the problem from a slightly different angle so what if we were to give our agents different personalities for example if we're in in data engineering i mean in reality you would involve an opinion from a data architect a business analysts to make sure that whatever pipelines, dashboards, et cetera, you're building are actually meeting requirements, security requirements, business requirements, et cetera. So that's something that we're going to weave into our agent setup. And the second piece is what people usually experience is if you work with coding agents on a blank slate, It works incredibly well. If you onboard a coding agent onto an existing code base, problems start to occur. Because your coding agent usually doesn't have the notion of a state. Like, which state is your code base currently in? And also, it doesn't really question your intention. Like, are you here to just, like, write a hotfix? Are you here to add a new feature? Are you here to refactor stuff? But all of this should factor in how the ensuing development workflow evolves, right? If you just want to build a hotfix, there's no need to do extensive planning. Chances are that you exactly know what you want to do. But if you want to build a new feature, you probably want to involve more of those additional perspectives from a platform engineer, from an architect, etc. There was a lot of talking on those abstract concepts, so I would say without further ado, let's actually dive in. There is this website, so if you go to tower.dev slash blog, which all of you should do now, there is a blog post that is not a blog post, but that just shows these two links to the repo that we are going to be using and to the Discord channel. So the Discord channel is over here. So join that, there you will find all the links that you will need later. And while you do that, I will get going with the actual demonstration. And for that, jump over to this repo. So what are we going to do together? This is a repo. There is a very simple data pipeline in there already. And what it does is it fetches all issues from Anthropix, Cloud, Code, public repo. So we want to do two things with that. First, we want to get this existing pipeline running, and then we want to build, like, a small data application on top that notifies us whenever a new bug ticket is filed. It's a toy example of what could work really well inside an organisation where you say, like I always want to stay on top of bug tickets to keep my customers happy. We're going to use this public repo because it's easier to access for everyone. Exactly. So what I'm going to do now is I'm going to clone this repo, and then run the pipeline without giving all these skills, tools, and hooks to my coding agent. We'll see how that evolves, and then we'll switch gears with all the additional tooling. And by the way, after this demo session right now, We also have a quick Q&A where you can ask questions about what we are doing here, also about Tower in general. We just wanted to make it more condensed for people to ask questions. All right. There we go. I'm going to zoom in a little bit. Okay. Whoops. I'm going to open a new terminal. Oops. Cool. So as I said, what we have in here is, I hope you can all see that. We have a single data pipeline, in this case it's a DLT pipeline that loads issues from Cloud Code repo into DuckDB. So I'm going to launch Claude, and there we go. And tell it to run the pipeline and see how it behaves. So this is now, like, a plain, like, if you just signed up for Claude, launch this on your IDE, no skills, no MCP servers whatsoever, and essentially start with a plain, stupid agent. What you see is what happens, so it had no idea what is actually in this repo, so it started exploring, it found a pipeline, it wants to run it, it fails. Why does it fail? Because it has no clue how this entire environment is actually managed. In this case, we're using UV for dependency management, so there is no global Python to run it with. And now it's starting to think, how can I fix this, and so on. The next problem we're probably going to run into is that there are no secrets configured. There is no safe way for the agent to configure secrets. And then, once we finally got the pipeline to run, we're going to struggle to actually get it deployed somewhere where we can run it on a schedule. Luckily, there is a solution to all of these problems. So let's switch gears. I'm going to go to the main branch. And the main branch comes with, that's why I want to spend a little bit of time on, quite a bunch of skills and other markdown files. Quick show of hands, who knows what skills are in the context of coding agents and LLMs in general? Okay. Yeah, we are all talking the same language here, this is good. So, when I first started using skills, I treated them as recipes for completing workflows. And there are still some of those recipe-like skills in here. For example, a recipe to debug a data pipeline, a recipe to initialize a tower app. But there is also other skills in here that are less recipe-like, they are more persona-like. For example, like a business analyst that does a review of my plan of building the pipeline, or a data engineer review that has a much more thorough understanding of data engineering best practices. So we'll see how those are gonna be useful. The second piece that we talked about earlier, and this is the really interesting one, is this workflow skill, which is no longer this linear workflow, but it is what I call a fuzzy state machine. It identifies your intent. What do you want to do if you prompt this? Do you want to build a feature? Do you want to deploy a hotfix? Do you want to just investigate some data? Do you want to refactor? It combines that with the state in which your repository is at the moment. Does it already have an app? Does it have nothing at all? Does it have some code, but it's not bundled yet as, in this case, a tower app? Depending on where you are at the moment, it sends you down a calibrated workflow. Without further ado, let us see how running the pipeline behaves with this more tailored tooling. It is checking the project state to understand where we are at. And as per this fuzzy state machine, it's seen, okay, there is some pipeline code in there, but it's not readily bundled into a tower app, so I'm going to do that first. It's using the skill, like, initialize a tower app, while that's going. It will realize that the tower MCP server is not running yet in the background. So, we have to start it. There you go. So, tower MCP server was not running. It uses the tower MCP server to, for example, validate the configuration. Interestingly, it saw that there was a little bug in our config file. We'll take a look at that in a second. So now it's running. And this is now an interesting step, because what did it do? So it tried to run the app, which is the pipeline, locally, and there was what looks like a failure. And we are using hooks in here that essentially hook into those individual tool and skill calls and compare it with the local state. In this case, it saw there hadn't been a historic run of the pipeline before, so it notified the agent that, hey, we might want to add some debugging utilities if we run this for the first time. And how is this useful? I don't know about you, but when I get to these existing pipelines that I'm supposed to extend or fix, I usually start by just looking at a sample of the data without running the whole thing, because it is going to take forever, and chances are that things are going to break anyways. So adding a bit of limits and more verbose logging is always a good idea. And that is exactly what happens here. So let's go ahead. So it is using another skill here, the debug pipeline skill, which is essentially just telling it to, hey, make the logging more verbose and pull less data so that it gets faster. Let's see what happens. All right. We have gotten a little further. Still not looking great, but we're getting there. There was a rate limit error, which is an interesting one. Let's see what Claude is going to do with it. It has correctly identified what the issue is, because GitHub API is rate limited unless you use a token. Any token would suffice here, because it is a public repo at the end of the day. One of the advantages of Tower is we have a secrets vault built into the runtime. That means in the UI, like this here, we can create secrets, like Claude has already created one for us with a placeholder value. So we can now go here, pick our secret from one password, put it in here, update, and those secrets will be available both on the local runtime on our machine, and also later when we deploy this to the cloud. So it's telling us, hey, go to tower, replace the token with the actual token value, which we did. So ready to go. Running again. This time we shouldn't run into timeouts anymore. Looks like we still did. Let's run it again. App completed successfully. That's good. So we were actually able to complete the first part of our mission here, which is to run the pipeline. But that was not the eventual goal, right? We wanted to get alerted when people file new bug tickets. So that's the next step. It's suggesting to remove the debug utilities again. So let's wrap that up. Yes. Okay. So I'll clean. done and so now it's asking us what we actually want to do and what we want to do is next I would like to build an alerting system that writes issues to Iceberg and tells me whenever a new bug ticket was filed via Discord. Let's use Discord because it's super easy to integrate with webhooks. Let's see what it does. Like last time when we prompted it, it was just like okay like we don't need to do extensive planning, we just want to run the pipeline. It was a very different intent from what we're doing right now. Let's see. Yeah. So this is a feature request. So we're on our fuzzy state transition matrix at a very different place. So what it's going to do now, it's going to make a plan, like a mini plan. And then it's going to use those two persona skills, like the business analyst and the data architect, to make sure what we're planning here is actually sane and I found this to be quite helpful because I used to invest a lot of time in like refining product requirements documents and then throwing them over to the agent until I tried using those like very specific personas to give feedback on very specific sub-aspects of these plans, makes them a lot more robust and also makes me think about things that I wouldn't have otherwise considered. Okay, it's come up with a plan. We're going to use Iceberg as a destination and we're going to add an alert hook from Discord. So, we're still waiting for the second agent to complete. While it's doing that, we can already head over to Discord and create a webhook. Integrations. webhooks, new webhook. Copy webhook URL. There you go. Okay. So based on the feedback, we've slightly revamped the plan. It's found that there are some additional dependencies that we need to add and some cleanups that we need to do. But overall, this looks good, so let's build it. This time obviously takes a bit longer because there is more stuff to build. What you can already do in the meantime is you can go to app.tower.dev and create an account for yourselves if you want to participate in the second part of this tutorial session. It's completely free to use, we give you a free compute for today, and then we're going to be faster later. agent has advanced it has all the details and starts implementing Yes.

Speaker 2 [32:33]

Go on, edit.

Speaker 1 [32:54]

You can leave in case of emergency, but otherwise please remain seated. There should be no walking during the talk

Speaker 3 [33:05]

If we can all I mean if if people If like we could also say like we do a quick break like if people do want to leave Like we don't want to force anyone to Like sit here and do things you don't You're not interested in Thank you. Okay, looks like we've weeded out the crowd, so excited to continue in a more intimate and more interactive setting. So what we're doing right now is, this is actually running, so I guess for the sake of this. We have gotten all the underlying concepts in place. I would open this up now for general questions on how these skills are composed, how the platform works, and then I would say we transition into getting everything up and running for you guys to try this out by yourselves. Sounds good. Then I would say we're open for questions.

Speaker 1 [35:14]

ask the questions through the talks.pycon.de. There are no questions for now, but maybe someone has questions. Yeah, and I will just hand.

Speaker 3 [35:36]

Yeah, thanks so much for the presentation and the demo. I just have a question. So from everything you have done, the only thing that is different was the API key stored in Toa, right? Because I've not seen anything different from what I do usually compared to what you have done. And are you presenting Toa as a secret manager for the project, or what exactly? Because I've not really gotten... Yeah, no, that's a really good question. And it's a very fair question, because we haven't seen much than Tower as a secrets manager at the moment. But it is actually much more. So let's say we're done with developing, and this actually works. Then I can just tell Claude, deploy this. hopefully it's going to do this and it's not going to object because we haven't finished the development yet. But this is like a tower, like this end-to-end platform. It's a runtime that runs on your machine, but the same thing runs also in the cloud. And in a normal setting, you would, I don't know, have to provision a Lambda function, a Google Cloud function, like EKS cluster maybe even. If it's a heavier workload. And all of that is going to be abstracted away for you. So like the secrets management is only one part of it. Does that answer your question?

Speaker 1 [37:20]

Quick reminder, please ask your question on talks.pycont.de.

Speaker 3 [37:28]

Okay, so for the deployment, sometimes I need to specify what I want to deploy. So normally I use like Terraform or whatever to create my infrastructure. I manage my secrets on Terraform vault. Can you connect to that? Because I don't want to move away from that. I need to keep that because I can manage those things. I have been managing them. I can easily provision because I don't know what kind of infrastructure I'm going to use. Sometimes I just want to use Kubernetes clusters, aka sometimes I want to use Nanda functions depending on the future of what I'm building. So how do I sync that with Toa? So I think, like, what are the people that you usually work with? Like, do you have, like, an internal data team that works on the infrastructure you provision or you are the data team? Okay, yeah, so what we usually try to do is to, like, simplify live for teams, so that you, like, now you already have, like, a Terraform setup, but most of the, like, other and smaller data teams out there, they are not that advanced, and this, like, this is where we come in and help them. I would say, these are very great questions and specific ones. We can have a discussion down at the booth and go in depth in all of those. right next to the main auditorium.

Speaker 1 [39:19]

All right, there is the next question. Have you tried other code harnesses like Codex or GitHub Copilot? What were your experiences?

Speaker 3 [39:30]

Yes, very good question. It comes very often. We have tried it and up until recently they were pretty, I would say, compatible with each other. Specifically, hooks are, at least as of last week, things are moving fast, only supported by Cloud Code and I actually found them to be quite useful. In terms of whether Opus is better than Codex, there was not really a difference. The way in which you can integrate all this tooling around them is slightly better for Cloud, at least in my experience.

Speaker 1 [40:21]

Thank you for the answer. How is the approach can be extended for machine learning use cases like for features, stores creating features.

Speaker 3 [40:33]

That is a very interesting question. I would say two things that you would need to have is your feature store needs to have a CLI or some way that an agent can interact with it, and then go through your own workflow. What kind of perspectives do you usually take? like a machine learning engineer or a statistician and then write like these persona skills and write some recipe skills so that the agent knows how to interact with your feature store and the underlying training process then, I guess.

Speaker 1 [41:20]

There is another question, how the standardization can be provided to have the same pattern across a company?

Speaker 3 [41:28]

Also a very good question, so probably this will be answered in the ensuing work that we are going to do. This is literally just a bunch of markdown files in a GitHub repo, so that can be shared across the entire company.

Speaker 1 [41:47]

right thank you yes there are no questions more do we have some questions

Speaker 3 [42:03]

So if not, I would say... No, we have one question. We have one more? I just wanted to ask, how was the procedure in order to create all these MacDone files or the workflows? Did you use Cloud Code as well to create them? Yeah. So it was like, I would say, a very iterative development process. Of course, the idea is not new. there's like lots of repos out there who adopt a similar approach for front-end development, back-end development and so this was the brainchild came from somewhere else and then I just spent a day or two with Claude together saying hey, this is how my usual workflows look like these are the perspectives I take these are the steps I follow and cast this into a harness of skills. Cool. Yeah, perfect. We're at 45 minutes, so we have 45 minutes left. I would say we're going to go around. There is also the Discord channel where you can ask questions. I'll be monitoring it. This is our Discord. Okay, lots of people on here already. A special perk for those who stuck around. For the part of this session, we will provide free Cloud API tokens. Yay! So the links are all in here. We're going to walk around. With 15 minutes to go, we'll do a cut, do a little final Q&A slash debrief. And if people feel really brave, we can also do a quick show and tell of what you've built. I'm pretty excited. I would say, let's get cracking.

Speaker 1 [45:51]

So now is hands-on session, and if you have any questions, just raise your hand, and Simon and Sergey will help you.