iOS Feature Implementation Using AI

Hello, welcome to the second lesson of module four. In the previous long lesson, you implemented a plan to introduce a new feature in the Tokens Dashboard application. You also learned how to implement the feature using a workflow that was capable of spawning multiple sub-agents to achieve the implementation, and they were running in parallel.

You could also be wondering if tasks one and two were working in parallel, would they affect each other? When I was actually recording this demo, the conclusion of one of the tasks happened while the second one was still running and modifying code, which actually resulted in a compilation error when the task itself was trying to verify. It didn’t happen later because each of the other tasks from three to four were happening in sequence.

Why am I recapping all of that? I also mentioned that it’s possible to run multiple tasks in parallel, and there’s an interesting setup for that. If you’re using conversations in Xcode, they will all work within the same branch, and they will interfere with each other. So basically, if you’re running a conversation with Xcode, it will all be working on the same workspace or the same branch. So you cannot work on different tasks at the same time. In this lesson, I’ll use a different application called Conductor. You’ll find its link to download it in this lesson’s introduction.

Now, let me show you how it works. Basically, I have the project that was implemented from the previous lesson in a branch, and it’s all committed on a Git repo I’ve added already.

Now, the main feature from Conductor is every conversation I create is actually creating an isolated worktree. Usually, Git works as you have a repo and a branch. You clone the repo in one folder, and this is it. All the branches are working underneath. If you want to have more than one running branch at the same time, things get a little bit messy, but this is where worktrees come in. You can have the same repo configured once, multiple worktrees, all of them or each of them has an isolated or a different branch. Thus, you are working on multiple tasks in parallel.

What we’re going to do in this lesson, we will review the plan that was implemented in the previous lesson, and in each conversation, tell it to audit the implementation from or against one or two different dimensions. We will have three parallel tasks or parallel conversations running. Each creates a completely fresh branch, and all of them will work in parallel. One important thing to note that all of those conversations are completely isolated. They do not share context. It’s almost as if they’re running on different machines. It’s just on the same project, but nothing is shared. So this allows you in one way to simulate a team.

In Conductor, you can be working on multiple project, and on each project, you’ll be doing multiple tasks. That does not save you tokens, so please pay attention to that.

Let’s get started. The current conversation is against the default branch, and this is the name (origin/versions/1.0). However, this is not where I implemented the feature. So I will start a new workspace, and here I’ll choose the new branch or the branch where my changes actually exist. The branch that I have is called Demo2. I selected it. Here it is shown. The first part that I want to audit against is the Goals and Non-goals sections in the plan document. Let’s have a quick look. The goals of what is meant to be achieved from this plan and non-goals are the things that should not happen. This basically forms a set of guardrails.

The prompt that I’m going to give AI is, “This branch contains the implementation of the plan in reviewed-feature-plan.md. I want you to audit what is implemented in the last commit against goals and non-goals from the plan. Do not fix anything, but generate a new file with all the positive and negatives findings and suggest action items to take.”

  This branch contains the implementation of the plan in "reviewed-feature-plan.md". I want you to audit what is implemented in the last commit against Goals and Non-goals from the plan. Do not fix anything, but generate a new file with all the positive and negatives findings and suggest action items to take.

I don’t want to implement anything. I want to get this audit, and in the next module that will cover testing, we will take this outcome and see what are we going to do with it, whether we implement UI tests or take note in the future.

While this is running, I will create another workspace by pressing the same plus here. Make sure that the right branch is selected, demo two, and now for the next one. I will almost use the same prompt, but it will just instruct or point out different sections in the plan. So for this one, I wanted to audit against Proposed Swift Surface, Proposed added and modified files from the plan. And let’s go for it.

  This branch contains the implementation of the plan in "reviewed-feature-plan.md". I want you to audit what is implemented in the last commit against Proposed Swift Surface, Proposed added and modified files from the plan. Do not fix anything, but generate a new file with all the positive and negatives findings and suggest action items to take.

Let’s create the third workspace, confirm the branch, Demo2. For this one, I wanted to audit against edge cases and acceptance criteria in the plan. All of them are almost the same, just the difference in the titles. Create.

  This branch contains the implementation of the plan in "reviewed-feature-plan.md". I want you to audit what is implemented in the last commit against Edge Cases & Acceptance criteria from the plan. Do not fix anything, but generate a new file with all the positive and negatives findings and suggest action items to take.

I’ll let it do its magic, and while all of this is working, let’s have a quick look at what the plan is. In the previous lesson, we went ahead with the implementation. In this one, we want to make sure that things are followed. Something can be missed. There can be a bug. There can be a violation in something in the plan. So this is basically someone else revising what the first AI agent achieved, but with focus for each conversation on certain parts on the plan. I could tell the agent to just cover all of this and review against, like audit against the whole plan. It can work, but if the plan itself or the implementation was big, it may not be really focused, and it can be somehow superficial. And I’m saying this out of experience. Having things focused like this makes the AI agents more descriptive as they’re not going to be lazy, so to speak, with just a couple of sentences on a specific point. But if you give it a long input, they may end up literally with a couple of sentences per point.

So the first one was Goals, the second one was Non-goals. The second conversation was focused on the Proposed Swift Surface and Proposed added and modified files. Here they are. And here is proposed: add and modified. I intentionally skipped the UI plan. That will be covered in the next lesson within Xcode directly. I will not give spoilers on that for now.

The third conversation was focused on Edge cases and Acceptance criteria. Those are quite important, and the outcome from this will be definitely used in the next module that focuses on unit testing. I’m also skipping accessibility requirements because this will also be part of lesson three. Again, no spoilers. I promise you, it’s fun. Going back to Conductor.

The first one, finished. Let’s have a look on the highlights. It verified the rule engine. It identified a gap, that there were no automated tests, and that was intentional in the execution, as this, again, will be covered in the next module. It pointed out that preview fixtures are bypassing the builder. Okay. And the file is created in here.

The next conversation, verified against Swift surface, proposed added and modified files. Let’s have a look. Positive online file, all nine proposed Swift Surface Types are implemented. Biggest gap, no tests. Yes, that is true. Data-model gaps, a minor point, and the audit file is generated here.

The final one, which is the most important, no tests at all, mock data, medium gaps, information about the VoiceOver, positive findings, and here is the audit outcome. In the top right corner, I can press on this sidebar and it will show me modified files within this conversation. Here is audit-findings.md, audit-findings.md, and this one is implementation-audit.md. If I’m paying attention to the file names, I’ll see that this conversation named the file audit-finding. Here is also audit-finding and this implementation-audit. Not ideal, and this is my mistake, because if I push all those changes and merge them back in the original branch, I will have a clear conflict. I will lose track of which file was what. So I would instruct it to define the names or rename the file, or I may as well not be lazy and rename the file myself.

If your first idea was to tell the AI agent to rename the file, I’ll understand, but is this the right usage to use tokens for?

With the changes within the workspace concluded, I can start creating a PR. It can be a draft or a manual. Let’s go through this flow. Conductor created the PR for me. Here is the link for the PR. I had a permission problem. It sorted through it, and I start making this a little bigger. This area started to look a little different. If I go to a previous conversation, I didn’t create the PR. Files were staged. But this one is showing a PR is ready. If I go to a different conversation and let’s do a draft PR, it’s running. Just to see how things will look different. Now, I can start pressing the review button and it will review itself or start a new AI session to review the code changes. Without going into much details about PR reviews, which will be covered in a later module, let’s give this a shot to see how Conductor will handle this.

The draft PR in this conversation is created. UI is a little different. I still have the review button. I can switch the PR status to ready for review, if I want or when I feel that it’s ready. Going back to the active one. The review finished and provided its feedback. It is providing an important point, but as I mentioned, the VoiceOver, I’ll cover it in the next lesson. This is just to show you how the review works.

Right now, it’s not necessary to actually do it for all three conversations because they’re not really writing code. They’re creating a markdown file, and if you noticed how the review did, it basically recreated the audit to make sure that the audit itself is correct, which is a little bit of an overkill at this point. Feel free to automatically create PRs and merge them, and in the next lesson, we will cover the VoiceOver, and we will cover a couple of specialized skills defined within Xcode to review some parts of the application.