I Built a Native Mac App With AI. That’s Exciting. It’s Also a Little Terrifying.

I’ve spent more than 25 years working in design, UX, branding, web development, creative direction, and all the messy territory where those disciplines overlap. Long enough to watch entire categories of tools come and go. Long enough to remember when building a website meant slicing Photoshop files into tables. Long enough to know that every few years somebody announces that some new technology is going to eliminate the need for designers, developers, agencies, or creative teams.

Most of those predictions have been wrong.

AI feels different.

I’m still not entirely sure how I feel about that.

Over the past couple of weeks, I built a native macOS application called DDrovr. It’s a desktop interface for DDEV, intended to give developers the kind of polished local-development experience that products like Local and Herd provide, while keeping DDEV underneath as the engine.

The idea itself wasn’t especially complicated. I use DDEV constantly. It’s powerful, reliable, and flexible, but it’s primarily a command-line experience. I started wondering what it would look like if managing DDEV projects felt more like using a native Mac application.

Normally, that question would be the beginning of a fairly substantial project.

Research. Competitive analysis. Feature definition. User flows. Wireframes. Visual design. Technical architecture. Swift development. Testing. Revision. More testing.

Probably several people.

Instead, I started talking to AI.

AI Has Become More Than a Faster Search Box

I think this is where a lot of the conversation around AI still misses what has actually changed.

The interesting part isn’t that ChatGPT or Claude can answer questions faster than Google. It’s that these tools can now participate in an entire creative and technical workflow.

I started by using ChatGPT to work through the product itself.

What should DDrovr actually do? Where should its responsibility end and DDEV’s begin? What could we borrow from Local? What could we borrow from Herd? What should we deliberately avoid building? What belongs in an MVP, and what belongs two or three releases down the road?

Those conversations helped turn a loose idea into a product definition.

Not because AI magically knew what the product should be, but because it was useful as something to push against. I could throw out an idea, challenge the response, narrow the scope, change direction, and keep iterating until the concept started to hold together.

That part felt less like asking a machine for answers and more like working through a problem with an extremely fast collaborator.

From there, I moved into interface exploration. AI design tools made it possible to mock up flows and screens quickly enough that I could evaluate ideas before investing much time in them. I could see how the project list might behave, how lifecycle controls might work, what project detail screens could expose, and where complexity needed to disappear.

Again, the machine wasn’t making the product decisions for me.

I was.

But the distance between an idea and something I could react to became dramatically shorter.

The Prompt Became Part of the Design Work

One of the things I’ve changed my mind about most is prompting.

A good prompt for a serious project isn’t “make me an app.”

It starts looking suspiciously like the sort of specification good teams have always needed.

What are we building? What problem does it solve? What are the architectural boundaries? What are the acceptance criteria? What should happen when something fails? What should explicitly not be built? What parts of the existing platform should remain authoritative?

ChatGPT and Claude became useful not just for generating those instructions, but for helping refine them until they were specific enough to hand off.

That feels important.

The better these coding agents become, the more valuable clear thinking becomes. Ambiguity doesn’t disappear because AI can write code. It just gets converted into code faster.

If your thinking is sloppy, you can now produce a sloppy product at breathtaking speed.

The real leverage comes from being able to define the problem well.

Then Claude Code Built It

This was the part that caught me off guard.

I handed the scope to Claude Code and had it build the native macOS application in Swift.

Not a prototype pretending to be an app.

A real application.

It talked to my actual DDEV installation. It discovered my real projects. It matched their statuses. It started, stopped, and restarted them. It streamed command output. It monitored external state changes. It handled invalid configuration without crashing. It had automated tests.

65 test cases across 14 suites. All passed.

The first project listing appeared about two seconds after launch. A project stopped manually in Terminal showed up in the app six seconds later. Lifecycle commands worked against my actual development environment.

There were rough edges. There always are.

DDEV’s logging behavior exposed a limitation around browser access logs. Cancellation could leave a project in an unhealthy state depending on when it happened. A few assumptions in the original scope had to change once they met reality.

That may actually be the most impressive part.

The workflow wasn’t simply “AI writes code and everything works.”

It behaved much more like development.

Build something. Test it. Discover that the real system behaves differently than the documentation or assumptions suggested. Adjust the implementation. Record the limitations. Keep moving.

The difference was the speed.

From the initial product idea to a working, tested native macOS app took no more than five hours.

Not five days.

Five hours.

In that time, I moved through product definition, competitive thinking, UX direction, technical scope, prompt refinement, Swift development, and real-world testing against my actual DDEV projects.

Without these tools, I would have expected that same exercise to take me and a small team considerably longer.

And the result exceeded my expectations.

That sentence is not especially comfortable for me to write.

Because This Is the Work I’ve Spent My Career Doing

There’s a version of the AI conversation that is relentlessly optimistic.

Everything becomes faster. Everyone becomes more productive. Tedious work disappears. Small teams can accomplish things that once required large ones.

All of that is probably true.

There’s another version that says AI is mostly hype, the output is mediocre, and skilled creative professionals have little to worry about.

I don’t think that’s true anymore.

I can look at what I just built.

That doesn’t mean I suddenly believe designers, UX professionals, developers, writers, or creative directors are obsolete. Quite the opposite.

DDrovr exists because I knew what I wanted to build.

I knew how software products are structured. I understood the audience. I could evaluate the competitive products. I could recognize when a proposed experience was wrong. I could define the visual and interaction priorities. I knew which technical compromises were acceptable and which would undermine the product.

Twenty-five years of experience didn’t become irrelevant.

It became leverage.

But it would be dishonest to pretend the economics of the work aren’t going to change.

When one experienced person can move from product concept to flows, interface direction, technical specification, native application development, and testing this quickly, it is difficult to imagine that creative and technology teams remain structured exactly the way they are today.

Some tasks will take fewer people.

Some roles will change substantially.

Some work that used to justify days or weeks of billable time may happen in hours.

And some of the people cheering loudest for that transformation probably haven’t spent decades building a career in the industries being transformed.

I have.

So yes, I have mixed feelings.

The Part AI Still Didn’t Do

What I keep coming back to is that AI dramatically accelerated the production of the thing, but it didn’t originate the reason for the thing.

It didn’t spend years using DDEV and get irritated by a particular workflow.

It didn’t recognize the opportunity between DDEV, Local, and Herd because of accumulated experience.

It didn’t decide that the application should treat the site as the primary object and DDEV as the invisible engine underneath it.

It didn’t know which features felt useful versus technically impressive but unnecessary.

It didn’t care whether DDrovr was worth building.

I did.

That distinction matters, although I suspect we’re going to spend the next several years figuring out exactly how much it matters.

The value in creative work has never really been the ability to move rectangles around a screen or type syntax into an editor. Those were the mechanics required to turn decisions into artifacts.

AI is getting frighteningly good at the mechanics.

That puts more pressure on the decisions.

What should we make?

Who is it for?

What problem are we actually solving?

What deserves to exist?

What feels right?

What should we leave out?

Those questions become more important, not less.

I’m Not Sure Where This Ends

I don’t have a neat conclusion about AI.

I’m skeptical of anyone who does.

I’m concerned about what happens to junior designers who traditionally learned by doing the production work AI now handles easily. I’m concerned about companies deciding that “faster” automatically means “fewer people” rather than using the leverage to make better things. I’m concerned about an industry filling up with technically competent but completely undifferentiated work because everyone is drawing from the same models.

And I’m concerned because I’ve now seen firsthand just how capable these tools have become.

At the same time, I can’t pretend I’m not energized by it.

I had an idea for a product.

I explored it, scoped it, designed it, specified it, built it, tested it, and watched it interact with fifteen real DDEV projects on my Mac.

I didn’t spend months doing it.

I didn’t spend weeks.

I spent about five hours.

The result wasn’t a disposable AI demo.

It was software I wanted to keep building.

That is remarkable.

Maybe the most useful position right now isn’t being an AI evangelist or an AI skeptic.

Maybe it’s staying curious enough to use these tools seriously, experienced enough to recognize where they fail, and stubborn enough to keep making the decisions ourselves.

Because for the moment, at least, that still seems to be the part that matters most.