I built a native macOS app last night. My first useful one. Planned it, architected it, compiled it. Fifteen minutes from blank screen to a running application on my Mac.
I didn’t write a single line of code.
The plan
The process started with a detailed plan. I spent time thinking about what the app needed to do, the user workflow, the data model, keyboard shortcuts, file format compatibility. All the things you’d normally sketch on a whiteboard before writing line one. I dictated most of it while walking, cleaned it up at my desk, and handed the whole thing to Claude Code as a structured build document.
Then I asked Claude to devise a build strategy that used multiple agents working in parallel. I didn’t architect the wave structure myself. I described what I wanted built, and Claude came back with a five-wave plan: which agents to launch in each wave, which files each agent would create, and which API contracts they’d depend on from prior waves. I reviewed it, thought it looked right, and accepted it.
Here’s where it gets interesting.
The toolchain
The build framework was Swift and SwiftUI, targeting macOS 15. The development environment was Xcode, which Apple ships as a free download from the App Store. Swift Package Manager handled the project structure, so there was no complex project file to maintain. The entire toolchain cost nothing. Claude Code orchestrated the agents from the terminal, each one generating Swift source files that slotted into the package structure. When the agents finished, I opened the package in Xcode and hit build.
Five waves, thirteen agents
Wave 1 was foundation: three agents running simultaneously, one creating the project skeleton and data models, another writing utility functions, a third building the core UI component I needed. No conflicts because each agent writes to its own files. They ran in about three minutes.
Wave 2 scaled up to four agents in parallel, each building an independent service layer. File scanning, image processing, data persistence, format interoperability. Five minutes. Wave 3 brought two agents online for the view models, the brains connecting the UI to the services. Four minutes. Wave 4 launched three more agents to build all the views. Another four minutes. Wave 5 was a single integration agent that read every file, fixed type mismatches, wired dependencies and got the thing compiling.
Thirteen agents total. Five waves. Each wave launches its agents simultaneously and waits for all to finish before the next wave begins.
Why parallel agents matter
A single agent writing 25+ Swift files sequentially would take well over an hour. The parallel approach collapsed that to fifteen minutes. That’s not a marginal improvement. It changes what’s possible in a sitting.
The parallel approach matters for two reasons beyond raw speed. First, each agent gets its own context window. A single agent building the entire app would need to hold every file, every type definition, every interface contract in one context simultaneously. By wave 3 or 4, that context would be saturated. Important details from early files would start falling out of the window, leading to subtle inconsistencies and type mismatches. With parallel agents, each one holds only the files it’s creating plus the contracts it depends on. Cleaner context, better output.
Second, speed. A single agent writing 25+ Swift files sequentially would take well over an hour, probably closer to ninety minutes with the back-and-forth of compilation errors. The parallel approach collapsed that to fifteen minutes of wall-clock time. It also fundamentally changes the development feel. Fifteen minutes is short enough that you stay in flow. Ninety minutes is long enough that you go make lunch and lose the thread.
The result
The app compiled and ran. It wasn’t perfect. Some UI elements needed repositioning, a few interaction flows didn’t behave as specified, and the image rendering pipeline needed tuning. But the architecture was sound. The bones were right. Every keyboard shortcut was wired, every data model matched the spec, every service interface connected properly.
Several more rounds of refinement followed. Fix the zoom synchronisation. Adjust the state machine transitions. Correct a file handling edge case. Normal development work, except I was describing problems in English and watching solutions appear in Swift. The feedback loop was minutes, not hours.
For a polished app there will be more rounds of refinement. But the foundation is solid. The hard part is done. Now it’s just a matter of tuning.
Where the effort actually sits
The hard part wasn’t coding. It was thinking. Designing the right workflow, specifying the right data structures, anticipating edge cases.
What strikes me most is where the effort sits now. The plan document I wrote was more detailed than any brief I’ve ever given a developer, because I knew the AI needed explicit contracts between components to work in parallel without stepping on itself. Domain knowledge, taste, and clear thinking about the problem are what matter.
The limiting factor has shifted. Technical implementation is collapsing toward zero. What remains is taste, domain knowledge and the ability to think clearly about what you actually want built.
I’m well on my way to my first genuinely useful macOS app. Built with Swift, SwiftUI and Xcode, without writing a line of code, in an evening, by someone whose last “real” programming was HyperCard stacks in the 90s. The muscle memory of working with agentic AI tools compounds fast. Start building the instinct for how to break problems into parallelisable work. That skill will matter enormously in the months ahead.