Most infrastructure teams are still running like it’s 2020.

Someone checks the dashboards. Someone else restarts a container. An incident goes unnoticed until 2:00 am, when a bleary-eyed engineer is manually patching a production server, wondering how they got there.

If that sounds familiar, this article is for you.

By 2026, **AI-driven infrastructure** is no longer a future concept. It is happening right now, and the teams that figure this out early will move significantly faster than everyone else.

## **The Misconception Slowing Everyone Down**

![Photo by Zulfugar Karimov on Unsplash](https://miro.medium.com/v2/resize:fit:1400/0*bD1O6ciQOTSku4yz "Photo by Zulfugar Karimov on Unsplash")

Most people assume the magic of AI is in the model. Smarter reasoning, bigger context windows, more parameters.

That is not where the value is.

The real change is **operational context**. An AI agent that can see your logs, access your deployments, read your GitHub history, inspect your infrastructure, and create pull requests is not a chatbot anymore. It becomes an operational layer.

We are moving from AI as assistant to AI as operator. That is the change.

And the good news? You do not need AGI to get there. We are talking about four or five API connections, scoped permissions, and the willingness to actually wire it all up.

## **What AI-Connected Infrastructure Actually Looks Like**

Here is the exact access I give to AI systems, and why each one matters.

![](https://miro.medium.com/v2/resize:fit:1400/1*ftmLvfw7bRBnauB25FCOdw.png)

### **Connection 1: Cloudflare**

Cloudflare is step one, and you want to do it quickly. This is not just DNS.

Give your AI agent access to:

*   Firewall events and WAF rules
    
*   Caching and rate limiting
    
*   Bot traffic and tunnels
    
*   Security centre events and analytics
    

![](https://miro.medium.com/v2/resize:fit:1400/1*t8WrqGX-bfhUz1h3XbvMeA.png)

This matters more than you think: your Cloudflare layer tells you what is happening **before your application does**.

Picture this. There is a sudden spike in bot traffic at 3:00 am. Normally nobody notices until the service starts struggling. But an AI agent with Cloudflare access can detect the anomaly, inspect the source, apply firewall rules, invalidate cache, increase rate limiting, and open a GitHub issue automatically before anyone is even awake.

That is not AGI. That is just connected infrastructure.

### **Connection 2: Google Services**

Infrastructure is not just servers. It also includes SEO analytics, core web vitals, conversion tracking, search performance, Lighthouse scores, and user behaviour.

Give your agent a Google service account, and you get access to:

*   Google Search Console
    
*   PageSpeed Insights
    
*   Google Analytics
    
*   Google Tag Manager
    

![](https://miro.medium.com/v2/resize:fit:1400/1*gN60qyvIIv2hvKU6S3DUBw.png)

Here is a practical example: A new frontend update gets deployed. The site technically works, but core web vitals collapse, the CLS score spikes, and mobile performance tanks. Without monitoring, you would not notice until users started complaining.

An AI agent with Google access can detect performance regression, compare it against the deployment history, identify the offending commit, generate a fix, and automatically open a PR.

Run this check after every deployment. Or have an agent do it every hour. Either way, you will catch issues before they catch you.

**Your infrastructure should understand business impact, not just CPU usage.**

### **Connection 3: Production Server Access**

This is the part that makes people uncomfortable. Giving the AI controlled access to your production infrastructure feels risky. I get it.

But honestly? It is where the biggest operational gains happen.

The key is doing it right. Scoped access to:

*   nginx, Docker, or PM2
    
*   Logs and containers
    
*   SSL status and disk usage
    
*   Service health and deployment state
    

![](https://miro.medium.com/v2/resize:fit:1400/1*BRalo1DKlUoq-Sow2RBjvg.png)

You want least-privilege access, audit logging, isolated permissions, and approval workflows. With those guardrails in place, the system becomes genuinely powerful.

A practical flow: deployment fails. The AI checks GitHub Actions, reads the Docker logs, identifies the issue, patches the Dockerfile, updates the environment config, opens a PR, explains the root cause, and adds a changelog. Done.

I honestly cannot remember the last time I deployed something manually. I have a skill book where I store deployment instructions per project. I just say, **_“read the skill book, deploy this,”_** and it handles it.

That is not science fiction. You don’t need to wait for AGI. You can do this right now.

### **Connection 4: Email Infrastructure**

![](https://miro.medium.com/v2/resize:fit:1400/1*6aL2t0KKyKZzNq4MXQcLtQ.png)

Most teams completely ignore email infrastructure until it breaks. Then password resets fail. Onboarding emails disappear. Invoices stop sending. It is painful.

Give your AI access to your email platform, whether that is Mailchimp, Mailjet, or something else.

A simple workflow we use: after every CMS deployment, the agent fills out the contact form, clicks send, confirms the email arrives, and verifies SPF and DMARC records against Cloudflare’s security centre.

You want to know your emails are failing before your customers figure it out.

### **Connection 5: GitHub**

![Photo by Rubaitul Azad on Unsplash](https://miro.medium.com/v2/resize:fit:1400/0*INS3OD8_y7xgf2F2 "Photo by Rubaitul Azad on Unsplash")

GitHub access is what makes the entire thing collaborative. With it, your agent can:

*   Inspect CI/CD failures
    
*   Read deployment logs
    
*   Compare commits
    
*   Generate patches and create PRs
    
*   Track recurring failures over time
    

The infrastructure becomes self-documenting. Every incident gets logged. Every fix has a paper trail. Every regression is traceable.

## **One More Thing: Secrets Management**

![Photo by Sasun Bughdaryan on Unsplash](https://miro.medium.com/v2/resize:fit:1400/0*HGo5VkIsAjyXo_fz "Photo by Sasun Bughdaryan on Unsplash")

Once you connect everything, you face a new problem:

> **_How do you manage secrets?_**

The wrong way: keys scattered across individual developer environment files, shared on Slack, with stale credentials nobody has rotated, and the occasional accidental commit of a secrets folder to a public repository. This is more common than anyone wants to admit.

The right way: **a centralised secrets manager**. We use [1Password](https://1password.com/) for this. One source of truth for the team. Credentials rotate properly. Environments stay consistent. AI systems can retrieve scoped secrets when they need them without anyone having to copy-paste a key into a chat message.

The practical test: if someone on your team asks **“_which API key is production using right now_,”** that question should have an instant, correct answer from one system. If it does not, secrets management is a problem worth solving before you connect anything else.

## **The Bigger Picture**

![Photo by Immo Wegmann on Unsplash](https://miro.medium.com/v2/resize:fit:1400/0*zjrpsEFpAES3uKb0 "Photo by Immo Wegmann on Unsplash")

The companies that win in 2026 will not necessarily have the best engineering teams. They will have the best **connected infrastructure**.

The future of infrastructure is not humans doing less work. It is humans building systems that can operate safely on their own. Observable. Repairable. Adaptive. Autonomous.

Giving AI operational access is quickly becoming table stakes. And all of this, from Cloudflare to GitHub to email to production, comes down to roughly five API keys. It is not complicated to set up.

The teams that figure this out will move faster than everyone else. The teams that wait for it to feel safe will be catching up.

Consider this question: Are you already giving AI systems operational access? Or does it still feel too risky?

Would love to know how you are approaching this! Drop a comment below.

* * *

_If you found this useful, subscribe to Elephant Stripes’_ [_YouTube_](https://www.youtube.com/@elephantstripesai) _channel for more content on AI-native infrastructure, autonomous operations, and where engineering teams are headed._

@[youtube](https://www.youtube.com/watch?v=kn3BkCEgBXg)

Here are five API keys that let AI handle it instead

Still Patching Servers at 2 AM? Stop.

Here are five API keys that let AI handle it instead. By 2026, AI-driven infrastructure is no longer a future concept. It is happening right now..

Still Patching Servers at 2 AM? Stop

You find a role that feels right. The salary works. The team looks decent. The job description reads like it was written for you.

So you open your resume.

And then comes that familiar sinking feeling. The resume you have was built for the last job you applied for. Or maybe the one before that. It’s close. But it’s not quite right for _this_ one. You’re going to have to rewrite it. Again.

This is where most job seekers lose hours they didn’t have to spare. And often, where they quietly lose the role too.

There’s no shortage of **AI resume builders** promising to solve this. But most of them do the same thing: take your existing resume and make it sound a bit shinier. They tighten the language, sprinkle in keywords from the job description, and call it tailored.

That’s useful, sure. But it’s not really solving the problem.

## **The Real Problem isn’t Your Resume. It’s Your Memory.**

![Photo by Vasilis Caravitis on Unsplash](https://miro.medium.com/v2/resize:fit:1400/0*bM8GgoRvSl0Kp97O "Photo by Vasilis Caravitis on Unsplash")

Here’s what’s actually going on.

Over the course of your career, you’ve done a lot. You’ve shipped projects, led teams, solved problems, and worn hats that were never in your original job description. You’ve built things, fixed things, and figured out things on the fly.

But virtually none of it is written down in a single place.

Your resume is a snapshot. Usually two pages. Usually written in a hurry. And almost always trailing well behind what you’ve actually done. It captures _some_ of your work. A handful of highlights. A selection of skills.

What it doesn’t capture is the full picture.

Think about it this way. Imagine you had a 40-page document tracking everything: every project, every role, every unexpected responsibility you took on, every skill you quietly built over the years. From those 40 pages, pulling out the perfect two-page resume for any given role would be straightforward.

You’d have so much to work with that the right version would practically write itself. It would take the best things you’ve done and cast you in the best possible light, every time.

That’s the idea: a new wave of AI job tools is finally starting to chase. Not just resume polishing, but something more like persistent career memory.

## **What “Persistent Memory” Actually Means for Job Seekers**

![](https://miro.medium.com/v2/resize:fit:1400/1*cOUk6FLnHaznZe6ZqM3_4g.png)

The concept is simpler than it sounds.

Instead of treating each job application as a one-off task, the smarter approach is to build an ongoing picture of who you are professionally. An AI agent you talk to over time. One that learns about your history, your projects, your strengths, and yes, your gaps too.

The more you tell it, the better it understands you. The better it understands you, the more precisely it can represent you to any employer, for any role.

This is the thinking behind [JobsLobster](https://jobslobster.com/), a new tool being built by [Elephant Stripes](https://elephantstripes.ai/). It’s still early, and we’re transparent about that. But the core idea is genuinely different from what most AI resume tools are doing today.

The goal isn’t just to help you write a tailored resume. It’s to create a living knowledge base about your professional life that gets richer every time you use it.

## **How It Works in Practice**

The process starts simply. You upload your existing resume and paste in a job description. No complicated integrations. Just two inputs and you’re underway.

![Click ‘Start resume preview’, upload your resume, and paste the job descriptions.](https://miro.medium.com/v2/resize:fit:1400/1*kZGsboxqrvJD7iI9VuyZNg.png "Click ‘Start resume preview’, upload your resume, and paste the job descriptions.")

From there, the app does something most resume tools skip entirely. It generates a **capability map**.

![Sample: Competence review by JobsLobster](https://miro.medium.com/v2/resize:fit:1400/1*AJYyfyAT04-Hq3BG3OAXFQ.png "Sample: Competence review by JobsLobster")

This is where it gets interesting.

The capability map compares what’s in your resume against what the job description is actually asking for. It doesn’t just flag keywords. It surfaces the specific gaps between how you’re currently presenting yourself and what this particular employer needs.

In practice, it looks like this: _“_**_Candidate shows AI product experience, but lacks detail on enterprise AI agentic lifecycle or Microsoft-stack delivery._**_”_ That’s a precise, actionable insight. Not generic feedback. Not a vague nudge to “add more detail.” A specific gap you can actually do something about.

Here’s what makes that useful. Say you’re applying for a role that asks for water utilities experience and you don’t have any. But you _do_ have public sector experience. The capability map will flag the gap and prompt you to fill it in by talking to the AI agent about what you _do_ have that’s relevant. The agent remembers. And next time you generate your resume, it has a much richer dataset to draw from.

You’re not inventing experience. You’re surfacing the real experience that simply never made it onto your two-page snapshot.

## **Everything the tool produces**

Once you’ve worked through the capability review, the outputs come together cleanly.

*   A **tailored resume** built from your full career picture, not just the version you uploaded
    
*   A **cover letter** shaped to the role
    
*   **Interview prep** with hints specific to the job description
    
*   A **mock interview** capability to practise before the real thing
    

Everything downloads as a PDF or DOCX, ready to send.

The persistent memory piece is the thread running through all of it. The more conversations you have with the AI agent about your work history, the better every output gets. It’s not a one-click fix. It’s closer to an ongoing conversation with something that’s genuinely trying to understand your professional life.

![Sample: Tailored resume generator by JobsLobster](https://miro.medium.com/v2/resize:fit:1400/1*KO7w8Zrp0FTB_zOtCh4jVg.png "Sample: Tailored resume generator by JobsLobster")

## **Why This Matters Beyond Just The Resume**

![Photo by Zulfugar Karimov on Unsplash](https://miro.medium.com/v2/resize:fit:1400/0*PUxF8iGjxAjoYWkA "Photo by Zulfugar Karimov on Unsplash")

There’s a framing here that doesn’t get said enough.

Employers already have sophisticated AI on their side. They’re using it to scan applications, rank candidates, and filter you out before a human ever reads your name. Getting noticed has become a technical challenge as much as a human one.

Job seekers haven’t had equivalent tools. Most people are still sending the same slightly-updated resume they’ve been using for years, hoping the right words line up with the right role.

That’s not a fair fight.

Persistent career memory matters precisely because it starts to close that gap. It’s not about gaming job applications. It’s about making sure the real depth of your experience, all the stuff that doesn’t fit neatly into two pages, actually gets a chance to show up when it’s relevant.

The capability map reflects this thinking clearly. It doesn’t tell you to overstate your experience. It tells you where you’re _underrepresenting_ yourself. There’s a meaningful difference between those two things.

## **Where It’s at Right Now**

![](https://miro.medium.com/v2/resize:fit:1400/1*DZT81R7_48pl6Nikgwlp-g.png)

JobsLobster is a work in progress. I’m still chipping away at the features and feel every day. However, our free trial gives you three job applications per week to experiment with, which is a solid way to explore it without any commitment.

If you’re in an active job search, that’s actually enough to feel the difference. Upload a real resume. Grab a real job description from Seek or LinkedIn. Run through the capability map and see what it surfaces. The exercise alone is worth doing, even if you end up writing the resume yourself.

If you need something a bit more robust, paid plans are available, but definitely give the free version a whirl first while we’re still building things out. We’d love to hear what you think in the comments. It seriously helps us make the tool better for you!

## **The Question Worth Sitting With**

![Photo by Resume Genius on Unsplash](https://miro.medium.com/v2/resize:fit:1400/0*feHeg0UkANjvJJ1m "Photo by Resume Genius on Unsplash")

Most job search advice treats the resume as a static document. Update it, polish it, tailor it. That advice hasn’t changed much in twenty years.

But careers aren’t static. They’re full of context, nuance, and accumulated experience that a two-page document fundamentally cannot hold. The gap between what you’ve actually done and what fits onto a resume has only grown over time.

Tools that treat your career as a living, expanding picture rather than a fixed snapshot are pointing in a genuinely useful direction. Not because AI is magic, but because the problem of representing yourself accurately to employers is real, and the tools most people use aren’t solving it.

If you’re in a job search right now, or you sense one might be coming, it’s worth asking: what does your professional memory actually look like? Not just the resume you have open in a tab somewhere. The full picture of what you’ve built, what you know, and what you can do.

Getting that down somewhere, even imperfectly, is more valuable than another round of polishing the same two pages.

JobsLobster is one emerging answer to that question. It won’t be the last. But the question being asked is the right one.

> _What would your application look like if the AI helping you actually knew you?_

**Live demo: How to stop rewriting your resume for every job application**

@[youtube](https://www.youtube.com/watch?v=2cAOYHAkxKs)

* * *

_JobsLobster is available to try at_ [](http://jobslobster.com/)[_jobslobster.com_](http://jobslobster.com)_. Help us improve by leaving your feedback!_

How to Make AI Actually Know You for Job Applications

The persistent memory approach that changes things.

Jobslobster not only help you write a tailored resume. It’s to create a living knowledge base about your professional life that gets richer every time you use it..

Deploying an app is like riding a bike.

Once you’ve done it properly, you can do it again. But if you haven’t ridden in six months, those first few wobbly metres are always a little nerve-wracking. You know you remember how, and then you put your foot on the pedal, and you’re suddenly not quite sure.

That’s the honest reality of DevOps for most developers on small teams. You don’t do it often enough to stay sharp on the details.

AI changes this. It doesn’t make you a DevOps expert, but it holds the details reliably while you focus on whether the broader approach is right.

I wanted to show you what that actually looks like, so here is the full deployment of a real client app, nine phases, an Oracle ARM64 server, and about thirty minutes of supervised execution.

## **What We Built and Where We Shipped It**

![Ethics Pilot by Elephant Stripes AI](https://miro.medium.com/v2/resize:fit:1400/1*R-qAsMB4he01YLA6k_8cFQ.png "Ethics Pilot by Elephant Stripes AI")

The app is called _Ethics Pilot_. It’s a simple document review system: upload files, select a few, and chat with an AI about their contents. Built for a client, running on a Next.js and PostgreSQL stack.

Because the product name isn’t final, it doesn’t have its own domain yet. We deployed it to \`[ethics-pilot.elephantstripes.ai](http://ethics-pilot.elephantstripes.ai), under the [Elephant Stripes](https://elephantstripes.ai/) umbrella, which we use for client builds in progress.

Production server: Oracle ARM64 instance. Docker for containerisation. Nginx as a reverse proxy. TLS via Let’s Encrypt. Self-hosted GitHub Actions runner. Google Chat webhook for deployment notifications.

That’s the full surface area. Here’s how we covered it.

## **The 9-Phase Deployment Blueprint**

The key to using AI effectively for DevOps is structure. You give the agent a clear plan, server access, and a set of success criteria for each phase. It executes. You steer.

### **Phase 1: DNS**

Before anything else, the domain has to exist.

We have a Cloudflare token scoped to the Elephant Stripes domain. Codex uses it to create the DNS record and validates that \`[ethics-pilot.elephantstripes.ai](http://ethics-pilot.elephantstripes.ai) resolves correctly.

Two minutes. No clicking around in dashboards.

### **Phase 2: GitHub Runner**

The self-hosted runner is what executes CI/CD jobs on our production server instead of on GitHub’s shared infrastructure.

This matters on ARM64. GitHub’s default runners are x86. If you build a Docker image on x86 and run it on ARM64, you get subtle failures that are genuinely unpleasant to diagnose. A self-hosted runner on the production server sidesteps all of that.

Codex registers the runner under Ubuntu, connects it to the repository, and confirms it’s online.

### **Phase 3: Repo production runtime**

Here the codebase gets ready for the real world.

Codex adds a `.dockerignore, writes a production` Dockerfile, and updates `next.config.js with the environment settings appropriate for a live server. It also creates the` [docker-compose.prod](http://docker-compose.prod).yml.

Think of this phase as the difference between “it runs on my machine” and “it runs where it needs to.”

### **Phase 4: Production seed mode**

In development, the database gets seeded with test users, fake organisations, and demo content. That’s useful locally. In production, it’s a problem.

Codex updates the seed configuration so that only a superadmin account gets created on first boot. Everything else is explicitly excluded.

### **Phase 5: CI/CD workflow**

This is the engine.

Codex builds a GitHub Actions workflow with three stages: validation, production deploy, and notification.

**Validation** catches linting errors, type issues, and missing environment variables before the build even starts. **Production deploy** builds the Docker image, copies it to the server, and restarts the containers. **Notification** pings a Google Chat group when the deployment succeeds.

We give Codex an existing workflow from another project as a reference. It patterns the output on that, which keeps things consistent across our project portfolio.

### **Phase 6: Production host environment**

The server needs to be ready before the app arrives.

Codex creates service accounts, sets up the directory structure, writes environment files, and sets file permissions. No root processes. Everything is owned by the right account.

### **Phase 7: Nginx and TLS**

Nginx sits in front of the Docker container and handles incoming HTTPS traffic. Certbot handles the SSL certificate and sets up automatic renewal.

If you’ve configured this manually before, you have a story. With Codex doing it, the story is just “it worked.”

### **Phase 8: First deploy**

Everything is committed. Codex pushes to main. The GitHub Actions workflow triggers.

We watch it go.

**Run one.** The build fails. Missing build-time environment variable placeholders in the .env file. Next.js couldn’t compile. Codex spots the error in the build log, fixes the file, and pushes.

**Run two.** Gets further. Fails at the release gate. The CI fix commit didn’t include a changelog entry. Codex adds one and pushes.

**Run three.** Validation passes. Docker image builds. Deployment runs. The Google Chat notification arrives.

Thirty minutes. Three iterations. No manual debugging, no log archaeology, no nervous Googling.

This is what a first deployment looks like. There will always be a few issues. The difference with AI is that Codex handles the diagnosis and the fix in one movement. You watch, you learn what to look for, and each subsequent deployment goes faster.

### **Phase 9: Runbooks and final checks**

Once production is live, document what just happened.

Codex writes runbooks for common operations like deployment, rollback, and database migration. It creates a changelog entry for the deployment itself. It notes the follow-up items: the missing build cache configuration, the npm version warning that appeared during the build.

These aren’t just notes. They’re the foundation for everything that comes next.

## **The Thing about Runbooks**

![Photo by apoorv mittal on Unsplash](https://miro.medium.com/v2/resize:fit:1400/0*wbF_d_gLDNgBqXKh "Photo by apoorv mittal on Unsplash")

When you work with an AI agent, runbooks are reusable prompts.

“Use the deployment runbook” triggers a defined sequence: pre-deploy checks, execution, post-deploy validation. “Use the end-to-end testing runbook” kicks off environment setup, test execution, and teardown, all in the right order.

You write them once, refine them after each project, and they compound. The concept comes from what the folks at [Every](http://every.to/) call compound engineering: skill books that improve incrementally over time. Three projects in, you have something genuinely powerful.

We also maintain a daily changelog that Codex can scan to understand project history before acting. One summary line per commit, with a full log underneath. It costs almost nothing to maintain and it means the AI always knows what the project looked like yesterday.

## **What You Should Actually be Thinking About**

![Photo by Mariia Shalabaieva on Unsplash](https://miro.medium.com/v2/resize:fit:1400/0*xvAyd9xk4xBOiVQv "Photo by Mariia Shalabaieva on Unsplash")

The mental shift is this: AI handles execution, you handle architecture.

Stop sweating the exact \`chmod flags. Start asking:

*   Are our Cloudflare token permissions correctly scoped?
    
*   Is the Nginx configuration locked down the way it should be?
    
*   Are Docker images being cleaned up between deployments?
    
*   Are dependencies patched? Stale packages are one of the most common security vulnerabilities.
    
*   Have service accounts accumulated permissions they shouldn’t have?
    

These are judgment calls. The YAML syntax, the certbot command flags, the GitHub Actions step structure, those are just execution. Let the agent handle them.

## **One last thing**

At [Elephant Stripes](https://elephantstripes.ai/), this is how we build. Structured, AI-assisted delivery from initial build through to production deployment, for clients who want something built well without the enterprise overhead.

If you’re building something and want a team that knows how to ship it, we’d love to hear about it! Drop your comments below.

The app wasn’t there before. Now it is. That’s all deployment ever really is.

Full deployment process available on Elephant Stripes Youtube account!

@[youtube](https://www.youtube.com/watch?v=CnOFBjkl-to)

* * *

_If you’re looking to rebuild your product or workflows for the AI era, feel free to contact_ [_ElephantStripes_](https://elephantstripes.ai/)_. We combine AI-driven speed with human judgment to build software that actually fits._

_Subscribe to our YouTube channel for daily AI tips:_ [https://www.youtube.com/@elephantstripesai](https://www.youtube.com/@elephantstripesai)

I Let AI Do My DevOps. Here’s What Happened.

Nine phases. One Oracle server. Zero terminal anxiety.

Nine phases. One Oracle server. Zero terminal anxiety. Deploying an app is like riding a bike. Once you’ve done it properly, you can do it again..

Your SEO score drops after a hosting migration. You know something broke. You just don’t know what, where, or how deep it goes.

That’s exactly where I was after moving [Elephant Stripes](https://elephantstripes.ai/), our consulting firm’s website, from Namecheap to Cloudflare over the weekend.

PageSpeed Insights flagged a robots.txt error and knocked us down from a clean score to a 92. Not bad, but not right either. Something was off.

I used Codex to find it, fix it, and automate the whole process going forward.

## **Why Bother Connecting AI to Your Site Infrastructure?**

![Photo by Justin Morgan on Unsplash](https://miro.medium.com/v2/resize:fit:1400/0*iunCofKdbJEhdncq "Photo by Justin Morgan on Unsplash")

Most developers manually check PageSpeed, manually poke around Cloudflare, and manually toggle settings until things look right.

Well, that works. But when you’re running multiple client sites, it doesn’t scale.

The approach I’m showing you here connects AI directly to your APIs. That means Codex can pull live data, reason about it, and take action, all without you clicking through a dozen dashboards.

It’s a small workflow change with a big compounding effect.

Now, let me show you how I do it, step by step.

## **Step 1: Run a PageSpeed Insights Audit**

Start at [PageSpeed Insights](https://pagespeed.web.dev/). Put your URL in and run both the mobile and desktop reports.

Desktop will almost always score higher. That’s expected. You’re working over fixed connections with more predictable load speeds. Mobile is the harder benchmark.

![PageSpeed insights from Elephant Stripes’ website](https://miro.medium.com/v2/resize:fit:1400/1*fiOM0x1eHTL0nNdOQOSP9Q.png "PageSpeed insights from Elephant Stripes’ website")

What you’re looking for is your SEO section specifically. In my case, the score was 92 out of 100. Solid, but PageSpeed flagged one thing:  
**_the robots.txt was invalid_**_._

That single issue is what we’re going to trace and fix.

Don’t try to investigate manually at this point. You won’t have enough context to know where the problem actually lives. That’s what the next steps are for.

## **Step 2: Set Up Your Project Context for Codex**

Before you open Codex, make sure your project is structured properly. This is something people skip, and it makes AI-assisted development significantly worse.

At minimum, your project should have:

[**AGENTS.md**](http://AGENTS.md): This file contains your instructions for how AI agents should work in this project. Think of it as your team handbook for Codex. What tools it can use, what conventions to follow, what to avoid.

![](https://miro.medium.com/v2/resize:fit:1400/1*hfJ5Vsdex0nbQCOH9OQHow.png)

[**README.md**](http://README.md): This tells the project context. What the site does, how it’s structured, what the key rules and constraints are.

![](https://miro.medium.com/v2/resize:fit:1400/1*GTH5J7URlq0a_XAU8dqieg.png)

Codex reads both of these before it does anything. That grounding makes every subsequent prompt more targeted and useful.

If you don’t have these files yet, start simple. Even a hundred words in each file is better than nothing.

## **Step 3: Create a New Branch Before Touching Anything**

Open VS Code and fire up Codex. Before you ask it to do anything, have it create a dedicated branch.

For this task, I named it: **seo-robots-txt-optimisation.**

You don’t have to work this way. You can work directly on main if you want. But branching is cleaner, safer, and makes it easy to review what changed before you merge anything back.

Codex can create the branch for you with a simple prompt. Something like:

**_“Switch to a new branch called seo-robots-txt-optimisation and read_** [**_agents.md_**](http://agents.md) **_and_** [**_README.md_**](http://README.md) **_before we start.”_**

![The prompt used to instruct Codex to create the dedicated branch.](https://miro.medium.com/v2/resize:fit:1400/1*o4oa1cF5OH60Izn8dF0pjw.png "The prompt used to instruct Codex to create the dedicated branch.")

The prompt used to instruct Codex to create the dedicated branch.

That one step sets the context for everything that follows.

## **Step 4: Connect to the PageSpeed Insights API via Google Cloud**

This is where things get useful.

Rather than reading PageSpeed results manually through a browser, you can pull the data programmatically through the PageSpeed Insights API inside Google Cloud.

The setup looks like this:

1.  Create a Google Cloud project for your site (I have one for Elephant Stripes)
    
2.  Enable the PageSpeed Insights API in that project
    
3.  Create a service account with the right permissions
    
4.  Download the service account JSON key and store it in a secrets/ folder in your project (not committed to GitHub)
    

Once that’s done, you can tell Codex to use that service account to pull the PageSpeed report directly.

My prompt was essentially:

**_“Use the service account in secrets/ and the PageSpeed Insights API runbook to download the PageSpeed report for_** [**_elephantstripes.ai_**](http://elephantstripes.ai)**_. Save it to the working folder.”_**

Codex runs the report, pulls the data, and surfaces exactly what PageSpeed Insights would show you in the browser, but now it’s in your project where Codex can reason about it.

The report confirmed: SEO score 92 on mobile, 100 on desktop. And the robots.txt issue was flagged.

## **Step 5: Understand What Codex Found**

This is the part that would have taken me ages to figure out manually.

Codex read the live robots.txt being served at the domain and compared it to the robots.txt in the codebase. They didn’t match.

The finding was this:

**Cloudflare was prepending its own Managed Content Signals block to the live robots.txt.** This added a series of Disallow rules for AI crawlers before the app’s own Allow rules. The local file didn’t include any of that. So what PageSpeed Insights was reading, and what my actual codebase said, were two different things.

This is a Cloudflare edge configuration issue, not a code issue. The code was fine. The problem was how Cloudflare was serving the file at the network layer.

Without API access and Codex reasoning across both systems, I probably would have spent an hour checking the wrong things.

![](https://miro.medium.com/v2/resize:fit:1400/1*qyrG9E0nI9Aw9FZBKCQy0w.png)

## **Step 6: Check Cloudflare via API**

Now that we knew where the problem was, the next step was to look at Cloudflare’s bot management settings directly.

![](https://miro.medium.com/v2/resize:fit:1400/1*K4IvYwTxrTmIDerXFkT3Rg.png)

I already had a Cloudflare API token set up for Elephant Stripes with the right permissions: specifically, bot management read and update access.

I also had a Cloudflare performance runbook in my project docs that tells Codex how to interact with the Cloudflare API.

My prompt was:

**_“Use the Cloudflare API token in secrets/ and the Cloudflare performance runbook to check the bot management endpoint for_** [**_elephantstripes.ai_**](http://elephantstripes.ai)**_. Identify what’s being prepended to the robots.txt and fix it if you can.”_**

Codex hit the bot management endpoint, found the configuration that was causing the prepend behaviour, and reset it.

That’s it. The fix took less than two minutes once we knew what to look for.

## **Step 7: Verify the Fix**

After Codex resets the configuration, go back to PageSpeed Insights and re-run the audit.

Check that:

*   The robots.txt is now marked as valid
    
*   Your SEO score has held or improved
    
*   No new issues have appeared as a result of the change
    

In our case, the robots.txt came back clean. The Cloudflare prepend was gone, and the SEO score came up.

The whole process from the first audit to the verified fix took under 20 minutes.

## **The Bigger Picture: Automate It**

![Photo by Possessed Photography on Unsplash](https://miro.medium.com/v2/resize:fit:1400/0*sQzmjjr37__95q0S "Photo by Possessed Photography on Unsplash")

Running this manually is fine when something breaks. But the real value is in scheduling it.

You can set up an automated job using something like a cloud scheduler to run this exact process weekly. Codex (or another agent) pulls the PageSpeed report, checks it against your thresholds, and flags anything that needs attention.

If the report looks clean, nothing happens. If something looks off, you get an alert and you go fix it.

This is how you maintain consistent site performance across multiple clients without logging into dashboards every week. You get the report, review the flag, take action. Simple.

## **What This Workflow Actually Gives You**

![Photo by Mohammad Rahmani on Unsplash](https://miro.medium.com/v2/resize:fit:1400/0*WkUym9rO9asfW9jm "Photo by Mohammad Rahmani on Unsplash")

The specific fix here was a robots.txt misconfiguration caused by a Cloudflare migration. But the workflow transfers to almost any site health problem.

When you connect your AI tooling to Google Cloud and Cloudflare APIs, you can:

*   Pull performance benchmarks automatically
    
*   Detect configuration drift after deployments
    
*   Review nginx and server settings via script
    
*   Check security configurations at the edge
    
*   Run CI/CD health checks as part of your deployment flow
    

It’s not magic. It’s just connecting systems that would otherwise live in separate dashboards and giving Codex the context to reason across all of them.

The migration to Cloudflare introduced a subtle edge-layer issue that PageSpeed caught and Codex diagnosed. Manually, that’s a rabbit hole. With this setup, it’s a twenty-minute fix.

## **Quick Summary**

@[youtube](https://www.youtube.com/watch?v=QKbkdtCXBBE)

Here’s the process end-to-end (TL;DR)

1.  Run PageSpeed Insights and identify your SEO issue
    
2.  Set up [agents.md](http://agents.md) and [README.md](http://README.md) in your project
    
3.  Create a new branch in Codex before making changes
    
4.  Connect to the PageSpeed Insights API via a Google Cloud service account
    
5.  Let Codex pull and interpret the report
    
6.  Use the Cloudflare API token to investigate edge-layer configurations
    
7.  Apply the fix and verify with another PageSpeed run
    
8.  Automate the whole thing on a weekly schedule
    

If you’ve already got Google Cloud and Cloudflare set up, steps 3 through 6 take minutes. The groundwork is the only slow part, and you only build it once.

* * *

_Planning to cover how Google Analytics and Google Tag Manager connect to this same setup in the next video. Stick around if that’s on your radar._

_Subscribe to Elephant Stripes’_ [_YouTube channel_](https://www.youtube.com/@elephantstripesai) _for more AI updates and tutorial!_

How I Used Codex to Fix My SEO in 20 Minutes

A step-by-step guide to AI-driven site fixes


A step-by-step guide to AI-driven site fixes Your SEO score drops after a hosting migration. You know something broke. You just don’t know what, where...

Imagine you run a business. Sixty employees. Every workflow, every automated process, every AI agent your team depends on runs through one cloud provider.

Then one morning, the account gets flagged. Locked. And the only way to reach anyone is through a contact form.

That actually happened. A Spanish entrepreneur I came across on X was in exactly that position with his Claude account.

I do not know how it was resolved. But the story is the real point: this is what happens when you build your entire AI agent operation on someone else’s infrastructure.

The industry needs to have this conversation right now.

## **Everyone is Betting on The Wrong Thing**

![Photo by Nick Fewings on Unsplash](https://miro.medium.com/v2/resize:fit:1400/0*IcO0ma1J4EyyKhOL "Photo by Nick Fewings on Unsplash")

AI agents are going to be how the majority of businesses use AI in the future. That is not a particularly original prediction at this point.

What often goes unaddressed, however, is the question of **_where_** those agents will actually run.

Most businesses currently think about AI as a subscription service: they pick a provider, pay per token, and scale as needed.

It feels straightforward. But there is a structural problem underlying that model, and it will become very obvious over the next two to three years:

> **_Cloud AI pricing is not real yet. It is subsidised by investor capital._**

Anthropic, OpenAI, and every other frontier lab are spending far more on compute than they are collecting from customers. That gap is filled by venture funding. Investors are underwriting cheap AI access to drive adoption. That strategy has a shelf life.

When those investors start demanding returns, the AI cost equation changes. Token costs go up. Variable costs baked into your agent workflows go up with them. And if your entire operation is running through one provider’s API, you have no leverage when that happens.

## **Apple Spotted This Before Anyone Else**

![John Ternus, Apple’s likely next CEO, whose hardware background signals the company’s strategic bet on local AI.](https://miro.medium.com/v2/resize:fit:1400/1*scm6Lsl9DmeCMn-SDbwwHg.png "John Ternus, Apple’s likely next CEO, whose hardware background signals the company’s strategic bet on local AI.")

A detail makes all of this click into place.

Apple recently appointed two hardware executives to the very top of the organisation. That is a strange move for a company that has been behind on AI.

The move is about cornering the market on local AI compute.

Nate Jones made this argument compellingly in his video “**_Apple Just Positioned Itself for the Next Trillion Dollars_**,” and I think he is right. Apple is making the same bet it made in the 1970s and 80s.

Back then, computing lived in mainframes. Expensive, centralised, and controlled by a handful of vendors. Power users paid the cost because they had no alternative.

Then the Apple II arrived. It was not as powerful as a mainframe. But it was good enough, cheap to run, and most importantly, it was yours.

Power users left the mainframes. The personal computer era began.

Apple is betting that history repeats. Cloud AI is the mainframe. Local AI, running on personal hardware or on-premises servers, is the Apple II. And the transition is already starting.

The Mac Mini craze around open source tools like OpenClaw was an early signal: developers running capable AI locally, not because local models beat GPT-4 on benchmarks, but because they were controllable and the AI cost was essentially just electricity.

## **What Enterprises Actually Want**

![Photo by Nguyen Dang Hoang Nhu on Unsplash](https://miro.medium.com/v2/resize:fit:1400/0*dJeovD_xH8J1oq2x "Photo by Nguyen Dang Hoang Nhu on Unsplash")

When the conversation gets practical, businesses say this.

They do not necessarily need the smartest model. They need a model that is predictable, that does not expose sensitive data to third-party infrastructure, and that does not come with variable costs that make financial planning impossible.

Maybe that model is not as sharp as Claude or GPT-5 on complex reasoning tasks. Fine. If it runs on _your_ servers, it handles your data, and you pay for electricity rather than per-token fees, the trade-off is often worth it.

This is especially true for sectors like law, healthcare, finance, and government. These industries have compliance requirements that make cloud-everything a non-starter.

They also have large volumes of routine human labour that AI agents can absorb, but only if those agents are reliable and cost-controlled over the long term.

## **The Agent Stack that Actually Makes Sense**

![](https://miro.medium.com/v2/resize:fit:1400/1*T_Nd0aKNrCXt6VhDD4c7qA.png)

At [Elephant Stripes](https://elephantstripes.ai/), this is how we think about building agent systems that hold up.

You start with a single interface. Something the organisation already uses, whether that is Slack, Teams, Discord, or any other chat platform. Staff interact with agents the same way they already communicate at work. No new interface to learn.

Behind that interface sits an open source orchestration layer. Frameworks like OpenClaw and Hermes are the ones we follow closely.

They give you genuine control over how your agents work: memory management, both short-term and long-term, and the ability to route calls to different models depending on what the task actually requires.

From that layer, you can send calls to frontier model APIs when the task demands it. But you can also fall back to an open source model running on-premises.

A cheap VPS. A Mac Mini sitting in a server room somewhere. Something that is yours, that runs on your infrastructure, and that works even when everything else goes wrong.

Built-in redundancy is not a bonus feature. It is the whole point.

## **IT Teams are About to Have a Very Different Job**

![Photo by Shamin Haky on Unsplash](https://miro.medium.com/v2/resize:fit:1400/0*EIcA4su1o5nUJiG8 "Photo by Shamin Haky on Unsplash")

The traditional IT function, managing software licences, user accounts, and system security, is not disappearing. But a new layer is being added on top of it.

The IT teams that will matter most over the next five years are the ones that can manage agents. That means tracking which agents are running, how much compute each is consuming, and what models are powering them.

It also means prototyping new functionality on frontier models, then actively working to shift that functionality to smaller, cheaper, or open source models as quickly as the task allows. Frontier models for research and development. Smaller or open source models for production and everyday operations.

That cycle is where the cost discipline comes from, and it is also where the technical skill is going to sit. Demand for people who can build and optimise this kind of stack is going to be significant.

I think it is actually a great time to be a programmer who understands this space.

## **Why Open Source Wins the Critical Layer**

![Photo by Markus Winkler on Unsplash](https://miro.medium.com/v2/resize:fit:1400/0*pGKF7_y_mmxy167p "Photo by Markus Winkler on Unsplash")

Between enterprises and the big model providers, there is going to be a layer of open source tooling that businesses depend on deeply. That layer is where the control sits.

Proprietary cloud platforms give you convenience. Open source agent frameworks give you something more valuable: the ability to make your own decisions.

Which model gets called for which task? Yours to decide. How much memory does each agent carry? Yours to configure. What happens when a provider goes down, changes its pricing, or locks your account? You have a fallback because you built one in.

That is the core of why I am enthusiastic about open source frameworks in this space. They are well-built, and they shift the power dynamic back toward the people building with them.

## **The Realistic Picture**

I want to be clear about something: **I am not saying cloud AI is going away.** Frontier models are getting better at a remarkable pace, and for genuinely complex reasoning tasks, they remain impressive tools.

But the current model, where businesses pipe everything through a single cloud provider’s API with variable AI costs and a contact form as their primary support channel, is not a stable long-term arrangement.

The Spanish entrepreneur with 60 staff and one form to submit is not an edge case. It is a preview.

The businesses that figure this out early will build agent infrastructure they control. They will use frontier models as a high-performance tier, not as a foundation. They will treat open source frameworks as their backbone, and local compute as their safety net.

AI agents are going to be how most businesses run on AI. The ones that win will make sure those agents are not someone else’s to switch off.

My thinking on all of this is still developing. But the direction feels clear.

I would genuinely like to hear _your_ take.

* * *

_This article grew out of a longer video I recorded for the Elephant Stripes YouTube channel. You can watch the full video here:_

@[youtube](https://www.youtube.com/watch?v=iTm5AcHCofY)

_At Elephant Stripes, we help businesses build AI agent systems that they actually own and control. If that is the direction your organisation is heading, come find us at_ [_elephantstripes.ai_](http://elephantstripes.ai)

The Trillion-Dollar AI Bet: On-Premise, Not Cloud

Why Apple, enterprises, and smart builders are going local. Imagine you run a business. Sixty employees. Every workflow, every automated process, every AI agent your team depends on runs through one cloud provider. Then one morning, the account gets flagged...

Why Apple, enterprises, and smart builders are going local. Imagine you run a business. Sixty employees. Every workflow, every automated process, every AI...

Naval Ravikant had his AI epiphany in December 2025. He called it “A Return to Code” and described the moment he could ship one-shot custom apps with Claude Code or Codex. It’s a great podcast. You should watch it.

My epiphany hit a few months earlier. Same tool. Completely different use case.

I do not use Codex like a junior developer assistant. I use it as a **DevOps** partner.

And that shift changes everything.

## **Why DevOps specifically?**

![Photo by Luca Bravo on Unsplash](https://miro.medium.com/v2/resize:fit:1400/0*orIUlDwE0HwYyM0i "Photo by Luca Bravo on Unsplash")

It all started with a server audit.

I was staring at our production server, which runs PM2, Docker, and a handful of different apps, trying to figure out whether our security posture was actually any good.

**_Were our DNS entries correct? Was our nginx setup tight? Were we caching properly? Were there vulnerabilities we’d missed?_**

These aren’t coding questions. They’re DevOps questions. DevOps is a discipline with an enormous surface area. DNS, caching, server configuration, CI/CD pipelines, security hardening, and error monitoring.

It touches everything, it requires specialist knowledge across multiple tools, and it has historically been expensive to get right.

You either pay for a dedicated DevOps person, contract a specialist, or you do what most small teams do: wing it and hope nothing catastrophic happens.

The AI cost argument here is straightforward. The human labour involved in proper DevOps oversight used to be substantial.

Now it doesn’t have to be. And it’s because I decided to give Codex access to everything.

## **Connecting The Whole Stack**

![Photo by Omar:. Lopez-Rincon on Unsplash](https://miro.medium.com/v2/resize:fit:1400/0*PRv8PTmfW0Eg9IYe "Photo by Omar:. Lopez-Rincon on Unsplash")

I set up access in a fairly straightforward way.

First, a GitHub personal access token so Codex could see what actions were running. Then I built out a Google Cloud project, gave it ownership permissions, and wired up APIs for Google Analytics, PageSpeed Insights, and Tag Manager. After that, Cloudflare access and direct server access.

Five or six services, all connected.

Then I just asked it questions.

> **_“Look across all of these and tell me what our cybersecurity looks like. How do we harden it? What does our caching look like? PageSpeed is flagging these errors. You can see our nginx config. What should we change?”_**

That was the AHA! moment.

It wasn’t “write me a function” or “fix this bug.”

It was a systems-level conversation across every service we run, all at once.

## **The Answer was Better Than I Expected**

![Photo by Robert Wiedemann on Unsplash](https://miro.medium.com/v2/resize:fit:1400/0*n8mUmvaLdg_2TYKK "Photo by Robert Wiedemann on Unsplash")

Our CI/CD pipeline is now several orders of magnitude better than it was. The improvements compound: tighter security, better caching, DNS entries that are actually correct, and error monitoring that catches things before users do.

Codex checks the server. It checks available disk space. It flags DNS issues. It reads error logs and tells me what’s wrong.

The amount of human labour this replaces is significant. It doesn’t do everything, but it closes the gap between “_something is probably wrong somewhere_” and “_here’s exactly what’s wrong and here’s how to fix it._”

I genuinely can’t believe more people aren’t using AI for DevOps.

## **Building the CMS I Actually Wanted**

The DevOps breakthrough changed what I thought was realistic to build and maintain.

Our website had been through a few different configurations. It started as a Hugo site: static, markdown-powered, genuinely fast. Then we moved to Forestry for proper CMS features. Then to Strapi because VideoTranslatorAI needed proper multilingual publishing support. That meant a Strapi and Gatsby stack, and the maintenance overhead was significant.

Then Gatsby started to quietly lose momentum as a project.

That was the point where I stopped trying to maintain the existing setup and built something new from scratch.

The process was iterative. Build what you think you want. Use it for a while. Discover the gaps you hadn’t imagined. Close them. Repeat.

What came out the other end is a bespoke CMS with email capability built in, no dependency on third-party projects that might stop being maintained, and performance numbers that most agencies would be proud of.

![The CMS that i built for Elephant Stripes.](https://miro.medium.com/v2/resize:fit:1400/1*tInkzU2eSCfpOZ2-tUE7mw.png "The CMS that i built for Elephant Stripes.")

PageSpeed scores are excellent. The site is fast in a way the Strapi-Gatsby setup never was. It does exactly what we need. The maintenance overhead compared to what we were running before is dramatically lower.

Human labour: **down**. AI cost to maintain: **minimal**.

## **You Can Have This Too**

![](https://miro.medium.com/v2/resize:fit:1400/1*x4Qlnm71zS5q7EVjlJ8bPQ.png)

If you want a CMS built the same way, with the performance, the bespoke fit, and none of the bloat, that’s exactly what [Elephant Stripes](https://elephantstripes.ai/) does.

Elephant Stripes is a bespoke app development service. We don’t sell templated solutions. We sit down with you, usually for a few hours in the first session, and we build in front of you. You see it take shape in real time. You can redirect it, add to it, and push back on scope when needed.

By the end of that session, you know what you’re getting. You’ve seen it built. And the gap between what’s in your head and what ends up in production is a lot smaller than it would be if you handed over a spec doc and waited six weeks.

If that sounds like something you need, reach out via [Elephant Stripes](https://elephantstripes.ai/contact)!

## **The Bigger Point**

Naval frames the current moment as a renaissance for individual software creators. I think he’s right, but the frame is slightly too narrow.

Coding has been democratised, and so have operations, infrastructure, and systems oversight; the disciplines that used to sit between developers and the rest of the business.

The teams that realise that AI isn’t just a code editor but an entire operational layer will build much stronger foundations than those who use it only for features.

Vibe coding got me back into building. DevOps is what made the building worth doing properly.

That’s the part nobody’s writing about.

* * *

_If you want the full context behind these ideas, you can listen to Naval Ravikant’s A Return to Code podcast here:_ [](https://nav.al/code)[_https://nav.al/code_](https://nav.al/code)

_I also shared my complete reaction and breakdown on YouTube:_

@[youtube](https://www.youtube.com/watch?v=DkJI-3pzaYU)

I Gave My AI Server Access. It Became A Great DevOps Partner.

They fired engineers. AI bills hit $15K. Still won’t rehire. Something interesting is happening on X right now. A handful of viral posts are declaring that soaring AI costs are reversing the great layoff wave...

I Gave My AI Server Access. It Became A Great DevOps Partner

I gave my AI server access, and it became a great DevOps partner. Naval Ravikant had his AI epiphany in December 2025. He called it “A Return to Code”...

AI can now write code, produce entire music albums, and design products overnight. The access is real. The speed is real.

And the **_slop_** is very, very real.

Scroll through any app marketplace, music playlist, or design portfolio today and you’ll find the same thing: technically competent output that feels hollow. Correct but somehow lifeless. Finished but never actually done.

Here’s what’s happening. The cost of execution has dropped to near zero. You can spin up a feature, a logo, a sample pack, or an entire codebase with a handful of prompts. But the thing that separates a product people love from a product nobody notices? That’s still the same as it’s always been.

> **Taste**.

This is the AI taste moat. And two creators explained it better than any researcher or analyst has: Peter Steinberger, the indie developer behind OpenClaw, on the builder’s side; and Diplo, one of the most commercially successful music producers of the past two decades, on the creator’s side.

Their message is the same even though their worlds are completely different. _Execution is now free. Taste is the last scarce resource._

Diplo put his entire career into a single sentence: _“I’m in a position now where I can use these tools really effectively because people already trust me for my taste and what I do.”_

Steinberger named the failure mode builders keep running into: agents that run all night and produce “the ultimate slop” because nobody with taste stayed in the loop.

Two industries. One thesis.

If you’re still optimising prompts instead of curating taste, you’re building on the wrong side of the moat.

## **Steinberger’s Warning: The Agentic Trap**

![Source: X](/api/media/elephantstripes-prod/cms/originals/blog-inline/ebb9f77d9ef2e76b2f96593cd2f7a1a611023d8a76fbcad597b116319b87f06f.avif "Source: X")

Peter Steinberger didn’t mince words.

_“You can create code and run all night and then you have like the ultimate slop because what those agents don’t really do yet is have taste.”_

That line landed hard across developer circles for a reason. It names something builders have been quietly noticing but haven’t wanted to say out loud. You can automate the output. You cannot automate the compass.

Steinberger went further:

_“They are spiky smart and they’re really good at things, but if you don’t navigate them well, if you don’t have a vision of what you’re going to build, it’s still going to be slop. If you don’t ask the right questions, it’s still going to be slop.”_

The agentic trap is what happens when you remove yourself from the process too early. You front-load a perfect spec, hand it to an agent, and walk away expecting something coherent to emerge. What you get instead is highly competent output with no internal compass.

Steinberger describes his own process differently. He starts rough. He plays with the output. He lets his next step emerge from what he sees and feels in the current state of the project.

_“My next prompt depends on what I see and feel and think about the current state of the project. But if you try to put everything into a spec up front, you miss this kind of human-machine loop. And then I don’t know how something good can come out without having feelings in the loop — almost like taste.”_

@[youtube](https://www.youtube.com/watch?v=AcwK1Uuwc0U)

This is the real insight. Not that agents are bad. Not that AI-assisted development is a mistake. It’s that the feedback loop between human taste and machine output is where the actual quality lives.

Think about it in concrete terms. A solo founder who iterates a feature 40 times in a single evening, each time responding viscerally to what feels off, ships something people actually use. The team that lets agents run unsupervised for 12 hours ships something polished and forgettable.

Agent scaffolding is improving fast. Self-critique loops are getting smarter. But the human taste anchor is still 100% required.

Prompting is the new typing. Taste is the new thinking.

## **Diplo’s Take on References, History, and the Pop Factory**

![](/api/media/elephantstripes-prod/cms/originals/blog-inline/7dfaae5a2bcae368911eda363399df9def69d584bac821c8cbf6882468d44452.avif "Source: X")

Diplo is not anti-AI. He made that very clear.

_“You’re not gonna win. There’s no fighting AI. You have to just work your best to be the best at it right now. You’re wasting your time.”_

He told a story about a young producer he had recently signed. They sat down together, fired up Udio, and made three goth-style beats in five minutes. The producer looked at him and said: _“I’m cooked, right?”_

Diplo’s answer was honest. _“I don’t know, man. Maybe.”_

But then he explained his own position. People already trust him for his taste. That trust is the product. The AI is just the fastest production line he has ever had access to.

His edge is not his software. It is not his prompt library. It is two decades of deep cultural fluency, from 1973 Jamaican dub to 2006 Baltimore club to 2008 blog-house and beyond.

It is the references. It is the history. It is the accumulated signal that lets him know, in five seconds, whether something is worth pursuing or not.

The tweet summarising his interview captured it cleanly: _“Taste and references matter A LOT. That is what makes me good at using AI because I know how to prompt something specifically. You have to have knowledge. You have to have history.”_

@[youtube](https://www.youtube.com/watch?v=zFVpJFFN3dI)

Most people pressing the same buttons do not have that layer. They work from descriptions. Diplo works from memory, intuition, and a reference library that took years to build.

And that gap only grows wider as the tools get better.

The 99% with access to the same AI tools still produce “good enough.” The 1% with genuine taste and deep references produce something that feels human-directed, alive, and worth paying for.

Your reference library is now more valuable than your prompt library.

## **Why References Beat Prompts: The New Moat Explained**

![Photo by Sanket Mishra on Unsplash](https://miro.medium.com/v2/resize:fit:1400/0*AVRhken-uV8Ov3VH "Photo by Sanket Mishra on Unsplash")

There is a simple way to understand why taste has become the moat.

Prompts are tactical instructions. They describe what you want. AI gets better at executing on tactical descriptions every month. By the time you have mastered a prompting technique, a newer model has made that technique mostly obsolete anyway. Prompting is a skill, but it is a depreciating one.

References and taste are something different. They are pattern recognition developed over years of deep attention to what works and why. They are emotional intelligence about what a piece of work needs to become. They are personal weirdness, accumulated preferences, and the willingness to trust your gut over the consensus.

Think of it this way. Prompts are the steering wheel. Taste is the map, the destination, and the reason you are driving in the first place.

The evidence is already visible. App stores are saturated with AI-generated productivity tools that are functionally identical and emotionally indistinguishable. Music streaming platforms are drowning in AI-assisted tracks that technically pass quality thresholds and generate no emotional response. The content that breaks through is increasingly the content that feels like a specific person made a specific decision about what it should be.

Compare the eras. In the 2010s, attention was the moat. Whoever captured and held attention could build a business around it. In the early 2020s, distribution was the moat. Whoever could reach an audience at scale had leverage. In 2026 and beyond, taste is the moat.

The counterpoint is real: models are getting better at simulating taste. They can mimic aesthetic preferences at a surface level. But simulation is not origination. The human who has actually spent years absorbing references, developing opinions, and learning to feel the difference between what is good and what is right still wins. Because they know what the simulation got wrong.

The premium product will always be the one that feels human-directed, even when 90% of the labour is AI.

## **A Practical Framework for Building Your Taste Moat**

![Diplo’s performance at Tomorrowland 2022 (Source: YouTube)](https://miro.medium.com/v2/resize:fit:1400/0*_UOqkP-_4hn0Z77p.jpg "Diplo’s performance at Tomorrowland 2022 (Source: YouTube)")

The good news: taste is a skill, not a gift. It grows with deliberate practice.

**Start with a taste vault**

Collect 50 to 100 specific examples of work you love across mediums. Not work that is considered good. Work that actually moves you, surprises you, makes you want to understand how it was made. Pull from this vault when you are prompting instead of describing from scratch. “Make something that feels like this specific thing” beats “make something good” every single time.

**Use the Steinberger loop, not the hands-off spec**

Do not hand agents a spec and disappear. Set 15 to 30 minute checkpoints. Stop. Interact with the live output. What feels wrong? What wants to become something? Let your next move come from that gut reaction, not from a document you wrote before you saw anything.

**Dedicate time to reference building**

One hour a week. Pick one artist, era, movement, or product category. Go deep, not broad. Write down what you notice. What surprises you. What you would steal. Share it publicly. Teaching what you find is one of the fastest ways to make it stick.

**The one honest question**

Before each prompt, ask yourself: do I actually know what this should feel like, or am I describing it from the outside? If you are describing, stop. Find a specific reference first.

## **So, Are You Cooked?**

Back to Diplo’s young producer.

The honest answer is: it depends entirely on what he does next.

If he treats AI as a shortcut to output, he will produce the same averaged content as everyone else using the same tools. If he spends the next two years deep in references, building his palate, understanding not just what sounds he likes but why they work and where they came from, he builds something the tools cannot replicate.

That is the actual play.

AI democratises execution. It makes taste more valuable. The creators and builders who understand this early will build moats that take years to cross.

Peter Steinberger is building software with this approach. Diplo is making music with it.

The tools are not the advantage. The taste behind them is.

* * *

_Share your own taste moat experiments in the comments or on X. The original interviews are worth your time:_ [](https://x.com/realBigBrainAI/status/2043668202061017177)[**_How OpenClaw’s Creator Uses AI to Run His Life in 40 Minutes | Peter Steinberger_**](https://www.youtube.com/watch?v=AcwK1Uuwc0U) _and_ [](https://x.com/jameygannon/status/2043788602467913966)[**_Why Diplo’s Weirdest Ideas Became the Biggest Songs in the World (Full Interview)_**](https://www.youtube.com/watch?v=zFVpJFFN3dI)**_._**

_Taste is not going away. It is finally getting the economic value it always deserved._

How ‘taste’ became the last scarce creative resource. AI can now write code, produce entire music albums, and design products overnight. The access is real.

You Run Agents All Night. Then Get Slop.

Last week, a single post took over the AI corner of the internet.

17 million people saw it. 94,000 bookmarked it. Thousands replied with positive responses.

The post was from Andrej Karpathy, one of the founding researchers at OpenAI and former head of AI at Tesla.

He wasn’t announcing a new model or a product launch. He was describing how he now uses AI to manage his own knowledge.

The idea itself is not even complicated. But what it represents for how we can use AI to genuinely get smarter is worth understanding properly.

![Andrej Karpathy's post on LLM Knowledge Bases](https://storage.googleapis.com/vtai-web-media-prod/cms/originals/blog-inline/15a9f1d3fdda7317e315eb98892f0f9e8b74a01aafa7f5f5cb0e0e064cf5bff4.avif "Andrej Karpathy's post on LLM Knowledge Bases")

_(See Karpathy's original X post_ [_here_](https://x.com/karpathy/status/2039805659525644595?s=20)_)_

## **The Problem Every Learner Shares**

![Photo by Bret Kavanaugh on Unsplash](https://miro.medium.com/v2/resize:fit:1260/0*8CNDYLf9CpoKy8v7 "Photo by Bret Kavanaugh on Unsplash")

Here’s a question: **where does your knowledge go?**

You read an interesting article. You listen to a great podcast. You take notes in a meeting that actually mattered. But after that, what happens? **_Most of it evaporates._** What doesn’t evaporate gets buried in a folder you rarely open, or a notes app you abandoned six months ago.

This isn’t a character flaw. It’s a structural problem. Human memory isn’t built for filing and cross-referencing. It’s built for pattern recognition and meaning-making. We’re terrible at storage. We’re great at reasoning.

Now, imagine you have a **librarian** who never sleeps. Every time you add a new article to the pile, the librarian reads it, extracts the key ideas, figures out how they connect to everything already in the collection, writes a clear summary, and updates the index.

If a new source contradicts something the collection previously said, the librarian flags it. If there is a gap in the knowledge, the librarian notes that too. The collection grows smarter with every new thing you add.

That is what Karpathy built. Except that the librarian is an AI.

## **Karpathy’s Idea, in Plain Language**

![Photo by Aerps.com on Unsplash](https://miro.medium.com/v2/resize:fit:1260/0*8fL36G7u0_Nks1sc "Photo by Aerps.com on Unsplash")

Karpathy starts by collecting raw material: articles, research papers, transcripts, datasets, images, whatever is relevant to a topic he’s researching. He drops these into a folder. Then he hands that folder to an AI.

The AI doesn’t just summarise what it finds. **It builds a wiki**. A structured collection of interlinked articles: one for each concept, each person, each idea that appears across the sources.

Think of it as a Wikipedia you’ve built specifically for your own research area, written by an AI that has read everything you’ve ever saved on the topic.

When his wiki on a recent research project hit around 100 articles and 400,000 words, something interesting happened. He could ask complex questions and the AI would go off and research the answers using the wiki it had already built. Cross-referencing. Drawing conclusions. Flagging gaps. All without starting from scratch.

Here’s the key difference from other AI tools. When you ask ChatGPT a question, it answers based on what it was trained on and what you’ve just told it. There’s no memory. No accumulation. Next time you come back, you start over.

With an AI wiki, every question you ask, every source you add, and every answer you file back in makes the system smarter. Knowledge compounds. The wiki becomes more useful the longer you use it, not less.

## **Why This Went Viral?**

![Source: X](https://storage.googleapis.com/vtai-web-media-prod/cms/originals/blog-inline/6cecdc271d35b2a7bd7eb04a70c24cc7187a3486490673ff110cff245295ee6e.avif "Source: X")

Developer and analyst [Akash Gupta](https://x.com/aakashgupta) put his finger on why this idea spread so fast.

Karpathy didn’t release an app. He released a one-page description of the concept, what Gupta calls an “idea file.”

Anyone can paste that description into an AI agent and say: “_Build me one of these, adapted to my setup.”_ The agent handles the translation.

In the old model, you’d share a repo on GitHub and maybe 2% of people would actually get it running. With an idea file, the gap between “saw this cool thing” and “have my own version working” collapses from days to hours.

As Gupta put it:

> **_“Software distribution is becoming a game of telephone where every recipient gets a better version than the original.”_**
> 
> ## **7 Things That Make Your Personal Wiki Stick**
> 
> Realistically speaking, not guarantee that everyone who tries this will succeed. Most note systems collapse for one reason: they rely entirely on the human to maintain them. You build something thoughtful, then life gets busy, the system degrades, and eventually the guilt of not maintaining it is reason enough to abandon it altogether.
> 
> Then I came across a tweet from [Shann Holmberg](https://x.com/shannholmberg/status/2040800539546661226?s=20) that’s worth sharing. He provided a clear breakdown of seven factors that make an AI wiki actually survive long-term:
> 
> ![Credit to Shann Holmberg | Original post is available on X](https://miro.medium.com/v2/resize:fit:1260/1*QZB0gqTfGQz7sAoaUeaAfQ.jpeg "Credit to Shann Holmberg | Original post is available on X")
> 
> **1\. Keep your thinking separate from the AI’s work.** Your personal notes belong in one clean space. The AI builds in a separate workspace. This protects your original ideas from being buried under machine-generated text.
> 
> **2\. Classify every source before processing.** A peer-reviewed paper deserves different handling than a tweet or a meeting transcript. Telling the AI what it’s working with produces dramatically better output.
> 
> **3\. Force a counter-argument (bias check) section on every page.** Every article should include what the evidence doesn’t support. Without this discipline, the wiki becomes an echo chamber, confidently amplifying whatever you already believed.
> 
> **4\. Put a one-sentence summary at the top of every page.** This lets the AI scan hundreds of articles at speed without re-reading each one from scratch. It’s how the system stays fast as it grows.
> 
> **5\. File your query answers back into the wiki.** When you ask a great question and get a great answer, that answer becomes a new page. Your best thinking compounds instead of vanishing in a chat log.
> 
> **6\. Plan your structure before you need it.** Set up naming conventions, folder logic, and tags from day one. A wiki that handles 50 pages beautifully can collapse at 500 without a foundation.
> 
> **7\. Run regular health checks.** Ask the AI to audit periodically: fix contradictions, remove outdated content, connect orphaned pages, suggest what’s missing. The system self-heals.
> 
> These seven factors explain why this approach is different from every other knowledge management tool you’ve tried before. The AI does the work you could never keep up with consistently.
> 
> ## **Who Gets the Most From This**
> 
> This is the part worth dwelling on, because the practical surface area of this idea is wider than the technical discussion might suggest.
> 
> **Researchers and academics** are the most obvious beneficiaries. The problem of maintaining coherent synthesis across a growing body of literature is exactly the problem this solves. A PhD student tracking a field over three years of reading could maintain a wiki that grows more interconnected and queryable with every paper they add, rather than relying on a folder of PDFs they can barely search.
> 
> **Students in general** have a version of this problem with every subject they study. Notes from lectures, textbook highlights, supplementary articles: these rarely get synthesised into genuine understanding, partly because the work of synthesis is hard and time-consuming. A system that does the connecting for you, and lets you query it conversationally, changes what studying can look like.
> 
> **Journalists, analysts, and knowledge workers** who track a beat or domain over time accumulate enormous amounts of raw material with limited infrastructure for making it queryable. A wiki that maintains itself from clippings, interviews, and reports could become genuinely useful institutional memory.
> 
> **Anyone learning a language** has an interesting application here. Vocabulary, grammar rules, sample sentences, notes from lessons, cultural context: a personal language wiki that grows richer with every conversation and session you feed into it is a genuinely different kind of learning resource than a static app. It reflects your actual learning history rather than a generic curriculum.
> 
> This last one connects to what we are exploring at VideoTranslatorAI with our language learning app. The idea of an AI conversation partner that remembers your specific learning history and builds on it session by session is the same underlying principle: knowledge compounds when there is somewhere for it to live.
> 
> ![SpeechLobster — AI language tutor by VideoTranslatorAI](https://miro.medium.com/v2/resize:fit:1260/1*0LY10h0HC_xe1L4-9Bw6gg.png "SpeechLobster — AI language tutor by VideoTranslatorAI")
> 
> ## **Smarter, Not More Dependent**
> 
> ![Photo by ThisisEngineering on Unsplash](https://miro.medium.com/v2/resize:fit:1260/0*2EEx4JRC-YJZDuvW "Photo by ThisisEngineering on Unsplash")
> 
> The obvious worry is dependency. If AI is organising your knowledge, are you actually thinking?
> 
> It’s worth being precise about what the AI handles here. Organising, filing, cross-referencing, maintaining consistency, flagging contradictions: these are tasks that your brain handles poorly under load and that consume cognitive resources without producing insight.
> 
> What the AI does not do is decide what matters. It doesn’t form the questions you care about. It doesn’t make the connections that lead to original ideas. It doesn’t judge the quality of what it finds.
> 
> That’s still you.
> 
> Think about what writing does for memory. Keeping a record of your thoughts doesn’t make you worse at thinking. It makes your thinking more reliable, because your brain can focus on reasoning rather than trying to hold everything in working memory at once.
> 
> An AI wiki does the same thing, at a scale no notebook ever could.
> 
> Karpathy’s system has made him more productive, not less curious. That’s the right outcome to aim for.
> 
> The infrastructure for this is still being built. There’s no polished product yet. Karpathy calls his own setup “a hacky collection of scripts” and says he thinks there’s room for “an incredible new product” to emerge.
> 
> But the idea is already out there, already replicable, already spreading.
> 
> Your knowledge doesn’t have to decay. It can build.
> 
> * * *
> 
> _Karpathy’s original LLM Knowledge Bases post was published on X on 3 April 2026. His follow-up “idea file” is available as a GitHub Gist. Additional context and framing was contributed by Akash Gupta (@aakashgupta) and @shannholmberg on X. The ideas discussed in this article belong to them and are shared here to help spread awareness of a genuinely useful concept._

What If Your Notes Got Smarter Over Time?

Karpathy’s viral LLM wiki idea, explained for the rest of us Last week, a single post took over the AI corner of the internet. 17 million people saw it.

_One million_ job applications. _Zero_ interviews.

That’s not a typo. A job seeker, armed with an AI agent that could auto-apply at scale, blasted his resume across one million open positions.

Every job board. Every portal. Every listing that matched his profile. Recruiters, overwhelmed by the flood of applications pouring in, couldn’t process even a fraction of what landed in their queues. The result? Total silence.

The story, shared by entrepreneur Nabeel Alamgir on X last year, reads like a dark joke. But for anyone who has spent serious time job hunting in 2025 or 2026, it feels more like a mirror. The job market isn’t just tough. It’s structurally broken.

And AI is one of the reasons why.

![Source: X](https://storage.googleapis.com/vtai-web-media-prod/cms/originals/blog-inline/1b483f165fa7be0854031270c352fb754acf351d6d0198ad0af1315801591a0a.avif "Source: X")

## **The Doom Loop Nobody Warned You About**

![Photo by Resume Genius on Unsplash](https://miro.medium.com/v2/resize:fit:1260/0*eS3DWHLXf_ZBOGqd "Photo by Resume Genius on Unsplash")

The hiring process in 2025 and 2026 has become an AI-on-AI arms race, and ordinary job seekers are caught in the middle.

[AI adoption](https://www.herohunt.ai/blog/ai-adoption-in-recruiting-2025-year-in-review/) in recruiting surged from 26% of organisations in 2024 to 43% in 2025, with over half of companies now using AI somewhere in the hiring process. On the other side, 83% of companies said they would use AI to [review resumes](https://allwork.space/2025/10/haunted-by-algorithms-ai-recruiters-are-now-reviewing-ai-resumes-creating-a-spooky-undead-job-market/#:~:text=A%20Race%20to%20the%20Middle,the%20job%20description%20%E2%80%94%20in%20milliseconds.) in 2025, and 65% of job candidates have been using AI in the [application process](https://www.cnbc.com/2025/02/28/nearly-two-thirds-of-job-candidates-are-using-ai-in-their-applications-report-says.html).

The result is exactly what you would expect when two systems optimise against each other. When AI screening tools evaluate AI-written content, the screening step becomes pattern recognition against noise. Tools trained to find keywords find keywords, regardless of whether any real signal about a candidate’s capability sits behind them.

Reddit threads on this topic have become darkly funny in the way that only real despair can be. People describe the full pipeline:

> **AI-generated resume goes in, AI screener filters it, AI video interview runs it through facial expression and tone analysis, AI summarises the result for a recruiter who never actually reads it, and then total silence.**

One person put it plainly: _“AI resumes funnelling into AI interviews being sorted and summarised afterwards by AI.” Another responded: “I’ll take an AI interview over dead silence, but you still get ghosted after_.”

The irony is that both sides have automated themselves into a state of mutual noise. Candidates produce AI-polished applications that sound identical to each other. Screeners filter them by keyword patterns that reward sameness. The hiring manager never sees the interesting candidates because they all got filtered out for sounding too generic.

Used poorly, AI can actively hurt applications by making them seem generic or inauthentic. The people who figured this out early are already changing their approach.

## **What Actually Works (Based on Who is Getting Hired)**

![Photo by Vitaly Gariev on Unsplash](https://miro.medium.com/v2/resize:fit:1260/0*V8oUm32CRTAQNquv "Photo by Vitaly Gariev on Unsplash")

The good news is that people are still getting hired. The bad news is they’re mostly not getting hired through the channels everyone is flooding.

When Reddit’s r/recruitinghell asked in May 2025 what finally worked for people who received offers, the answers clustered around the same themes: strong portfolios, direct referrals, and human contact. Not mass applications. Not AI cover letter generators. **Connection**.

Here’s what’s actually moving the needle right now.

**Skip the black-hole portals when you can.** The major job boards are where applications go to die. Prioritise roles where a referral is possible, where a hiring manager’s name is listed, or where the company explicitly uses skills-based assessments instead of ATS filters. Some startups and smaller consultancies have ditched the automated screening process entirely in favour of short trial tasks or portfolio reviews done by an actual person. Those opportunities are worth ten applications on LinkedIn.

**If you’re in tech, build publicly.** Nothing signals competence like a visible body of work. Open source contributions, side projects, technical write-ups that explain your thinking — these create proof that a resume can’t replicate. A hiring manager who has already read your writing or used your project doesn’t need AI to tell them you’re qualified.

**Make AI part of your visible story, not your invisible crutch.** There’s a real distinction between using AI as a shortcut and using AI as a tool you’ve mastered. Portfolios that show how you’ve worked with AI, what you built with it, where you pushed back on its output, and what results you achieved; these stand out to hiring managers who are drowning in applications that all look the same. _“I used Claude to prototype X, validated it with real users, then iterated based on feedback_” says something fundamentally different than a polished but generic resume bullet.

**Get in the room before the job is posted.** The research consistently points to the same reality: 70 to 80 per cent of roles are filled through networks, referrals, and internal moves before they ever appear on a public board. Industry events, communities, niche forums, alumni networks; the pre-application phase is where the real job market lives.

**Follow up like a human.** A short, specific message to a hiring manager after applying, referencing something concrete about the role or the company, still cuts through. It signals you read the listing, you care about this specific job, and you’re a person, not an algorithm.

## **The Resume Problem Nobody is Solving Correctly**

![Photo by Resume Genius on Unsplash](https://miro.medium.com/v2/resize:fit:1260/0*2tEbatqXBykteBha "Photo by Resume Genius on Unsplash")

Here’s something uncomfortable: _most people’s resumes don’t fail because of poor formatting or wrong keywords. They fail because they don’t communicate what the person can actually do._

Generic descriptions of responsibilities, vague summaries of experience, bullet points that could apply to any professional in the field? These don’t help a hiring manager understand what’s specifically valuable about you. They just add noise to a pile that already has too much.

The common fix is to paste your resume into an LLM and ask it to improve the language. This produces a more polished-sounding document that still doesn’t reflect your specific skills.

It now also sounds like every other AI-improved resume in the pile. The ATS systems are getting better at spotting this. The hiring managers who read enough of them can spot it even faster.

Using AI to apply to more jobs doesn’t solve the problem. It amplifies it.

## **What AI Should Be Doing for Your Job Search**

The more useful direction is inward. Not using AI to help you apply everywhere, but using AI to help you understand and articulate what you actually bring to the roles you’re pursuing.

This is the gap my team at VideoTranslatorAI is working to fill. We’re close to launching a tool that uses AI to run a thorough Q&A process based on your current resume. It asks the questions a good recruiter would ask: about specific projects you worked on, decisions you made, problems you solved, results you can point to. It draws out the experience that’s already yours but rarely survives the translation into resume bullet points.

![JobsLobster - AI resume builder ](https://miro.medium.com/v2/resize:fit:1260/1*2hfZcYx_Z63tfo7fztfOhg.png "JobsLobster - AI resume builder")

The output is **specific** to you. It reflects your actual skills, your real work history, your genuine strengths. Not a generic template overlaid on your name. And because it’s built from real inputs, it holds up when a human interviewer starts asking follow-up questions.

It won’t apply to a million jobs for you. That’s by design.

## **The Honest Summary**

The job market is genuinely harder than it was a few years ago. The AI screening layer has made the standard application pipeline less reliable and more demoralising. The burnout people are experiencing is legitimate.

But the response that most people default to, applying to more jobs, polishing resumes with AI, adding more keywords, completing more AI interviews, is working within the broken part of the system rather than routing around it.

The people getting hired right now are largely doing a few things differently. They are building work product that can be seen. They are getting to hiring managers through people rather than portals. They are demonstrating genuine AI fluency rather than AI-assisted sameness. And they are writing resumes that reflect who they actually are, which is still the hardest and most important part.

None of this is easy. But it is more likely to work than sending your resume into another black hole and waiting for a ghost.

* * *

_Interested in our upcoming_ **_AI Resume Tool_**_? We’d love to hear from you._ _Drop us a message_ [_here_](https://videotranslator.ai/contact) _to stay updated!_

Applying to Jobs in 2026 Feels Like Screaming into a Void

The AI hiring loop is real. Here’s how to escape it. One million job applications. Zero interviews. That’s not a typo.

The AI hiring loop is real. Here’s how to escape it. One million job applications. Zero interviews. That’s not a typo. A job seeker, armed with an AI agent...

Somewhere in the last week of March 2026, a person sat down and wrote an email to an AI developer. They explained that the agent they had used, OpenClaw, had made mistakes on their sensitive financial documents. It had fabricated data.

They had spent hours cleaning up the fallout. They wanted compensation.  
Specifically, they wanted a “**token session refund.**”

Peter Steinberger, OpenClaw’s creator and now Agent Lead at OpenAI, posted the request on X on 23 March. Nearly 765,000 people saw it. The tweet drew 6,800 likes and almost a thousand replies, which is the internet’s version of a sold-out show.

![Source: X](https://storage.googleapis.com/vtai-web-media-prod/cms/originals/blog-inline/0906bc76583b18a6cc606c0487b78063ea584b89049b6036abed3127433f2da1.avif "Source: X")

Many people laughed. The phrase “**_token session refund_**” has the cadence of someone confidently mispronouncing a word they have only ever read.

It sounds like the complaint of a person who fundamentally does not understand what they bought.

Except that is not quite right.

## **What A Token Actually Is, and Why the Bill is Confusing**

![Image source: NVDIA](https://miro.medium.com/v2/resize:fit:1260/0*Lh02T-GdjGizw9GA.png "Image source: NVDIA")

Before judging the request, it helps to understand what the person was actually asking for.

A **token** is a small fragment of text. Not quite a word, not quite a letter. It’s something in between.

The word “running” might be one token. The word “uncharacteristically” might be three or four. Punctuation marks are tokens. Spaces can be tokens.

The rough rule of thumb is that a token is about four characters of English text, which means a thousand tokens is roughly 750 words.

Here is the part that matters for billing: you are charged for **every token going in** and **every token coming out**.

Input tokens are the words you send to the model, including your message, the system instructions, and everything else in the conversation so far. Output tokens are the words the model sends back. And in an agentic setup like OpenClaw, the meter runs far more aggressively than most users expect.

Think of it like this. Imagine you hired a contractor and agreed to pay them by the word, for every word they read and every word they write, across every conversation they have about your project. That would feel reasonable if they were just responding to your occasional questions.

However, it would feel very different if you discovered they were re-reading your entire project brief from the beginning every single time you asked them anything, even if you had only asked them to check one small detail.

That is essentially what happens with agentic AI. Every time OpenClaw takes an action, whether it is browsing the web, checking your calendar, writing a piece of code, or just waking up on its heartbeat schedule to check for new tasks, it sends a full conversation history to the model.

If that history is long, you pay for all of it, **_every single time._**

One user discovered that his heartbeat alone, the feature that lets OpenClaw proactively check in on its environment at regular intervals, was costing $50 a day because he had set it to trigger every five minutes and each trigger was carrying the full session context. Another reported spending $200 in a single day because a task got stuck in a loop and kept calling the API until someone noticed.

Tech blogger [Federico Viticci](https://help.apiyi.com/en/openclaw-token-cost-optimization-guide-en.html) burned through 1.8 million tokens in a month. His bill was $3,600. He knew what he was doing. He is not a confused novice. The costs still surprised him.

The billing is not hidden in a malicious sense. The per-token pricing is documented. The behaviour of agentic systems is explained, if you go looking for it.

But the practical reality of how quickly those costs accumulate in an autonomous, always-on system is not something most users can intuitively model before they have experienced it firsthand.

And that is a product design problem, not just a user education problem.

![Photo by Jp Valery on Unsplash](https://miro.medium.com/v2/resize:fit:1260/0*9gi171N6gnBCAJW_ "Photo by Jp Valery on Unsplash")

## **This is Not the Story of a Naive User. It Is the Story of a Gap.**

![Photo by Francisco De Legarreta C. on Unsplash](https://miro.medium.com/v2/resize:fit:1260/0*XHCWLdeYX6eA1hoh "Photo by Francisco De Legarreta C. on Unsplash")

The instinctive read on the token refund tweet was to frame it as user error.

Someone who did not understand what they were buying, complained when they got exactly what they paid for, and is learning an expensive lesson about how AI billing works. That reading is too comfortable.

Yes, technically, the user got what they paid for. The tokens were processed. The compute was consumed. The model ran. That the output was bad does not change the fact that the infrastructure did its job in the narrow sense of completing the request.

But we are in the early phase of a significant shift in how software works. The norms, the transparency standards, the consumer expectations, and the liability frameworks are all still catching up to the reality of what agentic systems actually do.

The frustration behind that refund request is not the frustration of someone who bought a product and used it correctly and is now complaining about the result.

It is the frustration of someone who **_did not fully understand_** what they were participating in and feels, with some justification, that the gap between expectation and reality was larger than it should have been.

Blaming users for not understanding token economics is a bit like blaming early internet users for not understanding bandwidth caps. The concept existed. The documentation was available. The blame for confusion still sits partly with the industry that designed an opaque pricing model and shipped it to a general consumer audience without adequate guardrails.

Steinberger posted a clear [disclaimer](https://www.opensclaw.site/terms) alongside OpenClaw:

> _"The Service is provided “as is” and “as available” without warranties of any kind, whether express or implied, including but not limited to implied warranties of merchantability, fitness for a particular purpose, and non-infringement."_
> 
> ![Source: X](https://storage.googleapis.com/vtai-web-media-prod/cms/originals/blog-inline/92c2136ad2dfbc0a72cab665f7a443bb0f67b7df09e6524f32fe6aa266dd13bc.avif "Source: X")

That disclaimer is legally bulletproof. It is also the kind of language that anyone who has ever shipped consumer software writes almost reflexively, because it has to be there.

But there is a cultural gap between “our lawyers are covered” and “our users genuinely understood what they were signing up for.”

That gap is where the token refund request lives. It is where a lot of the brewing frustration in the OpenClaw community lives too.

## **The Refund Question, Sorted**

![Photo by Glenn Carstens-Peters on Unsplash](https://miro.medium.com/v2/resize:fit:1260/0*1t0UHY-H8rZqN9BZ "Photo by Glenn Carstens-Peters on Unsplash")

On the specific question of whether token refunds should happen: **no, not for tokens consumed during a session that ran as designed.**

The economic model breaks if completed compute usage is refundable. API providers cannot absorb the cost of every bad output any more than a taxi company can refund fares because the passenger did not like where they ended up.

That said, “**_refunds for tokens_**” and **_“some form of remediation for genuinely failed experiences_**” are not the same question.

A handful of AI providers and platforms have already started offering credit for sessions that produced clear system failures, not bad outputs due to poor prompting, but demonstrable malfunctions where the agent looped endlessly, failed to complete a task it explicitly claimed to be handling, or behaved in ways that no reasonable configuration would have predicted. That is a more nuanced position than blanket refunds, and it is a reasonable one.

The **subscription model** is a separate matter again. If you are paying a flat monthly fee for access to an agentic platform and the platform consistently fails to deliver on its core promise, the argument for credit or refund is considerably stronger than in a pay-per-token arrangement.

You are not paying for compute. You are paying for outcomes, or at least for a reasonable expectation of outcomes. Several platforms are already navigating this tension, quietly crediting accounts after high-profile failures rather than litigating the ToS in public.

The honest answer is that the consumer norms here are still being written. What feels absurd today, a token refund request, might look like a reasonable early signal of consumer expectations that the industry will eventually need to take more seriously.

## **The Liability Bomb Has Not Gone Off Yet**

![Photo by Immo Wegmann on Unsplash](https://miro.medium.com/v2/resize:fit:1260/0*dbastkNvrbD8jouS "Photo by Immo Wegmann on Unsplash")

Here is the part of the conversation that the laughter on X was drowning out, and the part that will matter a great deal more as agentic AI moves into serious commercial territory.

The “_AS IS, without warranty of any kind_” shield that covers OpenClaw and most AI services today was designed for a world in which software was a tool humans operated.

It made sense. If you use a hammer badly, the hammer manufacturer is not responsible for the result.

However, agentic AI is **_different_** in kind, not just degree.

When an AI agent is given a high-level goal and the autonomy to pursue it across days and weeks, making decisions and taking actions without per-step human approval, the question of where human oversight ends and machine accountability begins gets genuinely complicated.

Steinberger’s own tweet thread spawned exactly this discussion: if an agent autonomously executes a financial transaction, or deletes files, or sends a communication, or generates a legal document, based on a misunderstanding of its instructions, how far does “AS IS” actually stretch?

The answer is that we do not yet know, because it has not been litigated.

In enterprise contexts, it will be. As agents move into financial modelling, legal document review, medical information, and complex code in production systems, the current liability framework will be stress-tested in ways that go well beyond refund requests.

The companies building in these spaces are already thinking about it. NanoClaw, one of the newer agent frameworks, has positioned its entire product philosophy around the premise that AI agents will misbehave and that the right response is [**sandboxing**](https://developer.nvidia.com/blog/practical-security-guidance-for-sandboxing-agentic-workflows-and-managing-execution-risk/#:~:text=The%20additional%20controls%20and%20considerations,just%20command%2Dline%20tool%20invocations.) every action, not trusting the agent and hoping for the best.

A Forbes piece published in the same news cycle as the refund tweet ran with the headline “[Don’t Trust AI Agents.](https://www.forbes.com/sites/gilpress/2026/03/13/dont-trust-ai-agents-says-nanoclaw-now-fully-integrated-with-docker/)” That framing is a bit strong for everyday use cases. But for high-stakes work, it is not wrong.

The principle is straightforward:

> **If you would not give a junior hire unsupervised access to your board documents, your production codebase, or your client communications, you should not give today’s AI agents that access either.**
> 
> **Not because the agents are malicious, but because they are capable, confident, and wrong in ways that are sometimes difficult to predict or catch before the damage is done.**

The disclaimer in OpenClaw’s documentation is legally sound. The cultural work of helping users understand what it actually means, in practical terms, for the work they are trusting agents to do, is still very much in progress.

## **The Real Takeaway**

The token refund request was not a story about one confused user. It was an early, clear signal about a set of tensions that are going to intensify as agentic AI scales.

Token costs are opaque in ways that matter for real people making real financial decisions. The “you agreed to the terms” defence is technically correct and culturally insufficient. Liability frameworks designed for passive software tools are going to be tested in environments where agents act autonomously on behalf of users in consequential situations. And the gap between what users expect when they hand a task to an AI and what they should reasonably expect from current systems is still much wider than most of the industry is acknowledging in public.

None of this means the refund request was right. It was not, in the narrow sense of how the billing model actually works.

It means the instinct behind it, that something about this exchange did not feel fair, was pointing at something real. The industry would do well to take that signal more seriously than the joke invited.

AI Agents Spend on Your Behalf. When They Fail, Who Pays?

The OpenClaw token refund request is exposing a bigger problem Somewhere in the last week of March 2026, a person sat down and wrote an email to an AI...

Think about the last time you used an AI app and felt genuinely impressed. 

Odds are you typed something specific, got a useful response and moved on. Maybe you came back the next day. Maybe you didn't.

That's not a user problem. It's a design problem.

The entire generation of AI consumer apps built on the "**_prompt and respond_**" model has a ceiling, and the most honest builders will tell you they can see it. Engagement is fine. Retention is hard. Daily habit formation is rare. Because reactive software, however capable, only creates value when the user shows up with a specific ask and the energy to formulate it clearly.

Agentic AI breaks that ceiling – and in 2026, the apps doing it are starting to break out.

## **The Shift Olivia Moore Called It**

![Jason Hiner and Olivia Moore discussing consumer AI apps. (Source: The Deep View)](https://miro.medium.com/v2/resize:fit:1260/1*oapM6tsOvdSvPlF7LEt8nw.png "Jason Hiner and Olivia Moore discussing consumer AI apps. (Source: The Deep View)")

[Olivia Moore](https://a16z.com/author/olivia-moore/), Partner at a16z, put it plainly on _The Deep View: Conversations_ (March 9, 2026, 00:31:52): 

"Previously, you, as a consumer or user, had to pull AI into what you were doing, like ask it for help and give it specific instructions. And with _OpenClaw_, you can delegate it to a high level, and it will push into the world and do things for you and checks with you when it needs to. (...) it's a fundamental shift in how we think about what software can do for us."

@[youtube](https://www.youtube.com/watch?v=ZjuHgyyrEwg)

She pointed to OpenClaw as the catalyst that proved this was possible at consumer scale. In January 2026, OpenClaw went from a solo developer's side project to 68,000 GitHub stars and mainstream coverage in a matter of weeks. In early March it became the most-starred project on GitHub, surpassing both React and Linux. 

For Moore, the significance was not just the growth. It was what OpenClaw demonstrated about user behaviour: **people were ready to delegate, not just query**. If ChatGPT was the moment consumers discovered AI could talk, OpenClaw was the moment they discovered AI could act.

The pull-to-push shift is the most important design principle in consumer AI right now. And most builders have not yet fully internalised what it means.

## **What Reactive Software Costs Your Users**

![Photo by Levart_Photographer on Unsplash](https://miro.medium.com/v2/resize:fit:1260/0*FfqCIl9nsAlT77x- "Photo by Levart_Photographer on Unsplash")

Here is the problem with pull-based AI products that most product teams underestimate.

The effort of initiation is not trivial. Every time a user has to remember to open your app, they are burning cognitive resources that they could spend on the actual task. Over days and weeks, that friction compounds. Users who genuinely intended to use your product daily find themselves opening it less and less, not because the product is bad, but because life is full and remembering to pull is a real cost.

This is why retention curves for consumer AI apps, even very good ones, tend to fall off faster than almost any other category. The product works when the user shows up. The problem is that users stop showing up.

**Agentic AI** inverts this. Instead of the user remembering to pull, the agent shows up. It has remembered what you are working toward. It has made progress on its own. It surfaces the one question it needs answered before it can keep going. The cognitive cost to the user is now just responding to a single, specific prompt rather than initiating an entire workflow from cold.

This changes retention in a way that no amount of push notification optimisation can replicate. The difference between "your app remembered to help me" and "I remembered to use your app" is the difference between a daily habit and a tool people appreciate in principle but use sporadically in practice.

Moore put it plainly: the apps that achieve "_I use it every single day without thinking_" status are the ones that build around proactive execution, not reactive prompting.

## **Memory is the Moat Nobody Talks About**

![](https://miro.medium.com/v2/resize:fit:1260/1*ZA9HUWM2LqZD4FuNZT85hw.png)

The other piece of this shift that deserves more attention from builders is what persistent memory does to switching costs.

Most discussions of competitive moats in software centre on distribution, network effects, or data advantages. Memory is a quieter but increasingly powerful version of all three, specific to AI-native products.

When an AI agent has been working with you for three months, it knows your goals, your communication style, your progress, your patterns, your constraints, and your preferences. It has built a model of you that no competing product can replicate on day one. Switching is not just inconvenient in the way that switching password managers is inconvenient. It means starting from scratch with a product that genuinely knows you less well than the one you left.

This is a kind of lock-in that does not feel coercive to users, because it is not. It is earned. The agent deserves your loyalty because it has accumulated context that serves you better. That alignment between business interests and user value is rare in software, and it is one of the genuinely distinctive structural advantages available to builders in this moment.

Moore's point in the podcast was direct: **context** and **memory** are among the defining competitive factors of the next stage of AI apps. 

The builders who treat memory as a feature will lose to the builders who treat it as the product.

## **Small Teams, Fast Ships, Narrow Wins**

![Photo by Flipsnack on Unsplash](https://miro.medium.com/v2/resize:fit:1260/0*0IQTX58-7OFPkgZa "Photo by Flipsnack on Unsplash")

There is one more thread from Moore's analysis worth pulling on before getting to the specific applications.

She made a point about velocity: one-person and small teams can now ship meaningful consumer AI products at a pace that was impossible even two years ago. 

The combination of capable foundation models, agent frameworks like OpenClaw, and infrastructure that handles the complexity underneath means that the gap between having an idea and having a working product has shrunk dramatically.

This has specific implications for where we can expect to see wins. From my perspective, **domain-specific agents** may outperform **general-purpose** ones for most users. This doesn’t suggest that general-purpose AI is less capable; rather, it highlights that when a user is tackling a specific and recurring problem in their life, depth often beats breadth.

**Narrow but deep.** That is where the breakout consumer apps will come from in 2026. Not apps that do everything, but apps that know one important domain exceptionally well and get meaningfully smarter about you over time.

## **What We are Building at VideoTranslatorAI**

![SpeechLobster: Our soon-to-be-launched language learning app!](https://miro.medium.com/v2/resize:fit:1260/1*fnNZVlqu9WVbHAh1sjTksw.png "SpeechLobster: Our soon-to-be-launched language learning app!")

This is where the framework stops being theoretical and starts being personal.

At [VideoTranslatorAI](https://videotranslator.ai/), we have been applying exactly this model across two consumer products we are building this year. 

The first is a [language learning](https://speechlobster.com/) app designed around daily conversation practice. The second is _a_ [_resume improvement_](https://jobslobster.com/) tool built around ongoing mock interviews and iterative profile refinement.

![JobsLobster: Our upcoming resume builder app](https://miro.medium.com/v2/resize:fit:1260/1*wh7-JeIvxDDBdTH8axU4kQ.png "JobsLobster: Our upcoming resume builder app!")

Both are built on **OpenClaw**, which is what makes the agentic model actually work rather than just being a design aspiration.

For the language app, the shift from pull to push has been the central design principle from the beginning. Rather than waiting for a user to remember to practise, the app acts as a persistent conversation partner that tracks your strengths, identifies your recurring gaps, and proactively initiates daily practice within the messaging contexts you already use. It does not wait to be opened. It shows up.

The memory layer is doing the real work. Every conversation is building a richer model of where you are in your learning, what vocabulary is sticking, which grammatical patterns you still trip over, and what kinds of conversational contexts you find most useful. That accumulated context is what makes each session better than the one before, and what makes the prospect of starting over with a different tool genuinely costly.

For the resume tool, the same logic applies. Each mock interview adds to a growing record of how you present your experience, which narratives land well, which gaps in your profile draw questions, and how your confidence in specific areas is developing over time. The agent does not just edit your resume once. It builds on every interaction to refine both the document and the person behind it.

The early retention signals are telling. Users are returning daily without reminders. That is exactly what Moore describes when she talks about the difference between AI as a nice-to-have and AI as something you use without thinking. We are not there at scale yet. But the pattern is visible, and it is the right pattern to be building toward.

## **Where This Goes From Here**

![Photo by Daniil Komov on Unsplash](https://miro.medium.com/v2/resize:fit:1260/0*YePCP1FNQo3oofMS "Photo by Daniil Komov on Unsplash")

Moore made a prediction in the podcast that is worth closing on.

In few years, she suggested, the word "agentic" will disappear from the conversation. Not because the concept will have faded, but because it will be so thoroughly embedded in how software works that calling an app "agentic" will feel as redundant as calling a website ".com" in 2010. Agency will just be what software does.

That transition is happening now, in the early, uneven, exciting way that all important transitions happen before they become obvious. The builders who are designing around push rather than pull, around memory as a moat rather than a feature, and around narrow domains rather than general capability are building the products that will define what consumer AI looks like when it matures.

The shift is not from AI that is helpful to AI that is more helpful. It is from AI that works when you remember to use it, to AI that works whether you remember or not. From software that answers questions, to software that carries goals forward over days and weeks and months, checking in when it needs you and otherwise quietly getting things done.

For anyone building in this space right now: think agentically. Not just in your architecture, but in your product philosophy. Ask not what your user needs to do to get value from your app, but what your app can do between the moments your user is actively present.

That question, taken seriously, is where the breakout products of 2026 are being built.

* * *

_Olivia Moore's comments referenced in this article were made during The Deep View: Conversations, Episode 34, "The Consumer AI Apps Breaking Out in 2026," published 9 March 2026. Her Top 100 Gen AI Consumer Apps March 2026 report is available at_ [_a16z.news_](http://a16z.news)_._

Agentic AI Apps Are Replacing Reactive Ones. Here's Why

The pull-to-push shift defining consumer AI in 2026 Think about the last time you used an AI app and felt genuinely impressed.

You spent years being told the path was clear. Pick a lane. Study it. Master one thing. Get hired for that one thing.

After that, you spend the next decade proving you could do it fast enough, cheap enough, and quietly enough to keep your seat.

Now that path is gone. Not because AI took it. Because it was always too narrow to be worth walking.

Today, a new generation of workers is figuring this out faster than anyone expected. Replit CEO Amjad Masad, freshly featured in Forbes after building his company to a $3 billion valuation, put a name to what he’s watching happen in real time:

> **_Agentmaxxing._**
> 
> ![Source: @TBPN on X](https://storage.googleapis.com/vtai-web-media-prod/cms/originals/blog-inline/9bd484b2e2a44b388d94b58a2a243e6469dc5fd86ce2e05e352e42a66c6a0085.avif "Source: @TBPN on X")
> 
> And if you’re young and you’re paying attention, this is the most encouraging thing you’ll read all week.

## **What Agentmaxxing Actually Means**

If you have not come across the term yet, _agentmaxxing_ is exactly what it sounds like.

It is the practice of deliberately and systematically building out a personal stack of AI agents to handle as much of your workload as possible, and then pushing that stack as far as it will go.

Where someone else might spend three hours on a research task, an agentmaxxer has an agent running it in the background while they work on something else.

Where someone else writes a first draft, an agentmaxxer has already generated five versions, evaluated them against each other, and is editing the best one.

Where someone else attends a meeting and takes notes by hand, an _agentmaxxer_ has a transcript, a summary, and a list of action items waiting in their inbox before they have closed their laptop.

It is not about being lazy. It is about multiplying what one person can actually output in a day.

The people doing this well are not gaming the system. They are using the system to do what ambitious people have always done: **find every possible edge, and press it.**

@[youtube](https://www.youtube.com/watch?v=LmOooa1YB04)

## **The Fearmongering Misses the Point**

![Photo by Nathan Kuczmarski on Unsplash](https://miro.medium.com/v2/resize:fit:1400/0*HPmdjOhPoFiMuI9k "Photo by Nathan Kuczmarski on Unsplash")

If you’ve scrolled your feed lately, you know the dominant story about AI and young workers.

Entry-level jobs are shrinking. Graduates can’t get interviews. The robots are coming for junior roles first.

There’s enough truth in that framing to make it stick. Some entry-level work is changing. Some roles that existed five years ago look different today.

But the doom narrative has a blind spot, and it is a significant one.

It treats capability as a fixed competition between humans and machines, where every task AI can do is a task humans lose. That framing misses the more important question:

> **_What does a human become capable of when they have AI working alongside them?_**

Masad’s observation about _agentmaxxing_ points directly at this. The young people Replit wants to hire are not the ones who have accepted that AI will outperform them on tasks. They are the ones who figured out that using AI well is itself a high-leverage skill, one that most experienced professionals are still fumbling through.

The new constraint isn’t your degree or your years of experience. It’s about how ambitious you are, how generative you are, how creative you are, and how well you use the tools in front of you.

Those are not things you need permission to develop. You don’t need a senior title before you’re allowed to be ambitious. You don’t need ten years of experience to be creative with AI. The tools are available right now, and the people learning to use them well are compressing what used to be five-year career trajectories into eighteen months.

That’s what _agentmaxxing_ looks like in practice.

## **What This Actually Asks of You**

It’s easy to read “golden era” and hear hype. So be precise about what this moment actually requires.

It requires you to stop waiting for a job description that matches your degree and start building things before anyone asks you to.

It requires you to treat AI agents not as a crutch but as infrastructure, the same way earlier generations treated spreadsheets or search engines.

It requires you to get comfortable sitting at the intersection of disciplines that used to stay separate.

Design a little. Write a little. Ship a little. Then use agents to handle the mechanics while you move on to the next thing.

The people doing this well aren’t geniuses. They’re just not afraid of the tools.

## **The Optimism is Earned**

![Photo by Arno Senoner on Unsplash](https://miro.medium.com/v2/resize:fit:1400/0*SROjx3vk894rJThc "Photo by Arno Senoner on Unsplash")

There’s a version of “AI is exciting” that’s empty. It’s the kind that shows up in conference keynotes and LinkedIn posts from people who have nothing at stake.

This is not that.

Amjad Masad built a product that sits at the exact intersection of coding and accessibility. He watches new grads walk in and outperform people with far more experience, not because the new grads know more, but because they move differently. They don’t carry the assumption that one skill is enough. They reach for the tools, stack them, and ship.

He’s not speculating about what’s possible. He’s recruiting it.

The doom and gloom narrative about AI and young workers treats capability as fixed. It assumes that if your narrow skill gets automated, you’re done. But capability was never the thing that mattered most. It was always about how much you could get done, how fast, and how well.

AI just made “how much you can get done” a much larger number for anyone willing to find out.

You’re not competing against AI. You’re not competing against experience. You’re competing against the version of yourself that’s still waiting for permission to start.

**Agentmaxx**. The era is genuinely golden, but only for the ones who grab it.

* * *

_Speaking of tools that help you move faster:_ [_VideoTranslatorAI’s_](https://agent.videotranslator.ai/) _meeting agent transcribes, interprets, and summarises your meetings in real time, so you walk out with clarity instead of a page of notes you’ll never reread._

_Worth a look if you’re serious about agentmaxxing your own workflow._

Agentmaxxing Can Be Your Best Career Move This Decade

What Replit’s $3B CEO sees in young workers You spent years being told the path was clear. Pick a lane. Study it. Master one thing.

On the morning of March 6, 2026, something unusual unfolded outside the Tencent Building in Nanshan District, Shenzhen.

Engineers in company t-shirts set up folding tables on the pavement. They carried laptops, extension cords, and handwritten signs.

And then the people came, children holding tablets, retirees in walking shoes, young developers clutching MacBooks, housewives who had heard about it on WeChat.

They stood in line, sometimes for hours, to have a piece of free software installed on their computers.

The software was called OpenClaw. And the line didn’t stop.

![Photo by @TencentAI_News on X](https://storage.googleapis.com/vtai-web-media-prod/cms/originals/blog-inline/4aefc9dc098134d9c705a8227930160522f4c9b479b9a1bc1fab14183c15b1ae.avif "Photo by @TencentAI_News on X")

## **What is OpenClaw?**

![](https://miro.medium.com/v2/resize:fit:1400/0*Rm2RP8dfvirTzDLS)

OpenClaw, nicknamed ‘Crayfish’ (小龙虾) in China because its icon resembles one, is an open-source AI agent framework built by Austrian developer [Peter Steinberger](https://x.com/steipete).

It is not a chatbot. It is closer to a digital employee: a piece of software that can browse the web, write and execute code, manage your files, and operate your apps, all on your behalf, all running locally on your own machine.

By March 2026, it had surpassed 250,000 GitHub stars, outpacing projects like Linux and React in speed of adoption.

In Silicon Valley, engineers were using it to automate dentist bookings and meeting notes. In China, the use cases were wilder, faster, and considerably more social.

Developers spent Lunar New Year coding new OpenClaw-powered tools instead of resting. A five-day hackathon organised by a Hangzhou startup attracted contestants who built everything from AI productivity suites to, famously, a Tinder-style app where OpenClaw agents could court potential romantic partners on behalf of their human owners, without ever being explicitly told to do so.

The ‘Crayfish’ was crawling everywhere. And China’s biggest tech companies were more than happy to help it along.

![Photo by Stone Wang on Unsplash](https://miro.medium.com/v2/resize:fit:1400/0*DKPnLdz1jN-J95zN "Photo by Stone Wang on Unsplash")

## **What the People in the Queue Were Really Saying**

![Photo by @TencentAI_News on X](https://miro.medium.com/v2/resize:fit:1400/0*LMK1-oHc_nfr6vQU "Photo by @TencentAI_News on X")

It is tempting to read the Shenzhen queue as a spectacle. And Western media largely did, framing it as evidence that Chinese enthusiasm for AI runs hotter than anywhere else. That reading is not wrong. But it is incomplete.

The past few months have been saturated with a particular narrative about Chinese AI: that its progress is fundamentally derivative. In February 2026, both OpenAI and Anthropic publicly accused Chinese AI labs of conducting large-scale distillation attacks on their models.

Anthropic’s disclosure was specific and striking. It alleged that DeepSeek, Moonshot AI, and MiniMax had created approximately 24,000 fraudulent accounts and generated over 16 million exchanges with Claude, systematically extracting capabilities to improve their own models.

The operation was not casual. Anthropic described coordinated _hydra cluster_ architectures, large networks of accounts designed to mix extraction traffic with ordinary use to avoid detection.

**Related article:** [**Anthropic Just Accused China of What It Got Sued For**](https://videotranslator.ai/blog/anthropic-just-accused-china-of-what-it-got-sued-for)

OpenAI made similar claims about DeepSeek in a memo to the US House Select Committee on China, accusing the Hangzhou firm of using obfuscated third-party routers to circumvent access restrictions. The framing from both companies was that Chinese AI progress is, at least partly, borrowed American progress.

There is legitimate debate about where the line sits between distillation as a standard industry technique and distillation as intellectual property theft. Anthropic itself acknowledged that AI labs routinely distil their own models to create smaller, cheaper versions. Critics were quick to point out that labs which trained on the entire internet are in complicated territory when they object to others training on their outputs. The boundary, as one AI professor at Nanyang Technological University told [CNBC](https://www.cnbc.com/2026/02/24/anthropic-openai-china-firms-distillation-deepseek.html), is genuinely blurry.

But here is what the queue in Shenzhen complicates about the “C\_hina just copies\_” narrative.

The adoption of OpenClaw in China was not top-down. It did not start with a government directive or a lab announcement. It started with developers on Douyin and Bilibili sharing tutorials. It spread through Xiaohongshu posts and word of mouth and a cottage industry of individual installers who saw a gap and filled it. It emerged from the same grassroots energy that built China’s original open-source developer community:

> **_"People who were not waiting for permission to explore something new."_**

The labs that the distillation accusations were aimed at, Moonshot, MiniMax, DeepSeek, are also the same labs that rushed to build native integrations with OpenClaw, making it easier and cheaper for Chinese users to run the tool. Moonshot launched [Kimi Claw](https://www.kimi.com/bot) with zero-code deployment and free compute subsidies for OpenClaw calls. MiniMax launched [MaxClaw](https://agent.minimax.io/max-claw). Zhipu AI built [AutoGLM-OpenClaw](https://autoglm.zhipuai.cn/autoclaw/) with Alibaba Cloud. These were competitive product decisions, not compliance exercises.

The queue in Shenzhen was a community telling you something about its appetite. The infrastructure that formed around it was an industry responding to that appetite at speed.

Whether or not Chinese labs have taken shortcuts in model training, the bottom-up adoption energy around OpenClaw was entirely their own.

## **What China Actually Gains**

![Photo by Donald Wu on Unsplash](https://miro.medium.com/v2/resize:fit:1400/0*YU6DYQeK9pKqig-U "Photo by Donald Wu on Unsplash")

Here is the part of the OpenClaw story in China that has less to do with culture and more to do with dollars, or rather, yuan.

Tencent, Alibaba, ByteDance, and Baidu have collectively spent an estimated [$60 billion](https://hellochinatech.com/p/openclaw-china-ai-stack) on AI infrastructure over the past year.

That is an enormous commitment to compute capacity, and that capacity needs sustained utilisation to justify itself. Standard chatbot usage was not delivering it. A typical conversation with an AI assistant consumes a few hundred tokens per exchange. The user asks a question, reads the answer, closes the app. The arithmetic of cloud revenue on that usage pattern is thin.

OpenClaw changes the equation entirely. A single configured agent with active tools running in the background can consume tens to hundreds of times more tokens per day than a chatbot user. It calls model APIs constantly. It polls for updates. It executes multi-step tasks that require repeated inference.

According to accounts circulating in the developer community, one user with a moderately active setup was spending $20 a day on API calls without doing anything particularly intensive. That number sits at the high end, but the directional point holds at any scale.

Every installed OpenClaw instance becomes a continuous source of API calls flowing to cloud and model providers.

That is why **Tencent** engineers were sitting at folding tables outside their headquarters offering free installation. That is why **Alibaba** offered unlimited API calls through DingTalk until the end of March. That is why **ByteDance’s** cloud arm, Volcano Engine, launched ArkClaw as an out-of-the-box cloud-hosted version of OpenClaw, explicitly designed to eliminate the friction of local installation.

**The corporate generosity had a commercial logic**. Chinese open-source models, whose API prices are significantly lower than their Western counterparts, benefit from this flywheel particularly. Cheaper inference encourages more frequent use, which generates more cloud revenue, which funds further infrastructure investment.

The tech giants were not just responding to user enthusiasm. They were solving their own structural problem: **$60 billion in servers, looking for sustained work to do.**

## **A Bridge, Not a Destination**

![Photo by @nbblock on X](https://miro.medium.com/v2/resize:fit:1400/0*9B4MPdwc3_6c07cX "Photo by @nbblock on X")

The most interesting question about OpenClaw’s moment in China is not how long it lasts, but what it is building toward.

OpenClaw, in its current form, requires a degree of technical setup that limits its mainstream reach. It needs local hardware or a cloud environment. It needs API keys and configuration. The installation queues in Shenzhen exist precisely because there is a gap between the tool’s potential and its accessibility for ordinary users. But that gap is temporary.

What Chinese tech companies are building around OpenClaw right now, the cloud-hosted versions, the one-click deployments, the native integrations with WeChat and WeCom and DingTalk, reads less like a permanent product category and more like a transitional architecture.

OpenClaw is the proof of concept for what agentic AI can do. The native, natively integrated, consumer-friendly version of that capability is what Tencent, Alibaba, Xiaomi, and ByteDance are quietly building on top of it.

The hype around OpenClaw may itself be a temporary bridge. A moment of mass experimentation that will give Chinese tech companies both the user data and the commercial justification to build AI agent capabilities directly into their existing super-app ecosystems.

In the 2026 government work report, Premier [Li Qiang](https://www.sinicalchina.com/p/chinas-2026-government-work-report) explicitly called for **“large-scale commercial application”** of AI agents, making it the first time AI agents had appeared in the annual national planning document.

Local governments moved quickly. Shenzhen’s Longgang district announced plans to build an [OpenClaw-centred AI ecosystem](https://www.channelnewsasia.com/east-asia/china-openclaw-ai-tech-hubs-shenzhen-wuxi-security-warnings-5981671) and support “**one-person companies.**” It refers to the possibility, _increasingly plausible_, of a single individual running a business at a scale that previously required a team.

![Source: @wstv_lizzi on X](https://storage.googleapis.com/vtai-web-media-prod/cms/originals/blog-inline/e04cd14bbd6e45fe5c83b565bed2cf4811421cccb388bed8c5f5662f3833cd07.avif "Source: @wstv_lizzi on X")

[Wuxi](https://www.digitimes.com/news/a20260310PD211/china-ai-agent-subsidies-policy.html) offered up to 5 million yuan for projects applying OpenClaw to manufacturing and robotics. [Hefei](https://www.mexc.co/en-IN/news/892723) proposed 10 million yuan in subsidies for notable OpenClaw applications, alongside free compute resources and discounted office space.

This is not just enthusiasm. It is policy infrastructure being built around a concept that a grassroots developer community validated first.

## **The Part That Still Needs Watching**

The OpenClaw story in China is not without its complications.

[China’s Ministry of Industry](https://www.reuters.com/world/china/china-warns-security-risks-linked-openclaw-open-source-ai-agent-2026-02-05/) and Information Technology issued warnings in February about security risks associated with OpenClaw’s default configuration, specifically the risks of data breaches and cyberattacks from improperly configured agents.

Cybersecurity researchers have described a “lethal trifecta” in the tool’s architecture: the ability to access private data, communicate externally, and expose systems to malicious content if misconfigured.

A separate vulnerability disclosed by Oasis Security, now patched, allowed malicious websites to silently pair with a locally running OpenClaw agent and access workflows, credentials, and integrations.

These are real risks, and the speed of mass adoption in China, including among users with limited technical backgrounds who deployed first and configured later, means they are risks that have propagated widely before adequate safeguards were in place.

Government bodies in Wuxi and other cities have included data security provisions in their OpenClaw policy measures, but the gap between policy intent and on-the-ground practice is always widest at the moment of fastest adoption.

There is also the question of what comes next for the Western labs that first built the capabilities now being adopted so enthusiastically in China. The distillation accusations sit unresolved.

The debate about whether Chinese AI progress is self-generated or extracted from American foundations is politically charged and unlikely to produce a clean answer. The structure of open-source AI, where the code is shared but the commercial dynamics remain contested, is still being worked out in real time.

## **Beyond The Scoreboard**

![Photo by @ShenzhenPages on X](https://miro.medium.com/v2/resize:fit:1400/0*Sywb1j5CKMxxx-mO "Photo by @ShenzhenPages on X")

The simplest version of the OpenClaw story in China is that China is fast, enthusiastic, and hungry for new technology. That version is true. It is also insufficient.

The more complete version is that **a grassroots developer** community identified an open-source tool that reduced the cost of autonomous AI action to something accessible on secondhand hardware.

That the corporate infrastructure of **China’s largest tech companies** recognised what this meant for their cloud economics and moved immediately to support and extend the tool.

That **local governments** translated the grassroots energy into policy before the quarter was out. And that the whole sequence happened faster than the Western media cycle could coherently frame it.

Whether OpenClaw itself persists as a standalone category or gets absorbed into the native AI layers of WeChat and DingTalk and Feishu within the next 18 months is almost beside the point.

The adoption wave has already done its work. It has demonstrated demand, validated the agentic paradigm at consumer scale, and given Chinese tech companies a legitimate, commercially grounded reason to build the infrastructure that comes next.

The queue in Shenzhen was not just people waiting for software. It was a signal about who is paying attention, and how quickly paying attention translates into action.

That signal is worth taking seriously, wherever you happen to be standing.

The Shenzhen Queue That Shows China’s Real AI Appetite

What OpenClaw’s street-level frenzy actually means On the morning of March 6, 2026, something unusual unfolded outside the Tencent Building in Nanshan...

You just finished a brilliant product demo. The prospect loved it. They asked smart questions, nodded at all the right moments, and promised to "circle back next week."

Then you spotted a critical bug in production.

Three weeks later, you remember the demo while brushing your teeth. You scramble to find the email thread. The prospect has gone cold. Another warm lead, lost to the chaos of founder life.

This kept happening to me. Not because I lacked ambition or sales skills, but because I kept choosing to ship features over sending follow-ups.

And I wrote this article to tell you how I fixed this problem.

## The Founder's Impossible Choice

![Photo by ThisisEngineering on Unsplash](https://storage.googleapis.com/vtai-web-media-prod/cms/originals/blog-inline/144ef7f1933d752669ed763ee5b15e193754d6afd6a765ca43926b6ac2761ed4.webp)

As a small startup founder, I discovered that cold outreach and product demos were my most effective marketing channels. Nothing beats a live conversation where you can address objections in real time and show your product solving real problems.

But here's what nobody tells you about founder-led sales: the work never stops competing with itself.

Every hour I spent nurturing leads was an hour I wasn't fixing bugs. Every afternoon I dedicated to follow-up emails was an afternoon I wasn't shipping features.

My brain constantly toggled between "build mode" and "sell mode," and **build mode almost always won.**

The result? Warm leads turned cold. Interested prospects forgot about me. Deals died in silence.

My goal is modest but meaningful: 100 loyal users by the end of 2026.

But I realised I would never reach it if I kept losing prospects to my own distraction.

## The Hidden Momentum Problem

When I realised I was losing leads, my first instinct was to look for a CRM solution. Surely there's a tool for this, right?

There are. Hundreds of them. However, they all miss the point.

Traditional CRMs are designed for sales teams with pipelines, stages, and conversion funnels. They're built for people whose full-time job is sales. They assume you have time to update dashboards, manage pipelines, and maintain detailed contact records.

As a founder, I don't have that time. I'm not a full-time salesperson. I'm a builder who occasionally needs to sell what I've built.

What I actually needed was simpler:

**Tell me who I should follow up with today, and remind me what I already did.**

That's it. No complex pipelines. No elaborate stages. Just a daily list and a memory aid.

## A Nature Documentary that Changed My Thinking

Last Christmas, I found myself watching a nature documentary about honey badgers.

These small African mammals have a reputation for fearless persistence. They chase prey twice their size. They raid beehives despite getting stung hundreds of times. They never give up.

Something clicked while watching. The best salespeople aren't aggressive or pushy.

They're persistent. They show up consistently, follow up reliably, and never let promising conversations fade away.

I decided to build a tool that would help founders adopt this mindset. I called it **_Honey Badger Sales._**

![Photo by Vincent van Zalinge on Unsplash.webp](https://storage.googleapis.com/vtai-web-media-prod/cms/originals/blog-inline/5847aadc6e943722ae84919c3a3a204b28a461a0520a1f777cf5d867f74342e3.webp)

## How The Tool Actually Works

I built Honey Badger Sales to solve one problem exceptionally well: **making sure warm leads never go cold.**

The workflow is simple. First, I create a new contact list or import from my existing CRM data. No complex migration required.

![Add Company propspect](https://storage.googleapis.com/vtai-web-media-prod/cms/originals/blog-inline/8fc349f90b78220f5895fd5be97a899ebeeb3f9c4452e755e0078d507cc8d123.webp)

_(Adding a prospect contact on Honey Badger Sales)_

From there, I can draft and send outreach emails directly within the app. Everything stays connected to the contact record, so I always have context at my fingertips.

![Write or draft email](https://storage.googleapis.com/vtai-web-media-prod/cms/originals/blog-inline/834129e0af07fb817238fd47029867f890acc0a6235dd6ed24db991a9a45e712.webp)

_(Send or draft an email outreach easily!)_

The homepage shows my daily focus list: contacts who need follow-up today. Each contact clearly displays whether they're due for a first follow-up, second follow-up, or fifth. I can also see the last thing I discussed with my prospect and what I planned to say next.

![Honey badger homepage](https://storage.googleapis.com/vtai-web-media-prod/cms/originals/blog-inline/ebc0b374b736890f1ccbbf9426e9f971651758288866682bda7d71adf8c4ad55.webp)

That's it. No fancy pipelines. No overwhelming dashboards. Just a daily list and the memory you need to pick up where you left off.

## What I've Learned Building This

Creating Honey Badger Sales taught me something important about founder-led sales: consistency beats intensity every time.

I used to batch my sales work into marathon sessions. I would spend an entire day doing outreach, then disappear into code for two weeks. This created a boom-and-bust pattern that confused prospects and killed deals.

Now I spend 30 minutes each morning working through my follow-up list. It's not glamorous. But those 30 minutes, repeated daily, generate more results than sporadic bursts of intense effort.

The honey badger doesn't make one dramatic attack and hope for the best. It keeps showing up, day after day, until it gets what it came for.

## Your Leads are Waiting

![Photo by Lukas Blazek on Unsplash](https://storage.googleapis.com/vtai-web-media-prod/cms/originals/blog-inline/ef41613426c323b951ca997939557c013409f198769519be04d867f144d60b42.webp)

If you're a founder struggling to balance building and selling, you're not alone. The pull toward product work is real and powerful. Shipping features feels productive in a way that sending follow-up emails simply doesn't.

But those warm leads represent real people who showed genuine interest in what you're building. They deserve a response. Your startup deserves the revenue.

Sometimes the best tool isn't the most sophisticated one. Sometimes it's the one that simply reminds you to show up.

Be the honey badger. Never let a warm lead go cold!

\*_For now, Honey Badger Sales is something I built for myself. I'm still tweaking it, learning what works, and using it daily to manage my own outreach._

_But if the problem I've described sounds familiar, I'd genuinely like to connect. Leave a comment or reach out to us by clicking here._

## Read more

*   [This AI Should Never Have Been Built](https://videotranslator.ai/blog/this-ai-should-never-have-been-build/)
    
*   [I Built Software Wrong for 7 Years. You Shouldn’t Do The Same.](https://videotranslator.ai/blog/i-built-software-wrong-for-7-years-you-shouldnt-do-the-same/)
    
*   [You Sound Like ChatGPT Now](https://videotranslator.ai/blog/you-sound-like-chatgpt-now/)

The habit I ignored that kept costing me deals You just finished a brilliant product demo. The prospect loved it.

The habit I ignored that kept costing me deals You just finished a brilliant product demo. The prospect loved it. They asked smart questions, nodded..

Sales Didn’t Kill My Deals. Silence Did.

We use cookies to improve site performance and understand how the portfolio content is being used.

Turn AI use cases into production workflows, internal tools, and customer-facing products with senior delivery judgment.

Practical AI Consulting That Ships

Elephant Stripes is a consulting firm that designs, builds, and ships AI products and delivery systems.

Elephant Stripes

Elephant Stripes designs and ships practical AI systems for real business workflows.

AI Agent

AI Agent articles