AI is everywhere these days. It’s difficult to go a day without hearing something about AI or LLMs. Google searches now include AI overviews, and free services pop up regularly with new AI interfaces to accomplish various tasks. Users can generate images, make art, make music, and, yes, even generate code.

If there’s one thing that history has shown, it’s that ignoring new technology won’t make it go away. More importantly, the early adopters of major advancements tend to pull ahead in related fields.

How You Shouldn’t Use AI

Still, I think it’s important to recognize that what we know as “AI” right now is not true artificial intelligence. We’re seeing exciting new technology that opens up a lot of new possibilities, but it is limited. At this point, most of us have that one friend (or more) that uses AI for everything. While I appreciate capturing the value of tools like AI as much as any tech geek, modern AI is weak when it comes to making decisions within a broader context.

“Building apps in Swift and SwiftUI isn’t quite as easy for AI tools as other platforms, partly because our language and frameworks evolve rapidly, partly because languages such as Python and JavaScript have a larger codebase to learn from, and partly also because AI tools struggle with Swift concurrency as much as everyone else. As a result, tools like Claude, Codex, and Gemini often make unhelpful choices you should watch out for. Sometimes you’ll come across deprecated API, sometimes it’s inefficient code, and sometimes it’s just something we can write more concisely.” — Paul Hudson¹

When it comes to iOS development specifically, what does this mean? It means that AI is excellent at pulling from existing references and resources, known APIs, etc. to create code that compiles and runs (usually) — but that code might not be what you actually need. It may not solve your reported issue, it might be out of date, use deprecated code, use unsafe practices, miss key elements, and so on. To put it simply, don’t trust AI to do your job for you.

Some of you reading this will think to yourself “well duh,” but there will be just as many people who balk or question this statement. “Vibe coding” has been an increasingly popular approach to software development, and while it may have good use cases in my opinion it’s an extremely dangerous path. To be clear, this is not an old man shaking his fist at new technology; rather, this is someone who has already seen vibe-coded apps and features break down and require additional developer time to debug and fix what could have just been written correctly the first time.

A phrase I’ve heard tossed around in software engineering circles is “treat it like a junior developer.” I agree with this sentiment to a degree, but the mindset here matters. It’s important to think about the broader implications of that idea. If you treat your AI tool as a junior developer, that makes you the senior developer. With that comes a few important qualifications to the practice:

• Never ask the AI to do something you don’t know how to do yourself. Why not, you might ask? Well, how would you know if it was done correctly? How would you catch critical mistakes or issues in the implementation? You wouldn’t — and you won’t.
• Review any code an AI wrote as you would that of a junior. Scrutinize it, think of how it fits in the greater context of the architecture, look for common mistakes like memory leaks, redraw loops, etc.. Build it and test that it does what it claims to do.
• Don’t assume or trust that the AI knows the right answer or that it knows something you don’t. If you read the code and your initial thought is “wait, what?”, it’s probably best to be more thorough in your review.

All this to say that the code should be treated as suspect. Because of this, in many cases it might be more time efficient to just do the task yourself.

It’s worth noting that even those companies that have openly embraced vibe coding may be more conservative behind closed doors than their public announcements suggest. Builder.AI, for example, promised a platform that could create apps using vibe coding with no specific expertise required. However, after the company completely collapsed financially (from ~$1.5 billion in value to ~$0), it was revealed that they were using cheap programmers to do the bulk of their coding grunt work, rather than AI. So even a company that wanted to embrace vibe coding found that it was lacking and that they needed human input and developers to finish the job.²

How You Should Use AI

With all that being said, how should we use AI? I’ll be honest, when I first sought to answer this question I found it far more nebulous than I initially expected. I asked around, and for every four developers, I got five answers. There were, however, a few consistent themes in the responses. I’ve come to realize that how (and to what extent) devs use AI is a fairly personal decision, but the bulk of the uses fall into a few categories.

“We can ask it to help break down the problem if we want. We’re still breaking down the problem, we’re still finding the pieces. And so now I actually use AI all day long. I have copilots from GitHub inside of Xcode. … [O]ne of the complaints people have about that is it can’t do like whole apps or like whole views or stuff like that. And I actually like it that way.” — Donny Wals³

Efficiency

The first category that came up regularly was efficiency. AI can look at your project, recognize patterns, and create boilerplate code for you. It can also expand existing patterns if there is a lot of repetitive code required. A good example would be if you need to add another REST API call to your app, you could ask your preferred AI companion to generate the new API based on your existing patterns. You just saved yourself maybe 10-15 minutes of work.

What about a simple SwiftUI view that doesn’t have any special behavior or requirements? AI can do that for you. Need to refactor some old UIKit into a modern SwiftUI view? Probably not an issue. You can even ask your AI companion to review blocks of code for readability, potential risks or bugs, etc. It’s fairly helpful in this regard and can catch things you might overlook.

Additionally, if you use scripting in your development workflow, AI is great at that. The existing documentation and examples for scripting languages are massive compared to that of Swift/SwiftUI, so the AI has a lot more rabbits to pull out of its proverbial hat for that application.

Here’s an important note on all of those uses: Always double check the AI’s work. Again, treat it like a junior developer. It can recognize and copy patterns, but as I mentioned before it doesn’t understand context. The code might work, but make no sense in the broader feature or architecture.

Tests

This one is huge for me. We all love unit testing and the multitude of benefits it provides during large projects. But if you’re like me, you don’t necessarily like taking the time to write unit tests. They can bog you down a bit, and can interrupt your workflow if you’re working on a big task.

This is definitely a place where AI can help. Ask it to write unit tests. Be specific in your prompt for what your expectations are and what you want to test. Let AI generate the bulk of the test, then go in and fine-tune it to your specifications. This is a huge time-saver, and you get the benefits of unit testing-driven development. In addition to writing the tests, you can ask AI to check test failures and quickly identify the cause of the failure. This can be a wonderful tool to save you debugging time.

“Swift Assist serves as a companion for all of a developer’s coding tasks, so they can focus on higher-level problems and solutions.” — Susan Prescott⁴

Debugging and Code Evaluation

Tools like Claude, Cursor, and Copilot can be great for debugging and code review. You can ask the AI to look over your code for any issues, and it will find them. In fact, it will almost always find something. A lot of the time it’s wrong, but it’s also often right, and it can be a wonderful tool.

However, once again, it’s very important to remember that AI doesn’t understand context. It can’t see the bigger picture or understand the overarching architecture of your project. Keep this in mind when you read its feedback. It’s OK to tell the AI when it’s wrong and ask it to remember that, and it’s OK to reject suggestions that would be problematic in ways the AI might not see.

In short, use AI tools to get feedback, but take everything the AI suggests with a grain of salt and carefully consider what its suggestions might do in the broader context of the codebase.

Accessibility

This is a great use for AI, and it supports a best practice that I know many of us sometimes overlook. It can be very easy to write your code and create your user interface without thinking about accessibility features, especially if they don’t affect you directly. This is a workflow you can add to your AI — have it check for missing accessibility features. My AI has called me out on this a couple times, and my only response was “Oh yeah, that’s a good idea.”

Final Thoughts

AI has a wide range of tools that can make a senior developer’s process more efficient and their code cleaner and more polished. It allows us to spend less time doing boilerplate and setup and more time fine-tuning and making cleaner, more robust architectures.

If there’s one major takeaway from this discussion, I would say it like this: AI is a new suite of tools for engineers, not a replacement for them. Everything an AI can generate requires someone with genuine knowledge, expertise, and understanding of the requirements, the broader context, the target audience, etc. to bring the project home.

Never be afraid of using the newest, greatest tools. Anyone who rejects AI tools outright is very likely to fall behind at this point; but on the other hand, anyone who thinks AI is a replacement for an engineer who can provide the informed analysis on the project will find themselves tying their own hands.