Generative AI has changed software development in a real way. Large language models are good at human languages, but they’re even better at programming languages, which have smaller vocabularies and fewer ways to combine words. And because code actually does something, running it tells you pretty quickly whether it works.

The result has been a democratization of development, similar to what desktop publishing did in the 80s and 90s. The Mac and PageMaker let almost anyone produce a newsletter or brochure, but they didn’t turn everyone into a professional designer. AI can now produce working software for people who couldn’t have written it themselves, but generating code is only part of building something reliable.

If you have a repetitive task that’s too annoying to do manually but doesn’t warrant hiring a developer, tools like ChatGPT, Claude, or Gemini can help you create an AppleScript, shell script, Mac or iPhone app, or even a full web app. That said, there are real pitfalls to watch out for, and you’re ultimately responsible for what you build.

What Could Go Wrong?

There are two broad failure categories in AI-assisted development: problems with the development process itself, and problems with the finished product.

Modern AI tools have moved well beyond basic chatbots. They can look up information, modify files, write and run code, and interact with apps. That makes them powerful, but it also means they could accidentally change or delete data, expose confidential information, or introduce a security vulnerability.

On the finished product side, a local script could run but produce wrong results, fill up your drive, overwrite important data, or cause crashes. A networked app could generate excessive traffic, leak confidential data, or open a door into your network.

Take AI Development in Steps

Professional developers start with simple tasks and work up to more complex ones as they gain experience. With AI handling the programming, it’s tempting to jump straight to a full-blown app, but starting small is much safer. Here’s a reasonable progression.

Read-Only Experiments

The best starting point is data analysis: things that would otherwise require complex spreadsheet formulas, parsing large CSV files, or comparing exported data. It might not feel like development, but when you drag files into a chatbot and ask it to analyze them, it’s usually writing and running Python scripts behind the scenes.

The possibilities here are wide open. You could analyze an event registration spreadsheet for trends, get a plain-English summary of a massive log file, or compare two differently formatted CSVs to find overlapping records.

This is a great place to start because nothing you do changes the original data, and errors are usually easy to catch. That said, incorrect results can still look convincing, so compare against known examples, verify totals, and spot-check the underlying records.

Local Automation Scripts

The next step is local automation via AppleScript or shell scripts. You could build scripts for batch-renaming files, creating calendar events, manipulating images, or reformatting HTML files. If you’re unsure how to run a script, just ask the AI for instructions.

Because scripts can modify and delete data, you need to be more careful here. When possible, have the script create new output rather than modifying the original. Otherwise, work on a copy and ask the AI to:

• Flag risks or ambiguities in your request before doing anything
• Preview exactly what it plans to change
• Wait for your confirmation before acting
• Log what it changed
• Record enough information to reverse its actions if needed

Standalone Mac or iOS App

With AI and Apple’s Xcode development environment, you can now build native apps for your Apple devices. Setting up Xcode is involved, but an AI agent can walk you through most of it. When you get stuck on where a particular control lives, paste a screenshot into the chat and ask directly.

The potential here is genuinely exciting. You could build an injury rehab tracker, a publishing production checker, a custom document converter, a specialized camera app that tags photos with metadata, or really any workflow that’s currently awkward or doesn’t quite fit an existing app. Mac apps can be shared by copying the file. iPhone and iPad apps need to go through Apple’s TestFlight.

For personal or internal use, focus on reliability and data integrity. Ask the AI to build and run automated tests with every change, push back on anything that seems off, require automatic backups, and allow for manual data exports.

If you plan to distribute the app more widely, the bar gets much higher. You’ll need to think carefully about support, compatibility, privacy, and long-term maintenance. If you’re considering selling the app, make sure the licenses for any external code, images, fonts, or other components allow for commercial use. Be cautious.

Networked Systems

Networked systems open up compelling possibilities: an equipment checkout system, an event registration tool that goes beyond Google Forms, a shared inventory system, a document submission service, or a live data dashboard. But with that power comes real responsibility, especially if the system will be accessible over the internet.

Beyond app reliability and data integrity, you’ll need to think through:

• What data and operations need protection? Personally identifiable information deserves extra care. Authentication credentials, API keys, and other secrets should never live in source code, prompts, logs, or shared config files. Store them in a dedicated secrets manager and limit who can access them.
• Who can do what, and how is that enforced? Define user roles and limit each role’s permissions to only what’s necessary. You don’t want someone accidentally deleting the database.
• How do you handle hostile inputs and abuse? Attackers will test what happens when they submit malicious URLs, filenames, uploaded files, and unexpected inputs. Validate everything, limit size and complexity, and restrict how often users can trigger operations.
• How do you separate development, testing, and production? Once you go live, keeping these environments separate is essential. Mistakes in development shouldn’t take down the live system, and test data shouldn’t contaminate your production database.
• How will the system handle simultaneous requests and partial failures? Network requests can arrive twice, overlap, or fail midway through multi-step operations. These edge cases can lead to duplicate payments, registrations, or inconsistent records if you’re not careful.
• How will you detect and respond to attacks or unexpected behavior? Decide what to log, what should trigger alerts, how access can be revoked, and whether you can isolate a compromised component without taking everything down.

Before putting any significant networked system into use, assign a clear owner. That person is responsible for investigating failures, restoring data, updating dependencies, renewing credentials, responding to vulnerabilities, and eventually retiring the system. An unmaintained internal app becomes less reliable and less secure with every OS update and newly discovered vulnerability.

(Featured image by iStock.com/Boonyakiat Chaloemchavalid)