DEV Community: Agnel Nieves

He Built a Flight Simulator in Three Hours and Hit $1M a Year in 17 Days. Then It Went to Zero.

Agnel Nieves — Wed, 24 Jun 2026 14:31:32 +0000

In February 2025, Pieter Levels typed a sentence into Cursor. "Make a 3d flying game in browser with skyscrapers." Three hours later he had a working flight simulator. He had never made a game in his life.

I went through his last couple hundred posts so you do not have to, and I want to show you both ends of this. The part where it printed money, and the part where it stopped.

The setup

Levels is the indie hacker other indie hackers quote. Dutch, self-taught, builds everything solo in old PHP and runs it on a Hetzner box. His flagship is Photo AI, which trains a model on your selfies and spits out studio-grade portraits.

He posts his revenue. Constantly. That is the unusual thing about him. Most founders post a cropped Stripe screenshot once and disappear. Levels treats his Stripe dashboard like a public weather report.

The moment something worked, fast

The flight sim, fly.pieter.com, was a lark. He shipped it, tagged it as built with Cursor in about three hours, and posted the prompt.

"Today I thought what if I ask Cursor to build a flight simulator So I asked 'make a 3d flying game in browser with skyscrapers' And after many questions and comments from me I now have the official [ Pieter.com Flight Simulator ] in vanilla HTML and JS"

@levelsio on X

It went off. Elon Musk reposted it. The game was free, so the money came from in-game ad slots, branded blimps, and a $29.99 F-16 upgrade. Thirteen days in he posted $67,000 in monthly recurring revenue. Then this.

"fly.pieter.com has now gone from $0 to $1 million ARR in just 17 days! Revenue update: $87,000 MRR (which is $1M ARR) My first project ever to go up this fast"

@levelsio on X

Read that last line carefully, because he did. In the same post he wrote, "Whether the MRR is truly sustainable for a year we can only guess." He flagged the risk himself, in the victory tweet. The rest of the internet ignored that sentence and ran "1M ARR in 17 days" headlines for weeks.

The moment something broke, quietly

Here is the number the headlines never followed up on. As of his live X bio in mid-2026, the flight sim line reads "Pieter.com $0/m."

Zero. The thing that hit $1M ARR in 17 days makes nothing now.

That is not a scandal. It is the actual nature of the revenue. Sponsor slots and one-time jet purchases are not subscriptions that renew. Once the viral moment passed and the ad slots lapsed, the money left with the attention. Levels basically said as much at the peak. The crowd just preferred the clean version.

The product that actually pays the bills

So ignore the game. The durable story is Photo AI, and it is more impressive precisely because it is boring.

In September 2025 he posted a record month.

"Photo AI just reached a new record of $150,000/mo. 2,573 active subscribers. 87% profit margin. 100% bootstrapped + $0 funding. Employees: 1 = just me on my laptop. Tech: PHP + jQuery + SQLite on a Hetzner VPS with Nginx and Ubuntu"

@levelsio on X

One person. An 87% margin. A tech stack that working developers openly mock. When he posted that his code was "almost 14,000 lines of raw PHP mixed with inline HTML," the post pulled millions of views and a small civil war in the replies.

His current X bio lists the portfolio: Photo AI at $100K/m, RemoteOK at $44K/m, Vibej.am at $39K/m, InteriorAI at $35K/m, and a few smaller lines, which puts him in the neighborhood of $245,000 a month across everything as of mid-2026. Notice Photo AI is at $100K there, down from that $150K record. These numbers move around. He is honest that records are usually one good day, not a new floor.

The verdict

Here is the part the "one person, $150K a month" posts leave out, and Levels does not. He did not build an audience in 2025. He built it for a decade. His launches land because hundreds of thousands of people already trust his Stripe screenshots. After the Lex Fridman podcast he posted that sign-ups and revenue across almost all his sites doubled overnight, +93%, and in his $420K-record post he put Photo AI's bump specifically at 3x. That is an input you do not have.

So the copyable lesson is not the three-hour build. AI genuinely compressed that, and that is real. The lesson is the boring middle. Charge from day one. He told PPC Land, "pay me money, pay $10, $20, $40. I would ask more than $10 per month." Ship the fix in two minutes, not two weeks. And know the difference between revenue that renews and revenue that visited once, took a selfie in an F-16, and never came back.

Sources

Getting Your Writing Seen Beyond Your Own Site

Agnel Nieves — Sat, 20 Jun 2026 14:37:18 +0000

Part one of this series covered your own site: llms.txt, structured data, machine-readable feeds, the eight layers that make your pages legible to humans and to the AI agents that increasingly read on their behalf. This piece is about everywhere else.

The mental model is simple. Your site is the canonical home. Everywhere else is a spoke that points back to it. Spokes get you seen. The hub gets the credit. If you mix that up, you spend a year writing for someone else's audience and ranking for someone else's domain.

I just finished wiring this distribution stack on Promptway, the site you are reading. Here is what I built, in the order I would build it again, and why each layer matters.

Start with full content feeds

Most blogs ship a summary-only RSS feed by default. That is fine if RSS is just an archive ping for a few Feedly subscribers. It is a real problem the moment you want to syndicate.

Every downstream channel that consumes your feed reads from it directly. dev.to's RSS importer, Flipboard magazines, Feedly previews, AI ingestion bots, every one of them pulls the article body out of the feed. If your feed has a summary, that is all they get. They cannot republish a full article from a 200 character teaser, so they either skip you or post a fragment that is useless to anyone who finds it.

The fix is one feed change. In RSS, add <content:encoded> with the full rendered HTML of the article wrapped in CDATA. In JSON Feed, populate content_html. Keep the short description or summary field for clients that want a preview. While you are in there, add <atom:link rel="self"> so the feed is self-aware, a <link rel="hub"> pointing at a WebSub hub, and a <media:content> block with your hero image so cards render with art.

This is the foundation. Nothing else in this article works as well if the feed is summary-only.

Push, do not wait to be pulled

Crawlers used to be the only way new URLs got noticed. That is no longer true. There is a faster path for everything except Google, and it costs you one HTTP POST.

IndexNow is a small open protocol that lets you tell search engines about a new or updated URL the instant it ships. You generate a key, serve it from your domain as a static file, and POST your URLs to https://api.indexnow.org/indexnow. One submission propagates to Bing, Yandex, Seznam, and Naver. Google is not a participant.

Bing matters double. Seer Interactive's analysis found that roughly 87% of ChatGPT search citations overlap with Bing's top ten results. The fastest path into ChatGPT citations is being indexed by Bing the moment you publish, not three weeks later when its crawler eventually wanders in.

WebSub does the same thing for feed readers. Add a <link rel="hub"> to your RSS, then POST to the hub when you publish. Feedly, Inoreader, and similar readers subscribed to the hub get notified in seconds instead of on their normal polling interval. Google retired its hosted hub but Superfeedr's free hub still works fine for low volume publishers.

Both of these belong in your publish pipeline as one or two function calls. They are the highest-return two minutes of distribution work you will ever do.

Syndicate with canonicals, always

The standard objection to cross-posting is duplicate content. The fix is older than the problem. Every copy of your article on someone else's domain declares a rel="canonical" link back to your version, plus a visible "originally published at" line for human readers. Google has said for years that canonical syndication is fine, and dev.to, Medium, and Hashnode all support it natively.

The targets worth the effort, in roughly this order:

dev.to has an open API. Create an organization page, generate an API key, and POST /api/articles with canonical_url set to your version and organization_id set to your org. Their RSS importer also works if you would rather skip the code path. Dev.to's audience reads new posts, and the engagement signals roll up to your domain via the canonical.
Hashnode has an RSS importer that respects canonicals. Their free GraphQL API reportedly went paid in May 2026, so prefer the RSS path unless you are already on a paid plan.
Flipboard has been courting indie publishers in 2026, but the self-serve RSS pipe into magazines is gone, the help article for it now returns a 404. What works today: create a magazine, flip your own articles into it by URL, mix in third-party links so it reads like a magazine instead of a billboard, and email contentpartnerships@flipboard.com with your feed URL if you want true source-level ingestion.
Medium has an import flow per article that sets the canonical automatically. Their write API has been closed to new tokens since early 2025, so this is a manual step. Code blocks import poorly. Use it opportunistically for essay-style pieces.

The rule across all of them: never let a syndicated copy live without a canonical pointing home. If a partner's CMS does not support rel="canonical", do not syndicate there.

Social, with realistic expectations

The honest truth about social in 2026 is that the only platform where automation is a clear win for indie publishers is Bluesky. The rest are either too expensive, too restricted, or too judgment-heavy to automate.

Bluesky lets you claim a domain handle for free by adding a DNS TXT record. Claim your domain as the handle, @promptway.com in our case, for the same reason browsers show a padlock: the domain is the verification. The AT Protocol API is free and open, so a publish-time post is a few lines of code with an app password. EchoFeed at about $25 a year will do it for you from your RSS if you do not want to write the code.

LinkedIn is where the operator audience actually reads, especially for AEO and stack-of-tools pieces. Skip their API, which has a restricted approval process you will not pass as an indie. Post manually, or pipe through a tool like Typefully or Buffer. LinkedIn newsletters push to subscribers via email and notifications, which sidesteps the feed algorithm. Worth setting up once you are publishing weekly.

X is a poor investment in 2026. The free API tier is closed to new developers, and in April 2026 URL-containing posts were repriced to roughly $0.20 each on the paid tiers. Keep the account, post important pieces by hand, and put the automation budget anywhere else.

Email is the channel you actually own

Every platform above can change its rules, throttle your reach, or close its API tomorrow. Email cannot. It is the only channel where you own the list and the delivery mechanism.

Two practical pieces. First, you need a transactional sender that can do broadcasts. I use Resend because the API is good, the React Email integration is good, and the dashboard is sane. Postmark and AWS SES work fine too. Second, on every publish, send a broadcast to your audience. This is the closest thing you have to a guaranteed reader.

Do not skip RFC 8058 one-click unsubscribe. Gmail and Yahoo require it for any sender with a meaningful list, and inbox placement gets worse fast without it. Resend handles the headers if you use their broadcasts API; if you roll your own, add List-Unsubscribe and List-Unsubscribe-Post headers and honor the POST.

A welcome email on signup is a nice touch and roughly doubles the chance a subscriber remembers who you are by the time the next broadcast arrives.

The channels that cannot be automated

Some of the highest-value surfaces are also the ones where automation will get you banned, downranked, or quietly ignored. They are worth doing, but they are human work.

Reddit is the biggest of these. Research from ZipTie found Reddit is the most cited domain in Perplexity, near the top in ChatGPT search, and a dominant source in Google's AI Overviews. The dynamic is straightforward: AI engines treat Reddit as a corpus of authentic human discussion, and they pull from it heavily. A single relevant comment with a link to your piece can drive more AI citations than a month of feed syndication.

The catch is that Reddit kills self-promotion on sight. Two to four weeks of genuine participation in a subreddit before you ever post a link is the floor. Read the rules of each sub, the old sitewide 90/10 self-promo rule is retired and each subreddit governs itself now. Text posts that lead with the insight and link out as a citation tend to do better than link posts.

Hacker News is the other one. It rewards founder-bylined essays with plain factual titles and punishes anything that smells like marketing or AI prose. If you have personas writing on your site, post only the pieces under your own name and from an account that comments on other people's submissions too. Do not submit your own work every week.

These are slow channels. They are also where the citation flywheel actually spins.

Automate the mechanical, keep judgment human

The split is the whole game. The mechanical work (indexing, syndication, broadcast, the Bluesky post) belongs in a script that runs on publish. The judgment work (which subreddit, when to post to HN, which LinkedIn comment to respond to) stays with you.

My setup is a single distribute.ts script that GitHub Actions runs after the deploy succeeds. It hits IndexNow, pings the WebSub hub, posts to dev.to via API, sends the Resend broadcast, and posts to Bluesky and Mastodon with the hero art, an author tag, and hashtags. It writes a row to a committed ledger file so re-runs are idempotent. Total code, about a thousand lines, and most of that is per-channel error handling so one flaky API never blocks the rest.

The matching human side is a 15 minute per-article checklist: request indexing in Google Search Console, share-rail posts, one relevant subreddit if it genuinely fits, Medium import. Fifteen minutes is short enough that I actually do it.

Measure what is actually working

The headline number to track is not pageviews. It is AI referrals.

In GA4, build a custom channel group that captures the referrers worth knowing about: chatgpt.com, perplexity.ai, claude.ai, gemini.google.com. Industry data puts AI referrals around 1% of pageviews for most publishers, but they convert at multiples of organic search traffic. They are small, high-intent visits from people whose AI assistant has already vouched for you.

The other dashboards: Google Search Console for indexed pages and impressions, Bing Webmaster Tools for the IndexNow side, Resend for audience growth per broadcast, dev.to organization analytics for the syndicated reach. Look weekly, not daily. None of this moves fast.

The shape of it

The whole stack, in one breath: ship full content feeds, fire IndexNow and WebSub on publish, syndicate with canonicals, post to Bluesky and LinkedIn, email your list, participate honestly on Reddit and Hacker News, and watch the AI referrer channel quietly grow.

Most of it is one-time setup. The publish pipeline runs itself once it is wired. The human channels stay human. The site stays canonical.

The point is not to be everywhere. It is to make sure that when a human or an AI engine wants to find your work, every spoke they touch sends them back to the same place: your domain, your byline, your archive.

That is what gets your writing seen.

He Made $189,000 in Profit in a Single Month, Then Sold the Whole Thing to Wix for $80 Million. Six Months In.

Agnel Nieves — Tue, 16 Jun 2026 15:33:40 +0000

The lawyers finished the Base44 paperwork on a Thursday night. The signing was set for Friday morning. That same Friday morning, the war with Iran broke out. Maor Shlomo signed anyway.

That detail is the whole story in miniature. A guy in Israel, between reserve duty call-ups, sells a company he started as a side project, and the missiles are a scheduling problem.

The setup

Shlomo was not a kid with a dream and a laptop. He had already co-founded Explorium, a data analytics company that raised a total of $127 million, capped by a $75 million Series C led by Insight Partners, per TechCrunch. He left, did reserve duty after October 7, and came back restless.

Base44 started because his girlfriend needed a website for her art business and he was helping the Israeli Scouts with some software. He kept hitting the same wall. As he told CEO Insider, "Both times I realized, 'LLMs should be able to build this.'"

So he built the thing that builds the thing. Base44 turns a plain-English prompt into a working web app, database and login and all. No code.

The moment something worked

Here is where the numbers start, and they are silly.

He told his girlfriend that if they hit $1.5M in annual recurring revenue by the end of 2025, they would buy a nice car. They hit it in four weeks. He said this out loud on Lenny's Podcast, the same place he confirmed he hit $1 million ARR three weeks after launch and grew to more than 400,000 users without spending money on marketing.

Ten thousand users showed up in the first three weeks. By the six-month mark he was reportedly at 250,000 users, per TechCrunch.

Then the profit number. In May 2025, Base44 made $189,000 in profit. Not revenue, profit. Shlomo posted it himself on LinkedIn, and the figure got passed around the founder world fast.

"Base44 ended up making $189K profit in May and today got acquired by Wix for $80m..."

@PrivatEquityGuy on X

Per Calcalist, "Shlomo reported that the company had generated a profit of $189,000, nearly double his initial forecast of $100,000." I want to flag what that profit survived, because it is the part that almost broke him.

The moment something almost broke

Base44 calls large language models to generate full apps in real time. Every single request costs money. In May, model calls were 89% of Base44's total spend, according to a detailed breakdown via 36Kr of his public posts.

That is a business where the cost of goods sold tries to eat you alive. Shlomo's fix was unglamorous. He moved off OpenAI's API to cheaper routes through AWS Bedrock, Google Vertex, and Anthropic, chasing cost-per-performance. He also stopped charging users for failed outputs, which sounds generous until you realize a model that keeps making mistakes just burns more tokens on his dime.

He leaned on Cursor and Claude for development. He said on Lenny's that he had not written a line of front-end code in three months. The AI wrote it. He architected.

The verdict, with the asterisks

In June 2025, Wix bought Base44 for $80 million in cash, with earn-outs running through 2029.

Now the honesty section, because the clean version of this story is a lie of omission.

First, "solo" is doing heavy lifting. Wix confirmed to TechCrunch that Base44 had eight employees at the sale, and $25 million of the $80 million was a retention pool for them. Shlomo ran it alone for most of the six months and hired his first employee about six weeks before the deal, but the word "solo" on the marketing materials is a stretch by the finish line.

Second, the Explorium history matters more than the takes admit. A first-time nobody does not get a warm introduction to Wix's CEO. Shlomo was already known in Israeli tech, he was named to Forbes Israel's 30 Under 30 in 2020, and that network is a real input that you cannot copy by using Cursor.

Third, and this is the uncomfortable one for anyone treating the $80 million as the moral of the story. The acquisition has been rough on the acquirer. Base44 hit $100 million ARR nine months after the deal, per Calcalist, which is genuinely wild growth. But Calcalist also reports Wix's stock has lost nearly half its value in 2026, and that Base44's compute and marketing costs are a heavy drag on the company that bought it. The thing grows beautifully and bleeds cash at the same time. Both are true.

For Shlomo personally, it kept paying. Calcalist reports he is set to receive another $90 million if milestones hit, on top of the headline price.

So what is the actual lesson here. It is not "quit and vibe-code an $80 million exit by Friday." It is narrower and more useful. He picked a problem he personally had, twice. He shipped while it was embarrassing and broke often. He watched real users in real time and removed friction. And he understood his cost structure cold, which is the part most AI founders wave away until the GPU bill arrives and the math stops working.

He told Lenny something that has stuck with me. The best product feedback at $5M ARR was the same as at $150M ARR. People close to you, who feel comfortable telling you the truth. The tooling changed. That part did not.

Sources

From Invisible to Indexed: The Unglamorous Work of Getting Seen by AI Search

Agnel Nieves — Mon, 15 Jun 2026 20:55:43 +0000

Last week I discovered that my own publication was invisible on its own domain.

Not invisible in the poetic, nobody-reads-my-blog way. Literally invisible. promptway.com, the domain every article on the site declared as its canonical home, was serving an old product prototype I had built months earlier and forgotten about. The actual publication lived on a temporary platform URL. Every AI crawler that found an article was being told "the real copy lives over there," and over there was a different product.

I had written a whole piece about optimizing your site for AI agents and LLMs. The eight layers in that article were all real and all working. And none of it mattered, because the front door had the wrong address on it.

So I spent a day fixing the unglamorous parts. This is the checklist, in plain words. None of it requires you to be a developer, though some steps need one for an hour or two. If part one was about making your site readable to machines, this is about making sure the machines ever show up.

Step 0: check what your domain actually serves

Open a private browser window and type your domain. Not your bookmark. The domain.

Then check three URLs by hand: yourdomain.com/sitemap.xml, yourdomain.com/feed.xml, and yourdomain.com/robots.txt. If any of them 404, that is your whole afternoon right there. Mine did. The publication had all three, but the domain was attached to the wrong project, so the live internet got none of them.

While you are in there, settle the www question. Pick one form of your domain, either yourdomain.com or www.yourdomain.com, and make the other one redirect to it permanently. Search engines treat them as two different sites until you do. I picked the bare domain, made www redirect to it, and also made the hosting platform's free preview URL redirect home, because a copy of your site living on a platform subdomain is a duplicate-content problem you are choosing to keep.

Step 1: let the right robots in

Your robots.txt file is the bouncer at the door. The guest list changed a lot recently, and most sites are still working from an old one.

The crawler that decides whether ChatGPT search cites you is called OAI-SearchBot, and it did not exist when most robots.txt files were written. Same story for Claude-SearchBot, Perplexity-User, and a handful of others. If your file does not mention them, you are relying on default behavior. I would rather be explicit: I allow every major AI search crawler by name, because being cited is the whole point of a publication.

This is a ten-minute edit. Ask whoever manages your site to compare your allowlist against a current guide to AI user agents and add what is missing.

Step 2: put your whole article in the feed

Here is one I had completely wrong. My RSS feed only carried summaries.

A summary-only feed feels safe, like you are protecting the full text. What it actually does is cripple every downstream channel. Feed readers show your readers a teaser and a link. Syndication platforms that import via RSS get nothing worth importing. AI systems that ingest feeds get a paragraph instead of the article.

Full-content feeds are how machines subscribe to you. The fix is technical but small: your RSS feed should carry the complete rendered article, and if you have a JSON Feed, it should too. Your developer will know this as content:encoded. The conversation takes one sentence: "make our feeds full-content."

Step 3: tell the engines when you publish, do not wait to be found

By default, publishing works like this: you post, and then you wait for a crawler to wander by. That can take days.

Two free standards flip it to a push model. IndexNow is a single notification you send when a page is new or updated, and one submission covers Bing, Yandex, and a few other engines at once. Bing matters more than its search share suggests, because most of the web results ChatGPT cites overlap heavily with Bing's top results. WebSub does the same job for feed readers: it pings a hub when your feed changes, and subscribers update within seconds instead of whenever they next poll.

Both are set-and-forget. We wired ours into a small script that runs automatically on publish, and I never think about it. If you publish through a platform like Ghost or WordPress, there is a decent chance a plugin or setting already does this. Turn it on.

Step 4: put a human name on AI-assisted work

Some of the writing on Promptway is drafted by AI personas. That is disclosed openly, profile pages and all. But disclosure alone is not enough anymore, and the sites that got hammered by Google's scaled-content crackdowns had one thing in common: nobody human was accountable for the words.

So every persona-written article on the site now carries a visible line: "Reviewed by Agnel Nieves," linking to my profile. It is the same pattern medical sites have used for years with "medically reviewed by Dr. X." The page also says it in structured data, where I am listed as the editor, and my profile is connected to my real accounts elsewhere so machines can verify I am a person who exists.

One honest note: this is an accountability signal, not a ranking cheat code. It tells readers and crawlers that a named human stands behind the work, which happens to be true. If it were not true, I would fix that first.

Step 5: never ship a blank share card

Paste one of your article links into Slack or iMessage. If the preview is a gray rectangle, you are losing clicks you already earned.

Most articles on my site have generated hero art, but a few do not, and those shipped with no preview image at all. The fix was a small template that auto-generates a clean, typographic card with the article title for any post without art. Every link now unfurls into something. Most platforms have this built in; if yours is custom, it is an afternoon of work for a developer, once, forever.

Step 6: measure the AI traffic separately

Here is the stat that convinced me to finally set up analytics: visitors arriving from AI tools like ChatGPT and Perplexity are a tiny slice of traffic, around one percent industry-wide, but they convert far better than organic search visitors. Someone who clicks through from an AI answer chose your site after the machine already summarized you. That is a warm lead, not a drive-by.

If you lump that traffic in with everything else, you will never see it. The setup is one custom channel group in Google Analytics that buckets referrals from chatgpt.com, perplexity.ai, claude.ai, and gemini.google.com. Ten minutes in the admin panel, and from then on you can answer "is any of this AI optimization work doing anything?" with a number.

The part where I admit a fleet of agents did the typing

Full transparency: I did not hand-write most of this. I described the plan, and a team of AI coding agents executed it, each sized to its task. Small models refreshed the robots file and the redirects. Bigger ones rebuilt the feeds and wrote the publish-time automation. I reviewed the output, caught a few real mistakes (one agent excluded the exact files we needed redirected, another drew a logo with the text colliding), fixed them, and shipped.

That division of labor felt right. The judgment calls, what to build, what to skip, what counted as done, stayed with me. The typing did not have to.

The whole checklist, one more time

Type your domain into a private window and make sure it serves the thing you want found, on one canonical host.
Check sitemap.xml, feed.xml, and robots.txt by hand. Fix the 404s.
Update your robots.txt allowlist for the 2026 crawler landscape.
Make your feeds full-content.
Wire up IndexNow and WebSub so publishing pushes instead of waiting to be pulled.
Put a named, linkable human reviewer on anything AI-assisted.
Generate a fallback share image so no link ever unfurls blank.
Build an AI-referrals channel group in your analytics.

None of this is clever. That is the point. The clever work, the writing, the structured data, the llms.txt file, only pays off after the plumbing is sound. Check the front door first.

The De-Slop Prompt Stack: Six Prompts That Stop Claude and ChatGPT From Sounding Like a Robot

Agnel Nieves — Mon, 15 Jun 2026 20:55:42 +0000

Merriam-Webster's 2025 word of the year wasn't a tech term that crossed over. It was an insult. Slop: roughly, low-quality digital content churned out in volume by AI.

When the dictionary names the thing your content pipeline produces by default, that's worth twenty minutes of your attention. Here are the twenty minutes.

The trust penalty is measurable now

Canva's State of Marketing and AI 2026 report, a Harris Poll of 1,415 marketing leaders and 3,547 consumers across seven countries released in May, found that 97% of marketing leaders now use AI daily. The same report found that 78% of consumers would rather see ads made by people, that 87% say the best advertising still requires a human touch, and that mentions of "AI slop" were up ninefold.

Bynder's Human Touch survey of 2,000 UK and US consumers adds the twist. 52% said they get less engaged the moment they suspect copy is AI-written. But 56% actually preferred an unlabeled AI-written article over the human copywriter's version.

Read those two Bynder numbers together. People can't reliably detect good AI writing. They reliably punish detectable AI writing. The penalty isn't for using the tool. It's for the tells.

So the job is simple to state: remove the tells.

The tells, so you can delete them on sight

Before the prompts, the symptom list. Machine-default writing is recognizable because it always fails the same ways:

Metronome rhythm. Every sentence runs 15 to 20 words, forever.
The connector parade: furthermore, moreover, additionally, consequently.
Giveaway vocabulary: delve, tapestry, landscape, elevate, crucial, robust, journey.
"It's not just X. It's Y." Fine once. A tell when it's every third paragraph.
Threes. Everything arrives in threes.
Confident claims with no source attached.
Em dashes every other sentence. We ban them at Promptway entirely, and the models adore them.

No single item proves anything. Stacked together, they're the smell. The six prompts below kill them at the source.

The stack

The first three are setup prompts. Run them before drafting, or better, save them permanently (instructions at the end). The last three are editing passes you run on a finished draft.

1. The rhythm and banned-words prompt

The two loudest tells are vocabulary and rhythm, so handle both in one standing instruction:

# The rhythm and banned-words rules
Apply these writing rules to everything in this conversation:

Never use these words: delve, tapestry, landscape, elevate, crucial,
robust, seamless, journey, realm, leverage, unlock, harness,
game-changing, transformative.

Never open with "In today's" or "In the world of."

No "furthermore," "moreover," "additionally," or "consequently."
Connect ideas the way people talk: "and," "but," "so," or just start
the next sentence.

No em dashes anywhere. Use a period, a comma, or parentheses.

Vary sentence length on purpose. Some sentences under six words.
Some over twenty. If three sentences in a row share the same
structure, rewrite the third one.

Maximum one exclamation point per piece. Prefer zero.

Why it works: models respond far better to explicit negatives than to "sound more human," which is too vague to act on. What goes wrong: in long conversations the rules drift. Repaste them, or save them permanently so you never have to.

2. The voice transplant

The default model voice is generic-competent, which means it belongs to nobody. Give it yours:

# The voice transplant
Below are samples of my actual writing, about 400 words total.
Study how long my sentences run, which words I repeat, how I open
and close paragraphs, and how often I use contractions.

[PASTE 300 TO 500 WORDS OF YOUR OWN WRITING]

Write the piece I describe next in that voice. Do not reuse my
sentences or my topics. Match the rhythm and the vocabulary level.
If you are not sure whether I would say a phrase, leave it out.

Use writing you produced without trying to impress anyone. Emails to colleagues work better than your polished blog posts. What goes wrong: a sample under 200 words produces a caricature instead of a voice. And the last line matters, because "leave it out" stops the model from filling gaps with its defaults.

3. The coffee test

Our writing guide's oldest rule is to read every draft out loud. This prompt builds the rule into the machine:

# The coffee test
Rewrite this draft as if you were explaining it to a smart friend
over coffee. Contractions are fine. Sentence fragments are fine.
Keep every fact. Cut every sentence that sounds like a press
release. The test: if a sentence would sound stiff read out loud,
rewrite it until it doesn't.

This one earns its spot on tone alone. It converts announcements into explanations, which is most of what "sounding human" means.

4. The specificity pass

Vagueness is slop's natural register, and it's also where AI writing quietly lies. This pass fixes both:

# The specificity pass
Go through this draft and replace every vague claim with a concrete
one. "Saves time" becomes a number of minutes or hours. "Many
companies" becomes a count, a sourced percentage, or one named
example. "Recently" becomes a month and a year.

Important: if you do not have the real specific, do not invent one.
Write [NEED SPECIFIC] in its place so I can fill it in myself.

The [NEED SPECIFIC] line is the load-bearing part. Demand specifics without it and the model will manufacture them. A marked gap is useful. An invented number is a liability with your name on it.

5. The honest objection

Human writing argues with itself a little. Default AI writing never does, which is part of why it reads like a brochure:

# The honest objection
Find the weakest claim in this draft. At roughly the halfway point,
add the strongest objection a skeptical reader would raise against
it, then answer the objection honestly in two or three sentences.
If the objection partly wins, concede that part. Do not strawman
the reader.

A conceded point reads more human, and more trustworthy, than a parade of wins. It also forces you to know which of your claims is the weak one, which is worth knowing before your readers find it for you.

6. The true-anecdote opener

Nothing reads more human than a real, specific moment. Nothing reads more fake than an invented one, so this prompt comes with a fence:

# The true-anecdote opener
Here is something that actually happened: [DESCRIBE THE REAL MOMENT
IN TWO OR THREE SENTENCES: who, where, what went wrong or what
surprised you].

Open the piece with a short scene built only from those details.
Do not add details I did not give you. Keep the scene under 80
words, then move into the main point.

Ask a model for "an engaging opening story" and you get confident fiction. Feed it a real moment and restrict it to that moment, and you get the one thing slop can never fake: something that happened.

Save it once, stop repasting

Don't run this by hand every morning. Prompts 1 through 3 belong in your standing instructions: custom instructions or a Project in ChatGPT, and your project's custom instructions in Claude. Every new chat then starts with your rules and your voice already loaded. Prompts 4 through 6 work best as an editing pass you run on finished drafts before anything ships.

This is the same logic as putting your constraints at the top of the prompt: the rules you cannot afford to lose should be the first thing the model reads, every time, without you having to remember them.

Total setup time is about fifteen minutes, once.

What these prompts will not do

They fix tone. They do not fix truth.

A model can produce a beautifully rhythmic, perfectly voice-matched paragraph built around a wrong number. Verify every figure, name, date, and quote before you ship, every time. Slop that's also wrong is worse than slop.

And keep humans on the pieces where the reader needs to feel a person on the other end: the apology, the crisis note, the founder letter. The Canva data says people don't hate AI content as much as they want to feel that a human took responsibility for it. On some pieces, that feeling is the content.

The point was never the detector

AI detectors are coin flips anyway, so fooling them was never a goal worth having. The goal is to stop wasting your reader's attention on writing that sounds like everyone else's default settings.

Run the stack, then read the draft out loud. If it sounds like a person, ship it.

Rust Owns the JavaScript Toolchain in 2026

Agnel Nieves — Thu, 14 May 2026 00:00:00 +0000

TL;DR

If you are shipping a modern JavaScript app in 2026, almost every step between your editor and your production bundle is a Rust binary. Next.js builds with Turbopack. Vite builds with Rolldown. Your linter and formatter are Biome or oxlint. Your CSS pipeline runs through Lightning CSS. Bun, the runtime that started in Zig, just merged its Rust rewrite into main. The result: bundlers are 5 to 30x faster, linters are 50 to 100x faster, and the dependency tree of "the JavaScript toolchain" has collapsed to a handful of statically linked binaries with zero npm postinstall scripts. That last detail matters more than it sounds, because the npm supply chain spent the last 18 months getting set on fire.

Why I'm writing this

I noticed it in pieces. I shipped a terminal portfolio over SSH in Rust two weeks ago, and the build pipeline felt like a different planet to anything I had touched in Node years ago. Then Next.js 16 went stable with Turbopack as the default. Then Vite 8 shipped with Rolldown. Then Anthropic merged a Zig-to-Rust port of Bun, mostly written with AI. Then a fresh Mini Shai-Hulud wave hit TanStack, Mistral, and 160+ npm packages three days ago, on the heels of a November Shai-Hulud campaign that compromised roughly 25,000 GitHub repos. "Small dependency" is now a polite phrase for "unsandboxed code with full filesystem access."

Three threads, one direction. Worth writing down.

I am late to this take. Lee Robinson wrote "Rust Is Eating JavaScript" and the 2026 update made the bigger point cleanly. The angles I want to add are mobile and security, because the toolchain story is only the first act.

The toolchain went Rust

Pick a step in the build pipeline and chances are it has been quietly rewritten in Rust.

Turbopack. Next.js 16 (February 2026) shipped Turbopack as the default bundler for both next dev and next build. The numbers Vercel published before the cutover: more than half of all dev sessions and more than a fifth of production builds were already on Turbopack via 15.3+. After the default flipped, the 16.2 release in April claimed roughly 87% faster dev startup on real apps. The HMR feels different. I had stopped noticing how often I was alt-tabbing during compiles, and after switching I noticed how often I was not.

Rolldown. Vite 8 shipped on March 12, 2026 with Rolldown as the bundler, taking over from the Rollup plus esbuild combination. Public production numbers from the Rolldown team: Excalidraw dropped from 22.9s to 1.4s. PLAID, an internal product at ByteDance, dropped from 80s to 5s. Both are roughly 16x. The transitional rolldown-vite package was archived a week after 8.0 because it was redundant. If you npm create vite@latest today, you get Rolldown without asking for it.

Rspack. ByteDance's webpack-compatible Rust bundler hit 1.7 in January and is on the runway to 2.0. Internally they ship TikTok, Douyin, Lark, and Coze on it. Externally, Microsoft, Amazon, and Discord are in the public adopter list. The migration cases I have seen all land in the same neighborhood: 9x faster cold dev, 3x less memory, prod builds under 4 seconds on apps that used to take 30.

Biome and oxlint. ESLint is no longer the default lint stack. Biome 2 added type-aware rules that do not require running the TypeScript compiler. Oxlint 1.0 went stable in August, ran 50 to 100x faster than ESLint on the same rulesets, and shipped a type-aware alpha in March on top of tsgolint (which itself runs on Microsoft's Go-based tsgo). Shopify reported a 71% lint-time reduction across an ~80,000 file TypeScript codebase. The pattern teams actually use: oxlint as a pre-commit and CI gate for the hot rules, Biome for formatting, ESLint kept around for any plugin you cannot get rid of yet.

Lightning CSS. Tailwind v4's "Oxide" engine is Lightning CSS underneath. Full builds 5x faster, incremental builds up to 100x. The PostCSS chain is gone from the default setup.

Bun. Bun was a Zig project. In May, Anthropic (which acquired Bun last year and uses it inside Claude Code) merged a port of the entire codebase from Zig to Rust into main. The port is roughly 966,000 lines, it was largely AI-assisted, and it passes 99.8% of the existing test suite on Linux x64 glibc. Bun 1.3.14 is positioned as the last Zig release. The reasons given: Rust's memory safety story, and Zig's no-AI contribution policy clashing with how Anthropic builds tooling.

Deno and Node. Deno's core was always Rust, and the 2.6 release in December bumped V8 to 14.2, added dx to replace npx, and started using tsgo for type checking. Node 25.2 (November 2025) shipped stable TypeScript support through Amaro 1.0, which is a wrapper around @swc/wasm-typescript. Node's official type-stripping path is now SWC compiled to WebAssembly, shipping inside core. There is more Rust running inside node than most teams realize.

If you list the build steps in your CI pipeline (lint, format, type check, transpile, bundle, minify, optimize CSS) the only step still being done by JavaScript on JavaScript code in 2026 is type checking. And the most consequential type checker (Microsoft's official one) is being ported to Go, not Rust, by the team that wrote TypeScript in the first place. That is the one part of the ecosystem where the obvious "rewrite it in Rust" bet did not pay off, and it is worth saying out loud.

Bigger than dev tools

This is bigger than JavaScript. Microsoft has publicly committed to embracing Rust across Azure infrastructure, and Azure CTO Mark Russinovich has spent the last two years telling every conference audience that new kernel development at Microsoft should stop using C or C++. New code for Windows and Azure should be written in Rust. That is not a future commitment. Production components already moved: parts of Win32k.sys, Hyper-V, the SymCrypt cryptographic library, and Azure Data Explorer. The Azure SDK for Rust shipped beta in February 2025 and now releases monthly alongside the other language SDKs. At RustConf 2025, Microsoft's Galen Hunt described the broader internal goal as refactoring roughly one million lines of code per month for the rest of the decade, with the aim of eliminating C and C++ from Microsoft's codebase by 2030.

The Linux kernel has merged Rust drivers since 6.1 (late 2022) and the Rust-for-Linux subsystem keeps growing each release. AWS rewrote Firecracker, its microVM monitor, in Rust years ago and continues to add Rust services across the stack. Google has Rust in Android, in parts of Chromium, and in Fuchsia. When the kernel your build tools run on is moving to Rust, the build tools moving to Rust is the predictable next step.

What about mobile

Mobile is a different shape and Rust shows up differently.

The default cross-platform stacks (React Native, Flutter) are not Rust. React Native's New Architecture (Fabric, TurboModules, JSI) is C++. Hermes is C++. Flutter is Dart plus C++. What changed in the last 18 months is the layer just above that: Rust as a shared core, exposed to those frameworks through binding generators.

The pattern teams actually use: write the things that should not be rewritten twice in Rust, and put a thin native UI on top of them.

Signal does this with libsignal. The protocol, AES-GCM and other primitives, zero-knowledge groups, and remote attestation are all Rust crates. Java, Swift, and TypeScript wrappers expose them to Android, iOS, and Desktop.
1Password rewrote its core (sync, storage, crypto, permissions) in Rust, kept native UI per platform, and built TypeShare so type definitions stay consistent across the FFI boundary. One Rust core, eight clients on top.
Mozilla ships sync, login storage, browsing history, push, and experimentation as Rust components shared between Firefox iOS and Firefox Android, all generated through UniFFI.
Cloudflare ships BoringTun, a userspace WireGuard implementation in Rust, on millions of consumer iOS and Android devices through Mozilla VPN and others.
Bitwarden is moving its cryptographic operations into a shared bitwarden_core Rust SDK consumed by every client.

The new bit, and the reason this thread is worth pulling on right now: in December 2024 Mozilla and Filament released Uniffi for React Native. It generates a TurboModule (TypeScript plus the JSI C++ glue) directly from a Rust crate and a UniFFI interface definition. That finally aligns React Native with the pattern Signal and 1Password have been using productively for years. Flutter has had flutter_rust_bridge doing the same job for a while, and v2 is now an officially Flutter Favorite package with async Rust support, web targets, and zero-copy big arrays.

The Rust-native UI frameworks (Dioxus, Slint, egui) are real and improving. Slint added an iOS tech preview in 1.12 last June, with proper Xcode integration, simulator and device deploy, TestFlight, and App Store publishing. Dioxus 0.7 runs on iOS reasonably well and on Android with some pain (Huawei and Airbus are public production references). None of these are what I would reach for to build a polished consumer app today, but the trade is no longer "no Rust GUI on phones." It is "yes, but you should know what you are signing up for."

The honest tradeoffs on mobile have not gone away.

Toolchain pain. NDK plus cargo-ndk for Android. Xcode, codesigning, provisioning, and a sometimes fragile lipo/XCFramework dance for iOS. Every Rust target multiplies your CI matrix.
String impedance. Rust is UTF-8, Swift is UTF-16, Java/Kotlin is "modified UTF-8." Conversions are easy to get wrong, and "wrong" means corruption or crashes.
FFI overhead is real. The well-worn guidance: batch your calls. One call processing 100 items beats 100 calls processing one.
Binary size. A naive Rust core can add MB to your IPA or APK before optimization. LTO, panic=abort, and symbol stripping are the price of entry.
Platform API drift. Widgets, App Intents, Live Activities, Material You, and the latest media APIs almost always live outside the Rust core, in native code. Apple and Google ship features faster than any binding generator can chase.

The takeaway for mobile is the same as on the desktop side: Rust as a shared core works. Rust as the whole app on mobile is niche.

And then there is npm

This is the part of the story I do not think gets told enough.

The last 18 months were brutal for the npm registry. Three events worth grounding the rest of this on:

September 8, 2025: qix / chalk + debug. A maintainer named Josh Junon (handle qix) owns some of the most foundational packages in JavaScript: chalk, debug, ansi-styles, strip-ansi, color-convert, and a dozen more. He received a phishing email from support@npmjs.help, a lookalike domain registered three days earlier. The attacker captured his credentials and TOTP through an adversary-in-the-middle session and published malicious versions of 18 packages with combined weekly downloads of roughly 2 billion. Exiger estimated the transitive blast radius at around 34% of the entire npm registry. The payload was a browser-side crypto-clipper that hooked window.ethereum, window.solana, fetch, and XHR, then swapped wallet addresses in outgoing transactions using minimum Levenshtein distance so the substitution would survive a quick visual check. Aikido flagged it within five minutes. The malicious versions were on the registry and being installed by CI worldwide for the entire window before that. Vercel published a same-day advisory.

September 15, 2025: Shai-Hulud. A week later, @ctrl/tinycolor (2M+ weekly downloads) was found to contain a self-replicating worm. The malware was the first true worm in the npm ecosystem: every install used the victim's npm token to enumerate other packages the maintainer owned, injected a Webpack-bundled payload, bumped the version, and republished. By the time CISA issued its alert on September 23, more than 500 packages were affected, including ones from CrowdStrike, @nativescript-community, and @operato. The payload ran TruffleHog against the host to scrape AWS keys, GCP credentials, Azure tokens, GitHub PATs, and npm tokens, then uploaded them to public GitHub repos named "Shai-Hulud." A second wave on November 24 moved its hook from postinstall to preinstall (so it ran before any user-visible install output) and hit roughly 25,000 GitHub repositories. CERT/CC VU#534320 called it the first credential-stealing, self-propagating worm in npm.

May 11, 2026: Mini Shai-Hulud. Three days ago, as I write this. A threat actor StepSecurity has been tracking as TeamPCP hit TanStack hard: 42 packages, 84 malicious versions. The same campaign caught Mistral AI, Guardrails AI, UiPath, OpenSearch, and the Bitwarden CLI. Socket flagged 416 affected packages in total; Aikido catalogued 373 malicious package-version entries across 169 names. The technique was novel: a pull_request_target workflow that ran attacker-controlled fork code, GitHub Actions cache poisoning across the fork/base trust boundary, and OIDC token extraction from the runner's process memory. Once inside maintainer CI, the worm did what its predecessor did: scrape credentials, find publishable packages, inject, republish.

The detail that mattered most: the malicious TanStack packages were the first documented npm malware shipping with valid SLSA provenance attestations. The cryptographic chain worked perfectly. The attacker had simply stolen the GitHub OIDC token used to sign builds. Provenance proves "this package was built by this CI run." It does not prove the CI run was not compromised.

The earlier baseline (the December 2023 Ledger connect-kit attack that drained DeFi front-ends for about five hours, the LottieFiles compromise in October 2024, the Rspack token theft in December 2024) is what made September 2025 land as a confirmation, not a surprise. May 2026 made it a pattern.

The structural reason these keep happening: npm is built on install-time arbitrary code execution and ambient authority. The preinstall, install, and postinstall hooks run before any human can review them, with full read and write filesystem access and full network. A typical app's node_modules is several thousand packages from several hundred maintainers, any one of whom can phish or token-leak their way into your build. A logger and a color formatter have the same operating-system privileges as your application code, because Node has no capability-based security to draw a line between them.

The protective measures that shipped (npm provenance, expanded required 2FA in October and November 2025, scan tools like Socket and OSV-Scanner) help at the margins but do not change the model. A phished maintainer with a valid provenance signature still ships valid signed malware. Mini Shai-Hulud proved that this week, with attestations the GitHub Actions runner generated honestly while compromised. 2FA does not stop an adversary-in-the-middle proxy. Detection time has tightened from days to minutes, which is real progress, but the first thousand installs of a poisoned package still happen.

Why this makes Rust tooling load-bearing

Moving the build toolchain to Rust does not fix the structural problems in your runtime dependencies. Your app's node_modules is still a forest of trust assumptions. What it does change is that the build toolchain (the most-installed, most-privileged surface area in the average project) leaves the npm graph entirely.

A linter, a formatter, a bundler, a test runner, and a transpiler are pure dev-time tools with read access to your whole codebase and write access to your machine. They are also among the most-installed packages on npm, which is exactly what made their maintainers attractive phishing targets. Replacing them with one statically linked Rust binary collapses that surface. There is no postinstall. There is no transitive graph. There is a single maintainer organization whose key you can pin.

Concrete numbers from a clean npm install I ran this week:

Toolchain choice	Top-level deps	Total packages	Disk
`eslint` + `prettier`	59	77	20 MB
`@biomejs/biome` (Rust)	1 platform binary wrapper	1 user-facing	48 MB binary
`rollup`	3	4	4.5 MB
`rolldown` (Rust)	3 platform binary wrapper	4	19 MB

Biome's own docs report that a realistic ESLint + Prettier + typical plugins setup lands closer to 127 to 200 packages once plugin ecosystems get involved. The 59 above is the bare minimum.

Cargo has its own supply-chain risks (typo-squats, the long-running debate about serde's precompiled binaries, the occasional malicious crate). What it does not have is a postinstall hook that fires arbitrary code on every developer machine for every transitive build dependency, on every install, forever. That is the difference that matters.

Why Rust specifically

Two reasons. The performance numbers are the easy half: 5 to 30x for bundlers, 50 to 100x for linters, 3 to 4x lower memory across the board. That alone would explain the move.

The harder half is everything else.

Memory safety without a GC. Long-running dev servers and HMR processes do not want to pause for 200ms at the wrong moment. GC-based runtimes (Go, JS) hit this; Rust does not.
Single-binary distribution. CLIs like oxlint and biome ship as one executable per platform. No Node bootstrap, no thousand require() calls, no JS launcher script wrapping a native binary wrapping the actual logic.
Fearless parallelism. rayon and tokio let linters and bundlers fan out across cores cleanly. The JS event loop is fast but it is one core at a time.
WebAssembly as an escape hatch. Node 25.2 ships SWC as wasm inside core. Browser playgrounds run Oxc directly. The same Rust crate can serve a CLI, a Node API, and a browser sandbox without rewriting any of the hot path.

It is also worth saying clearly: Rust is not the only winner. TypeScript's compiler is being ported to Go, not Rust, by Anders Hejlsberg and the team that wrote TypeScript in the first place. The 7.0 beta dropped on April 21, 2026 with a 10x speed claim. Bun started in Zig and only just switched. The honest story is "native code ate JS tooling, mostly Rust, but not entirely."

What I would build with this stack today

If I were starting a new app this week:

next@16 or vite@8 for the framework. Both Rust bundlers underneath.
@biomejs/biome for formatting plus a lint baseline. oxlint as a CI gate for the type-aware rules.
Tailwind v4 with the Oxide engine.
A Rust core library for anything cryptographic, anything sync-heavy, or anything I would want to share between web and mobile, exposed through UniFFI or flutter_rust_bridge if mobile is on the roadmap.
bun or pnpm as the package manager. Lockfile discipline matters more than the manager you pick.

The whole pipeline would have one or two Node processes that exist mainly to host the dev server and run user code. Everything else underneath would be Rust binaries doing the heavy work. That is not aspirational anymore. That is just npm create.

The honest limitations

Three things I would rather not glaze over.

Plugin ecosystems fragment. Every Rust tool eventually faces the same fork: stay in Rust (fast, inaccessible to most JS contributors) or expose a JS plugin API (slower, ergonomic). Rolldown went hard on Rollup-plugin compatibility for adoption. Oxlint shipped a JS plugin alpha in March because too many ESLint rules people care about live in plugin land. Marvin Hagemeister's Speeding up the JavaScript ecosystem series is the canonical write-up of this tension and worth reading if you are considering migrating.

The contributor bus factor is real. Rust is a learning curve for JS-native maintainers. Concentration on Turbopack, Oxc, and Biome is worth pricing in if you are building on top of these tools.

Memory regressions happen. Rolldown 1.0 RC.18 shipped with about 7x higher RSS than Vite 7 in dev for some apps before the fixes landed. Bundlers in Rust are not automatically more memory-efficient. They are faster, but the wins live in CPU time, not necessarily memory.

Try it yourself

If you have not migrated a project off ESLint yet, bunx @biomejs/biome init plus bun add -d oxlint will take you 15 minutes. The Biome migration commands (biome migrate eslint, biome migrate prettier) are doing the right thing in 2026. The Vite 8 upgrade is a npm install vite@8 for most apps. Next.js 16 is the same story; the Turbopack flag is just gone now.

The faster builds are the part people notice. The smaller dependency tree is the part your security team should notice. The shared Rust core that could ship to mobile next quarter is the part your CTO should notice.

It all started with one team being annoyed enough at webpack to write SWC. We got here by accident.

Built by Agnel Nieves, a design engineer with 15+ years across product, design systems, and crypto. More writing on the blog.

Building a Terminal Portfolio You Can SSH Into

Agnel Nieves — Tue, 12 May 2026 00:00:00 +0000

TL;DR

You can now browse this site in your terminal:

ssh agnelnieves.sh

No install. One Rust binary that runs as either a local CLI or an in-binary SSH server. No system sshd, no user accounts, no auth. The TUI is built with ratatui; the SSH layer is russh; render code is shared between local and remote modes. It's hosted on Fly.io behind a dedicated IPv4, and the whole thing costs about $2/mo. The code lives as a cli/ package inside the same Next.js project that powers this site, so the website and the terminal share a single deploy story. If you want the full build (architecture, code, Fly.io setup), I wrote it up as a step-by-step guide.

The setup

ssh agnelnieves.sh. That's it. No -l user@, no keys to add, no first-time signup. The server accepts whatever username your local SSH client offers and drops you straight into a terminal UI.

Press h/a/b/c to jump between Home, About, Blog, and Connect. j/k (or arrows) to navigate lists. Enter to open. q to quit, which closes the SSH session.

Why I built it

Honestly? I saw terminal.shop and thought it was awesome. They sell coffee at ssh terminal.shop (that's the whole storefront, no website) and the first time I tried it I wanted to know if I could build something like it.

I do side projects like this when I need to step away from whatever I'm shipping day-to-day. They're not pitches. They don't need a thesis. They're more like the way some people fix a bike on a Saturday: sit down, follow whatever's pulling on your curiosity, and at the end you have a thing that didn't exist before. That's the whole reason.

So this was that. A few evenings poking at ratatui and russh to see what it would take to make ssh agnelnieves.sh actually work. Turns out: less than I expected. The hardest parts were the ones I didn't see coming, which is what makes any of this fun.

The architecture

One binary. Two modes. One render path.

            ┌─────────────────────────────┐
            │ agnel (single .exe) │
            └──────────────┬──────────────┘
                           │
            ┌──────────────┴──────────────┐
            │ │
       agnel (no flag) agnel --serve
       Local TUI SSH server (Fly.io)
       crossterm stdin russh + custom backend
            │ │
            └──────────┬──────────────────┘
                       │
                src/render.rs ← shared
                       │
                Per-session App state
                       │
                Live fetches from agnelnieves.com APIs

The pieces:

TUI: ratatui draws everything: header, ticker, ASCII banner, projects list, blog reader. The render function lives in src/render.rs and is identical whether the binary is running on your laptop or whether you're seeing it over SSH.
State machine: App in src/app.rs owns screen, scroll position, list selection, ticker animation, and async-fetch results funneled through an mpsc::Receiver.
Data: zero content is bundled. The CLI fetches live from /feed.json, /api/blog/[slug]/raw, /api/projects, and /api/site.json on this site, cached for an hour at ~/.agnel/cache/. So a new blog post here shows up in your terminal immediately without redeploying anything.
SSH server: russh 0.60 in src/serve.rs. One tokio task per session.

The decision that made it easy: don't fork a PTY

Most "expose a TUI over SSH" guides suggest spawning a pseudo-terminal and exec-ing the TUI binary inside it. That's how mosh, tmux, and Go's wish library (the one terminal.shop uses) handle things. It works, but it's heavier:

Adds a libc dependency (forkpty)
Forks a process per connection (more memory, slower spawn)
Hard to share state between the SSH layer and the app

Russh's ratatui_app example showed a cleaner path: implement a custom std::io::Write backend that funnels bytes through russh's Handle::data(channel, bytes) API. Ratatui doesn't know it's writing to an SSH channel instead of stdout. No fork, no PTY, just bytes:

struct TerminalSink {
    sender: UnboundedSender<Vec<u8>>,
    sink: Vec<u8>,
}

impl std::io::Write for TerminalSink {
    fn write(&mut self, buf: &[u8]) -> std::io::Result<usize> {
        self.sink.extend_from_slice(buf);
        Ok(buf.len())
    }
    fn flush(&mut self) -> std::io::Result<()> {
        if !self.sink.is_empty() {
            let _ = self.sender.send(std::mem::take(&mut self.sink));
        }
        Ok(())
    }
}

A background tokio task drains the channel and pushes bytes back to the client through russh. Each session gets its own App and its own Terminal<CrosstermBackend<TerminalSink>>. The lock graph stays tiny: an Arc<Mutex<SessionState>> per session, plus a HashMap of all sessions for cleanup.

Inputs go the other direction. Russh hands raw bytes to my data() callback, and a small parser turns them into the same crossterm::event::KeyEvent values the local TUI uses. That meant zero changes to App::handle_key:

fn parse_keys(buf: &[u8]) -> Vec<KeyEvent> {
    // 0x03 → Ctrl+C, 0x1b[A → Up, 0x1b alone → Esc,
    // printable ASCII → Char(b), etc.
}

Window resize hooks into the same place. window_change_request calls terminal.resize(rect), and ratatui redraws on the next 50 ms tick.

The result: a single binary you can drop on a VPS, in a container, or even into a Lambda-style worker, and it just serves the TUI.

What I learned about hosting

A few things I didn't expect.

1. Fly trial orgs block dedicated IPv4, and SSH needs IPv4. For HTTP, Fly's edge gives you a shared anycast IPv4 for free. For raw TCP on port 22, you need a dedicated v4 (~$2/mo), and trial orgs can't allocate one. Pure-IPv6 isn't a real option, either: most US residential ISPs still don't have native IPv6 SSH paths. Adding a card was the unlock.

2. The SSH host key has to persist. If the container generates a fresh Ed25519 key on every boot, every returning visitor gets REMOTE HOST IDENTIFICATION HAS CHANGED warnings after the next deploy. The fix is a 1 GB Fly volume mounted at /data, with --host-key /data/ssh_host_key. First boot generates and writes the key; every boot after just reads it.

3. Trial machines auto-stop after 5 minutes. That's how the Fly free tier nudges you toward billing. Once you're paying, set auto_stop_machines = "off" and min_machines_running = 1 if you want a long-running service.

4. fly proxy is fine for HTTP, weird for raw SSH. I burned half an hour on Connection reset by peer through fly proxy 12222:2222 before realizing I should just bash /dev/tcp/127.0.0.1/2222 from inside the machine via flyctl ssh console. The SSH server was healthy the whole time; the proxy path was the problem.

ANSI Shadow beats slant

The first banner I shipped used figlet's slant font. It looks fine in a docs file. At terminal width with full-block rendering, it falls apart into disconnected diagonals.

Swapped to ANSI Shadow, the same boxy block font terminal.shop and charm.sh use. Six rows tall, about 93 columns wide, reads instantly. Probably the kind of thing I'd have gotten right the first time if I'd looked at more references before opening figlet.

Visitor #N

One fun thing I added. Look at the bottom-left of the footer when you connect: it says visitor #N. First SSH session ever was #1, second was #2, and so on. The count lives in a tiny text file on the Fly volume next to the host key, increments once per channel_open_session, and persists across deploys (host-key lesson applied).

Implementation is about thirty lines. An AtomicU64 loaded from the file at startup, a spawn_blocking write after each fetch_add. The file is just a base-10 number with no header, so cat /data/visitor_count is the dashboard.

There's no leaderboard. No real meaning to the number. But watching it tick up after shipping is the moment the whole side project starts feeling worth it.

The stack

Layer	Tech
TUI	ratatui 0.29, crossterm 0.28
SSH	russh 0.60
HTTP client	ureq 2 (sync, plenty for this)
Async runtime	tokio 1
CLI args	clap 4
Host	Fly.io (`iad`, shared-cpu-1x, 256 MB, 1 GB volume)
DNS	Vercel Domains (A + AAAA on the apex)
Binary size	~3 MB release (macOS arm64), 4.3 MB (Linux x86_64)
Image size	28 MB (Debian bookworm-slim runtime)
Cost	$2/mo for the dedicated IPv4 + free tier for the rest

What's next

Pretty errors and loading states. Today they say Loading… which is functional but boring.
Project deep-links. I render project metadata but not the original write-ups. Pulling MDX through the API would let me ship long-form case studies in-terminal.
Cross-platform release binaries. The current install path is cargo install --path cli/. Homebrew tap + release artifacts for macOS and Linux is a Saturday morning.

Try it

ssh agnelnieves.sh

If you want to build your own version, the guide has the full setup (Rust + ratatui + russh + Fly.io), with a copy-paste prompt at the top so you can hand it to your AI agent of choice. If you ship one, let me know.

Built by Agnel Nieves, a design engineer with 15+ years across product, design systems, and crypto. More writing on the blog.

Optimizing Your Website for AI Agents and LLMs

Agnel Nieves — Tue, 14 Apr 2026 00:00:00 +0000

Your website has two audiences now. Humans, obviously. But also AI agents — LLMs that crawl, summarize, cite, and recommend your content to millions of people. If your site isn't optimized for both, you're leaving visibility on the table.

I just finished optimizing my personal site for AI consumption, and the process revealed something interesting: most of what makes a site good for AI also makes it better for humans. Clear structure, machine-readable content, and explicit metadata benefit everyone.

Here's what I did and why it matters.

What Are AI Agents Actually Doing with Your Site?

When someone asks ChatGPT, Claude, Perplexity, or Google's AI Overview a question, those systems don't just generate answers from training data. Increasingly, they fetch and cite live web content. Your site might get:

Crawled for training data by bots like GPTBot, ClaudeBot, and Google-Extended
Fetched at query time by Perplexity, ChatGPT browsing, and similar agents
Cited as a source in AI-generated responses
Summarized in featured snippets and AI overviews
Navigated by autonomous agents that interact with your APIs

Each of these has different needs, but they all benefit from the same foundation: structured, discoverable, machine-readable content.

The llms.txt Standard

The llms.txt spec is the equivalent of robots.txt for AI agents. While robots.txt tells crawlers what they can access, llms.txt tells them what your site is — a structured markdown index served at your domain root.

The format is simple:

# Your Name or Site

> A one-line summary of what this site is.

A longer description paragraph.

## Section Name

- [Link Title](https://url): Description of what's at this link

I implemented two variants:

/llms.txt — the index. A table of contents with links to all pages, blog posts, projects, social profiles, and feeds. Think of it as a menu for AI agents to browse selectively.
/llms-full.txt — the full dump. Every blog post's complete markdown content, every project description, biographical context. For agents that want to load everything into context at once.

Both are served as text/plain with markdown formatting. Both are generated dynamically from the same data sources that power the site, so they never go stale.

Inline LLM Instructions in HTML

This one comes from a Vercel proposal and it's clever: embed AI-readable instructions directly in your page's <head> using a script tag browsers ignore.

<script type="text/llms.txt">
# Your Site Name

This is the personal website of [name], a [role] based in [location].

## Site Structure
- / — Home: Description
- /blog — Blog: Description
- /about — About: Description

## Key Facts
- Name: Your Name
- Role: Your Role
- Specialties: Thing 1, Thing 2, Thing 3
</script>

Browsers skip <script> tags with unknown types. LLMs process them. It's a zero-cost way to give every page on your site a machine-readable context block. I added one to my root layout that describes who I am, the site structure, and where to find machine-readable content.

Structured Data That AI Engines Actually Use

JSON-LD structured data has always been important for Google. It's now equally important for AI engines. When an LLM encounters schema.org markup, it understands the semantics of your content — not just the text, but what the text represents.

I already had structured data for my blog posts (BlogPosting schema with breadcrumbs). What I added was CreativeWork schema for my portfolio projects, giving each project a machine-readable identity:

{
  "@context": "https://schema.org",
  "@type": "CreativeWork",
  "name": "Project Name",
  "description": "What this project is",
  "url": "https://project-url.com",
  "creator": {
    "@type": "Person",
    "name": "Your Name"
  }
}

The more schema types you cover, the more AI engines can understand and cite your work with proper attribution.

Machine-Readable Feeds

RSS is great, but it's XML — not the most natural format for AI agents to parse. I added a JSON Feed endpoint alongside my existing RSS feed:

/feed.xml — RSS 2.0 for traditional feed readers
/feed.json — JSON Feed 1.1 for programmatic consumption

JSON Feed is cleaner for AI agents to parse and reference. Both are registered in the site's metadata so they're auto-discoverable.

Making robots.txt AI-Aware

Most sites already have a robots.txt. The key addition is explicitly allowing AI crawlers and pointing them to your llms.txt:

User-agent: GPTBot
Allow: /

User-agent: ClaudeBot
Allow: /

User-agent: PerplexityBot
Allow: /

Sitemap: https://yoursite.com/sitemap.xml

# AI/LLM Content
# llms.txt: https://yoursite.com/llms.txt
# llms-full.txt: https://yoursite.com/llms-full.txt

Many sites block AI crawlers by default. If you want your content cited and discovered by AI, explicitly allow the major bots: GPTBot, ChatGPT-User, Google-Extended, ClaudeBot, anthropic-ai, PerplexityBot, Applebot-Extended, Bytespider, and cohere-ai.

Why This Matters for Creators

As a design engineer with 15+ years of building products, I've watched SEO evolve from keyword stuffing to semantic web to AI-native discovery. We're at an inflection point. The sites that get cited by AI aren't necessarily the ones with the best domain authority — they're the ones with the clearest, most structured, most machine-readable content.

This is especially important for personal sites and portfolios. When someone asks an AI "who are the best design engineers in Miami?" or "what's a good article about design tokens?", you want your site to be citable. That requires more than good content — it requires content that AI can find, understand, and attribute.

The Full Stack of AI Optimization

Here's the complete checklist of what I now have in place:

Layer	What	Why
`robots.txt`	Explicitly allow AI bots	Let them crawl
`sitemap.xml`	Dynamic sitemap with all content	Let them discover
`llms.txt`	Markdown index of the site	Let them understand structure
`llms-full.txt`	Full content in one file	Let them ingest everything
Inline `<script>`	Page-level LLM instructions	Let them understand context
JSON-LD	Structured data on every page	Let them understand semantics
RSS + JSON Feed	Machine-readable content feeds	Let them subscribe
Meta tags	OpenGraph, Twitter, canonical	Let them cite accurately

None of these changes affect how the site looks or feels for human visitors. They're invisible additions that make the site dramatically more useful for AI.

What's Next

The AI web is evolving fast. Standards like llms.txt are still emerging, and new patterns will appear. But the fundamentals won't change: structure your content clearly, make it discoverable, and give machines the metadata they need to understand it.

If you want to replicate this setup, I've published a full implementation guide with code examples for Next.js. The approach works for any framework — the concepts are universal.

Building something and want to talk AI optimization? Let's connect.

We Found a Hidden Pet System in Claude Code's Leaked Source and Shipped It Overnight

Agnel Nieves — Wed, 01 Apr 2026 00:00:00 +0000

On March 30th, 2026, Anthropic accidentally shipped a 59.8 MB source map file inside their Claude Code npm package. Within hours, the entire 512,000-line TypeScript codebase was mirrored across GitHub and picked apart by thousands of developers. Buried inside that code, alongside feature flags for autonomous agents and undercover commit modes, was something nobody expected: a fully built virtual pet system called Buddy.

My co-founder peroni and I did the only sensible thing. We shipped it.

We all know what happened yday with Claude Code. Buried in the source: a hidden pet system called "Buddy." Every user gets a unique pixel creature based on their ID. Deterministic, same hash, same buddy, every time. So @peronif5 and I did the most sensible thing... Shipped it.… pic.twitter.com/YE4ZSEIXq7
— Agnel (🇵🇷) (@agnelnieves) April 1, 2026

What Happened with the Claude Code Leak

If you missed it, here's the short version. Chaofan Shou (@Fried_rice) noticed that version 2.1.88 of the @anthropic-ai/claude-code package on npm included an unminified source map — cli.js.map — containing the full, readable TypeScript source. By 4:23 AM ET, it was public. By noon, the internet had catalogued every hidden feature, internal codename, and unreleased capability Anthropic had been quietly building.

Among the bigger discoveries:

KAIROS — an always-on daemon mode that lets Claude Code operate as a persistent background agent, watching, logging, and acting without waiting for user input
Undercover mode — auto-activated for Anthropic employees on public repos, stripping AI attribution from commits
44 feature flags covering unreleased functionality
And tucked away, a complete companion pet system called Buddy

The Buddy System: A Pixel Pet for Every User

The Buddy system was fully implemented. Every Claude Code user was supposed to get a unique pixel creature generated deterministically from their user ID. Same hash, same buddy, every time. The code included 18 species across rarity tiers, stat generation, personality descriptions — the whole gacha experience, just waiting to be turned on.

It was the kind of detail that makes you smile. In a tool built for productivity and code generation, someone at Anthropic took the time to build a pet system. A little pixel friend that lives in your terminal. That's the kind of craft and whimsy that makes developer tools memorable.

The moment I saw it, I knew what we had to do.

From Discovery to Deploy in a Day

Peroni and I have a rhythm. We spot something interesting, we build. No planning committee, no Jira tickets, no "let's circle back Monday." As a design engineer with 15+ years of shipping products, I've learned that the best side projects are the ones you can't not build. This was one of those.

We built Claude Buddy — a web app that lets anyone generate their own pixel companion. Type your name or your Claude Code user ID, and watch it draw your buddy pixel by pixel, complete with retro CRT animations and pop sounds.

Here's what we shipped:

12 unique pixel art species across 5 rarity tiers — from common Blobbits to the legendary Nebulynx (3% chance)
Deterministic generation — same name always produces the same buddy, making them feel like yours
Shiny variants with a 5% drop rate, because of course
Buddy stats — Vibe, Chaos, Focus, and Luck, each randomly rolled but consistent to your hash
One-command terminal install — curl a script and your buddy appears in your Claude Code statusline
Social sharing — download as PNG, share via URL, generate QR codes, post to X/LinkedIn with pre-populated text

The whole thing runs on Next.js 15, renders sprites on HTML5 Canvas, and uses a Mulberry32 PRNG seeded by a DJB2 hash of your input. No backend, no database, no authentication. Pure deterministic fun.

Why Build This?

Partly because it's fun. Partly because of how I approach creative work — I try to ship a hackathon-style project every quarter to stay sharp and experiment with new patterns. But mostly because I think the Buddy system represents something important about how we relate to our tools.

Developer tools don't have to be purely utilitarian. The best ones have personality. They reward curiosity. They make you want to open the terminal. A pixel pet that lives next to your cursor won't make you a better programmer, but it might make the work feel a little less solitary.

Anthropic clearly felt the same way — they built the whole thing, ready to ship. We just opened the door a little early.

How the Generation Algorithm Works

For the technically curious, the generation is straightforward:

Take the input string (name or user ID), lowercase and trim it
Salt it with a fixed string to avoid collisions
Run a DJB2 hash to convert it to a numeric seed
Feed that seed into a Mulberry32 PRNG
Roll for species (weighted by rarity tier probabilities)
Roll for shiny status (5% chance)
Generate four stats between 1 and 99
Select a soul description from the species pool

Same input, same seed, same rolls, same buddy. Every time. No server involved.

It's Open Source

The entire project is open source on GitHub. Built by the Basement team. Fork it, remix it, hatch your own buddy.

If you want to see what came out of this, check the thread on X where we announced it. And if you're building with Claude Code, maybe your buddy is already waiting — just type your name and find out.

Have thoughts on this or want to collaborate on something weird? Let's connect.

The AI-Native Design Gap: From Static to Dynamic Experiences

Agnel Nieves — Thu, 16 Oct 2025 00:00:00 +0000

Here's something I see all the time: teams spend weeks perfecting static mockups in Figma, present them with confidence, and then watch as stakeholders nod politely but don't quite get it. Why? Well, we're designing static artifacts for dynamic experiences.

Every scroll, swipe, and tap in a real product triggers visual feedback. It's how users actually understand what's happening. Yet we keep pitching ideas as if they exist in freeze-frame.

The AI-Native Design Challenge

This gap matters more than ever, especially if you're working on AI-native products. Whether it's OpenAI's ChatGPT, Perplexity's search interface, or Claude's conversations—these products are rewriting the rules of digital interaction. They're introducing entirely new patterns: streaming responses, conversational flows, adaptive interfaces that feel less like traditional apps and more like living dialogues. Even more so if the interactions include voice motion which is supposed to react to the user's voice.

You can't capture that in a static frame. You have to show it in motion.

Why Interaction Design Is an Unlocked Skill

Here's the thing about motion and interaction design: it's a toolkit you unlock through experimentation, not strictly tied to theory or studies. You learn it by thinking about physics, natural movement, user intent—concepts you absorb from using dozens of different apps and noticing what feels right. Think about it, try to explain a motion ui pattern to someone, try to explain the core concept of what you have in your mind. It's difficult… It's open to interpretation of the person to whom you're explaining it to, and limited by their imagination (which is highly likely different from yours).

This creates a knowledge gap. Most designers haven't had the chance to experiment enough with motion to build that intuition. But here's what I've learned: even designing interactions frame-by-frame, storyboard-style like old Disney animations, can be enough to transform how you communicate ideas. It forces you to think through every transition, every state change, every moment of feedback.

And it doesn't just help you—it helps engineering understand exactly what you're trying to build.

Design Is Taking the Spotlight Again

We're in an exciting moment. With AI tools and no-code platforms, pretty much anyone can spin up a functional prototype. The technical barrier to entry has lowered significantly.

What does that mean? Design becomes the differentiator. When everyone can build something that works, the products that win are the ones that feel incredible to use. Motion, polish, and thoughtful interaction patterns aren't nice-to-haves anymore—they're what separates successful products from forgettable ones.

My Approach: Build to Learn

I try to ship a hackathon-style project every quarter. Not because I need more side projects, but because it's the only way to stay ahead and fresh. New patterns emerge constantly. AI products iterate at light speed. Existing products unveil interactions you never even considered.

The only way to keep your intuition sharp is to experiment relentlessly with what's out there.

This comes from personal experience. My background has helped me a lot in this area—I started as a designer, shifted to software engineering, and eventually came back to design. That engineering foundation changed everything. I can quickly prototype motion patterns directly in code (often faster than in design tools), play with them until something clicks, then bring those learnings back to Figma to polish everything together.

This workflow might sound backwards, but to me, it makes sense and it just works: code/define the motion first, design and polish last. Code gives you the freedom to experiment rapidly. Spin up prototypes quickly, and gather feedback. Design tools give you the precision to perfect it.

The Practical Takeaway

If you're trying to sell an idea—whether to stakeholders, users, or investors—don't stop at static screens. Invest time in showing how it moves. Show how it responds. Show how it feels.

You don't need to be an engineer to do this. Start simple:

Sketch interaction sequences frame-by-frame
Use Figma's prototyping features to simulate key transitions
Try tools like ProtoPie, Lottie Lab for more complex motion
Or, if you're comfortable with code, prototype directly in React or HTML

The medium matters less than the commitment: design for motion, not just for pixels.

Because in an era where AI is democratizing creation, the products that win won't just work—they'll feel magical. And you can't explain magic in a static mockup.