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.

The trap you might not know you’re in

Here’s something that surprised me when I actually sat down and counted: I was paying monthly fees to eleven different software companies. Email tools, automation platforms, database services, payment processors, scheduling apps. Eleven separate bills showing up every month like clockwork.

And I don’t think I’m unusual. Most people who build anything online probably have a similar stack of monthly fees. Whether you’re running a business, creating content, or selling courses. Maybe more subscriptions than you’ve counted. Each one feels small. Twenty bucks here, fifty there. But they add up.

The thing that started bothering me wasn’t the money, though. It was the realization that I don’t actually own any of it.

Every tool I use belongs to someone else. They set the prices. They decide when to change features. They can triple their rates tomorrow, or shut down entirely, and I’d just have to deal with it. I’m renting my entire business infrastructure from companies that don’t know I exist.

I started asking myself an uncomfortable question: What would happen if any of these tools suddenly cost three times as much? What would I do?

For most of them, I didn’t have a good answer.

Share G8N•AI

What is Software Sovereignty?

I’ve started calling this idea Software Sovereignty. It’s not a common phrase, and that’s intentional. I needed a name for something I was thinking about that didn’t have good language yet. I’ve seen similar terms, such as digital sovereignty, being used at a national level in some cases, where countries are trying to be more “digitally independent” from corporate control (collaboraonline.com/blog/openmatters004).

Digital sovereignty, cyber sovereignty, technological sovereignty and data sovereignty refer to the ability to have control over your own digital destiny – the data, hardware and software that you rely on and create.

Or, as the Centre for Africa-Europe Relations puts it: the physical layer (infrastructure, technology), the code layer (standards, rules and design) and the data layer (ownership, flows and use).

from weforum.org/stories/2025/01/europe-digital-sovereignty

Software Sovereignty, in my case or the case of our brands and businesses at a more local level, means having agency over your tools, not just access to them.

It means owning your own data so you can take it anywhere. It means controlling your costs in a way that doesn’t scale against you as you grow. It means understanding your systems well enough that if something breaks, you can fix it. And it means having the freedom to change things when your needs evolve.

Here’s what Software Sovereignty is not about: being cheap. I’m not interested in penny-pinching my way through building a business. Life’s too short, and my time has value.

And here’s the other thing it’s not about: becoming a programmer. I’ve written software professionally for twenty years, so I obviously have that background. But the version of this I want to share doesn’t require you to become a developer. It requires you to stop being trapped.

This connects to something I think about a lot. I don’t wait for companies or institutions to protect my future. I build my own safety net. And renting every piece of software that runs my business means depending on companies that could pull the rug out from under me at any time.

That’s not a safety net. That’s a hope.

Subscribe now

Why this is possible now

Five years ago, if I told you to run your own tools instead of renting them, you’d need serious technical skills. You’d be reading dense documentation, learning arcane commands, troubleshooting obscure error messages. It would take months just to get something basic working. Maybe years to get comfortable.

The barrier was real. Building your own stuff required knowledge that took a long time to acquire.

AI changed that equation. Not completely (I want to be honest about this), but substantially.

Now you can describe what you want in plain English. You can say “I need to set up a system that sends automated emails when someone signs up for my list” and get back actual instructions. Specific steps. Real guidance. When something breaks, you can paste the error message into a conversation and get help understanding what went wrong.

The barrier dropped from “years of study” to “willingness to try and ask questions.”

I don’t want to oversell this. There’s still a learning curve. You’ll hit walls. You’ll get confused. Some days you’ll wonder why you didn’t just pay the monthly fee and move on with your life.

But the curve is shorter than it’s ever been. And for the first time, this option exists for people who aren’t professional developers. Not in theory. In practice.

What this looks like in practice

Let me tell you what happened when I actually tried this.

I have about 18,000 students in my online courses. They signed up through the course platform, but that platform owns the relationship. If I want to email them directly, to share updates or offer new courses or just stay connected, I need to bring them onto my own email list.

So I looked up what that would cost.

The email software most creators use would charge me somewhere between $145 and $155 per month for a list that size. That’s just for email. Add automation tools for workflows (when someone clicks this, do that), a database to track who’s interested in what, and monitoring to know if something breaks? I’m looking at $300-400 per month easily. Some people pay much more.

That’s $3,600-4,800 per year. For software I don’t own. For data I can’t fully control. For tools that could change their pricing whenever they want.

I decided not to pay it.

Instead, I spent a few days building my own system. Email sending, automation workflows, a database I control, monitoring that tells me when something goes wrong. All of it running on my own setup.

Total monthly cost: about $17. $21~25 if you add any volumes or enable backups, per Hetzner’s pricing. $32 for my specific case with my configuration and with a few more servers hosting other apps I’ve developed, and just to be transparent - but still significantly less than hundreds to thousands of dollars per month.

Let me be clear about something. This wasn’t easy. I hit obstacles. I made mistakes. The company I needed for email delivery rejected my application twice. Both times, manual rejections from actual people with no explanation. The second rejection even included “thank you for your understanding”—as if there was anything to understand when they’d told me nothing. I pushed back. Told them no, they didn’t have my understanding, and demanded an actual reason so I could address whatever the issue was. A couple of days later, they approved me. I changed nothing. They never explained. Bureaucratic friction is part of the game.

But now I have something that works. Something I own. Something that won’t suddenly cost me ten times more because a company changed their pricing tiers.

And I learned things along the way that will help me build whatever comes next.

This might not be for you

I want to be careful here. I’m not saying everyone should do this.

Some people are at a stage where the learning curve isn’t worth it. You’re in the middle of launching something, or your business is already humming along, or you genuinely don’t care about this stuff and your time is better spent elsewhere. All of that is valid.

But here’s what I do think: you should know this option exists.

Most people don’t. They assume that using business software means paying monthly fees forever. They’ve never considered that there’s an alternative. And because they don’t know, they never evaluate whether the rental makes sense or whether they’d be better off owning.

Software Sovereignty isn’t about everyone building everything themselves. It’s about having the knowledge to make a real choice. Knowing which tools make sense to rent and which ones make sense to own. Understanding the tradeoffs.

Once you see this, you can’t unsee it. Every time you sign up for a new tool with a monthly fee, you’ll find yourself asking: Could I own this instead? What would that cost me in time? What would it save me in freedom?

Sometimes you’ll decide the rental is worth it. I still rent plenty of software. But you’ll be making that choice consciously, not by default.

If you’re curious about how this works, I’m going to be sharing more of it. The thinking behind it, the actual steps, the places where I got stuck and how I got unstuck. Not as a course or a product. Just as part of building in public and showing what’s actually involved.

Follow along if you want. Ask questions if you have them. Try things if you’re ready.

Leave a comment

What Software Sovereignty really means

At the end of all this, Software Sovereignty isn’t really about software. And it’s not really about technology.

It’s about independence.

It’s about recognizing that every system you depend on but don’t control is a vulnerability. A point where someone else makes decisions that affect you. A place where you’re hoping for the best instead of building for it.

I think a lot about what it means to build your own safety net. To take ownership of outcomes even when the reasons things go wrong aren’t your fault. To have skills and systems that let you adapt when circumstances change.

Owning your tools is part of that. Not because it saves money (though it does). Not because it’s technically interesting (though it can be). But because it gives you options. Because it means one less company can hold your business hostage. Because it turns a hope into a plan.

That’s what G8N•AI is about, ultimately. Teaching agency through building. Showing that the things that feel locked away (technical skills, infrastructure, independence) are more accessible than they look.

You don’t have to become a software developer. But you can stop being trapped by software.

And that changes more than you might expect.

Share

If this resonated with you, subscribe to G8N•AI for more on building with AI, owning your tools, and creating the kind of independence that lets you focus on work that matters.

PS—I help founders replace their $400+/month SaaS stack with self-hosted tools they actually own. Two weeks. Complete setup. Training sessions so you understand what you have. You keep the savings forever.

If Kit’s 35% price hike made you wince—or if you’re just tired of feeling trapped by tools you don’t control—book a call and let’s talk about what sovereignty looks like for your business.

This is part of what I’m calling “teaching agency through building.” That’s what G8N•AI is about.

Share

Share

Share

Share

Transcription since Substack’s transcription feature is failing brilliantly:

Hello, I’m Ahad Amdani. Welcome back to Generation AI. That’s G8N.AI, where I explore practical ways to build with artificial intelligence. I’m building in public, vibe coding custom AI tools, and sharing everything I learned along the way.

This is episode two, and I’m recording this less than 24 hours after episode 1 went live. That’s not because I’m some productivity machine. It’s because I’ve built a system that makes showing up easier than not showing up. Today, I want to talk about that system and why building frictionless workflows is the single most important thing you can do if you want to create content consistently.

Here’s something I want you to understand. I don’t feel like doing this tonight. I’m tired. I had a long day. Part of me wants to just skip it. Tell myself I’ll do it tomorrow. But here’s the thing. I have set up my process so that skipping feels worse than doing it.

That’s the mindset shift. When you’re relying on motivation, you lose. Motivation is unreliable. It shows up when you don’t need it and disappears when you do.

But a system? A system works whether you feel like it or not.

Right now, recording this audio content dump takes maybe 15 to 20 minutes. Tonight’s actually took 40 minutes. I’m literally just talking into my phone. That’s it. No fancy equipment, no perfect environment, just me rambling through the ideas I want to share.

Then the AI takes over. It transcribes. It organizes. It produces a script that I can refine. All of the tedious parts, the parts that I hate are handled. What’s left is the creative work, the part that I actually enjoy.

So when I think about skipping a day, I’m thinking 15 minutes of talking versus the failure of breaking my streak. The system made that math easy.

Let me walk you through exactly how this works. This is the same process I used for episode 1, and I’m validating it again right now with episode two.

Step one, audio content dump. I open the recorder app on my phone and I just talk. No script, no outline, just the ideas I want to cover in whatever order they come out. Sometimes it’s 10 minutes, sometimes it’s 40. Doesn’t matter. The goal is to capture raw content.

Step two, transcription. I drop that audio file into NotebookLM, Google’s AI Notebook tool. It generates a transcript. It’s not perfect, but it’s good enough for the next step.

Step three, script generation. I take that transcript and I paste it into my Claude project. I spent time building detailed instructions for how I want my podcast scripts formatted: tone, structure, pacing cues, everything. Claude transforms my rambling into a coherent script with sections, transitions, and delivery notes.

Step four, refinement. I read through the script. I adjust anything that doesn’t sound like me. I practice it out loud a few times. And this is where I spend my creative energy, not on the production logistics or on uh audio style or uh things that don’t really matter to me, right?

I care about the content. I care about making it appealing and I care about spreading this knowledge. I want to make sure that the message lands.

Subscribe now

Step five, recording. Once I’m happy with the script, I record it properly. Right now, that’s still me reading into a microphone. Eventually, I’m planning to use an AI voice clone trained on my speech patterns. Either way, the recording is the easy part because all the thinking has already been done.

Step six, post-production. I run the audio through Podcastle AI to clean it up, reduce background noise, normalize levels, fix any obvious issues. Then it’s ready to publish.

Total time from idea to finished episode, 2 to 3 hours. And most of that is refinement, the work that I actually want to do. Right now, I’m still in the middle of this script, so I don’t know yet exactly how I’m going to make a bunch of changes.

For example, everything I’m saying right now isn’t scripted, but this is why I’m sharing this process in detail.

If you’re building a personal brand, if you’re trying to create content consistently, if you’re a solopreneur or a technical founder or someone who wants to share your expertise, you’ve probably struggled with the same problem I did. You know, you should be putting out content. You know it matters for your growth, but the friction is too high.

Share G8N•AI

Writing a blog post from scratch, that’s a whole afternoon. Recording and editing a podcast the traditional way, that’s a whole day. And when it takes that long, you don’t do it. You push it off. You tell yourself, “Next week, this weekend, whatever.” Anything to get out of doing it right then.

But what if it took an hour? What if the hardest parts - the organization, the editing, the production - were handled by AI? Suddenly, consistency becomes possible. Suddenly, daily content isn’t crazy. It’s just a system.

The same philosophy applies to any high-value activity you’ve been avoiding because it’s tedious. Figure out what you hate about the process, then automate that part. Keep the creative work, delegate the rest.

Let me give you a concrete example of what’s possible when you apply this thinking to tool building. I built an app called Stack Coach AI. You can check it out at stack.g8n.ai. That’s stack.g8n.ai.

It’s a Substack content creation and coaching tool. You can draft posts, get AI feedback on your writing, generate images, transcribe audio, even get monetization strategy suggestions.

Subscribe now

Here’s the thing. I built it in 3 hours. 3 hours start to finish. Front end. backend, deployment, custom domain, all of it. I used Gemini and Google AI Studio for the initial prototype. Then brought in Claude Code with Opus 4.5 to add the backend infrastructure. The tech stack includes React, TypeScript, SQLite, and it’s hosted on Vercel and Fly.io.

Now, I’m a senior developer with almost 20 years of experience. I knew the technologies involved. But even accounting for that, 3 hours to go from zero to deployed is insane. That’s the power of vibe coding with modern AI tools.

Is it production ready at scale? No, it’s a prototype. But prototypes become products. And if the prototype takes three hours, operationalizing it takes weeks, not months.

The point is the barrier to building custom solutions is collapsing. If there’s a tedious part of your process that you hate, you can probably automate it faster than you think.

I want to be clear about why I’m doing this. I believe most people are under-leveraged on AI. They’ve heard the hype. They might be scared of it. They’ve maybe played with ChatGPT a few times, but they’re not using these tools to fundamentally change how they work.

Share

And I get it. There’s a learning curve. There are legitimate concerns about safety and bias and job displacement. And I’m not dismissing any of that.

But the technology is here. It’s getting better every month. And the people who learn to use it well, the citizen developers, the builders, the ones willing to experiment, they’re going to have a massive advantage. Not because they’re smarter, because they built better systems. Frictionless systems.

And that’s what I want to help with. Education, upskilling, showing what’s possible, building tools that demonstrate the approach, creating a community of people who are figuring this out together. If that resonates with you, stick around, subscribe, share this with someone who might benefit.

For episode three, I’m going to document something fun. I mentioned I’ve been talking to my business partner about updating some stale course content we have on our company site Explainly. He was skeptical that we could refresh it efficiently.

Subscribe now

So I walked him through this exact podcast process, showed him episode one, explained the workflow, demonstrated the time savings. He’s convinced. We’re booking time to apply this approach to our educational content.

So episode three will cover that conversation, what objections came up, how I addressed them and what we’re planning to build together. It’s a real time case study in using AI to solve an actual business problem.

If you want me to vibe code a tool for you, something small, practical, something that solves a real pain point, drop a comment on this episode. Serious offer. I’ll pick one and build it live for a future episode.

That’s where we’ll leave it for today. Thank you for spending this time with me. I know there are infinite things competing for your attention.

And the fact that you chose to listen here? I don’t take that for granted.

Head over to g8n.ai for show notes and resources. That’s generation.ai and check out Stack Coach AI at stack.g8n.ai if you want to see what three hours of vibe coding looks like.

Until next time. Keep building, keep learning, keep asking good questions. Talk soon.