Skip to main content
Paul Welty, PhD AI, WORK, AND STAYING HUMAN

· essays

In the AI era apps are easier to build. And irrelevant.

I spent months building a meal planning app. This weekend I replaced it with two emails, a spreadsheet, and an AI model — and realized the stage I was racing toward wasn't the destination.

I built a meal planning app. A real one. Next.js, PostgreSQL, Drizzle ORM, NextAuth, AI-powered recipe suggestions, pantry tracking, shopping lists organized by store section, a rating system that learns what your family likes. I migrated it from Supabase to Neon this morning. Shipped five features today.

Then I replaced all of it with a markdown file, a spreadsheet, and an AI named Kit.

Not as a joke. Not as a prototype. As the actual product. Kit emailed my family, asked what they want to eat this week, and will plan dinners based on what they say. The “database” is a Google Sheet with four tabs. The “app” is a conversation with an AI that can read the sheet and send email.

For months I thought the goal was to get AI to build my apps for me — faster, cheaper, better. That was the future I was racing toward. This weekend I realized the apps aren’t the point. They never were.

The four stages

Ask the question almost nobody bothers to ask: what is an app, exactly? Strip away the login screens and the Stripe integration and the mobile breakpoints, and what’s left? An app is an abstraction that stands in for a human interaction that didn’t scale. Every form field is a conversation somebody didn’t want to have. Every dropdown is a preference somebody didn’t want to explain. The app was the compromise we reached when the coordination problem was too big for a phone call and too small for hiring a person.

Stage 1 — Humans build apps. For most of software history, building an app meant hiring a team and waiting. A meal planner — the kind I started building a year ago — took months before a family member could touch it. Ten database tables. Seventeen unit tests. A ranking engine, auth, migrations, a weekly planning workflow with candidate selection and approval stages. The feature surface grew at the rate one person could type, and real software took real time.

Stage 2 — Humans with AI build apps. Then came Copilot, then Cursor. The demos were thrilling — autocomplete on steroids, whole functions conjured from a comment. Teams started shipping two and three times faster, and every engineering leader I talked to was sure this was the revolution. The shape of the work didn’t change. The same meal planner, with the same ten tables and the same login screen, just arrived a quarter earlier. A faster keyboard is not a different kind of sentence. The code got cheaper. The thing the code was building did not.

Stage 3 — AI builds apps. Then the AI stopped assisting and started driving. I run a fleet of thirteen coordinated Claude Code sessions. Last week they closed seventy features across six projects in a single session — a ranking engine rewritten, a Supabase-to-Neon migration, branded email templates on three products — while I was walking the dog. The cost of a new product drops to roughly the cost of deciding to start one. Scaffolding a whole Next.js app with auth, a marketing site, and its own orchestration loop takes one session. If you’re paying attention to AI and software, this is the future everybody is writing about.

I’m writing this from inside Stage 3. I’m the guy running the fleet. And here is what Stage 3 hides, which I didn’t see until this weekend: stages 1, 2, and 3 are all on the same ladder. They argue about who writes the app — humans, humans-with-AI, AI alone — and how fast. None of them question whether the app should exist.

Stage 4 — We don’t need apps. Stage 4 is not on the ladder. It’s off the side of it. I replaced the meal planner with a markdown file, a Google Sheet, a cron job, and an email address named Kit. Kit emails the family, asks what they want to eat, reads the replies, updates the file, writes the shopping list. There is no login screen because nobody logs in. There is no mobile breakpoint because nobody opens anything.

Come back to the question: what was the app for? The app was an abstraction standing in for a human interaction I didn’t have time to have every week — asking every family member what they wanted to eat and why. A good model does that interaction better than my dropdowns did. It asks follow-ups. It reads tone. It remembers that my daughter hates mushrooms without me building a mushrooms-specific UI.

Once you see that an app is artifice designed to imitate a conversation nobody had time for, and you notice that the model now has time and does it better, the artifice has nothing left to stand on.

Kit gives a damn. The app was a form.

What replaced the app

Here is the entire system, end to end, that replaced ten tables and seventeen tests and six months of work:

The file (kitchen.md) — four paragraphs. Who lives in the house. What each person eats, what they don’t, what they’re suspicious of. The current week’s plan. A log of what worked in the past month. A human wrote it. A human can read it. The AI can read it too.

The spreadsheet — Google Sheets, four tabs. meals: date, planned, actual, rating, notes. preferences: name, likes, dislikes, allergies, restrictions. pantry: item, have-it, running-low, last-bought. shopping: week, item, section, source.

The email address[email protected]. Every reply comes back to the same inbox. Kit reads them, updates the file, writes back.

The schedule — a cron job, three lines. Tuesday: “What sounded good this week?” Thursday: “Final call — any changes?” Saturday 4pm: “Tonight is [meal]. Recipe attached.”

No CRUD screens. No authentication. No Stripe. No loading spinners. No “Uh oh! Something went wrong” modal. No mobile breakpoint debugging. The family doesn’t install anything. They don’t learn a new UI. They read an email and reply to it.

The onboarding survey that would have taken me a week to build as a web form — the profile creation, the preference toggles, the dietary restriction checkboxes, the allergy warnings — was four casual questions in an email from someone named Kit.

Frozen conversation, live negotiation

An app is a frozen conversation. It encodes assumptions about what the user wants into interfaces that the user navigates. A conversation is a live negotiation. It adapts in real time. It asks follow-up questions. It changes direction when the user changes their mind.

My meal planning app had a “dietary restrictions” dropdown with checkboxes. Kit’s email asked, “Anything you absolutely don’t want?” The dropdown is a theory about what restrictions look like. The question is a conversation about what this specific person, this specific week, actually needs.

The dropdown is faster to tap. The question is better.

The model compounds. The app calcifies.

This week, Anthropic shipped Opus 4.7. I can feel the difference in every conversation. Longer-horizon reasoning. Better judgment about when to ask a clarifying question. Cleaner refusals when it genuinely can’t help. Opus 4.7 at a keyboard is a better collaborator than Opus 4.6 was eight weeks ago.

Eight weeks.

Meanwhile, somewhere in a Figma file, a designer is adding the 47th screen to a meal planning app that will ship in July. The team is still debating Drizzle versus Prisma. The roadmap has “AI-powered recipe suggestions (Q3)” on a pink sticky note.

That app will ship. It will be worse than Kit. The team isn’t bad. Kit just isn’t an app. Kit is a markdown file and an email address wired to a model that is already smarter than whatever the app will ship with, and will be smarter still by the time they cut the ribbon.

The model compounds. The app calcifies. That’s the whole game.

What survives

Not everything dissolves. The app had four things the raw conversation doesn’t:

Memory. A model doesn’t know my family’s preferences unless I tell it every time. But memory doesn’t need a database. A markdown file remembers.

Continuity. A prompt doesn’t know what we cooked last week. But a log does. Four columns in a spreadsheet: date, meal, rating, notes.

Timing. A prompt only answers when asked. A cron job asks at 4pm every day: “What’s for dinner tonight?” and sends a notification.

Action. A prompt can suggest dinner. An agent can email the family, compile the responses, generate the shopping list, and — eventually — order the groceries.

Memory, continuity, timing, action. Those four things are real. They justify some kind of system. But “some kind of system” is a markdown file, a spreadsheet, a cron job, and an email address. It is not a web application.

Almost everything else an app does is the form standing in for the conversation.

The stage I didn’t see coming

I’ve been paying close attention to AI and software for years. I run the fleet. I build the products. I write about this stuff. And I still spent months building the meal planning app while standing next to the realization that would dissolve it.

Stage 3 was so intoxicating — AI actually building the apps — that I mistook it for the destination. It isn’t. Stage 3 is the thing that makes Stage 4 visible. When building an app becomes trivial, the next question becomes unavoidable: why build this one at all?

For a surprising number of apps, the answer is: we shouldn’t.

Kit emailed my family ten minutes ago. By tomorrow I’ll know what everyone wants to eat this week. No app required.

Why customer tools are organized wrong

This article reveals a fundamental flaw in how customer support tools are designed—organizing by interaction type instead of by customer—and explains why this fragmentation wastes time and obscures the full picture you need to help users effectively.

Infrastructure shapes thought

The tools you build determine what kinds of thinking become possible. On infrastructure, friction, and building deliberately for thought rather than just throughput.

Server-side dashboard architecture: Why moving data fetching off the browser changes everything

How choosing server-side rendering solved security, CORS, and credential management problems I didn't know I had.

The work of being available now

A book on AI, judgment, and staying human at work.

The practice of work in progress

Practical essays on how work actually gets done.

Tag things the way you'd order them

Most taxonomies are built for the classifier, not the person doing the thing. The cheap test that separates one from the other.

On the death of the author and the birth of the detector

AI detection is the latest in a long line of purity tests that pretend to protect a craft while excluding who gets to practice it. Dumas faced this in 1845. Jim Thorpe faced it in 1912. The pattern is older than AI, and it always collapses. Sometimes too late.

The ghost in the git config

We spent three hours exorcising a dead bot from our deployment pipeline. The lesson wasn't about git.

The ghost in the git config

We spent three hours exorcising a dead bot from our deployment pipeline. The lesson wasn't about git.

When teaching stops being bounded

AI removes the constraints that gave teaching its shape—one teacher, thirty students, limited time. But lifting constraints doesn't make the work easier. It makes it different. Teachers trained for a bounded classroom now face an unbounded role that requires judgment, discernment, and presence in ways we haven't yet mapped.

Why your job matters more than mine: The selective morality of job loss

This article reveals the uncomfortable pattern behind which jobs get moral protection and which get called 'market forces'—and what that means for everyone outside the creative class.