Since April I’ve been building Tether, a community app for churches, on my own time. It has an iPhone app for members and a web console for staff, and one small church tests it with me every week. It’s still a work in progress and not available to the public yet, so this isn’t a pitch. It’s notes on how it’s being made. I designed it and I decide what ships. AI coding agents wrote the code.
By the end of September we’d shipped 43 iOS test builds. I’m a designer, not an engineer, so a fair question is: what was I actually doing all that time?
The short answer is that the design work didn’t disappear. It moved.
What got faster
A lot, honestly.
- Implementation. Two apps and a database came together far faster than they could have with me alone.
- Changes everywhere at once. Updating every copy of a pattern across both apps is tedious for people. For an agent it’s an afternoon.
- Tests and checks. Security and permission tests I’d never have written myself now run before releases.
- First drafts. Release notes, test plans and first-pass copy.
If your picture of a designer is “the person who makes the screens,” that picture is under pressure. Agents can make screens.
What didn’t
Here’s what stayed mine:
- Deciding what the product is. What a “ministry” is, what a “group” is, who can see what. These aren’t technical questions, and an agent will cheerfully pick an answer if you don’t.
- Noticing what a word means to real people. More on that below.
- Hearing one complaint and seeing the pattern behind it.
- Saying no.
When building gets cheap, the bottleneck moves to judgment: knowing what’s worth building, describing it precisely enough that an agent gets it right, and checking that it did.
Every correction becomes a rule
An agent will happily build the wrong thing well. Early on, one build treated a small Bible study as if it were a whole ministry: right code, wrong idea.
So every time I corrected something, I wrote the correction down as a rule the agent reads at the start of every session. A few of them:
- Ministries are the shelf; groups are the rows. A ministry is never listed as a peer of the groups inside it.
- Two-breath creation. A “create” form asks for what and when, three inputs at most. Everything else comes later, when it’s needed.
- Nouns are data. Every church names things its own way, so no screen hardcodes “ministry” or “group.”
- Change it everywhere, or just here? Before changing a component, the agent finds every copy and asks me.
That rulebook turned into the real design system. Most of it isn’t about color or spacing. It’s about meaning. If you lead a design system team, this is the part I’d pay attention to: when agents consume your system, an agent follows your documentation to the letter. When a designer reads a vague guideline, they ask a question or use common sense. An agent just guesses, and builds the guess with total confidence. Vague docs used to produce inconsistent screens. Now they produce wrong software that looks finished.
Count the audience
One spec said “staff can read a group’s pastoral notes.” That sounds reasonable until you count. At this church, “staff” turned out to mean 17 of 31 people.
Agents take words literally, and so do permission systems. Now, before any feature that reaches people, I don’t ask “who is this for?” I ask “how many people is that, by name?” That one habit has caught several changes that would have shown private information to the wrong people.
No agent caught that. A designer asking a boring question did.
“All clear” wasn’t
Tether runs an automated suite that tries to break its own permissions. It ran against the live system, reported green, and cleaned up after itself.
But the test messages had already sent push notifications to real members’ phones. Nobody noticed for months, until a member sent a bug report with a screenshot of her lock screen.
The fix went in at the boundary, not in the test: the notification sender now ignores anything marked as a test, so even tests nobody has written yet are covered. The lesson I took is one I’d give any team using AI to move faster: a cleanup proves the database is clean. It never proves the outside world is untouched. Before running anything against production, ask what leaves the system: pushes, emails, webhooks. None of it can be undone.
What this means for design teams
I don’t think AI makes designers less necessary. I think it changes where we spend our time:
- Less time drawing, more time defining. The clearer the rules, the better the output.
- Write your design system for a literal reader. Assume a collaborator will follow it word for word, because one will.
- Consequences are design work. When the system acts on someone’s behalf, what happens, who sees it, and whether it can be undone are design decisions, not engineering details.
- Test on real devices with real people, early. Some of my hardest bugs only appeared on an iPhone and never in a desktop browser.
The agents made me faster. They didn’t make me less responsible for whether the thing was right. If anything, they made that the whole job.
More on the working model, with screens, in the Tether case study.