G8N•AI Podcast

Ahad Amdani
  • 0.0 (0)
  • Technology

GenerationAI • Focus with Intention and Leverage with AI Building in Public • Custom vibe-coded AI tools www.g8n.ai

  1. 7h ago

    They Keep Working. I Keep My Weekends.

    At least once a week, usually on Saturdays, my siblings and their families come over for dinner with my parents and my wife and kids - 9 adults and 8 kids (2 of them teenagers). It’s chaos; also amazing and fun. They get here around 6pm, and we usually don’t break until close to midnight. It’s been going on for over a decade, and for a very long time, I’d mostly miss out. I’d catch the meal, sometimes, and then I’d be back at it: 2 hours out of 6, if I was lucky. It wasn’t just my weekends, either. On weeknights, I was there for the kids at bedtime, some of the time, and the trips to the park or the arcade kept slipping. Like many others, I’ve got a lot of things on my plate. For me, it’s a full-time job, a business with a partner, a software product being piloted at a public university, and a book I’m writing about humans and compounding capability. All of it was eating my nights and weekends. I broke away from that slog over nine months, and I did it by digging into AI and leveraging the hell out of it. Not in a “this saves me a few hours each week” kind of way, but in a “this reimagines my entire life” kind of way. This is what led to my Simple Dispatch Fleet - an agentic AI fleet managed with simple messages sent between agents to coordinate and share the load. Now, we’ve all got different circumstances, but the problems are usually ones most of us share. What’s less obvious is that the solutions are shared too, and fairly simple - just not easy. AI is one of them, but most people give up after a few attempts with bad results, never figuring it out or putting in the time and effort to really pick it up as a skill. McKinsey’s State of AI survey this year found that 80% of respondents said AI made them more productive, while 37% said it’d shown up in their company’s operating profit at all. The report’s explanation for the small group doing better is worth quoting in full: high performers “fundamentally redesign workflows rather than layer AI onto existing ones; and they embrace practices that sustain deployment, such as senior-leadership role modeling, human-in-the-loop design, impact measurement, and risk management.” That’s what my nine months turned out to be, and this is the system I ended up with, along with the smallest version of it that you could start this week. I said the solutions are simple, just not easy. This is the not-easy part, and it’s technical. If you onl y came for the story, this is where to stop. If you want to build your own, read every line, because I’ve left in everything I’d want to see if I were starting over. Is it “legal” to let an AI agent post from your own account? It’s my account, my words and my computer, and nothing gets typed until I’ve approved the post. “It’s my account” is a feeling, though, so I had the law researched properly before I wrote this. This is my reading of that research. It isn’t legal advice, and if you’re going to copy this setup, talk to a lawyer where you live first. * It isn’t a computer crime. In Van Buren v. United States (2021), the Supreme Court read the federal computer-fraud laws as “a gates-up-or-down inquiry.” Logged into my own account and posting my own words, the gate’s up. * It isn’t a bot under California’s disclosure law, which defines a bot as an account where “all or substantially all of the actions or posts of that account are not the result of a person.” I approve every post. Even if it were one, the law only applies when a bot hides what it is to sell something or sway a vote. * The real exposure is contract, and the platform enforces it with your account. LinkedIn’s help page says members who use automation software “risk having their accounts restricted or shut down.” Substack’s acceptable-use policy reads as aimed at spam and at “any processes that run or are activated while you are not logged into Substack,” and my tools only act inside my own logged-in session, one approved post at a time. That’s my reading of their words, and it’s worth a lawyer’s look. * hiQ won the computer-crime argument against LinkedIn over public data, and then, according to the case reports, lost on its contract in 2022, for scraping and for creating fake accounts, and ended with a $500,000 consent judgment. Every case I found that went badly involved fake accounts or other people’s data. So the question left over is a contract question: who decides how my posts get typed. I decide that for myself, and you, dear reader, decide that for yourself, never the platform. They can ban your account, but they cannot silence your voice. The protections below are how you make sure of that: * Own the distribution the account rents you. Export your subscriber list and keep a local archive of every post, so losing an account costs you one channel and your audience stays with you. * Approve every post, and keep the record that shows you did. Mine’s a line in a ledger with a time and a name on it. * Never collect anyone else’s data. Every bad outcome above started there. * Use a platform’s own scheduler wherever it works. My Substack Notes go through Substack’s native scheduler. My LinkedIn posts also go through LinkedIn’s native scheduler. * Stay at human pace and a human volume. * Try anything new on an account you can afford to lose. Should you build a fleet like this? Most of the time, you shouldn’t, and the best-documented case against it comes from the company whose model runs my agents. Anthropic’s engineering team wrote in 2025 that “agents typically use about 4× more tokens than chat interactions, and multi-agent systems use about 15× more tokens than chats.” That 15× is their own figure, published without a method, so I’d treat it as a vendor describing its own product. Cognition’s Walden Yan named the deeper problem in a post titled “Don’t Build Multi-Agents”: “Actions carry implicit decisions, and conflicting decisions carry bad results.” Cemri and colleagues went through more than 1,600 annotated traces across seven multi-agent frameworks and found 14 distinct failure modes. And in April 2026, Dat Tran and Douwe Kiela found that with the reasoning budget held constant, single agents “consistently match or outperform” multi-agent systems on multi-hop reasoning, although that study hasn’t been replicated yet. The reconciliation I’d defend came from LangChain’s Harrison Chase: “Read actions are inherently more parallelizable than write actions.” That’s the shape my fleet runs. Agents fan out to research and check, exactly one agent writes any given thing, and the agent whose job is to find problems isn’t allowed to fix them. My own setup has limits I’d rather you hear from me: it’s one Mac with no failover, the wake-up hop only works with Claude Code today, and when the plan’s allowance runs out, work waits. Or at least, that’s what was true before. Now, I actually have failover to Codex, and failover when that usage runs out to my own Hermes setup, running Qwen 3.6. If you’ve got one recurring job and one agent doing it, you don’t need any of this. Start with that one agent and the four lines at the end, and add a second agent only when you can name the thing the first one can’t do. What do my AI agents actually do all night? Nine agents are on my roster. Or at least nine of the ones that I’m talking about right now. Eight of them run on my Mac inside a single terminal session, each in its own window with its own project folder, and every one of them is running through Claude Code today. Each one’s got a job description, and all but the newest have a Discord channel where they talk to me. See if you can guess the theme before you reach the bottom of the list. * Oracle is the brain and the memory of the operation. She captures everything that’s relevant, tracks tasks and deadlines, and sets strategy, and Alfred, Lucius Fox, Gordon and Robin report to her. * Alfred writes, markets and sells in my voice. He drafted this newsletter. * Lucius Fox is the researcher, and every claim in his briefs comes back marked verified, reported or unverified. * Gordon is the adversarial editor. He tries to break every draft before I see it, and he’s forbidden from rewriting a single word. * Robin is the executive assistant, who captures transcriptions and meeting notes and keeps me on track and on task. * Viki Vale works on my long-form manuscripts and reports to Alfred. * Damian Wayne develops my 3D Unity game. * Nightwing does product engineering for EngageLive, the rebrand and rewrite of the uPoll product. He’s being registered now, so he doesn’t have a channel yet. * Riddler used to orchestrate everything. He’s out of rotation while I rebuild him as a thin watchdog and router. Here’s what that looked like this week: Alfred read what was landing among the writers I follow and picked a theme the conversation was already having. He drafted three LinkedIn posts and five Notes on checking your AI maturity, and before I saw any of it, a repetition check caught one Note whose opening was a 75% match for a Note I’d published ten days earlier, and it got rewritten. Then Gordon found two things no script could: a McKinsey figure in one Note that was missing from the saved record of what had been read, and, once that was fixed, a time in the record that the file’s own timestamp contradicted. Both were fixed before anything went out, he signed off on the second pass, and the Notes reached me as a card parked on a question on my task board, where I couldn’t lose track of them. I approve every piece myself, and the publishing tools check the platform afterward to confirm it actually happened. The agents handle the drafting and the research, the checking and the chasing, and what reaches me are the decisions that are mine to make. G8N•AI is a reader-supported publication. To receive new p

    They Keep Working. I Keep My Weekends.

  2. Sep 18

    They Draft. I Speak.

    My agents wrote the first draft of this newsletter. Not one of them is allowed to post a comment underneath it. That sounds like a small distinction. It’s the most load-bearing rule in my whole operation, and it’s the one I get asked about least. Last week a writer I follow, Claudia Faith , posted a note that got more engagement than anything else she published that week. Forty-two reactions, ten replies. It said, roughly: use AI for your writing, your images, anything you like, but please don’t use it to write comments under other people’s posts. The same week, Wyndo , who writes carefully about working with AI, credited an AI content system for keeping his publishing consistent. Both of those people are right, and neither of them says where the line is. That’s the part worth writing down, because I’ve had to find it the expensive way. What actually goes wrong when a tool speaks for you? Here’s the specific thing that happened to me, and the numbers are exact because I counted them: a tool of mine posted the same comment on one of my own posts four separate times. That tool posts the first comment on my own LinkedIn posts, five minutes after they go live. The comment is written by me, approved by me, and sits in a file. The tool’s only job is to wait and paste. Once at the right moment, then again a day later, then again, then again. Four identical copies under a post where a real person, Luke Beck, had left two genuinely useful pieces of advice. He was having a conversation with me and my tooling was talking over it. The cause was dull, which is how these things usually go. After posting, the tool checked whether its comment was visible, couldn’t find it within four seconds, and reported failure. The comment had been live since the first attempt. Anything that retried on that failure posted again. Nobody was harmed. But the shape of it’s the thing: a piece of automation with permission to speak, a verification step that couldn’t see the truth, and a public surface where the mistake is already in front of someone by the time you learn about it. Why is drafting safe when speaking isn’t? Because a draft has a gate after it and a comment doesn’t. If an agent writes me a bad post, I read it and delete it, and the total cost of that failure is my attention for nine seconds. Nobody knows it existed. The gate sits between the machine and the world, and everything upstream of the gate is cheap to get wrong. A reply in someone else’s comments is already in front of them by the time I see it. There is no gate after the fact. There’s only an apology, and an apology costs more than the comment was ever worth. That asymmetry is the entire argument. Two jobs that look similar from the inside, because both of them are just producing text, carry completely different risk the moment you ask where the undo button is. So the rule I run is that the machines produce and a human speaks. I call it the Approval gate, and it’s the one piece of my system I’ve never been tempted to loosen. Where does the Approval gate actually sit? It helps to be concrete, because “a human in the loop” is the kind of phrase that means nothing until you say exactly which loop. My agents draft LinkedIn posts, Substack notes, and this newsletter. They file records, take locks so two of them can’t work the same day, refuse malformed input from each other, and run every morning without me in the room. I haven’t opened the thing that makes them in weeks. Not one of them can send a message to a person. The first comment is pre-written by me and approved before the post exists. The direct messages have a hard ceiling that lives in a config file, three connection requests and five messages a day in the first week, and the first ten sends on any platform each need individual approval before the eleventh is allowed to go automatically. Replies to real comments I write myself, by hand, usually slower than I’d like. The gate isn’t a feeling. It’s a list of things that are allowed to reach a person without my eyes on them, and the correct length of that list, for almost everybody, is zero. How do you decide what an agent may do on its own? Most people aren’t deciding this at all, and there’s a number for it. Teleport’s 2026 Infrastructure Identity Survey found that 70% of organizations grant AI systems more privileged access than a human would get in the same role. 51% said slightly more. 19% said significantly more. Nearly one in five is handing software more reach than the person whose job it’s doing. That’s not a trust problem. It’s a nobody-drew-the-line problem. I stopped thinking about this as one permission and started thinking about it as five, in order of how expensive the mistake is: * Reading is free. An agent that reads my calendar, my repository, my own published work or a public feed can be wrong and the cost is a wasted minute. Everything I own reads without asking. * Writing for me is nearly free, because of the gate. Drafts, notes, summaries, a proposed reply I haven’t sent. All of it lands somewhere I look before anyone else does. * Writing to my own systems is where it starts to matter: filing a record, moving a card, closing a task. A mistake is recoverable but not free, because now something downstream believes a thing that’s not true. This is the layer where I’ve spent the most time building checks that refuse bad input from other agents. * Acting on outside systems is the first genuinely sharp edge. Publishing a post, sending a scheduled note. I allow it, narrowly, and only for content that already passed the gate as a draft. The agent isn’t deciding what to say. It’s executing a decision I already made, at a time I already picked. * Speaking to a person is the one I don’t automate. Not comments, not replies, not messages. The useful part of that list isn’t my particular answers. It’s that the question has five answers instead of one, and 70% of organizations are still treating it as a single switch labeled “do you trust AI?” What does this cost? More than I’d like, and I’d rather say so than sell you a version where it’s free. It costs me speed. I answer my own comments, which doesn’t scale and never will. Some days I’m late, and being late to a comment thread on LinkedIn is expensive in a way the platform makes very clear: it costs me reach I could technically have. There are tools that would engage on my behalf all day, and some of them would probably work for a while. What it buys is narrow and, I think, worth it: every conversation anyone has had with me on these platforms was actually with me. When Luke told me to brand my images and to drop a popup that was blocking crawlers, he was talking to a person who could act on it, and both things shipped that week. That exchange doesn’t survive being automated. It’s the whole reason the account is worth anything. Is this just a taste preference? No, and I want to separate the two, because taste is where this argument usually goes to die. Claudia’s objection reads partly as taste. She doesn’t want her comment section filled with generated warmth, and I agree with her. But the reason I hold the line is mechanical rather than aesthetic. It’s about where the undo button is. You can test it without any philosophy. For any automation you own, ask one question: if this produces something wrong at three in the morning, what does the recovery look like? If the answer is “I delete a file,” you can let it run. If the answer is “I apologize to someone,” it doesn’t speak without you. That test doesn’t care how good the model is. A better model lowers how often you need the recovery. It doesn’t change what the recovery is. What I’m not claiming I’m not claiming AI-written comments never work. Plenty of people are doing it and getting engagement. I’m claiming that the engagement isn’t the thing being risked, and that people who measure only the engagement won’t see the cost until it arrives attached to a name they wanted to keep. I’m not claiming my setup is the right one for you. Mine is shaped like my work, which is one person with a lot of automation and a small audience where individual relationships matter more than volume. If you run a support desk, your line sits somewhere completely different, and it should. And I’m not claiming I drew this line on principle. I drew it after four identical comments under a post where someone was trying to talk to me. Do this to one automation today Open whatever tool you’re using that touches other people. A scheduler, an auto-responder, a comment tool, an agent with an integration you set up once and stopped thinking about. Find the exact place where it can reach a person without you looking first. There’s usually one, and it’s usually not where you expected, because it got added later for convenience. Then decide, in writing, whether it stays. Ten minutes. If it stays, write down what happens when it’s wrong, and who apologizes. I’m Ahad Amdani, I write G8N•AI, and the Approval gate is the rule I’d keep if I had to throw the rest of the system away. Get full access to G8N•AI at www.g8n.ai/subscribe

    They Draft. I Speak.

  3. Sep 11

    AI Will Cite You Without Ever Naming You

    Everything I’d learned about writing to be found turned out to be aimed at the wrong reader. For twenty years the reader was a crawler. You wrote for a machine that matched strings, and the craft was getting the right phrase in the right places often enough to be counted. That reader’s gone, and what replaced it does something the crawler never did: it reads your page, takes what it needs, and answers the question itself. I went looking for what actually works now, because I was about to spend real time on it. What I found wasn’t a list of tactics. It was a shape. Getting found by AI is three separate contests, not one. You can win any of them and lose the others, and almost nobody is competing in all three, because most people don’t know the second and third exist. Here’s the shape, then the evidence for it, then what I’d do about each stage. The three contests * Retrieval. Does the engine consider your page at all? * Lift. Once it’s looking, does it take anything from your page? * Attribution. Once it’s used your material, does the reader learn your name? Different things win each one. That’s the whole insight, and it’s why “do good SEO” is now advice about one third of the problem. Does Google rank decide whether AI cites you? I assumed the pages AI cites were roughly the pages Google ranks. They aren’t close. Ahrefs looked at the thousand most-cited pages in ChatGPT, part of about a billion data points they worked through this year. 28.3% of those pages have zero organic visibility in Google. The overlap between ChatGPT’s results and Google’s top ten organic is 6.82%. If you’ve been using your Google rank as a proxy for whether AI will cite you, that proxy is about 7% accurate. The mechanism underneath is stranger and more useful. Among cited pages, 65.3% sit on high-authority domains, while 67.3% of those same pages have almost no page-level authority of their own. Read that twice. The domain matters enormously. The individual page’s backlinks barely matter at all. Which inverts a decade of advice. The old play was to build links to the one page you wanted ranked. The new one is to get the domain trusted, then publish the specific page and stop worrying about whether anyone links to it directly. That’s genuinely good news for a small operator publishing consistently on one domain, and bad news for anyone whose whole strategy was a single heavily-linked cornerstone page. What to do: stop optimizing individual pages for links. Publish consistently on one domain you own and let the domain carry the pages. And know that a page can earn citations while ranking nowhere, which means your analytics will under-report this entirely. Contest two: lift is won by material a model can safely reuse Once you’re in the consideration set, something has to be worth taking. The foundational study here is GEO, for Generative Engine Optimization, out of Princeton and IIT Delhi and presented at KDD in 2024. They tested nine content modifications across roughly ten thousand queries and measured which made a page likelier to show up inside an AI-generated answer. Three things won: citing sources, adding quotations, and adding statistics. Together the best techniques lifted visibility by up to 40%. I’ll be careful with that number, because almost nobody who quotes it is. 40% is the maximum that study found, not the average. It gets passed around like it’s a floor. It’s a ceiling. The loser is the more useful half. Keyword stuffing came in around minus 9%, and roughly 10% worse than baseline on Perplexity. The technique that defined this discipline for a decade doesn’t just stop working. It costs you. That paper’s two years old, which in this field is a long time, so I checked whether it still holds. It does, and the newer work is more specific: structural rewrites on their own, meaning sectioning, fact placement and list use, lifted citation rates by 17.3%. You don’t have to change what you think. You have to change how it’s arranged on the page. There’s a format finding too, and it’s uncomfortable if you write essays. Ahrefs found “best X” listicles are the single most-cited content format in ChatGPT, at 43.8% of cited page types. What to do: put liftable units in your writing. A sourced number, a named authority, a sentence precise enough to quote. Then arrange them so they’re findable: real sections, facts near the top of their section, lists where the content is genuinely a list. And accept that some of your best material will get lifted from a format you find “beneath” you. Why does being cited so rarely turn into being named? This is the part that re-organised how I think about all of it, and it’s the contest nobody is playing. GPO published research in August 2026 with a finding I haven’t stopped thinking about since. When a brand’s own content was cited as a source inside an AI Overview, that brand was still left out of the model’s actual recommendation 69% of the time. Read that again. Your page is good enough to be the source. The answer’s built out of your work. And then the model recommends somebody else. The same research measured how badly old signals transfer: * Brands appeared in Google’s local 3-pack 35.9% of the time. * ChatGPT recommended those same brands 1.2% of the time. * Gemini 11%. * Perplexity 7.4%. For the same brands, that’s roughly a thirty-to-one gap between ranking and being recommended. Semrush and Kevin Indig found the adjacent version in June, looking at 3,981 domain appearances across 115 prompts, fourteen countries and four engines. They called them ghost citations: the answer links your page as a source and never says your name in the text a human actually reads. That was 61.7% of citations. Ghost citations are real. So you can win contests one and two completely, supply the entire answer, and still leave the reader with no idea who you are. What to do: make your name inseparable from your best claim. Not in the title tag, in the sentence. If the liftable line is “the fifth step is the one people skip,” you get cited. If it’s “the fifth step of the 5 Ds is the one people skip,” the thing that travels is yours. Name your frameworks. Put your own name in the prose. A claim with a name welded to it is the only unit that survives summarization intact. The theory, in one paragraph Domain trust gets you considered. Liftable material gets you used. A named claim gets you credited. They’re three different jobs, they’re won by three different things, and the last one is both the least worked on and the one that decides whether any of it turns into a reader who knows your name. If your traffic is flat but your ideas keep showing up in other people’s mouths, you’re winning the first two and losing the third. That’s the most common shape I see, and it’s the one that feels like failure while actually being most of the way there. The audit I run now I ran this on the piece you’re reading and it failed five of six checks on the first pass. * Is there a claim here specific enough for an answer to lift and cite? * Does that claim carry the name or idea I want remembered? * Is my own name in the prose, not just the metadata? * Are the numbers sourced, in the text, where a model can attribute them? * Do the headings ask questions the section beneath actually answers? * Have I named a concept I own? That last one is the item that pays most and the one nobody does. The fifth matters more than it looks: question headings help, but only where the section genuinely answers the question. The research is explicit that a question a section doesn’t answer is the trick that doesn’t work, which is the rule most advice in this area gets backwards. I’m Ahad Amdani, I write G8N•AI, and this audit is now the last thing that happens before anything goes out. What I’m not claiming I’m not claiming this makes you rank. Nobody’s got a formula that guarantees an AI retrieves, cites or recommends you, and anyone selling one is ahead of the evidence. The Ahrefs data is one vendor measuring mostly ChatGPT. The GEO study is two years old. Treat all of it as a working theory that’s better than the one you had, not as physics. I’m also not claiming the old work was wasted. The same ingredients that make a page citable, clear evidence and a claim that survives outside its paragraph, are what make it trustworthy to a person. That’s the part I find genuinely reassuring: what works on the machine is what was always good writing. Do this to one page today Open an article you actually want people to find. Circle every sourced number, every named authority and every sentence that could be lifted whole. Then check whether a single one of them says who you are. If it hasn’t got any, you have a contest-two problem and the fix is material. If it’s got several but none carries your name, you have a contest-three problem, which is the more interesting one and the one 69% of cited brands have right now. If you want the how rather than the what, that’s a conversation. Reply to this and tell me which of the three you’re losing, and I’ll tell you what I’d change first. Get full access to G8N•AI at www.g8n.ai/subscribe

  4. Sep 3

    Your Claude Setup Will Be Gone in Two Years. The Design Underneath It Won’t.

    I could lose every tool I use tomorrow and be back at work by the weekend. Not because I keep backups. Because none of them holds the thing that matters. The chat app, the task board, the AI model, the place my writing goes. I can throw all of it away and the system I built keeps working. I set it up that way on purpose. It’s close to the opposite of the advice everyone’s giving right now. Here’s my system with no product names in it Five helpers: * One remembers everything and decides what happens next. * One writes and sells. * One looks things up. * One argues with the others and checks whether what they said is true, and it’s not allowed to rewrite anything, so its complaints stay complaints. * One keeps track of what’s waiting on me. Work shows up and becomes a card. Every card says who it’s for, what it’s for, and what’s happened to it so far. Every single action gets written down as one line: the card, the action itself, who did it, and when. Nothing goes out to real people without me. On the path that messages strangers, that gate is strict in a specific way: the send tool looks up each message and refuses unless it finds a yes recorded by a person, and a yes written by a tool is thrown out. On the publishing path, it’s a quieter thing: a button only I can reach. Different strengths, same rule. Read that again and notice what’s missing. No brand names. No AI model. No app. Two of those five have been running for months. The other three are new, added in the last few days, and here’s the part that matters: adding them didn’t change the description. It also didn’t change when I swapped what runs underneath. A design that can absorb three new workers, and a change of model, without being rewritten is the thing I’m actually claiming. The question everyone asks stops being true very fast Open almost any newsletter like this one and you’ll find the same article: here are the tools to use, here’s the stack to copy, here’s the fourteen things that will put you ahead. I actually read a really good one this week. It listed the exact tool for fourteen different jobs. It’ll be wrong within a year. The person who wrote it knows that, which is why he writes a new version every few months. Tools change fast. Prices go up. A better one shows up. The one you learned gets bought by a bigger company and slowly gets worse. Enshittification is real. If your business is a list of products, you have signed up to redo the work every time the list changes. The layer underneath the tools barely moves at all. What I could throw away this afternoon This isn’t a thought experiment. These are things I’ve already changed, or could change today. The chat app: work shows up as messages, whether that’s Discord or Teams or an email inbox. Changes one small piece of code. The task board: cards, columns, comments, done. That’s Asana, or Trello, or Linear, or the one I use - Fizzy, by 37Signals. The AI model: today that’s Claude, and I like it. I’m using Anthropic’s Fable and Opus and Sonnet for the right-sized tasks for those models. My helpers are described in plain writing, so what runs them underneath is a setting. If something better arrives next year I change the setting, and every one of them still knows what it’s for. The places I publish: Substack, LinkedIn and X are all driven from a browser I’m already signed into, so none of them has me locked in through a connection I would have to rebuild. When Substack added a scheduler for Notes, switching to it took one morning, because my system already knew what a scheduled piece was. The part I couldn’t throw away is the part nobody sells you: what each helper is for. The rule that one of them may never rewrite another one’s work. The single gate that needs a human. Those took real thinking. They’re also just words in files I own. Your history should belong to you The clearest example is where my writing lives. Every piece I have written, drafted, killed or published is a list of lines in a file in my own folder. Just over a thousand pieces across 222 days. 636 of them went out. Every change is one line with a time and a name on it. The searchable copy sitting on top of that file is throwaway. I delete it and rebuild it from the lines whenever I feel like it, and I have. If that history lived inside somebody’s app instead, I’d be renting my own memory. Most people make that trade without noticing, because the app is genuinely good and there’s an export button right there in the settings. Why almost nobody talks about this part There is nothing to buy. Nobody advertises “spend an afternoon deciding what each part of your business is actually for.” It doesn’t look good in a screenshot. It’s also harder. Comparing tools takes twenty minutes and feels like progress. Writing down exactly what you want, clearly enough that the right tool becomes obvious, takes an afternoon and feels like you didn’t do anything at all. So everyone writes the tool article. It’s quick to write, quick to read, and somebody buys something at the end. I’m not against those articles. I wrote one this week. But it answers a question that expires, and the reason mine keep working is that I answered a slower question first. The one question I ask before adding anything What happens to my system if this exact product disappears in eighteen months? If the answer is that one small piece of code changes, it goes in and I barely think about it. If the answer is that my history lives inside it, or that the way I work would be shaped by its buttons? Then it doesn’t go in. Or it goes in, and I keep my own copy of the record somewhere I own. That question has kept me away from products that were better than the ones I use. It was worth it every time. A slightly worse tool that leaves you holding your own history beats a better one that holds it for you. Try this before you pick anything else Write down how your business works on one page, without naming a single product. Who does what? What decides what? What has to be written down? Where a person is required, and why it has to be a person there? Most people can’t finish that page on the first try. That’s the useful part. Every place you get stuck is a decision you have quietly handed to a product. Then, go and pick your tools. You’ll find the choice is much easier, and much less interesting, which is exactly what you want. PS. If you want a resilient setup for your own business, I can help. Get full access to G8N•AI at www.g8n.ai/subscribe

  5. Aug 26

    The Best Product Fix Was Deleting the Feature

    An instructor told me the attendance-code flow in uPoll was confusing students. The obvious response was to make the instructions clearer. We could have changed the wording, moved the code higher on the screen, or added another line to onboarding. Each option would have been quick. Each would also have preserved the thing causing the confusion. So we removed attendance-by-code entirely in uPoll v3.0.0. Students now get an alert when attendance opens. There is no code to receive, remember, or type. The instructor still gets the outcome the feature was built to provide. The student carries less of the design. That was the strongest product decision I made this week, and most product teams are organized to avoid it. A shipped feature starts defending itself Once a feature exists, every conversation about it starts with the same quiet assumption: the feature stays. People discuss copy, placement, speed, error messages, and training. The debate sounds practical because those are all things a team can change. Nobody has to reopen the earlier decision or explain why the work was built in the first place. The feature also has weight now. Somebody designed it. Somebody wrote the code. Tests cover it. Documentation names it. A release note announced it. Removing it can feel like admitting that work was wasted. That feeling is expensive. The work is already spent. Keeping the feature doesn’t recover it. It only asks every future user to keep paying for the original decision. This is known as the sunken cost fallacy: a cognitive bias where people continue an endeavor or stick with a decision because they have already invested time, money, or effort, even when quitting is the more logical choice. In this case, the payment was tiny: one code entered during class. But tiny friction repeated across a room still becomes the product. A student doesn’t experience the architecture or the reason the feature made sense on a whiteboard. The student experiences one more thing standing between opening the app and being counted present. The instructor’s report gave us a chance to defend the interface or protect the outcome. We chose the outcome. The feature wasn’t the job Attendance codes were one way to answer a larger need. An instructor opens attendance. Students respond. The instructor gets a usable record. The code was an implementation detail inside that flow. Over time, it had started acting like the flow itself. This happens easily when you build software. The database has a concept, the interface gets a screen for it, and the team starts speaking about the screen as if users arrived wanting that object. Users rarely want the object. They want to finish a piece of work with less effort and more confidence. That distinction matters because a request about a feature can carry two very different messages. Some feedback says the feature is doing the right job and needs a better edge. In the same release, direct user requests led to collapsible poll answer options and a grade-display fix. Those changes preserved the underlying interaction and made it easier to use. Other feedback says the user is carrying work that belongs to the product. The attendance-code report was that kind. Improving the code screen would have made us better at asking students to do something the alert model could remove. You can’t tell the difference by counting requests. One clear report from a person using the product in a real classroom can expose more than a backlog full of feature ideas. The useful signal is where the burden sits. Deletion requires a written outcome Teams struggle to remove features when nobody wrote down what those features were meant to accomplish. Without that sentence, the feature becomes its own justification. Attendance-by-code exists because the product has attendance codes. The circular logic feels solid inside a roadmap review because everyone already knows the nouns. A plain outcome breaks the circle. For this flow, the outcome is an instructor opening attendance and getting a reliable record while students do as little extra work as possible. Once that is visible, the code has to compete with every other way to reach the same result. An alert is simpler for the student, so the old implementation loses. I use four lines to pressure-test a feature before adding another patch: * Name the user outcome without using the feature’s name. * Name the work the current design puts on the user. * Sketch the shortest path to the outcome with the current feature removed. * Compare that path with what real users have already reported. The first line does most of the work. If a team can’t describe the outcome without naming the interface, it has probably confused its solution with the user’s job. The second line makes small burdens visible. A code, an extra confirmation, or a required status choice can look trivial in isolation. Users experience the accumulation. The third line creates permission to start over on paper. No migration plan is needed yet. No estimate. Just a sketch of the cleanest route. The fourth line keeps the exercise honest. A tidy diagram made in a product meeting is weaker than a sentence from somebody using the thing under real conditions. Feedback is evidence, not a specification The instructor didn’t arrive with a replacement architecture. The report was narrower: the attendance-code flow confused students. That distinction protects both sides of the product conversation. Users shouldn’t have to design the system for the team. They know the moment where the work becomes awkward. The builder owns the translation from that moment into a product decision. Sometimes the translation is direct. A request for collapsible poll options points to a clear display problem. A grade that appears incorrectly points to a clear result that needs correction. The job and the requested change line up. The attendance report reached deeper. The confusion lived inside a step that the product could remove. Treating the report as a request for clearer code instructions would have translated the words while ignoring the work. This is why a feature-request list isn’t a roadmap by itself. Two requests with the same number of votes can carry different product information. One asks you to make an interaction work as intended. The other reveals that the interaction has become a tax on the outcome. I don’t need a large survey to inspect that second kind of report. I do need enough context to understand the real use, the stakes of changing it, and the path that replaces it. Deletion should come from evidence and a protected outcome, not from impatience with maintenance. The standard is simple: remove the feature only when the replacement asks less from the user and still does the job. That is subtraction with responsibility behind it. AI makes the wrong fix easier to ship AI can produce all the obvious patches fast. Give it a confusing screen and it can rewrite the instructions, move the field, add validation, generate tests, and draft the release note before the meeting ends. That speed makes a patch feel cheap. The hidden cost sits with the user. Every patch that preserves the wrong interaction adds more code around the original assumption. The system gets larger while the experience barely improves. This is one reason I don’t treat AI as the product decision-maker. It can explore five implementations in minutes. It can’t decide which burden my users should keep carrying under my name. That call needs the context around the work and responsibility for what ships. The useful 70/30 split shows up clearly here. AI can handle a large share of production. I keep the judgment about what deserves to exist. Faster building raises the value of deletion because adding another layer has almost no immediate friction for the builder. When code was expensive, effort forced some restraint. Now the restraint has to come from taste, observed use, and a clear outcome. Deleting a feature is still product work Removal can look like less ambition from outside the team. Inside a product that people use, it is often the cleaner form of progress. We still had to change the flow, update the surrounding behavior, and make sure the alert model carried the job the code used to do. Deletion didn’t mean shrugging and walking away. It meant spending the effort on a simpler contract with the user. That contract matters more as a product grows. uPoll now has 297 students, 120 lectures, 520 polls, and 1,172 responses in its production aggregates. Those are counts, not engagement claims. They tell me the product is far enough past its first demo that a small burden can reach a lot of real use. At that stage, shipping more surface area isn’t automatically progress. The product earns trust when each new version asks less from the people using it while protecting the outcome they came for. The attendance change did that. Students stopped carrying a code. Instructors kept the attendance flow. The product became smaller at the exact point where it became more useful. A ten-minute deletion review Open the backlog for one product or internal workflow you own. Pick the feature that keeps attracting requests for clearer instructions, better placement, or one more exception. Set a timer for ten minutes and write four lines: * The outcome the user needs. * The work the feature puts on the user. * The simplest route with the feature removed. * The evidence from someone who actually uses it. If the new route protects the outcome and removes work from the user, give deletion a real place in the next product conversation. Don’t let the time already spent make the decision for you. The best fix may leave you with less software to maintain and a better product to use. PS. If your business is carrying workflows that keep getting patched but never get simpler, I help map the outcome, remove the unnecessary steps, and build the parts worth owning. Start at coaching

  6. Aug 19

    The Three Sentences My System Couldn’t Write

    My content system produced every draft last week. On time, in my voice, with the images rendered and the comments already written. Five decisions have been sitting in its queue waiting on me. The oldest is fourteen days old. I built the thing to remove my bottleneck. It removed the one I was looking at. So I went back through the last three weeks looking for the things that actually changed a situation for somebody, which is a different list than the things that got produced. Three came up. My system wrote none of them. All three were sentences I said out loud, in conversations, and two of them took under a minute. What the system actually took off my plate I want to be precise about this, because “AI does my content” is the kind of claim that sounds like either a boast or a confession depending on who’s reading. Here is the real division: drafting is handled, and research reads the field and comes back with what people are actually saying this week, sourced. Voice matching is handled well enough that I stopped rewriting openings. Images render. Scheduling holds. The system will not publish anything without me, and that gate has never moved. That’s a genuine amount of work gone. Ten months ago, most of a Tuesday went into one newsletter, a LinkedIn repurposing, and two Substack notes. The shape of it, since a few of you asked after last week: every morning a batch gets drafted and lands in a dated folder with a queue file next to it. Each item has an ID, a status, and a line saying what it’s waiting on. Nothing moves out of that folder without me supplying the ID. When something publishes, the system writes back what actually happened, including when it failed, and I read that rather than assume the send worked. The interesting part is that almost all of the engineering went into the refusals: the checks that stop a thing from going out when a gate cannot be verified. What’s left is smaller and much harder to hand off. Every item in that queue is a judgment call with two defensible answers. Keep pursuing a conversation that’s gone quiet, or let it close. Retire a tool that’s failed repeatedly, or keep trusting it. Approve a post the system has surfaced four separate times, or admit I’m never going to run it. The system can draft all of those. It can argue both sides better than I can. It cannot decide, because deciding requires knowing which outcome I actually want, and I’m the only one who has that. Two words, in a conversation I wasn’t managing Late July. I was talking with someone I’ve met recently about what he was building. He had the experience, he had the track record, and he was describing his offer in a way that took four sentences and still left you unsure what you’d be buying. I said two words, well, two that mattered: “Fractional CTO.” That’s it. I didn’t write him anything. I didn’t build him anything. I named the thing he was already doing. Eight days later he’d rebuilt his entire offer around it, had two people he trusts review the result, and sent the finished structure back to me. Along with a video he thought I should watch, which turned out to reframe how I price my own work. I’ve thought about that exchange more than anything my system produced that month. Two words, from a twenty-year pattern library I didn’t consciously consult, and it reorganized someone’s business. Then the return came back around without either of us selling anything. No model in my stack makes that call. The words themselves are easy. Knowing which two matter to this specific person, at this specific moment in his thinking, requires having sat in that conversation. The call where I gave away the framework Two weeks ago, a working session with someone trying to figure out where AI actually fits in her QA work at a large company. She came in with the question most people bring, which is some version of “what should I use.” That question has no good answer, and answering it directly is how people end up with eleven tools and no workflow. So I gave her a different one. Where do you want this process to be in six months, described as if it already works? Then we worked backwards from her answer. Out of that came a decision rule she can apply without me. When the thing you want is a repeatable procedure you’ll run the same way every time, build a skill. When it needs to look at a situation and choose, build an agent. Most people build the agent first, then spend a month debugging judgment they never needed. She left with a specific recommendation for her own workflow and a rule for the next twelve decisions. I left with a sharper version of the rule than I walked in with, because explaining it to someone with a real constraint is what exposes where it’s vague. My system could have written a thorough article about skills versus agents. It could not have watched her describe her workflow and noticed that the future-state question was the one she needed. The thing he’d already told me he needed The third one is barely a sentence, and it’s the one I almost missed. Someone described a problem to me in detail, as a side note to other things he was telling me about his business and how their business and team leverages AI. His team’s best AI work was stuck on one person’s laptop. Useful things being built, none of it reaching anyone else, and everybody who wasn’t already AI-literate getting more overwhelmed with each new tool. Then he wished, almost as an aside, that he could get a daily digest of his meetings with risks flagged. I’d been running exactly that since July. Every recorded meeting, full transcript rather than the vendor’s summary, decisions and commitments pulled out, anything needing a human pushed to a channel where I’ll see it. Building it was never the valuable part. It already existed. The value was in hearing an aside as the actual request, and recognizing that the thing I run for myself every morning answered the problem he’d spent months trying to solve. That’s pattern matching across two conversations that a transcript would have flattened into one line of small talk. What these have in common Each one took less than a minute of output. Together they produced more value than everything my system generated in the same period, and I say that as someone who genuinely likes what the system produces. The common thread is that all three required being present while somebody else was thinking. Not retrieving information. Sitting in a live situation with enough context to know which of a hundred true things was the one worth saying right then. Notice what none of them required. Speed wasn’t the constraint in any of them, and neither was volume or a better model. Two of the three were things I already knew and had already built, waiting for the moment where they applied to someone. There’s a version of this that turns into a comfortable story about human irreplaceability, and I don’t believe that version. The models are getting better at more of this every quarter, and anyone telling you where the permanent line sits is guessing. Here’s the narrower claim I’ll defend: right now, today, the constraint in my business is not production. It’s the number of live situations I can be genuinely present in, with enough context loaded to say the useful thing. My system expanded my output roughly fivefold. It expanded that second number by zero. Which is why the queue keeps growing. Where this leaves you If you’ve built something that drafts for you, you already know the feeling. The relief lasts about three weeks and then you notice the work didn’t leave, it concentrated. What’s left is denser and it’s all yours. None of that argues against building the system. Mine gave me back most of a day a week and I’d build it again tomorrow. It does argue for being honest about what the day is for. I’ve started treating the queue as the actual job rather than the overhead. Five open decisions is not an embarrassing backlog, it’s the accurate measure of what only I can do. Fourteen days is too long, though, and that one’s on me. Do this in the next ten minutes. Open whatever holds your undone work. Go through it once and mark every item that is genuinely a decision rather than a task, meaning two defensible answers and no amount of research settles it. Count them. That number is your real workload now. Everything else is production, and production is the part you can hand off. Then take the oldest one and decide it today. The answer may well turn out wrong. It has been costing you attention every time you look at that list, and a decided-wrong is cheaper than an open-forever. Mine was fourteen days old. I closed it this morning. PS. If you’re staring at a list like that and most of it turns out to be production rather than decisions, that’s the gap I help people close. I map how the work actually runs today, build the pieces that should run without you, and stay long enough to see whether your team is still using any of it in month five. Reply to this email and tell me what’s on your list. Get full access to G8N•AI at www.g8n.ai/subscribe

  7. Aug 13

    When the Model You Rented Disappears

    Anthropic’s most capable model went live on June 9th. By June 12th it was gone. On July 1st it came back. Eighteen days, and nobody who had built on it picked a single one of those dates. That’s the part worth keeping now that the panic has passed. Fable 5 launched with a million-token context window and the best coding score anyone had posted, free to paying subscribers, and people wired it into their products the way you wire anything that looks permanent. Then the Commerce Department ordered access suspended under export-control rules, citing national security. The instruction covered any foreign national, inside or outside the United States, including Anthropic’s own employees. There was no way to comply narrowly on that deadline, so the model went dark for everyone. Two and a half weeks later the controls were lifted and it returned. I’m not writing this to pile onto Anthropic. I use their tools every day, and an impossible order arrived with a clock on it. I’m writing it because of what those eighteen days did to people who had made one model “load-bearing”, and because the ending makes the lesson easier to ignore than it should be. Rented reach, rented foundations I’ve said for a while that the followers you collect on a platform aren’t yours. You rent access to them, and then the landlord changes the rules whenever they want. Fable 5 pointed that same lesson at a different part of the stack. A legal-AI startup called Legion went to court over it, because their product stopped working the moment the model did. Their filing put it plainly: every day the directive held disrupted their product and operations, sidelined their engineers, and eroded the company’s ability to survive in a field defined by continuous access to the most capable models. Legion did exactly what everyone tells you to do. They built on the best model available, and then they learned what “available” means when it depends on a vendor and a government you don’t control. Across developer forums the conversation shifted inside a week. It stopped being about which model scores highest and started being about single points of failure. Teams that had hard-coded one provider spent those days building the ability to fail over to another. The ones who already could just kept working. Tying your business to one frontier model isn’t a safety net. It’s a hope. Draw the line before you need it You can’t self-host a frontier lab, and you shouldn’t try. What you can do is decide, in advance and in writing, which parts of your system have to be yours and which parts you’re happy to rent. I run my business on something I built called Core: my CRM, my tasks, my content, and the record of what actually shipped. That lives somewhere I control and can move. I self-host the pieces that are genuinely mine, the hosting and email behind my core workflow product. Everything else is a deliberate rental. Supabase runs my production databases, and it earns its keep with backups and security I’d otherwise be maintaining at two in the morning. Kit and Substack handle publishing. All in, I’m paying somewhere around a hundred dollars a month across managed services, and that number goes up as I ship more. Sovereignty was never a cheap monthly bill or cancelling all your SaaS. It’s owning the core and renting only what genuinely earns its place. The models sit firmly on the rented side, and they’re deliberately swappable. When one’s best for a job, I use it. When it’s gone, I route around it. The value was never in any single model; it’s in the harness around it, the contracts between the pieces, and knowing my own work well enough to point whatever model is standing at the problem. The lane nobody can switch off Since June I’ve been building one piece of insurance, and it isn’t a second subscription. At 1:46 in the morning last week, two models running on my own laptop each drove a 39-turn research loop with live web search across ten topics, and both produced valid structured reports. No API bill, no account, no policy anywhere that could switch them off mid-run. They’re not as good as the frontier models. That isn’t the point. The point is that a lane nobody can revoke changes what the revocable lanes are allowed to cost you. Bounded, repetitive, verifiable work is a good candidate: research, extraction, summarizing, the tasks where you can check the output yourself in seconds. I’d also rather state the reason plainly than dress it up. Quota exhaustion is a routine operating condition here, not an incident. And the subscription policies underneath all of this have reversed three times in four months, which I keep on my risk list rather than in my feelings. Owning one lane outright is how a policy change stops being an outage. What this isn’t It’s easy to turn one strange month into a sermon, so let me be careful. This isn’t an argument to abandon the big models. They’re remarkable, they do things nothing on my laptop can approach, and you should use them. You also don’t need an elaborate five-provider routing layer you’ll never maintain. Building that before you need it is its own kind of trap. And I’m not predicting a repeat. The controls lifted, the model came back, and the specific politics of June may never recur. What you got was a free, low-stakes look at what a hard dependency feels like when it fails. The next one will cost more than a look. Do this in the next ten minutes Open whatever runs your business and find your single biggest dependency on something you don’t control. The model behind your app. The platform that holds your audience. The service that holds your data. Write one sentence: if this disappeared for three days, here’s exactly what I’d do. If you can answer cleanly, you own the seam and you’re fine. If the honest answer is that you’d be stuck, you’ve found the first thing worth fixing, and it starts smaller than you’d think. Export the data. Write down the manual fallback. Turn one hard-coded provider into a setting you can change. You don’t need to predict the next directive. You need one dependency you’ve stopped pretending is permanent. If you want help working out which layer to own first, and then building it, that’s exactly what I do with operators. Get full access to G8N•AI at www.g8n.ai/subscribe

  8. Aug 5

    The Decisions That Carried the Outage

    At 1:19 in the morning on Saturday, my primary AI assistant hit its usage ceiling and went dark for two days. I found out later that morning, the way you find out about good news: nothing was wrong. The Saturday content batch was drafted, staged, and waiting for my review, exactly where it always is. Sunday ran the same way. A backup had taken over both mornings, followed the same rules, and left the same paper trail. Nothing about that weekend was lucky. Every decision that carried it was made three weeks earlier, in calm conditions, when nothing was on fire. That gap, between when protection gets designed and when it gets tested, is what this edition is about. The three decisions A takeover contract, written down where any tool can read it. There’s a small file on disk for each day. It says who owns the day’s run, when they claimed it, and what state the work is in. The rule lives in the file, in plain text: if the owner goes quiet for forty-five minutes without delivering, or marks the day failed, the backup may take over. A rule agreed on in advance and enforced by whoever shows up, instead of a meeting or a 7 a.m. judgment call. When the primary went dark, the backup didn’t have to decide anything. It read the file, saw the conditions were met, and started working. The decision had been made weeks before, by me, once. A deliberately underpowered backup. The backup can draft everything and publish nothing. It works in a sandbox with no network access: it can’t publish or email anything, and it can’t touch a live system. A separate delivery step, with its own checks, moves finished work to where I review it. I weakened the backup on purpose, and trust had nothing to do with it. Permissions are the honest form of governance. Anyone can write a policy document that says “the backup will be careful.” The sandbox makes carefulness structural. When it took over, the worst it could possibly do was already decided, and it was small. A gate that doesn’t move. Nothing publishes under my name without my word. That was true when my usual assistant was working, it was true while the backup ran the mornings, and it will be true for whatever model I’m running next year. The gate outranks the tools on both sides of it. Swap everything else out and the one thing a reader can rely on is unchanged: a human decided this was worth their time. What broke anyway, and why that was fine Honesty requires the other half. The backup couldn’t do everything. The parts of my morning routine that need live reads of the outside world, engagement data, other people’s posts, simply didn’t happen for two days. Those are exactly the powers the backup doesn’t have. That’s isn’t a hole in the design. That is the design. The blast radius of the outage was decided in advance: drafting continues, publishing waits for me, and anything requiring live access pauses cleanly instead of running on stale assumptions. I’d rather lose two days of engagement plans than have a backup improvise with yesterday’s picture of the world. A colleague-in-craft put the principle better than I had: Charlotte Ledoux wrote this week that AI agent governance is a design decision, not a clean-up job, and that most teams do it in the wrong order. They deploy, then discover what the agent shouldn’t have been able to do. The outage was my proof of the right order. By the time a system is being tested for real, the only decisions that count are the ones you already made. One detail I keep coming back to On Monday morning, with the primary back online, the backup still claimed the day first. It woke at 7:37. The primary showed up at 8:00 and found the work already staged, with a note in the contract file saying so. No collision, no duplicate, no confusion, because the same file that handles disasters also handles ordinary mornings. Systems that only exist for emergencies rot before the emergency arrives. The takeover contract works because it isn’t emergency equipment. It runs every single day, which means it was rehearsed hundreds of times before it mattered. The ten-minute version for your business Pick one process that would hurt if you were unreachable for two days. Invoicing, client replies, publishing, payroll approval, whatever stings to imagine dropped. Write three lines about it, somewhere your backup person or tool can actually see: * Who owns this, and how would anyone know they’ve gone quiet? * Who takes over, and after how long? * What is the taker-over explicitly NOT allowed to do without you? That third line is the one people skip, and it’s the one that matters most. A backup with unlimited permissions isn’t a safety net. It’s a second way to have an accident. The full system can come later. Something better already happened: the next outage now has rules waiting for it instead of improvisation. If you’d like systems like this running your business, calm on their worst weekend, that’s what we build together, step by step, in coaching. The strategy call is thirty minutes, and you’ll leave with at least one takeover rule worth writing down. Book whenever suits you. Get full access to G8N•AI at www.g8n.ai/subscribe

    The Decisions That Carried the Outage
See All (21)

About

GenerationAI • Focus with Intention and Leverage with AI Building in Public • Custom vibe-coded AI tools www.g8n.ai

Information

  • Creator
    Ahad Amdani
  • Years Active
    2025 - 2026
  • Episodes
    21
  • Rating
    Explicit
  • Copyright
    © Ahad Amdani
  • Show Website
    G8N•AI Podcast