iOS Feature Implementation Using AI
AI-assisted, author-verified How this module was made
Welcome to the first lesson of module four. In this lesson, you will implement the review plan for the feature from module three.
Before we get started, let’s have a quick look on this feature plan. So basically, the plan file includes multiple sections, a summary, audience, goals, non-goals, what is not meant to be implemented, a user flow, and then there’s a UI plan, details how the UI should look like, proposed Swift service, files to be modified, and to a certain level of details. But the plan overall is meant to introduce a new section in the homepage or the first screen of the application, providing a bit more AI usage insights. Let’s have a quick look on the app itself.
Let’s build and run the application without any changes. So here is our app. It consists of three cards. The new feature we want to implement is a fourth card on the homepage and shows some details on the AI usage.
To get started for that, let’s see first if the plan is ready, or in a way, let’s ask AI what is the summary of the plan, what’s its status, and if anything missing in the app itself. Consider this as an initial setup.
Give me a brief explanation of the feature being implemented in the plan and point out any inconsistencies, missing information in the plan, or anything missing in the project that needs to be added before the execution of the plan starts.
Give me a brief explanation of the feature being implemented in the plan and point out any inconsistencies, missing information in the plan, or anything missing in the project that needs to be added before the execution of the plan starts.
Here we go. Let’s have a quick look on what the response on the readiness of the plan is. One, it’s not final. Two, no source data model matching what the plan requires. Three, no test target exists. No tie in the project existing deterministic date pattern. Provisional threshold may be untestable against real mock data. Fair. Names check out, but only partially. It does miss a number of points, and we are quite aware that the plan itself contains a number of open questions. So I want to have those questions also answered before we start with the implementation.
So what I will suggest to the agent is, one, give me recommendation for those open points, but first I’ll tell it to give me in this conversation each one of the open questions so I can give an answer to.
In this conversation, give me each one of the open questions to answer and document this answer in the plan to prepare for execution.
In this conversation, give me each one of the open questions to answer and document this answer in the plan to prepare for execution.
The minimum group I want is actually 10 and the aggregate fields, model names plus reporting periods only. This is suggested as the recommendation. Who approves? Product owner, which is me. Does the product owner approve the final V1? Yes, approve it as is. Send the answer for those four. And here is the remaining three. Let’s start.
“How should design present the neutral partial coverage note and information, insufficient data, no quality change states?” So for this one, my team gave me something slightly different. So here is the answer. Use neutral styling. Do not use warning colors, alert icons or error language. There we go. Next question. “Who owns the separate safety work on existing summary screen, individual rankings and causal language and what release gate applies?” The answer I got from my team was slightly different. Also, it’s not any of the recommended ones. So here it is. Work only on this new feature without removing the existing rows from the summary or detail screen.
For the final question: “After V1 is one representative model share shift sufficient, or is a richer distribution needed?” The answer I got from my team matches the recommendation, which is one is sufficient. Here we go. All three are answered and the send button was active. Press Send and let’s wait.
The agent recapped the answers for all the questions, mentioned also that it updated the review file or the plan with all those answers under different sections. But it’s also highlighting that there is still a number of open questions, as it mentioned in the very beginning of the conversation. No data model, test target or data anchoring.
I will instruct it that tests are out of scope currently as the next module will cover test targets in more details.
Provide a recommendation for each of the open points/gaps. Show me recommendations first to confirm it before moving forward. As for unit tests, exclude those from the scope for now.
Provide a recommendation for each of the open points/gaps. Show me recommendations first to confirm it before moving forward. As for unit tests, exclude those from the scope for now.
Here are the recommendation points, and I am going through them. In a way, they look acceptable. Since this is a sample project and a demo, I will not dig heavily or dig deeper into those answers, and I’ll just accept those for the current state. I will not give the green light for the implementation. I need to have a better understanding on what or how the implementation is going to look like. I will ask it to break the whole plan into something like tasks. I want to understand what are the dependencies, if different tasks can be implemented in parallel or everything depends on each other.
This can make a very big difference on how you’re implementing a feature. It’s possible to have multiple things implemented together in parallel by multiple agents running or just have them done sequentially. Let me understand a little bit more on that.
Build a detailed execution plan in a separate file for this feature identifying the following. A breakdown of standalone tasks for this feature. The modified files for each. A brief explanation for each task to use as a description to use for the task ticket. What tasks can be implemented in parallel and what depends on others? And create a small diagram.
Build a detailed execution plan in a separate file for this feature identifying the following. A breakdown of standalone tasks for this feature. The modified files for each. A brief explanation for each task to use as a description to use for the task ticket. What tasks can be implemented in parallel and what depends on others? And create a small diagram.
Let’s have a look at the provided plan. Scope assumptions, task breakdown. We have seven different tasks and here is the graph on how they look like. One and two are in parallel, and then everything afterwards are in sequence. And it also generated a Mermaid flowchart for those dependencies.
Now, ideally, you should take a look and better understand how things are going to be implemented. You can, for documentation purposes, based on how you work, your company, or if you want to be extra organized to actually generate different tickets from this information. You can ask for more details on each task if you would like. To keep things simple and short for this demo, I will accept those details, and I will also confirm that the earlier gaps and questions are part of this implementation file or this execution plan. If you’ve noticed, I did not confirm to document this information.
Document the decisions from earlier and the open questions in the execution file to have everything documented in one place.
Document the decisions from earlier and the open questions in the execution file to have everything documented in one place.
Here is the modification on the file. Those are the open questions, resolved decision. Everything is in one place right now. There are currently still open questions and which is a good call-out, so I will confirm the numeric threshold, and I will take note and confirm that this edition file is accepted.
[ON-SCREEN: confirm the numeric threshold (its value isn’t in the captions), then add this reply, around 10:53. The captions only give it as read aloud, so check it against the recording]
For the current open points, I confirm and it's accepted.
For the current open points, I confirm and it’s accepted.
The agent confirmed that all pending items are confirmed, updated both documents. The plan from module three now includes all the decisions. The execution plan contains more technical details on how the feature will be implemented, including the dependencies. At this point, the plan is ready for execution.
Before I start with the implementation, take note that there is a possible workflow to implement this feature. You can see from here, as I mentioned earlier, the task one and two can run in parallel, then three, four, five, six, seven, all in sequence. You can tell the agent directly to create a workflow for what you want to implement. Instead of telling it now directly, implement everything in this conversation, it will take first task, second, third, etc. The result can be identical. The workflow can create multiple sub-agents underneath, as if it can control a team on its own, but this can be a little bit more expensive than doing things in the same conversation. But if the changes are too big, the number or the size of the context might not be enough to accommodate for the implementation needed. You can experiment with this gradually yourself with smaller changes, but for the purposes of this demo, I will use this workflow, and I will instruct it accordingly.
Go ahead and start the implementation. Create a workflow based on the dependencies of the task, run parallel tasks when applicable, and create sub-agents where applicable.
Go ahead and start the implementation. Create a workflow based on the dependencies of the task, run parallel tasks when applicable, and create sub-agents where applicable.
The idea from this, or why did I create an execution plan, although it’s not detailed enough, you can iterate on this execution plan and consider it as something like a technical design document, where a principal engineer or a very senior team member from the team prepares everything, does all the studying, does all the hard work, prepares a document explaining how the implementation should look like, and the rest of the team can follow this instruction or this design document. With AI agents, you can use a powerful AI model to generate this plan and then instruct it to create a workflow with less sophisticated or simpler models to do the work. Depends on the complexity of the feature that you’re working on, it might pay off, or other times it might not be making a big difference. For this demo, I went ahead with the workflow.
When your current conversation is about to create different sub-agents, it actually generates the prompts to give, and gives each sub-agent the task it’s meant to execute. So basically, you’re only talking to one person. It takes care of the others that are spawned as part of this conversation, and it follows up when they’re done. You don’t need to engage with those sub-agents yourself. It’s not meant to work like this. Again, this can be very useful if the task you’re working on is substantial in size. If it’s small, it might end up being a little bit more expensive if you always do this.
The workflow finished. It did mention that T1 and T2 were implemented in parallel, and sequential chain from T3 to T7. It described the changes to some extent, and if you were paying attention as the workflows were running with each task it was building, it’s possible that you’ve seen a build failure in with T1 or T2, since both were working at the same time on the same code base. You might be asking, what if I want each task to be separate on a branch on its own, for example. That is possible, but let’s put this for the next lesson. I’ll show you a very nice way to achieve this.
So it did mention that there’s something on the preview, and let’s have a look. Here’s the SwiftUI file that’s been implemented with its preview. And so far it looks okay. But first, let’s build and run the app to see how everything fits together. Those are the original three sections. This is the new added card, and this is the information within.
So far, it looks good, but at the same time, I didn’t really dig deep into was everything matching the acceptance criteria, did anything violate the non-goals that were mentioned in the plan? So there is quite some work I need to take care of to ensure that everything was done as it should be. The plan was followed correctly, not the implementation itself. So it’s a matter of, did I do the right thing? Did I do the thing right? Most likely, the AI model did the thing right, but I need to verify that it was actually the right thing that was implemented or described in the plan file.
In the next lesson, I will run an audit on the application and the implementation to find was something not followed across the different sections of the plan. And for that, we will use a different application. It would be ideal to put all those code changes in a small Git repo, and I’ll explain this a little bit more in the next lesson. See you then.