TL;DR
The short version
The question isn't "can I code." It's picking a cell in a grid. One axis is the build pattern — what the software does to your work: automate the same job, upgrade its output, or invent a job that wasn't possible before. The other is the durability class — how robust it has to be: prototype, personal, production, product.
Who uses the thing and what its failure costs decide the class, not your ambition. Match the rigor to the class and most "it's not secure enough" objections turn out to be the product tier applied to a throwaway. Framed by Nathaniel Whittemore on The AI Daily Brief.
Source: Nathaniel Whittemore, "Where to Start AI Coding if You're Not Yet a Coder" on The AI Daily Brief. Analyst framing, illustrated with worked examples.
Two axes, chosen before you prompt
Most people treat AI building as a single skill you either have or don't. Whittemore reframes it as a decision with two dials, both set before the agent writes a line. The first names what the software does to the work you already do. The second names how much engineering the software has to survive.
Get the two right and the fog clears: you stop asking "am I technical enough to build this" and start asking "what am I building, and who has to trust it."
Build patterns: automate, upgrade, invent
The first axis names a build's relationship to your existing work. Automate: same job, same output, now done by machine — the Friday export runs itself. Upgrade: same job, better output — a static report becomes a live dashboard. Invent: a new job with an output manual work never made possible.
The three are a scan, not a hierarchy. Run them across your presentation, content, data, document, inbox, and admin work, and the recurring rules-based rituals light up first — the invoice pile, the weekly report, the export you rebuild by hand every Friday. Those are the software-shaped problems, and Whittemore's point is that you can't see them until you've built one.
Durability classes: who depends on it sets the bar
The second axis is the one that decides how much rigor the build needs. Prototype: disposable, optimize for speed, throw it away. Personal software: reliable enough for you or your team, polish is negotiable. Production: used by a specific known group, so it needs security, access control, and support. Product: built for a market of strangers — the only tier where you truly act like an engineer.
What sets the class is who uses the thing and what its failure costs — not how ambitious you feel. A dashboard only you read and a payments flow a million people touch sit at opposite ends of the same ladder, and they demand completely different amounts of engineering.
Building software, not for the sake of releasing software for other people to use, but for the sake of doing your own work better, is now just a foundational capacity that knowledge workers need to have.
Nathaniel Whittemore
The personal tier is the newly-unlocked middle
The interesting rung is the one that just opened. Building something useful for one goal, for one period, then discarding it was never worth the effort before. AI collapses the build cost, so the middle of the ladder — disposable, single-purpose personal software — becomes viable for the first time. That's where most knowledge-worker wins actually live.
It also picks your tool for you. Prototyping tools (Lovable, Replit, Figma Make) are built to move fast and be thrown away; commercial tools (Claude Code, Cursor, Codex) are built to ship durable software. Reaching for one encodes which class you're targeting — build-to-learn is a different job from build-to-earn.
Climb only as high as you have to
Climbing the ladder is a cost decision, not a moral one. Most objections — it's not secure, it'll break, it's ugly — are really the product tier applied to a prototype job. Match rigor to class and the objection dissolves; over-engineer a throwaway and you've spent away the very collapse in cost that made building worth it.
One rung before you start, though: check whether someone already sells the top of the ladder. A vendor whose whole job is that product usually beats your 68th to-do. Just because you can build it doesn't mean you should.
Personal software still has a maintenance bill
Matt Hartman of Factorial Capital vibe-coded Ghost Pepper, a local voice-to-text tool that passed 3,000 GitHub stars, and came away with a plain lesson: "when you just vibe code something for yourself, you have to maintain it." His read on SaaS fees changed with it. What you pay for is someone keeping the product great; the job of a SaaS app is to keep iterating and stay at the edge.
Every's Natalia Quintero tells the same story from the other end. She vibe-coded her team's CRM, ran it for months, then moved the data to Attio once upkeep was eating the time she could spend with clients.
AI lowers the cost of building on the personal rung, not the cost of staying there. The build-or-buy question comes back the moment upkeep starts, and Hartman expects a new category of tools whose whole job is helping people maintain this code. More from the interview: Back the Pivot Foot, Not the Pitch.
