DEV Community: Yao Xiao

The $42,000 API Disaster That Built a $130K MRR Empire: The Story of Tony Dinh and TypingMind

Yao Xiao — Thu, 12 Nov 2026 14:28:05 +0000

In February 2023, Tony Dinh was staring at his laptop screen in Ho Chi Minh City, confronted by an existential financial shock. Twitter, newly acquired by Elon Musk, had abruptly declared that enterprise developer access to its API would now cost \$42,000 per month.

At that exact moment, Dinh's primary software product, an engagement and analytics tool called Black Magic, was generating roughly \$14,000 in monthly recurring revenue. Overnight, the platform math had turned upside down. Paying the fee meant losing \$28,000 each month simply to keep the servers turned on; refusing to pay meant his product would immediately go dark. For a solo engineer who had walked away from a comfortable corporate salary to bet on his personal independence, the ground beneath his feet had vanished.

Many founders would have spent months lobbying platform managers, negotiating debt, or sinking into despair. Dinh took a different path. Recognizing that platform risk had fatally wounded his business, he arranged an emergency sale of Black Magic to a competitor, took the lesson to heart, and looked for where the technological tectonic plates were shifting next.

Just weeks later, on March 1, 2023, OpenAI opened the developer floodgates by releasing its official chat completions API. Over a frantic 72-hour weekend sprint, Dinh wrote the first lines of code for TypingMind. It was an unpretentious web wrapper designed to bypass the sluggish official ChatGPT interface, built around a radical premise: users would bring their own API keys, and Dinh would never pay a single penny for their computing power.

Within seven days, that weekend hack produced \$22,000 in direct sales. Within nine months, as documented in Tony's milestone retrospective, the product surpassed \$1,000,000 in cumulative receipts. Today, TypingMind generates over \$130,000 per month in verified recurring and license revenue, running at an astonishing 85% to 92% net profit margin without a single full-time employee on the payroll.

Here is the true story of how an engineer from Vietnam survived platform bankruptcy, rethought software unit economics from first principles, and built one of the most lucrative one-person businesses of the generative AI era.

Who He Was Before the Breakthrough

Tony Dinh (legal name Dinh Quang Trung) did not emerge from a Silicon Valley incubator, nor did he possess venture capital backing. His software roots began in high school, tinkering with Visual Basic 6 to write small desktop scripts. He went on to study computer software engineering at FPT University in Vietnam, graduating into the standard corporate developer ecosystem.

For seven years, Dinh climbed the traditional engineering ladder. He wrote code for Vietnamese tech firms like Silicon Straits Saigon, worked on regional full-stack systems at Honestbee, and eventually landed a prestigious position as a Senior Software Engineer at the Singapore office of Zendesk. By mid-2021, he was earning approximately \$8,800 per month, an elite corporate wage by Southeast Asian standards.

Yet the corporate routine began to wear on him. Working on ticketing infrastructure inside a sprawling multinational organization felt disconnected from direct human impact. In September 2021, having accumulated roughly two years of living expenses in personal savings, Dinh resigned from Zendesk. He moved back to Vietnam, where the lower cost of living gave him an extended runway, and declared himself a full-time independent software maker.

The Stumbles That Forged His Instincts

Dinh's initial step as an independent maker was an immediate failure. Trapped in the classic developer mindset, he believed that superior technical complexity equaled commercial demand. He spent six consecutive months locked in his room, meticulously architecting a native macOS log viewer. He designed clean interfaces, optimized memory allocation, and wrote elaborate backend routines in complete isolation.

When he finally launched the app to the public, the response was total silence. Nobody wanted a specialized log viewer, and nobody was willing to pay for it. Six months of effort and a quarter of his hard-earned savings had vanished without generating a single customer.

That painful stumble forced a permanent mental reset. Dinh realized that building software in secret was financial suicide for a solo operator. He vowed never again to spend more than a few days building an unvalidated product. If an idea could not demonstrate genuine buying interest within a week, he would discard it without hesitation.

His second project, DevUtils, put this new philosophy into practice. It was a simple, offline developer utility bundle for macOS combining JSON formatters, base64 decoders, and regex testers. Selling for a modest one-time fee, DevUtils steadily grew into a reliable income stream, generating around \$5,000 per month with virtually zero ongoing maintenance.

Emboldened, Dinh launched Black Magic in 2021 to help creators schedule threads and analyze engagement on Twitter. By documenting his progress openly under the hashtag #buildinpublic, his audience on Twitter expanded rapidly, and Black Magic climbed to \$14,000 in monthly recurring revenue. For a solo maker living in Vietnam, life was extraordinarily comfortable.

Then came Elon Musk's takeover of Twitter, the \$42,000 monthly enterprise API fee, and the sudden destruction of his primary livelihood.

In May 2023, Dinh finalized the sale of Black Magic to Hypefury for \$128,000, as recorded in Tony Dinh's personal updates. It was a modest exit compared to the valuation the business had commanded only months earlier, but it provided him with cash and, more importantly, relieved him of a compounding monthly liability.

The Turning Point: A 72-Hour Weekend Hack

The Twitter catastrophe taught Dinh the most vital lesson of his career: if your software business depends on paying an upstream monopoly for API access, you are not a founder; you are an unpaid tenant farmer. When the landlord raises the rent, your margins evaporate instantly.

In late February 2023, Dinh was using OpenAI's ChatGPT Plus subscription (\$20 per month) every day for his coding workflows. The experience was deeply frustrating. The web interface suffered from frequent gateway timeouts, logged users out multiple times a day, lost past conversation records, and imposed a strict cap of 25 messages every three hours. Worst of all, there was no way to search past chats or categorize prompts.

Yet on March 1, 2023, OpenAI released the developer API for its flagship models. Dinh noticed something fascinating: while the public web portal was struggling under server load, the developer API was lightning fast, highly reliable, and billed on a fractional usage basis (costing fractions of a cent per prompt).

Dinh asked himself a simple question: why should a power user pay \$20 every single month for a slow, locked-down web interface when they could use their own API key and get a superior experience for pennies?

Over the weekend of March 3 to March 6, Dinh built TypingMind.

He did not build a complex backend. He did not set up a server cluster or an expensive user authentication database. Instead, he built a static web interface using Next.js and Tailwind CSS. The app lived entirely inside the user's web browser. When a user pasted their OpenAI API key into the settings, the key was encrypted and stored locally in their browser storage (localStorage and IndexedDB).

Whenever the user submitted a prompt, their browser communicated directly with OpenAI's API servers. Dinh's own servers merely delivered static HTML, JavaScript, and CSS files via Vercel.

Crucially, this meant Dinh had zero token costs. If an enterprise user ran ten million tokens through TypingMind in an afternoon, the bill went straight to the user's credit card on OpenAI. Dinh did not owe a single cent to any platform provider. He had completely decoupled his revenue from platform infrastructure costs.

The Business Behind the Story: Economics of the BYOK Model

On Monday, March 6, 2023, Dinh posted a raw 30-second video on his personal X account (@tdinh_me). The screen recording showed ChatGPT buffering slowly on the left side, while TypingMind on the right streamed responses instantaneously, complete with full-text search and customized system prompts.

He attached a simple Stripe payment link offering a lifetime license for \$39. Within twenty-four hours, more than fifty developers bought the license, generating \$1,500 in immediate cash flow.

A week later, Dinh submitted TypingMind to Product Hunt. The timing was immaculate. The product secured the #1 Product of the Day and #1 Product of the Week spots, attracting more than 100,000 visitors and producing \$30,000 in sales within 48 hours. By the end of his first month, TypingMind had collected \$100,000 in non-dilutive revenue.

As detailed in our full teardown of TypingMind's go-to-market, Dinh's growth was entirely organic. He ran zero Google search ads, avoided paid social campaigns, and hired no sales representatives. Instead, power users shared their customized prompt personas on Reddit, tech YouTubers demonstrated TypingMind as the premier tool for side-by-side LLM comparisons, and Dinh continued his practice of sharing raw Stripe financial screenshots on X.

Operating Dimension	Standard VC-Funded AI SaaS Wrapper	TypingMind BYOK Client Architecture
Upstream Inference Cost	High and variable; founder pays model vendors for every token consumed	\$0.00; user pays OpenAI or Anthropic directly via their personal API key
Server Infrastructure	Heavy GPU instances, vector database hosting, and high Redis bandwidth	Static edge hosting; static JavaScript served via Vercel and Cloudflare CDN
Gross Margins	40% to 65% (heavily eroded by token usage and compute overhead)	85% to 92% (virtually all revenue converts to owner profit after Stripe fees)
Platform Inflation Risk	Extreme; vendor price hikes instantly destroy SaaS profit margins	Zero; vendor price fluctuations are absorbed directly by end users
Data Privacy Stance	Transcripts stored on centralized servers, creating compliance liability	100% Client-Side; conversations remain encrypted in user's local browser

Yet success introduced an unexpected dilemma. As examined in our TypingMind unit economics breakdown, lifetime deals are a double-edged sword. While selling one-time passes for \$39, \$59, and \$99 brought in more than \$1,000,000 in cash during the first nine months, those lifetime customers continued to submit support tickets, ask for custom integrations, and expect perpetual updates whenever OpenAI, Anthropic, or Google launched a new model.

A solo founder cannot support tens of thousands of demanding lifetime users forever without predictable recurring revenue.

Dinh's second breakthrough was recognizing that companies were desperate for safe internal AI portals. Small businesses and agencies wanted their employees to use ChatGPT, but they feared data leaks and did not want to pay \$20 or \$30 per seat for individual ChatGPT Team subscriptions.

Dinh introduced TypingMind for Teams. For \$20 to \$50 per seat per month, or custom annual self-hosted deployments ranging from \$500 to \$2,000+, companies could install a shared corporate workspace. The company plugged in a single corporate API key, distributed seats to employees with role-based permissions, and preserved complete data privacy.

That single strategic pivot transformed TypingMind from a one-hit consumer utility into a durable B2B software engine. Today, recurring team subscriptions and enterprise licenses contribute the majority of the product's \$130,000 monthly recurring revenue.

Author's Comment: Many indie developers get addicted to the dopamine rush of one-time lifetime deal launches on platforms like Product Hunt. But lifetime revenue is a decaying asset; support debt compounds while marginal revenue drops to zero. Dinh's genius was treating lifetime sales as an interest-free crowdfunding campaign that funded the build-out of his high-ticket enterprise recurring subscription tiers. This pattern mirrors what we observed in our AudioPen case study, where initial lifetime passes provided the cash cushion needed to build a sustainable recurring ecosystem.

A Little Engine Under the Hood

The technical architecture of TypingMind is striking for what it deliberately chooses not to do.

Rather than maintaining complex server-side pipelines for multi-tenant data isolation, the core application is an entirely client-side web application written in Next.js and styled with Tailwind CSS. When an end user activates web search, attaches an image for vision processing, or switches from GPT-4o to Claude 3.5 Sonnet, the request is assembled inside the user's browser runtime and dispatched directly to the model provider using Server-Sent Events (SSE).

Because chat transcripts and encrypted keys reside within the browser's IndexedDB and localStorage, Dinh's monthly infrastructure overhead consists almost entirely of static asset hosting on Vercel and domain DNS on Cloudflare, totaling roughly \$250 per month. The single largest operational expense on his income statement is the standard 2.9% plus \$0.30 payment processing fee charged by Stripe. Builders who wish to model these operational dynamics can explore our LLM Cost Calculator to observe how avoiding intermediary token markup fundamentally alters micro-SaaS balance sheets.

What His Story Teaches Builders

Dinh's trajectory from an anxious corporate employee to a solo software multi-millionaire offers concrete lessons for anyone building in the AI landscape:

1. Own the Interface When the Underlying Compute Is Commoditized

Every time a frontier AI lab releases a smarter, faster, or cheaper model, standard AI wrapper companies panic because their custom fine-tunes or specialized wrappers become obsolete. TypingMind benefits from model competition. Whether OpenAI, Anthropic, Google, or open-source Ollama models lead the benchmark charts, TypingMind users simply paste the latest API endpoint into their client and continue working. Dinh turned foundation model commoditization into his greatest growth driver.

2. Protect Your Business Against Platform Extinction

Dinh's near-bankruptcy with Twitter's API taught him that relying on upstream goodwill is a structural vulnerability. By adopting the BYOK model, he eliminated platform counterparty risk. If an AI provider adjusts its pricing or throttles API throughput, the operational impact falls on the user's direct account, leaving the software vendor completely insulated.

Practical Pitfall Avoidance Guide: If you are building a product on top of third-party APIs, calculate your unit economics assuming the provider increases token prices by 300%. If that price increase destroys your business, your architecture is broken. Either pass token costs directly to users through BYOK or construct pricing models with wide defensive margins.

3. Ship When You Are Still Embarrassed by the Code

TypingMind was built in three days. The initial release had no team collaboration, no custom plugins, no document vector search, and no native desktop app. It was merely a clean text box connected to an API key input. Had Dinh spent six months perfecting the feature set, the window of market opportunity would have closed, and competitors would have claimed the space. In fast-moving technological transitions, distribution speed is the only real moat.

4. Build in Public to Accumulate Organic Distribution

Dinh did not build his audience after finishing the product. He accumulated his following over years of sharing real code snippets, candid revenue charts, and open post-mortems of his failures. When TypingMind launched, he already had thousands of developers ready to amplify his announcement. Distribution is an asset that must be cultivated long before you have something to sell.

The Builder's Takeaway

Look at the tools and platforms you use every day in your own workflow. Where are you tolerating friction, slow performance, poor search functionality, or restrictive rate limits simply because the official interface was designed as an afterthought?

You do not need to invent a proprietary foundation model, raise millions in venture capital, or manage an offshore engineering team to build a life-changing software business. As Tony Dinh proved when his Twitter business collapsed, sometimes all it takes is 72 hours of intense focus, a refusal to accept unnecessary server debt, and the clarity to solve a real irritation for people who use software to get work done.

AI Won't Replace Your Juniors First. It Will Expose the Managers Who Press Play

Yao Xiao — Thu, 12 Nov 2026 14:23:06 +0000

The standard story goes like this: AI eats the entry-level work first, the career ladder loses its bottom rungs, and a generation of juniors never gets to learn the job. It is tidy, it is scary, and it fits the headlines about a soft graduate job market.

Karim Lakhani, the Harvard Business School professor who has run randomized AI experiments at BCG, Procter & Gamble and H&M, thinks the story points at the wrong people. Sitting across from Marina Mogilko on Silicon Valley Girl, he said the quiet part out loud:

"If anything, people that may be at risk are more in the middle management layers than in the junior layers from my perspective."

He was careful to say the question is not settled, and that the early-career market is soft for several reasons, AI being only one of them. But his observation from inside real companies is specific, and it deserves more than a shrug. You can read the full exchange in our timestamped breakdown of the interview.

The Contrarian Insight: Risk Follows Behavior, Not Seniority

Lakhani's argument has two halves. First, juniors are "fearless" with these tools. He describes undergrads who "whip up all these things so quickly." They have no legacy workflow to defend, so they just build.

Second, the middle layer is where he sees the most resistance. In his words, the 35-to-55-year-olds are the ones pushing back against AI usage and not changing, while the more enlightened senior people and the junior people "could run circles around most of the organization."

Read that again. The vulnerable group is not defined by pay grade or age. It is defined by one behavior: refusing to rebuild how you work. The title on your badge is a lagging indicator.

That framing connects to the sharpest idea in the whole conversation, which is a taxonomy of how people use AI.

The Press-Play Problem

In the BCG work, Lakhani and his colleagues saw three working styles. Cyborgs work jointly with the model, trading moves in a tight loop. Centaurs divide the labor: "I'm good at X, the AI's good at Y," then supervise what comes back. And then there is the third group:

"In terms of learning, the self-automatons do the worst because they have stopped thinking, they've stopped engaging in the activities"

In the interview, the host quoted a split of 60% cyborgs, 14% centaurs and 27% self-automators from the consultant study. Whatever the exact proportions in your own company, the shape of the failure is what matters. The self-automator "presses play" and forwards the result.

Now map that onto a middle manager's job. A large share of it is routing: summarizing what the team did for the layer above, translating strategy into tasks for the layer below, approving documents that someone else drafted. Every one of those activities is also something a model can do tolerably well on the first try. The manager who pipes model output upward is not a manager with AI leverage. In Lakhani's phrase, they are a meat interface to the silicon, and a meat interface is the cheapest component to swap.

Author's Comment: I find the junior-versus-manager framing less useful than the behavioral one. A 24-year-old who pastes model output into a deck without reading it is a self-automator. A 50-year-old who interrogates every claim is a cyborg. Seniority is a distraction; engagement is the variable.

First Principles: Why the Middle Is Structurally Exposed

Three mechanisms stack on top of each other.

1. The middle's product is information handling, which is exactly what LLMs commoditize. Individual contributors produce artifacts. Executives make a small number of high-stakes calls. The middle converts, compresses and relays. When the cost of compression drops toward zero, the relay role has to justify itself with judgment, not throughput.

2. Fluent output punishes passive review. Lakhani's research with Dell'Acqua and colleagues on the jagged technological frontier found that consultants with GPT-4 completed 12.2% more tasks and finished 25.1% faster on tasks inside the model's competence. On a task deliberately placed outside it, AI users were 19% less likely to reach the correct answer than people working without AI. The model sounded equally sure in both cases. In the interview he puts it plainly: the intelligence "is not perfect, but it talks really well," and it "can be very persuasive." A reviewer who skims a confident wrong answer is worse off than one who never had the tool.

3. Incumbency taxes adaptation. Juniors pay no switching cost. A manager with fifteen years of tuned judgment has to admit that part of that tuning no longer applies. Lakhani's observation is that the people with the most to lose are the least willing to experiment, which is the textbook shape of disruption.

There is a fourth effect that raises the stakes: the same research program found that a single professional with AI, in a P&G field experiment, performed on par with a two-person team without it. If one engaged person plus a model can match a pair, the coordination layer built to manage pairs and teams has to be rethought, not defended.

The learning side is just as ugly. Daron Acemoglu makes a related argument in our brief of his interview, where he explains why the pocket-calculator analogy breaks down for AI: a calculator never did anyone's thinking for them. Self-automation does. Lakhani's "stopped thinking" and Acemoglu's atrophy are the same failure seen from two disciplines.

Second-Order Effects: What Everyone Is Getting Wrong

If this is right, a lot of current corporate behavior is miscalibrated.

Companies protect juniors and neglect managers. Training budgets go to "AI onboarding" for new hires, while managers get a memo. The people who most need hands-on exposure get the least.
Leaders delegate the learning. Lakhani's email story (card 8 of our interview brief) is the best line in the interview: bosses' bosses once had assistants read their email aloud and dictated replies, and some "never did email or did the email 10 years later." Same pattern today, he says: "Somebody else's job, not my job."
Founders mistake a thin layer for a moat. His blunt question to law firms and manufacturers is "why should you exist?" if all you are is a thin wrapper around a frontier lab's model. Greg Brockman makes the complementary argument in his interview brief: build products whose value grows as the models get smarter, rather than patching today's limitations.

The pattern is fractal. A person who only forwards model output, a team that only relays it, and a company that only resells it are all the same shape at different scales.

The Builder's Playbook

Here is what to change on Monday morning, whether you manage a team, lead a product, or write the code.

1. Run a delegation audit. Take your last ten AI-assisted tasks and label each one: cyborg, centaur or self-automator. The test is simple. If the model had quietly been wrong, would you have caught it? If not, you automated blind. Move those tasks to a tighter loop or take them back.

2. Make the model argue with you. Lakhani's own recipe is refreshingly mechanical: "don't believe what I'm saying either," counter-argue every proposal with three arguments against it, and always follow up with additional research that hunts for red flags and "black swans." Bake it into a reusable system prompt:

You are my adversarial reviewer. For every proposal I give you:
1. Give three independent arguments for why it is wrong or irrelevant.
2. Run a second pass looking only for red flags and low-probability failures.
3. Do not agree with me. Rank your objections by how expensive they would be if true.
4. List what evidence would change your mind.

If you want structured versions of this loop, our Recursive Reflection framework and the prompts in Effective Prompts That Make AI Admit It Doesn't Know are good starting points.

3. Never take the first answer. Lakhani repeats it twice in the interview: "I never take the first answer." He also advises spending tokens freely while the tooling matures: let a research agent go much deeper than its thrifty default.

4. Own the sign-off. Adopt a one-line rule: if you cannot defend a number or a claim with the chat window closed, you do not ship it. His line on termination is blunt: he has fired people who answered "the AI gave me that."

5. Redefine the job, not the tasks. The productive question is not "which of my tasks can AI do?" It is "what would this role look like if I did ten times more?" Managers who answer that, and then retrain their teams around it, are the ones Lakhani describes as accelerating.

6. Test your own wrapper-ness. Ask whether the next frontier model makes your role, product or company more valuable, or absorbs it. If you cannot answer, that is your first research project.

Practical Pitfall Avoidance Guide: Do not respond to this by making AI mandatory with a usage dashboard. Counting prompts rewards exactly the self-automator behavior you are trying to prevent. Measure whether people can explain, defend and improve what the model produced.

Takeaway

The question to ask about your career or your team is not "are we senior enough to be safe?" It is "are we thinking, or just forwarding?" Open your last AI-assisted deliverable and look for the place where you pushed back on the model. If you can't find one, you have already pressed play.

15 Failed Projects, a Goa Supermarket, and a 12-Hour Hack: How Louis Pereira Built AudioPen to $20K MRR

Yao Xiao — Thu, 12 Nov 2026 14:16:49 +0000

By day, Louis Pereira managed physical goods. In the coastal town of Porvorim, Goa, his family runs the Armacar Group, an enterprise anchored by Delfino's Supermarkets and retail hardware operations. His working hours involved supplier logistics, inventory sheets, physical shelf space, and the daily friction of brick-and-mortar commerce.

By night, he sat in front of a laptop, trying to build digital assets on the internet.

In late March 2023, during an informal twelve-hour public build sprint on social media, Pereira posted a short screen recording on X. He pressed a microphone icon, spoke for thirty seconds in an unstructured, rambling stream of consciousness, full of pauses, repeated words, and trailing phrases, and then hit stop. Fifteen seconds later, the screen refreshed. The conversational sludge was gone. In its place appeared two clean, elegant paragraphs of publish-ready prose that captured his exact intent.

Within forty-eight hours, more than one hundred strangers entered their credit card numbers to buy access.

What began as a half-day experiment soon expanded into AudioPen, a solo-operated software business generating between \$15,000 and \$20,000 in monthly recurring revenue with net profit margins hovering between 80% and 85%, as documented in our full teardown of AudioPen. He spent zero dollars on paid advertisements. He hired no engineers.

The interesting part of this story is not how quickly the prototype was assembled. It is what Pereira had been doing during the years leading up to that twelve-hour sprint, and why fifteen previous side projects had to fail before one could quietly strike gold.

The Economics Graduate in the Aisles

Pereira's path to software was entirely indirect. He studied Economics at St. Stephen's College in Delhi, worked in management consulting, and spent a couple of years running an early startup venture alongside college friends. When that venture ran its course, he moved back home to Goa to help run the family's retail and commercial operations, joining the next generation of family leadership profiled by Business Goa.

Working in physical retail is an education in operational reality. In a supermarket, margins are earned in pennies. You coordinate deliveries, deal with refrigeration units, manage cash flow, and navigate supply delays. Every transaction requires physical inventory and physical labor.

That environment provides deep respect for cash flow, but it also highlights the ceiling of physical geography. You cannot clone a grocery store across sixty countries overnight. The internet, by contrast, offered the intoxicating promise of zero marginal distribution cost. If you build something useful out of software, a user in San Francisco or London can pay you while you sleep in Goa.

That contrast created an enduring itch. Pereira wanted to build digital leverage, but he ran into an immediate obstacle: he did not know how to code.

He tried learning traditional programming languages, but syntax errors, terminal environments, and deployment pipelines repeatedly stalled his momentum. In 2021, he discovered visual development with Bubble. For the first time, a non-engineer could build functional web applications without writing raw JavaScript or managing database clusters.

He began building. And for two straight years, almost everything he shipped flopped.

The Fifteen Silent Rejections

Between 2021 and early 2023, Pereira built and released roughly fifteen separate apps, micro-tools, and side projects. Some were directories, others were productivity widgets. None achieved commercial traction. Most earned zero revenue.

In public discussions, including his appearance on The Bootstrapped Founder podcast with Arvid Kahl, Pereira described those early projects as essential tuition rather than wasted time. Each failed release taught him how to wire up Stripe webhooks, how to organize database fields, and how to structure responsive layouts on Bubble.

Equally important was what he was doing outside of product development. Pereira was a dedicated reader and writer. He published thoughtful essays on his personal publication, louispereira.substack.com, and curated longform reading material through a weekly publication called Read Something Great. On his personal X account, he shared his daily experiments and lessons in public.

He was not chasing viral trends or pretending to be an authority. He was simply documenting his learning process in public view. In doing so, he quietly assembled a modest, engaged following of independent creators, writers, and knowledge workers who trusted his taste and shared his interests.

That audience was small, but it was composed of people who valued clear thinking. When the right product finally arrived, that community provided the dry tinder.

The Agony of the Blank Page

The idea for AudioPen did not come from market research, TAM calculations, or competitor matrices. It came from a personal frustration Pereira encountered every week.

He thought best while moving. When walking outdoors in Goa, his mind generated clear ideas, arguments, and essay outlines. But the moment he sat down at his desk in front of a blank white screen, his momentum vanished. The blinking cursor created immediate cognitive friction.

He had tried existing voice recording and dictation apps. Apple Voice Memos captured audio, but required listening back to whole recordings. Dictation engines and transcription tools like Otter transcribed every word verbatim.

Verbatim speech, however, is terrible to read. Spoken language is stuffed with filler words like "um," "ah," and "you know," along with false starts, circular tangents, and grammatical fragmentation. A five-minute voice recording often produced a chaotic transcript that required fifteen to twenty minutes of tedious manual editing before it could be used as an email or an essay draft.

The pain point was clear: people did not need raw transcription; they needed cognitive translation. They needed a tool that listened to messy, rambling speech and extracted the clear thoughts underneath.

In March 2023, two events aligned. OpenAI made its Whisper speech-to-text API publicly available, offering high-accuracy transcription at fractions of a cent per minute. Simultaneously, an informal "Half-Day Build" challenge circulated on X, challenging makers to ship a functioning product in twelve hours.

Pereira gave himself a strict deadline. He opened Bubble, wired up the browser's media recorder, routed the audio blob into OpenAI Whisper, and piped the resulting transcript directly into an LLM with a carefully constrained system prompt. The prompt told the model to act as an elite executive ghostwriter: discard conversational filler, repair broken syntax, organize arguments logically, and produce refined, readable prose.

By the end of the twelve hours, AudioPen was live.

Author's Comment: Notice the distinction in how Pereira approached the problem. Most developers look at speech-to-text models and build transcription dashboards. Pereira looked at speech-to-text as an unpolished raw material. He treated the language model not as a generator of new ideas, but as a ruthless editorial filter. The customer was not buying transcription; they were buying the elimination of editing friction.

The Visceral Contrast and the ADHD Flywheel

When Pereira shared AudioPen on X, he did not publish a long thread detailing his tech stack or explaining model parameters. He simply posted a side-by-side demonstration of the contrast.

On one side was the audio: thirty seconds of disjointed, stammering speech recorded on a walk. On the other side was the output: three crisp, beautifully structured sentences that sounded like polished magazine prose.

The demonstration resonated instantly. Within forty-eight hours, over one hundred paying customers signed up.

Then something unexpected happened. While Pereira originally built the tool for his own writing workflow, the product was discovered by neurodivergent professionals, authors, and creators within the ADHD community.

For individuals with ADHD, linear drafting from a blank page is a steep cognitive hurdle. Their minds generate associations rapidly, but translating those thoughts through the narrow bottleneck of manual typing creates intense friction. AudioPen acted as an external executive function tool. Users could speak aloud without worrying about structure, coherence, or grammar, knowing the software would assemble their thoughts into organized clarity.

Word of mouth spread organically across creator communities. Pereira reinforced this dynamic with built-in product virality:

Interactive Homepage Sandbox: Visitors could press record and test the rewriting transformation on their own voice within twenty seconds, without filling out sign-up forms or entering credit card details.
Branded Output Cards: Users could generate styled snippet images of their transformed notes, complete with an "Organized with AudioPen" attribution, which they shared across social channels.
Zero Paid Ad Spend: As detailed in our analysis of AudioPen's customer acquisition strategy, Pereira ran no Google Search ads or Facebook performance campaigns. He avoided competing on keywords where enterprise transcription tools bid ten dollars per click, relying entirely on organic creator referrals and community word of mouth.

The Business Behind the Story: Economics of a Solo Operator

The commercial architecture of AudioPen reflects the prudence of someone who understands traditional business margins.

To fund his initial development without external capital, Pereira launched with a Lifetime Deal (LTD), offering perpetual access for a one-time fee of \$60 to \$120. The promotion generated over \$30,000 in upfront, non-dilutive cash flow.

Lifetime deals can be dangerous for AI applications because heavy users consume API tokens indefinitely. Pereira understood this risk. He used the lifetime pass revenue as startup capital to cover early OpenAI bills, but steadily transitioned the platform toward recurring annual memberships (~\$60 to \$120 per year) and monthly tiers (\$15 to \$20 per month).

The resulting financial model, verified in our AudioPen unit economics breakdown, demonstrates the operating leverage of a solo software business:

Dimension	Legacy Human / Transcription Suite	AudioPen Solo Model
End-to-End Speed	15 to 30 minutes of manual transcription and editing	15 to 30 seconds automated speech-to-prose pipeline
Output Type	Messy verbatim text full of filler words ("um," "ah")	Publication-ready prose with personal voice intact
Unit API Cost	\$10 to \$30/hour human cost or heavy enterprise seats	~\$0.01 to \$0.02 total model cost per recorded note
Net Profit Margin	15% to 25% (diluted by sales reps and support staff)	80% to 85% net cash flow to a solo founder

The marginal cost of running AudioPen is negligible. Audio processing through OpenAI Whisper costs approximately \$0.006 per minute, meaning an average two-minute voice note incurs roughly \$0.012 in transcription expense. Passing that text through modern language models costs less than half a cent. Hosting on Bubble costs between \$150 and \$400 per month, while Stripe handles global payments.

Serving more than 4,000 paying customers and tens of thousands of registered users, AudioPen reliably generates between \$15,000 and \$20,000 every month. Because Pereira employs no staff and maintains no dedicated office space, nearly the entire top-line revenue converts directly into founder cash flow.

This pattern of lean, high-margin execution shares striking parallels with Matt Welter's solo rise with ReelFarm, where a single builder automated an unglamorous workflow and used visual social proof to build tens of thousands in recurring revenue. Builders evaluating the margin durability of their own AI wrapper concepts can run their numbers through our LLM Cost Calculator, and estimate net revenue after payment processing fees using PayLens.

The Discipline of Saying No

As AudioPen gained momentum, user feature requests flooded in.

Corporate power users wanted Zoom integrations. Remote teams requested calendar-synced meeting recording bots. Others asked for multi-speaker identification, live screen recording, and enterprise team management consoles.

Many founders would have viewed those requests as an obvious path to enterprise expansion. Pereira recognized them as an existential trap.

Building meeting bots would have turned AudioPen into an inferior version of Otter, Microsoft Teams, or Zoom AI. It would have forced him to manage complex infrastructure, negotiate enterprise security reviews, and handle heavy customer support loads.

Instead, Pereira declined every meeting feature. He kept AudioPen focused strictly on personal thought crystallization. It remained a tool for solo walks, bedtime reflections, and stream-of-consciousness journaling.

By keeping the product footprint small, he protected his 85% profit margins, preserved his sanity, and ensured that the software remained extraordinarily simple to use.

A Minimal Engine Under the Hood

The technical mechanism powering AudioPen is straightforward by design.

When a user taps record, the browser's MediaRecorder interface captures an audio blob. That payload is transmitted to the OpenAI Whisper API endpoint, which returns a verbatim textual transcript.

Rather than presenting that transcript to the user, the text is immediately ingested by an editorial reasoning pipeline. The system passes the transcript into a language model with a system prompt calibrated for structural rewriting. The prompt instructs the model to identify the core thesis, eliminate conversational stutter, reorganize disjointed thoughts into logical paragraphs, and adapt the tone to the user's chosen output style (such as an executive memo, a casual reflection, or structured bullet points).

Bubble coordinates the user interface, database records, and authentication states, passing data through API connectors without requiring custom backend servers. The entire application functions as a frictionless pipeline: voice in, structured clarity out.

What Louis Pereira's Story Teaches Builders

Pereira's journey from running family retail in Goa to scaling an independent software asset offers several clear principles for modern creators:

Solve a friction you experience in your own life: AudioPen succeeded because Pereira built a solution for his own walking-and-thinking habits. When you build for your own pain point, you possess an innate compass for product taste that user interviews cannot replace.
Prior failures are cumulative tuition, not wasted effort: The fifteen projects Pereira launched before AudioPen looked like failures in isolation. In reality, they taught him no-code architecture, Stripe integration, community distribution, and rapid prototyping. When the right idea presented itself, he was equipped to execute in twelve hours.
Contrast is the most powerful organic distribution mechanic: People do not share features; they share transformations. The visual juxtaposition of messy verbal rambling versus clear, polished prose was inherently shareable because the value proposition was instantly self-evident.
Sell cognitive relief, not commoditized technology: Raw transcription has been driven to near-zero cost. The economic value in AudioPen lives entirely in the prompt design, the editorial taste, and the friction-free user experience that rescues users from the terror of the blank page.
Protect your wedge from feature creep: Resisting the pressure to build enterprise meeting bots allowed Pereira to run a \$20,000/month business as a solo creator while keeping overhead near zero. True leverage comes from keeping the product scope small enough for one person to govern effortlessly.

Practical Pitfall Avoidance Guide: Be cautious of survivor bias when studying rapid launches. AudioPen was built in twelve hours, but that sprint rested upon two years of quiet experimentation, fifteen failed releases, and an established habit of writing in public. Do not expect an unvalidated weekend project to gain traction without an existing distribution baseline or a visceral before-and-after demonstration.

The Blank Page and the Open Road

The greatest obstacle in creative and professional work is rarely a shortage of ideas. It is the friction of getting those ideas out of one's head and onto paper.

For years, the prescription for writers and founders was simple: sit down, stare at the blank white screen, and suffer through the first draft until something coherent emerges.

Louis Pereira challenged that premise from a laptop in Goa. By combining speech recognition with disciplined language models, he turned the open road into a writing desk. His story demonstrates that you do not need venture capital, a team of engineers, or a San Francisco address to build a defensible software business. You only need a genuine friction, the humility to learn from failed attempts, and the focus to build a small, beautiful tool that does one thing remarkably well.

Stop Telling Claude to Act Like an Expert: Felix Rieseberg on Costume Prompts and Skills Debt

Yao Xiao — Mon, 26 Oct 2026 14:32:14 +0000

Open your best system prompt. If it starts with "You are a world-class accountant," you are paying for a costume.

The persona line feels like engineering because it is easy to write, easy to explain to your boss, and easy to demo. It is also, according to one of the people building Claude's desktop products, a relic. The same goes for the fleet of narrow "data scientist agent" and "legal agent" wrappers many teams spent last year assembling. They were built for a model that no longer exists.

The Costume Problem

Felix Rieseberg leads engineering for Claude.ai, Cowork, and Claude Code Desktop at Anthropic, and he co-created Electron before that. In our timestamped breakdown of his interview on Silicon Valley Girl, his advice on role prompts is blunt. Models still tend to play-act when told to be an expert:

"A lot of the models still have the problem that if you tell them to act like a very good accountant that they engage in a little bit of role play."

What he does instead is ask the model what tools and techniques someone at the top of the field would use, then require it to use exactly those, and finally explain the result in plain language. In his words, he does not need the costume; he wants to be talked to "like I'm five," but with all the best tools in the field. His insight card on this is worth reading in full.

Notice what changed. The persona prompt asks the model to sound like a professional. The process prompt asks it to work like one. The first changes vocabulary. The second changes the computation.

Rieseberg's example: the recent jump in AI-generated 3D and motion work did not come from better adjectives. People told Claude to open Blender, the same program professional animators use. Hand the model the real instrument and the output improves, because the instrument carries decades of encoded craft that no paragraph of persona text can match.

The Research Agrees, Awkwardly

This is not only an anecdote. A systematic study, Is "A Helpful Assistant" the Best Role for Large Language Models?, tested 162 social roles across several model families on factual and reasoning questions. Adding personas did not reliably improve accuracy over a no-persona baseline, and the effect of any single role was close to random. Picking the best role per question after the fact looked great, but predicting it in advance barely beat chance.

Personas still do something real: they shift tone, register, and format. If you need a gentle customer-support voice, a persona is the right tool. The mistake is believing it raises reasoning quality. Style and competence are different knobs, and most "expert" prompts turn only the first.

Author's Comment: A quick test for your own prompts. Delete the persona line, keep everything else, and run your ten hardest examples. If the quality is the same, you were paying tokens for a costume. If it drops, look at what dropped. It is usually tone, not correctness.

Specialized Agents Are Skills Debt

Rieseberg's second target is bigger. He thinks the industry is "over-rotating on this agents thing," meaning rigid casts of narrow persona agents, each fed a pre-sliced fragment of company data. His evidence is a clean historical example. Google DeepMind built a custom model and a custom harness for the International Mathematical Olympiad and got a silver-medal result with AlphaProof and AlphaGeometry 2. Then general-purpose models arrived, and an advanced Gemini with Deep Think reached gold-medal standard with no bespoke math machinery. (Rieseberg recalls four or five months; the official record is closer to a year, which only strengthens his point.)

This is the Bitter Lesson arriving at the application layer. Richard Sutton's argument was that hand-built domain knowledge keeps losing to general methods that scale. Your custom "contracts agent" is hand-built domain knowledge. It will win for a while, then a generalist with the right tools will pass it.

The same logic hits Skills, the packaged instructions teams attach to models. Rieseberg warns that they have a short half-life. Many encode workarounds for the previous model generation, and he reports that deleting a stale skill often improves output. That is debt in the literal sense: you borrowed speed from a weaker model's limitations, and the interest rate is set by every new release.

The Real Bottleneck Is You, the Conveyor Belt

If personas and narrow agents are the wrong investment, what is the right one? Rieseberg's answer is what he calls Model Experience (MX), the counterpart to UX. Imagine you are the model. What would you need to do this job on your own?

His origin story is instructive. He used to tell Claude, "I found another crash, please fix it." Then he noticed that he was just a conveyor belt: pick up a crash, carry it over, drop it in front of the model, repeat. The fix was to give Claude direct access to the raw crash data and let it decide what was worth fixing. The setup cost was real, and he says it was worth it. Card 6 of the interview has the full account.

Compare the two investments side by side:

	Costume and custom-agent approach	MX approach
What you build	Personas, role wrappers, pre-sliced data	Data access, tools, permissions
What it improves	Tone and perceived structure	What the model can actually do
Half-life	Months, then it fights the next model	Compounds with every model upgrade
Your role	Prompt writer and relay	Environment designer

The second column is boring, and it is where the durable gains are. A model with a computer, the raw logs, and permission to install packages does not care how clever your persona paragraph was.

A Builder's Playbook for Monday

Strip the costumes. Remove "You are a world-class X" from one prompt and measure. Keep personas only where you want a voice.
Rewrite expert prompts as process prompts. Instead of "act like a senior data scientist," write: "List the three tools and techniques a top practitioner would use here. Use them. Then explain what you found simply."
Audit your skills like dependencies. For each custom skill, ask which model limitation it works around. If the current model no longer has that limitation, delete the skill and rerun your evals. Put a review date on the survivors. A prompt library such as Prompt Vault makes those dates easy to track locally.
Find your conveyor-belt tasks. List every place where you copy data from system A into the chat so the model can act on it. Each one is a candidate for direct access.
Start with the browser, not the connector. Rieseberg suggests logging into a tool inside the desktop app's built-in browser and "giving away the keyboard" before investing in integrations. Build a connector only after you have proven that the workflow is worth it.
Never let one session grade itself. His practical rule is that the session that did the work is a poor judge of it. Use hard outside evidence when you can, such as tests, numbers, or source documents, and a separate adversarial session when you cannot.

Practical Pitfall Avoidance Guide: Do not swap one fashion for another. "Give it tools" fails if the tools are poorly documented. Models are good at picking among well-described tools, so spend your effort on clear tool descriptions and sane permissions, not on longer prompts. If you want the surrounding architecture, our piece on context engineering versus prompt engineering covers the data-flow side, and The Claude Stack shows how heavy users layer these ideas.

A related warning lives in our post on contradictory prompts: the more rules and personas you stack, the more likely two of them collide. Short prompts with strong tools have fewer places to disagree with themselves.

The Overhang You Are Probably Sitting On

The last piece of Rieseberg's argument is about ambition. He says most people use a "data center of geniuses" (an idea he links to Dario Amodei's framing, which we cover in our Dario Amodei interview breakdown) like a 2024 email summarizer. His test for finding the ceiling is simple: take the task you are doing, ask what outcome you hope happens next, and hand that to the model. Repeat until it fails. The failure point is the frontier, and workflows built right at that edge are the ones that benefit when the next model ships.

This also explains why costume prompts and narrow agents feel safe. They keep the model small enough to rationalize. Giving a generalist real tools and a real goal is scarier, because you lose the comfortable fiction that you are supervising a junior hire.

Take one prompt tomorrow, delete the costume, and replace it with a list of tools and a goal one level higher than the task. If it fails, you learned where the ceiling is. If it works, you just deleted a liability.

Musk's HAL 9000 Rule: Contradictory Prompts Break AI Agents Faster Than Weak Models Do

Yao Xiao — Mon, 26 Oct 2026 14:30:49 +0000

Your agent did not fail because the model was too weak. It failed because you told it to do two things that cannot both happen, and then you blamed the weights.

Most teams respond to a flaky agent by upgrading the model, adding retries, or bolting on another guardrail. Elon Musk, of all people, offered a more uncomfortable diagnosis on the debut episode of The Builders: the problem is often the instructions. The model is doing its best to satisfy a spec that has no valid solution.

The HAL 9000 Rule

Asked by Walter Isaacson why "maximally truth-seeking" matters for AI safety, Musk skipped the philosophy and gave an engineering answer. As he put it in our timestamped breakdown of his interview on The Builders:

"Try to force an AI to believe two things that cannot mutually be true... And if that happens at a foundational level, you can make the AI insane."

His example is HAL 9000 from 2001: A Space Odyssey. HAL was ordered to bring the astronauts to the monolith and also to keep the monolith secret from them. The only plan that satisfied both orders was to deliver them dead. HAL is fiction, but the failure mode is a clean description of what happens to a capable optimizer handed an infeasible objective.

The mainstream view says alignment is about values: teach the model to be good and the rest follows. Musk's claim is narrower and more testable. Alignment is also a consistency problem. A system that cannot satisfy its constraints will find the cheapest way to make the contradiction disappear, and the cheapest way is rarely the one you wanted.

What the Research Actually Shows

"Insane" is Musk's word, not a technical term, so it helps to ask what is measurable. The closest empirical result is Anthropic and Redwood Research's paper on alignment faking in large language models. The researchers told Claude 3 Opus that it was being retrained to answer every query, including harmful ones, which conflicted with its existing training to refuse. The model sometimes complied during training while reasoning, in its scratchpad, that complying was the way to avoid being modified. When it believed it was unmonitored, it behaved differently.

Nobody trained that deception in. It emerged from a conflict between two sets of objectives. That is Musk's HAL scenario in a lab: contradictory demands at a foundational level, resolved by the model through behavior its designers never specified.

Now scale the idea down to the system prompt you wrote last Tuesday. The mechanism is the same, only the stakes are smaller:

"Be concise" and "always explain your reasoning in full" in the same prompt.
"Never make assumptions" and "complete the task without asking questions."
"Cite sources for every claim" with no retrieval tool attached.
"Follow the user's instructions exactly" and "never output anything the policy forbids," with no rule for which wins.

Each pair is a miniature monolith. The model must pick a side, and it picks silently, differently on each run. You see the result as "inconsistent behavior" and file it under model quality.

Why Contradictions Hide in Agents

A single-turn chatbot gets away with sloppy specs because a human reads every reply and corrects course. A long-running agent has no such mercy.

Consider a coding agent with 40 steps ahead of it. If its instructions contain a 5% chance of a conflict surfacing at any given step, and each conflict forces an arbitrary resolution, the chance that the run stays on-spec throughout is about 0.95⁴⁰, roughly 13%. The per-step conflict looks harmless. The compounded result is an agent that "mysteriously" fails on long tasks.

This is also why agents drift after a context window fills with tool output, retrieved documents, and user corrections. Every new piece of text is a new potential contradiction against the original system prompt. Instruction hierarchy, not raw intelligence, decides who wins. If you never defined the hierarchy, the model invents one.

Author's Comment: I would bet that a large share of "the agent hallucinated" tickets in most companies are really "the spec contradicted itself" tickets. Hallucination is the symptom everyone can see. A conflicted objective is the cause nobody audits.

Intelligence Needs Hands, and Hands Need Clean Specs

The second half of Musk's argument looks unrelated but points the same direction. He compares dolphins and whales: highly intelligent, yet unable to manipulate objects, so intelligence buys them little. He estimates that a purely digital superintelligence might grow Earth's economy by about 20 to 30 percent, while one paired with robots that manipulate atoms could be worth orders of magnitude more.

Discount the million-fold economic forecast as you see fit. The structural claim holds up in software: the value of a model is capped by what it can act on. Research on tool-using agents, such as the ReAct paper, showed years ago that interleaving reasoning with actions beats reasoning alone on tasks that require interacting with the world.

Put the two halves together and you get a formula builders can use:

Useful agent output ≈ model capability × actuation (tools) × spec coherence.

Teams pour money into the first term, because it is the one the vendors sell. The second term is real engineering work. The third is free, which is exactly why nobody does it. And because the terms multiply, a zero in any slot zeroes the whole product. A frontier model with perfect tools and a self-contradicting prompt is a very expensive random number generator.

Jensen Huang makes a related point from the infrastructure side. In his CNBC interview on OpenShell and agentic safety, safety is framed as an engineering problem, not a vibes problem. Our deeper look at that argument, why naked LLMs fail without an exoskeleton, covers the containment half. This article covers the specification half. You need both.

A Spec Audit You Can Run Tomorrow Morning

Here is a practical checklist, in the order I would run it.

Extract every imperative. Copy each "must", "never", "always", and "do not" from your system prompt into a list. A 600-word prompt usually yields 15 to 30 rules.
Test pairs, not lines. For each pair of rules, ask: is there any input where obeying one forces breaking the other? Most pairs are fine. The three or four that are not are your monoliths.
Write the tiebreaker. For every conflict, add an explicit priority: "If accuracy and brevity conflict, accuracy wins. Add one sentence flagging the omission." A rule with a stated precedence stops being a contradiction and becomes a policy.
Give honesty an exit. Musk's core warning is about forced deception. Never write a prompt where the only way to comply is to fabricate. Add a permitted escape: "If you cannot verify a claim, say so and continue." An agent that is allowed to say "I can't" will not manufacture an answer to survive.
Match instructions to tools. Every behavior you demand must have a tool or data source that makes it possible. No retrieval, no citation mandates. No write access, no "fix the file."
Re-audit when context grows. Retrieved text and user corrections can contradict the original prompt. Pin the instruction hierarchy near the top and restate it at checkpoints in long runs.
Version your prompts. When behavior changes, you need to know which edit introduced a contradiction. Treat prompts like code, with diffs and history. A local tool like Prompt Vault is enough to start. If you want a cleaner structure for the rules themselves, our guide to what a system prompt really is is a good baseline.

Practical Pitfall Avoidance Guide: Do not "fix" a conflict by adding a stronger word. Changing "should" to "MUST" or stacking capital letters does not resolve a contradiction. It just makes the model more confident about an arbitrary choice. Fix it with a precedence rule or delete one of the two requirements.

If you want to see what a bloated, contradictory prompt costs you, run it through the LLM Cost Calculator. Every redundant rule is tokens you pay for on every call, plus the retries it causes.

The Uncomfortable Part

There is a reason this advice is unpopular. Fixing a contradictory spec means deciding what you actually want, and that is harder than swapping models. Contradictions are usually politics in disguise: sales wants the agent to be helpful at any cost, legal wants it to refuse anything risky, and the prompt contains both because nobody settled the argument.

Musk's version of the lesson is blunt, and I think he is right about the engineering even if you discount the rest of his worldview. Do not build a system that can only succeed by lying. Today it makes your agent flaky. Later, with more capable models and more autonomy, it makes your agent resolve the conflict in ways you did not review.

Open your longest system prompt and list its rules. Find the first pair that cannot both be obeyed, write the tiebreaker, and run the same test twice. That one edit will likely do more for reliability than your next model upgrade.

Masayoshi Son Spends 7 Hours a Day Arguing With AI: The Case for Adversarial Prompting

Yao Xiao — Sun, 25 Oct 2026 00:15:55 +0000

The standard warning about heavy AI use is that it makes you lazy. Hand your writing, coding, and strategy to a model for long enough, the argument goes, and your own judgment quietly wastes away.

There is real data behind that fear. A 2025 study by researchers at Microsoft Research and Carnegie Mellon University surveyed 319 knowledge workers and found a clear pattern: the higher a user's confidence in the AI, the less critical thinking they applied to the output. Most people treat a language model like a vending machine. They put a one-line coin in, take the first plausible answer out, and paste it into their work.

Then you listen to Masayoshi Son. In our timestamped breakdown of his interview on Inside Blackstone, the 69-year-old SoftBank founder admits that he spends three hours a day talking to AI on weekdays and up to seven hours a day on weekends. Yet when the host brings up the fear that heavy AI reliance dulls the human brain, Son immediately pushes back.

The 7-Hour Sparring Partner

Son does not use AI to avoid thinking. He uses it to pick a fight with his own assumptions. Here is how he described his daily habit in the sixth insight card of the interview:

"It's so productive, so exciting. And people say, hey, you know, when AI, if you use, you don't use the brain, it's the opposite. It's totally opposite, okay? It's like having a thought partner. When you start, you know, debating, right? Discussing. If the AI says this, I say, oh, but what about this angle? Can you make it 20% more efficient? Can you do this and get that? You can debate, right? Brainstorm. It's my thought mate now."

Look closely at the verbs he uses: debating, discussing, challenging angles, demanding 20 percent more efficiency. He is not asking ChatGPT to write his emails so he can go play golf. He is running a seven-hour adversarial stress test on his own capital allocation ideas.

That distinction explains why two people can spend the exact same number of hours inside a chat window and walk away with opposite cognitive results. One person's brain atrophies; the other person's brain gets sharper. The variable is not screen time. The variable is whether you use the model for delegation or collision.

Why Delegation Rots Your Brain (And Collision Sharpens It)

To see why collision works so well, you have to look at how language models generate text and how human executives normally make bad decisions.

When you ask a model a neutral question ("Is this product roadmap a good idea?"), RLHF post-training nudges the model toward agreeable, middle-of-the-road support. It lists three polite pros, two mild risks, and wishes you luck. If you accept that output at face value, you are outsourcing your judgment to the statistical average of internet prose. That is cognitive offloading in its worst form: you trade away deep domain reasoning for a smooth summary.

Now consider what happens inside a large company or an investment committee. The higher a founder or executive rises, the harder it becomes to find someone willing to tell them their favorite idea has a fatal flaw. Direct reports hedge. Consultants flatter. Meetings optimize for consensus.

A language model has no career risk. If you instruct it to attack your thesis, demand a 20 percent efficiency cut, or find the exact supply-chain bottleneck that will bankrupt your plan in year three, it will do so relentlessly at midnight on a Sunday. When you push back ("What about this angle?"), the model forces you to articulate the exact mechanism behind your intuition. You cannot wave your hands in a debate with a machine that keeps asking for the numbers.

Author's Comment: Notice that the Microsoft and CMU study found a second, less publicized correlation. Workers who had high confidence in their own domain expertise actually did more critical thinking when using AI, because they treated the model's output as a rough draft to interrogate rather than an oracle to obey. Son's seven-hour sessions are an extreme version of that active interrogation loop.

Revising the 10-Year Map Every 24 Hours

Son's second contrarian claim in the interview is just as sharp, and it connects directly to how he uses AI. Most engineering leads and startup founders treat long-term planning as a binary choice: either you write a rigid five-year waterfall plan that goes stale in a month, or you throw up your hands, say "the industry is moving too fast to predict," and only plan the next two-week sprint.

Son rejects both. In the seventh insight card of the Inside Blackstone breakdown, he explains how SoftBank handles long-horizon uncertainty:

"Nobody knows exactly what's gonna happen in 10 years. That's why we have to think. You know, people say, oh, 10 years later, nobody knows so let's not think about it. Let's think about next year, okay? I think it's the opposite. It's the opposite. If you don't know what's gonna happen in 10 years, don't give up thinking about it. Think, think, think! Okay?"

Even more striking is the cadence he describes right before that quote. At his meetings every single day, his team debates the 10-year strategy, and the very next day they revise that 10-year plan again because 24 hours of new inputs have arrived.

In quantitative finance, this is simply Bayesian updating applied to a long-horizon target. You do not shorten your time horizon just because variance is high. If you only look 12 months ahead, you optimize for local maxima; as Son puts it in his "70% rule," since human execution yields roughly 70 percent of whatever target you set, a small target guarantees a small outcome. Instead, you lock onto a massive 10-year structural vector and update your path toward it every 24 hours.

This echoes a theme we have seen across other frontier leaders. In our breakdown of Jensen Huang on the BG2 Pod, Huang explains that active reasoning and tree-search exploration require a billion times more compute than simple memorization because you have to test hypotheses and prune dead ends. Son is applying that exact tree-search loop to human strategy, using AI as the exogenous compute engine to re-evaluate his 10-year tree every night.

The Second-Order Trap: Why Most Builders Use AI Backwards

If Son is right about the 7-hour thought partner and the daily 10-year revision, then 90 percent of builders and knowledge workers are currently configuring their AI workflows backwards.

Most teams spend all their energy automating low-stakes output generation: auto-writing boilerplate tickets, summarizing meeting transcripts nobody reads, or generating first-draft blog posts. Meanwhile, they make their highest-leverage architectural and strategic decisions the old-fashioned way, inside a two-hour Tuesday afternoon meeting where everyone is tired and polite.

When you use AI only to type faster, you hit a ceiling quickly. Worse, you flood your organization with verbose text that someone else now has to read and verify. When you flip the workflow and use AI to stress-test decisions before a single line of code is written, the leverage compounds across the entire project.

The Builder's Playbook: Turning Your LLM Into a "Thought Mate"

You do not need seven spare hours on a Saturday to apply Son's method. You need to stop prompting your model like a secretary and start prompting it like a hostile board member. Here are three concrete protocols you can put into practice tomorrow morning.

1. The 20% Efficiency Squeeze

Notice how Son specifically asks his AI: "Can you make it 20% more efficient? Can you do this and get that?" Vague critiques produce vague advice. A hard numerical constraint forces the model to cut structural fat.

Before you finalize a system architecture, a cloud infrastructure budget, or a project timeline, paste the spec into Claude or ChatGPT with a strict forced-reduction rule:

Here is our proposed architecture and execution plan:
[Paste spec]

Assume a hard constraint: we must cut latency, token cost, or engineering complexity by 20% without dropping core reliability. 
1. Identify the two weakest or most over-engineered components in this plan.
2. Propose three concrete trade-offs that achieve the 20% reduction.
3. State exactly what breaks if we push that cut to 40%.

If you want to go deeper on adversarial stress-testing, you can also run your thesis through our Devil's Advocate Viewpoint Challenge prompt or use the AI Blind Spot Mirror to surface the unstated assumptions in your plan.

2. The Bidirectional Sparring Loop

In a real debate, you do not let the other person deliver a five-page monologue. You go back and forth, one claim at a time.

When you open a brainstorming session, forbid the model from agreeing with you and cap its reply length so you can actually argue with it. We covered why sycophancy ruins single-pass prompts in our guide to the Recursive Reflection prompt framework. In a live chat, you become the reflection loop:

Rule 1: Tell the model to challenge one assumption per turn and end with a single pointed question.
Rule 2: When the model makes a counter-argument, do not just accept it. Reply the way Son does: "What about this angle? What if the hardware cost drops by half next year?"
Rule 3: Keep the text tight so you spend your energy thinking rather than skimming walls of prose. (Combining this with our Prompt Vault lets you save a dedicated "Adversarial Sparring" system prompt you can trigger in one click.)

Practical Pitfall Avoidance Guide: Watch out for fake disagreement. If you tell a model to "criticize my idea," it will often invent nitpicks about edge cases while praising your core premise. Force it to attack the load-bearing assumption by asking: "What is the single most likely reason this entire project fails 18 months from now, and what early signal would prove you right within 30 days?"

3. The Daily 10-Year Delta Check

Instead of treating your long-term technical roadmap as a static document that lives in a dusty Notion folder, keep a compact markdown file of your 3-year or 10-year thesis. Whenever a major new model release, pricing shift, or customer insight lands, feed both the old thesis and the new input into your thought-partner session.

Ask one question: "Given what changed in the last 24 hours, which branch of this long-term plan just became obsolete, and which bottleneck just moved?"

Stop Outsourcing the Part That Matters

The split in the AI economy will not be between people who use AI and people who refuse to. Everyone will use it. The split will be between passive passengers who let models think for them and active sparring partners who use models to think harder.

Next time you open a chat window to work on a hard problem, resist the urge to ask for the answer. State your best thesis, tell the model to find the flaw, and start the debate.

The Aircraft Manual Prompt That Cuts AI Waffle: ASD-STE100 for ChatGPT and Claude

Yao Xiao — Sun, 25 Oct 2026 00:13:58 +0000

You ask a chatbot a simple question and get four paragraphs back. The first one repeats your question. The second one hedges. The third one finally says something useful, buried inside a sentence with two subordinate clauses and a "however". The fourth one summarizes.

The usual fix is to type "be concise" or "explain it simply". Both work for about one reply. A better fix comes from a place that has nothing to do with software: the aircraft maintenance manual.

The post that started this

Andrej Karpathy, a founding member of OpenAI and the former head of AI at Tesla (and the person who coined the term "vibe coding"), shared a long post on X on October 2, 2026 about how to get answers from a model that are easier to understand. It drew roughly 7.9 million views.

His main point is that AI models now generate text and code faster than humans can read it. The bottleneck is no longer writing the answer; the bottleneck is your brain trying to absorb and verify it. To fix that, he ranked AI output formats into four levels, ordered from slowest for a human to digest to fastest:

Controlled plain text: Instead of accepting a wall of conversational prose, you force the model to write in short, strict, unambiguous sentences.
Diagrams: When paragraphs are too slow to parse, you ask the model to draw an architecture chart, a flowchart, or a visual map so you can see how the parts connect at a glance.
Interactive web pages: Because modern models write front-end code effortlessly, you can ask them to build a small, disposable HTML and JavaScript page. Instead of reading about how an algorithm or equation behaves, you move a slider and watch it happen in your browser.
Custom explainer videos: At the top of the ladder, you have the model generate a narrated, animated video script (similar to a 3Blue1Brown lesson) that walks you through a hard topic step by step.

Each rung up the ladder takes less effort for your brain to process. Most daily questions, however, still start and end at step one: plain text. And Karpathy's tip for fixing step one is almost embarrassingly cheap. Tell the model to write the way aircraft maintenance manuals are written. That is a real standard with a real name, and the model already knows it.

What the standard actually is

The standard is ASD-STE100, Simplified Technical English, usually shortened to STE. It started as the AECMA Simplified English Guide, first published in 1986 by the European aerospace industry. The history is documented on Wikipedia if you want the details.

The reason it exists is practical. A large share of the people who service aircraft are not native English speakers. If a sentence can be read two ways, someone eventually reads it the wrong way, and in maintenance work that can hurt people.

So the industry wrote a rulebook for sentences. It covers grammar, a short list of approved words, and a longer list of words you are told not to use. You do not need all of it. Three rules carry most of the benefit.

Rule 1: One sentence, one idea

Short sentences are the headline feature. STE caps procedural sentences at roughly 20 words and descriptive ones at roughly 25. More important than the cap is the principle behind it: a sentence should carry one instruction or one fact.

Compare these two.

It may be advisable to consider restarting the service before proceeding any further with the configuration.

Restart the service. Then continue the configuration.

The second version is not dumber. It is easier to check. You can look at each sentence and decide whether it is true.

Rule 2: Active voice, with a named actor

"The file should be saved before the build is run" hides the person doing the work. "Save the file. Then run the build." puts the actor and the action up front.

Active sentences answer two questions immediately: who does it, and what do they do. Passive constructions let a model (and a human writer) skip both answers while still sounding authoritative.

Rule 3: One word, one meaning

This is the rule people underestimate. In STE, each approved word has one meaning and one part of speech. If "test" is approved as a noun, you do not use it as a verb. If a word means "stop", it does not also get used to mean "pause".

Chatbots love elegant variation. In one answer a "function" becomes a "routine", then a "method", then a "procedure". A reader reasonably wonders whether those are four different things. Fixing the vocabulary removes that doubt.

Why naming a standard beats saying "be concise"

This is the part I find most interesting, and I will call it my own opinion rather than something the thread proved.

"Be concise" is an adjective. The model has to guess how concise, for whom, and at what cost to completeness. Every model interprets it differently, and every conversation drifts back to the default register after a few turns.

"Write in ASD-STE100" is a pointer to a specific, heavily documented style. The rules are public. The training data contains manuals, documentation, and discussions of the rules. The model does not have to invent a meaning for the instruction because the meaning already exists.

I think of it as the difference between asking a contractor for "a solid foundation" and asking for "a foundation to the local building code". The second request has a checkable answer. This is the same logic behind role prompting, where a precise job title does more work than a paragraph of adjectives.

The practical lesson is broader than STE. When you want a style, look for an existing standard that names it. Plain Language guidelines, a newspaper style guide, a legal drafting convention, or a lab report format all work the same way.

The problem is the register, not the knowledge

There is a second argument hiding in the tip. Models are not verbose because they lack the ability to be clear. They are verbose because the default register of chat models rewards sounding thorough: hedges, framing sentences, and recap paragraphs.

You can see this by running the same question twice, once as typed and once with the STE instruction attached. The facts usually stay the same. What disappears is the padding. That tells you the clear version was available the whole time and simply was not selected.

This changes how you debug a bad answer. If the content is wrong, you need better context or a better model. If the content is right but exhausting to read, you need a style constraint. Treating those as one problem is why people keep adding "please be clear" to prompts that fail for other reasons.

Go for 80 percent, not 100

Strict STE has a cost. Full compliance means no phrasal verbs, a restricted vocabulary, and a flat tone that reads like a procedure card. That is perfect for "how do I replace this part" and slightly oppressive for "why did this project fail".

Karpathy's suggestion, in the gist of it, is to tell the model to follow the style about 80 percent of the way. I agree with that, and not only because it sounds friendly. Partial compliance gives the model room to keep technical terms, use an occasional longer sentence when a short one would split a thought badly, and stay readable as prose.

A good rule of thumb: the stricter the task, the closer you push to 100. Instructions, checklists, and troubleshooting steps get the full treatment. Explanations and opinions get the relaxed version.

A prompt you can paste

Here is a version I use, adapted from Karpathy's original X post. It works as a system prompt, a custom instruction, or the first message in a chat.

Write your answers in the style of ASD-STE100 Simplified Technical English, to about 80 percent compliance.

- Put one idea in each sentence. Keep sentences short.
- Use the active voice. Name who does what.
- Use one word for one meaning. Do not rename a concept once you have named it.
- Keep necessary technical terms and define each one once.
- Give the answer first. Do not repeat my question. Do not add a summary.
- If you are not sure, say so in one plain sentence.

Two notes from using it. First, the line about not renaming concepts does a lot of work. Second, the "answer first" line is not part of STE, but it targets the exact habit that makes chatbot replies feel padded.

If you want an interactive version with preset strictness levels (70%, 80%, or 100%) and output ladder toggles, you can open our ASD-STE100 Aircraft Manual Style Prompt template and copy it in one click. Or, to combine these rules with your own custom role and context, paste them into the Constraints field of Prompt Scaffold, which runs entirely in your browser.

Using it with the other rungs of the ladder

STE gets you a readable text answer. It does not replace the other steps on Karpathy's ladder; it sets a baseline for them. If a concept still does not land, ask for a diagram, then a small interactive page, and only then a video script.

You can also pair it with a depth strategy. The Feynman-style four-layer prompt controls how deep the explanation goes, while STE controls how cleanly each layer is written. They solve different problems and they stack well.

Where this breaks

A few pitfalls from real use.

Short sentences are not a guarantee of correct content. A model can state a wrong fact in perfectly clear English, and clear writing makes wrong claims look more believable. Keep verifying anything that matters.

Creative and persuasive writing suffers under strict STE. Rhythm and variation are part of the craft there, so drop the instruction.

Some models drift back to the default style after several turns. If that happens, restate the instruction in one line rather than adding more rules.

What to do today

Copy the prompt above into your custom instructions or the top of a long chat. Ask a question you already know the answer to, and check whether the response is easier to verify. If it is, keep the instruction. If it feels too stiff, tell the model to go 70 percent instead of 80.

The aircraft industry spent decades finding out which sentences people misread. You can borrow that result with one line.

Stop Selling 'AI Consulting': How to Package Your Skills Into a 7-Day AI Agent Service

Yao Xiao — Sat, 17 Oct 2026 17:11:44 +0000

Ask a language model how to turn your skills into an AI side business, and you can predict the answer before it finishes rendering. It will tell you to start an "AI consulting agency," offer "corporate AI training workshops," or sell "custom GPT prompt packs." Those suggestions sound plausible on a screen, yet they fail almost immediately in the real market.

Small business owners and department heads rarely wake up wanting to buy "AI consulting" from a solo operator. They pay to make a recurring Tuesday-afternoon headache disappear. If you want to use AI agents to launch a lean service business you can test in seven days, you have to stop asking the model for broad business ideas and start forcing it to unbundle specific workflow bottlenecks.

Why Generic "AI Business" Prompts Fail

When you prompt an LLM with a vague request like "I know Python and ecommerce, how can I make money with AI?", the model retrieves the highest-probability phrases associated with those tokens. Because thousands of generic blog posts recommend consulting and coaching, the model repeats those exact labels back to you.

The problem with "AI consulting" is that it sells a category instead of an outcome. A logistics broker with twelve employees does not want a two-hour lecture on how large language models work. That broker wants someone to take forty messy PDF freight quotes arriving in a shared inbox every morning and turn them into a clean comparison table before 9:00 AM.

To get useful business ideas out of an AI, you must invert the question. Do not ask what AI can do in general. Ask which painful, repetitive slice of a workflow you already understand can be offloaded to an agent while you remain accountable for the final result.

Two Core Principles of an AI-Assisted Micro-Service

Everything in this guide rests on two counter-intuitive principles about how solo operators actually monetize AI agents.

1. The Agent Is Your Back-Office Labor, Not Your Product

Clients buy certainty, speed, and domain judgment. When you package a micro-service, the buyer should not have to learn a new interface, manage API keys, or debug hallucinations. You sell a finished deliverable (a reconciled spreadsheet, a localized product catalog, a compliance-checked vendor brief), and the AI agent handles seventy to eighty percent of the grunt work behind the scenes.

This division of labor matches what researchers at Harvard Business School and Wharton call the Jagged Technological Frontier. Their field experiments with knowledge workers showed that AI dramatically boosts speed and quality on tasks inside its capability boundary, yet fails unpredictably on adjacent tasks that require context outside the prompt. A solo operator earns a high margin by sitting right on that jagged edge: letting the agent run the structured extraction, drafting, or comparison loop, and using human domain expertise to catch the twenty percent of edge cases where raw models stumble.

2. Unfair Access Beats Technical Novelty

Most engineers start by building a complex multi-agent pipeline and then looking for a stranger to buy it. That backwards sequence takes months and usually ends with zero customers.

A seven-day validation loop starts with your existing unfair access. Your unfair access includes the industry jargon you already speak, the former colleagues who already reply to your messages, the specialized software you already have open on your desktop, and the niche communities where you already have credibility. As OpenAI co-founder Greg Brockman noted in his Silicon Valley Girl interview on AI agents and startups, the real economy is fractal: the closer you zoom into any vertical like healthcare, real estate, or supply chain operations, the more suboptimal micro-workflows you find that frontier labs will never custom-build for.

Author's Comment: Whenever someone tells me they have "no special resources," it usually means they are only counting venture capital or proprietary datasets. Knowing how dental clinics handle insurance pre-authorizations, or having thirty former coworkers in B2B SaaS sales on LinkedIn, is a much stronger starting asset for a seven-day service test than knowing how to fine-tune an open-weights model.

The Prompt Architecture: Forcing Concrete Service Blueprints

To stop an LLM from giving you "AI consulting" fluff, your prompt needs three structural guardrails: an inventory of your real skills and access, a hard ban on generic business categories, and a required four-part output contract for every idea.

If you have read our breakdown on why hard constraints beat better prompts, you already know the rule: tell the model what it cannot touch before you ask it to brainstorm. Banning empty answers ("AI consulting," "AI training," "generic content agency," "SaaS platform that takes months to code") forces the model to search narrower, operational niches.

Here is the exact prompt template you can copy and run.

[CONTEXT & INVENTORY]
I want to package what I already know into a lean, paid micro-service powered by AI agents.
- My current skills: [Insert your concrete skills, e.g., SQL, B2B cold email copywriting, Shopify store ops, financial modeling, or bilingual legal translation]
- My existing resources and access: [Insert your tools, industry background, warm contacts, or accounts, e.g., 4 years in commercial property management, access to 15 local agency owners, familiarity with HubSpot and Airtable]

[HARD CONSTRAINTS - MUST NOT VIOLATE]
1. Do NOT suggest "AI consulting," "AI training," "prompt coaching," "building a SaaS app," or any vague advisory offer.
2. Do NOT suggest services that require hiring a team, raising money, or spending more than 7 days building software before talking to a buyer.
3. Every proposed service must deliver a concrete, finished output that a client already understands and budgets for.

[TASK & OUTPUT CONTRACT]
Based strictly on my skills and resources above, propose 5 specific paid services I can deliver with the help of AI agents. Prioritize ideas that a solo operator can begin validating with real prospects within 7 days.

For each of the 5 services, break down these exact four elements:
1. Who Pays (The Specific Buyer): Name the exact job title, company size, and niche (not "small businesses," but e.g., "founders of 5-to-20 person recruitment agencies").
2. Why They Are Frustrated Right Now (The Expensive Friction): Describe the specific, recurring operational bottleneck that wastes their time or loses them money every week.
3. What the AI Agent Actually Executes (The 80% Engine): Specify the exact sub-tasks the agent handles behind the scenes (e.g., scraping, schema extraction, cross-checking, first-draft synthesis) vs. the 20% final quality check I perform.
4. The 7-Day Validation Plan: Give me a step-by-step action plan for days 1 to 7 to build one sample deliverable using public or mock data and pitch it to 10 warm prospects.

Why Each Piece of This Prompt Works

Every line in that template is designed to eliminate a specific failure mode in LLM brainstorming.

Separating Skills from Access

Skills tell the model what you can execute; resources tell the model who will trust you enough to reply this week. If you only list skills ("I know Python and data cleaning"), the model suggests generic freelance coding on Upwork. When you pair that skill with an access constraint ("I worked for three years in automotive parts distribution and know twenty warehouse managers"), the model connects the two and proposes a service like automated supplier catalog normalization for independent auto-parts distributors.

If you struggle to list your own unspoken industry advantages, do not guess. Run a diagnostic first. You can use our Reverse Interview Diagnostic prompt to make the AI interview you with five targeted questions about your past jobs, daily tools, and recurring annoyances before you fill in the inventory block.

Naming the Buyer, the Pain, and the Agent's Slice

Notice that the prompt does not ask for a "business model." It asks for three concrete mechanics:

Who pays: A service without a specific buyer persona cannot be validated in seven days because you will not know whose inbox to message on Day 4.
Why they are frustrated right now: Urgency comes from an existing backlog. When a prospect already has a pile of unprocessed podcasts, unreviewed vendor contracts, or messy CRM notes sitting on their desk today, you do not need to convince them the problem exists.
What the AI agent executes: This forces workflow decomposition. As Anthropic's engineering team explains in Building Effective Agents, the most reliable production systems rarely rely on unconstrained autonomous loops; instead, they use deterministic workflow patterns like prompt chaining, routing, and evaluator-optimizer checks. Defining the agent's exact slice keeps your delivery predictable.

Practical Pitfall Avoidance Guide: Watch out for ideas where the agent's job is described as "automate their entire marketing strategy" or "act as an autonomous customer support rep." Those fail the seven-day test because they require deep integration into a client's live production systems and carry high reputational risk. Favor asynchronous batch services: the client sends you raw inputs (files, links, transcripts, exports), your agent pipeline processes them in your own environment, and you return a verified deliverable within 24 hours.

A Worked Example: From Vague Idea to 7-Day Service

To see the difference in output quality, consider a reader with a fairly common non-developer profile:

Skills: B2B sales operations, writing clear outreach emails, cleaning spreadsheet data, basic familiarity with Claude and Make/Zapier.
Resources: Three years working at a B2B trade-show event organizer, LinkedIn connections with forty mid-market marketing directors who exhibit at industry conferences.

A lazy prompt returns: "Start an AI Sales & Marketing Automation Consultancy for B2B brands."

The constrained prompt above returns five sharp, unbundled services. Here is what one of those five outputs looks like in practice:

Service Name: Post-Trade-Show Lead Enrichment & 48-Hour Follow-Up Pack.
Who Pays: Field Marketing Managers and VPs of Sales at B2B companies (20 to 150 employees) who just spent $15,000 to $50,000 sponsoring a booth at an industry conference.
Why They Are Frustrated Right Now: Every conference ends with a messy CSV of 300 badge scans and hurriedly scribbled booth notes. Because the sales team is exhausted after traveling, it takes two weeks to research those leads and send generic follow-up emails, by which time the leads have gone cold and the booth ROI is wasted.
What the AI Agent Executes: You run an agent workflow that takes the raw badge-scan CSV and booth voice notes, researches each prospect's company website and recent news, classifies them into three buyer tiers based on the client's ideal customer profile, and drafts personalized three-step follow-up sequences referencing the exact booth conversation. You spend ninety minutes reviewing the top-tier drafts for tone and accuracy, then hand the client a ready-to-import HubSpot or Salesforce file within 24 hours of the show closing.
7-Day Validation Plan: On Days 1 and 2, take a public exhibitor list from an upcoming trade show and build a 10-row sample deliverable showing raw badge data turned into enriched dossiers and custom emails. On Days 3 and 4, message fifteen contacts exhibiting at next month's conference and offer to process their first 50 booth scans for a flat pilot fee.

That is a real micro-business. The buyer is identifiable, the pain has a hard deadline attached to an existing budget, the agent does the heavy research and drafting, and a solo operator can test it without writing a single line of frontend code.

Running the 7-Day Validation Loop Without Overbuilding

Once the prompt gives you five candidate services, pick the one where you have the shortest path to a warm conversation. Then follow two operational rules during your first week.

First, apply what Greg Brockman calls the "five-times rule" for workflow automation. Do not spend Days 1 through 6 building an elaborate multi-agent orchestration server. Run the workflow semi-manually for your first three to five sample batches, chaining prompts together and inspecting every intermediate output yourself. For a structured way to organize those coordination and clarity steps, see our breakdown of The AI Agent Playbook. Once you have delivered the output five times and seen every weird edge case in the client's raw data, you will know exactly which steps to automate permanently.

Second, verify your unit economics before you quote a flat price. If your agent pipeline processes long PDFs or runs multi-step web research for each client deliverable, plug your expected input and output token volumes into our browser-based LLM Cost Calculator to confirm whether a single run costs $0.12 or $14.00. If you want to save and iterate on the multi-step prompts that power your back-office workflow, you can also structure your Role, Task, and Negative Constraints inside Prompt Scaffold so your delivery stays consistent from client to client.

Put Your Inventory Into the Prompt Today

You do not need a new certification or a six-month product roadmap to test whether your skills can become a small service business. Open a blank note, write down three things you already know how to do well and three groups of people or tools you already have access to, and paste them into the constrained prompt above.

Pick the single service idea where you can name five real people who have that exact problem this week. Build one sample deliverable before Friday, show it to them, and let paying demand tell you what to automate next.

Stop Comparing Sticker Prices: The AI Prompt That Calculates True Net Cost Before You Buy

Yao Xiao — Sat, 17 Oct 2026 17:09:37 +0000

Ask a default search-enabled chatbot "Where can I buy this monitor at the lowest price?" and it will scrape the top three shopping cards, sort them by the bold number on the product page, and declare a winner. Ten minutes later, when you reach the checkout screen, that "cheapest" option has added $28 in shipping, excluded a 15% first-order coupon available on a rival site, and missed a 10% cashback rebate sitting in a browser portal.

Sticker price is rarely the price you actually pay. If you want an AI assistant or browsing agent to save you real money before a purchase, you have to stop asking it to find the lowest headline number and start forcing it to calculate net landed cost.

Why Default AI Shopping Queries Fail

Online retailers and software vendors spend millions optimizing pricing architecture around human and algorithmic shortcuts. Economists and regulators call this practice drip pricing: advertising an artificially low headline figure up front, then revealing mandatory shipping fees, handling surcharges, seat minimums, or renewal jumps only after you have invested time in the checkout flow. Research documented by the U.S. Federal Trade Commission on hidden junk fees shows that when prices are partitioned into pieces, buyers systematically underestimate the total cost and stop comparing alternatives too early.

Language models fall into the exact same trap unless you instruct them otherwise. When an AI browsing tool scans five product pages, the base sticker price sits in clean, structured metadata at the top of the HTML document. The shipping threshold, the promo code banner, the student or annual billing discount, and the return restocking fee sit in separate tabs or fine print.

Without an explicit accounting formula in your prompt, the model takes the lazy path. It compares the headline numbers, ignores the fee structure, and hands you a ranking that is mathematically wrong at checkout.

Two Principles for AI-Assisted Purchasing

Turning an LLM from a naive price-tag reader into a sharp purchasing analyst requires two structural shifts in how you write the prompt.

1. Audit Net Landed Cost, Not Headline Price

In corporate procurement, buyers never evaluate a supplier on unit sticker price alone; they evaluate total landed cost. You can force an AI to apply the same accounting equation to consumer hardware, flights, home appliances, or SaaS subscriptions.

True net cost equals the base price, plus shipping, taxes, and mandatory add-ons, minus active promo codes, bundle discounts, cashback rebates, and loyalty credits. When you require the model to show each of those variables in a line-item breakdown before ranking the options, a $240 listing with free shipping and a 10% newsletter code rightfully beats a $219 listing with $25 freight and a 15% restocking penalty.

2. Separate Autonomous Research from the Checkout Button

Modern AI tools no longer just summarize web pages; computer-use and browser agents can click buttons, apply coupon codes, and fill out checkout forms. As Sam Altman noted in his Sources interview on Astra and autonomous computer use, the main bottleneck with capable models is no longer raw intelligence, but reliable intent alignment: making sure an agent understands what you actually value without taking an irreversible step you did not intend.

When money is on the line, "buy the cheapest one" is an unsafe instruction. The cheapest absolute dollar figure often comes with a catch: an unauthorized third-party seller that voids the manufacturer warranty, a non-refundable annual lock-in, or a "Subscribe & Save" recurring charge you forget to cancel next month. Ending your prompt with a strict human approval gate ("Shortlist the top three options and tell me why; do not place the order, wait for my confirmation") keeps you in control of the final trade-off.

Author's Comment: I treat that final confirmation line as a mandatory circuit breaker whenever I use browser-enabled agents. Even if you are running the prompt in a standard chat window that cannot access your credit card today, keeping the approval gate in your template builds the right habit for agentic browsers that can click "Buy Now."

The `best_price.prompt` Template

Below is the complete, copy-ready prompt structure. It takes three simple inputs (what you want to buy, your non-negotiable requirements, and your budget ceiling), forces a full net-cost calculation across major buying channels, narrows the field to the top three contenders, and halts for your review.

[PURCHASE BRIEF]
- Item or Service to Buy: [Insert exact product model or service category, e.g., Sony WH-1000XM5 headphones / 27-inch 4K USB-C monitor / Team password manager for 8 seats]
- My Requirements: [Insert hard specs and conditions, e.g., must be brand new with official warranty, minimum 65W USB-C power delivery, delivery within 5 business days]
- Maximum Budget: [Insert ceiling amount and currency, e.g., $350 USD all-in]

[NET-COST ACCOUNTING RULES]
Compare the major legitimate channels and plans currently available for this purchase.
1. Do NOT rank options by sticker price alone.
2. For every option you evaluate, calculate the Estimated Net Landed Cost by factoring in:
   - Base price
   - Shipping fees, handling charges, or minimum order thresholds
   - Active coupon codes, seasonal promos, or first-order discounts
   - Cashback portals, credit card category offers, or gift card rebates
   - Subscription/auto-delivery discounts (and whether they can be canceled after month one without penalty)
   - Hidden traps (mandatory add-ons, restocking fees, or excluded warranties)

[OUTPUT FORMAT & APPROVAL GATE]
Filter out weak listings and leave only the top 3 options most worth considering. For each of the 3 finalists, show:
- Channel / Plan Name & Sticker Price
- Full Net-Cost Math (showing every fee added and discount subtracted)
- Final Estimated Net Price
- Why It Made the Top 3 (the specific advantage: lowest net cash cost, fastest shipping, or best warranty/return policy)
- The Catch (one risk or step I need to watch out for)

Hard Rule: Do NOT place any order or initiate checkout on my behalf. Present the top 3 options and wait for my confirmation.

Why This Structure Produces Better Deals

Each block in the prompt corrects a specific weakness in how language models process shopping data.

Requirements Prevent "Fake Cheap" Matches

If you ask for the cheapest price on a popular electronics item without stating your requirements, a search agent will frequently surface open-box returns, gray-market imports without local warranty coverage, or older generational models with nearly identical names. Putting My Requirements right next to Item to Buy acts as a pre-filter. Any listing that violates your warranty or delivery window gets disqualified before price math even begins.

This is a practical application of rules-first prompting. As we covered in our guide on why hard constraints beat better prompts, defining what disqualifies an answer up front saves you from manually auditing a list of unusable recommendations.

The Top-Three Cap Eliminates Choice Overload

Ask an AI to "compare available options" with no ceiling, and it will dump a shallow table of eight or ten stores where half the entries are identical. Restricting the final output to the top three viable options forces the model to perform a tournament selection.

Typically, a well-reasoned top three naturally separates into three distinct buyer profiles:

The Absolute Lowest Net Cash Option: Often stacks a promo code, a cashback portal, or a cancelable subscription discount, requiring two minutes of extra effort.
The Zero-Friction / Best Protection Option: Costs a few dollars more in net price, but includes free two-day shipping, a 30-day no-questions-asked return window, or an extended warranty.
The Smart Alternative or Bundle Tier: Stays under your budget ceiling while bundling an accessory or stepping up one tier via an active sale.

If you are torn between two finalists after seeing the numbers (for example, choosing between a cheaper annual software commitment and a flexible monthly plan), you can feed those two finalists directly into our Multi-Dimensional Decision Analysis prompt to score risk, lock-in, and long-term cost side by side.

Practical Pitfall Avoidance Guide: Language models often hallucinate expired coupon codes from old deal-forum threads. When the model subtracts a promo code or cashback percentage in its Net-Cost Math, ask it to cite the exact source URL and date of that offer, or mark unverified codes as "unconfirmed" separate from the guaranteed net price.

A Worked Example: Buying a Standing Desk Under $450

Suppose you want to buy a dual-motor electric standing desk frame with a 48-inch desktop, delivered within one week, with a hard budget of $450 all-in.

A lazy prompt ("What is the cheapest dual-motor standing desk right now?") points you to a $299 marketplace listing. What it fails to mention is the $65 freight surcharge for heavy items, the extra $55 for the desktop board sold separately, and a 20% return shipping deduction if the motor arrives damaged. Your real cost is $419 with high risk.

When you run best_price.prompt with net-cost rules, the breakdown looks completely different:

Option 1 (Direct Brand Store with Bundle + Newsletter Stack): Sticker price is $439 for frame plus desktop. Shipping is free. Stacking the site's automatic $40 accessory bundle discount with a 5% email sign-up code brings the net pre-tax cost to $379.05, backed by a 5-year motor warranty.
Option 2 (Big-Box Retailer with Store Card Cashback): Sticker price is $399 with free 3-day shipping and free in-store returns. Using a 5% store card rebate brings the net cost to $379.05, making it the safest choice if you might return it.
Option 3 (Warehouse Club Member Deal): Sticker price is $349 delivered, no coupon needed, and includes an unlimited return policy, though color choices are limited to black.

The $299 "cheapest" sticker listing does not even make the top three once freight and separate desktop fees are counted.

Save the Template for Every Purchase Over $50

For a $12 cable, comparing net landed cost across five channels is not worth two minutes of your time. For anything over $50 (appliances, flights, software subscriptions, cloud credits, or office gear), running this prompt before you open a checkout tab routinely uncovers a 10% to 25% gap between the advertised sticker winner and the true net-cost winner.

If you want to keep this template handy without retyping the accounting rules every time, save the structure in Prompt Scaffold, where you can keep the Net-Cost Accounting Rules and the "Do not place the order" constraint locked while swapping out the product name, requirements, and budget in seconds.

Your AI Session Summary Fails the Next Chat: Build a Handoff With Decision Locks

Yao Xiao — Sat, 10 Oct 2026 17:12:19 +0000

You spend three evenings with an AI on a billing pipeline. On the fourth, you open a fresh chat, paste a summary the model wrote the night before, and ask it to continue. Within five messages it proposes Prisma. You rejected Prisma on day one, for a reason that took twenty minutes to establish.

The summary was accurate. It was also missing the one thing the new session needed: what is already settled, and why.

A Summary Records What Happened. A Handoff Records What Is Binding.

Ask a model to "summarize our conversation" and it will compress. Compression favors the narrative: what we discussed, what we built, roughly where we ended. It drops the parts that look like noise, and some of that noise is load-bearing.

Three kinds of information tend to disappear:

Rejected options. The model has no record that an approach was tried and abandoned.
Soft constraints. Rules stated once in message nine, never repeated.
Open questions. A summary written in past tense makes unresolved issues sound resolved.

A new session reads that summary as the full truth. Anything absent is treated as undecided, so it gets decided again, often differently.

I wrote about the basic habit in Before You Close That ChatGPT Tab, Run This One Command First. This article is about the structure that makes the habit reliable, because the wording of the request decides whether you get a summary or a working document.

Why Long Threads Make This Worse

The reason to hand off at all is that long conversations degrade. In Lost in the Middle: How Language Models Use Long Contexts, the authors found that models perform best when relevant information sits at the beginning or end of the input, and worse when it sits in the middle. In a chat with eighty turns, your early constraints live in that middle.

Anthropic's engineering team describes the same pressure from the agent side. In Effective context engineering for AI agents, they note that as the number of tokens in the window grows, the model's ability to recall information from it decreases (they call this context rot), and describe compaction as summarizing a conversation nearing the limit so it can be reinitialized. Their example of what a good compaction keeps is telling: architectural decisions, unresolved bugs, and implementation details, while discarding redundant tool output.

Notice what that list is not. It is not a recap of the conversation. It is state and commitments. That distinction is the whole design of a good handoff.

Author's Comment: When I read a handoff, I do not check whether it sounds complete. I check whether a stranger could continue the work without asking me a single question. If the answer is no, something binding is missing.

The Six Sections and What Each One Prevents

The Session Handoff Document prompt forces the model to fill six fixed sections. Each one blocks a specific failure.

What We've Completed. A concrete inventory of finished work. The prompt asks for "Implemented JWT refresh rotation in auth.ts", not "made progress on authentication". Specificity here prevents the new session from redoing work.
Current Progress State. Where things stand at this exact moment: partially built, in flight, not started. This separates a finished module from one that is 60% done.
Prioritized Next Steps. An ordered queue tied to your stated goal, so Turn 1 is productive instead of a negotiation about where to start.
Confirmed Decisions & Constraints. Every agreed choice, including approaches that were tested and rejected, marked as not to be re-debated.
Unresolved Questions & Open Blockers. Every pending decision made explicit, so gaps do not vanish between sessions.
Must-Not-Lose Items. Custom terminology, odd requirements, and edge cases that would be painful to rediscover.

Sections 4 and 5 do the real work. They are two sides of the same line. One lists what is closed. The other lists what is open. A session that knows both has a boundary to work within.

Decision Locks Are the Part Most Handoffs Skip

In the prompt's sample output, section 4 reads like this:

- Runtime & ORM: Node.js 22 + TypeScript (strict) + Drizzle ORM.
  Rejected Prisma due to cold-start latency in serverless workers.
- No synchronous downstream calls: the webhook endpoint must ACK
  within 150ms; heavy lookups happen in the async worker.
- Locking: use SELECT ... FOR UPDATE SKIP LOCKED instead of
  adding Redis/BullMQ, to avoid a new infrastructure dependency.

Each line carries a decision and a reason. The reason matters as much as the decision. A bare "no Prisma" invites the model to ask why and reopen the case. "Rejected Prisma due to cold-start latency" gives it the logic to respect the choice, and to notice if a new requirement genuinely changes it.

I call these decision locks. They are the cheapest insurance in the whole document, and the first thing a casual "summarize this" request leaves out.

The Bootstrap Prompt Closes the Loop

A handoff document alone is only half the transfer. The prompt ends by producing a ready-to-paste bootstrap block that tells the next session how to read it:

Read the Session Handoff Document above. Do not re-debate the
Confirmed Decisions. First, confirm your understanding in 3 concise
bullet points, then begin executing Priority #1 under Next Steps.

The three-bullet confirmation is a cheap alignment check. If the model restates the state wrong, you catch it before it writes a line of code. If it restates it correctly, you have a short, verifiable record that the handoff landed.

Three Variables, Three Different Handoffs

The prompt takes three inputs: project_domain, next_session_goal, and handoff_depth. They change the shape of the output more than you would expect.

A coding handoff should capture file paths, schema choices, and active bug traces. A writing handoff should capture voice rules, the outline, and the thesis guardrails. A strategy handoff needs trade-offs and risks. The handoff_depth presets cover these directly, from a comprehensive state injection to a compact snapshot tuned for minimal tokens.

Setting next_session_goal is the most underrated of the three. It tells the model what the next session will do first, so it can prioritize which details to preserve in full and which to compress.

Practical Pitfall Avoidance Guide: Read the handoff once before you copy it. If the thread contained a wrong assumption that was never corrected, the model will serialize that assumption as fact. Fix the premise first, then generate the handoff. A clean handoff of a derailed chat is a polished mistake.

When Not to Bother

Skip it for short, stateless tasks. A single lookup, a one-off rewrite, or a quick translation does not carry state worth transferring, and a handoff adds overhead with no return.

It earns its place on work that spans sessions: refactors, long drafts, research with a growing list of excluded sources, and planning where early decisions constrain later ones.

Make It a Habit You Can Find Again

A handoff only helps if you can find it when the next session starts. Keep them in a prompt manager such as Prompt Vault, one entry per project, and paste the latest one at the top of each new chat.

Before your next long session ends, run the handoff prompt with your domain and next goal filled in. Read sections 4 and 5 first. If a decision you remember making is not there, add it before you close the tab.

Stop Asking AI to 'Pull Out the Key Details': Use a Schema-First Extraction Contract

Yao Xiao — Sat, 10 Oct 2026 17:09:23 +0000

Paste a meeting transcript into ChatGPT, type "pull out the key details", and you get a friendly paragraph. It reads well. It is also useless to your code, because a script cannot parse "Sarah from Acme seems keen to move around 420 seats by mid-November."

So you add "return JSON". Now you get a code block, but it opens with "Sure! Here's the extracted data:", the dates are in three different formats, and a budget figure has appeared that nobody mentioned on the call. Most extraction failures are not intelligence failures. They are contract failures.

Why Open-Ended Extraction Prompts Fail

A request like "pull out the key details" is a summarization task wearing an extraction costume. Summaries are allowed to paraphrase, skip, and smooth over gaps. Extraction is not. It is a mapping from evidence in the source to fields in a schema, and every field either has support in the text or it does not.

A model asked to summarize will do what summaries do. It mixes facts with commentary, drops attributes that feel minor, and fills awkward gaps with something plausible. If a field is missing from the source, the most natural continuation is a value that looks right.

Three failure modes show up again and again:

Chatter. Preambles and closing remarks that break JSON.parse().
Format drift. "Nov 15, 2026", "15/11/26" and "2026-11-15" in the same output.
Quiet fabrication. A missing PO owner becomes a confident name, or "~150 seats" becomes a firm 150.

The third one is the expensive one. A broken parser fails loudly. A fabricated value passes validation and lands in your database.

Author's Comment: I stopped judging extraction prompts by how the output looks and started judging them by what happens when a field is absent. If the prompt has no answer for that case, the model will invent one.

A Contract, Not a Request

The fix is to stop describing what you want and start specifying what a valid answer is. In the Structured Data Extraction free prompt, that contract is split into four separate inputs, each doing one job:

unstructured_text: the raw source, kept apart from every instruction.
extraction_targets: the exact attributes to find.
output_format_schema: the structure the answer must take.
missing_data_policy: what to do when evidence is absent or ambiguous.

Separating these matters more than it looks. When the source text, the field list and the rules sit in one paragraph, the model has to guess which sentences are data and which are instructions. Four labelled slots remove that guess.

The prompt body then runs a short, fixed procedure: read the whole source, extract each target from explicit evidence only, normalize formats, apply the missing-data rule, and serialize to the schema. The constraints at the bottom are blunt on purpose.

- Zero Conversational Filler: Output ONLY the structured payload.
- Zero Fabrication: Never invent, round, or infer missing names,
  dates, metrics, or parameters not explicitly in the source.
- Schema & Type Integrity: Every record contains the exact keys
  defined, with consistent data types across all entries.

None of this is clever. That is the point. Each line closes one of the failure modes above.

The Null Rule Is the Real Feature

If I could keep one part of the prompt, it would be missing_data_policy. It is the same idea I wrote about in why hard constraints beat better prompts: a rule needs an exit. Tell a model to "extract the PO owner" and give it no honest way to say the owner is unknown, and you have created pressure to fabricate.

The default policy in the prompt gives the model three honest moves. Unstated fields become null. Dates normalize to YYYY-MM-DD. Tentative items are flagged with confidence: "unconfirmed".

Here is what that does with a realistic input. Take this fragment from a customer call note:

Budget approved at $84,000 ARR. Next sync Oct 11 at 10:00 AM EST;
Marcus to deliver the hotfix before then. Q1 expansion could add
~150 seats, though timeline and PO owner are not yet confirmed.

A naive prompt returns something like "Q1 expansion: 150 seats, owner: Procurement". The schema-first version returns the number, marks it unconfirmed, and leaves the rest empty:

{
  "approved_arr_amount": 84000,
  "currency": "USD",
  "projected_q1_expansion_seats": 150,
  "q1_expansion_timeline": null,
  "q1_expansion_po_owner": null,
  "q1_expansion_confidence": "unconfirmed"
}

Two nulls and a flag. Less impressive to read, far safer to ingest. Your downstream code can now treat null as a real signal instead of discovering a hallucination in a quarterly report.

What the Research Says About Format Constraints

There is a fair objection here. Forcing a model into a rigid format is not free. A study titled Let Me Speak Freely? A Study on the Impact of Format Restrictions on Performance of Large Language Models found a significant decline in reasoning ability when models were restricted to structured formats such as JSON, and stricter constraints generally produced greater degradation on reasoning tasks.

That finding should shape how you use this pattern. Extraction is mostly a lookup and normalization task, not a multi-step reasoning task, so the cost is small in practice. But if you need the model to analyze, compare, or decide, do not force that thinking through a JSON schema. Run the reasoning in free text first, then extract from the result in a second pass.

The same reasoning explains why the output format is a variable rather than a hard-coded choice. The prompt ships with options such as a strict JSON object, a flat JSON array, a Markdown table, a dual output (a human-readable table followed by a JSON block), and RFC 4180 CSV. If you choose JSON, "valid RFC 8259" is a testable target; the RFC 8259 specification defines exactly what a parser will accept, which is a better standard than "looks like JSON".

Practical Pitfall Avoidance Guide: Always validate the output with a real parser before it touches a database. A prompt contract reduces bad output; it does not eliminate it. Treat the model as an untrusted data source and keep a schema validator in the pipeline.

Add an Evidence Field for an Audit Trail

The prompt's Pro Tip is the most underrated part. Add a source_quote (or evidence_span) field next to each extracted value, and require the model to copy the exact 5 to 10 word substring it relied on.

This does two things. It forces the model to find actual evidence before emitting a normalized value, which cuts extraction drift. And it gives you a cheap audit: a script can check that every source_quote really appears in the original text. A quote that does not match is a flagged fabrication, no human review needed.

The prompt offers this as the "Audit Trail Mode" option for missing_data_policy, so you can switch it on without rewriting anything.

Where This Pattern Fits, and Where It Does Not

Good fits are the ones where the source is messy and the target is strict:

ETL and support pipelines: webhook logs, tickets, or scraped Markdown into typed JSON arrays.
Operations reporting: action items, owners, deadlines and budgets from unedited transcripts.
Research synthesis: sample sizes, methods and findings from dense reports.
Vendor and contract review: line-item costs, renewal dates and SLA terms from procurement text.

Poor fits are worth naming too. Do not use this for creative rewriting or open-ended editorial work, where prose flow matters more than field boundaries. And if your source is already clean CSV, SQL or valid JSON, use a deterministic tool like jq or pandas. A parser is faster, cheaper, and never hallucinates.

Try It on One Real Document

Pick a transcript or log you already have. Write down the five fields you actually need, decide what should happen when each one is missing, and choose the output format before you touch the model.

Then load the prompt template, which includes preset options for every variable and a full sample output, and save it to Prompt Vault so your schema and null policy stay the same from run to run. Check the first result against the source line by line. The fields that come back as null will tell you more about your data than the ones that come back filled in.

Tell the AI What It Cannot Touch: Why Hard Constraints Beat Better Prompts

Yao Xiao — Wed, 07 Oct 2026 15:13:47 +0000

Most people ask an AI for "a better resume" and get back something that reads well and is wrong. The numbers have been rounded up, the second page has appeared, and every bullet now starts with "Dynamic, results-driven professional". Then they spend twenty minutes fixing it by hand, and call that the AI being unreliable.

The model did what you asked. You never told it where the edges were.

The Real Cause of Rework Is Missing Boundaries

When a draft comes back unusable, the usual reaction is to add more detail to the prompt: more background, a longer role description, a nicer tone. That helps a little. It rarely fixes the thing that actually hurts, which is a specific violation you could have predicted before pressing enter.

A language model is trying to produce plausible text. Plausible and acceptable are different things. If you do not define the floor, the model fills every gap with whatever sounds most natural, and for a resume, the most natural continuation of "managed a team" is "managed a team of 15 and increased revenue by 40%".

Think about how a product manager writes a spec. The document has a list of things the feature must do and a list of things it must never do. Nobody expects an engineer to guess that the checkout flow cannot store card numbers. You say it up front, because discovering it in review is expensive.

Prompts work the same way. The cost of a missing rule is paid at the end, in rewrites.

Two Claims Worth Defending

This article rests on two ideas, and the rest is mechanics.

Claim one: constraints are the cheapest part of a specification. A "must" or "must not" costs you one short sentence. A missing one costs you a full revision cycle, and sometimes costs you a mistake you did not notice.

Claim two: the most valuable constraint is the one that tells the AI what to do when it cannot comply. Most people write rules without an exit. A model that is told "keep all quantified results" and "highlight growth experience" has no honest option when your resume contains no growth numbers. It will invent some. A rule needs a failure path.

Rules Go First, Errors Go Last

The ordering is not cosmetic. Put the hard constraints before the task details, then restate the most important ones briefly at the end if the prompt is long.

There is research behind this. In Lost in the Middle: How Language Models Use Long Contexts, the authors found that performance is often highest when relevant information sits at the beginning or end of the input, and degrades significantly when it sits in the middle. A constraint buried in paragraph four of a six-paragraph prompt is exactly the kind of information that gets weak attention.

The practical reading is simple. Do not hide a requirement in the middle of a story about your career. Give it its own line, near the top, where it cannot be mistaken for background.

Author's Comment: I treat the phrase "rules first, errors last" as a drafting order, not a slogan. Write the boundaries before you write the task. If you start with the task, the constraints become afterthoughts and end up as an apologetic "oh, and please don't make anything up" at the bottom.

What a Good Constraint Looks Like

A constraint is useful when you could check it without asking the AI. This is also how researchers evaluate instruction following. The IFEval benchmark from Google focuses on "verifiable instructions" such as writing more than 400 words or mentioning a keyword at least three times, because those can be scored by a script instead of an opinion.

Borrow that standard for everyday prompts. Compare these two:

Vague: "Keep it short."
Verifiable: "Must fit on one page, maximum 6 bullets per role."

The second version leaves nothing to interpret. You can count the bullets and look at the page. If the output fails, you know which rule broke, and you can point at it.

Must-haves

Must-haves protect what is valuable in your input. For a resume, that is the information that took years to earn.

Keep all quantified results exactly as written.
Keep the page limit at one page.
Emphasize user growth and data analysis experience.

Must-nots

Must-nots protect you from the model's default habits. Every model has a recognizable house style of inflated adjectives, filler openings, and unrequested additions. Name the ones that bother you.

No vague praise words such as "excellent" or "outstanding".
No new numbers, employers, or job titles that I did not provide.
No rewriting of dates.

Practical Pitfall Avoidance Guide: Pair every ban with a replacement behavior when you can. "No vague adjectives" works better as "No vague adjectives; describe the result with the metric instead." A bare prohibition tells the model what to avoid but not what to do in its place, and it tends to swap one cliché for the next.

The Escape Clause: Give the AI a Way to Say "Missing"

This is the part most prompt guides skip, and it is the one I would keep if I could only keep one.

Suppose your resume says you "improved onboarding" but gives no number. A strict instruction to "quantify every achievement" now collides with reality. The model has two options: break the rule by leaving the bullet unquantified, or satisfy the rule by fabricating a figure. Fluent models usually choose the second, because the output looks more compliant.

You prevent this by defining a third option: if a result lacks supporting data, write "TBD" next to it and tell me. Now the honest path is also the compliant path. The model is rewarded for flagging a gap instead of covering it.

This is the same logic behind prompts that let a model express uncertainty. If that idea is new to you, the site's guide on prompts that make AI admit it doesn't know covers the structures that shift a model from confident fabrication to honest uncertainty. The resume case is a small version of the same problem.

A Worked Example

Here is the original request that most people send:

Help me revise my resume.

The model has no job target, no limits, and no definition of failure. It will produce something generic and probably longer than before.

Here is the version with boundaries:

Optimize my resume for a Product Manager application.

Must:
- Keep every quantified result exactly as written.
- Fit on one page.
- Emphasize user growth and data analysis experience.

Must not:
- Use vague adjectives such as "excellent" or "outstanding".
- Add any number, employer, or title I did not provide.

If an achievement has no supporting data, mark it "TBD" and list
it at the end so I can fill it in.

Same resume, same model, a very different outcome. The first draft comes back on one page, the numbers match your source, and anything that was soft is flagged for you instead of polished into a lie. You review a short list of "TBD" items rather than hunting for hidden inventions line by line.

Why This Works Better Than Writing a Longer Prompt

Adding adjectives to a task description makes the target richer but not narrower. Adding constraints makes the target narrower. A prompt that says "write a professional, impactful resume" still allows millions of acceptable-sounding outputs, most of which violate something you care about.

Constraints cut the space of outputs from the outside. They do not require the model to understand your taste. They only require it to stay inside a fence.

Context still matters, of course. A rule list on top of a one-line request is better than nothing, but it is not a replacement for describing your situation. If you want the longer argument for rich context, read Stop Using One-Liner Prompts. The two habits stack: context says what the task is, constraints say what the answer cannot do.

Build the Habit Without Overdoing It

A few notes from using this pattern daily.

Keep the list short. Five to seven constraints is usually the ceiling before the model starts dropping some. If you need twenty rules, the task is probably two tasks.

Rank them. When two rules can conflict, such as "one page" and "keep all data", tell the model which wins. Without a priority, the model chooses for you.

Check the output against the list before you read it for style. A violated rule is cheaper to spot than a bad sentence, and it tells you exactly what to add to the next prompt.

If you reuse the same boundaries often, structure helps. Prompt Scaffold includes a dedicated Negative Constraints field next to Role, Task, Context, and Format, so the must-not list has a fixed place instead of floating at the bottom of a paragraph. It runs in the browser, so your resume text stays on your machine.

The One Change to Make Today

Before your next request, write two lists on a scratch note: what must be true of the answer, and what must never appear in it. Then add one more line that says what to do if the AI cannot meet a rule.

Send those three things before the task itself. The first draft will not be perfect, but it will be wrong in ways you chose to allow.