Your PM Just Shipped a Mac App. Now What?

Something shifted in how your team can build. A PM can now stand up a working app in a day. A designer can draw a circle around an ugly button and watch an agent fix it. Repeatable weekly work can run itself. None of this waited for an eng sprint.

That sounds great until you think about who owns the output, who reviews it, and what breaks when three people ship at once. Let me catch you up on what actually moved and what to do about it before your next review.

The build that skips the ticket

Casey Newton spent his year building personal software with no eng help. Using Raycast's Glaze, he built three Mac apps in his first month, including a research tool that runs semantic search over six years of his own writing. He put it together in about a day. His point is simple: software used to be too expensive to build for a single person's weird need. Not anymore.

What makes these tools land for non-engineers is the friction they remove. Glaze starts with a working app template, compiles and installs on its own, and lets you edit the app while it is open by circling the thing you want to change. That is a different job than writing code in a terminal. It is closer to sketching.

For your team, this means a PM or designer can now test a real idea instead of describing it. The prototype becomes the pitch. That is faster than any spec doc, and it changes what you can expect out of a discovery week.

Loops that run without you

The other half of this is work that repeats. Aakash Gupta spent five weeks testing what he calls PM loops, systems that start themselves and do work on a schedule. His example: a loop that checks Salesforce every week, mines deals for things a PM can act on, and delivers takeaways with links. No prompting each time. You design it once and it runs.

The test he offers is worth stealing. If the work repeats, has clear inputs, and produces something you would act on, it can be a loop. Weekly sprint prep, monthly interview themes, business reviews all fit. This work used to live in tools like Relay or Lindy. Now it runs out of Claude Code or Codex.

Paweł Huryn is teaching PMs the same muscle, releasing 19 session recordings covering Cowork, Codex, n8n, and Lovable, with demos that go from 100 interviews to prioritized ideas to prototypes. The skill your team needs is shifting from doing the task to designing the thing that does the task.

The polish trap

Here is where I slow you down. The apps are fun and the loops feel powerful, but the ceiling is real. Newton admits his silly Nightwing to-do app has no practical use beyond making chores fun, and his one serious build is still half-baked over privacy concerns.

David Pierce, who has installed and abandoned around 200 to-do apps, is blunt about the returns. AI is good at busywork like converting files or clearing marketing emails. What it cannot do is exercise judgment about what matters to you. When he set it loose on his real inbox, it "started getting almost everything wrong." His advice: offload the dumb tasks, keep doing the work that builds your understanding.

His find-and-replace trick is the one to carry into your review. Swap the word "AI" for the word "software." Sometimes it is very good software. You still evaluate it like software, with the same questions about reliability and fit. That reframe kills a lot of hype fast.

The plumbing nobody set up

Underneath the demos is an infrastructure gap. The KDnuggets team notes that 51% of professional developers use AI tools daily, but only 17% say those tools improved team collaboration. That gap is not about the models. It is about the workflow layer no one built.

When two agents edit the same directory, the second one overwrites the first with no warning, and you find the corrupted work an hour later when tests fail. Git worktrees fix this by giving each agent its own isolated directory. At the Microsoft Global Hackathon 2025, engineering lead Tamir Dresher ran three agents in three windows and shifted his own role to tech lead: scoping tasks, reviewing diffs, merging finished work like he was reviewing a human's pull request.

That role shift is the tell for how you staff this. Whether it is a single builder or a fleet of agents, someone has to review, isolate, and merge. The orchestration frameworks confirm it. AgentScope uses a structured message hub so you can audit which agent influenced which decision, because debugging a multi-agent mess without that is brutal.

The deep cut

The skill that matters now is not building. It is reviewing. When a PM ships a working app and a designer runs three agents in parallel, your team produces more raw output than anyone can eyeball. Dresher did not stop being technical when he became a tech lead. He got more valuable, because judgment on the diff is what kept the output shippable.

So the move for your next planning cycle is to name who reviews agent and vibe-coded output before you let the volume climb. Pierce's whole system rests on one idea: a single source of truth, so you know where a thing is and where to put it. Apply that to your team. One place these prototypes live, one person accountable for what graduates from toy to product. Without that, you get 200 half-baked apps and no one who trusts any of them.

Three questions for your team

1. Which repeated PM or design task on your team passes Aakash's test (repeats, clear inputs, output you would act on) and could become a loop this quarter?
2. Who reviews and merges vibe-coded or agent-built work before it touches anything real, and does that person have the technical judgment to catch a silent break?
3. Run Pierce's find-and-replace on your roadmap: swap "AI" for "software." Which of your bets still hold up, and which were riding on the word?