Agentic Coding with Xcode

Now, since we’ve looked at the basic starter project and we have an idea of what agentic AI is and how it could possibly help us, let’s see if we can ask Codex to give us some help implementing our desired features. One of the things that we wanted to do was to make some different models — baked goods and beverages — and also maybe get a different view for the beverages.

So let’s see what the agent will do if I give it this prompt:

  Add the ability to provide specific recipes such as baked goods and beverages, adding any other necessary properties. Suggest a new detail view for beverages that is unique from the existing detail view.

Let’s go ahead and see what this does, and we’ll talk about it on the other side of the processing.

As you can see, it is analyzing the project. It is going through and actually reading the existing code, and it’s doing some thinking. It’s actually saying, “I’m scanning these other files and key UI files to pinpoint core data models for implementation next.” So this is part of the planning process that we talked about with how agentic AI works. After reading a few more files, it goes through and decides what it’s going to do for designing a recipe category and beverage details. And it explains in fairly good detail what it’s going to do — plan to add a RecipeCategory enum to distinguish baked goods and beverages, with optional beverage-specific properties. This includes creating a new beverage detail view and updating navigation logic to show distinct detail views based on category, and adding sample data accordingly.

It even goes in and shows you some inline code. So it’s presenting the recipe category that it’s going to make, and it tells you that it’s going ahead and updating RecipeDetailView. And mind you, all of this is happening without user intervention — it is adding these files and updating this code without me doing anything. I’m just reading what it’s doing. So updating RecipeDetailView and planning the BeverageDetailView is sort of its next step. It’s going through and making some sections in the recipe detail view, and it’s designing a detailed beverage view that’s going to use a ScrollView, temperature badges, a summary card, and an ingredient list — and then it pumps out the file. Interestingly, it’s also grabbing the copyright information for this file based on what was in other files in the project.

It’s going to update our ContentView to use BeverageDetailView where appropriate. And then it’s going to assess — it’s going to review the UI and the model updates — and then it’s going to give a summary of what it’s done. It’s also resolving an indentation style conflict. The linter we use here at Kodeco is set to two spaces, but there are places where there’s actually four. So let’s keep that in mind for later.

So it’s added our recipe categorization, gives some specific details, and then it gives you some suggested next steps: building the project to ensure the migrations compile cleanly, and running the previews. So let’s do that — let’s actually run a build. This isn’t a great sign that it can’t build, but let’s go ahead and do it fresh.

Let’s go over to our area view. We’ve got a lot going on. Some of these warnings you can ignore — these are in the sample data, and our linter is complaining a little bit about that. But we’ve got some issues with this category that it introduced. In terms of pure errors, though, that’s the only one.

Let’s look at what it’s done in terms of our baked good. We’ve got our recipe categories and our beverage temperatures. But is there a baked good model? Okay, so we don’t have a separate baked good model — we have a specific recipe category that is differentiating them, and it’s probably going to be the same for beverages. No new beverage model either, but what I really wanted was to actually have the system use model inheritance, which you can now do with SwiftData. So I’m going to add another prompt to see if we can get around that:

  Update the SwiftData model to use model inheritance. Use the original recipe model and add baked good and beverage models that inherit from recipe.

So again, giving it a broad stroke on what to do, but letting the system run with that. It’s going to go and again do some analysis of what is there, it’s going to plan an inheritance update, and we’re going to see some changes to the code take place.

It even says here that it’s going to remove the enum in favor of type checks, which is important if we’ve got BakedGood, Beverage, and Recipe all as different types, even though BakedGood and Beverage will be inheriting from Recipe. So it’s doing a little bit of extra thinking here, taking a little while to respond, but ticking away nonetheless.

There we go. We’ve got some inheritance updates and some new code that it’s brought in. We’re keeping our beverage temperature, so that’s good to have. It’s going to update some type usage and some detail views. We’ll take a look at the BakedGood and Beverage models shortly. But you can even see in some of the code it’s showing you that it’s adding a Beverage type now. It’s also updating our SwiftData model to include BakedGood and Beverage, so that’s good — we’re heading in the right direction. It’s also refactoring some of the sample data to make a concrete instance of a BakedGood instead of a recipe with an enum. And again, at the end, it gives you your summary.

It also offers to run a quick build or refresh code issues to confirm the SwiftData migration compiles cleanly. We’re just going to build it and see what happens. Still getting a build fail. Let’s take a look and see what is going on here.

We’ve got some issues that we’re going to put aside for the moment. We’re going to do one other thing here, just to help with some of these warnings that we’re seeing. We’re going to ask the assistant to shift all indentations to two spaces instead of four, as that is required by our linter. Let’s see what it does with that.

It’s actually going to make a little Python script that’s going to run via shell command for simplicity and safety, pending approval. That’s a very important thing to note — I’m going to go ahead and allow it. And it does shift the code down to two spaces. So let’s give ourselves a build again. Still failing because of these errors, but aside from the line length violations and some other linter warnings, the ones that were complaining about two spaces needed for an indentation are now gone. But what about these errors? In the next video, we’ll take a look at what we can do to have the agent take a look at these errors and find a solution.