Wagtail and AI Agentic Coding

Speaker 1: Hello everybody. Welcome, welcome. No, we have a bunch of folks streaming in here. But at the same time, we definitely would like to keep things moving. So I'm going to go ahead and introduce my fellow colleague and co-owner from Torchbox. Machek Baron is going to talk to all of you today about Wagtail and AI agentic coding. Alright, take it away, Machek.

Speaker 2: Great, thank you, Megan. Yes, as a form of introduction, my name is Matchik Baron and I'm a senior engineer at Torchbox. And uh I've been using AI for coding for quite some time and a few months ago I started using AI agents and agentic tools as well. So What I wanted to do today is talk through some of the things that I've discovered and learned, explain how to set things up, and also how you can use such tools for coding, creating Magtail websites or any project really. So um so this will be uh the essence of this talk and I hope you find it interesting. But first let's have a little introduction to AI itself and how we sort of see it as developers. So I'm sure that a lot of you have gone through this sort of

Speaker 2: Kubleros grief cycle with AI, uh, especially at the beginning where you weren't sure like where it's going and and what the future holds for us, you know. And at the beginning I remember I was thinking like, ah AI is not that great, you know, it's not good enough, it's not gonna do anything. And quite quickly you started seeing all these models and all these tools coming out and thinking, like, gosh, actually it's getting quite good. And are we actually gonna lose our jobs? Is this gonna replace us? Like we start getting frustrated and you start getting anxious about it, right? But then slowly as I was sort of discovering it and sort of looking at it into it more you sort of start start realizing that well you know maybe it's not that much of a deal and you can actually use it for something beneficial in terms of your

Speaker 2: like your workflow and the way you create websites and code and create software. So I'm sort of at the acceptance stage now in terms of uh where I am in with AI and I've used it in a few different ways and I have my opinions and I think it's not perfect. I think there are problems associated with it, but I think there's also a lot of benefits. So um what I want to do is give it a go and tell you how to set things up and uh essentially how to use these tools. So today I'll be specifically talking about a clawed code and how to use that for coding. And I'll go through the setup, I'll go through the basics, how it works. and how you can sort of configure it. I'll talk about context management and then I'll talk about some Wacktail specific topics as well and how you can use it

Speaker 2: to create good Wacktail websites. So let's start with the initial setup. So as you probably can guess, it's a very simple way to install software. You just do npm install. To install clawed code, you give it a prompt, it does it for you, and yeah, that's how it works. It's very simple to set it up, you don't require anything at all. What you have to do though once you sort of start working with claude chord is to start start giving it a bit more information, right? So we're gonna start with a prompt. So in terms of what Claude Code can do for you, it can, you know, you can tell it to create a model, you know, you can create a template, you can create a CSS file, you can review your code. So there's a lot of things that you can do with it.

Speaker 2: You essentially use natural language and you talk to it as you would talk to a fellow developer, right? And sort of give it tasks and tell it like, hey, I want you to run tests using this specific command and so forth. So how does it work? So in terms of the way it works, normally what you have is your front-end and backend. So this is different to the front end and backend that we are used to when it comes to coding in general Um because the front end here, what we refer to as the front end, is the AI agent, right? So we have uh the either clawed code or open code or Gemini CLI or anything like that. That's the piece of software that reads out commands and performs certain actions, right? And then we have the back end, which is the AI model itself.

Speaker 2: So that could be Claude Sonic Opus, that could be any of the other chat GPT, GPT-4, GPT-5 models that you use. So the front end communicates with the backend in a way. So for instance, you know, the frontend may have its system prompts that it uses to edit the code. It offers a certain number of tools like tools to edit a file, to search for files, and so forth. Give it to the model and the model then works out what it needs to do and that's how it sort of works. So I'm going to talk about this in a bit more detail later on, but just wanted to give you like a brief overview of sort of how you can split this sort of when it comes to infrastructure. So I briefly talked about um having a file

Speaker 2: inside your setup. So The first slide showed this is how you install the clawed code and this is how you set up the software. But in order to make it work well with your project, you need to have basically an agent file. So in this case we have our Claude markdown file. It's basically a README but designed for consumption by the agent. So this README file will contain, for instance, instructions or basically a brief description of the project itself, right? So you can use Claw to generate one for you if you if you want it to be sort of automated. But what you want to make sure is that it sort of provides a very brief but also concise and uh detailed way of of of how to work through your code and for how to work through your code base as well. So if there's a lot to write about you can also split into separate files and then tell it that if you ever say

Speaker 2: need to work on the front end, look at this file. If you want to do some tests, look at that file and so forth and so forth. So I'll describe in a second why we do this and and also I'll talk about context management so that you understand for instance why we don't just write two million lines in this file and describes every single aspect of your project. But to sum it up, it's just a file like a readme butt for bots. Then what I want to talk about is MCP servers. So you may have heard about them before. MCP stands for model context protocol. And what it does is standardizes access to tools, resources and prompts. I think it's quite useful, but also a bit overhyped. I think at some point people were just installing loads of MCP servers because they thought like, wow, well all these things are really powerful.

Speaker 2: I do think that certain MCPs can be quite useful, but also some of them seem completely pointless, like an MCP to get the current date and time. I think that's pretty pointless. You can still tell the agent how to use an API or how to use local script or how to use different tools, but it's a good way of standardizing access to that. And it's a new technology, so we're still learning how it fits in. So I at the moment use a couple, so I use Context7, which uh gives you access to most up-to-date documentation, and I also use Chrome DevTools. which allows you to use and control a browser. Previously I used Playwright MCP as well to do the same thing. And also previously I used Zen, which is an MCP server that allows you to use different AI models for um different problems so you can actually use cord

Speaker 2: code alongside other models and other services. But now I use a slightly different method which I'm also going to talk about in a second. Great. So now that we have this set up and working, let's talk about the whole workflow and how we actually work through this to work with our code and make Cloud Code or any other agent do everything properly for us. So the way we use this tool is incredibly important, right? So this is a tool, it's not a hack or a shortcut. Because I think a lot of people, you know, when you hear about vibe coding, I think people just use it as a hack and like, hey, it's a really easy way to make a piece of software. But I don't think that's that's right. I think it's more of a tool and planning is still very, very important. So you can't give it just like a vague prompt and be like, hey, create a Twitter clone for me.

Speaker 2: I mean that won't work. What you want is a healthy, well-documented code base. You want to have tests that allow you to verify what the agent is doing. And like I said, context management is crucial, so I'm going to speak about it in a second. Once you have these elements together, then the software can work like wonders for you and actually create code that works really well and is reliable. If you don't have these elements in place, you'll be struggling, you'll be going in loops and the agent will just start doing things that you don't want it to do. So again, it's a tool, it's not a hack or a shortcut, and you have to keep that in mind. So for instance here's what I've been doing at the beginning. So I thought, you know what, I'm going to define a workflow in my Claude file that defines what I expect the agent to do.

Speaker 2: But at some point I realized that it wasn't really following the workflow. So I asked Claude Code to improve this for me and create something more specific so that it can follow the workflow. So what I did, it added these sort of signs. It's mandatory. You have to follow this. Do not skip these steps. And that improved it a tiny bit. But then it's It's also started sort of skipping some of these steps and not working really well. So I asked Claude Covid again, like what should I do for you to not skip those steps? And it created this massive thing saying like critical workflow reminder you have to first follow this list of steps because otherwise you will violate the established process. So I realized like, well, I don't think this is the right way of doing it, and there must be a better way of doing it instead of shouting out clawed code. I realized that essentially AI-based automation is unreliable and

Speaker 2: needs to use standard automation. In order to achieve that, we can use hooks, either like git commit hooks or clawed code hooks. So essentially we have a guarantee that something will happen. once an action is performed, right? So for instance, we can define a hook that once Claude Code edits a file, they can then uh run a command for you automatically, for instance, right? There could be this could be a linter, this could be something else. You can define the same thing using git. So for instance, you know, before git commit is run, then a command will be run to make sure that for instance all tests pass and so forth. This will also optimize the context because you're not like spamming the agent with all these different instructions and all these reminders to run certain tools at certain stages. So that's really important So this is when I realized I wasn't using

Speaker 2: clawed code properly. It was my fault for not doing it the way it should be done. And I think we're all still sort of learning like what is the best workflow with these tools to make sure it works properly But we have to remember that even things like that are not perfect and Claude can get confused if your hooks don't provide appropriate feedback. So for instance, exit codes matter. So if you write little scripts that you want to run at certain stages, you want to make sure that zero is for success. one for non-blocking issues and two for blocking issues, right? So you can write a little bash script or Python script that does something and you want to make sure that the return code, or the exit code rather, gives information to Claude and tells it like this failed, you have to do something else, or this is a non-blocking issue, just a warning for you to read or something like that.

Speaker 2: So here's my current workflow that I use with Claude Code. So first I use uh I break up tasks into subtasks and I think again planning is very important when you use these tools. I gather requirements with our AI. Then I use Gemini to do some planning. I create a plan that I save in a markdown file. I give it a clawed code. It writes the code. It runs tests. It writes the tests. um and then goes into this loop. What I do next is I review the code using a separate tool. So for instance either using Gemini again or For instance, there are other ways like you can use the LLM CLI tool and connect it to things like Open Router, where you can grab other agents and sort of consult them and make sure that they review your code. Then again, I apply the feedback with clawed code.

Speaker 2: Might come in a second time. And I can automate this process as well, right? So I can for instance tell it like, okay, once you commit, then ask this agent to review your code and then apply feedback to it. So this whole process can be automated, but obviously it's important to keep an eye on it So I'm just looking on uh time, it's been 12 minutes, so I think we're still doing well. Also, so if you work with agents, you might want to work on something on your own or maybe use two agents to work on different features. So in order to achieve that you can use git work trees. So that allows you to have multiple working trees in separate folders that share the same bit repository. So for instance, you can have the agent work in one feature on one branch, in one folder, and then you can use a separate folder to work on your own code as well, or your own feature rather. So it's quite a useful thing and I think is

Speaker 2: commonly overlooked this this feature of Git. So very useful. Right. So I've been talking about context management for a while. So I'm not going sort of dive into it a bit bit deeper because I think it's very very important and I think context management will actually be uh something that future developers will have to learn and have to remember because it will be super crucial in terms of the quality of the code that it generates. So as you can imagine with increased noise the quality of work done by Claud will decrease, like because we call it context rot, because there's more and more information being provided to the model, there's more and more sort of tokens that needs to process Obviously it will be get slower, it will get more expensive to run. And I think you know context management starts at the first prompt. Like you have to optimize the instructions that you give to an agent, you want to make sure that your documentation is right and you have to provide good feedback as well.

Speaker 2: That's very, very important. And you have to also remember that this is not a colleague of yours that will remember the past project we've worked on. Like Claude will always or any agent will start afresh every time unless you have some sort of memory set up for it, right? So you have to make sure that the information that is given is enough for it to be able to work on different projects and different features that you want it to work on. You can also ask it to keep things in the Claude file or the agent file itself, right? So as it's working for different features, you can tell it to be remembering things or recording like learnings into a separate file as well. And when you give feedback, you have to make sure that it's good feedback, right? It's not sort of like, oh, this doesn't work, work it out. You want to make sure that it's given all the right information.

Speaker 2: because otherwise it can go in a loop and sort of try to break things and before it fixes them. So remember to give quality feedback and you know you have to point at specific files, you need to give examples, be precise and detailed in your prompts and avoid unnecessary peacock terms, but emphasize as well the importance of different problems, right? And I think tests are incredibly important because it gives automatic agent feedback, right? So if you have any unit tests, the functional tests then uh every time the agent does something they can quickly then basically evaluate the output and what you what what they've done and then quickly sort of fix the problem. So I think you know Looking at all of this, I think when you use agents and use this sort of type of programming, it actually

Speaker 2: enforces good dev habits as well, right? Because you document your code, you write good tests. Also that, you know, the agent can use this and provide good code and good quality code for you, but also it helps you and other developers on your team because of the documentation, because of the tests and so forth. So I think it's sort of Hopefully, you know, if you approach it in a proper way, it actually sort of emphasizes and sort of strengthens these different uh sort of techniques and things that good developers use. Right, so let's briefly focus on Wacktail. So uh obviously all the things that I've mentioned so far. You can use them for different projects and different code bases. It's not specific to Python or Django Wacktail. But there are a few things I wanted to talk about when it

Speaker 2: comes to Wacktail. So as you probably know, the way models are sort of created, they are trained on loads of loads of data. And this might be code bases, this might be text. This might be different pieces of data that then form the sort of brain of the model itself. And I think what is good about Wacktail is that a lot of Wagtail problems are actually Django problems. So even if say Wactile is not as popular as say WordPress, which has a larger sort of user base, there's still enough data in those models. that allows you to sort of work with Wacktail and solve different problems. So it's really good that Django is the sort of backbone of Wacktail because the data that is used to train these models contains a lot of these examples.

Speaker 2: And I think because of that, when you work with these agents, they excel at defining page models, for instance, but they can struggle in other areas, and I'll discuss that in a moment. I think what's useful as well in some of these agents, like for instance, Clawed Code, Claude Code, you can create sub-agents as well. So you can actually create agents that focus at specific types of tasks or expertise in your Wacktail workflow. So for instance, you can have an agent which is an expert in writing unit tests and migrations, or you can have another sub-agent that works, say, on creating SaaS files or creating migration files and so forth. So it's quite useful because then you can isolate the context of these different sub-agents and they will do things in isolation without polluting each other's context.

Speaker 2: And this is really good for setups like Wacktail because obviously there's quite a lot of layers to a Wacktail website. You will have your page models, you will have your templates, you know, whether it's Ginger2 or Django templates, we have your tests, you'll have your migrations that have to be written and tested and so forth. So it's sometimes quite good to split that work into different sort of streams And then that way things can happen simultaneously, but also it won't affect the context window of other agents as well. So I think that's a pretty good way of approaching it. So Megan, who introduced me earlier, she actually wrote a really good article called What AI Tools Get Right and Wrong with Wacktail, and I really recommend this article because she used the AI tools for building Wachttail websites and working

Speaker 2: Wacktail projects. And she sort of listed quite a few of the sort of good things and bad things about using these tools, and I think this was really good. So yeah, the link is below and I'm sure you can find it on the Wacktail blog as well if you look for it. So definitely recommend reading that Great. So having spoken about how to use these tools and you know what they're good for, I also want to talk a bit more about the current challenges that we are facing with these tools because that's actually quite important as well. These tools are not perfect and obviously they evolve at such a quick pace, things change all the time. And so it's important to sort of understand the limitations of these tools and how we can use them. So the first big one is securities. So People talk about the YOLO

Speaker 2: mode of these agents where you just allow them to do anything you want. I don't think that's a good idea. It might seem tempting because you don't get interrupted and the agent will just do what it wants to do But I think a good practice is to keep a list of commands that you don't want it to ever use and perhaps a list of allowed commands as well. So here's an example of some commands that you can deny. Because it's possible for the agent to get confused and do something it's not supposed to, even if there's no prompt injection. You may have heard about the term prompt injection. It's when a prompt contains maybe something that it shouldn't contain. in in certain files data sets that the agent is consuming. So this can prevent both accidents and attacks. So it's quite important that you think about it. You also have to be careful when you expose the agent to MCP servers because obviously it's an agent that can read some

Speaker 2: of your files. Those files can contain API keys, it can contain sort of some secrets and sensitive data. So if you don't pay attention to what the tools you use and how they sort of extract information from your project, it can be quite dangerous. So you have to make sure that you look at those and see what they are actually doing. Supply chain attacks can have a huge impact on your project and this is something that you have to keep in mind. So just to sum up, if you use Cloud Code. Make sure that you have a list of commands that you deny, a list of commands that you approve, and instead of using the YOLO mode, because that can be quite dangerous. So here's an example I found on online when you can get an agent very confused and it can do something it's not supposed to. So, you know. Here's an example of something to bear in mind, right?

Speaker 2: Because uh again of the day it's not a dev, it's a model. So it might do weird things Another world challenge itself, I don't know if it's a challenge or more of a just the nature of things, new things come out every week. Like we have new models, new agents, new AI tools, new ways of working, new plugins, new new MCP servers every single day, every single week, and sometimes it's very, very tricky to remember and also keep an eye on everything that comes out. So You might be using one tool one day and learning how to use it and then suddenly you hear about a new tool and you sort of jump to that. So uh it's challenging, but at the same time, I think you know A lot of people are trying different things and we are living in these times where things are very dynamic and exciting because all these different things come up. But um I think it's important to not get discouraged and not to sort of keep jumping ship and jumping on the latest thing because a lot of things are quite similar, but also like just because it's new doesn't mean it's

Speaker 2: good or it's better to what you're using right now. So as long as you sort of stick to one thing and sort of make sure you learn it well and you understand it, then you can move on to something else if you want. But um but yeah I think that's also quite challenging at the moment So another problem is obviously hallucinations. You know, I'm sure all of us heard about hallucinations when it comes to AI and also outdated knowledge. So hallucinations are a problem because the model can be very convinced it's right even though it's wrong and it's suggesting something that doesn't actually exist. On the right hand side I shared a screenshot where basically the model thought I'm trying to deceive it and got really, really angry. It was basically saying that what I did was a complete fabrication and I'm just using some evil tactics.

Speaker 2: Only because I was trying to point it at the correct documentation, the correct source code. So you have to be very careful. Also the solutions that you might suggest might be based on older versions of Wacktail, for instance, sometimes very outdated So it's important that you make sure that your model is using, or your agent rather, is using up-to-date documentation. So again, there are MCP servers that can handle that, which is really good. And again, you might even struggle sometimes to convince the model that they are wrong. Like they will just think like whatever you're doing is is not correct, and they will strongly believe that the information that's deeply embedded in them is actually correct. And I had moments where basically I was arguing with a model because it was doing that. So it is quite frustrating and funny sometimes. So bear that in mind

Speaker 2: And another challenge is the cost, right? Because it can get quite pricey overall. Some of these tools, you know, cost you like $150, $200, $250 a month, you know. I just put some calculations here when it comes to some of these models. And obviously there are cheaper models, there are more expensive models, and this will definitely get cheaper over time, not only because technology will be cheaper, but also the models will improve and be optimized. So at the moment can be quite expensive. But also there are free versions of certain models if you want to try them out without paying any money. And I'm sure that Gemini as well from Google actually offers some free allowance. quite substantial allowance I think for for for Google users so definitely something to try out. But one thing to keep in mind I think.

Speaker 2: Right, so some final thoughts from me. I don't think AI will replace us, but I think it will definitely drastically change software development. I think context and agent work for management will be key developer skills. I think the skills that we will be looking developers will be very different, but it doesn't mean that developers will disappear. I think the way we write code will change And there will be some skills that will be using a lot more or skills that we haven't even had before. And I think, you know, AI is a tool which still requires knowledge and experience. uh and it's not something that will replace a uh a dev and just you know we won't be vibe coding our future I think. And I think developers will also have frontend and back end preferences and potentially provider preferences as well. So you might like a certain agent that

Speaker 2: sort of manages your changes, but you also might have a preferred model that you use as well or a provider, you know, because based on cost and latency and so forth. So that'll be a thing as well. And I think you know models can suggest code which is outdated and doesn't follow latest specs, so we have to keep that in mind. I think that whacktail benefits from being a Django application and sort of having that retained knowledge inside those models that can sort of improve the way you work with things. And I also think that we are still very early and everything is quite volatile and things will keep changing at intense pace. So I think that's something to keep in mind. Like don't get discouraged if you know you've been learning one thing and suddenly everyone else is doing another thing. It's normal, I think. You know, it's just the way things are with stick to technologies like this that keep improving, keep changing all the time.

Speaker 2: At some point probably things where it gets standardized and worked out so maybe there'll be fewer things to remember but again just give it a go uh don't be scared of it and I think it's not gonna affect us or our careers uh in any way in a sense that it won't replace us, but it will definitely affect the way uh we work with code and what we'll be looking in future developers as well. Thank you. So this is all my thoughts about agents and I hope you found it very or at least a tiny bit interesting. And if you have any questions, just please let me know. I saw there were some messages popping up on chat. Unfortunately, I wasn't able to read them So I'll just mute myself and maybe try to go through them in a second. And I also uh I might not stop sharing in case someone wants to look at a slide, but I'll just mute myself for the time

Speaker 2: being. Thank you.

Speaker 1: All right. We do have a couple questions for you in the QA area that let's go ahead and answer some of those. The first one comes from Andrew Seltzer. Says, do you think Wagtail should have an agents. md file? And if so, what do you think it should contain?

Speaker 2: I think that's a great question. I haven't seen many open source projects yet which have an agents MD file. There are a few, and I think it's you know interesting that people and teams like that are thinking about including them in uh in those repositories. But I think this is definitely like a a a a far reaching thing, you know, once we have a file like that because uh I think there might be a lot of discussions about what to include with inside those files within open source teams. And I think it's definitely a potential source of friction because many different people have opinions like what's the right thing to include and you know tweaking wordings and things like that But if say theoretically we had an agents file in a Wactail, in a core WACTAL repository, definitely we would obviously describe them the

Speaker 2: main aspects of the code base in terms of like how it differs from regular Django and uh you know how we are using Django to achieve things like having pages and uh uh having a different sort of admin panel with uh management pages and so forth. So uh that would be definitely quite important. I also think definitely how to write good tests and make sure that your code is testable so that the agent always writes tests. and always verifies things before um or after writing them. And again, there could be wider discussion whether we want to use a test-driven development approach here where we ask the agent to first write tests that fail and then write code to meet those tests. Again, I think there will probably be a lot of discussions and a lot of different conflicting thoughts about this, so it might be difficult to establish one, but we'll see, maybe in the future.

Speaker 1: All right. Ralph is asking, where do you define the deny options?

Speaker 2: It's in the settings file, so you can do that in a few places. You can either do this in your local cloud, uh, claude. um configuration file within the project itself or you can have a global deny file as well. I don't remember the exact location off the my head. I think that's in in your home direction dot dot clord and then I think in the project file I think it's awesome. claude um but it's essentially the whenever you are whenever Claude asks you do you want to just accept this for this project and you click yes it will add an entry to your file anyway so you can try finding where that is and then you can add things manually as well and deny things as well so Um yeah, sorry, I don't remember that on the top of my head, but I'm sure you will find it if you just um look for it in your project. Thank you.

Speaker 1: All right. Um this will be the last. question um and hopefully it'll be uh it's probably not a quick answer though but which model do you find to be best for Wagtail?

Speaker 2: That's a tricky question because I've been using a lot of different ones recently and I don't think I had enough time to spend enough time with one of them for an elongated period of time To see like oh this one's definitely better. New ones keep appearing all the time. So for some time I've been using Sonnet. Now we have Sonnet 4. 5, so I've been using that a lot. And to be honest, it was quite good I don't think Gemini is that great, at least Gemini Pro. I think Gemini Pro has a lot more hallucinations than I've noticed, say, in the anthropic models I think I've used Quen code, if I hope I remember this correctly, Quencode as well. And it was pretty good, I'd say. So there are a few options out there, I think, you know

Speaker 2: But um but yeah, I th I I don't think there's one preferred option at the moment. But I I I think Gemini is good for planning, but I wouldn't say for coding. So I can maybe say which model I don't like for Wagtail uh but not which one I like. So avoid Wacktail for uh avoid sorry avoid uh Gemini uh for writing Wacktail but try other models if you want

Speaker 1: All right, that's all the time we have, folks. Thank you so much. This chat was so active. Uh I'm definitely going to share the um the transcript with Machek so that he can catch up with y'all on any of the questions that came through there. You can also chat with each other in the lobby if you'd like as well. All right. Thank you so much, everybody

Speaker 2: Thank you everyone thanks for listening