I could lose every tool I use tomorrow and be back at work by the weekend.

Not because I keep backups. Because none of them holds the thing that matters. The chat app, the task board, the AI model, the place my writing goes. I can throw all of it away and the system I built keeps working.

I set it up that way on purpose. It’s close to the opposite of the advice everyone’s giving right now.

Here’s my system with no product names in it

Five helpers:

• One remembers everything and decides what happens next.

• One writes and sells.

• One looks things up.

• One argues with the others and checks whether what they said is true, and it’s not allowed to rewrite anything, so its complaints stay complaints.

• One keeps track of what’s waiting on me.

Work shows up and becomes a card. Every card says who it’s for, what it’s for, and what’s happened to it so far. Every single action gets written down as one line: the card, the action itself, who did it, and when.

Nothing goes out to real people without me. On the path that messages strangers, that gate is strict in a specific way: the send tool looks up each message and refuses unless it finds a yes recorded by a person, and a yes written by a tool is thrown out. On the publishing path, it’s a quieter thing: a button only I can reach.

Different strengths, same rule.

Read that again and notice what’s missing. No brand names. No AI model. No app.

Two of those five have been running for months. The other three are new, added in the last few days, and here’s the part that matters: adding them didn’t change the description. It also didn’t change when I swapped what runs underneath. A design that can absorb three new workers, and a change of model, without being rewritten is the thing I’m actually claiming.

The question everyone asks stops being true very fast

Open almost any newsletter like this one and you’ll find the same article: here are the tools to use, here’s the stack to copy, here’s the fourteen things that will put you ahead.

I actually read a really good one this week. It listed the exact tool for fourteen different jobs.

It’ll be wrong within a year. The person who wrote it knows that, which is why he writes a new version every few months.

Tools change fast. Prices go up. A better one shows up. The one you learned gets bought by a bigger company and slowly gets worse. Enshittification is real. If your business is a list of products, you have signed up to redo the work every time the list changes.

The layer underneath the tools barely moves at all.

What I could throw away this afternoon

This isn’t a thought experiment. These are things I’ve already changed, or could change today.

The chat app: work shows up as messages, whether that’s Discord or Teams or an email inbox. Changes one small piece of code.

The task board: cards, columns, comments, done. That’s Asana, or Trello, or Linear, or the one I use - Fizzy, by 37Signals.

The AI model: today that’s Claude, and I like it. I’m using Anthropic’s Fable and Opus and Sonnet for the right-sized tasks for those models. My helpers are described in plain writing, so what runs them underneath is a setting. If something better arrives next year I change the setting, and every one of them still knows what it’s for.

The places I publish: Substack, LinkedIn and X are all driven from a browser I’m already signed into, so none of them has me locked in through a connection I would have to rebuild. When Substack added a scheduler for Notes, switching to it took one morning, because my system already knew what a scheduled piece was.

The part I couldn’t throw away is the part nobody sells you: what each helper is for. The rule that one of them may never rewrite another one’s work. The single gate that needs a human. Those took real thinking. They’re also just words in files I own.

Your history should belong to you

The clearest example is where my writing lives.

Every piece I have written, drafted, killed or published is a list of lines in a file in my own folder. Just over a thousand pieces across 222 days. 636 of them went out. Every change is one line with a time and a name on it.

The searchable copy sitting on top of that file is throwaway. I delete it and rebuild it from the lines whenever I feel like it, and I have.

If that history lived inside somebody’s app instead, I’d be renting my own memory. Most people make that trade without noticing, because the app is genuinely good and there’s an export button right there in the settings.

Why almost nobody talks about this part

There is nothing to buy.

Nobody advertises “spend an afternoon deciding what each part of your business is actually for.” It doesn’t look good in a screenshot.

It’s also harder. Comparing tools takes twenty minutes and feels like progress. Writing down exactly what you want, clearly enough that the right tool becomes obvious, takes an afternoon and feels like you didn’t do anything at all.

So everyone writes the tool article. It’s quick to write, quick to read, and somebody buys something at the end.

I’m not against those articles. I wrote one this week. But it answers a question that expires, and the reason mine keep working is that I answered a slower question first.

The one question I ask before adding anything

What happens to my system if this exact product disappears in eighteen months?

If the answer is that one small piece of code changes, it goes in and I barely think about it.

If the answer is that my history lives inside it, or that the way I work would be shaped by its buttons? Then it doesn’t go in. Or it goes in, and I keep my own copy of the record somewhere I own.

That question has kept me away from products that were better than the ones I use. It was worth it every time. A slightly worse tool that leaves you holding your own history beats a better one that holds it for you.

Try this before you pick anything else

Write down how your business works on one page, without naming a single product.

Who does what? What decides what? What has to be written down? Where a person is required, and why it has to be a person there?

Most people can’t finish that page on the first try. That’s the useful part. Every place you get stuck is a decision you have quietly handed to a product.

Then, go and pick your tools. You’ll find the choice is much easier, and much less interesting, which is exactly what you want.

PS. If you want a resilient setup for your own business, I can help.

Book a Call

An instructor told me the attendance-code flow in uPoll was confusing students.

The obvious response was to make the instructions clearer. We could have changed the wording, moved the code higher on the screen, or added another line to onboarding. Each option would have been quick. Each would also have preserved the thing causing the confusion.

So we removed attendance-by-code entirely in uPoll v3.0.0.

Students now get an alert when attendance opens. There is no code to receive, remember, or type. The instructor still gets the outcome the feature was built to provide. The student carries less of the design.

That was the strongest product decision I made this week, and most product teams are organized to avoid it.

A shipped feature starts defending itself

Once a feature exists, every conversation about it starts with the same quiet assumption: the feature stays.

People discuss copy, placement, speed, error messages, and training. The debate sounds practical because those are all things a team can change. Nobody has to reopen the earlier decision or explain why the work was built in the first place.

The feature also has weight now. Somebody designed it. Somebody wrote the code. Tests cover it. Documentation names it. A release note announced it. Removing it can feel like admitting that work was wasted.

That feeling is expensive.

The work is already spent. Keeping the feature doesn’t recover it. It only asks every future user to keep paying for the original decision. This is known as the sunken cost fallacy: a cognitive bias where people continue an endeavor or stick with a decision because they have already invested time, money, or effort, even when quitting is the more logical choice.

In this case, the payment was tiny: one code entered during class. But tiny friction repeated across a room still becomes the product. A student doesn’t experience the architecture or the reason the feature made sense on a whiteboard. The student experiences one more thing standing between opening the app and being counted present.

The instructor’s report gave us a chance to defend the interface or protect the outcome. We chose the outcome.

The feature wasn’t the job

Attendance codes were one way to answer a larger need. An instructor opens attendance. Students respond. The instructor gets a usable record.

The code was an implementation detail inside that flow. Over time, it had started acting like the flow itself.

This happens easily when you build software. The database has a concept, the interface gets a screen for it, and the team starts speaking about the screen as if users arrived wanting that object. Users rarely want the object. They want to finish a piece of work with less effort and more confidence.

That distinction matters because a request about a feature can carry two very different messages.

Some feedback says the feature is doing the right job and needs a better edge. In the same release, direct user requests led to collapsible poll answer options and a grade-display fix. Those changes preserved the underlying interaction and made it easier to use.

Other feedback says the user is carrying work that belongs to the product. The attendance-code report was that kind. Improving the code screen would have made us better at asking students to do something the alert model could remove.

You can’t tell the difference by counting requests. One clear report from a person using the product in a real classroom can expose more than a backlog full of feature ideas. The useful signal is where the burden sits.

Deletion requires a written outcome

Teams struggle to remove features when nobody wrote down what those features were meant to accomplish.

Without that sentence, the feature becomes its own justification. Attendance-by-code exists because the product has attendance codes. The circular logic feels solid inside a roadmap review because everyone already knows the nouns.

A plain outcome breaks the circle.

For this flow, the outcome is an instructor opening attendance and getting a reliable record while students do as little extra work as possible. Once that is visible, the code has to compete with every other way to reach the same result. An alert is simpler for the student, so the old implementation loses.

I use four lines to pressure-test a feature before adding another patch:

• Name the user outcome without using the feature’s name.

• Name the work the current design puts on the user.

• Sketch the shortest path to the outcome with the current feature removed.

• Compare that path with what real users have already reported.

The first line does most of the work. If a team can’t describe the outcome without naming the interface, it has probably confused its solution with the user’s job.

The second line makes small burdens visible. A code, an extra confirmation, or a required status choice can look trivial in isolation. Users experience the accumulation.

The third line creates permission to start over on paper. No migration plan is needed yet. No estimate. Just a sketch of the cleanest route.

The fourth line keeps the exercise honest. A tidy diagram made in a product meeting is weaker than a sentence from somebody using the thing under real conditions.

Feedback is evidence, not a specification

The instructor didn’t arrive with a replacement architecture. The report was narrower: the attendance-code flow confused students.

That distinction protects both sides of the product conversation. Users shouldn’t have to design the system for the team. They know the moment where the work becomes awkward. The builder owns the translation from that moment into a product decision.

Sometimes the translation is direct. A request for collapsible poll options points to a clear display problem. A grade that appears incorrectly points to a clear result that needs correction. The job and the requested change line up.

The attendance report reached deeper. The confusion lived inside a step that the product could remove. Treating the report as a request for clearer code instructions would have translated the words while ignoring the work.

This is why a feature-request list isn’t a roadmap by itself. Two requests with the same number of votes can carry different product information. One asks you to make an interaction work as intended. The other reveals that the interaction has become a tax on the outcome.

I don’t need a large survey to inspect that second kind of report. I do need enough context to understand the real use, the stakes of changing it, and the path that replaces it. Deletion should come from evidence and a protected outcome, not from impatience with maintenance.

The standard is simple: remove the feature only when the replacement asks less from the user and still does the job. That is subtraction with responsibility behind it.

AI makes the wrong fix easier to ship

AI can produce all the obvious patches fast.

Give it a confusing screen and it can rewrite the instructions, move the field, add validation, generate tests, and draft the release note before the meeting ends. That speed makes a patch feel cheap.

The hidden cost sits with the user. Every patch that preserves the wrong interaction adds more code around the original assumption. The system gets larger while the experience barely improves.

This is one reason I don’t treat AI as the product decision-maker. It can explore five implementations in minutes. It can’t decide which burden my users should keep carrying under my name. That call needs the context around the work and responsibility for what ships.

The useful 70/30 split shows up clearly here. AI can handle a large share of production. I keep the judgment about what deserves to exist.

Faster building raises the value of deletion because adding another layer has almost no immediate friction for the builder. When code was expensive, effort forced some restraint. Now the restraint has to come from taste, observed use, and a clear outcome.

Deleting a feature is still product work

Removal can look like less ambition from outside the team. Inside a product that people use, it is often the cleaner form of progress.

We still had to change the flow, update the surrounding behavior, and make sure the alert model carried the job the code used to do. Deletion didn’t mean shrugging and walking away. It meant spending the effort on a simpler contract with the user.

That contract matters more as a product grows. uPoll now has 297 students, 120 lectures, 520 polls, and 1,172 responses in its production aggregates. Those are counts, not engagement claims. They tell me the product is far enough past its first demo that a small burden can reach a lot of real use.

At that stage, shipping more surface area isn’t automatically progress. The product earns trust when each new version asks less from the people using it while protecting the outcome they came for.

The attendance change did that. Students stopped carrying a code. Instructors kept the attendance flow. The product became smaller at the exact point where it became more useful.

A ten-minute deletion review

Open the backlog for one product or internal workflow you own. Pick the feature that keeps attracting requests for clearer instructions, better placement, or one more exception.

Set a timer for ten minutes and write four lines:

1. The outcome the user needs.

2. The work the feature puts on the user.

3. The simplest route with the feature removed.

4. The evidence from someone who actually uses it.

If the new route protects the outcome and removes work from the user, give deletion a real place in the next product conversation. Don’t let the time already spent make the decision for you.

The best fix may leave you with less software to maintain and a better product to use.

PS. If your business is carrying workflows that keep getting patched but never get simpler, I help map the outcome, remove the unnecessary steps, and build the parts worth owning. Start at coaching.g8n.ai.

Book a Call

My content system produced every draft last week. On time, in my voice, with the images rendered and the comments already written.

Five decisions have been sitting in its queue waiting on me. The oldest is fourteen days old.

I built the thing to remove my bottleneck. It removed the one I was looking at.

So I went back through the last three weeks looking for the things that actually changed a situation for somebody, which is a different list than the things that got produced. Three came up. My system wrote none of them. All three were sentences I said out loud, in conversations, and two of them took under a minute.

What the system actually took off my plate

I want to be precise about this, because “AI does my content” is the kind of claim that sounds like either a boast or a confession depending on who’s reading.

Here is the real division: drafting is handled, and research reads the field and comes back with what people are actually saying this week, sourced. Voice matching is handled well enough that I stopped rewriting openings. Images render. Scheduling holds. The system will not publish anything without me, and that gate has never moved.

That’s a genuine amount of work gone. Ten months ago, most of a Tuesday went into one newsletter, a LinkedIn repurposing, and two Substack notes.

The shape of it, since a few of you asked after last week: every morning a batch gets drafted and lands in a dated folder with a queue file next to it. Each item has an ID, a status, and a line saying what it’s waiting on. Nothing moves out of that folder without me supplying the ID. When something publishes, the system writes back what actually happened, including when it failed, and I read that rather than assume the send worked. The interesting part is that almost all of the engineering went into the refusals: the checks that stop a thing from going out when a gate cannot be verified.

What’s left is smaller and much harder to hand off. Every item in that queue is a judgment call with two defensible answers. Keep pursuing a conversation that’s gone quiet, or let it close. Retire a tool that’s failed repeatedly, or keep trusting it. Approve a post the system has surfaced four separate times, or admit I’m never going to run it.

The system can draft all of those. It can argue both sides better than I can. It cannot decide, because deciding requires knowing which outcome I actually want, and I’m the only one who has that.

Two words, in a conversation I wasn’t managing

Late July. I was talking with someone I’ve met recently about what he was building. He had the experience, he had the track record, and he was describing his offer in a way that took four sentences and still left you unsure what you’d be buying.

I said two words, well, two that mattered: “Fractional CTO.”

That’s it. I didn’t write him anything. I didn’t build him anything. I named the thing he was already doing.

Eight days later he’d rebuilt his entire offer around it, had two people he trusts review the result, and sent the finished structure back to me. Along with a video he thought I should watch, which turned out to reframe how I price my own work.

I’ve thought about that exchange more than anything my system produced that month. Two words, from a twenty-year pattern library I didn’t consciously consult, and it reorganized someone’s business. Then the return came back around without either of us selling anything.

No model in my stack makes that call. The words themselves are easy. Knowing which two matter to this specific person, at this specific moment in his thinking, requires having sat in that conversation.

The call where I gave away the framework

Two weeks ago, a working session with someone trying to figure out where AI actually fits in her QA work at a large company.

She came in with the question most people bring, which is some version of “what should I use.” That question has no good answer, and answering it directly is how people end up with eleven tools and no workflow.

So I gave her a different one. Where do you want this process to be in six months, described as if it already works? Then we worked backwards from her answer.

Out of that came a decision rule she can apply without me. When the thing you want is a repeatable procedure you’ll run the same way every time, build a skill. When it needs to look at a situation and choose, build an agent. Most people build the agent first, then spend a month debugging judgment they never needed.

She left with a specific recommendation for her own workflow and a rule for the next twelve decisions. I left with a sharper version of the rule than I walked in with, because explaining it to someone with a real constraint is what exposes where it’s vague.

My system could have written a thorough article about skills versus agents. It could not have watched her describe her workflow and noticed that the future-state question was the one she needed.

The thing he’d already told me he needed

The third one is barely a sentence, and it’s the one I almost missed.

Someone described a problem to me in detail, as a side note to other things he was telling me about his business and how their business and team leverages AI. His team’s best AI work was stuck on one person’s laptop. Useful things being built, none of it reaching anyone else, and everybody who wasn’t already AI-literate getting more overwhelmed with each new tool.

Then he wished, almost as an aside, that he could get a daily digest of his meetings with risks flagged.

I’d been running exactly that since July. Every recorded meeting, full transcript rather than the vendor’s summary, decisions and commitments pulled out, anything needing a human pushed to a channel where I’ll see it.

Building it was never the valuable part. It already existed. The value was in hearing an aside as the actual request, and recognizing that the thing I run for myself every morning answered the problem he’d spent months trying to solve.

That’s pattern matching across two conversations that a transcript would have flattened into one line of small talk.

What these have in common

Each one took less than a minute of output. Together they produced more value than everything my system generated in the same period, and I say that as someone who genuinely likes what the system produces.

The common thread is that all three required being present while somebody else was thinking. Not retrieving information. Sitting in a live situation with enough context to know which of a hundred true things was the one worth saying right then.

Notice what none of them required. Speed wasn’t the constraint in any of them, and neither was volume or a better model. Two of the three were things I already knew and had already built, waiting for the moment where they applied to someone.

There’s a version of this that turns into a comfortable story about human irreplaceability, and I don’t believe that version. The models are getting better at more of this every quarter, and anyone telling you where the permanent line sits is guessing.

Here’s the narrower claim I’ll defend: right now, today, the constraint in my business is not production. It’s the number of live situations I can be genuinely present in, with enough context loaded to say the useful thing. My system expanded my output roughly fivefold. It expanded that second number by zero.

Which is why the queue keeps growing.

Where this leaves you

If you’ve built something that drafts for you, you already know the feeling. The relief lasts about three weeks and then you notice the work didn’t leave, it concentrated. What’s left is denser and it’s all yours.

None of that argues against building the system. Mine gave me back most of a day a week and I’d build it again tomorrow. It does argue for being honest about what the day is for.

I’ve started treating the queue as the actual job rather than the overhead. Five open decisions is not an embarrassing backlog, it’s the accurate measure of what only I can do. Fourteen days is too long, though, and that one’s on me.

Do this in the next ten minutes. Open whatever holds your undone work. Go through it once and mark every item that is genuinely a decision rather than a task, meaning two defensible answers and no amount of research settles it. Count them. That number is your real workload now. Everything else is production, and production is the part you can hand off.

Then take the oldest one and decide it today. The answer may well turn out wrong. It has been costing you attention every time you look at that list, and a decided-wrong is cheaper than an open-forever.

Mine was fourteen days old. I closed it this morning.

PS. If you’re staring at a list like that and most of it turns out to be production rather than decisions, that’s the gap I help people close. I map how the work actually runs today, build the pieces that should run without you, and stay long enough to see whether your team is still using any of it in month five. Reply to this email and tell me what’s on your list.

Book a Call

Anthropic’s most capable model went live on June 9th. By June 12th it was gone. On July 1st it came back.

Eighteen days, and nobody who had built on it picked a single one of those dates.

That’s the part worth keeping now that the panic has passed. Fable 5 launched with a million-token context window and the best coding score anyone had posted, free to paying subscribers, and people wired it into their products the way you wire anything that looks permanent. Then the Commerce Department ordered access suspended under export-control rules, citing national security. The instruction covered any foreign national, inside or outside the United States, including Anthropic’s own employees. There was no way to comply narrowly on that deadline, so the model went dark for everyone. Two and a half weeks later the controls were lifted and it returned.

I’m not writing this to pile onto Anthropic. I use their tools every day, and an impossible order arrived with a clock on it. I’m writing it because of what those eighteen days did to people who had made one model “load-bearing”, and because the ending makes the lesson easier to ignore than it should be.

Rented reach, rented foundations

I’ve said for a while that the followers you collect on a platform aren’t yours. You rent access to them, and then the landlord changes the rules whenever they want.

Fable 5 pointed that same lesson at a different part of the stack.

A legal-AI startup called Legion went to court over it, because their product stopped working the moment the model did. Their filing put it plainly: every day the directive held disrupted their product and operations, sidelined their engineers, and eroded the company’s ability to survive in a field defined by continuous access to the most capable models. Legion did exactly what everyone tells you to do. They built on the best model available, and then they learned what “available” means when it depends on a vendor and a government you don’t control.

Across developer forums the conversation shifted inside a week. It stopped being about which model scores highest and started being about single points of failure. Teams that had hard-coded one provider spent those days building the ability to fail over to another. The ones who already could just kept working.

Tying your business to one frontier model isn’t a safety net. It’s a hope.

Draw the line before you need it

You can’t self-host a frontier lab, and you shouldn’t try. What you can do is decide, in advance and in writing, which parts of your system have to be yours and which parts you’re happy to rent.

I run my business on something I built called Core: my CRM, my tasks, my content, and the record of what actually shipped. That lives somewhere I control and can move. I self-host the pieces that are genuinely mine, the hosting and email behind my core workflow product. Everything else is a deliberate rental. Supabase runs my production databases, and it earns its keep with backups and security I’d otherwise be maintaining at two in the morning. Kit and Substack handle publishing. All in, I’m paying somewhere around a hundred dollars a month across managed services, and that number goes up as I ship more.

Sovereignty was never a cheap monthly bill or cancelling all your SaaS. It’s owning the core and renting only what genuinely earns its place.

The models sit firmly on the rented side, and they’re deliberately swappable. When one’s best for a job, I use it. When it’s gone, I route around it. The value was never in any single model; it’s in the harness around it, the contracts between the pieces, and knowing my own work well enough to point whatever model is standing at the problem.

The lane nobody can switch off

Since June I’ve been building one piece of insurance, and it isn’t a second subscription.

At 1:46 in the morning last week, two models running on my own laptop each drove a 39-turn research loop with live web search across ten topics, and both produced valid structured reports. No API bill, no account, no policy anywhere that could switch them off mid-run.

They’re not as good as the frontier models. That isn’t the point. The point is that a lane nobody can revoke changes what the revocable lanes are allowed to cost you. Bounded, repetitive, verifiable work is a good candidate: research, extraction, summarizing, the tasks where you can check the output yourself in seconds.

I’d also rather state the reason plainly than dress it up. Quota exhaustion is a routine operating condition here, not an incident. And the subscription policies underneath all of this have reversed three times in four months, which I keep on my risk list rather than in my feelings. Owning one lane outright is how a policy change stops being an outage.

What this isn’t

It’s easy to turn one strange month into a sermon, so let me be careful.

This isn’t an argument to abandon the big models. They’re remarkable, they do things nothing on my laptop can approach, and you should use them. You also don’t need an elaborate five-provider routing layer you’ll never maintain. Building that before you need it is its own kind of trap.

And I’m not predicting a repeat. The controls lifted, the model came back, and the specific politics of June may never recur. What you got was a free, low-stakes look at what a hard dependency feels like when it fails. The next one will cost more than a look.

Do this in the next ten minutes

Open whatever runs your business and find your single biggest dependency on something you don’t control. The model behind your app. The platform that holds your audience. The service that holds your data.

Write one sentence: if this disappeared for three days, here’s exactly what I’d do.

If you can answer cleanly, you own the seam and you’re fine. If the honest answer is that you’d be stuck, you’ve found the first thing worth fixing, and it starts smaller than you’d think. Export the data. Write down the manual fallback. Turn one hard-coded provider into a setting you can change.

You don’t need to predict the next directive. You need one dependency you’ve stopped pretending is permanent.

If you want help working out which layer to own first, and then building it, that’s exactly what I do with operators.

Book a Call

At 1:19 in the morning on Saturday, my primary AI assistant hit its usage ceiling and went dark for two days.

I found out later that morning, the way you find out about good news: nothing was wrong. The Saturday content batch was drafted, staged, and waiting for my review, exactly where it always is. Sunday ran the same way. A backup had taken over both mornings, followed the same rules, and left the same paper trail.

Nothing about that weekend was lucky. Every decision that carried it was made three weeks earlier, in calm conditions, when nothing was on fire. That gap, between when protection gets designed and when it gets tested, is what this edition is about.

The three decisions

A takeover contract, written down where any tool can read it. There’s a small file on disk for each day. It says who owns the day’s run, when they claimed it, and what state the work is in. The rule lives in the file, in plain text: if the owner goes quiet for forty-five minutes without delivering, or marks the day failed, the backup may take over. A rule agreed on in advance and enforced by whoever shows up, instead of a meeting or a 7 a.m. judgment call.

When the primary went dark, the backup didn’t have to decide anything. It read the file, saw the conditions were met, and started working. The decision had been made weeks before, by me, once.

A deliberately underpowered backup. The backup can draft everything and publish nothing. It works in a sandbox with no network access: it can’t publish or email anything, and it can’t touch a live system. A separate delivery step, with its own checks, moves finished work to where I review it.

I weakened the backup on purpose, and trust had nothing to do with it. Permissions are the honest form of governance. Anyone can write a policy document that says “the backup will be careful.” The sandbox makes carefulness structural. When it took over, the worst it could possibly do was already decided, and it was small.

A gate that doesn’t move. Nothing publishes under my name without my word. That was true when my usual assistant was working, it was true while the backup ran the mornings, and it will be true for whatever model I’m running next year. The gate outranks the tools on both sides of it. Swap everything else out and the one thing a reader can rely on is unchanged: a human decided this was worth their time.

What broke anyway, and why that was fine

Honesty requires the other half. The backup couldn’t do everything. The parts of my morning routine that need live reads of the outside world, engagement data, other people’s posts, simply didn’t happen for two days. Those are exactly the powers the backup doesn’t have.

That’s isn’t a hole in the design. That is the design. The blast radius of the outage was decided in advance: drafting continues, publishing waits for me, and anything requiring live access pauses cleanly instead of running on stale assumptions. I’d rather lose two days of engagement plans than have a backup improvise with yesterday’s picture of the world.

A colleague-in-craft put the principle better than I had: wrote this week that AI agent governance is a design decision, not a clean-up job, and that most teams do it in the wrong order. They deploy, then discover what the agent shouldn’t have been able to do. The outage was my proof of the right order. By the time a system is being tested for real, the only decisions that count are the ones you already made.

One detail I keep coming back to

On Monday morning, with the primary back online, the backup still claimed the day first. It woke at 7:37. The primary showed up at 8:00 and found the work already staged, with a note in the contract file saying so. No collision, no duplicate, no confusion, because the same file that handles disasters also handles ordinary mornings.

Systems that only exist for emergencies rot before the emergency arrives. The takeover contract works because it isn’t emergency equipment. It runs every single day, which means it was rehearsed hundreds of times before it mattered.

The ten-minute version for your business

Pick one process that would hurt if you were unreachable for two days. Invoicing, client replies, publishing, payroll approval, whatever stings to imagine dropped.

Write three lines about it, somewhere your backup person or tool can actually see:

1. Who owns this, and how would anyone know they’ve gone quiet?

2. Who takes over, and after how long?

3. What is the taker-over explicitly NOT allowed to do without you?

That third line is the one people skip, and it’s the one that matters most. A backup with unlimited permissions isn’t a safety net. It’s a second way to have an accident.

The full system can come later. Something better already happened: the next outage now has rules waiting for it instead of improvisation.

If you’d like systems like this running your business, calm on their worst weekend, that’s what we build together, step by step, in coaching. The strategy call is thirty minutes, and you’ll leave with at least one takeover rule worth writing down. Book whenever suits you.

Book a Call

Last week I sat down to review a document that existed for exactly one reason: to fix the problem of my AI agents stating stale information as if it were current fact.

Inside it, I found a stale snapshot stated as current fact.

The builder assigned to implement the fix caught it. That was the seventh time in one session that an agent in my fleet had asserted something outdated as if it were live truth. And the seventh one was hiding inside the cure.

I want to walk you through what we found when we finally stopped blaming the agents, because the answer turned out to be about my business, and probably yours, more than it was about AI.

Last week I published the full checklist I run before trusting any AI output. If it didn’t hit your inbox, it’s here. Its third check, did I verify it or did I trust the report, is the one this whole story is about. This was the week that check earned its keep inside my own system.

Seven wrong facts, zero lies

Here’s the part that made this hard to diagnose. None of the seven assertions were hallucinations. Every single one had been true when someone first observed it.

A queue that had been empty was reported empty, hours after it filled. An email described as “scheduled for tomorrow” had already been rescheduled by another process. A deployment URL that was correct on Friday was quoted confidently on Sunday, after it changed.

The information had simply expired between the writing and the reading. That difference matters, because you can catch a lie with a fact-check. An expired truth passes every fact-check you run against the moment it was written.

The investigation that pointed back at me

I run a small fleet of AI agents that draft content, manage publishing, watch queues, and coordinate through a shared database. When the stale assertions kept coming, we did what you’d do with an underperforming employee: we studied the employee.

Four separate expert reviews analyzed the agent’s behavior. Detailed, thoughtful work. Then an independent reviewer did something none of the others had done.

It read the standing orders.

Our operating instructions declared one planning file “the single source of truth for session state” and told every agent to read it first, before anything else. That file held 670 lines of append-only history. Entries from days and weeks earlier, stacked oldest to newest, under a heading that called itself Session State.

Every line in that file was a dated historical claim. Every agent had been instructed to read it as current fact.

The agents weren’t violating the process. They were following it.

I’ve been building software for twenty years, and I still needed an outside reviewer to see it. When every actor in a system makes the same mistake, the instructions are the suspect, and the instructions were mine.

Assertion laundering

That’s the name for the mechanism, and naming it is important, because once you name it you see it everywhere: assertion laundering.

An unverified claim gets written into a status document. The document gets read as evidence. A summary quotes the document, a handoff quotes the summary, and three retellings later nobody remembers that no one ever checked the original claim against reality. The claim didn’t get more true along the way. It just got harder to trace.

Your business does this. Mine did. The status deck that says the integration is “on track” because the last deck said so. The wiki page describing a process the team abandoned in March. Each was true once. Each is read as true now.

A document is not a status. Anything append-only is a stack of dated historical claims, and the moment someone reads it as “the current state,” the laundering has begun.

Why “be more careful” was never going to work

My first instinct was to add a rule. Something like: verify information before asserting it. We actually had versions of that rule already. The agents ignored them, and it turns out they were being economically rational.

I measured what verification costs in my stack. A full state refresh means about fifteen separate reads across the systems that hold real truth. The single cheapest one costs 3.6 seconds of wall clock. Recalling something from notes costs nothing, and it feels exactly as certain.

That’s the whole contest. Fresh truth costs seconds and effort. Stale memory is free and feels identical. A rule that says “be more careful” asks every reader, human or AI, to keep paying a tax that laziness refunds instantly. That gradient wins every time, in my fleet and in your Monday standup.

So the fix can’t be a plea for discipline. It has to change what the data itself looks like.

The fix: make freshness visible

What shipped is small and boring, which is usually a good sign.

First, every state read in the fleet now leads with a timestamp. “AS OF 07:03 UTC,” stamped by the system that answered, and stamped only when the read actually succeeded. A claim without a timestamp is visibly naked now. You can’t quote it without noticing you don’t know how old it is.

Second, the 670-line file got restructured. The current-state section is 15 lines. The history didn’t get deleted, it moved below the fold and got labeled as what it always was: history. The file went from 840 lines to 871 in total. We removed nothing. We just stopped letting the past wear the present’s name tag.

Honesty requires me to tell you this fix is a first tier, and a reviewer has already found two defects in it. That’s fine. The goal was that a stale claim now looks different from a fresh one, so catching the difference stops depending on anyone’s virtue.

The test for your own business

You don’t need an agent fleet for this to bite you. You need exactly two things: a document people trust, and time.

So here’s the test I’d run on any document your team treats as truth. Pick a load-bearing claim from it and ask when it was last observed, by whom, against the real system. If the answer is a date, you have a status. If the answer is “it’s in the doc,” you have laundering.

The uncomfortable version: the more trusted the document, the better the laundering works. Nobody re-verifies the source of truth. That’s what makes it one.

Do this in the next ten minutes

Open the one document your team treats as current truth. The status page, the master tracker, the handoff doc.

Find the three claims that would cost you the most if they were stale. Next to each one, write the date it was last verified against the actual system rather than against another document. If you can’t produce a date, mark the claim “unverified as of today.”

That’s it. The process is still unfixed, and you’ve already done something better: you’ve made the staleness visible, and visible problems are the only kind that get fixed.

P.S. It took an outside reviewer to spot what my own instructions were doing, and that’s not an accident. You can’t proofread your own operating assumptions. That’s exactly what the AI Workflow Audit is: 30 minutes of checking what’s actually true about where your hours go, instead of what the docs and the habits claim. Short intake, a working call, and a written map of your highest-impact automation opportunities, ranked. Ten founding-rate spots this week: audit.g8n.ai

All of my writing is AI. I’m proud of it. So what?

Recently, Substack gave every reader a reason to ask. They shipped a button that scans any post and estimates how much of it a machine wrote, built on Pangram, one of the sharper detectors out there. Open one of my newsletters, tap scan, get back a number. If it’s high, some readers will close the tab.

Good. Let them. I’m not writing for the people counting my keystrokes. I’m writing for the ones who want something worth reading.

But “all of it is AI” is easy to misread, so I’ll be precise about what I’m actually claiming, and where I think the scanner gets it badly wrong.

What the scanner actually sees

Pangram is good at its job. I’ll give it that, and so will people far more adversarial than me. Limited Edition Jonathan, a writer I follow who makes a kind of sport out of beating tools like this, put it bluntly: it’s annoying, he finds it unethical, and he still hasn’t found a way to beat it. It’s accurate. I believe him.

Accurate at what it measures, though, is the catch.

It tells you a machine touched the words. It cannot tell you whether a person cared. It can’t see the months and years I spent learning what a sentence is supposed to do. The four passes I made stripping out every line that sounded like a robot are invisible to it. So is the fact that the idea underneath the piece is one I’ve been turning over for a decade. It sees texture, calls that texture “AI,” and a certain kind of reader treats “AI” as a reason to leave.

Substack’s own CEO, Chris Best, drew the line in a more honest place. He put the weight on ideas over words. Using a tool to get the words down is fine. The offense, in his framing, is passing off thinking you never did as your own. I agree with that completely. The thinking has to be yours. On that test, I’m not nervous about a scanner. I’ll take it.

How this newsletter actually gets made

Substack now suggests writers add a note explaining how they work. Happy to. Here’s mine:

I don’t sit down to a blank page. A model writes the first draft, fed on a pile of my own writing, my rules, and the list of things I refuse to say. Then the real work starts. I (or rather, now, my AI) cuts the generic lines, adds the specific number the model didn’t have but the context supplied, and kills every sentence that reads like it came off an assembly line - and there are always a lot of them, because that’s what first drafts are. What survives has to clear a filter I built that hunts down over thirty separate tells of machine writing. Only then does a human, me, read it end to end and decide whether it’s worth your inbox.

Call it the 80/20 split (moved from the 70/30 I used to tout). The AI does about eighty percent of the volume. The twenty percent I supply — the direction, the taste, the judgment, the deletions, the one true story — is where the entire value sits (and I manually added these em dashes, too bad Mr. AI Detector). Take that twenty out and you get slop, and you’d be right to close the tab. Leave it in and you get something I’ll put my name on.

That’s the part the scanner can’t grade. It counts the eighty. It has no field for the twenty.

The line I actually hold

I use AI for almost everything I ship. I also know exactly where I stop trusting it, and that line is the whole point.

Last week I wrote about the three checks I run before I trust anything a model hands me. The scanner news makes them matter even more, so here’s the checklist itself. Keep it near your desk.

Before you ship or send anything AI touched, ask three things, in order:

1. If this is wrong, can I undo it easily?

2. Does the cost of being wrong here justify how hard I’m checking?

3. Do I actually know it worked, or am I trusting a “done” message?

Most things pass all three in a couple of seconds. Editing a paragraph is reversible and low stakes, so you barely look. The moment something is permanent, or touches money, or touches another person’s data, the checklist tells you to stop and read it like your name is on it. Because it is.

That third check is the one almost nobody runs, and it’s the one that saves you. A tool saying it worked and the thing actually working are two different facts. I learned that watching one of my own tools print “POSTED” for a LinkedIn post that never went live, with a screenshot of somebody else’s feed saved as its proof. Now I look at the thing itself, not the log. Did the post appear on the profile. Is the file actually in the sent folder. Is the row really in the database when I go look.

That’s the bar. The bar isn’t whether a human typed every word. It’s whether a human owned the judgment. A scanner can’t see that. You can.

I promised that full checklist last week, and it’s yours. The complete version, with the reversibility triage, the over- and under-checking trap, and the verify-it-yourself list, lives here.

Where I get off the purity train

The reactions to Substack’s button split the way you’d expect, and the split is worth watching.

Some writers are treating the number like a verdict. High AI, low value, case closed. , who writes Product with Attitude, pushed back with a whole essay arguing the binary itself is broken. There’s a missing category, she says, between “human-made” and “AI-made,” and most careful work now lives there. She calls it AI-assisted craft. I think she’s right. The scanner offers two boxes for a job that clearly has three.

Then there’s the harder objection, the one I keep circling back to. , the same writer who admitted Pangram works, pushed the purity test to its logical end. Disclose your ghostwriter next. Then your spell-check. Then the operating system you typed on, and the way you did your research. Once “real writing” means “no machine touched it,” the standard quietly eats everyone, because a machine has touched all of it for years.

I don’t want to live on that side of the line. I’d rather tell you exactly how the work gets made, which I just did, than pretend a tool didn’t help. Transparency, all day. Purity theater, no thanks.

There were people who refused to use calculators, too. And computers. And the internet. I’m just not building for them.

What this means for you

If you write with AI and you’ve felt a little exposed this week, here’s the reframe. The scanner doesn’t change the real question, and the real question hasn’t moved in years: is the thing worth reading. AI makes it easy to produce more of everything. It does nothing, on its own, to make any of it worth someone’s time. That part is still yours. It’s the only part that was ever yours.

So stop hiding the tool. Start owning the judgment.

Making this very newsletter, the AI got a few things wrong, and I’d rather show you the seams than smooth them over. The tool that runs my publishing, the one I mostly let the AI drive, quietly set this week’s post to mail the whole list when I’d asked for web only. It never sent. I’d built the tool to refuse to publish unless it could first prove no email was going out, because publishing is the one place I don’t let the machine run unsupervised.

Same week, the tool told me a draft was ready, header image and all. I opened it anyway. No image, and my three-point checklist had collapsed into one unreadable line. The report said success. Success hadn’t happened. Each of those was an AI doing exactly what I asked and missing a detail, and each got caught the same way: I looked at the actual thing. The words are AI. The catches were mine.

Your ten minutes this week: take the last thing you made with AI and run it back through the three checks, then add a fourth for the writing itself. Would you still publish this if your name were the biggest thing on the page. If yes, ship it, and let anyone scan it they like. If no, the tool was never the reason. Go back and find the thirty percent you skipped.

PS. I build these guardrails into the system so the judgment doesn’t have to live in my memory: idempotent actions, and a verify-then-report gate with a human in the loop. If you want that discipline wired into your own AI setup instead of hoping you remember it every time, that’s the kind of thing I work on with people one on one.

Last week I gave you the three checks I run against anything an AI hands me before I trust it. Reversible or not. Consequence versus checking effort. And the big one, did I verify it myself or just believe the tool’s report.

I promised I’d hand over the actual checklist I run those three against. Here it is. Steal it, keep it next to your desk, and run your next AI output through it.

First, the thirty-second version

Before you ship or send anything AI touched, ask three questions in order:

1. If this is wrong, can I undo it easily?

2. Does the cost of being wrong here justify how hard I’m checking?

3. Do I actually know this worked, or am I trusting a “done” message?

If all three come back clean, ship it. If any one of them snags, that’s exactly where you slow down. Most AI output passes all three in a few seconds. The checklist isn’t there to slow you down everywhere. It’s there to tell you the one place to slow down.

Now the full version, one check at a time.

Check 1: Reversibility

The question: if the AI got this wrong, what does it cost me to fix?

Run down this list:

• Can I undo it in one click or one command? Editing a paragraph, re-running a draft. Green light, barely look.

• Does this write to something permanent? A database, a billing total, a live post, a sent email. Slow down.

• Could running it twice by accident do damage? If yes, it needs a guard before it needs your trust.

The rule I build into everything: a re-run or a script I fire twice can’t quietly cost me an afternoon. If an action isn’t safely repeatable, I make it safely repeatable before I let AI near it. Check-before-write. A dry run first.

Your ten-second version: is this edit-and-forget, or is this permanent? Permanent gets read.

Check 2: Consequence versus checking effort

The question: does the downside here justify the scrutiny, or am I wasting my attention?

There are two ways to lose here, and most people only guard against one.

Over-checking. You read every throwaway draft with the same intensity as production code, you burn out, and then, exhausted, you stop checking the things that actually mattered. Over-checking everything is how people end up checking nothing.

Under-checking. The first ten AI outputs were great, so you stopped looking. The eleventh quietly wasn’t, and it was the one that went to your biggest client.

The fix is to match effort to stakes, deliberately. A rough draft gets a glance. Client-facing copy gets a real read. Anything that touches money or someone’s data gets read like your name is on it, because it is.

And remember the thing a better model will never fix: context. A smarter AI still doesn’t know your biggest client hates being called a “partner,” or that one number in that report is the one your boss will circle. That’s not the model’s job. It’s yours.

Check 3: Did I verify it, or trust the report?

This is the one almost nobody runs, and it’s the one that saves you.

A tool telling you it succeeded and the thing actually succeeding are two separate facts.

I learned this watching automations report “done” while the actual thing hadn’t happened. So now, for anything that matters, I check the reality, not the log:

• The tool says the post published. Did it actually appear on the profile?

• The tool says the file sent. Is it in the sent folder, with the attachment?

• The tool says the record saved. Is the row actually there when I query it?

• The tool says “success.” Success at what, and can I see it with my own eyes?

The gap between “reported done” and “actually done” is small when models are bad, because they fail loudly. It gets more dangerous as models get good, because they fail quietly and confidently. The better your tools get, the more this check matters.

Your ten-second version: don’t read that it worked. Look at the thing.

How to actually use this

You’re not running a three-page audit on every prompt. That would be its own kind of failure.

Here’s the real rhythm. The reversibility and consequence checks happen in your head, in a second or two, and they tell you whether to bother. Ninety percent of the time the answer is “reversible, low stakes, move on.” The verify-it-yourself check is the one you actually stop and do, only on the small handful of things where being wrong is expensive and permanent.

That’s the whole system. Two fast filters that tell you where to look, and one real look where it counts.

Your ten minutes this week: take the last thing an AI did for you that actually mattered, something that sent or shipped. Don’t trust the confirmation. Go look at the real thing and confirm it happened the way you think it did. That habit, more than any model upgrade, is what separates people who build on AI from people who get surprised by it.

PS. I build these checks into systems so I don’t have to remember them: idempotency, and verify-then-report with a human in the loop. If you want that discipline wired into your own AI setup instead of living in your head, that’s what I do with people one on one: coaching.g8n.ai

I didn’t mark it done. I opened my own profile’s activity page and looked for the post myself. It was there, and the header image had rendered correctly, so I moved on. But sit with the gap for a second: a system reported success, and the success it reported was just a log line that happened to be true this time, coincidentally.

Last week I told you the scarce skill left over once AI gets good is judgment, not generation. The short version, if you missed it: AI writes clean, well-structured, confident-sounding output now by default, at zero cost and infinite volume. That used to be a decent proxy for someone knowing what they were doing. It isn’t anymore, because the model can fake the surface for free. What it can’t fake is the read that catches what’s wrong underneath the polish.

I promised to come back with how I actually run that review instead of just describing it from a distance. Here are the three checks, in the order I actually use them, plus the mistake that reminded me why check three exists.

Check one: is the mistake reversible?

I wrote about this back in April without knowing I’d need it again this week, in a note about deciding where to place my trust in AI. The real question is what happens if AI got it wrong.

A bad line of code gets caught in code review before it ships. A bad paragraph gets edited before anyone reads it. Both of those are cheap to undo, so I let AI move fast there and I review lightly. A LinkedIn post that goes out with the wrong link in its first comment costs real time to fix, and a lot of it is spent apologizing. A database write that silently duplicates a row nobody notices for three weeks costs even more, and it’s usually discovered by accident, weeks after the fact. The scrutiny I apply scales with how expensive a mistake is to reverse. How much I happen to trust the tool that produced the work has nothing to do with it.

I built this directly into the system behind this newsletter. Before it writes anything to my content ledger, it checks whether the row already exists. If it does, it updates. If it doesn’t, it inserts. The tool that schedules my Substack Notes does the same thing on the way in: it checks whether a note is already sitting in the queue before adding it, so running the import twice never creates two copies of the same post. Neither check is clever. Both of them mean a re-run, a retry, or a script I fire twice by accident can’t quietly cost me an afternoon of cleanup I wouldn’t have noticed I needed.

You don’t need a database to use this. A “solopreneur” running AI-drafted invoices can let the tool guess at line-item wording all day, because a clumsy sentence costs thirty seconds to fix. The total at the bottom is a different animal. Get that wrong and you’re either under-billing yourself or asking a client to fix your math for you. Same tool, same afternoon, two different reversibility levels depending on which field you’re looking at.

Check two: is the consequence proportional to how hard I’m checking?

I turn this dial per task. Code that touches production, I turn it up high, because a broken function costs me hours and maybe a client’s trust in the work. A first draft of a Note, I turn it down, because the worst case is I rewrite three sentences before I post it.

Most people I talk to run one setting for everything instead. Some check every output like it’s a nuclear launch code, burn out by week three, and quietly stop checking anything at all. Others stop checking after the first ten outputs look clean, and the eleventh one is the one that costs a client, or ships a number that was never real. An operator automating invoices needs the dial turned up on the total and turned down on the greeting line. A non-technical builder using AI to draft a contract needs it turned up on every clause with a dollar figure in it and turned down on the formatting.

I see the opposite failure most often in people who love the tools the most. The AI enthusiast who’s tried every new model the week it ships tends to trust the newest one the hardest, because it’s smarter than last month’s, and that’s true on average and useless for any single task in front of you. A smarter model still doesn’t know that your biggest client hates being called a “partner” in an email, or that the number in row 40 of your spreadsheet came from a source you stopped trusting last quarter. That context doesn’t come bundled with more capability, no matter how new the model is.

The dial has to move task by task. Check one, reversibility, is how I decide where to set it.

Check three: did I verify it myself, or did I trust the tool’s report of itself?

This is the one nobody talks about, and it’s the one that got me yesterday.

A tool telling you it succeeded and the thing actually succeeding are two separate facts. Written down like that, it sounds obvious. It stopped feeling obvious around 7am, with eleven items queued and the fastest path being to read the word “done” in a log and move to the next one.

The fix is a habit: for anything that matters, go look at the real state of the world instead of the tool’s description of it. A newer model doesn’t buy you out of this one. The same system that publishes my LinkedIn posts arms a follow-up comment five minutes after each one goes live, and every time, it re-opens the actual post and re-reads the actual comment thread before calling the job finished. That habit has caught real gaps. A comment the log marked as posted that never landed. A note scheduled for the wrong month because a date picker assumed the wrong one. None of those showed up anywhere in a success log. All of them showed up the moment I checked the real thing instead of the report about the real thing.

This isn’t only a developer problem. If AI drafts your client email and your inbox shows “sent,” that’s the tool’s report. Whether the client actually opened it, whether the attachment actually came through: the real inbox holds those answers. The confirmation screen is designed to make you feel done. Feeling done and being done are not the same event.

Why this matters more as models get better

I run more of my work through AI models today than I did a year ago, and that number keeps climbing every quarter. This is about exactly where trust has to stop: at the line between “the tool said it worked” and “I confirmed it worked.” Everything on the generation side of that line is fast, cheap, and getting cheaper by the month. Everything on the verification side of it is still yours to do, and it’s the part that doesn’t show up in a demo video.

That’s the part last week’s piece was pointing at without naming it directly. These three questions are what judgment actually looks like in practice, asked in order, on the thing in front of you, before you ship it or believe it.

As models get better, this gets more important. A worse model fails in ways you notice. It writes an awkward sentence, or the code doesn’t compile, and the failure announces itself. A better model fails quietly. The sentence reads fine. The code compiles and passes its tests and does something subtly different from what you actually needed. The confidence of the output stops correlating with how much you should trust it, and the three checks are what fill the gap that used to be filled by “well, it looked wrong.” Nothing looks wrong anymore. That’s exactly why you still have to look.

Do this in the next ten minutes

Pick one thing an AI tool did for you today that you marked done without checking. Run it through the three questions. Was the mistake reversible if the tool got it wrong? Was the consequence proportional to how little you actually checked? Did you verify the real result, or did you verify the tool’s report of the result?

If the honest answer to that last one is “the report,” go look at the real thing right now, while it’s still fresh enough to fix.

Next week, I’ll hand over the actual checklist file I run this against.

PS. Building the specific checks and systems that keep your judgment in the loop, instead of a tool’s word for it, is what I help operators do. If that’s the muscle you want built into your own work, the details are at coaching.g8n.ai.

Researchers at BetterUp and Stanford put a name to something you’ve probably received this week. They called it workslop. AI-generated work that shows up looking polished and professional and turns out to hold almost nothing.

You know the feeling. A document that’s formatted perfectly, hits every expected beat, and leaves you no smarter than before. A pull request that looks clean and quietly does the wrong thing. The surface is flawless. There’s nothing underneath.

Here’s what that tells you about where the value’s going.

The problem was never bad output

For years the knock on AI was that it produced junk. Garbled text, broken code, obvious mistakes. That mostly got solved. The new problem’s the opposite, and it’s worse.

These models default to polished. They produce work that looks expert on the surface, at zero cost and infinite volume. The grammatical errors are gone. The structure’s clean. A non-expert can now generate something that’s indistinguishable, at a glance, from the real thing.

So the old signals of quality stopped working. For a long time, competent-looking output was a decent proxy for competence. Clean writing meant a clear thinker. Working code meant a careful engineer. AI broke that link. The polish is free now, which means polish tells you nothing.

What’s left is the thing the model can’t fake. Judgment. Knowing whether the polished thing in front of you is actually any good.

Generation got cheap, so judgment got expensive

This is the whole shift, and most people have it backwards. They’re racing to generate more, faster. The leverage moved the other way.

When I build now, AI hands me five ways to solve a problem in about twenty seconds. Four of them look fine. One’s actually right for what I’m making, and knowing which one comes from twenty years of getting it wrong. That part doesn’t transfer to the model. It’ll give me options, but it can’t care about the specific thing I’m building, or notice the bug that only matters because of how someone uses it on a Tuesday.

I caught one of these last week, building a video game with an AI agent wired straight into the game engine through MCP. The agent decided the portraits and artwork needed to be generated fresh to match the rest of the art style. It sounded confident and entirely reasonable. It was also completely wrong, I’d already sourced the proper assets and applied them myself. I didn’t even need to argue with it. I’d built a guardrail earlier that runs every AI-generated-asset request through an evaluator before it can spend a single credit, and the evaluator caught what I already knew: the premise was wrong. That one check stopped 54 unnecessary portraits and a few hundred credits from getting burned on a problem that didn’t exist.

The work used to be production. Type the thing, build the thing, make the thing exist. The model does that now, at a quality that looks great and a price near zero. So the scarce work is the other half. Choosing. Knowing what to throw away. The taste to look at a pile of fine and pull out the one piece that’s correct.

That’s good news if you’ve got real experience in any craft. Your judgment is suddenly the rare thing, the one part the model can’t generate for you.

The trap hiding inside the good news

I want to be honest about the part that worries me, because it’s the part nobody selling you AI will mention.

Taste isn’t free either. Mine came from years of doing the exact low-level work AI now does for free. Writing the bad draft. Shipping the broken version and feeling it break. I read my own confident mistakes back to myself until they sank in. The judgment I lean on today got built by grinding through the grunt work yesterday.

So there’s a real risk in handing all of that to the model. If a new developer offloads every routine task to AI, they produce polished work on day one and never build the foundation that lets them tell good from bad on day one thousand. The apprentice who skips the apprenticeship never becomes the artisan. They just become a faster way to make workslop.

That’s the line to hold. Use AI to remove the tedium, not to remove the reps that build your eye. Automate the generation. Stay in the judgment seat. And keep doing enough of the hard work by hand that your taste stays sharp enough to be worth something.

Do this in the next ten minutes

Take one piece of AI output you were about to ship today. A draft, a function, an email, a plan. Don’t ship it.

Spend ten minutes doing the opposite of generating. Hunt for what’s wrong with it. What you’d cut. What a real expert would notice that the model missed. Where it’s polished on top and empty underneath. Mark it up like you’re reviewing a junior’s work, because that’s exactly what you’re doing.

That hunt is the skill. Not the prompt that made the draft. The read that catches what the draft got wrong. Do it once today, then do it every time, until reaching for the red pen is the most automatic thing you do.

The people who win the next few years will be the ones who can look at a sea of polished output and know, fast, which drop of it is real.

Next week: how I actually run that review, the specific things I check first, and where I’ve learned to stop trusting the model entirely.

PS. Building the judgment to tell good AI work from convincing junk, and the systems that keep you in the judgment seat, is what I help operators do. If that’s the muscle you want to build, the details are at coaching.g8n.ai.

Topics under discussion:

• Who I am: 20-year software developer, last 4 with AI, helping solopreneurs turn AI sprawl into a frictionless system they own and take back their week

• ‘s 1:1 AI builder offer and how her coaching, along with her supplied writing and scheduling software, enabled me to automate my entire content generation pipeline. Also, becoming a reseller for her writing software that saves me 7+ hours per week.

• Using Drift, Claudia’s professional AI-enabled writing software, plus the 49 PRs of additional AI-driven customizations I tweaked to enable scheduling and publishing on both Substack and LinkedIn, including the ability to generate images for the posts via my Gemini subscription using browser automation, and to build carousels for LinkedIn as well.

• Dispatching goals/projects via Discord to tmux-based Claude Code sessions (AI agents) on my server, an M5 Max MacBook Pro. It’s basically running a fleet of per-project AI Agents as well as an orchestrator that handles the dispatches I send with intelligent routing to the appropriate project, or offers to build the project itself, or instead to setup an appropriate new repo, new agent, and new discord channel to enable communicating with the fleet. Automatically launches the fleet if there’s an interruption or a restart.

• Resources for non-technical folks to be able to jump into AI, build momentum, and start saving their hours

One free thing to take with you: three common time sinks you can fix this week. No new tools, no obnoxious setup.

If a question came up while you were watching, reply below. I read every message.

P.S. If you want to automate the tedious parts of your content creation the way I did, you can pick up Drift here. And I’ll be back in the app with another live soon.

If you have any questions or an idea for my next post, please send me a reply! I read every message.

A few nights ago I cleared a failing check on a production app without opening my laptop. I typed one sentence into a Discord channel from my phone, set it down, and went back to my evening. About twenty minutes later a reply came back: the check was green, the fix was pushed, here’s exactly what changed. I read it, looked at the pull request, and merged it.

I didn’t write that fix. An AI agent did, running on a Mac at my house that I hadn’t touched in hours.

I want to be careful with how that sounds, because “autonomous AI agents” is the phrase everyone’s drowning in right now. Half the feed says agents will run your whole company by Friday. The other half says they’re a demo that collapses the second real work touches them. Both takes are exhausting, and neither matches what I actually use.

So here’s the unglamorous version. What I built, what it really did that night, the part nobody shows, and the much smaller version you could start with this week.

What it actually is

Strip away the word “autonomous” and it’s simpler than it sounds. I have a few Claude Code agents that stay running on an always-on machine. They coordinate through Discord, the same chat app a lot of people already use. One channel is where I drop tasks. Other channels are where the agents post what they’re doing.

When a task lands, an agent wakes up, does the work in the right place, and reports back. Because the machine’s always on, I can send that task from anywhere. My phone in a grocery line. A laptop that has nothing to do with the work. It barely matters where I am, because the thing doing the work isn’t the thing in my hand.

That’s the whole idea. A reliable place to drop a well-scoped task, and something on the other end that picks it up and finishes it while I go live my life.

What happened that night

Here’s the actual sequence, because the specifics matter more than the pitch.

I had a pull request open on one of my apps. The code was reviewed and clean, but one check stayed red: a security scan flagging known vulnerabilities in some dependencies. So I typed one line into my dashboard channel: make sure this pull request is fixed and the checks pass.

I did nothing else. A watcher noticed the message, started up the coordinating agent, and handed it the task. That agent figured out which project it belonged to, started the project’s own agent, and passed it along. The project agent dug in. It traced the failing scan to a batch of advisories published two days earlier, against libraries already in the project. My code was innocent. It bumped the flagged libraries, ran the entire test suite to make sure nothing broke, pushed the update, and posted a clear summary back to me. Then it waited for the checks to finish and confirmed every one of them went green.

The only things I did were type one sentence and, later, click the merge button. The diagnosis, the fix, the testing, the write-up: none of it was mine.

Why this is leverage, not magic

Here’s why it matters to me: the machine stays on when I don’t.

For most of my career, progress required me to be at a keyboard. If I stepped away, the work stopped. This flips a small but real piece of that. A bounded task can move forward while I’m at dinner, asleep, or three errands deep into a Saturday. I’m off the leash that ties getting something done to sitting at my desk.

I also want to be honest about the ceiling here, because the hype skips it. This is a long way from the AI running my business. It fixed a dependency advisory, the kind of narrow, checkable job I’d hand to a junior engineer and verify after. The judgment stayed mine. I read what came back. I decided to merge. An agent that can show me precisely what it did, with tests proving it, is one I’ll trust with a small task. The moment a task is fuzzy or the blast radius is large, I’m back in the loop, and that’s correct.

The part nobody shows

Now the unsexy truth, because building in public means showing the middle.

This system sat dead for two months. I’d set most of it up earlier and it never actually worked. The coordination table I built for the agents had twenty-five old entries, every one of them stuck or cancelled, none ever finished. It looked like infrastructure. It functioned like a brick.

Making it real took a long string of small, frustrating fixes. The agents stalled on every single action because they kept stopping to ask permission, so I had to give them a careful, scoped set of things they could do on their own. One stale setting silently blocked them from saving any work at all, and it took a while to even find it. The agents couldn’t hand tasks to each other, because they all share one chat identity and the system quietly drops a bot talking to itself, so I had to route the handoffs a different way. And my favorite: for an hour the whole thing was writing to the wrong database entirely, because one environment pointed somewhere I didn’t expect.

The clean, hands-off run I described at the top only happened after all of that. The autonomy is real, and it was earned the slow, annoying way. Anyone selling you the twenty-minute version is selling you the demo, not the Tuesday.

How the pieces fit, plainly

You don’t need to know any of this to get the point, but here’s the map in plain words.

There’s a tool that keeps programs alive on a machine after you disconnect from it. There’s the chat app, which is just my remote control: where I send tasks and read status from any device. There’s a coordinating agent whose only job is to receive a task and hand it to the right specialist. There are the specialist agents, each one living in its own project. And there’s a small watcher that boots the whole thing the instant a task arrives, so nothing has to burn power until there’s real work to do.

That last piece is the one I’m proudest of, because it means the system is asleep by default and only wakes for a real request.

You don’t need the whole fleet

Here’s where I talk you out of copying me exactly.

I run this because I ship across a lot of projects and I’m away from my desk constantly. That’s a specific situation. You almost certainly don’t need a dozen agents and your own chat server. If you build the full thing because it sounds cool, you’ll spend your weekend debugging plumbing instead of getting the one benefit that actually matters.

The benefit worth stealing is small. It’s the habit of handing a bounded, well-defined task to an agent and trusting it to run without you watching every keystroke. Everything else, the dispatch-from-your-phone part, the coordination, the always-on machine, is convenience you bolt on later, once that core habit is reliable.

The small version you can start with

You can get most of the value today with nothing I have. Open Claude Code, or whatever AI coding tool you use, and give it one task with a clear finish line. Make it concrete: update these dependencies and make sure the tests still pass, then tell me what changed. Then walk away for ten minutes and let it run.

When you come back, actually read what it did, the way you’d read a junior teammate’s work. That single loop, a bounded task plus a clear way to check it plus the discipline to actually check, is the entire foundation everything else sits on. The remote control and the agents are plumbing that sits on top of that habit.

If you do want the always-on, send-it-from-your-phone version built around your real work, that’s the kind of system I help people set up. But earn the habit first. The plumbing is worthless without it.

Your ten-minute start

Pick one task you’d normally babysit. A dependency bump. A test that needs writing. A small refactor you keep putting off.

Write two sentences before you hand it over. The first says what done looks like. The second says how you’ll know it worked: the test or the check or the output you’ll look at. That second sentence is the one most people skip, and it’s the one that makes an agent trustworthy instead of hopeful.

Then give it the task and leave for ten minutes. Come back and read the result like it’s someone else’s work, because it is.

Do that a few times and you’ll feel the shift. Mostly it feels like getting a piece of your attention back. That’s the whole game. Start with one task you can walk away from. The rest is plumbing.

GPT-5.5 landed a couple of weeks ago. Six weeks after 5.4. The same week, another lab shipped a model that beat it on three benchmarks, and by the time you read this there’ll be a newer one with a louder launch (edit: this happened already, Fable 5 is out from Claude, based off Mythos).

I’ve built software for twenty years and used AI seriously for the last four. And I still feel the pull of that noise. The sense that if I’m not reading every release thread, testing every tool, and forming an opinion on every model, I’m somehow falling behind.

I want to tell you the truth about that feeling. It’s overwhelm. And overwhelm is the thing that actually keeps people stuck, far more than any gap in what you know.

The noise is not the work

Here’s what the feed never says out loud: most companies haven’t finished deploying the model they bought eight months ago. The average enterprise takes the better part of a year to change how people actually work. Meanwhile a new frontier model ships every few weeks (months at the latest), and every one of them gets treated like a deadline you missed.

It isn’t a deadline. Swapping models is easy. Changing how you work is hard. The people getting real value out of AI right now picked a couple of tools, went deep, and rebuilt one piece of their actual work around them.

I’ve watched this from both sides. I use Claude, ChatGPT, and Gemini depending on the job. I could spend every evening chasing the next release. Instead I spent the last year shipping things: a polling app a professor now uses with dozens of students and multiple classes, a self-hosted email system that replaced a stack costing hundreds a month, a handful of other tools my kids and my peers actually use, an AI agent per project on a dedicated server with an orchestrator that can pickup requests from Discord and dispatch messages to the proper agent. Every one of those came from picking one problem and refusing to let go until it worked.

Overwhelm has a shape

When I slow down and look at the overwhelm, it always has the same shape. Too many options, no clear next step, and a quiet fear that everyone else already gets it.

Collecting tools feels like progress. You download the app, you bookmark the tutorial, you can name the feature that shipped this morning. None of it changes your Wednesday. The work that changes your Wednesday is narrower and far less exciting. You take one task you do by hand every week and you build something small that does it for you.

That gap, between knowing about AI and using it, is where most people live. It’s also where the overwhelm comes from. You’re carrying the weight of everything you could be doing and the guilt of doing none of it.

You can put that weight down. You don’t need to know everything. You need one problem and a path through it.

How I actually cut through it

The method is almost boringly simple, and it’s the same one I use whether I’m building a product or writing this newsletter.

Start with one sentence. Before I open any tool, I write a single sentence describing what done looks like. When I built that polling app, the sentence was: a system where a professor can ask a question and see every student’s answer in real time. One clear outcome, stated plainly. If you can’t write that sentence yet, you’re not ready to build, and that’s useful to know too.

Treat AI as a collaborator, not a vending machine. Roughly seventy percent of the volume comes from the AI. The other thirty percent is direction, review, and judgment, and that thirty percent is where the value lives. I read what it gives me. I push back. I don’t ship anything I couldn’t explain to another person.

Ship the ugly version. My first builds barely work. The polling app shipped rough but functional. Hundreds of hours of small (and large) fixes later, a university professor trusted it with real students. Shipping early means shipping the smallest thing that proves the idea, then improving it against reality.

That’s the whole method: pick a real problem, describe the outcome in a sentence. Then, let the AI do the heavy lifting while you keep the judgment. Ship something rough and improve it. None of it requires you to have an opinion on this week’s model.

What this looks like in practice

Let me make it concrete with something small. A while back I was paying for a stack of subscriptions just to send email to my list. Add up the email tool, the automation, the database, and the monitoring, and it came to a few hundred dollars a month for software I didn’t own and couldn’t change.

I decided not to keep paying it. Over a few days I described what I wanted in plain language and built my own version. Email sending, automations, a database I control, alerts when something breaks. It runs for about thirty-four dollars a month now.

I’m not telling you to go self-host your email this afternoon. The point is the shape of it. I just named one expensive annoyance, described the outcome in plain words, built the rough version, then fixed it when it broke. The email provider even rejected my application twice with no explanation. I pushed back, asked for a real reason, and a few days later they approved me. Friction is part of it. You work through it one piece at a time, and on the other side you own something.

But here’s the part that matters for you. None of my builds started big. I made a playable game in one hour. A coaching tool for my own writing took three. A podcast production workflow took six. A LinkedIn scheduling tool took twelve. A bigger writing app took dozens of hours. The polling app took hundreds, across more than a thousand prompts. That ladder is the whole point. The thousand-hour thing only ever looks possible after you’ve climbed the one-hour and three-hour steps in front of it. You start at the bottom, with the smallest version that works, and the next one gets easier.

It’s the same move whether you’re building an email system, a small dashboard, a polling app, or a way to draft your week’s content: small problem, clear outcome. Rough first version, steady improvement.

What I ignore on purpose

Cutting through overwhelm is as much about what you ignore as what you do.

I ignore most launches. When a new model ships, I note it and move on. If something I use gets meaningfully better, I feel it in the work without reading a single thread. The model is rarely the thing holding you back anyway. Context is. Knowing what you’re building, and giving the AI enough of the right information, matters far more than which model you point at the problem.

I tune out the pressure to use ten tools. I use a few and I know them well. A hundred dollars a month for the AI I actually build with does more for me than a folder of trials I never opened twice.

And I ignore the voice that says everyone else already figured this out. They didn’t. Most people are exactly where you are, scrolling, a little anxious, waiting for permission. You don’t need anyone to hand you that permission. You can just start.

Why this newsletter is changing

This is the part where I tell you what I’m doing differently, because it’s the reason you’re reading this.

For the last stretch I published when I felt like it. Some good things came out of that, and some weeks went quiet while I was heads down building. Going forward, G8N•AI has one job and one rhythm.

The job is to help you end AI overwhelm. Every week I’ll show you one real thing I use, the tech, a tool, or a framework, and exactly how I use it. The actual move, with the actual tradeoffs. You’ll be able to take it and run with it yourself. And when you’d rather not go it alone, there’s a path to do it together. You don’t have to become the expert. You have to know where you’re trying to get to, and I help you see the line from where you are now to there. That’s what the coaching is. Same method, with me in the room.

The rhythm is weekly. One reliable signal in a noisy feed. I’m committing to it because there’s always something real to say about cutting through the noise, and because a thing you can count on is worth more than a thing that shows up whenever it feels like it.

This is for you whether you run a one-person business, have never written a line of code, follow every AI thread for the sport of it, or have shipped software for twenty years like I have. The overwhelm is the same across all four. So is the way out. One problem, one path, one week at a time.

Your ten-minute start

Don’t close this and go read three more articles about AI. That’s the overwhelm talking.

Take ten minutes right now instead. Open a blank note. Write down one thing you do by hand every week that you quietly resent. The report you rebuild. The message you retype. The numbers you copy from one place into another. Name it in one sentence, the way I name an outcome before I build.

That sentence is the entire beginning. A real problem that annoys you, written down where you can see it.

Next week I’ll show you how I take a sentence like that and turn it into something that works. Bring yours.

I do this on occasion, going into “monk mode,” when I’m focused on delivering products and getting things out the door for clients. But it’s not a reason to push the content I’ve already produced down the line so I can post it live, rather than trusting the scheduler or worrying about algorithm effects. I have systems in place, and schedulers, but I couldn’t overcome the “try to make it perfect” mindset instead of trusting in my own judgement and efforts, the research and analysis of others who’ve proven it works, and the social proof I’d already witnessed (my own as well as that of others who I follow).

That changes right now. Don’t get me wrong, some of it was a good reason - I was heads down building! Some of it was due to a medical procedure and the recovery after. And some of it, if I’m being straight with you, was that I’d been quietly rethinking what this newsletter is even for.

I figured it out. So here’s where things stand:

G8N•AI has one job now - helping you end AI overwhelm.

You know the feeling. A new model drops every few weeks. There are a hundred tools, each one promising to change your life. And underneath it all, the nagging sense that everyone else already gets it and you’re behind. I’ve built software for twenty years and used AI seriously for three, and I still feel that pull. So I know it’s not a knowledge problem. It’s overwhelm. And overwhelm is the thing that actually keeps people stuck.

Cutting through it is the whole point of this newsletter.

Here’s what’s changing. One issue a week, same job every time: I show you one real thing I use, the tech, a tool, or a framework, and exactly how I use it. Not just theory, but the actual move, with the actual tradeoffs. You can take it and run with it yourself, or we can do it together.

One reliable signal in a very noisy feed. That’s what I’m committing to.

A small heads-up: over the next couple of weeks you’ll hear from me a bit more than usual. I’m opening up a live workshop, and I want you to have every detail to decide if it’s for you. If it’s not your thing, no problem. The weekly issues keep coming either way.

The first real issue lands this week. It’s about the one move I make to cut through the noise every single time, whether I’m building a product or writing this email. And it’s about ending AI overwhelm.

Thanks for still being here. I mean that.

Ahad

PS. If there’s one AI thing you keep meaning to figure out and never quite do, hit reply and tell me what it is. It might just become an issue.

Share

Episode 009: Building Community (What Actually Happened)

Building in public means showing the real numbers, the experiments that didn’t work, and the pivots that emerged from doing the work. This episode covers:

- The honest numbers: 131 followers, 61 subscribers (not the 100 I targeted)

- The workshop experiment that didn’t go as planned

- The repositioning insight: expert rapid builder vs. teacher of vibe coding

- How I use Claude to plan, strategize, and iterate on content

- The prompts and process behind AI-assisted content creation

- What’s coming in Season 2

Current projects mentioned:

- uPoll.live — course engagement platform, university pilot

- BuildWith — builder/client marketplace

- QueryBase — writers’ SaaS for share agent database to use as a querying and research platform

- Landing page/lead magnet tool (in development)

The repositioning:

I can validate your business idea in 14 days. The opportunity cost of waiting is real. That’s the offer.

Get involved:

- What do you want Season 2 to cover?

- What tools would help your work?

- Reply, comment, or DM — the community shapes what comes next.

Subscribe: g8n.ai/subscribe

Share

You’ve read about vibe coding. You’ve seen what’s possible. You’re curious.

But you haven’t actually built anything yet.

That’s fine. Everyone starts somewhere. This is the guide I wish I had when I started—not theory, not philosophy, just what to do on Day 1 and every day after.

By the end of seven days, you’ll have shipped something real. Something you use. Something that proves to yourself that you can do this.

Let’s go.

Before You Start: The Only Tool You Need

Forget the complicated setups. Forget the YouTube tutorials about “the perfect AI stack.” You need one thing:

An AI assistant you can have a conversation with.

I recommend Claude. Not because it’s the only option—but because it specifically handles the things that matter for building: complex multi-file work, database design with security considerations, payment integrations, real-time architecture, and maintaining context across long sessions. The entire BuildWith marketplace I’ll show you later was built with Claude.

Which tier matters:

Pro: $20/mo - minimum for serious building

Max: $100/mo - recommended for production projects

Max+: $200/mo - heavy AI leverage, multiple projects

If you’re just starting, Pro is fine. If you’re building something real that you plan to deploy, Max is worth it. One subscription handles everything from ideation to deployment.

Free tiers work for your first experiments. But when you’re ready to build something production-grade, the paid tiers are where the capability lives.

Share G8N•AI

Day 1: Pick Your First Problem

Don’t start with “I want to build an app.”

Start with: “What do I do manually that annoys me?”

Look for something you do at least once a week. Something repetitive. Something that makes you think “there has to be a better way.”

Good first projects:

• A checklist you recreate every week

• A template you fill out repeatedly

• A calculation you do by hand

• Information you look up over and over

• A reminder system that doesn’t exist yet

Bad first projects:

• “An app like Uber but for...”

• Anything involving payments - save this for later, unless you have guidance or already know what you are doing when it comes to this

• Anything involving user accounts - save this for later, unless you can easily integrate an auth & auth solution - and if you don’t know what that is, you probably can’t

• Anything you’d need other people to use immediately

The goal for Day 1: Write one sentence describing your problem.

Not the solution. The problem.

“I waste 20 minutes every Monday creating the same meeting agenda template.”

“I can never remember which client prefers email versus Slack.”

“I manually calculate my freelance project profitability every month and I always mess up the formula.”

That sentence is your foundation. Everything else builds from there.

Spend the rest of the day, or however long you feel you need, putting together what you want in terms of features, workflows, journeys - however you want to think of your problems and what would work to solve them.

Leave a comment

Day 2: Describe What “Done” Looks Like

Open Claude (or your AI of choice). Start a new conversation. Paste your problem sentence. Then add:

“I want to solve this. What would a simple solution look like?”

Don’t accept the first answer. Push back. Ask questions. Have a conversation. Use the rest of the material and context you thought through on Day 1 and have the AI challenge your thinking, your approach, your assumptions, and your level of understanding.

The AI will probably suggest something too complicated. That’s fine. Say: “That’s too complex for a first version. What’s the simplest thing that would actually solve my problem?”

Keep going until you can describe “done” in one sentence.

“A single-page checklist that I can reset with one click.”

“A simple lookup tool where I type a client name and it shows their communication preference.”

“A calculator where I input hours, rate, and expenses and it shows my actual profit.”

The goal for Day 2: Write one sentence describing what the finished thing does.

Not how it works. What it really does, and how that ties back to solving your problem.

Day 3: Build the Ugly Version

Today you build. And it will be ugly. That’s the point.

Go back to your AI conversation. Say: “Help me build this. I want the simplest possible version that works.” Start from there, and don’t worry, you haven’t lost all that other context you’ve given it, because with memory capabilities and Claude Projects, you can have the AI review your other chats and any files you attach to your Claude Project. So for now, build the minimum viable solution to your specific problem.

If you’re comfortable with code or the terminal, at least, the AI can write it for you and you can stick with my recommendation of using Claude Code in the terminal. If you’re not, ask for a no-code approach—there are visual builders like Notion, Airtable, or Google Sheets that can handle simple tools.

For something more interactive, try one of these visual AI builders:

• Replit — Good for code-based builds with AI assistance, and the one I actually recommend, pay for and use regularly for products, including uPoll, which is continuing to be piloted at UTA, with new updates, bugfixes and feature improvements almost every day (usually via Claude Code, even if we still deploy via Replit before shifting to our production systems).

• Lovable (lovable.dev) — Builds React apps from descriptions

• Bolt (bolt.new) — Similar, builds full applications

Don’t worry about picking the “right” tool. Pick one and start.

You will hit errors. Things won’t work. This is normal.

Remember: Generate → Lint → Fix → Test → Fix → Repeat.

That’s not failure, that’s the actual workflow. I go deeper on this in the workshop - more on that below!

When errors happen:

1. Copy the error message

2. Paste it to your AI

3. Say: “I got this error. What went wrong?”

The AI will explain and suggest a fix. Try the fix. If it doesn’t work, tell the AI what happened. Keep going.

The goal for Day 3: Have something that works, even if it’s ugly.

“Works” means it does the thing you described on Day 2. Not perfectly. Not beautifully. It just does the thing.

Maybe you've already tried building something. Maybe you hit a wall—Bubble couldn't do what you needed, the AI output was garbage, the whole thing fell apart. That's actually a good sign. You've validated that the problem matters. Now you need a better approach.

Subscribe now

Day 4: Use It For Real

Today, no building. Today, you use the thing you made.

This sounds obvious. It’s not. Most people build something and then never actually use it. They move on to the next idea.

Don’t do that.

Use your tool for its intended purpose. If it’s a checklist, run through the checklist. If it’s a calculator, calculate something real. If it’s a lookup tool, look something up.

While you use it, notice what’s annoying. What’s missing. What’s confusing.

The goal for Day 4: A list of 3-5 things that bug you about your own tool.

Write them down. These become tomorrow’s improvements.

Day 5: Fix One Thing

Pick the most annoying item from your list. Just one.

Go back to your AI conversation (or start a new one with context about what you built). Describe the problem: “When I use this, [X] is annoying because [Y]. How do I fix it?”

Fix that one thing. Test it. Make sure it works.

Don’t fix everything. Just one thing.

The goal for Day 5: Your tool is slightly better than yesterday.

This is iteration. This is how real software gets built. Not in one perfect session, but through repeated small improvements, and a short feedback loop: test, track, iterate.

Day 6: Make It Accessible

Your tool works. You’ve used it. You’ve improved it. Now make sure you can actually get to it when you need it.

If it’s a web page, bookmark it.

If it’s a spreadsheet, pin it to your home screen.

If it’s code running locally, figure out how to launch it easily.

The best tool in the world is useless if you forget it exists. Make access effortless.

The goal for Day 6: You can open your tool in under 5 seconds. Optionally (though I always do it), make it so that you can easily deploy/update it. You want to be able to spot an improvement or bug, get a fix in place with the help of AI, and push it out to test/validate that it did in fact get fixed as quickly as possible.

Day 7: Reflect and Decide

You built something. You used it. You improved it.

Now ask yourself two questions:

1. Did this solve the problem I started with?

If yes, great. You have a tool. Keep using it. Keep improving it when things bug you.

If no, that’s valuable too. You learned something about what the problem actually is. That’s progress.

2. Do I want to keep building?

Some people do this once and they’re satisfied. Problem solved, move on.

Some people get hooked. They start seeing problems everywhere that could be solved the same way. They want to build more.

Both are valid. But if you’re in the second camp, you just discovered something important about yourself. As always, I delve deeper into this during the workshop, which I give details on below.

Share G8N•AI

What You’ve Proven

In seven days, you went from “I’ve never built anything” to “I built a thing and I use it.”

That’s not a small thing. Most people never do it.

You proved you can:

• Identify a real problem

• Describe a solution

• Work with AI to build it

• Handle the debug cycle (it’s normal, not failure)

• Use it and improve it

• Make it part of your workflow

The next build will be faster. You’ll know the rhythm. You’ll trust the process.

And the build after that will be faster still.

Key Takeaways

Five things to remember:

1. AI accelerates, doesn’t replace. You still need to understand the patterns. The judgment is yours.

2. Security first. Even for simple tools, think about who can access what. For production apps: authentication, input validation, access controls.

3. Debugging is normal. The Generate → Fix → Test → Repeat cycle isn’t a sign of problems. It’s how this works.

4. One tool, full stack. Claude handles planning, design, frontend, backend, devops, testing. You don’t need to learn five different tools.

5. Cost-effective leverage. $100/month for capabilities that would require a team. That’s the new reality.

   Subscribe now

What’s Next

If you want to keep going, here’s the pattern:

Week 2: Build something slightly more ambitious. Two features instead of one. A little more complexity.

Week 3: Build something you’ll share with one other person. A friend, a colleague. Get feedback from someone who isn’t you.

Week 4: Build something that solves a problem for someone else entirely.

Each week, you expand the scope slightly. You stretch into new territory. You learn what you don’t know.

That’s the whole game. Repeat until you’re building things you never thought possible.

And, if you go through this and find that building, while enabling you, takes too much time by yourself, or you aren’t willing to go through the trouble without guidance, you can always build with me during the workshop—details below!

What This Looks Like With Experience: The BuildWith Story

A couple of days ago, I built BuildWith: a two-sided marketplace connecting AI builders with clients. Production-ready with payments, messaging, security scanning. In a single day.

Here’s the honest truth: This is what 20 years of software engineering plus 3 years of building with AI looks like. Experience compounds. I’m not one or two steps ahead of someone starting out, I’m 10 or 20 steps ahead. And it’s crazy how much leverage AI can give you - I’ve built more apps in the last 12 months than I have in the previous 12 years!

But that’s the point. When you start doing this and build this leverage and learn these patterns, you can get here too. What I did in a single day, you can sustainably do in a week. And it’s only going to get faster and better as AI improves and the intelligence infrastructure - the pipelines, the capabilities - keep advancing.

Here’s what actually happened:

The Numbers

Commits: 28

TypeScript Files: 144

Database Tables: 10

Supabase Migrations: 24

E2E Test Suites: 7

Unit Test Files: 3

Build Time: Single Day

Subscribe now

Phase 1: Foundation (Before Any Features)

Before writing any code, I created a dedicated Claude Project using the Claude MacOS desktop client, and I used the first chat thread to describe what I wanted to build, and had it do deep research on competitors, features, roadmaps, as well as to come up with appropriate Claude Project instructions for the project. I update the project instructions with the results after some review and fine-tuning, then started a new chat and started having a conversation with Claude to figure out the plan, design, things I wanted in the MVP, strategy for building, etc. I ended up manually creating the initial code project directory with a CLAUDE.md file, which serve as persistent instructions that guide every conversation in Claude Code, the terminal-based interface I used in this case for the actual development of the marketplace.

NOTE: You don't need to understand this file in its entirety. The point is: I documented the patterns I wanted Claude Code to follow, so every conversation started with shared understanding. Now, here's what that looks like:

# CLAUDE.md

This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.

## Project Overview

BuildWith is a two-sided marketplace connecting AI/vibe coders (Builders) with clients seeking custom builds, template personalization, and repo customization. Deployed at buildwith.g8n.ai.

## Commands

```bash
npm run dev      # Start development server (localhost:3000)
npm run build    # Production build
npm run lint     # Run ESLint
```

## Tech Stack

- **Framework**: Next.js 16 (App Router), React 19, TypeScript strict mode
- **Database**: Supabase PostgreSQL with Row Level Security
- **Auth**: Clerk (Google, GitHub, LinkedIn, email)
- **Payments**: Stripe Connect Express (milestone-based escrow)
- **Realtime**: Supabase Realtime (messaging, notifications)
- **Styling**: Tailwind CSS v4 + shadcn/ui
- **State**: TanStack React Query for client-side data fetching
- **Forms**: React Hook Form + Zod resolver

## Architecture

### Route Groups
- `(auth)` - Authentication pages (sign-in, sign-up, onboarding)
- `(dashboard)` - Protected dashboard with role-based navigation
  - `/client/*` - Client features (post projects, manage applications, milestones)
  - `/builder/*` - Builder features (browse projects, listings, applications, earnings)
- `(marketing)` - Public marketing pages
- `/builders/[id]` - Public builder profile pages

### Supabase Integration
- **Server**: `createSupabaseServerClient()` from `@/lib/supabase/server` - uses Clerk JWT via `auth().getToken()`
- **Client**: `useSupabase()` hook from `@/lib/supabase/client` - uses Clerk session token
- **Admin**: `createSupabaseAdminClient()` from `@/lib/supabase/admin` - bypasses RLS for system operations
- **Types**: Manual types in `@/types/database.ts`

### Server Actions Pattern
Located in `src/app/actions/`:
- `builder.ts` - Builder profile, listings, applications
- `project.ts` - CRUD for projects, application accept/reject
- `milestone.ts` - Milestone management and payment flow

All server actions follow this pattern:
```typescript
type ActionResult<T = void> =
  | { success: true; data?: T }
  | { success: false; error: string };

export async function actionName(input: Input): Promise<ActionResult> {
  // 1. Auth check via auth() from Clerk
  const { userId } = await auth();
  if (!userId) return { success: false, error: "Unauthorized" };

  // 2. Zod validation
  const validated = schema.safeParse(input);
  if (!validated.success) return { success: false, error: validated.error.errors[0].message };

  // 3. Supabase operation with RLS
  const supabase = await createSupabaseServerClient();
  // ... operation

  // 4. Cache invalidation
  revalidatePath("/path");
  return { success: true, data: result };
}
```

### Validation Schemas
Located in `src/lib/validations/`:
- `builder.ts` - Profile, service listings, applications, filters
- Schemas defined in server action files for project/milestone operations

### User Roles
Three roles stored in `profiles.user_type`: `client`, `builder`, `admin`
- Role hooks in `@/lib/clerk/hooks.ts`: `useUserRole()`, `useIsBuilder()`, `useIsClient()`
- Dashboard sidebar in `@/components/layout/dashboard-sidebar.tsx` auto-switches navigation based on role

## Code Conventions

- TypeScript strict mode, avoid `any` types
- Zod schemas for all input validation
- Server Components by default, `"use client"` only when needed
- Named exports only (no default exports)
- Mobile-first Tailwind classes
- Use React Query for client-side data fetching with `useSupabase()` hook

## Database Tables

| Table          | Purpose                                          |
|----------------|--------------------------------------------------|
| profiles       | User data, linked to Clerk ID                    |
| projects       | Client project postings                          |
| applications   | Builder proposals for projects                   |
| milestones     | Payment stages with escrow status                |
| services       | Builder service listings                         |
| conversations  | Chat threads                                     |
| messages       | Individual messages                              |
| reviews        | Bidirectional ratings                            |
| notifications  | User notifications                               |
| security_scans | Snyk vulnerability scan results for deliverables |

## Security Requirements

- RLS policies on ALL Supabase tables
- Auth check at data layer (server actions), not just middleware
- Validate all inputs with Zod before database operations
- Verify Stripe webhook signatures
- User can only access their own data (enforced by RLS using `auth.jwt()->>'sub'`)

## Supabase Migrations

Migrations stored in `supabase/migrations/`. Apply via:
```bash
# Using Supabase MCP (preferred)
mcp__supabase__apply_migration

# Using CLI
npx supabase db push
```

This isn’t just documentation—it’s instructions that shape how Claude Code understands and extends the codebase. Every conversation started by reading it.

And this shape of the CLAUDE.md file? It’ll change by tomorrow, when I spend another day on it, making updates from feedback and piloting users, online research around the features and capabilities available in similar or competing marketplaces, safety and compliance checks, performance updates, or data gathered from folks helping me to test and iterate and improve this builder/client marketplace so that we can put together a template, if not a complete solution.

The template could serve as the basis for future workshops where we focus on clients getting to personalize and build their own marketplace rapidly using a pre-existing structure and minimum set of features.

Share

Phase 2: Core Features

Once the foundation was solid:

• Project posting and browsing

• Builder applications with proposals

• Milestone system with escrow tracking

• Real-time messaging

• Notification system

Phase 3: Design System

One significant commit overhauled the entire UI:

• Dark-first luxury aesthetic

• 760+ lines of CSS custom properties

• Theme switching (dark/light/system)

• Glassmorphism, mesh gradients, glow effects

Phase 4: Payments

• Stripe Connect Express for builder payouts

• Webhook handlers for all async events

• Escrow pattern (happy path complete, rejection path under design):

  • Client funds →

    • Status “funded” →

      • Builder delivers →

        • Client approves →

          • Transfer to builder (85%) + Platform fee (15%)

        • Client rejects (TBD, still reviewing what works best here) →

          • Feedback gathered and submitted back to Builder for Revision

          • Revisions negotiated between builder and client prior to escrow process

          • Client can opt for project/contract dismissal

            • 25% cancellation fee charged to client from current milestone price for 15% platform fee and 10% builder compensation regardless of dismissal.

            • Any milestones previously hit by builder will already have been awarded/paid out and had the platform fee collected, thus will not be refunded to client.

          • Delivered content for current milestone locked out to client after gathering feedback.

          • All deliveries to client from prior milestones will remain available to them, as that portion of the transaction is already paid out and considered complete.

Refer a friend

Phase 5: Security & DevOps

• Snyk integration for dependency scanning

• Security scanning on builder deliverables

• CI/CD pipeline with GitHub Actions

• Rate limiting middleware

Phase 6: QA & Fixes

Multiple commits fixing TypeScript errors, ESLint warnings, test selectors, formatting. This phase is important to understand:

The real workflow is: Generate → Lint → Fix → Test → Fix → Repeat.

AI doesn’t produce perfect code on the first pass. The git history shows fixes for strict null checks, type mismatches, unused imports, build-time vs runtime errors. This is normal. This is expected. The debugging cycle is part of the process, not a sign something went wrong.

The Cost

Claude Max: $100 per month

Vercel: Hobby Free

Supabase: Free tier - $0

Clerk Free: 10K MAUs - $0

Sentry (if you want to go that route instead of keeping it simpler up front): Free - 5K errors - $0

Total: $100/mo

$100/month for capabilities that would take a team. That’s the leverage.

Give a gift subscription

Why This Matters For You

The 7-day framework I supplied you with above is the sustainable version of what I compressed into one day for folks who don’t do this regularly. The speed came from experience with these patterns—patterns you’ll learn by doing.

What’s possible: BuildWith in a single day.

What’s sustainable for newcomers: The same quality in a week.

The gap closes faster than you think. And every month, AI gets better. The intelligence infrastructure improves. What takes a week today might take two days next year.

Workshop: Build With Me

I’m running a live workshop on Sunday, January 25th.

Three hours. Three spots. Everyone walks out with a working frontend prototype.

The goal isn’t to watch me talk. The goal is to build. I’ll walk through my exact process—the same approach behind uPoll, UltraPost, BuildWith, and everything else. Then we build together. You work on your project, I provide guidance and troubleshooting in real-time.

Investment: Normally $997. First run: $249.

Why the discount? I want three people who are serious about building, and I want to refine the format and the framework I’m putting together. You get a deal. I get proof. We both win.

I’m qualifying by project scope. Three hours is enough to get a working prototype if the scope is right. If your idea is too big, we won’t hit that goal, and I’d rather say no upfront than have you walk away frustrated.

Interested? Reply to this email or DM me with your project idea. I’ll tell you if it fits.

Next up: “Why Owning Your Tools Matters More Than Saving Money”—the real reason I build my own software. Subscribe so you don’t miss it.

Notes / Links

• The Vibe Coding Playbook: How I Actually Build -

• What Vibe Coding Actually Is -

• Software Sovereignty post: What If You Owned Your Tools Instead of Renting Them? -

Visual builders mentioned:

• Replit

• Lovable

• Bolt

AI recommendation:

• Claude Subscription

  • Pro $20/mo - minimum. Good enough for most people who are solving small pain points and first beginning to leverage AI to build things.

  • Max $100/mo - recommended. For folks serious about continuing beyond the prototypes and single-person artifacts they are putting together and getting comfortable building.

  • Max $200/mo - serious for heavy AI use. This option is for if you’re going to be full time on a project or building out your brand/business and willing to learn about and leverage multiple agents running in parallel or across multiple projects for you.

Projects mentioned:

• BuildWith — buildwith.g8n.ai

• uPoll — upoll.live

• UltraPost — ultrapost.g8n.ai

Share

I've shipped more in the last 12 months than in the previous 12 years.

A course engagement platform piloting at a university. A LinkedIn tool in beta. Games I'm building with my kids. Custom tools I'm building in public with peers.

All of it built the same way: describing what I want, iterating until it works, and applying judgment throughout.

Last week I wrote about what vibe coding actually is.

Today I'm sharing the exact system; including where it falls apart.

The Three Pillars

Pillar 1: Start With a Clear Outcome, Not a Feature List

AI can't read your mind. It doesn't know what "good" looks like for your specific situation.

Before I open any tool, I write one sentence describing what success looks like. Not a feature list. Not a technical specification. One sentence about the outcome.

When I started building uPoll, the sentence was: "A system where professors can broadcast questions to students in real-time and see responses instantly."

That clarity shaped every decision. When features got suggested that didn't serve that outcome, I said no. When I got stuck, I returned to that sentence to figure out what actually mattered.

The discipline isn't technical. It's knowing what you're building before you start building it.

Tactical takeaway: Before your next build, write one sentence.

"A tool that does [X] so that [Y] happens."

If you can't write that sentence, you're not ready to build yet.

Share G8N•AI

Pillar 2: Treat AI as a Collaborator, Not a Vending Machine

The critics who say vibe coding produces garbage aren't entirely wrong. If you treat AI like a vending machine - insert prompt, receive code, deploy without thinking - you'll get exactly what they describe.

That's not how this works.

AI handles the grunt work. I handle the judgment. Every suggestion gets reviewed. Every output gets tested. When something doesn't make sense, I ask why. When something breaks, I understand the failure before accepting a fix.

The split is roughly 70/30. AI generates 70% of the volume. I provide 30% of the direction, review, and decision-making.

That 30% is where the value lives.

When uPoll's context window filled up during a complex feature, Claude suggested pagination. Technically correct. But pagination would have broken the real-time experience that was the whole point. I had to recognize that and redirect.

AI gave me options. I made the choice. That's collaboration.

Simon Willison said it better than I could: "I won't commit any code to my repository if I couldn't explain exactly what it does to somebody else."

That's the line. Cross it, and vibe coding becomes the mess the critics describe. Stay on this side, and you have leverage.

Tactical takeaway: Before accepting any AI-generated code, ask: "Can I explain what this does?"

If no, don't ship it. Ask the AI to explain. Or simplify until you can.

Subscribe now

Pillar 3: Iterate Relentlessly, Ship Imperfectly

uPoll.live didn't ship polished. It shipped functional. The polish came from iteration.

The first version worked. Barely. Students could answer questions and professors could see responses. That was the core loop.

Then came testing. Real professors. Real students. Real problems I hadn't anticipated. One professor needed anonymous responses. Another needed response timing. A third found an edge case that crashed the whole thing.

Every problem became a conversation with AI. Every fix made the tool better. Three hundred hours of iteration later, it was polished enough for a university to trust it.

Here's what most people get wrong: they think shipping early means shipping garbage. It doesn't. It means shipping the smallest thing that proves the concept, then improving it based on reality.

The games I'm building with my kids started the same way. Simple. Barely functional. We played them, found what was fun and what wasn't, iterated. Now they're actually good.

Tactical takeaway: Your first version should be embarrassingly simple. Ship it anyway. The feedback will tell you what actually matters.

Leave a comment

Your First Week Building With AI

If you've never built anything with AI, here's how to start:

Days 1-2: One small automation.
Pick something you do manually at least once a week. A form you fill out. A report you compile. A message you send. Use AI to automate it. The goal isn't impressive. The goal is completing the loop: idea → build → ship → use.

Days 3-4: Expand slightly.
Take that automation and add one feature. Or fix something that annoyed you. The goal is learning how to iterate. You'll hit errors. That's fine. The errors teach you how the system thinks.

Days 5-7: Build something you'll actually use daily.
Now you've got the pattern. Pick something you'll use every day. A dashboard. A tracker. A tool that scratches your itch. Something small enough to finish in a few sessions but useful enough that you'll actually open it.

Tools to start with:
- Claude or ChatGPT for the conversation
- A visual builder like Google AI Studio, Replit, Lovable, or Bolt for the interface
- That's it. You can get sophisticated later.

Where It All Breaks Down

I'm not going to pretend this works for everything. It doesn't. Here's where vibe coding hits its limits:

Context limits: Long conversations lose coherence. The AI forgets earlier decisions. You get contradictory suggestions. The solution: break complex builds into smaller sessions with clear handoffs. Document your decisions outside the chat.

Complex debugging: When systems get interconnected, AI guesses can make things worse. One "fix" creates two new bugs. The solution: isolate the problem first. Strip away complexity until you can see what's actually broken.

Anything with real consequences: Payments. Authentication. Security. Data you can't afford to lose. The solution: prototype with vibe coding, but slow down for production. Understand what you're deploying when the stakes are real.

The solution isn't to avoid vibe coding. It's to use it appropriately. Prototype fast. Iterate freely. Then slow down when it matters.

Beyond Code: Building With AI as a Thinking Partner

Here's something I didn't expect when I started: AI isn't just useful for code. It's useful for thinking through problems.

The content strategy for this newsletter? Developed in conversation with Claude. The episode planning for the podcast? Same thing. The positioning for my services? Refined across multiple sessions.

I'm not accepting everything AI suggests. I'm challenging it, pushing back, using my judgment. But having something to react to is faster than staring at a blank page.

The 70/30 split applies to business building, not just coding. AI generates ideas and options. I decide what's actually right for my situation.

Share G8N•AI

What I'm Building Now

Here's where I'm at:

uPoll.live: Live, piloting at University of Texas at Arlington. Real professor using it with real students. The iteration continues.

UltraPost: In beta at ultrapost.g8n.ai. A LinkedIn content generation and scheduling tool built on these same principles. Testing with early users now.

Custom client tools: Building in public with peers who want their own solutions. More on this soon.

Games with my kids: Not for distribution, just for fun. But the process is identical.

And this whole thing: the newsletter, the podcast, the content machine. It’s a demonstration of what's possible when you approach AI as a collaborator.

Share

Workshop: Build Your First Prototype With Me

I'm running a live workshop on Sunday, January 25th.

Three hours. Three spots. Everyone walks out with a working frontend prototype.

The goal isn't to watch me talk. The goal is to build. I'll walk through my exact process - the same approach behind uPoll, UltraPost, and everything else. Then we build together. You work on your project, I provide guidance and troubleshooting in real-time.

Investment: Normally $997. First run: $249.

Why the discount? I want three people who are serious about building, and I want to prove this format works. You get a deal. I get proof. We both win.

I'm qualifying by project scope. Three hours is enough to get a working prototype if the scope is right. If your idea is too big, we won't hit that goal, and I'd rather say no upfront than have you walk away frustrated.

Interested? Reply to this email/post or DM me with your project idea. I'll tell you if it fits.

Next up: "Your First Week Building With AI" — a detailed walkthrough for complete beginners. Subscribe so you don't miss it!

Share

The barrier to building serious software has collapsed. This episode covers:

• Why most people who could build with AI don’t (hint: it’s not technical)

• What vibe coding actually requires: clarity, discipline, iteration

• Proof that this approach builds production software, not toys

• How Software Sovereignty and the citizen developer mindset connect

• What’s coming in 2026 with agentic AI and agentic workflows

Links referenced:

• “What If You Owned Your Tools Instead of Renting Them?” — https://www.g8n.ai/p/what-if-you-owned-your-tools-instead

• “What Vibe Coding Actually Is (And Why Both Camps Are Wrong)” — https://www.g8n.ai/p/what-vibe-coding-actually-is

Projects mentioned:

• uPoll.live — 300+ hours, university pilot, course engagement SaaS

• UltraPost — ultrapost.g8n.ai (in beta)

Subscribe: g8n.ai/subscribe

Share

The Real Skill Isn’t Using AI. It’s Knowing Where to Stop and Adjust.

In February 2025, Andrej Karpathy posted something that would define the year in software development.

“There’s a new kind of coding I call ‘vibe coding,’” the OpenAI co-founder wrote, “where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.”

He described his approach: accepting all AI suggestions without reading them, copy-pasting error messages without analysis, letting “the code grow beyond my usual comprehension.”

The response was immediate and polarized.

One camp embraced it completely. Suddenly feeds filled with people claiming anyone could build production apps overnight. No coding required. Just describe what you want and AI handles the rest.

The other camp rejected it just as forcefully. Senior engineers called it irresponsible. They pointed to security vulnerabilities, deleted databases, applications that collapsed under real usage. A study from METR found developers actually worked 19% slower with AI tools—even though those same developers believed they were faster. Before the study, developers predicted AI would speed them up by 24%. After experiencing the measured slowdown, they still believed AI had improved their productivity by 20%.

That perception gap should concern everyone.

Here’s what both camps missed: Karpathy explicitly said this approach was for “throwaway weekend projects.” Not production software. Not apps handling real users or real money. Weekend experiments where the stakes are low and the learning is high.

That context got stripped away in every hot take that followed.

Share G8N•AI

The Actual Question Nobody’s Asking

The debate over whether vibe coding is “good” or “bad” misses what matters. The real question is simpler: Where does AI help end and human judgment begin?

Simon Willison—creator of Django, one of the most widely-used web frameworks—drew the line clearly: “Vibe coding does not mean ‘using AI tools to help write code.’ It means ‘generating code with AI without caring about the code that is produced.’”

His personal rule: “I won’t commit any code to my repository if I couldn’t explain exactly what it does to somebody else.”

That’s the distinction. Not whether AI wrote the code, but whether you understand it.

If you’ve reviewed everything, tested it, and can explain what it does? That’s not vibe coding—that’s software development with better tools. If you’re accepting suggestions without reading them and hoping it works? That’s the approach Karpathy reserved for throwaway projects.

The people having success with AI building aren’t the ones who’ve figured out how to give AI complete control. They’re the ones who’ve figured out how to collaborate—when to trust AI’s output and when to question it.

Subscribe now

When to Use This Approach

Not every project deserves the same level of scrutiny. A weekend experiment is different from software handling customer data. The skill is matching your approach to the stakes.

This approach works well for:

Personal tools and games you’re building for yourself. The worst case is you waste some time if something breaks.

Prototypes where you’re testing whether an idea is worth pursuing. Speed matters more than polish. You’re trying to learn something, not ship something.

Learning projects where the goal is understanding, not production. Breaking things is part of the process.

Automation for your own workflows. Connecting tools, moving data around, simplifying repetitive tasks. Low stakes, high leverage.

This approach breaks down for:

Anything touching money. Payments, transactions, financial data. The cost of getting it wrong is too high.

Anything touching security. Authentication, authorization, user data. A Veracode analysis found 45% of AI-generated code introduced security vulnerabilities. That’s not a rounding error—that’s a pattern.

Production systems you don’t understand. If you can’t explain what the code does, you can’t debug it when it breaks. And it will break.

Code that other people depend on. When the blast radius extends beyond yourself, the standards have to go up.

The Permission You Might Need

Here’s something that took me too long to realize: you don’t need to “become a developer” to build useful things with AI.

That framing is wrong. It implies there’s a binary—either you’re a developer or you’re not, and you need to cross some threshold before you’re allowed to build.

The data suggests otherwise. According to research on vibe coding adoption, 63% of people using this approach identify as non-developers. Product managers, designers, entrepreneurs—people building functional applications without traditional engineering backgrounds.

The goal isn’t becoming an engineer. The goal is solving your problems.

What you do need: willingness to try, willingness to break things, willingness to ask questions when you’re stuck. The barrier isn’t knowledge—it’s permission.

And here’s the thing about permission: you don’t need anyone else to give it to you. You can just start.

Build something small. Something where the stakes are low and you’ll learn regardless of whether it works. See what happens. See if you like it. See if you want to keep going.

Most people who build successfully with AI didn’t start with a grand vision. They started with a small annoyance they wanted to fix. The skills compound from there.

What Comes Next

This piece was intentionally about framing. About understanding what vibe coding actually is, when it applies, and where the real skill lies.

Next week, I’ll share the actual playbook—the specific principles that guide how I build, with examples from tools I’ve shipped. The tactics work better once this framing is in place.

But here’s what I want you to take from today:

The skeptics aren’t entirely wrong. There are real risks, real failures, real reasons to be careful. Understanding those risks is part of being good at this.

The enthusiasts aren’t entirely wrong either. The barrier to building has genuinely collapsed. Things that required teams of engineers five years ago can be built by individuals now. That’s real and significant.

The skill isn’t picking a side in that debate. It’s developing judgment about when to trust AI’s output and when to verify. It’s understanding enough about what you’re building that you can catch problems before they become disasters.

That’s not magic. It’s not “just vibes.” It’s a learnable skill. And it starts with permission—permission to try, to break things, to build something even if you don’t have all the answers yet.

You’re allowed to try this.

Leave a comment

Next week: The Vibe Coding Playbook—specific principles for building with AI, with examples from tools I’ve shipped. Subscribe so you don’t miss it.