Hello and welcome to the Coding Intelligence for Beginners group lab. My name is Angelica, I'm part of the Worldwide Developer Relations team, and it is my privilege to be hosting today's group lab because I am joined by some great panelists, some that you might be familiar with from a certain platform State of the Union, including someone who had an incredible wardrobe with Xcode themes. Thank you, I didn't wear it today. Unfortunately, I really wanted that neon noir one. and also Monsieur Fantastique himself. We are all so excited to answer your questions today. There are quite a few of you joining us today, so there's a chance we won't get to every question. We're going to be focusing on the most popular questions and questions that benefit the broader audience. If you don't get your questions answered today, don't fret. We can continue the conversation in developer.apple.com slash forums. And of course, don't forget about feedbackassistant.apple.com where you can submit code level questions, bug reports, and enhancement requests. All right, that's enough from me. Let's get started with a round of introductions starting from across the table. Who are you and what do you do here at Apple? Yeah, I'm Nathan and I manage one of the, one of a few different Xcode intelligence teams, specifically one that deals a lot with the interactions with the agents and the models we deal with. I'm Ken. In addition to doing fun costume changes and so too, I lead the Xcode team. Hi, good morning, everyone. I'm Jerome. I'm the product manager for Developer Tools and also a pins collector. Hey, everyone. I'm Kevin. I'm one of the senior engineering managers for Xcode, focused on our AI tools. Awesome. Well, this is coding intelligence for beginners, after all, so I'm going to start with a general question for all four of you. Coding intelligence, working with agents, it's a pretty big shift in terms of the way developers work. And some folks are at different levels of familiarity with agents or working with agents. How would you say development has changed, especially app development? How has it changed since the introduction of agents? Maybe Jerome or Ken, you have talked about this. I mean, I think from my perspective, what you get to do a little bit more tangibly now is you get to work with these agents to articulate some of your ideas and make those a little bit more real, something you can see. Something I personally do is I work with the agent to create a spec for what I'm building. So it kind of creates this document that says this captures my intent or it doesn't. And if it doesn't, then I can iterate with it. And then I can see it over time. I can modify it over time. And so that's one big change. Like, all of those things were happening before. People were doing those, but they just weren't maybe quite as codified. So I think that's a big one. Yeah. I mean, you know, from the very beginning of computer science, we tried to make coding easier, right? And, like, you know, in the beginning, you just type, you know, one character at a time. You know, and we had a mistake. You had to find exactly what it was. So we added code completion and, you know, code completion with models. and then this chat experience that allows you to generate codes in a certain files. But like this agentic flow, you know, that can verify it's on work, fix it's on errors, and actually work until something is done, that's a much bigger shift that helps you realize your ID much faster and actually keeps you very creative because you can really focus on making those IDs a reality with the help of all these antique tools. I would say it goes beyond just the idea of getting to the idea that you already have in your mind. I think what I love is that you can actually test your idea to see if it's good. I find most of the time my initial idea is probably wrong. And before, I would stare at this complex path before me and be like, I just don't know if it's worth it to go down that path with agentic coding. It's so easy to explore all those different paths. There's a lot sort of shifts in your mind when you're exploring a problem space and the cost of writing new code and deleting old code is so fundamentally changed. You feel much more emboldened to try things that you might not try before and to really do something for your user that you wouldn't have thought possible. I think that's very, very cool. That's the coolest thing, really, is that it shifts this cost around a little and makes it possible for you to try big things. One of my favorite things that I think that it has introduced is the introduction of some of the best practices that a lot of folks may delay or put later in their roadmap, like how introducing testing has actually helped with agent workflows. So building your test suite actually benefits every prompt that you have with the agent moving forward or introducing the translation with agents and localizing your apps. And these type of things, it benefits you as a developer because it makes it easier for you to do. but the incredible benefit to your users, to the people who are using your apps, is immeasurable, I think. So that's, I think, what was the most exciting about the introduction of agents, especially in app development. Totally. All right, we do have some great questions from some developers. The first one we have from Pichaya TryYS. I really hope I pronounced that correctly. Where is the best place to learn all the commands like slash plan and more? Yeah, so when you type slash Xcode has collected from the agent, if the agent happens to provide a list back to us, the compatible commands that it knows about, and then it'll also show you any of the skills that are loaded up from Xcode, things like that. You can also ask the agent, right? You can ask the agent for help with this stuff. The agent is aware of almost every command that can be executed and what it will do. I would suggest experimenting with both of those things and seeing what you can learn from that. And just try some of them and see what they show you because you may be really pleasantly surprised about a whole new workflow that either we provide or the agent provides already out of the box that really changes the way you work with these. I think ask the agent is probably something that, you know, will be an answer for many of the questions today, you know? Definitely a good tactic to ask the agent. All right, we have another question from our developer, Jason Chung. As more developers adopt agent-first workflows, What unique advantage does Xcode's built-in coding intelligence provide over external AI agents? And how does Apple see the future of relationships between AI and Xcode? Well, maybe the future question might be a little bit tougher since we don't talk about future plans. But I'm very curious if you all have insights on, you know, what's unique? What's a unique advantage of using Xcode for agent workflows? Yeah, Kevin, why don't you? Yeah, I'll start with that one. I think a couple things that come to mind immediately. One is we've spent a lot of time thinking about our tool set that we provide. We've spent a lot of time talking about the knowledge that we provide and also the project understanding. So if we look at we've really tried to get the agent to understand how your project is laid out, what does that mean for developing on Apple platforms, then there's a lot of great tools that surface information about the SDK and the APIs. We have our documentation tools that allow the agent to explore what are the new APIs. So it's always getting the most relevant information. And then there's tools for validation. And I think this is what gets me really excited is how do we help the agent actually check its work as it goes along? So we have tools that you'd expect, like building. We have a couple different kinds of building tools because we're also trying to make it really fast. So we have both build the whole thing, but we also have little builds that can run. We also have tools for validating the execution of code, which is, I think, really exciting. We can do both the execution of little snippets of code all the way up through actually rendering your UI and interacting with it and testing it. So those are a couple of the different tool sets and knowledge that we provide for the agent to use inside of Xcode. Yeah, and then I think there's other things that go beyond that into the Apple ecosystem that give you access to data about your apps. So your crash data, best practices with localization, and there's a lot of Apple knowledge baked into those to help surface up things to you to make it a lot easier to utilize that. - Yeah, Xcode has like years and years of experiences of building apps for our platforms. And it comes with unique features, like the preview system, for example, which is unique to Xcode, allowing you to actually visualize all your changes. And now, you know, we're giving the preview system to the agent so that he can visualize its work, right? And we build those very nice crafted experience within Xcode, you know, to annotate things, text, but also previews. So not only, you know, you have all the tools available, but the experience itself, you know, feels very, you know, Apple, very well crafted. So that it's, you know, welcoming for newcomers that maybe are using agentic for the first time, they will feel at home using an Apple product, but also very powerful for all the people that wants to do very complex things. And maybe they're working in Excel for 20 years. They also need to be welcomed with that new agentic workflows. The other thing that we offer is there's an onboarding point when you're just getting started with these agents where it's very overwhelming, because you're looking at all the different things you can do with these. And you just send an English language sentence to an agent, will come back with an answer and it'll look like it's done a great job. And it probably has done a pretty good job, actually. But we have a lot of experience working with agents now and understanding how to onboard into these agents really effectively. So we offer out-of-the-box guidance on a really good starting point. We have a really good planning mode that really helps you get the most done with the agent's built-in planning mode, and we add a lot of great stuff on top of it. We have a really good base set of tools, and you can extend both of those things with plug-ins now, of course. But it means that as you get started, you already have sort of a running start that someone outside Xcode might not have in terms of learning how to use an agent really effectively. Great. All right. Moving on to a very highly upvoted question from Harry3. Does the Xcode 27 UI have any indication of the amount of agentic resources being consumed while it is carrying out your request? Yes. So your agent provider will have a slash command of some kind that will give you access to that information. I don't want to enumerate every single one of the different ones because there's so many. I will point out that there's often two. There's one that tells you what the current state of the primary context window, the central coordinating agent that's handling the transaction, how full that is. And then there's also going to be one that tells you how much things have costed so far or how much you've used. These are often two different numbers, and it can be easy to mislead yourself by looking at the wrong one in terms of am I going to regret spending $20 on this session or whatever might be a different answer than am I getting close to the point at which the agent is going to start compressing down its context and I have to wait a minute or so. I think maybe a clarifying point too is that we don't have that information in the UI. That's something that you ask. To Jerome's point earlier, you ask the agent for that information. You ask the agent for that information, yeah. If there's more information like that that you'd like to have better surfaced, that's a great time to file a feedback. Yeah, absolutely. Because this is the kind of workflow stuff we're really interested in fixing for people. Yeah, if there's a particular use case or perhaps a suggestion for where would you like it to be surfaced outside of asking the agent, file feedback at feedbackassistant.apple.com. All right. Let's move on to another question from a developer, Juto Art. If the Xcode AI agent needs to read or search implementations from other projects, is there a way to add additional working directories to its context? For example, could we let the agent access another local project when it needs cross-project references? This is a great question about security and permissions that the agents have. Nathan, do you want to kick it off, Nathan? Yeah. So we do sort of have a few different modes of security that you can operate in in Xcode with agents, right? By default, out of the box, we will use permission prompting to sort of make sure that the agent can get to the things it needs to get to but doesn't have free reign. If you find that the permission prompting is getting in the way of being able to let the agent do a lot of hard work, the other thing that we offer, in addition to allow always, is a mode that you can turn on that is still sort of an early preview of this functionality, but this managed security mode that lets you instead sort of gate on the agent's actions themselves at sort of the file system level and govern what happens. In terms of handling references, if it's referenced in your Xcode workspace, the agent can get to it and can know about it. If it's referenced outside your Xcode workspace, it's something on disk somewhere that you want the agent to be aware of, all the time I'm pasting in file paths or I'm saying, oh, it's in my documents directory and I'm letting the agent go explore and find it. It's very good at just figuring out the distinction between these things and getting the access it needs. That's a great point about configuring your Xcode environment for what you're working on. Xcode workspaces are a great way to bring in multiple projects. You can kind of mix and match based on what you're working on at the moment. Configure your workspace, and then we automatically handle the agent being able to see all those pieces. Super important is you're always in control. You will see those tool calls, and the agent will ask you permission to enable a certain – some of those tools can actually move your files or delete your files, so we always ask you if you allow those tools within your project. Yeah, but there's – I mean, there's great – it's easy to give access to things where you always want that. Like if you're like me, you take a lot of screenshots, drop them on your desktop, you want the model to have access to that. So you can reference those and talk about those. Really easy to do that. But you always get to make the choices. Absolutely. Okay. There is, as Nathan mentioned, there is an experimental one, an experimental feature in the settings, I believe. You were mentioning in Xcode settings, if you wanted to give it permissions to take certain actions. But when you're copying, moving, deleting things in other directories, of course, we want to make sure that you are in control and know exactly what the agent's going to be doing since it is pretty non-deterministic most of the time. All right, great. Let's move on to a question from Tammy Santana. Coding intelligence builds features but doesn't explain them. A beginner finishes a session with working code that they don't understand. They can't debug it, maintain it, or extend it. Please add an optional, explain what I just did and why summary. This might be more of a feature request. Please add an optional explain what I just did and why summary after each completed task for people who want to learn, not just ship. That's a great point. I think there's a couple things to do. One is asking the agent questions is such a great idea. It's a great way to do it. They love to talk, so it's great to be able to ask the agent, like, why did you just do that? And it's happy to give you, in kind of the form that you want, like I love asking for like HTML reports or Markdown files. It's just like, tell me why you did this. Help me understand. And you can kind of get, like what's cool about agents too, is you can configure them to kind of do your common things like out of the box. So if you have like an agents MD in your project, you can configure it to say, after I want a prompt, just always give me some explanation. Here's the format I want it in. Here's how I want you to do it. And now suddenly you've just basically built yourself a feature inside of Xcode, which I think is just really fun and powerful. So much you're creating a skill for yourself, which is, you know, every time I ask for something, I want you to create documentation for it or, you know, create a summary of what you just did. The way I'm using it, though, is I'm creating two conversations, right? In Xcode 27, you can have many conversations in parallel. And so while the agent's working, actually ask questions on the code that's being generated or a question of a new API that it's using, right? So you build and learn at the same time, which is really cool. Yeah. And I think this kind of goes back to the sort of spec-driven development that I was talking about, where you can bake it into what you're asking for. So you can upfront ask, you know, like, let's start by actually, you know, you tell me all the assumptions you're going to make. Maybe tell me how you're going to implement it and capture that in something that you always have. I find that to be, you know, a good way to kind of split the difference there. Yeah. Another strategy I use all the time is I will write the shape of the code. I will declare the struct where the work will happen. I will add some of the properties. I'll put a comment saying, and the other's there. And then I will go over and I will declare the protocol that something else conforms to. And I will add a comment somewhere else that says, and here's where I think we're going to have to call this stuff. And then I'll open up a chat with an agent, and I will say, all right, let's do this work together to put this thing together, to thread these pieces together, and the agent can help fill in the gaps. that can be a very, very powerful technique as you're sort of working through solving these problems. And I've found, especially in apps that I'm just bringing up for myself, I can define a lot of the structure that way very quickly without having to get as hands-on as I used to. That's a great point about constraints. Like, there's different fidelities of constraints you can give it. Like, sometimes I'll give it natural language constraints. Like, please do this thing for me. Sometimes I'll give it, like, a source file that's, like, fill in these things for me. And sometimes you can combine it. It's like, I'm not sure how to build this part, so I'll do it in natural language. This part, I really care that it's a protocol that has these kind of requirements on it. And then you bring those together, and the agent does a great job of blending those. That can help also with the understanding. You can kind of start with what you understand and then bring in the parts you don't. - I was thinking too, like we talk about plan mode as a way to be able to understand before implementing any code, before anything gets changed in your project. But plan mode's also a really great way for you to understand how it approaches a problem. And so rather than just saying that agents are just shipping features that I don't understand, that plan mode is actually there for you to be able to make changes and be the conductor of the work that the agent actually has to build. So I would say that there's a lot of opportunities to learn or learn about what you're building as you're going along with the agent. Again, asking questions is a great way. Building architecture documents that you then leave in your project is also an added benefit because that means the agent can use that in the future when you're building more features. And that means you also get to use that as resources or your teammate gets to use that as resources. So there are lots of ways you could use agents. It doesn't necessarily mean it has to go off and do its work on its own. There's a lot of control that's built into Xcode for you to be able to participate. The other thing is like there's always this sort of tension that you feel as you're working on this stuff of like I told the agent to go off and build this part of the calculator, but when I display the tip, I wrote this part, but now I feel very alien from that calculator stuff. How do I fix this? One of the things I've found that is a very fun way to sort of do this stuff is I will even sometimes, if it makes a big change for me, I will ask it to host a little game show for me and ask trivia questions with its question-asking tools about how the code is put together. And then I have to answer the multiple-choice questions, and I get to play a little game. And it teaches me about the code that I now own. If you go did wrong, it's tough working. That's a great point about the different ways that we all learn. I'm a visual learner, so I love diagrams. So I always have to make diagrams because it makes so much more sense to me. I think that's why my first thought was architecture documents, because I have to be able to look at the way data flows or how these features are built so that I can validate that that's actually how I want it to work. And I think that's the part that working in Xcode specifically, being able to understand the context of the project, what's happening with Xcode, details from the organizer data or crash data, you could actually be a little bit more thoughtful about what you do. And debugging is still your responsibility. You could ask it to debug things, but you still have to figure out exactly if those solutions are correct. And so there's a lot of control that you, And again, a lot of collaboration that you can do with agents rather than necessarily leaving it to chance. All right. Moving on to another question from Florentine F. What are some common mistakes the coding assistant makes that beginners would find pretty hard to catch on their own? It's a great question. So there are, of course, whole classes of bugs that these coding agents will commit just like humans do. The most subtle thing a coding agent can do is not understand the assumptions that you were making when you asked it to do the work. And this takes many different forms. It could be that you asked for one thing and it gives you something completely different. But it can also be that you asked for one thing and it gives you an unmaintainable version of that thing. You know, there are whole sort of categories of these failure modes. It also can often not discover absolutely everything it needs to. In Xcode, we do a lot of work to make sure that agents can find what they need as quickly as possible and learn from it as quickly as possible. But these are fallible tools in a way that a compiler is generally not. So you have to watch out for those things. I think the variant that I am often the most sort of nervous about is what I would call like cheating, where an agent has quietly gone through a bunch of work and its job is to finish the job. Sometimes it will look at the work that has been done and it will go, well, I haven't made that unit test pass. but that's okay. It doesn't pass because I'm in a debug configuration right now. It'll pass in production. If you wouldn't accept that answer from a coworker, don't accept it from a machine. And you have to watch out for that stuff and keep on top of it, but you can also teach it over time what your expectations are, especially with things like tests and strong types in your project that get caught by the compiler and live issues. The agent gets feedback on that stuff fast so that it can iterate and see its wrong work before it gets to you By the time it gets to you, it's going to become much more challenging to catch everything that's happened. Yeah, and I think that's something that we've spent a lot of time doing is working on the tools for validation, particularly. That's why we have so many tools for validation. So I'd say experiment with some of the different tools that are in the Xcode suite to kind of figure out, like, what works for your project, what's important, like, different workflows, and share them with us. We'd love to. I think I would love to hear, you know, what developers are doing. I think that's my first thought process is, I mean, this happens with a lot of our features in Xcode, Swift language. When it's finally available to a larger audience, you know, we all sit here thinking about how agent workflows are going to be, or like how we think it would be best done with Xcode's context and the tools that we have available. But the way they use those tools are always surprising to us sometimes, you know, like not always, but sometimes surprising. where you're choosing a different workflow or your agent workflow is a little bit different than we expect. And of course, that's where feedback assistance is incredibly valuable. If you have an enhancement request or a tool that you want to work in a certain way, reach out to us and let us know. All right. Let's take a look at another highly upvoted question from Tammy Santana. This might be another feature request that might be great for us. It's my favorite kind of feature request. So, Tammy Santana is saying, there is no undo button. Xcode Coding Intelligence needs an undo agent changes button. When the agent edits 10 files across my project, my only rollback option is Git, which beginners, not all beginners know. One button to revert everything the agent did would save hours of damage from bad suggestions. Well, actually, you can tell the agent. actually, you know, this doesn't work for me, come back to the previous state. And they will do that usually pretty well, right? So he knows how to undo the work that he's just done because he has a whole context, so he can always roll back to the previous state. But that's a good feature request. The other reason that I was joking that this is my favorite kind of feature request is because it's an already implemented feature request. We have actually this history thing that has kept track of. As long as you have initialized a Git repository for the agent to work within in your project. We do track states across each turn with the agent, and you can open that up and move the slider up one level and hit revert, and it will go back to the way that it was right before the agent took its last turn. Right, so there's different levels of things you can use. There's obviously Git is the largest tool, the largest time window, I guess you could say. Then Xcode has this history feature for the very granular, the last action that you took. And, Jerome, you were saying, ask the agent. And the agent's also very good at understanding kind of what it did, which is also nice if there's parallel work that you're doing or there's multiple threads. You can be like, well, undo this part, but keep this part over here, and it will kind of merge those together. Yeah. I mean, I found the agent does a fantastic job reasoning about its own work, especially over time. So as you're making commits or having it make commits and you realize something from yesterday isn't quite right or isn't panning out, it does a good job when you point that out. So it does fantastic. I do want to call out also, Tammy has a great point here, which is the only rollback option is tied to Git. So both the history, if you have a Git repository set up with your project, that's the best way to be able to use that feature. You could ask the agent to go back. what I want to call out is regardless if you're using an agent using Git is incredibly valuable please use Git there's a reason that box is ticked by default when you hit new projects when you start new projects you can set up a Git repository with your project so that you can actually do these changes I would say even if you're developing features on your own I just want to say this because I've encountered a lot of developers who are solo developers they think that Git is related to working in the team where you have to do pull requests and things like that but being able to revert issues like bugs that you introduce in your app, and you released it already, and you have to revert very quickly and be able to release it really quickly, Git is your best friend. Definitely take a look at that. I have a ton of little side projects. They're just me, and I always turn Git on. I mean, there's no downside to it, right? Yeah, exactly. All right. And it's really healthy for an agent, too, to be able to look back and Git history and see an archive of why changes were made. all the time I will be able to trace back in one of my apps a bug that was created because of a bad assumption that happened when I was working on something unrelated, you know, and that's only possible if you have a tool like Git at stores, the changes and the explanations that's alongside each other. I guess that's a pro tip too, is like the commit message is really important. And the more you document assumptions in there, so it doesn't have to re-evaluate what the assumptions are by looking at the Git diff. I was like, you don't have Git commits like me where it just says WIP? Work in progress. Fixing bugs. Habits I got out of because agents didn't like them. This goes back to a point I had earlier, which is I feel like what agents has introduced to a lot of folks is because it has, Because by introducing things like good development practices like Git or testing or any of those tools that you typically wouldn't necessarily do as a solo developer, once you have that context, the agent actually works better because it can make a lot of assumptions about how you work and what your project history is. And those prompts that you have or whatever plans that you try to have them generate, it will have better assumptions to start. And that first prompt will be much better than it typically would. All right, great. Let's go into another developer question from UJ. I have years of iOS development experience, but little experience with AI coding assistants. As more engineering roles expect AI-assisted development skills, how would Apple recommend using Xcode's coding intelligence or other AI tools to develop the skills needed to meet industry expectations? How much time do we have today? Who wants to start? I mean, I would say just start simple. Like you don't need to start with some massive project. I mean, what I would do is work it into the things you're already doing, find small changes you want to make, small bugs you want to fix, maybe that you don't want to spend the time doing it and have the agent do that for you where you can reason about it really easily. I think as you do that, you'll start to find what works really well and what doesn't. And so that sort of iterative process, you'll become more confident in making bigger changes. So it's sort of a natural cycle, I think. Building the confidence is something that is important. So I would start with tasks you already know how to do, right? And so that you can very quickly compare the result of the agentic work to what you would have done. yourself and like, you know, build that confidence. Oh, wow. This is actually working really great. And, you know, and, and, and slowly but surely expand, you know, to all the capabilities of these energetic flow. Um, but yeah, I mean, try it is really the first, you know, great advice we can say cause it's, it's really fantastic. That's a great point about like bringing in your experience to working with agents is invaluable. So if you have like lots of industry experience, like that's huge, it makes such a big difference. And like to drum's point, like some of the first times sometimes you use an agent, you might as an experienced developer look at it and be like, that's not what I would have done. But what's great is they love to learn. And you can direct them and guide them. And they're like indefatigable about like all the advice that you can give them, all the guidance that you can give them to kind of help shape the way that you, the kind of code you want written, the architectures you want, the validation loops that you want, and they'll just keep doing it and keep learning. And I think that's, again, that experience is invaluable. Yeah, you can teach the agent that experience you have to make you even more comfortable. You can tell, hey, this is the way I work, and I want you to help me keeping that work the same. There's no one way to use these tools either. There are many people who use them just as a very powerful find tool to help them create the plan of action for what they do. That's a totally valuable way to use these things. If you're looking at this stuff and you go, I'm not sure I like this because it's surrendering a kind of control I'm not comfortable with surrendering at this point, then you don't have to. Just use it as a planning aid and see where that gets you. And if you like that, experiment with some other stuff over time. If you don't, no harm. I think that that's one of the coolest things here is that this is adaptive in a way that other technology traditionally hasn't been, and it can really become whatever you need it to be. I think the thing that a lot of a big misconception, I think, when working with agents is that you're handing all the control over. Actually, it's really important with agents, as you were talking about, Kevin, that you don't disconnect. Like, in fact, you should be you should be reviewing all your changes. You should be working with the agent and using plan mode to be able to determine that its implementation details are correct. I want to highly recommend a session that came out this year called Xcode Agents and You for workflow ideas. It talks a lot about exploring or exploring a project or exploring new features as a way to use agents, as well as building, refining, or orchestrating multiple subagents to do something like translation. All of them are really great ways to use it. And as Nathan said, you don't have to do all of them. You can just choose which works best for your workflow. One more thing I would say is I think there's both kind of a way to come at it from the top and a way to come at it from the bottom. What I mean by that is I find that working on just engineering problems in general, sometimes starting with a low fidelity, like a really coarse grain look at a problem is really helpful. Like I had a colleague who had always asked me, write your header files first. And that just let me think about the shape before I actually wrote any lines of code. So you can start with the agent. Just like, give me the shape. Like, let's just talk about your Swift interface, you know, equivalent. Or you can kind of go from the other way where you're like, I know the shape that I want because of all my experience. And I know I want protocols here and these classes here, et cetera. And then you can have the agent kind of work in the like, it has so much context at that point of like what the function is and how it fits in with the whole scheme. It can kind of like just implement the body and you can like review that. So either top down or bottom up is two different ways to approach it. Absolutely. All right. Hope that answers your question, UJ. I know we probably could have spent another 20 minutes talking about this. We do have several other questions. We have one from Pichaya TryYS again. What are the key differences between agent mode and chat mode? I successfully connect to Xcode to the local LLM with MLX LM server in chat mode following example from WWDC 26 session. But the result is much different from the coding intelligence demo from our other WWDC 26. Yes, it will be. So this is absolutely true. So the difference between that chat area in the settings and the agents area that we sort of floated up to the top is really capability. Because in that chat mode, we do give the agent a few tools to call to do things on your code base. But it's on the order of 10 to 15 things that it can do. In the agent mode, the number of things that an agent can do is basically infinite. It can do anything it wants if you let it, right? It can use command line tools. It can use almost 60 tools inside Xcode now. We give it all sorts of capabilities there that it wouldn't have otherwise. And these agent wrappers that sit around the model and give it other superpowers are super important as well because they let it manage its context. And they let it spawn other agents and all of these things that as you get more experience working with them, you'll find more and more useful. A couple of the agent integrations that are already in Xcode sitting in the UI are open source agent integrations that actually encourage you to try using with open models. And they have documentation on their websites or in their GitHubs that explain how to configure it. In the Xcode settings, you can select the agent name and then go to the dot, dot, dot, and it says set up with configuration file. And then it will point you to the configuration file. You can just paste in the example from the documentation. You can also use ACP mode, which is any agent, basically, that you can find information about. You can set up four local agents as well, one of those. And some of those are designed specifically around being really, really great with these local agents. So, I mean, the capability of the agents is just so much more. You'd be a great person, Nathan, to tell us the difference in scope of code completion, like predictive code completion, chat, agentic. What's happening at each of those? The time horizon that they work on goes way up, and so the capability goes up. This is my favorite question, actually, because this is something that has really been staggering to me. Because I remember when the predictive code completion stuff was starting and we were working on that, I remember thinking to myself, this could be kind of a big deal. I way underestimated how big this was going to be because when we did that, we were saving you maybe two, three, five seconds at a time. Pretty good. But then when we added this chat stuff, that became it can go for 30 seconds and find an answer for me and that's the right answer and make some code changes. And a year ago when we started experimenting with this agent stuff, even six months ago when we started adding the agent integration you're now used to in Xcode, it was a half hour that you could get out of an agent sometimes. And now it's an hour, an hour and a half, even more sometimes that an agent can work independently doing a lot of work for you so that you can get to an ultimate conclusion. It doesn't mean it has to, but it can. And that's just not possible with that chat feature. That's not really what it was aimed at doing for people. So you're going to get a very different experience when you use these agent modes. We really want everyone moving from chat to agents, and now is a great time to do that with Xcode 27. Because if you want 30-second mode, it can still give you 30-second. It does all the time. Agents can do the small things, too. Exactly. All right. We have, I'll say, two questions. They're related to each other, both highly voted. The first one is from Interferon. I prefer to use local models instead of cloud models. If I use a local model with Xcode instead of a cloud model, what features do I miss? Will I just get slower? Will it just get slower or maybe less accurate answers? Or are there whole agentic features that are not possible with local models? Well, there's two things, right? They're the agents that you run and the model that it talks to, right? And somehow you can mix and match, I want to say, right? So from the very beginning, I think in Xcode, we added the capability to talk to local, and local being on your own machine or on a local server. If you have a bigger Mac, for example, you can use tools to run the model here and plug Xcode basically to talk to those models. So if you're just using the model, the chat mode with the local model, well, you will get the chat experience. Now, those local models are becoming really good, right? And so we get probably great results, but there will still be chat mode results. It's coming that way, right? Now, if you plug an agent, you know, and they're open source local agent that you can use, plug them to local model, you can totally do that. And you will get a lot of those agentic tools using the local agents and the local models right here. - So essentially, kind of, if I were to TLDR that, Because of ACP, it sounds like the tool set that Xcode provides, so all of the tools that are provided for our Claude Codex and Gemini agents, if you are using ACP, all of those same tool sets, that same tool set will be available to a local agent. Yeah, absolutely. The same tool set will. The biggest difference is, of course, if a commercial model provider is going to give you a model that is so big it has to be hosted on a really powerful GPU in its own special cluster that they have somewhere, you're not going to get the same super genius on your MacBook Air. It's great, but you're not. And that's okay, actually. You can get a lot done with this stuff now. The things that you can do with our computers are mind-boggling to me. It just means that you have to give it more guardrails. Make sure that those validation steps that we were talking about before are really pristine because those are going to be the things that it's able to keep itself on track with when it's not quite as smart. Yeah, and as a follow-up question, we got a question from Pachaya, TryYS, around the same thing. Is it possible to connect the coding intelligence to a local LLM like the one hosting an MLXLM.server command and an agent not in the chat mode? So that it would be more capable to handle stuff in Xcode without pointing file to file. And as we just said, ACP support, that's basically how you want to approach it. And there are many open source tools and wrappers available with local model support like OpenCode. And I'm really excited for ACP also to be used to help other enterprises as you have your own configurations. Regardless of what harness you talk to on the back end, ACP is a great way to get all those inside of Xcode and working for your enterprise. All right. We're going to move on to a question from Antscrashing. Great username. What can you tell me about the privacy of the code of my app when it is accessed through a third-party LLM via Xcode? Will the LLM be able to train on my code base and queries? Will it be able to store data short-term or long-term? This is a great question. Yeah. Well, so, you know, when you enable a coding agent and a coding model with one of the partner we have, you will see their, you know, terms and condition or how they use your code. And you're always in control of, you know, choosing if you allow the agent provider to use your code for training or not, right? So it's very clear here, you know, and the way to do that is going to your account and, you know, just in the settings of the model providers tells what you can and cannot do with the code you provide. It's the same for, you know, Chad and Agentic here. So you're always in control of what the model provider can do with your data. That's really important from the beginning when we start creating this feature. - And agents in Xcode, Apple doesn't see any of that. That's all through the model provider that you use. - Yeah, there's a direct call to the agent provider. - Exactly, yeah. - It's by design that's how we build these features. - Yes. - All right, so as a kind of a quick summary for you, Ant's crashing, definitely check your provider for its privacy policies. Check out your accounts for the subscriptions you have for these providers and see what kind of control you have to be able to limit the data that it uses for for training but as for Apple Apple does not see anything in as it's sending these messages as it's sending these requests all that data is sent directly to your provider with the one caveat that if you send us a feedback report saying when I write this it doesn't work we will see the thing that you told us you wrote. - Yes, that's true. If you click on the Feedback Assistant button, we will see that context. - Yes. - All right, great. Moving on to, man, these usernames are fantastic. StuffMC has a question. What's the best way to work with AI in Xcode while being offline? For example, in a train while commuting and without having an M5 Pro with 128 gigs of RAM. You kind of mentioned a little bit about this, Nathan, about providing guardrails a little bit more. But do you have any other suggestions? First of all, the best way to get one of those models running and get the most out of it is MLX. And there's a reason we have a whole session on how to use MLX in this context. You can get a larger, more interesting model running with MLX than any other technology on our devices. And I really strongly recommend watching that session and getting started with that. The next thing, though, is it is all about the guardrails. It's all about the constraints. And you'd be surprised how much you can accomplish on your laptop on a train if you make sure that the agent has to pass unit tests to move on. And you write good unit tests with the agent all the time, then it can't lie and cheat its way out of a situation if it happens not to be smart enough to figure it out the first time. It can keep working until it finds the solution, and it will find the solution. And I think if the offline is temporary or you're going on a commute or something like that, sometimes you can combine the two. So you can use a larger model before you know that you're going to be offline to help with planning and requirements and setting things up. Then you're offline for a number of hours, a number of days, and have those local agents document all the assumptions that they make. Then when you're back online, you can use a large model to double check that those assumptions that were made all along the way actually match up. Yeah, and this is like a very exciting area, sort of ongoing research from a lot of our partners is the idea of using larger models to advise agents powered by smaller models. You can get a lot of that functionality and benefit just by asking agents to write things out to mark down files and then critique each other. And then they can talk back and forth and find things out. And Xcode makes it very easy to even run that simultaneously. It's a great feature of Xcode to be able to configure multiple agents and model and just start a new conversation with different agents and models. So you can switch when you're offline to a local version of this and then go back to the other one when you're online. I wanted to point out, Nathan, you mentioned a session that would be great to watch. I believe the name of the session is Run Local Agentic AI on Mac Using MLX. is the one you can take a look at. Thank you. No problem. All right. Moving on to another question from Jay Rodin. I've been using Claude Code in Terminal for quite a while now. I find that I barely need to use Xcode anymore. What am I missing? Go ahead. Yeah, no, I think one of the things that, I think one of the things that's really important is everyone's going to approach using agents in different ways. And there's different kinds of experiences. And so I think the thing that we have built in Xcode is both a set of really powerful tools, and we've built a great user experience on top of that. One of the things that's really great about our user experience that we're trying to really invest in is the difference between kind of like a nonlinear flow. A terminal is just a lot of text flying by. It's also very linear. So you're understanding the story is kind of like unwrapping in that linear fashion. What I love about Xcode is that we try to pull out the bits of the story that are happening into the kind of new artifacts area next to the conversation. So you can see the evolution of the change kind of unfolding. You can, you know, click around, edit source code, et cetera. And then there's all of Xcode's context. So the actual in-memory context of having the files that are open, the schemes that you have active, all that is information that we use to help you as you're working. So even natural language things like, oh, this and that, it's just very easy to point to what you're working on. Currently selected, what your project settings are, things like that. Yeah, Isco is not just a source editor that can run things. It's an ensemble of tools. You have instruments, you have all the previous system, you have the device hub now that the agent can control. And so when you put all those tools together, it really supercharges the developer experience, given tools that are not possible to use in just the plain text view of the terminal. - Yeah, I think the idea of you being able to write a great prompt is a practice that everyone's doing now, especially with agent workflows, but to then also back it up with the entire context that Exco can provide about your project, about what get history or crash data, things like that, I think it just really benefits. It makes that first solution really closer to what you want to achieve. Yeah. I think also, I mean, a lot of it depends on how you want to work, right? Like, it doesn't have to be all or nothing either, right? Going back to terminal sometimes, maybe that's the right answer. But when you're in Xcode, you get a really visually rich experience. You get richly rendered, beautiful markdown. You get previews. So you get to see the results in a very different way than you would get just in a regular terminal. With amazing color seams as well. With great color seams. Great color seams. Beyond the war. All right. We can get a few more questions in before the end of today's group lab. So let's go move on to Jack92's question. Is it possible to use local AI models for coding intelligence with XCO27? We talked a little bit about this. What would your suggestion be to balance speed, accuracy, and privacy? So kind of going for the first question, again, watch run local agentic AI on the Mac using MLX. That's the best way to approach it. But I think the interesting part that we could add here is what would you suggest to balance speed, accuracy, and privacy? We talked a little bit about some solutions to that, including using the larger model first for planning and then have the local smaller models maybe keep track of its work or assumptions. Yeah, I think part of it is there's a lot of local models, and they all have different quantizations, floating point, et cetera. Part of it is kind of see what works for your project. Absolutely. It could be totally different. Yeah. We spend a lot of time trying to figure out how to assess that we are giving agents the right tools to do their jobs effectively, that when we provide them with additional context, it's helping them and not hurting them, things like that. So we've become very experienced in benchmarking these agents and models. And one of the things we've learned along the way has been that that gives you really powerful signal. And you can go online and read all sorts of spreadsheets that people put together of every variation with every letter of the alphabet combined in a very long name of each variant of these models. But the thing that ultimately is the determining factor of how you are drawn to this stuff is the vibes. It's how it feels to use. So the best way to figure out this balance for yourself, if you're picking which kind of agent you want to use, which kind of model you want to pair with that agent, whether that's from a commercial provider somewhere or it's local on your machine, is giving it a shot and seeing if you enjoy it and if it's giving you things that you want to use. I think a common pattern, too, is that you can develop your own kind of like scorecard. Like there are things that are really important to me that, you know, in my project that agents can, you know, or different models can get wrong. So I can develop this like scorecard and then I can run through, you know, local models as new ones come out, try different settings and just see for my scorecard, how are they doing? And it doesn't have to be something that's like super scientific and has a bunch of numbers behind it. It can be like Nathan said, just like vibes of like, oh, this one felt the best. It enabled me to feel the most creative and to work the fastest. - Yeah, and if you become a person who's really into this stuff, you might find yourself asking the agent to help you create something that's like a mechanistic scorecard that you can reuse and then you wind up chasing, well, what do the vibes I felt correspond to in numbers and stuff like that? But yeah, just get started and see what you can feel out about what you want these tools to do for you because they're so personal. - And maybe another thing would be, it's not always necessarily true that the bigger the model, the better the results. - Definitely not. - Like sometimes it's actually good to check extremes of like, okay, I used all this memory to load this model, but it doesn't actually give me much better results or even any better results than something that's much, much, much smaller. It can dynamically change and have multiple models on your Mac and swap them. Or swap them depending on the tasks that you do. Exactly, yeah. Yeah, absolutely. Another kind of related question from Ran Learns. I don't want to give access to Anthropic, OpenAI, or Google. For privacy reasons, is there a path to use foundation models as the agent for Xcode coding intelligence? I think it's a lot of the things we've already been talking about like models local agents Yeah run local agentic AI on the Mac using MLX sessions It's exciting to hear all the excitement about this The Mac is a great place to do this Yeah, absolutely Like on just an M5 Mac it's pretty powerful already If you have an array of Mac studios You know you could have one of the largest models on it So absolutely definitely try that out Okay, let's take a look at a couple more questions. We have one from C. Prada. Is there a beginner's guide or similar document that gives an overview of this topic that we're talking about as opposed to tutorials for those of us who need a general map of a subject that they can fill in after with details as opposed to jump in the middle of the subject hands-on approach? So yeah, if someone wanted to try to figure out how to approach it or like a good roadmap how to approach using agents rather than just trying it out as we've been suggesting. If you're a visual learner, one of the things that's really cool about the session we keep mentioning, this Xcode Agents and Use session, is that there are lots of very illustrative diagrams of what is the agent actually doing right now that's giving it an understanding of what's happening. And when you start to sort of break down into pieces what it's doing and understand what's happening, that's a very powerful thing. So I really do recommend that session a lot. I don't know, do you have suggestions for the resources we provide today for this sort of thing? I think just talking to folks is a great way to learn, too. I'm, like, constantly learning things from, you know, like Nathan and Ken and Jerome. Things that they're trying or, you know. Yeah, talk to other developers. How they're using it, exchange, you know, the best practices. You know, just give it a try. And I also feel like don't overthink it. it's also like it can you know sometimes you can feel overwhelming because it's changing so rapidly and so fast um but because it's changing rapidly and so fast there's also like there's just a lot that you can discover and it's okay like you're there's a lot of great kind of initial groundwork that we've done you know in our tools and and the model providers have done to make it seamless to onboard yeah and while i think we generally have approached it by saying like just try it uh one of the things that you know it's really really great about the way it's integrated in xcode is that can try it without as high of a risk or impact on what you're building. I always talk about plan mode because there's plan mode in lots of places. But plan mode really allows you to ensure that you know exactly what it's doing, and you could ask questions. You made this plan. How did you actually approach this? But yes, Xcode Agents and You does do a really great job in that session to walk through, this is a prompt, this is what it's working on, but this is also how it's working behind the scenes. Really great way to approach it. One, going back to an earlier question, I mean, this kind of reminds me, one of the values of staying in Xcode is that you get that choice of, like, how much you want to buy in to the new workflow. You can just do a little bit. You can do a lot. So as you're, you know, new to the experience, I think it's a lot less disruptive than if you were to just go and be all in on terminal, I'm going to totally change how I do things. So I think that you have a much broader continuum of how you can work with it. Yeah. And I would say maybe one other thing, too, is the community has a lot of great resources out there. And one of the things we've worked really hard in Xcode 27 is that the way that you use agents in Xcode 27, there's a lot of transfer from other places that you use them. So if there's other techniques or things that are happening in other IDEs or other tools, Generally, those are just going to transfer just fine in Xcode 2. So it doesn't have to be that it's only about look for resources that are about Xcode specifically. Just look in general, and you can do those techniques inside of Xcode with Xcode 27. I was going to mention documentation for the agent providers is a really great way, or how people are using agent providers currently. And again, one of the cool things is that there's not a single right path. You're not playing Mozart, you're playing jazz. And you can sort of figure out what's working for you by borrowing from everything you hear. What a great quote. You're not playing Mozart. You're playing jazz. And kind of related to that, Kevin, you were mentioning, models are changing all the time. Best practices right now might be different in the future. So it really is about trying it out and seeing how much you want to buy in or just testing things out depending on what you want to build. I mean, every time a new model comes out, they literally change. The best practices change. So you have to sort of be aware of that. Maybe there's a new one where we're actually talking. Could be. Yeah, I know. All right. I think we have time for one more question. Let's see which one we could take. Actually, I wanted to add a question that we got in a previous group lab. I think we had a coding intelligence, Apple intelligence group lab back in Tuesday evening here in Cupertino. And there was a great question around how do we make sure that the most up-to-date APIs, like the things that we announced at DubDub this year, that agents are actually familiar with this. We talked about it very briefly, but I wanted to make sure that we say it out loud in this group lab. What's the best way for new APIs to be in the agent's context? Yeah, so we have a whole tool that's dedicated to being able to look up new APIs and documentation. So we have awesome teams that develop our amazing documentation for all of our new APIs. And then we've provided tools for Xcode to be able to search through that documentation. And we've experimented with a bunch of techniques to help make that as efficient as possible so that you always know that you're getting the latest APIs. When you download Xcode, you also download the latest documentation. I was going to say, it's on-device. And now it comes in the version you can read, but also versions specifically for models. to be very efficient, to be very fast, and give you the best answers. And so the agent, when he doesn't know about an API, will actually tap into that documentation and get all the resources from that documentation added to the context that now it can help you with that. We're also shipping Xcode with a set of specialists, skills that we build. For example, there's one, the new resizability feature that we're shipping in iOS 27. And so we're going to help you when you ask this question of building this new API. The agent will bring that skills and have new context and new ways to build those features. So, yeah. The other thing is, if you don't have confidence in this yet, just give it a shot. Create an empty project and ask the agent to demonstrate a new set of iOS 27 APIs for you. I think Foundation Models is a great choice here, actually, because there doesn't happen to be one of these specialists for it. And part of that is because it's so good at getting that information from this documentation index and working with it. They've done a great job on the documentation team of giving us what we need to be able to make that happen. Yeah, and another thing else, too, is you can always ask for, like, search documentation. Use documentation. Or there's a new API in iOS 27 about this topic. It would actually directly ask the model to go to the documentation. So I guess don't feel shy about asking the agent to use these tools. Ask the model. Ask the agent. I think in particular, as we were talking about models changes, providers change. What's great about Xcode providing this documentation tool is that regardless of which provider you're using, whether you're using a local model or, say, Claude Codex or Gemini, you are getting that information. Xcode is providing that to whatever agent you're using. So if the agent isn't up to date with the APIs because we just announced it, Xcode's got your back on that one. And the great news is the documentation ships as an individual asset, right? So we're going to update documentation as new APIs are coming, and you will get that automatically as a new download in Xcode. That's a great point. Well, what a great way to end our group lab. Unfortunately, that's all the time we have. Thank you to my panelists, Nathan, Kent, Jerome, Kevin. It's so great to have you here. to answer questions, give your insights. And thank you to the team behind the scenes for helping triage the questions and keep this event running smoothly. And of course, thank you to all of you who joined us, whether you asked the question or just tuned in. It's great to have you, and we are so privileged to be able to host this for you and answer questions for you today. If you didn't get your question answered, check out the forums, developer.apple.com slash forums. And you could also check out the generative AI search experience in developer.apple.com. to learn more about what we talked about today. If you have a code level question, bug, enhancement request, please submit in feedbackassistant.apple.com. Again, thank you for joining us. Have a great WWDC.