Aaliyaan Chaudhary — Writing

SpaceX IPO Made Elon Musk the World's First Trillionaire

Tue, 16 Jun 2026 00:00:00 GMT

On Friday, June 12, SpaceX started trading on the Nasdaq under the ticker SPCX.

By the time the dust settled a few days later, one private spaceflight company had pulled off the largest public offering in history, and one person had crossed a line nobody had ever crossed before.

Elon Musk is now a trillionaire. Not on a projection or a Polymarket bet. On the actual closing price of a stock you can buy.

I have watched a lot of IPOs get hyped and then fizzle. This one did the opposite. The numbers are big enough that they are worth writing down before the headlines round them off.

The biggest IPO ever, by a wide margin

SpaceX priced 555,555,555 shares at $135 each. That raised about $75 billion and valued the company near $1.75 trillion before a single share traded, according to the pricing announcement and NPR's coverage.

To put $75 billion in context, the previous record holder was Saudi Aramco, whose 2019 listing raised $29.4 billion. SpaceX raised more than twice that. It is not a new record by a few percent. It lapped the field.

The stock opened at $150, about 11% above the IPO price, and closed its first day around $159. That alone would have been a strong debut.

It did not stop there.

The stock kept climbing

By the second trading day, SPCX jumped another 20% and closed near $192, which put the company's market cap above $2.5 trillion, per Celebrity Net Worth's breakdown.

As I write this on June 16, SPCX is trading around $206, according to Investing.com. That is roughly 53% above the IPO price in four trading days.

A run like that on a company this size is rare. Most mega-cap debuts pop and then sag as early investors take profits. SPCX has done the opposite so far. Whether that holds is a different question, and I would not bet a paycheck on the next four days looking like the last four.

How Musk crossed a trillion dollars

Musk owns about 42% of SpaceX. The IPO filing puts it at roughly 4.8 billion shares, plus 350 million stock options exercisable at $8.39 each.

Do the math at current prices and his SpaceX stake alone is worth close to $866 billion, per Reuters. Stack his roughly 12% of Tesla on top of that, plus his stakes in X and xAI, and his total net worth has crossed $1 trillion. Some trackers now put it near $1.3 trillion after the second-day jump.

He is the first person to ever hold a trillion-dollar fortune. For scale, that is about twice what Jeff Bezos and Bernard Arnault are worth combined.

One thing worth being honest about. This is paper wealth. It is the market value of shares he holds, not cash in an account. If SPCX drops 30% next month, so does the headline number. Musk cannot sell $1 trillion of stock without crushing the price and triggering a tax bill that would itself make news. The trillion is real in the way the stock market is real, which is to say it is real until it moves.

Why a company that hated going public finally did

SpaceX stayed private for 22 years. Musk has said for most of that time that he did not want public-market pressure on a company doing things as long-horizon as Mars.

So why now? Money. Specifically, the kind of money that even a $1.75 trillion private company struggles to raise from venture rounds alone.

Three programs are eating capital. Starship is still in heavy development and burns cash every test cycle. The AI and data center push needs the same kind of spending everyone else in AI is doing right now, which is to say enormous. And Starlink keeps expanding its satellite fleet, which is not cheap to launch even when you own the rockets.

Here is the part that surprised me. Starlink is already the profit engine. It generated $11.4 billion in revenue in 2025, up 48% from the year before, and turned an operating profit of $4.4 billion, according to the stock analysis on Intellectia. That single business line is most of why investors were willing to pay a $2 trillion valuation for a company that still posts overall net losses from Starship.

Of SpaceX's $18.7 billion in total 2025 revenue, Starlink was the majority of it. Rockets, the thing the company is famous for, were the smallest slice at around 13%. The launch business is the brand. The internet business is the money.

What I am actually watching now

The IPO is the headline, but the interesting part starts now.

A public SpaceX has to file real numbers every quarter. For 22 years we got leaks and estimates. Now we get audited financials, and we will find out how deep the Starship losses really run against Starlink's profit.

I am watching three things. Whether Starlink's growth rate holds as it saturates the easy markets. Whether Starship development costs start showing up as a drag the market is not willing to forgive on a public timeline. And whether Musk's split attention across SpaceX, Tesla, X, and xAI becomes the kind of governance question public shareholders ask out loud in a way private investors never could.

Bottom line

SpaceX raised $75 billion, became a $2 trillion-plus company in days, and made Elon Musk the first trillionaire in history. Those are facts you can check against the tape.

If you want to follow it from here, do not watch the net-worth headlines. Watch the first quarterly filing SpaceX puts out as a public company. That report, not the IPO pop, is where you find out whether the $2 trillion price tag was a bet on rockets, on Starlink, or on Musk himself.

Sources:

Supercomputers, Quantum Computers, and the Threat to Crypto

Tue, 09 Jun 2026 00:00:00 GMT

The headline you keep seeing is wrong in both directions.

"Quantum computers will steal all the Bitcoin" is too strong. "Quantum is 40 years away, ignore it" is too comfortable. The truth sits in the gap, and the gap has been shrinking fast enough that the people who run the numbers for a living are nervous.

Here is the part that should get your attention. In 2012, breaking RSA-2048 was estimated to need roughly a billion physical qubits. By 2025, newer architectures put the figure under 100,000. That is five orders of magnitude in two decades, and most of the drop came from better algorithms and error correction, not bigger machines.

Let me walk through what is actually being threatened.

What "breaking crypto" really means

There are two different cryptographic primitives in play, and they fail in completely different ways.

The first is asymmetric cryptography. RSA and elliptic curve cryptography (ECC) are what protect your wallet keys, your TLS connections, and your signed transactions. Their security rests on math problems that are hard for classical computers: factoring large numbers, and the discrete log problem on an elliptic curve. Shor's algorithm, running on a large enough quantum computer, solves both in a way that is not just faster but fundamentally different. This is the real threat.

The second is symmetric cryptography and hashing. AES-256 and SHA-256, the hash that secures Bitcoin mining and addresses. Quantum computers help here too, through Grover's algorithm, but only by halving the effective key strength. AES-256 drops to AES-128 equivalent, which is still fine. SHA-256 stays well out of reach. Bitcoin's mining is not the weak point. The signatures are.

So when someone says "quantum breaks Bitcoin", they mean the ECDSA signatures that prove you own your coins, not the proof-of-work that secures the chain.

The qubit numbers that changed

For years the comforting figure was 20 million qubits to break ECC, with no machine anywhere near it. That number is gone.

In 2025, Google Quantum AI showed elliptic curve cryptography could be broken with fewer than 500,000 physical qubits, in a runtime measured in minutes. Then research from Caltech and a startup called Oratomic went further: with a neutral-atom architecture, ECC-256 could fall to roughly 26,000 qubits in about 10 days, and RSA-2048 to around 102,000 qubits over three months.

The most aggressive estimate now puts the threshold for emptying crypto wallets near 10,000 qubits.

For context on where the hardware sits today: Google's Willow chip, announced in December 2024, has 105 qubits. It demonstrated the thing that actually matters, which is below-threshold error correction. Each time they scaled the grid of qubits up, the error rate dropped by half instead of climbing. That is the result that turns "more qubits" from a liability into a path forward, and it is why the resource estimates keep falling.

We are not at 10,000 logical-quality qubits. But the trend line and the algorithmic improvements are both moving the wrong way for anyone holding long-lived secrets.

Harvest now, decrypt later

This is the attack that makes the timeline argument fall apart.

You do not need a working quantum computer today to be a victim today. An attacker can record encrypted data now, sit on it, and decrypt it the day a capable machine exists. For most encrypted traffic that is bad. For Bitcoin it is worse, because the ledger is public and permanent by design.

Every Bitcoin transaction that has ever exposed a public key is sitting on-chain in plain view, forever. Project Eleven estimates roughly 6.9 million BTC are in addresses where the public key is already visible. That includes about 1.7 million coins in ancient pay-to-public-key (P2PK) outputs from the earliest mining era, some believed to be Satoshi's roughly 1 million BTC.

Those coins cannot move themselves to safety. A dormant wallet is a sitting target. The day ECC breaks, anyone with the machine can derive the private key from the exposed public key and sweep the balance. Satoshi's wallet is the canary in the coal mine. If it ever moves, the migration is over and the panic has started.

What is already being done

The defense is not theoretical. It shipped.

In August 2024, NIST finalized three post-quantum standards: FIPS 203 (ML-KEM, for key exchange, formerly Kyber), FIPS 204 (ML-DSA, for signatures, formerly Dilithium), and FIPS 205 (SLH-DSA, a hash-based backup). FIPS 206 (FN-DSA, based on Falcon) is expected later in 2026. These are lattice-based and hash-based schemes that Shor's algorithm does not touch.

The migration calendar is real too. NIST's transition plan deprecates RSA-2048 and ECC P-256 by 2030 and pulls all quantum-vulnerable algorithms from its standards by 2035. The NSA's CNSA 2.0 mandates post-quantum crypto for new national security systems by 2027.

Bitcoin has its own path. BIP-360 proposes a new quantum-resistant address type, letting holders migrate coins to a "bc1r" address backed by post-quantum signatures. The hard problem is not the cryptography. It is getting millions of holders, many with lost keys, to actively move funds before the window closes. Coins in lost wallets can never migrate, which is exactly why the exposed P2PK pile is the unfixable part.

What I actually think

The 20-to-40-year estimates you see quoted are doing a lot of load-bearing work, and they are getting revised down every few months. I would not bet a life savings on them.

The realistic risk is not that quantum computing breaks crypto overnight next year. It is that the capability arrives gradually, the harvest-now data has been accumulating the whole time, and the migration is slow because coordination is hard. The technical fix exists. The deployment is the bottleneck.

Where to start

If you hold crypto, stop reusing addresses. A fresh address that has only received funds keeps its public key hashed and hidden until you spend from it, which is meaningful protection against the harvest-now attack. Reused addresses leak the public key on the first spend.

Move long-term holdings off ancient P2PK and exposed addresses into modern address types now, while it costs nothing but a transaction fee. Do not wait for the migration to be mandatory.

If you build anything that stores secrets meant to stay private past 2030, start looking at hybrid post-quantum key exchange today. ML-KEM is standardized and shipping in TLS libraries already. The data you encrypt this year is the data someone may be harvesting this year.

The machine that breaks this does not exist yet. The data it will break is being created right now. That mismatch is the whole problem.

Sources:

What Running Claude Code as an Agent Taught Me

Sat, 09 May 2026 00:00:00 GMT

Most of my Claude Code time used to look like this. Type a prompt. Read the diff. Accept it. Type another prompt.

That is chat. It works. It is also not the thing the tool was built for.

The shift happened when I started letting Claude run as an agent. Long-running tasks. Plan mode. Subagents doing the investigation. Hooks running verification on their own. After a few months of that, the lessons I came back to over and over were not about features. They were about discipline.

Here is what running Claude Code agentically actually changed for me.

Short sessions beat long marathons

The single most useful thing I noticed is that context degrades long before it fills up. Anthropic's best-practices doc says it plainly. Performance drops as context fills.

What this looks like in practice. Around 60 to 70 percent context, Claude starts forgetting rules in CLAUDE.md it was following an hour ago. It bundles commits even though I told it one fix per commit. It claims a fix works without running the verify command.

The fix is /clear between tasks, not /compact. Compaction summarizes. Clearing resets. For unrelated work, you want the reset. Agent-based runs in particular eat context fast because the agent reads files, runs commands, and pulls back tool output you do not need anymore.

Rule I keep. Two unrelated tasks in one session is one too many.

Checkpoint before any autonomous run

If you are about to say "go fix all the lint errors" or "migrate this directory to TypeScript", commit first.

Atomic, named, signed if your repo cares. The reason is simple. Agent-based work compounds errors. By the time you notice the agent has gone off the rails, it has touched fifteen files. Reverting from a clean checkpoint takes one command. Fixing forward takes an hour and rarely works.

Claude Code now ships checkpointing inside the tool itself. Double-tap escape, restore code or conversation or both. Useful, but it only tracks Claude's edits, not external processes. Real git commits still cover you for everything else.

Rollback over fix-forward

This is the rule that took me longest to accept.

When an agent run produces something wrong, the instinct is to correct. "No, you missed this case. Fix it." That works for one round. Rarely two. Past that, the context is polluted with failed approaches and the model is now reasoning from the wrong frame.

A fresh session with a sharper prompt almost always outperforms a long session with twenty corrections. The Claude Code docs flag this directly under "common failure patterns" and call it the correcting-over-and-over trap.

When I notice I have corrected the same issue twice, I stop. /clear, write a better prompt that bakes in what I learned, and go again. Faster every time.

Plan mode is not optional for multi-file work

The agent will happily jump straight into a refactor and bundle three concerns into one commit before you can stop it.

Plan mode separates research from execution. Claude reads files and writes a plan to disk. Nothing changes until you approve. For anything touching more than two files, anything refactor-shaped, anything in auth or migrations, I use it without thinking.

The single CLAUDE.md rule that made the biggest difference. "If execution diverges from the approved plan, stop and re-enter plan mode." Without it, agents drift. With it, they ask before scope-creeping.

Press Alt+T inside plan mode to enable extended thinking. For migrations and architecture decisions, the extra reasoning budget is worth more than the tokens it costs.

Verification is the line between an agent and an intern

The model defaults to optimism. Left alone, it will say "done" when the test it wrote does not actually run.

Three things plug this gap.

A PostToolUse hook that runs typecheck after any edit. If the typecheck fails, the agent cannot move on. Hooks cannot be ignored the way prompts can.

A CLAUDE.md rule that says "do not say done until you have run the verify command and pasted the output." Roughly 80 percent compliance from the rule alone. The hook covers the other 20.

For UI work, screenshots. The Chrome MCP or playwright lets the agent open the deployed page, grab a screenshot, and compare. This catches the cosmetic drift that tests cannot.

Split your models

Running everything on Opus is expensive and often slower. Running everything on Sonnet leaves quality on the table for the hard reasoning steps.

The split that works for me. Opus on the main session for planning, integration, and architecture calls. Sonnet on subagents for the focused work. The CLAUDE_CODE_SUBAGENT_MODEL env var controls the subagent model. Set once, forget it.

Subagents get their own context window. The main agent stays clean. The subagent burns its own tokens on a focused task and returns a summary. This was the single biggest token win I measured when I switched.

Worktrees beat branches for parallel agents

Two agents on the same checkout will collide. They will overwrite each other's edits, fight over the same lockfile, and leave the working tree in a state neither one expected.

Git worktrees give each agent its own isolated checkout of the same repo. Same git history, separate working directory. The Claude Code desktop app supports this directly. Each session gets its own worktree. Edits do not cross.

I use worktrees for two patterns. Writer plus reviewer, where one agent implements and a second agent in a fresh context reviews without bias toward the code it just wrote. And fan-out, where I run several focused agents on independent chunks of a larger migration.

Where to start

Three things, in order.

Set up CLAUDE.md with the rule about re-entering plan mode if execution diverges. One line. It changes more behavior than any other line you can write.

Make checkpoint commits a reflex before any autonomous task. Atomic, named, before the run starts. Reverting becomes free.

When you notice yourself correcting the same thing twice in a session, stop. /clear and start over with a sharper prompt. Treat polluted context as a dead session, not something to salvage.

Agent-based coding is a different mode of work, not a different feature. The features were already there. The discipline is what I had to build.

Sources:

The Best Super Powers for Claude Code

Fri, 08 May 2026 00:00:00 GMT

Most people I see complaining that Claude Code "feels mid" are using maybe 20% of what it can actually do.

They type a prompt, accept the diff, type another prompt, accept the diff. That is autocomplete with extra steps.

The thing that turned Claude Code from a fancy autocomplete into something I trust on real work is a small set of features that nobody bothers to read about. They are sitting in the docs. They take an hour to learn. After running this setup daily for months, here are the ones I would not give up.

Subagents

Subagents are the single biggest token win I have measured.

Each subagent has its own context window, its own prompt, and its own tool permissions. The main agent plans and integrates. The subagent does the dirty work and returns a summary. According to Anthropic's docs, they inherit MCP tools by default, so you can scope them tightly without losing capability.

I use them mostly for two patterns. Open-ended file searches like "find every place we call the Stripe webhook" go to an Explore subagent. The thrown-away pile of file reads stays out of my main context. Independent verification, where I want a second opinion on a migration or a security review, goes to a fresh subagent that has not seen my reasoning. That gives me an honest read instead of a yes-machine.

The cost is real. Subagents have startup overhead. For a one-shot grep, just grep. For a five-minute open-ended dig, spawn the agent.

Hooks

Hooks are deterministic code that runs around tool calls and session events. PreToolUse, PostToolUse, SessionStart, Stop, PreCompact.

The reason this matters is hooks cannot hallucinate. If a prompt says "always run typecheck before stopping", Claude will obey it about 80% of the time. If a Stop hook runs typecheck, it runs 100% of the time. As one writeup put it, hooks are how you turn a soft rule into a hard one.

The ones I keep. A PostToolUse hook that runs tsc --noEmit after any TypeScript edit. A Stop hook that auto-saves session retros to disk so the next session can load them. A PreToolUse hook that blocks edits to generated files.

I use maybe five hooks total. The point is not to automate everything. The point is to stop doing the same three things by hand at the start and end of every session.

Skills

Skills are reusable slash commands packaged as a SKILL.md file with YAML frontmatter and instructions.

The trick is the frontmatter tells Claude when to invoke the skill on its own. So /blog-post runs the full publishing pipeline, but I do not even need to type the slash. If I say "write a post about X", Claude reads the description, matches it, and runs the skill.

The big shift in 2026 was that custom slash commands got merged into skills. As the docs explain, files in .claude/commands/ still work, but skills in .claude/skills/ are now the recommended approach because the body only loads when invoked. Long reference material costs almost nothing until needed.

What I keep skills for. Multi-step playbooks I run more than twice a week. A /commit skill that drafts the message, runs verify, and stages. A /review skill that loads my review checklist. A /blog-post skill that handles research, voice-matching, and image fetching.

Skills you set with disable-model-invocation: true are user-only. Useful for anything with side effects like deploys or sending Slack messages, where you do not want the model deciding to run it.

Plan mode

Plan mode separates research from execution. Claude analyzes, reads files, and writes a plan to disk. Nothing changes until you approve.

Armin Ronacher noted that a plan in Claude Code is effectively a markdown file in Claude's plans folder. That framing helped me. It is not magic. It is just a file you read, edit, and approve.

When I use it. Anything multi-file. Anything refactor-shaped. Anything touching production or auth. Skip it for trivial mechanical edits where the plan would be longer than the diff.

The single rule that has improved my outcomes the most. Add this to CLAUDE.md: "if execution diverges from the approved plan, stop and re-enter Plan Mode." Without this, the model will quietly extend scope mid-task and you will not notice until something breaks.

Press Alt+T while in plan mode to enable extended thinking. For migrations, architecture, and anything where being wrong is expensive, the extra reasoning budget pays for itself.

MCP servers

MCP is how Claude Code reaches outside the terminal. The protocol is the same. The servers are pluggable.

The five I would not work without.

github for PRs, diffs, issues, and file reads without leaving the terminal. supabase for SQL, migrations, and schema reads from chat. context7 for current library docs instead of stale training data. This one alone has cut my "wrong API version" bugs to almost zero. playwright so Claude can browse the deployed site, take screenshots, and verify its own work. sentry for production error triage from chat.

The warning from Anthropic's best-practices doc still applies. Ten or more MCP servers slows startup and adds token overhead. Install what you actually use and remove the rest. I have culled mine twice this year.

Persistent memory

Memory is what lets Claude carry knowledge across sessions without you writing CLAUDE.md by hand.

It lives in ~/.claude/projects/<project>/memory/ as typed markdown files prefixed with user_, feedback_, project_, and reference_, with a one-line index in MEMORY.md. Claude decides what is worth saving based on whether the fact would be useful in a future conversation.

What it is good for. Facts that survive across sessions. Deployment quirks. Naming conventions. Prior decisions you keep wanting to look up. Feedback the user has given that should not need repeating.

What it is not good for. Code patterns and file paths. Those live in the code. Saving them just creates duplicate truth that goes stale.

The other half of this is CLAUDE.md at the repo root. Stack overview, ownership matrix, hard rules. Aim for under 200 lines. Past that you are putting code-pattern detail in a place where it does not belong.

Where to start

Pick three.

Write a CLAUDE.md with your stack, your conventions, and your "do not touch" list. Add the rule about re-entering plan mode if execution diverges.

Set up two or three skills for the playbooks you run most. Start with whatever you keep pasting into chat.

Use subagents for any task that starts with "find every place where" or "check whether the codebase does". Those are the open-ended searches that destroy your context if you do them in the main thread.

Hooks, MCP, and memory are all worth adding. Just not on day one. The reason a tight setup works is because the model has fewer distractions, not because every component on a list is installed.

The model is not the variable. The harness is.

Sources:

5 Claude Projects That Can Run Your Whole Business

Thu, 07 May 2026 00:00:00 GMT

Most people use Claude like a chatbot.

Open a tab. Type a question. Close the tab. Repeat.

That works, but it wastes the most useful feature inside Claude. Projects.

Projects give Claude a persistent layer of memory tied to a specific area of your work. You set the context once, and every conversation inside that project starts with it already loaded. Anthropic ships them with a 200K-token context window, custom instructions, a knowledge base for files, and on paid plans, RAG that expands capacity by up to 10x when the knowledge base outgrows the window. (Source: Anthropic support docs.)

After running this setup for the last few months, I have settled on five projects that each cover one part of my business. It is the closest thing to a real second brain I have used inside an AI tool.

Here is what each project does and the instructions to drop in.

What Projects actually do

A Project is a workspace with three things attached to it.

First, a system prompt that runs on every message you send inside the project.

Second, a knowledge base where you upload files. PDF, DOCX, CSV, TXT, HTML, RTF, EPUB, and a few more. Each file can be up to 30MB, with no cap on the number of files as long as the total stays inside the context window.

Third, conversation history kept inside the project, so threads stay separate from your other work.

That combination is what makes Projects different from a regular chat. You stop re-explaining your business, your tone, your audience, and your goals on every message. Claude already has the context.

The catch is that the system prompt counts against your context window. Keep it tight. Anthropic's own guidance is to use it for general context and reserve task-specific instructions for the chat itself.

1. Content

The first project I set up was Content.

This is where every post, caption, newsletter, and thread gets drafted. The point is consistency. If I write in three different tones across LinkedIn, X, and my blog, I sound like three different people. So the system prompt locks in one voice.

My brand is [name].
My audience is [describe].
My tone is [3-5 words].
Platforms I post on: [list].
My content style: [describe or paste examples].

Every piece of content should sound like me, not AI.

I also drop 4 to 5 of my best-performing posts into the knowledge base. Claude pattern-matches off them. The output is closer to my actual writing than anything I get from a fresh chat.

2. Clients

The Clients project handles every outbound message that goes to a real person paying me money.

Proposals, onboarding emails, scope clarifications, follow-ups. The instructions cover what I sell, who buys it, and how I move someone from a first reply to a signed contract.

My business offers [services].
My ideal client is [describe].
My pricing: [list].
My process from inquiry to delivery: [describe].

When writing to clients, match this tone: [professional / casual / friendly].

The reason this saves time is not the typing. It is the thinking. I no longer have to reconstruct my own pricing logic or scope language every time a new lead lands in my inbox.

3. Emails

Email is its own project because the tone is different from client work.

Newsletters, replies to readers, cold outreach, and personal email all live here. The trick is being specific about what you do not want. Vague instructions produce vague output.

I write emails for [business / personal / both].
My tone is [describe].
I prefer emails that are [short and direct / warm and detailed].

Never use: [words or phrases you hate].
Always include: [sign-off, CTA style, formatting preferences].

I have a "never use" list with about a dozen entries on it. Phrases like "I hope this finds you well", "circle back", and "just wanted to check in". Banning them once, inside the project prompt, fixes them forever.

4. Research

The Research project is the one I underestimated at first.

Default Claude is good at research but it gives you everything. You ask a small question and you get six paragraphs. This project trims that down.

When I ask you to research something, give me facts first, opinions second.
Include sources when possible.
Summarize in bullet points.
Flag anything that is uncertain.

My industry is [industry].
Focus on information relevant to [your niche].

The "flag anything uncertain" line is the one that matters. Claude will sometimes give you an outdated number or a half-correct claim with full confidence. Asking it to flag uncertainty up front catches a lot of those before they reach a draft.

For deeper work, I pair this with web search and a few uploaded reference PDFs in the knowledge base.

5. Finances

This one I treat with more caution. Claude is not a CPA. But it is good at math, ranges, and sanity checks if you give it the real numbers.

My business revenue is approximately $[range].
My main expenses: [list].
My currency is [currency].

When I ask about money, assume my tax situation is [country / filing status].

Help me find savings, optimize spending, and plan ahead.

I use this for monthly reviews, expense categorization, and "if I cut X, what happens to Y" scenarios. Anything that touches an actual tax filing still goes through a human professional. But for the routine stuff, having a context-aware sounding board has been useful.

One note on privacy. Anthropic does not train on your data by default for paid plans, but read the policy yourself before uploading anything sensitive.

Where to start

Pick one. Not all five.

Content is the easiest to feel value from quickly because you generate output every day. Set up the project, drop your tone notes and a few sample posts in, and use it for a week before adding the next one.

The mistake people make is doing all five on day one and never adjusting any of them. The system prompts in this post are starting points. The version that actually runs your business is the one you have edited four or five times after seeing what Claude got wrong.

Sources:

Chrome Silently Installed a 4 GB AI Model on My PC

Thu, 07 May 2026 00:00:00 GMT

I noticed it on a Saturday morning while running a routine cleanup.

My SSD had been complaining about space for weeks. I cleared old node_modules folders, blew away dead Docker images, emptied the trash. Nothing moved the needle the way I expected.

So I opened a disk-usage scanner and let it walk the whole drive.

The first surprise was that Chrome was sitting at over 5 GB. Not the install. The user profile.

The second surprise was a single file inside it called weights.bin, weighing in at almost exactly 4 GB.

I had not asked for a 4 GB file. I had not been told a 4 GB file existed. And the name looked an awful lot like an AI model.

This is what I found when I started pulling the thread.

Where the file lives

On Windows, the path is buried where most people will never look:

C:\Users\<your-name>\AppData\Local\Google\Chrome\User Data\OptGuideOnDeviceModel

On macOS, the same idea sits at ~/Library/Application Support/Google/Chrome/OptGuideOnDeviceModel. On Linux it is at ~/.config/google-chrome/OptGuideOnDeviceModel.

Inside the folder is a versioned subdirectory and one large weights.bin file. There is no readme. There is no setup wizard that mentioned it. There is no settings page in Chrome that says "you have a 4 GB model installed and here is how to remove it" the way a Steam library lists installed games.

It is just there.

What the file actually is

The bin is the model weights for Gemini Nano. That is Google's small on-device language model, the kind designed to run inside the browser process without calling out to a cloud endpoint.

Chrome uses it to back a handful of features. The "Help me write" prompt that appears in text fields. On-device scam and phishing detection. Smart paste. Page summaries. AI-assisted tab grouping. Anything exposed through the new Prompt API and the related Writer, Rewriter, and Summarizer APIs that Chrome has been rolling out for web developers.

In isolation, those features are fine. Some of them are even useful. The problem is not the existence of an on-device model. The problem is how it got onto my machine.

What triggers the download

Chrome runs a quiet eligibility check on startup. If your machine clears all four of these bars, the download begins in the background.

More than 4 GB of GPU VRAM.

At least 16 GB of system RAM.

Four or more CPU cores.

At least 22 GB of free storage on the drive holding your Chrome profile.

If you sit above all four, Chrome calls Google's optimization-guide endpoint, pulls the model, and writes it to disk. No prompt. No notification banner. No "do you want this?" dialog. The internal feature flag that controls it, OnDeviceModelBackgroundDownload, is being switched on for eligible users before the matching toggle is even visible in your settings.

If your free disk space later drops below 10 GB, Chrome quietly cleans the model up. If you fail the eligibility check for 30 days in a row, same thing. The browser is silently managing a multi-gigabyte asset on your machine and not telling you about any of it.

What "delete it" actually does

My first instinct was to nuke the file. I closed Chrome, deleted the entire OptGuideOnDeviceModel folder, restarted the browser, and watched my disk usage drop by 4 GB.

For about a day.

The next time I left Chrome running long enough for an idle window, the folder reappeared and the bin came back with it. The eligibility checker had run again, decided I was still a good candidate, and the optimization-guide service had repulled the model from scratch.

This is the part most people miss when they first find the file. The folder is not garbage left behind by a one-time event. It is actively maintained. The browser will undo your cleanup as a matter of design.

The real way to stop it

There are two paths that actually hold up.

The settings path is the friendly one. Open Chrome and go to chrome://settings/ai. Turn off the on-device AI features there. Then close Chrome, delete the OptGuideOnDeviceModel folder one more time, and reopen the browser. With the feature off, the model does not come back.

The policy path is the hard kill. On Windows, open regedit, navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome, and create a new DWORD value called GenAILocalFoundationalModelSettings. Set it to 1. That is the official enterprise policy for blocking the local foundation model. Restart Chrome and visit chrome://policy to verify it is loaded.

I went with the policy route because I do not want to find out in six months that a future Chrome update flipped the settings toggle back on by default.

On macOS, the equivalent is a defaults write com.google.Chrome GenAILocalFoundationalModelSettings -integer 1 command. On Linux, it is a JSON file dropped into /etc/opt/chrome/policies/managed/ with the same key.

Why this bothers me more than it should

I am not against on-device AI. I would rather have a model running locally than have my keystrokes shipped to a server every time I write a sentence in a text area.

What bothers me is the consent model.

Four gigabytes is not a rounding error. It is a Steam game. It is a Linux distro and a backup, sitting in the same disk allocation. On a 256 GB laptop, it is over 1.5% of the entire drive. At a billion-device scale, it is petabytes of storage and a real amount of bandwidth, paid for by users who never agreed to host any of it.

A browser is supposed to be the layer I trust to not surprise me. The implicit contract is that it loads pages, stores cookies, and gets out of the way. Background-downloading a multi-gigabyte model into a hidden folder breaks that contract, even when the model itself is harmless.

The fix Google has shipped, the AI settings toggle, only works if you know the model is there in the first place. Most people will never check.

Where to start

If you use Chrome on a machine that meets the spec, do this today.

Open chrome://settings/ai and read what is on. Turn off anything you do not actively use. The "Help me write" entry is the one most people want gone.

Then open the OptGuideOnDeviceModel folder for your platform and check the size. If you see a multi-gigabyte weights.bin file you did not ask for, you now know what it is and what to do about it.

If you are on a managed device, or you want a permanent block that survives Chrome updates, set the GenAILocalFoundationalModelSettings policy to 1 using the registry on Windows or the defaults command on macOS. That is the one setting Chrome respects across versions.

The model is not malware. It is not stealing your data. But it is a 4 GB decision that someone else made for you, and you get to decide whether you want to keep it.

Claude Code Is Not the Problem. Your Harness Is.

Thu, 07 May 2026 00:00:00 GMT

Most people I see complaining about Claude Code "going dumb" or burning through quota are not using a broken model.

They are using a broken setup.

No CLAUDE.md. No memory. No tools. They dump 40 files into one context window, watch it hallucinate, and conclude the model is the problem.

After running Claude Code daily for the last several months, I have landed on a setup that mostly works. The framing I keep coming back to is this. The harness is the variable. Below is what I actually use, the rules that hold up under daily pressure, and the parts I would skip.

Context discipline cuts token usage

Anthropic's own Claude Code docs say context is your fundamental constraint. Every token you spend on noise is a token you do not have for the actual problem.

Three things bring this under control.

A CLAUDE.md at the repo root. Stack overview, ownership matrix, hard rules. Things like "run tsc --noEmit after every edit", "max 50 lines per bugfix", "one fix per commit", "do not touch auth or payments without approval". Claude reads it at the start of every session. You stop answering the same questions on every chat.

Persistent memory at ~/.claude/projects/<project>/memory/. Typed markdown files prefixed with user_, feedback_, project_, reference_, with a one-line index in MEMORY.md. I do not use this for everything. I use it for facts that survive across sessions, things like deployment quirks, naming conventions, and prior decisions I keep wanting to look up. Code patterns and file paths do not belong here. Those live in the code.

Subagents for grep work. This is the biggest single token win I have measured. Spawning an Explore or general-purpose subagent to do file digging keeps the noise out of your main context. The subagent burns its own tokens, returns a summary, and disappears. My main window stays clean.

The caveat from Anthropic's docs is real. Subagents have startup overhead, so you do not use them for small one-shot lookups. Use them when the search is open-ended or when the result will be a thrown-away pile of file reads.

Workflow rules that hold up

A few rules I keep because they actually change behavior.

Auto-retros after each non-trivial session, saved to docs/retros/YYYY-MM-DD-topic.md. The next session loads the latest retro at start. You get continuity without the re-briefing tax.

Verification before completion. Claude does not get to say "done" or "fixed" until it has run the verify command and shown the output. This kills hallucinated success. It is also the rule I had to enforce most aggressively at first because the model defaults to optimism.

Atomic commits, one fix per commit, hard line limits. Forces Claude to scope its work and gives me clean rollback. Without this rule, the model will quietly bundle three things into a single commit and you will not notice until something breaks.

For architecture decisions or anything touching security or migrations, I spawn Gemini Pro, Flash, and Sonnet in parallel and synthesize the answers. Three independent reads beat one confident monologue. This has caught things a single model missed more than once.

MCP servers I keep installed

The ones I would not work without:

supabase for SQL, migrations, and schema reads from chat. Saves me bouncing to a separate console.

github for PRs, diffs, issues, and file reads. The official server. One connection covers most of what I used to leave the terminal for.

playwright and chrome-devtools-mcp so Claude can browse the deployed site, take screenshots, and run JS in the page. It QAs its own work instead of asking me to "please verify".

context7 for current library docs instead of stale training data. This is the single MCP that has reduced my "Claude wrote against the wrong API version" bugs to almost zero.

sentry for production error triage from chat.

firecrawl for on-demand scraping and a gemini MCP to power the multi-model panel above. I use both occasionally, less than the others.

One thing the post is right about: 10+ MCP servers slows startup and adds token overhead. Anthropic's best-practices doc warns about the same thing. Install what you actually use, remove what you do not.

Hooks do the janitor work

PreToolUse, PostToolUse, SessionStart, PreCompact, Stop. These let you run shell commands in response to specific events. Auto-save memory on Stop. Auto-run typecheck on PostToolUse for an edit. Sync state before compaction.

I use a small number of hooks. The point is not to automate everything. The point is to stop doing the same three or four things by hand at the start and end of every session.

What I would skip

A lot of "ultimate Claude Code setup" lists recommend graphify for clustering large repos into HTML and JSON knowledge graphs, and claude-flow for swarm orchestration with hooks, memory coordination, SPARC, and TDD pipelines.

I have tried both. For the kind of work I do, they were more setup than payoff. If you maintain a 200-file monorepo with multiple teams touching it, the calculus might be different. For a solo or small-team codebase, plain CLAUDE.md plus subagents already covers most of the win.

More tools is not better. The reason a tight setup works is because the model has fewer distractions, not because every component on a list is essential.

Where to start

Pick three things in this order.

Write a CLAUDE.md. Put your stack, your rules, and your "do not touch" list in it. Aim for 50 to 150 lines. If it grows past that, you are putting code-pattern detail in there that belongs in the code.

Add the verification-before-completion rule. One sentence in CLAUDE.md. Claude must run the verify command and paste output before claiming a fix works.

Use subagents for any task that starts with "find all the places where..." or "check whether the codebase does...". Those are the open-ended searches that destroy your context if you do them in the main thread.

The model is not the problem. The setup around it is what decides whether Claude Code feels like a senior engineer or a confused intern.

Sources:

Top 10 GitHub Repos to Power Up Claude Code

Tue, 05 May 2026 00:00:00 GMT

Claude Code works well on its own. But most people using it have not touched the ecosystem around it. MCP servers, custom skills, hooks, GitHub Actions, community configs. All of it is free and sitting on GitHub.

Here are 10 repos worth knowing about.

1. hesreallyhim/awesome-claude-code

Start here.

It is a curated list of skills, hooks, slash commands, orchestrators, apps, and plugins built by people who actually use Claude Code. Not vendor content. A real community index.

When you do not know what you are looking for, or want to check if something already exists, this is where you start.

hesreallyhim/awesome-claude-code

2. anthropics/claude-code-action

This GitHub Action puts Claude inside your pull request workflow. Tag @claude on any issue or PR and it will respond. In agent mode, give it a task via prompt and let it run.

For teams, this is the easiest way to share Claude access without changing how people already work. Review, triage, and summaries happen without someone having to sit down and do them.

anthropics/claude-code-action

3. modelcontextprotocol/servers

Anthropic's reference implementations for MCP. Filesystem access, persistent memory, a few others. Teams use these directly in production — they are not just examples.

If you are about to build your own MCP server, read one of these first. The code is clean and it will save you an afternoon of guessing.

modelcontextprotocol/servers

4. github/github-mcp-server

GitHub's own MCP server. One connection gives Claude Code access to your repos, issues, pull requests, and code search.

It runs as a managed remote endpoint so there is nothing to maintain. You can also run it locally and choose which GitHub API features to expose.

github/github-mcp-server

5. microsoft/playwright-mcp

Claude Code can read a browser page through its accessibility tree, not a screenshot. That means it sees the structure of the page the way a screen reader does — fast and accurate without needing vision mode.

I use this to check that what I built actually renders correctly in a browser. It also handles automated testing for flows I would otherwise skip.

microsoft/playwright-mcp

6. upstash/context7

Claude writes code against outdated library versions more often than it should. Context7 fixes this by pulling current, version-specific documentation and injecting it into Claude's context.

Set it up once. You will notice it stopping to correct itself less on API calls that changed between versions.

upstash/context7

7. rohitg00/awesome-claude-code-toolkit

135 agents, 35 skills, 42 commands, 20 hooks, 14 MCP configurations, and more. It is a lot to take in.

The hooks and agent definitions are where to start. Skip the rest until you have a reason to go looking.

rohitg00/awesome-claude-code-toolkit

8. tolkonepiu/best-of-mcp-servers

Most MCP server lists go stale fast. This one updates automatically every week, with servers ranked and categorized.

When you want to find a server for a specific integration and do not want to wade through hundreds of low-quality entries, this is the right place to look.

tolkonepiu/best-of-mcp-servers

9. Comfy-Org/comfy-claude-prompt-library

The ComfyUI team published their actual Claude Code setup — the commands and CLAUDE.md entries they use in production.

Seeing how a real team has configured their context is more useful than most documentation. Even if you change everything, it gives you a concrete starting point.

Comfy-Org/comfy-claude-prompt-library

10. travisvn/awesome-claude-skills

Skills only. The list is focused and the quality bar is higher than most "awesome" repos.

If you want community-built skills for code review, testing, or documentation, start here before browsing the broader collections.

travisvn/awesome-claude-skills

Where to start

github/github-mcp-server and upstash/context7 are the fastest to set up and make the most immediate difference. Add playwright-mcp if you are working on anything with a browser interface.

Keep hesreallyhim/awesome-claude-code open as a reference. The rest you can pick up as you need them.

Top 20 ChatGPT Image Generation Examples (With Prompts)

Tue, 05 May 2026 00:00:00 GMT

GPT-Image-2 is OpenAI's most advanced image model, built directly into ChatGPT and available through the API. It handles photorealism, accurate text rendering, complex prompt adherence, and multi-turn editing better than anything before it.

The difference between a mediocre output and something actually usable is not the model. It is the prompt.

Most people describe. The best results come from people who brief — like a creative director briefing a photographer, or an art director briefing an illustrator. Subject, style, lighting, medium, mood. In that order.

Here are 20 prompts across 20 categories that show exactly what GPT-Image-2 can do when the prompt does its job.

1. Cinematic Portrait

Portrait prompts fail when they stay vague. "A beautiful woman" gives the model too much freedom and the result is generic every time. Lock down the lens, the light source, and the mood before anything else.

A close-up cinematic portrait of a 35-year-old woman with piercing green eyes, photographed on an 85mm f/1.4 lens, soft golden hour sidelight coming from the left, shallow depth of field, slight film grain, visible skin texture, neutral blurred background, muted warm color grade reminiscent of 2000s cinema, photorealistic

What makes this work: the lens focal length (85mm), aperture (f/1.4), and light direction turn a vague idea into a specific visual.

2. Neon Cyberpunk Cityscape

Cyberpunk prompts work when the physical environment is specific. Rain, surface reflections, signage language, and color temperature are what make a scene feel lived-in rather than generated.

A rain-soaked cyberpunk alley at 3am, neon signs in magenta and electric blue reflecting off wet cobblestones, dense fog rolling between brutalist buildings covered in kanji advertisements, a lone figure in a black trench coat standing at the far end of the alley, cinematic wide shot, anamorphic lens flare, volumetric fog, photorealistic, 8K detail

The lone figure anchors the scale. Without a human reference, urban scenes lose their sense of depth.

3. Surreal Dreamscape

The trick with surreal prompts is anchoring one impossible element inside an otherwise hyper-real environment. The contrast between the ordinary and the impossible is what creates real impact.

A hyper-realistic photograph of a grand marble staircase ascending through open ocean water, each step clearly submerged but bone dry, schools of tropical fish circling the ornate banister, perfect natural daylight filtering down from above, seaweed and barnacles on the lower steps, photorealistic despite the impossible subject, fine detail throughout, 35mm film aesthetic

Note the instruction "photorealistic despite the impossible subject" — GPT-Image-2 needs that signal to commit to realism instead of drifting into painterly abstraction.

4. Luxury Product Photography

Product prompts need three things: precise material description, the exact lighting angle, and a surface for the product to inhabit. Skip any of those and the output looks like a placeholder mockup.

A luxury perfume bottle, hexagonal cut crystal glass with a brushed gold cap and embossed floral pattern, positioned on textured white marble with micro water droplets beading on the glass surface, single dramatic sidelight from the left casting a long prismatic shadow, deep black background with a subtle gradient lift, macro lens detail, commercial product photography, ultra high contrast

The prismatic shadow is the detail that makes this specific. That one physical fact forces the model to commit to a real light source.

5. Epic Fantasy Landscape

Epic landscapes work when you layer the composition explicitly: what occupies the foreground, midground, and background. Tell the model what lives in each plane and the depth takes care of itself.

An epic fantasy valley at dusk, massive bioluminescent mushrooms towering 200 feet high in the foreground with soft blue-green light emanating from their caps, a river of liquid gold winding through the midground, an ancient stone castle built into a floating rock formation hovering above the mist layer, twin purple moons rising on the horizon, digital matte painting style, hyper detailed, dramatic volumetric lighting

Three distinct layers of the scene described explicitly means three distinct zones of detail in the output.

6. Gourmet Food Photography

Food photography prompts are about camera angle, surface texture, and steam. Most amateur prompts skip two of those three. All three are what separate restaurant-quality from stock image.

A hero shot of pan-seared duck breast on a dark slate plate, thin slices fanned out to reveal a perfect medium-pink center, golden jus pooling around the base of the meat, microgreens scattered with tweezers, wisps of steam rising from the surface, shot from a 45-degree overhead angle, Hasselblad medium format photography style, controlled ambient light with a rim highlight from the right, restaurant quality

"Scattered with tweezers" is the kind of detail that tells the model this is precision plating, not home cooking. Word choice signals intent.

7. Deep Underwater Scene

Underwater prompts need to describe how light actually behaves underwater. It does not beam downward — it fans out and diffuses. That one physical fact separates outputs that feel real from ones that feel like a digital painting of water.

A view from 20 meters below the ocean surface looking up at a coral reef, shafts of turquoise-teal light fanning through the water from above, a sea turtle gliding toward the surface in the center frame, soft coral in vivid orange and purple covering the reef walls, a school of silver fish catching the light and scattering, cinematic underwater cinematography, bubbles rising from below, photorealistic, fine detail throughout

The upward-looking angle is worth trying in any underwater prompt. It gives the model a direction for the light source.

8. Space / Sci-Fi Scene

Scale is the hardest thing to convey in space imagery. Include one human-scale reference and everything else becomes legible. Without it, the vastness reads as emptiness.

A derelict space station orbiting an amber gas giant with clearly visible storm bands, the station's fractured solar panels spinning slowly through a debris field of metal fragments, a single astronaut in a white EVA suit tethered to the outer hull, dwarfed by the planet filling the frame behind them, lens flare from a distant binary star, cinematic composition, photorealistic, volumetric lighting, fine film grain

The astronaut does all the work of making the station feel massive. Everything else describes the environment.

9. Studio Ghibli / Anime Style

Style prompts work best when you name the source directly and then describe the scene in the same vocabulary that source uses. Ghibli means warm light, hand-painted textures, and a specific quietness that is hard to achieve without naming it.

A hand-painted Studio Ghibli-style landscape of a cobblestone village street in late autumn, warm amber lamplight spilling from a bakery window onto the street, a young girl in a red coat walking home with a canvas umbrella, fallen leaves swirling around her in the breeze, soft painterly brush textures throughout, muted earth tones with pops of crimson and gold, 2D anime illustration, Studio Ghibli aesthetic

Naming "Studio Ghibli" twice — once in the opening and once at the close — reinforces the style commitment. It works.

10. Watercolor Illustration

Watercolor prompts need to specify what bleeds and what stays contained. Deliberate looseness is the point of the technique — but a prompt that does not acknowledge that produces something that just looks unfinished.

A loose watercolor illustration of a hummingbird hovering over a tropical hibiscus flower, pigment blooms and bleeds visible at the edges of each shape, wet-on-wet technique evident in the background wash, soft paper texture showing through the lighter areas, limited palette of emerald green, coral pink, and ivory, white space preserved around the subject, delicate ink linework applied over the dried washes

"Wet-on-wet technique" and "ink linework over dried washes" are real watercolor terms. GPT-Image-2 understands them and applies them accurately.

11. Architectural Render

Architecture prompts should specify material finishes, time of day, and whether people are present. Absence is often the better choice. A building without people keeps focus on the space itself.

A photorealistic architectural render of a minimalist beach house cantilevered over a rocky cliffside at golden hour, exposed raw concrete exterior with board-form texture, floor-to-ceiling frameless glass panels facing the ocean, an infinity pool flush with the terrace edge reflecting the amber sky, interior pendant lighting beginning to glow against the fading daylight, wide tilt-shift lens, no people, warm against cool color contrast

"Board-form texture" is a specific concrete finish. That one detail tells the model the building has been designed with intention, not just rendered in a default material.

12. Vintage Film Photography

Vintage prompts land when you name the specific film stock, the decade, and the exact light source. "Vintage feel" is not a brief. "1972 Kodachrome 64" is.

A candid street photograph in the style of 1972 Kodachrome 64 film, a man in a wide-lapel checked blazer reading a folded newspaper at a linoleum diner counter, harsh overhead fluorescent lighting casting slightly unflattering shadows, deeply saturated primary colors with a warm color cast, fine grain structure visible throughout, 35mm full bleed composition, slightly soft focus as if scanned from an original print with minor handling marks

"As if scanned from an original print with minor handling marks" gives the model permission to add imperfection. That imperfection is what sells the vintage quality.

13. Abstract Geometric Art

Abstract prompts fail when they just say "abstract and colorful." Name the organizing principle — color field theory, sacred geometry, recursion. Give the model a logic to follow and the output has intention.

A large-format abstract painting in the tradition of color field theory, three vertical bands of color occupying the full canvas — deep cerulean on the left, raw umber in the center, ochre on the right — each band bleeding softly into the next at the seam, visible linen canvas texture throughout, slight paint build-up at the outer edges of each field, museum quality, photographed flat under even studio lighting, no reflections, no shadows

Mark Rothko and Barnett Newman painted in this tradition. Naming the tradition is more useful than trying to describe the aesthetic from scratch.

14. Wildlife Photography

Wildlife prompts are about the relationship between the animal, the light, and the moment — not the animal alone. The environment and the technical specification are what make the photograph feel real.

A wildlife photograph of a Bengal tiger emerging from tall golden savanna grass at dawn, one amber eye locked directly on camera, backlit by the rising sun creating a strong rim light through the fur, shallow depth of field with the foreground grass softly blurred, Canon 500mm telephoto compression, dusty warm dawn light, absolute stillness in the tiger's posture, National Geographic quality

"National Geographic quality" at the end of a prompt functions as a quality floor instruction. It works surprisingly well.

15. Fashion Editorial

Fashion prompts should read like a shoot brief. Location, garment description, light source, camera format. That specificity tells the model what decision a real photographer would have made — and the model commits to it.

A high fashion editorial photograph of a woman in a sculptural off-white origami-folded gown standing in a brutalist concrete corridor, harsh direct flash at camera height creating flat, sharp shadows on the wall directly behind her, the garment's geometric silhouette graphic against raw grey concrete, shot on a Mamiya RZ67 medium format camera, blown-out highlights on the fabric surface, no accessories, stark and architectural in composition

Naming a specific camera (Mamiya RZ67) and a specific film medium format aesthetic tells the model a lot about contrast, tonal range, and grain. It is a shorthand for an entire visual language.

16. Macro Nature Photography

Macro prompts live or die on subject specificity. "A flower close-up" is too vague. Name the exact insect, exact plant species, or exact surface. The model's botanical and entomological knowledge is extensive — use it.

An extreme macro photograph of a honey bee covered in yellow pollen grains on a lavender floret, every individual pollen particle visible on the bee's fuzzy thorax and legs, one compound eye rendered in sharp focus showing its hexagonal facets, the wing membrane catching a backlight and revealing its cellular vein structure, out-of-focus purple lavender bokeh in the background, natural daylight, 5:1 macro magnification, Canon MP-E 65mm lens rendering

"Hexagonal facets" of the compound eye and "cellular vein structure" of the wing are real anatomy. Naming them produces them.

17. Horror / Dark Atmosphere

Horror prompts work when they name what is specifically wrong — not just that things are dark. Vague dread produces nothing interesting. A precise wrongness inside an ordinary scene is what makes an image genuinely unsettling.

A photorealistic photograph of an ordinary hospital corridor at 3am, every overhead fluorescent light burned out and dark except one at the far end flickering irregularly, a wheelchair facing away from camera positioned precisely in the center of the hallway, wet footprints on the linoleum leading toward it from nowhere visible, no shadows where shadows should logically fall, medium film grain, clinical institutional detail throughout, hyper real

"No shadows where shadows should logically fall" is the specific wrongness that does the work. It is the kind of detail you cannot get from a vague prompt.

18. Children's Book Illustration

Children's book prompts need to describe the emotional warmth explicitly. These images communicate safety and wonder through texture and light. Naming the painting technique matters more here than in most other categories.

A children's book illustration of a small red fox wearing a hand-knitted orange scarf, sitting by a crackling campfire in a snowy pine forest at night, visible stars through the tree canopy above, warm amber firelight on the fox's face contrasting against cool blue-white snow on the ground, a tin mug of something hot steaming beside him, gouache painting technique, slightly textured paper, soft rounded forms throughout, storybook warmth

Gouache is the right medium to name here. It gives the image opacity and warmth that watercolor cannot and that digital illustration often misses.

19. Historical Reimagining

Historical reimagining prompts are most interesting when the anachronism is precise rather than general. Both sides of the collision need to be specific. A smartphone in a Rembrandt portrait works because the 17th century and the 21st century are each described accurately.

A photorealistic oil painting in the Dutch Golden Age style, depicting a wealthy 17th-century merchant seated at a writing desk, holding an iPhone 15 Pro instead of a quill, the phone screen clearly showing a stock trading app with live charts, Rembrandt three-quarter lighting from a high window on the left, period-accurate dark doublet with white lace collar, deep shadow background, fine oil paint craquelure visible as if the painting has aged 400 years

"Craquelure" is the network of cracks in aged oil paint. Naming it produces it. GPT-Image-2 understands art conservation vocabulary.

20. Double Exposure / Concept Portrait

Double exposure prompts need to name both visual layers and describe exactly how they interact. The blend is not random — you are directing where one image ends and the other begins.

A double exposure concept portrait, a woman's head and shoulders in sharp silhouette, the interior of the silhouette filled entirely with a dense pine forest scene, the tree line running exactly along her jaw and cheekbones, moonlight visible through the gaps between branches where her eyes would be, a single owl perched on a branch at temple height, cool silver-blue tones throughout, film double exposure technique, precise clean silhouette edge, editorial quality

"The tree line running exactly along her jaw and cheekbones" is directorial instruction. You are telling the model where two things meet. That precision is what separates concept art from a compositional accident.

What actually makes a prompt work

Every prompt here follows the same structure: subject, style, lighting, camera or medium, mood. That order is not arbitrary. It mirrors how a creative brief moves — from what to show, to how it should look, to how it should feel.

GPT-Image-2 responds to specificity at every level. "A woman in Paris" is a direction. "A 32-year-old woman in a belted trench coat on the Rue Crémieux at 7am in late October, overcast diffused daylight, cobblestones wet from overnight rain, Canon 5D Mark IV with a 50mm f/1.2, photojournalism aesthetic" is a brief. The difference in output is not subtle.

A few things I have noticed consistently across all these categories:

The more precisely you describe the light source and its angle, the more control you get over mood. Mood is mostly light. Everything else serves that.

Naming a specific camera, film stock, or real-world photographer signals an entire visual vocabulary in one phrase. "Hasselblad medium format" carries different color, contrast, and tonal assumptions than "Canon 5D."

GPT-Image-2 holds context across conversation turns. Run one of these prompts, then ask for a different angle, a warmer color grade, or a shifted time of day. Each refinement builds on the last. That iterative workflow is where real control lives.

Start with one category that matches something you are already working on. Get one prompt right. Then take what you learned about specificity into the next one.

The model is capable. The limiting factor, almost always, is the brief.

10 AI Tools to Automate Your Social Media (And Make Them Work)

Sun, 03 May 2026 00:00:00 GMT

Most people are still doing social media the hard way.

Writing posts manually. Thinking about captions at 11pm. Forgetting to post for a week. Then scrambling. Then burning out. Then going quiet.

That cycle kills accounts. And it is completely avoidable now.

I have tested most of what is out there. Some I kept. Some I dropped fast. Here is what actually made the cut.

1. Buffer

Buffer has been around for years. The AI they added is simple and it works.

Paste your idea. It writes caption variations. Pick one, tweak if needed, schedule it. Two minutes instead of twenty.

No complicated setup. No 30-tab dashboard. Connect your accounts, set a queue, let it run. If you have not touched any of these tools before, start here.

2. Hootsuite with OwlyWriter

Hootsuite is the older, heavier platform. OwlyWriter is their AI layer on top.

The difference from basic AI writers is context. It pulls from your past posts, trending topics in your category, and suggests angles you did not think of yourself.

Not cheap. But if you are managing multiple client accounts, the math works in your favor quickly.

3. Jasper

Jasper is the right choice when you need volume.

Give it your brand voice and a topic. Posts, threads, LinkedIn content, testing variations. A week of content in about an hour.

The brand voice setup is what most people skip and then complain it sounds generic. Train it with your existing content first. Worth the extra time.

4. Lately

Lately has a different model.

Feed it something long: a blog, a podcast transcript, a recorded call. It finds the shareable moments and turns them into posts. Then it watches what actually performs and adjusts over time.

Most tools do not do that second thing. That second thing is the whole reason to use it.

5. Predis.ai

Predis does text and visuals in the same step.

Give it a product, a topic, or a URL. Caption, image, hashtags, done. The designs are not going to impress anyone. But most accounts that fail are inconsistent, not poorly designed. Predis solves the consistency problem without needing a designer.

6. FeedHive

Most people have not heard of FeedHive. Most people should.

Write something once. FeedHive reposts it on a schedule, slightly varied each time so it does not look like a copy. Write 20 posts. They circulate all year.

The idea that you have to produce new content every day is not a rule. It is a pattern most people follow because nobody told them they did not have to.

7. Taplio

LinkedIn is its own game. The content that works there does not work anywhere else. Taplio is built specifically for that.

Post writing, scheduling, a feed of what is performing in your niche, a lightweight CRM for relationship tracking. The AI understands LinkedIn's tone, which matters more than people expect.

If your clients are on LinkedIn, this belongs in your setup.

8. Ocoya

Ocoya is for product businesses.

Connect your store. It pulls images, descriptions, pricing, writes captions, and schedules the posts. If you have hundreds of products and need to post daily, manual is not a strategy. Manual is a job. Ocoya makes it a setup you do once.

9. ManyChat

ManyChat is not about posting. It is about what happens after posting.

Someone comments. They get a DM with whatever you configured: a link, a discount, a download. Someone messages your page with a question. A flow you built runs automatically. Around the clock, without you.

Most people treat posting as the finish line. It is the starting line. The conversation after is where the conversion happens.

10. Metricool

Every other tool here is about producing content. Metricool is about understanding what that content is actually doing.

Performance across platforms. Best times to post based on real behavior data. Which formats are pulling. Where you are wasting effort.

Most people call what they are doing a strategy. Without data, it is just a posting habit. There is a difference.

The system

The tools are not the hard part. Most people buy the tools and nothing changes.

What changes things is having a system and actually running it.

Write one long piece a week. Blog, newsletter, video. Something with substance.

Run it through Lately or Jasper. You will get ten to fifteen social posts out of one piece.

Predis for anything that needs a visual. Buffer or Hootsuite to schedule the week.

ManyChat flows on anything with a call to action.

Monday morning, Metricool to see what worked.

That is the whole thing. Most of it runs without you after the first setup.

The people who build something like this once stop reinventing their content every week. The people who never build it are still sitting down every Sunday night trying to think of something to post.

AI did not make this easy.

It made the repetitive parts optional.

That is a real difference, if you decide to use it.

Design Systems Die at Month Six. Claude Cowork Is the Fix.

Sun, 03 May 2026 00:00:00 GMT

Most design systems do not die at launch.

They die at month six.

That is when the person who owned it gets pulled into a different feature.

That is when the Figma library starts drifting from the codebase.

That is when "use the design system" turns into "we have a design system, but nobody reads it."

I have shipped design systems for clients. I have seen this pattern play out for almost 14 years across freelance work, agency work, and my own products. The first version is always exciting. New tokens, fresh components, a clean Notion page, a launch announcement in Slack.

Then real work happens.

Designers ship faster than the system can absorb. Engineers paste Tailwind classes that should have been a token. Someone introduces a new shade of grey because the existing one "looked off in the modal." Six months later you have three button components and nobody remembers which one is the official one.

That is not a tooling problem.

That is an operations problem.

And operations is exactly what Claude Cowork was built for.

What Cowork actually is

You give Claude scoped access to specific folders and connectors on your machine. You describe a task. Claude makes a plan, waits for your approval, and then does the work. Sometimes once. Sometimes on a schedule. It opens apps. It pulls data from dashboards. It writes reports. It drops files where you tell it to.

It is not chat.

It is not autocomplete.

It is closer to a junior teammate who never forgets to do the boring stuff.

For a design system, the boring stuff is the entire game.

Token drift is the first thing I would automate

Every design system has tokens. Colors, spacing, radii, type scale, motion durations. The promise is that these live in one place, get exported to code, and stay in sync with Figma.

The reality is that someone always hardcodes a #1a1a1a somewhere. Or pushes a padding: 14px because 12 and 16 both felt wrong. The system slowly leaks.

Set up Cowork to run a weekly scan. Give it read access to your repo folder. Tell it to grep for hex codes, magic-number paddings, and font-size declarations that bypass your tokens. Tell it to drop a report in Google Drive every Friday at 6pm with a summary, the exact files, and the line numbers.

You wake up Saturday morning to a list. Not a vague "code is drifting" feeling. An actual punch list.

That is the difference.

The drift was always happening. Cowork just makes it visible without you having to remember to look.

Component usage is the next blind spot

Most teams have no idea which components are actually being used, which are stale, and which were quietly forked into a one-off variant for a marketing page that shipped 18 months ago.

Cowork can solve this in one scheduled task. Point it at your monorepo. Have it count import statements per component. Have it compare against the public component list on your docs site. Have it flag any component used fewer than five times across the codebase and any one-off variant that is not in the official catalog.

Drop the result into a Slack channel called #design-system-pulse every Monday morning.

Now you have a heartbeat for the system. Your design lead can say "we are deprecating LegacyCard because nothing uses it anymore" and have a real number behind that decision instead of a hunch.

This is the kind of work I never wanted to do manually. I would set out to do it once a quarter and quietly skip it for two quarters in a row.

Cowork does not skip.

Deprecation needs a watcher, not a Notion doc

Every design system I have seen has a "deprecated components" page.

Every one of those pages is out of date.

The fix is not better documentation. The fix is a cron.

I would have Cowork scan the codebase nightly for any imports of components on the deprecated list. The next morning, anyone still importing OldButton gets a Linear ticket auto-generated, with the file path and the suggested replacement. Approval-gated, of course. Cowork shows me the plan, I glance at it on my phone, I tap approve.

That last part matters. Cowork has mobile pairing. You can fire off a task from your phone and the desktop agent continues the work. I would not approve actual file edits from a phone, but I will absolutely approve a plan to file 14 cleanup tickets while I am at the gym.

Onboarding docs are the quiet killer

Every new engineer asks the same question. "Where do I start with the design system?"

Most teams answer by dumping a Notion link that has not been touched since the original maintainer left.

This is a perfect Cowork job. Once a month, point it at your component folder and your Storybook config. Tell it to draft an updated "getting started" doc. Pull live examples from the actual code, not from a stale tutorial. Drop the draft in Drive for the design lead to review.

A draft you edit beats a blank page you procrastinate on.

Every single time.

I have rewritten onboarding docs from scratch four times in my career. If I had Cowork back then, I would have rewritten them maybe once and let the agent handle the refresh after that.

Release notes for the system itself

Design systems ship versions. Most teams forget to write release notes because the people who would write them are the same people shipping the changes.

Cowork can pull a git log between two tags, cross-reference Figma changelog exports if you keep them in Drive, and produce a release note draft. You take it from there.

Cowork is not going to write perfect release notes. What it will do is hand you a half-finished doc on Friday afternoon when you would otherwise be staring at an empty page on Monday morning.

A draft is a starting point. Nothing is just nothing.

This is not about replacing designers or engineers

I know how a post like this reads if you skim it. "AI is going to take over your design system." That is not the argument.

The argument is the opposite.

Designers should be designing. Engineers should be building. The maintenance work, the audits, the digests, the deprecation cleanups, the doc refreshes, the release notes. Those are the things nobody on the team actually wants to own. They are the things that get dropped first when a deadline hits. They are the things that quietly kill a design system over 12 months.

Cowork is good at that exact kind of work. Repeatable. Scoped. Boring. Important.

Use the humans for the parts that need taste.

Use the agent for the parts that need a calendar.

How I would actually start tomorrow

If I were running a small design-system effort right now, here is the exact rollout I would do.

Week one. One scheduled task. Token drift report, Friday 6pm, dropped in Drive. That is it. Get used to the approval flow. Get used to reading the report.

Week two. Add the component usage digest. Slack on Monday morning.

Week three. Add the deprecation watcher. Approval-gated ticket creation.

Week four. Onboarding doc refresh, monthly. Release notes drafting, per-version.

By the end of the month you have a design-system operations layer that runs without anyone losing a day to it. You spend that recovered time on the parts of the system that actually need a human. New patterns. Hard accessibility calls. The motion language. The voice of your error messages.

That is the trade I want to make every week.

The pattern is not new

I keep saying this in different ways across different posts, but it is the same idea every time.

Early adopters do not win because they are smarter.

They win because they recognize when a tool changes the cost of work they were already doing badly.

Design system maintenance is work most teams were already doing badly.

Cowork changes the cost.

Move now, or watch another design system die at month six.

Freelancing Is Not Dead — It's Shifting to AI

Sun, 03 May 2026 00:00:00 GMT

Freelancing did not die suddenly.

It started dying the day people stopped learning and started looking for shortcuts.

I have been in this game for almost 14–15 years.

Most people here know me from Fiverr. I started from zero, became a Top Rated Seller, completed more than 100,000 orders, and generated millions of dollars in revenue over the years.

But before Fiverr, there was another chapter.

Orkut.

Many people today may not even remember it, but at that time Orkut was a massive social platform. I was one of the early adopters. I had communities with huge audiences, millions and millions of users. At that time, I did not fully understand how big that opportunity was, but I understood one thing clearly:

Where attention goes, opportunity follows.

Orkut allowed links in community descriptions, so I created my first blogs, placed those links there, and started getting traffic. That traffic became my first real exposure to online earning, blogging, AdSense, digital marketing, and the internet business world.

That was not luck.

That was early adoption.

Then freelancing platforms started growing. Fiverr came. I joined early, learned the game, adapted, tested, failed, improved, and kept going.

While many people were still asking whether Fiverr was real or fake, I was already building.

While many people were waiting for the "perfect method," I was learning from every order, every client, every mistake, every bad day, and every small win.

That is how a career is built.

Not by shortcuts.

Not by screenshots.

Not by motivational videos.

By adapting before everyone else is comfortable.

Now we are standing at another turning point.

AI is here.

And this time, the shift is much bigger than Orkut, blogging, AdSense, Fiverr, or any freelancing platform.

AI will not just change freelancing.

It will change the meaning of work itself.

I saw this coming early. I knew the old freelancing model would slowly become weaker. Not completely gone overnight, but definitely weaker. The same services people used to pay for blindly will now be done faster, cheaper, and sometimes better with AI.

So I had two choices.

Sit and defend the past.

Or move.

I chose to move.

I started working on micro SaaS ideas, small products, practical tools, private-label ecommerce stores, and projects that solve real problems. Because the future is not about selling your time forever. The future is about building assets, systems, products, brands, and distribution.

And yes, ecommerce is still powerful.

No matter how advanced AI becomes, people will still buy clothes, products, experiences, tools, and solutions. Demand will remain. Only the way we create, market, sell, and operate will change.

That is where the opportunity is.

The people who understand AI as a tool will grow.

The people who treat AI as a threat will complain.

The people who keep asking "what should I do?" but never actually do anything will stay exactly where they are.

And I want to say this honestly.

If you still come to my inbox asking, "bro, what should I start?" or "what should I do now?" without even using AI to explore your own skills, your own market, your own ideas, your own direction, then you are already behind.

Not because you do not know.

Because you are not trying.

Today, you have access to tools that people like us could not even imagine when we started. You can research markets, build websites, write content, create images, analyze competitors, learn skills, build products, automate work, and test ideas faster than ever before.

But still, most people are waiting for someone to hand them a shortcut.

That mindset is the real problem.

The next few years will create a huge gap.

Not between rich and poor.

Not between freelancers and business owners.

But between people who adapt and people who keep repeating old formulas.

I am not saying everyone should quit freelancing.

I am saying freelancing alone is no longer enough.

Learn AI.

Use AI.

Build something.

Create your own products.

Start a small brand.

Solve a small problem.

Build a tool.

Create content.

Learn distribution.

Learn marketing.

Learn how attention works.

Learn how to sell.

Because the future will not reward people who only know how to follow instructions.

It will reward people who can think, adapt, build, and move early.

I have seen this pattern before.

Orkut rewarded early adopters.

Fiverr rewarded early adopters.

AI will reward early adopters too.

The only question is:

Will you move now, or will you wait until everyone else is already ahead?