> The cheap AI era is coming to an end.

I believe most people are already aware, but let me try to explain it in the simplest way possible.

Picture your favourite **_all-you-can-eat buffet_**. The first time you go, it is incredible. Endless plates. One low price. You go back the next week. You bring your friends. Your friends bring their friends. The place is packed every night, and the food just keeps coming.

Then one day you walk in and the manager is standing at the door with a slightly uncomfortable expression. The crab legs are gone. The prawns have a serving limit. There is a new premium tier for the good stuff. The sign on the window still says _all-you-can-eat_, but something has clearly changed.

This is exactly what is happening with AI right now.

For the past two years, using AI felt like a magical, unlimited buffet. You could chat, generate, analyse, summarise, code, and create as much as you wanted for a flat monthly fee. The food kept coming. And behind the scenes, the restaurant was losing money on every plate.

That era is ending. And the reason it is ending tells you a lot about where AI is heading next.

## **How the AI Buffet Got Started**

![AI buffet illustration (Created with Canva AI)](https://miro.medium.com/v2/resize:fit:1400/1*6XH5LoyBF8EmAcMokDf82A.png "AI buffet illustration (Created with Canva AI)")

To understand why the buffet is changing, it helps to understand how it was funded in the first place.

When OpenAI launched ChatGPT Plus in 2023, the pricing was deliberately attractive. The goal was not to make money immediately. It was to get as many people as possible using the product, so they would form habits, build workflows, and become the kind of customer who would pay more later.

Think of it like Uber offering heavily discounted rides in a new city, or Costco handing out free samples at every corner of the store. The price is a **_customer acquisition strategy_**, not a reflection of actual costs.

It worked extraordinarily well. ChatGPT reached 100 million daily active users faster than any consumer app in history. Anthropic’s revenue grew 44 times in just 15 months. Millions of people signed up for flat-rate subscriptions and started using AI for everything.

The economics were sustainable because of how people naturally use AI in conversation. You type a message. You read the response. You think. Maybe you type another message five minutes later. The AI is only actively working during those brief exchanges. The rest of the time, the server is idle. Flat-rate subscriptions work when usage is spread out and human-paced, because you can average the costs across millions of people who use it at different times.

This is the buffet logic: nobody eats non-stop. Most customers take a plate, sit down, eat slowly, and leave. The restaurant can price for the average customer because the outliers do not break the model.

Then came the **_agents_**.

## **AI Agents: The Customers Who Never Left**

![The greedy AI agent (created with Canva AI)](https://miro.medium.com/v2/resize:fit:1400/1*hhRydzrT-fzNpwDy2tsNaQ.png "The greedy AI agent (created with Canva AI)")

An AI agent is not like a chatbot. You do not have a conversation with it and then go about your day. You give it a goal, and it works toward that goal continuously, taking actions, checking results, correcting mistakes, running searches, writing code, sending requests, and retrying when something fails. Over and over, without stopping to wait for you.

In buffet terms, the other customers left after dinner. The agents stayed. And they **kept eating all night.**

This changes the economics completely. One agent working on a complex software project for a day might make thousands of API calls. Each call consumes compute, which costs money.

The flat monthly subscription that made sense for a human having a few conversations per day makes very little sense for an agent running thousands of operations per hour.

The numbers bear this out in uncomfortable ways. One developer’s coding project with Claude ran up costs exceeding $150,000 in a single month through API usage. A power user documented by The New York Times burned through 1.8 million tokens in a single month, racking up a bill of $3,600. These are not bugs or misconfigurations. They are a preview of what normal agentic usage looks like at the infrastructure level.

As Eric Broda wrote in his Substack piece “[_The End of Token Subsidies_](https://agenticmesh.substack.com/p/the-end-of-token-subsidies)”:

> _“For two years, companies treated subsidised AI pricing as if it were durable economics. It was not. It was promotional pricing for a new kind of compute habit.”_

That promotional period is over. The kitchen is starting to ask questions about where all the food went.

## **Who Was Paying for All of It?**

![Photo by Logan Voss on Unsplash](https://miro.medium.com/v2/resize:fit:1400/0*oFtDG_O488sNM7eu "Photo by Logan Voss on Unsplash")

The honest answer is: mostly **investors**.

OpenAI has raised over $17.9 billion and is not yet consistently profitable despite enormous revenue. Anthropic has raised billions on the premise that it will eventually capture enough of the market to justify the losses.

The data centre buildout required to run these models at scale costs tens of billions of dollars in capital expenditure. Someone is funding the gap between what AI costs to run and what users actually pay.

For now, that gap is funded by venture capital, tech giants with deep pockets, and increasingly by sovereign wealth funds and government-adjacent investors who see AI infrastructure as strategic. Governments have indirectly contributed through tax incentives for data centre construction and energy infrastructure.

This is not a criticism. It is how new technology industries work. The telephone network was not profitable for decades. The internet required massive subsidies before it became commercially self-sustaining.

The subsidies create adoption, adoption creates data and capability, and capability creates a product worth paying a real price for.

But subsidies have to end eventually. Investors want returns. The losses cannot grow indefinitely. And the arrival of agents has dramatically accelerated the timeline on which that reckoning arrives.

## **What the Buffet Looks Like Now**

The changes are already underway, even if they are not always announced in big press releases.

Anthropic quietly tested removing Claude Code from its standard $20 per month Pro plan in early 2026. Claude’s Max plan now costs $200 per month and is positioned explicitly for heavy users.

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

OpenAI has introduced usage limits on its most capable models and launched higher tiers for users who need more. The era of genuinely unlimited access at a fixed low price is narrowing.

The direction of travel is clear. AI is moving toward **usage-based** billing models where heavy consumers pay proportionally more. There will be different tiers for access, with various features costing different amounts. Users will have better tools to monitor and manage their AI spending before receiving their bills.

Is this bad news? Not necessarily.

When companies are forced to operate more efficiently, they tend to innovate. Smaller, smarter AI models are already appearing that can do specific jobs at a fraction of the cost of the big general-purpose ones. The pressure to be profitable is pushing the industry toward more sustainable engineering choices.

But there’s no getting around the other part of the picture either. As Ed Zitron's analysis pointed out:**more compute does not make OpenAI or Anthropic’s services cheaper to offer**. The path to profitability goes through higher prices.

The buffet is switching to “pay by the plate.” For light, occasional users, that might not change much. For heavy users and businesses running autonomous agents around the clock, the bill is about to look very different.

## **What This Means for You**

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

If you are an individual user, the practical impact depends on how you use AI.

**Casual users** who chat with AI occasionally and use it for occasional writing, research, or creative projects will probably not notice much difference. Standard tiers will continue to exist at reasonable prices. The changes are aimed at the heavy end of usage.

If you are a **developer** or **small business owner** who is starting to build with agents, this is the moment to start paying attention to your AI costs the same way you pay attention to your cloud infrastructure costs. Set budgets. Monitor usage. Build with efficient models where the task does not require the most capable option available. The habit of treating AI spending as a variable cost to be managed rather than a flat subscription to be ignored is one worth developing now, before it becomes urgent.

For **businesses** already running significant AI workloads, the advice is to audit what your agents are actually doing, identify where compute is being consumed unnecessarily, and build approval workflows for tasks that might trigger large unexpected bills.

For **everyone**: AI is not going away. It is growing up. It is moving from a magical technology subsidised by venture capital into something more like a real utility, with real bills, real pricing tiers, and real consequences for wasteful usage. This is what maturity looks like in a technology industry.

## **The Buffet Will Still Be Open**

![Photo by Igor Omilaev on Unsplash](https://miro.medium.com/v2/resize:fit:1400/0*wj7Z4apKvyIDqARB "Photo by Igor Omilaev on Unsplash")

The unlimited era was genuinely fun while it lasted. Cheap, powerful, always-on AI changed how millions of people work, create, and solve problems. That shift is permanent regardless of what happens to pricing.

What is changing is the economic model underneath it. The kitchen is becoming more honest about what things actually cost. The all-you-can-eat sign is coming down in some places and being replaced with something more like a good restaurant: excellent food, clear prices, and the expectation that serious eaters will pay a serious bill.

That is not a tragedy. That is sustainability.

The tools will keep improving. The prices will keep coming down per unit of capability. And the companies that figure out how to use AI thoughtfully, measuring what they use and optimising how they use it, will find they are spending less and getting more than the ones who treated the buffet as something that would last forever.

Nothing does. But the kitchen is still open.

* * *

_Check out Eric Broda’s “_[_The End of Token Subsidies_](https://agenticmesh.substack.com/p/the-end-of-token-subsidies)_” and Ed Zitron’s “_[_AI Is Too Expensive_](https://www.wheresyoured.at/ai-is-too-expensive/)_” on Substack. I recommend these reads for anyone involved in AI infrastructure._

Why Your AI Subscription Feels Different Now

The truth about the AI buffet model that was never meant to last

The truth about the AI buffet model that was never meant to last. The cheap AI era is ending. I believe most people are already aware, but let me explain it simply

Read practical notes from Elephant Stripes on AI product delivery, automation, language technology, and useful software systems.

Blog | Elephant Stripes

Practical notes from Elephant Stripes on AI product delivery, automation, language technology, and the operational decisions behind useful software.

Blog

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..

Last week, I wrote an article called “[_A Translator Called Me Out, and They Were Right._](https://medium.com/@tathagat.banerjee/a-translator-called-me-out-they-were-right-2a61934bbb92)” I expected some disagreement. I expected the usual pushback about AI being inevitable, about adaptation being necessary, about how technology always creates more than it destroys.

What I did not expect was the volume and consistency of what came back.

Professional translators across LinkedIn responded with the same core message: you still do not fully understand how bad this has become.

Honestly, I think they are right about that, too.

## **The Feedback Was Not Abstract**

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

The responses were not theoretical concerns about some distant AI future. They were people describing a profession being economically hollowed out right now, in real time, in measurable ways.

I think the AI industry needs to sit with that, rather than immediately pivoting to optimism, which appears to be our default.

One comment reframed the conversation in a way I keep coming back to. She said: we need to stop asking “**will there be translators in the future**” and start asking “**will it be sustainable to be a translator in the future.**”

That is an entirely different question. And it is the right one.

Most AI discussions still frame everything around replacement, as in, will AI replace translators? But the people actually living through this are talking about sustainability.

Can you still earn a middle-class income doing this work? Can you still build a career around it? Can you justify the years spent mastering languages, culture, specialisation, nuance, domain expertise?

These are economic questions. Not technological ones. And the AI industry often avoids them because they are much harder to answer.

## **The Productivity Trap**

![Photo by Andreas Klassen on Unsplash](https://miro.medium.com/v2/resize:fit:1400/0*kKXKqKGmhy63DPFW "Photo by Andreas Klassen on Unsplash")

One of the most repeated ideas in AI is that AI handles the repetitive work so humans can focus on higher-order work.

You hear this constantly. “**Let the AI do the simple stuff. You do the complex stuff. Unlock creativity. Add strategic value.”**

The translators who responded pointed out the gap in that argument that I had glossed over. The industry never explains what the compensation model for that higher-order work actually looks like.

Because here is what is actually happening in post-editing work, which is the role many translators have been pushed toward: You are no longer translating from scratch. You are reviewing AI output. Monitoring for subtle errors, hidden inaccuracies, awkward phrasing, cultural mismatches, false fluency. The market response to this has largely been: you touched fewer words, therefore we pay you less.

There is a logic to that from a buyer’s perspective. But from the worker’s perspective, the work has not actually become easier. In many cases it has become more mentally draining. You are not reading your own prose for errors. You are reading AI output that often looks correct on the surface while containing mistakes that require genuine expertise to identify.

One commenter described it precisely: “**You are constantly monitoring for things that look right but are not. That is cognitively exhausting in a different way from translation itself**.”

The result is a profession that has become harder while simultaneously becoming less economically valuable. The efficiency gains do not flow to the translator. They flow upwards, to buyers, to platforms, to whoever controls distribution. The translator absorbs the cognitive load and hands the savings to the client.

That combination is not sustainable. And the translators are saying so clearly.

## **The Cruelty of the Transition**

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

Several responses touched on something I think deserves to be named directly.

Some commenters used the word “**cruel**” to describe the specific emotional dynamic of the current transition. I think that word is accurate, and I want to explain why.

These translators are not anti-technology. They are not refusing to adapt. They are not Luddites. Many have used computer-assisted translation tools like TRADOS for years. They adopted translation memory systems, terminology databases, workflow automation. They welcomed tools that made them better at their work.

The argument is not that technology is bad. The argument is that the economic value of their labour is collapsing faster than new forms of value are emerging.

And what makes it cruel is the contradiction they are being asked to hold simultaneously. The industry tells them: your expertise matters, human nuance still matters, cultural understanding still matters. And while that message is being delivered, their rates are collapsing in real time.

Being told your skills are irreplaceable while watching your income decline is a psychologically specific form of damage. It is not the same as being told you are redundant. It is being told you are valuable while being paid as if you are not.

## **The Training Problem Nobody Wants to Say Plainly**

Several translators raised something that the AI industry still does not particularly like discussing openly.

Their work is being used to train the systems that are replacing them.

One commenter put it in a way that has stayed with me: “**every edit, every correction, every quality adjustment is being squeezed for intelligence and fed back into the engines.”**

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

That sentence is uncomfortable. It points to something structurally different about AI compared to earlier tools.

Historically, tools amplified labour. A word processor made you faster at writing. A CAT tool made you faster at translating. The tool served the worker.

AI increasingly **_absorbs labour_**. Every correction a translator makes to an AI output potentially improves the model. Every high-quality translation they produce potentially reduces the future dependence on translators who produce that kind of quality. The worker trains the system that is competing against them.

Whether you think this is inevitable, good, bad, necessary, or some complicated mix of all of those things, it fundamentally changes the relationship workers have with the technology. Using the tool can feel indistinguishable from participating in your own displacement.

That is a very different psychological contract than any previous generation of workers has been asked to accept.

## **The Bigger Economic Question**

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

Several comments across platforms raised a question that sounds dramatic until you sit with it.

> “If AI keeps reducing the value of human labour across industries, who actually has money left to participate in the economy?”

Translation, writing, design, programming, support work, research, media, and coordination tasks. The jobs being impacted are predominantly white-collar knowledge work roles.

The core tension is this. AI massively increases productive capacity. But capitalism still distributes income primarily through labour. So what happens when society becomes more productive while human work becomes less economically valuable?

This is not a translation industry question. It is an economic question that affects many industries, and I do not think we have great answers to it yet. But it is an important question, and translators are asking it from the front line.

## **The Canary is Already in the Mine**

![Photo by Eddie Lau on Unsplash](https://miro.medium.com/v2/resize:fit:1400/0*Jk7TTwnWoBpk5FyU "Photo by Eddie Lau on Unsplash")

One reason translators deserve particular attention right now is that they are simply earlier than most knowledge professions at the bleeding edge of this transition.

Translation is one of the first knowledge professions to experience full-scale AI commodification. The outputs are digital. The evaluation criteria are probabilistic. The work maps extremely well onto what large language models are structurally good at. That is why the disruption hit translation so hard and so fast.

Translators are effectively living through a future that many other professions are only beginning to glimpse.

What they are telling us is this: the technological transition is moving much faster than the economic transition. The tools arrived. The compensation models have not. The rights frameworks have not. The labour protections have not. The new ownership structures have not. And the people caught in the middle are absorbing the shock personally.

## **Two Things Can Be True at Once**

I want to be clear about where I stand, because this matters given that I build AI tools, including [VideoTranslatorAI](https://videotranslator.ai/).

I still believe AI translation creates enormous positive value. VideoTranslatorAI started as an interpretation tool for clinicians when a professional interpreter was not available. That gap was real. The access it provides to patients who would otherwise have had no interpretation at all is genuinely good. I believe that multilingual communication becoming more accessible is broadly positive for humanity.

But I also think it is entirely possible for technology to create real societal value while simultaneously causing genuine economic pain to specific groups of people. Both can be true at the same time.

The translators who responded to my article deserve credit for forcing that contradiction into the open. For refusing to let the AI conversation stay comfortably abstract. For saying plainly that while the rest of the industry is discussing productivity, they are discussing survival.

Those are not the same conversation.

* * *

_Thank you to every translator who took the time to respond. The quality of your feedback changed how I think about this, and that is the point of writing publicly about hard things._

_Their valuable thoughts are available under the LinkedIn post I posted this week. If you’re interested in reading the whole discussion, click_ [_here_](https://www.linkedin.com/feed/update/urn:li:activity:7463460480326488064/)_._

What translators are experiencing is a preview of where this is all heading

Translators vs. AI Reality

What translators are experiencing is a preview of where this is all heading Last week, I wrote an article called “A Translator Called Me Out, and They Were Right.”

 Translators vs. AI Reality

Two billboards went up in New York City recently, and the image of them together has been circulating ever since because it captures something that a thousand think pieces have failed to say as clearly.

The first is sleek, dark, and almost cinematic. An AI-generated face with perfect symmetry stares out. Above her, three words in bold: “_Stop Hiring Humans._” Below is the tagline: “_The Era of AI Employees Is Here._”

![Artisan billboard above a New York City street. Photo by Kay Rubacek](https://miro.medium.com/v2/resize:fit:1212/1*62zlMyYuu0T7Nt7Se9egFQ.jpeg "Artisan billboard above a New York City street. Photo by Kay Rubacek")

The company is Artisan, an AI startup selling what it calls “AI employees” to replace human workers. The billboard is not trying to be subtle. It wants your payroll budget, and it is not embarrassed to say so.

The second billboard, in contrast, is light-coloured. It’s a sad stick figure holds a cardboard sign: “_Will Create 4 Food.”_ Floating above it, mock chat bubbles styled like a corporate memo: “_Thank you artists for donating your life’s work to our AI. Your generosity hasn’t gone unnoticed. Just uncompensated._”

![Replacement.AI billboard above a New York City street. Photo by Kay Rubacek](https://miro.medium.com/v2/resize:fit:1400/1*PP57tMnBVvcDOB1R3ChV2Q.jpeg "Replacement.AI billboard above a New York City street. Photo by Kay Rubacek")

This one was paid for by anonymous artists behind a project called [Replacement.AI](http://Replacement.AI). They are not selling anything. They spent their own money to put that message in one of the most expensive advertising spaces on earth. Their website describes itself as “_the only honest AI company._”

Two billboards. Between them is the argument that has not been resolved: whether what is being built is a tool or a replacement, a future or an ending.

## **What Actually Went Into These Models**

![Illustration: a robot painting on a canvas (generated by author with Canva AI).](/api/media/elephantstripes-prod/cms/originals/blog-inline/f70656b88857fde9074cf2e551f33a97a7682a089563905607ced0594a900d8c.avif "Illustration: a robot painting on a canvas (generated by author with Canva AI).")

The second billboard points to something real, and it deserves to be addressed directly rather than sidestepped.

The AI models powering the tools that promise to replace human workers were trained on an extraordinary volume of human-made content. Writing, art, music, journalism, code, conversations, arguments posted online at three in the morning. This ingestion happened fast, in server rooms, while most people were clicking “_I Agree_” on terms and conditions nobody reads.

In a submission to the House of Lords, [OpenAI](https://www.theguardian.com/technology/2024/jan/08/ai-tools-chatgpt-copyrighted-material-openai) acknowledged plainly that training today’s leading AI models without copyrighted materials would have been impossible.

The courts are beginning to reckon with this. Over 30 copyright infringement lawsuits have been filed against AI developers. [Getty Images](https://katten.com/getty-images-v-stability-ai-intellectual-property-rights-in-the-age-of-generative-ai) sued over 12 million scraped photographs. The New York Times sued OpenAI.

In January 2026, [Universal Music](https://www.billboard.com/pro/universal-music-sues-anthropic-ai-lawsuit-pirated-songs/) filed a $3.1 billion lawsuit against Anthropic, alleging its models were built on a foundation of unlicensed music. None of these cases has reached a final verdict. The legal system moves at human speed through a problem that was created at machine speed.

This matters not as an abstract legal question but as a practical one. The creative output that made these models useful came from people who received nothing in return for it. The second billboard is not being melodramatic. It is being accurate.

## **The Predictions That Contradict Each Other**

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

What makes the billboard image so powerful is that it sits at the exact point where expert opinion collapses into honest uncertainty.

[Goldman Sachs](https://www.goldmansachs.com/insights/articles/how-will-ai-affect-the-us-labor-market) estimates AI could displace the equivalent of 300 million full-time jobs. [The World Economic Forum](https://www.weforum.org/press/2025/01/future-of-jobs-report-2025-78-million-new-job-opportunities-by-2030-but-urgent-upskilling-needed-to-prepare-workforces/) projects 92 million jobs displaced by 2030 but 170 million new ones created, a net gain, on paper at least. [Dario Amodei](https://www.businessinsider.com/anthropic-ceo-warning-ai-could-eliminate-jobs-2025-5) at Anthropic has warned that AI could replace half of all entry-level white-collar roles within five years. In contrast, [Jensen Huang](https://fortune.com/2026/01/14/nvidia-ceo-jensen-huang-ai-lead-to-more-jobs-if-embraced-gen-z-market-struggles/) at Nvidia argues that greater productivity historically creates more hiring, not less.

Both billboards are right, which is the uncomfortable part. The cold efficiency promise and the stick figure holding a cardboard sign are not competing fictions. They are two real things happening simultaneously to different people.

## **The New Problem Nobody Planned For**

There is a second-order problem now developing that was not part of the original conversation.

The large language models (LLM) that power modern AI are hungry for training data, but human-created internet content cannot keep pace with the appetite of systems that do not sleep.

So the models are starting to train on AI-generated content, iterating upon their own outputs, creating a feedback loop that risks losing the human spark that made them genuinely useful in the first place.

What gets compressed out in that spiral is the thing [Replacement.AI](http://Replacement.AI) was trying to protect: the **grief**, the **wonder**, the **weirdness**, the specificity of **_human experience_** pressed into language.

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

Media organisations have noticed. The New York Times is now partnering with Amazon’s AI. News Corp with Meta. Reddit with Google. The finite supply of quality human-generated content is being licensed rather than scraped, which is a more honest arrangement.

But it doesn’t resolve the underlying tension between the velocity of AI development and the pace at which humans, institutions, and legal frameworks can adapt.

## **Where I Stand After Building This Stuff Every Week**

![Elephant Stripes: bespoke software studio](https://miro.medium.com/v2/resize:fit:1400/1*dLT4xoKvNBPiS8qkHAg4jw.png "Elephant Stripes: bespoke software studio")

I build custom AI software for businesses. I have seen what these tools genuinely do well and where the optimism is ahead of the reality.

The honest version of my view is this.

AI is a genuinely powerful tool for eliminating drudgery, handling high-volume repetitive tasks, and compressing the time between an idea and a working prototype. For a small team or solo operator, the leverage it provides is real and significant.

AI is not, in any current form, a full successor to human judgment, empathy, accountability, or the kind of creativity that comes from having lived a life with consequences.

The face on Artisan’s billboard doesn’t need to ground herself after a hard week. She doesn’t need anything. What is being sold there is not intelligence. It is the absence of need. That is genuinely useful for some tasks and genuinely inadequate for others, and the gap between those two categories is where most of the consequential decisions get made.

The advice I give clients consistently is the same. Use AI to remove the boring parts of what your people do, then ask what new value your people can create with the time that frees up.

Do not ask which roles you can eliminate. Ask what becomes possible if you remove the drudgery. The second question tends to produce better outcomes and better companies.

Keep humans in the loop for the decisions that matter: client relationships, ethical oversight, final judgment on anything consequential. Not because AI cannot simulate those things, but because accountability requires a human who can be held responsible, and that structural fact is not going to change regardless of how capable the models become.

## **The Argument is Still Open**

The artists behind [Replacement.AI](http://Replacement.AI) spent their own money to put a stick figure in Times Square because they felt the argument was being conducted without them.

They were right about that. The debate about AI’s impact has largely been conducted by the people building and funding these systems, with the people most affected by them treated as a data point in a projection rather than participants in a decision.

Both billboards represent real positions held by real people with real stakes in the outcome. The question of whether AI is being built as a tool or as a replacement is not settled by the technology itself. It is settled by choices: company by company, policy by policy, workflow by workflow.

The experts cannot agree on where this ends. The lawyers are still filing. The models are still training on whatever they can find. And somewhere in Times Square, a stick figure holds his sign, waiting for someone walking past to stop long enough to read it.

That is not a metaphor for despair. It is an invitation to be one of the people who stop.

* * *

_The two billboards described in this article were reported and photographed by Kay Rubacek via_ [_The Epoch Times_](https://www.theepochtimes.com/opinion/two-billboards-in-new-york-capture-the-conflict-of-our-time-6033720?utm_source=partner&utm_campaign=ZeroHedge) _and republished by_ [_ZeroHedge_](https://www.zerohedge.com/ai/two-billboards-new-york-capture-conflict-our-time) _on 25 May 2026._

We Still Don’t Know If AI Is Our Servant or Successor

And that uncertainty is the real story Two billboards went up in New York City recently, and the image of them together has been circulating ever since..

Last November, I wrote an article about AI and translation. A translator who works between Japanese and English recently left a comment on it that I have been thinking about ever since.

She wrote:

_“Everyone says with AI doing the translation work, it will allow translators to focus on higher order work, but no one tells how much translators are getting paid for such higher order work.”_

She was not wrong. And I want to address that directly, because articles like mine, including my own, have been repeating a comfortable narrative that is not the full truth.

The comfortable narrative goes like this: **AI is a tool, not a replacement.** **Translators will move up the value chain. The work becomes more interesting. Everyone wins.**

The uncomfortable reality is that translation rates have plummeted. And if you have trained for this work, built a career on it, and are good at it, that is genuinely awful.

No amount of enthusiasm about the potential of AI changes what is happening to people’s incomes right now.

## **What the Comment Was Really Saying**

![](https://miro.medium.com/v2/resize:fit:1400/0*U1dg9-YU8iGHU8UH.png)

She made a specific point that deserves to be taken seriously on its own terms.

She has been using computer-assisted translation tools like TRADOS for a decade. She is not anti-technology. Translators have never had a problem adopting tools that help them do better work faster.

The problem, as she put it, is that _“business and tech leaders are not presenting a complete true picture.”_ The articles, the conference talks, the LinkedIn posts. They celebrate productivity gains, new workflows, expanded reach. They do not talk about the income collapse happening at the same time.

She is right about that. And I think I owe it to her, and to every translator in the same position, to be more honest about it.

## **The Maths Nobody Wants to Say Plainly**

![Photo by Rodeo Project Management Software on Unsplash](https://miro.medium.com/v2/resize:fit:1400/0*6gT4IPD4TnSNF5_m "Photo by Rodeo Project Management Software on Unsplash")

Here is a simple way to think about what has happened.

If one translator using AI can now do the work that five translators did in 2019, the market changes. That is not a precise statistic. But even directionally, it points to something real. Four of those five translators either need to find different work or accept significantly lower rates as supply exceeds demand.

The total volume of translation might increase, because work that was previously too expensive to translate is now getting done. But the income per translator does not keep pace with productivity, because productivity gains flow to buyers and platforms, not to the people doing the work.

This is not unique to translation. It is happening across every knowledge-based profession that AI has touched. But translation has been hit particularly early and particularly hard because the core task of converting language from one form to another is exactly what large language models are structurally well-suited for.

The tools exist. The rates have moved. And the safety net, the institutional infrastructure that would help translators adapt and capture value in the new environment, does not yet exist in any meaningful form.

## **What the Future of Translation Work Probably Looks Like**

I want to be honest about something here. I do not have a complete answer to the question she raised. What I have is a direction that I think is probably right, and a clear acknowledgement of what is missing.

The direction is what I would call:

> **_Compute Allocation._**

Let me explain with an analogy from my own work. I write software. I used to write it by typing out code directly. Now I write detailed prompts that tell the AI what to build.

I have gone from being a programmer in the traditional sense to being a **compute allocator**: someone who decides what is worth building, how to direct the AI toward it, and where the AI’s output needs human correction.

My guess is something similar will happen with translation. The work shifts from manually translating every sentence to directing the AI, allocating attention to the parts that genuinely need human judgment, and deciding what is worth translating in the first place.

![Photo by Per Lööv on Unsplash](https://miro.medium.com/v2/resize:fit:1400/0*6COqe4hh_pVOjeIU "Photo by Per Lööv on Unsplash")

Practically, this might look like a translator who understands a particular language and culture well enough to spot that a YouTube channel has a real audience in their language that the creator does not know exists. They translate it, using AI for the volume of work. Their value is not the typing speed. It is the cultural intelligence that identifies the opportunity and the taste that knows which 5% of the output needs a human hand rather than an AI second draft.

That is real expertise. It is different from what translation work looked like in 2019, but it is no less skilled. In some ways, it requires more.

## **The Gap That Has Not Been Filled Yet**

Here is where I want to be direct about what is missing, because this is the part of the conversation that usually gets skipped.

The future I just described, where translators operate as compute allocators and cultural curators, only works if the economic infrastructure exists to pay them for that role. Right now, **it largely does not.**

![Photo by Jakob Owens on Unsplash](https://miro.medium.com/v2/resize:fit:1400/0*zMbgfFKSojLDHSg1 "Photo by Jakob Owens on Unsplash")

If a translator identifies an opportunity, translates a video channel into a new language market, and that translation drives genuine audience growth and revenue for the creator, how does the translator capture a share of that value?

Currently, the answer is: **they mostly do not**. They get paid a one-time fee, if they are lucky, and the upstream value they created disappears into someone else’s analytics dashboard.

What would need to exist is something like a translation rights and revenue-sharing model. A platform where creators make their content available for translation, translators take on the work knowing they will receive a share of the downstream traction, and both parties benefit as the audience grows. Think of it as translation curation with ongoing royalties rather than flat-fee work-for-hire.

Something like this does not exist in any mature form today. The pieces are technically possible. The economic model is coherent. The reason it does not exist yet is that it is a genuinely hard coordination problem: you need creators willing to share revenue, translators willing to take on speculative work, a platform able to track attribution across languages, and a payments infrastructure that can handle micro-distributions at scale.

That is not an excuse. It is an honest account of why the transition is painful right now, even for people who can see where it is heading.

## **What We Believe at VideoTranslatorAI**

Again, we need to say this clearly.

We did not build [VideoTranslatorAI](https://agent.videotranslator.ai/) to replace translators. We built it to make multilingual communication accessible in settings where it was previously impossible: a nurse trying to explain a diagnosis to a patient who speaks a different language, a small business owner trying to reach a customer overseas, a community health worker trying to run a group session across five different languages simultaneously.

These are **not situations where a professional translator was sitting ready and got displaced**. These are situations where **no translation was happening at all, because it was impractical or unaffordable**. The access gap we are trying to close is real, and the people we are trying to serve genuinely needed the tool.

Press enter or click to view image in full size

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

At the same time, the world is changing in ways that affect professional translators, and pretending otherwise is not honest. The demand for high-volume, routine translation work is increasingly served by AI. The demand for judgment, cultural knowledge, and the kind of taste-based decision-making that determines what is worth translating for whom is not going away. It is, if anything, becoming more valuable.

The problem is that the gap between those two realities is where a lot of skilled, experienced translators are currently sitting, watching their rates fall without a clear path to the higher-value work they are told is waiting for them.

We acknowledge that. It is not a gap we created, but it is one that the industry, including companies like ours, has a responsibility to think about more seriously than it has been.

## **To the Translator Who Wrote That Comment**

Thank you for saying it plainly. Your comment was more useful than most of the optimistic takes I have read on this topic, including what I wrote.

The income collapse is real. The higher-order work is real in potential but not yet real in practice for most people. And the infrastructure that would make it real, the rights frameworks, the revenue sharing models, the platforms that let translators monetise cultural intelligence rather than volume, has not been built yet.

That is the honest picture. It does not mean translation as a profession is finished. It means the profession is in a painful, unresolved transition, and the people experiencing that transition deserve a clearer acknowledgement of what they are dealing with than they have been getting.

The tools will get better. The economic models will eventually catch up. Neither of those things helps someone whose rates have already dropped by half.

That part is genuinely hard, and I do not want to minimise it.

* * *

_The original comment referenced in this article was left by a Japanese to English translator on the following Medium Article:_

[_AI Translation is Already Running These 7 Jobs_](https://medium.com/@tathagat.banerjee/ai-translation-is-already-running-these-7-jobs-91e26fe86302?source=post_page-----2a61934bbb92---------------------------------------)

A Translator Called Me Out. They Were Right.

The income collapse nobody in AI wants to talk about.

The income collapse nobody in AI wants to talk about. Last November, I wrote an article about AI and translation. A translator who works between Japanese and English..

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..

We have been rolling out a series of in-app guided tours to help new and returning users get up and running quickly. Rather than keep them separate, here is everything in one place: the Prompt Tour, the Interpret Tour, and the Video Call Tour.

Each tour is available anytime inside the app by clicking **Take a Quick Tour** inside the chat..

## **Tour 1: Building a Prompt**

**Goal: Get the best summary result from the first meeting.**

The Building a Prompt Tour walks you through how to customise the AI so it produces summaries that match your specific needs, your terminology, your format, your tone.

**Step 1: Open the Custom Prompt Setup.** Click the **Custom Prompt Setup** button inside your chat interface. This opens the prompt builder where you define your preferences.

![](/api/media/elephantstripes-prod/cms/originals/blog-inline/2e8e4005d2060d96ae30c2c8a32df59cb8b309a4da7e8750530d42d193172533.avif)

**Step 2: Build your summary prompt.** Choose from pre-set options to guide the AI: the Session Type (Team Meeting, Client Pitch, etc.), the Formatting Style (Bullet Points, Narrative, etc.), and the desired Tone (Formal, Action-Oriented, etc.).

![](/api/media/elephantstripes-prod/cms/originals/blog-inline/2d1eb9e6858b8e5e689743f8719e60f5464655f475ecc992fdb40ed2b1e4abe8.avif)

**Step 3: Add context and constraints.** Tell the AI about speaker roles, topic areas, and any terminology it should prioritise or avoid. This is where the summary goes from generic to genuinely useful.

![](/api/media/elephantstripes-prod/cms/originals/blog-inline/0f32a3f2c26c9ab3cc31f122cb43546b31e85254600f4c3d950c1162d1ce6d3c.avif)

**Step 4: Preview and save.** Run a quick preview and save your configuration as a reusable template. You will not need to set this up again for the same type of session.

![](/api/media/elephantstripes-prod/cms/originals/blog-inline/cb6d1206c1499a0962e87ee1d36571849f24216c1de7b9b4afcb3ef6052f21e9.avif)

**Best for:** First-time users and anyone who wants consistent, customised summaries across meetings.

* * *

## **Tour 2: How to Interpret**

**Goal: Run your first live interpretation session with confidence.**

The Interpret Tour walks you through VideoTranslatorAI's real-time interpretation mode, where two people speaking different languages can have a live conversation with AI handling the translation in both directions.

**Step 1: Select interpretation mode.** Click the ‘Interpret’ button located next to the Transcribe button, and you’re ready to go. 

![](/api/media/elephantstripes-prod/cms/originals/blog-inline/de3df020cff6510fd75c9ea4cd5632f5e509f167e33c2c08e090a9b0a719837c.avif)

**Step 2: Configure speakers and languages.** Assign the languages to be used in your meeting. A maximum of two languages can be selected for in-person interpretation and video call mode. 

![](/api/media/elephantstripes-prod/cms/originals/blog-inline/a4f2950b9dd62e737e202a305c635fc632bf373e192b13193f8ab4f01d42c979.avif)

**Step 3: Start the session.** Activate live audio capture. The tour walks through microphone permissions, audio quality checks, and how to pause or restart mid-session.

![](/api/media/elephantstripes-prod/cms/originals/blog-inline/d3c28745c61d362ff8b29ce1ef2fd6c3e30d6f462dbce99135741b3e5e4a52f6.avif)

**Step 4: Review and export.** When the session ends, access a structured summary of the conversation. Export it as a document or share it with participants directly.

**Best for:** Healthcare consultations, legal interviews, client meetings, and any setting where live, accurate interpretation matters.

* * *

## **Tour 3: Setting Up a Video Call**

**Goal: Host a multilingual video call in under two minutes.**

VideoTranslatorAI has its own built-in video call platform. No third-party meeting tool required. The Video Call Tour covers the full setup from selecting a mode to sending invitations.

**Step 1: Activate Video Call mode.** From your active chat, select Video Call mode. Choose whether the call will run in interpret mode (two languages) or transcribe mode (English-only transcription).

![](/api/media/elephantstripes-prod/cms/originals/blog-inline/62660a40827287e38b2cd31f915d972301f4f0bdb74ddc63933525e3b9bb4f35.avif)

**Step 2: Open the setup form.** Fill in the meeting time and each participant's name and email address. If you are running interpret mode, assign each participant their preferred language here.

![](/api/media/elephantstripes-prod/cms/originals/blog-inline/1e22cc9cd5302b5c80a9e55310983e3aee84cbaee2b9f68cd5223adc9b1233f5.avif)

**Step 3: Send meeting invitations.** Generate the participant invitation and send it. VideoTranslatorAI automatically translates the invitation into each participant's language before it goes out.

![](/api/media/elephantstripes-prod/cms/originals/blog-inline/65ecfc3aba34cb1aee3b62c112c6e810b0135e533302bf3ce94bcd860cdb6a0c.avif)

**Step 4: Run the call.** Once both parties connect, live subtitles appear automatically. Toggle on voice-over if you want each participant to hear the conversation in their chosen language in real time.

![Video call - newest](/api/media/vtai-web-media-prod/cms/originals/page-inline/5576c0f316dcc32912e1274db4b155ae7e42783401001378db9bf3a3270f6a7f.avif)

**Best for:** Cross-language client calls, consultations, and interviews where you need a self-contained multilingual video platform.

## **Ready to Start?**

All three tours are live in the VideoTranslatorAI app now.

[**Open the app and take a tour →**](https://agent.videotranslator.ai)

Your Complete VideoTranslatorAI Starter Guide

Three tours, one place, zero guesswork. We have been rolling out a series of in-app guided tours to help new and returning users get up and running quickly...

There’s a phrase that quietly runs most business software decisions: “good enough.”

It’s how companies ended up on WordPress, Shopify, or whichever open-source CMS more or less solved the problem.

It’s why internal tools are a patchwork of Notion, Airtable, and three integrations held together by an optimistic Zapier workflow.

“Good enough” made sense for a long time. Bespoke software was expensive. It required big teams, long timelines, and a budget that only enterprise companies could justify without flinching. So small and mid-market businesses made do. They bent their processes to fit their tools.

That era is ending. Bespoke software is back, and AI is the reason.

## **The Pendulum, and Why It Swung**

![Photo by engin akyurt on Unsplash](https://miro.medium.com/v2/resize:fit:1400/0*cgws-OOEaOzbv1H9 "Photo by engin akyurt on Unsplash")

Cast your mind back to the late 90s and early 2000s. Digital agencies were building bespoke content management systems for businesses of all sizes.

Every client got something crafted from scratch, tailored to exactly what they needed. It was expensive, sometimes messy, and occasionally out of date the moment it shipped, but it was theirs.

Then the economics shifted. Open-source platforms matured. WordPress became the default answer to almost any web problem.

Tools like Drupal, Joomla, and later Shopify, Webflow, and dozens of SaaS alternatives made standardised software the sensible choice. It had security updates, active communities, and enterprise tiers if you needed to scale.

Migrating to these platforms was smart. For most businesses, it was the right call.

Standardised software is built for the widest possible audience. By design, it’s a compromise. And the compromise starts showing itself the moment your needs drift even slightly outside the mainstream.

You want to restructure how SEO metadata is managed across your pages? File a request and hope it makes the roadmap. You want your blog, email sends, and contact management in a single admin panel that actually reflects your workflow? Good luck finding that out of the box. You need structured data configured exactly the way Google expects for your specific content type? You’re probably doing it manually, in multiple places, with no single source of truth.

That’s the ceiling of “_good enough._” And AI has just given us a way past it.

## **Why Bespoke is Suddenly Affordable**

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

Building custom software used to come down to one constraint: time. Developers are expensive. Good developers are very expensive. A small team building a bespoke CMS or internal tool represented months of salary, testing, iteration, and maintenance. Most businesses simply couldn’t justify it.

AI has collapsed that constraint.

Done **_correctly_**, AI-assisted development doesn’t just speed things up. It applies best practices systematically, because it’s trained on them.

You’re not trading quality for speed. You’re getting both. What once required a team of five over six months can now be built by one person with the right process in a fraction of the time.

The gap between “bespoke” and “affordable” has essentially closed. And once that gap closes, the whole calculus of software procurement changes.

## **Our Own Path Through the Platforms**

At [Elephant Stripes](http://elephantstripes.ai/), we didn’t arrive at this conclusion theoretically. We went through it.

VideoTranslator, our core product, has had a few homes over the years. It started on Hugo: a static site generator that was genuinely fast and easy to work with. Blog posts were markdown files, GitHub Actions handled deployments, and there was no backend to speak of. Lean, performant, and exactly right for where the business was at the time.

As the product grew, so did the requirements. We moved to a frontend framework with Forestry as the CMS. Forestry was decent, but it had limits we kept running into, and the frontend wasn’t something we were proud of.

![VideoTranslatorAI’s website interface in early (Hugo frontend; Strapi backend)](https://miro.medium.com/v2/resize:fit:1400/1*BSZsFV12yTFUuz2rJX2oJw.png "VideoTranslatorAI’s website interface in early (Hugo frontend; Strapi backend)")

Then came a rebrand. We moved to Gatsby on the frontend with Strapi as the backend. Strapi is genuinely good software. Gatsby, another static site generator like Hugo, had real promise as a concept, but the project eventually stalled. Community support faded. It just didn’t age well.

Each of these platforms worked, in the way that “good enough” works. None of them was exactly what we needed. We were always working around something.

## **Building the CMS We actually wanted**

Early this year, my team and I started spending a lot of time with what people are calling vibe coding: using AI to build software quickly, iteratively, with a rough idea rather than a full spec. It was genuinely fun, and it was **fast**.

And at some point, it occurred to me that instead of adopting yet another platform, we could just build the CMS we’d always wanted.

What did that look like?

We wanted all our SEO in one place. Not scattered across plugins, settings panels, and meta boxes, living in three different corners of an admin interface.

We wanted to sit on a single page and see the page title, meta description, Twitter card image, and JSON-LD structured data all together.

Press enter or click to view image in full size

![Our Bespoke CMS for VideoTranslatorAI](https://miro.medium.com/v2/resize:fit:1400/1*_e24qm_kzIpzPePK89hYaw.png "Our Bespoke CMS for VideoTranslatorAI")

JSON-LD is the structured data format that tells Google explicitly what your content is about. It’s what powers those rich snippets in search results: the business name, hours, reviews, and product details laid out clearly beneath the main link.

In a generic CMS, getting JSON-LD right is fiddly. It involves plugins, workarounds, and guessing whether something fell back to a default.

In a bespoke CMS built for our specific needs, every single page has an SEO section. Right there, next to the content. Set it, confirm it, done.

We also wanted our blog system to handle email sends. We wanted project pages, recognition sections, and contact management in the same admin interface, so our team didn’t have to context-switch between platforms.

We wanted the whole thing to reflect how our business actually works, not how an open-source contributor imagined a generic user might manage content.

Building this even five years ago would have been a significant investment. This year, it took weeks.

![VideoTranslatorAI’s website interface today. Powered by our bespoke CMS.](https://miro.medium.com/v2/resize:fit:1400/1*3YVYEIYVW8WwZrSTypnfeQ.png "VideoTranslatorAI’s website interface today. Powered by our bespoke CMS.")

## **What The Improvement Process Looks Like**

Bespoke software gives you something else that off-the-shelf platforms can’t: genuine ownership of the improvement loop.

When I identified recently that our CMS needed better SEO hygiene across pages, I didn’t file a feature request and wait.

I ran an audit of the current site state, cataloguing what was missing, what was inconsistent, and what was falling back on defaults that weren’t quite right.

With that audit, I created a deep-dive analysis to validate the gaps in detail. From there, an implementation plan with clear phases: what to fix, in what order, with what expected outcomes.

After that, I set an AI agent to work executing the plan. It ran for about 28 minutes, worked through each phase, wrote a changelog for each one, and handled the database migrations I’d flagged. I tested the output, and I’m confident to say that it looked good.

The whole cycle, from spotting the problem to reviewing the result, happened in a single working session.

Compare that to the experience of trying to get a similar fix done inside an off-the-shelf platform: filing support tickets, waiting on plugin updates, hoping a third-party integration doesn’t break when the platform updates underneath it.

The bespoke path is faster, more predictable, and leaves zero mystery about what changed and why.

_Watch how I optimise website SEO with Codex:_

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

## **The Benefit Nobody Mentions**

Something that surprised me when I went through this process, and I think it’s genuinely underrated.

Building bespoke software forces clarity about what you actually need.

When you can’t point at a feature on a pricing page and say “that one,” you have to define it yourself. You have to think about what the tool should do, how your team will use it, what the edge cases are. That process of definition is uncomfortable at first. But it produces real understanding of your own business.

People often come out of a bespoke build with sharper workflows, cleaner thinking about their product, and a much better handle on what matters versus what they thought mattered.

The software becomes a side effect of getting clear.

![Photo by Balint Mendlik on Unsplash](https://miro.medium.com/v2/resize:fit:1400/0*eeTuRUb5Zgfcx7OO "Photo by Balint Mendlik on Unsplash")

## **Is Bespoke Right for Everyone?**

My honest answer to this question is: No. Not automatically.

If your requirements genuinely match a standard product, or if your team needs something deployed tomorrow with no time to build, off-the-shelf can still be the right call.

But if you’ve ever found yourself fighting your tools, building workarounds, or paying for features you’ll never use while missing the one feature you actually need, bespoke is worth taking seriously.

The cost is lower than you assume. The timeline is shorter than it used to be. And the outcome: software that fits your business rather than asking your business to fit the software, is genuinely hard to replicate.

At Elephant Stripes, this is what we do. We build software that reflects how your business actually works. Whether that’s a custom CMS, an internal tool, or a full application with its own admin system, we build it to fit exactly, not approximately. If that sounds like something worth a conversation, drop us a message [here](https://elephantstripes.ai/contact).

Bespoke software is back. And this time, the economics are on its side.

* * *

_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)

AI just changed the maths. Here’s what that means. There’s a phrase that quietly runs most business software decisions: good enough It’s how companies ended up on WordPress, Shopify, or whichever open-source CMS more or less solved the problem...

Bespoke Software is Back in Vogue

AI just changed the maths. Here’s what that means. There’s a phrase that quietly runs most business software decisions: good enough It’s how companies ended up...

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...

Three years ago, South Western Sydney Local Health District (SWSLHD) issued a challenge that quietly captured something important about the gap between what Australia's healthcare system promises and what many patients actually experience.

For the 40% of SWSLHD's community who speak a language other than English at home, accessing equitable, safe health care too often depends on the availability of a professional interpreter. When one is not available, the consultation proceeds anyway. Information gets lost. Patients leave without fully understanding their condition or their care plan. Clinical staff do the best they can.

The 2022 NSW Small Business Innovation and Research Program CALD Services Challenge asked: **_could AI change this?_**

Today, we are proud to say that it can, and that MediCALD is the result.

## **Thank You**

None of this would exist without the commitment of the clinical and program teams who worked alongside us from the beginning.

From SWSLHD, our clinical stakeholders Josephine Chow, Safa El-Dadoun, Aleisha Heys, and Sam Shen brought rigorous, patient-centred thinking to every stage of the program. Their willingness to challenge our assumptions and redirect our focus when the evidence pointed elsewhere is the reason MediCALD became something genuinely useful rather than merely technically interesting.

From the Office of the Chief Scientist and Engineer (OCSE), Aashna Rampal, Lewis Bennet, and Carlos Carbonato-Bowket provided outstanding program support across all three phases. Their guidance kept the project anchored to the objectives of the SBIR program while giving us the space to build and iterate properly.

We are grateful to all of you.

## **How We Got Here**

### **Version 1: Video Translation Application (2023)**

The Feasibility Study delivered what the original challenge brief described: a platform that allowed health communications staff to upload existing video content, transcribe it, translate it into multiple CALD languages, and apply AI-generated voiceovers. The medical terminology management tools worked well. The technology was sound.

![Version 1 interface of the Video Translation Application.](/api/media/elephantstripes-prod/cms/originals/blog-inline/c20857f596ecba8c36e032ff739ad54ac04e0891ee734de16f3e124958070269.avif "Version 1 interface of the Video Translation Application.")

But early conversations with clinical staff at SWSLHD surfaced something more urgent. The gap they were experiencing every day was not in translated video content. It was in the consultation room itself, where a midwife, nurse, or community health worker needed to communicate with a patient who did not speak English, right now, without a professional interpreter available.

That insight changed everything.

### **Version 2: Telehealth Application (2024 to 2025)**

The Proof of Concept set the video translation application aside entirely and rebuilt around the real clinical need: live, two-way interpretation during consultations. Version 2 introduced a telehealth application providing real-time AI-assisted communication between a clinician and a CALD patient, with both video call and in-person consultation modes, AI transcription and translation in the chat interface, multilingual voiceover output, broadcast capability for group health sessions, and an interpreter call-in feature.

![Version 2 telehealth interface: two-way consultation with live transcription and translation.](/api/media/vtai-web-media-prod/cms/originals/page-inline/5576c0f316dcc32912e1274db4b155ae7e42783401001378db9bf3a3270f6a7f.avif "Version 2 telehealth interface: two-way consultation with live transcription and translation.")

This was the version that clinical staff actually used in practice. The feedback it generated shaped everything that came next.

## **The Market-Ready Platform**

Version 3 is MediCALD as it stands today: a production-grade, enterprise-ready health communication platform designed to be deployed across health organisations and embedded into existing clinical workflows.

The shift from Proof of Concept to market-ready product involved not just expanding features, but rethinking how the platform fits into a health organisation's broader technology and compliance environment. Every capability in Version 3 was designed with that context in mind.

![Version 3 interface: Interpret Mode with summary.](/api/media/elephantstripes-prod/cms/originals/blog-inline/fa49bfef36fde4532c761838fdb9b8a972dbbd86bdc85bc86092d21494208f30.avif "Version 3 interface: Interpret Mode with summary.")

**Session summaries and smart prompts** automatically generate a structured record of each consultation at close. Clinicians receive a clear, organised summary without the administrative burden of manual documentation during or after the session.

**Enhanced transcription and translation** deliver improved accuracy, lower latency, and better contextual understanding across all supported languages, powered by OpenAI as the primary AI provider. The platform now also supports English-only transcription as a standalone capability, making it useful to any organisation that needs reliable transcription independent of translation.

**A significantly simplified user experience** reduces the entire session setup to selecting a mode and language pair. The session begins automatically. What previously required several configuration steps now takes seconds.

**Native iOS and Android mobile applications** mean MediCALD can be deployed on any device in the care pathway, from a desktop workstation at a clinic to a tablet carried into a patient's home.

**Self-hosted deployment** allows health organisations to run MediCALD within their own server infrastructure. For organisations with data sovereignty obligations and cybersecurity requirements, this is often a prerequisite for adoption rather than a preference.

**Single Sign-On integration** enables clinical staff to access MediCALD using their existing organisational credentials, removing the friction of separate logins and simplifying rollout at scale.

**Multilingual appointment reminders** are automatically sent to patients in their preferred language ahead of scheduled consultations. This addresses one of the consistently reported challenges in CALD health service delivery: non-attendance driven by miscommunication or uncertainty about appointment details.

## **What Comes Next**

The NSW SBIR program provided the structure, the funding, and the partnership that made MediCALD possible. What it produced is a platform that is ready to go beyond the pilot context and operate at the scale the clinical need demands.

SWSLHD's challenge named a problem that exists across every health district in Australia. Linguistically diverse communities face real inequities in health access and outcomes when language is a barrier. MediCALD was built to reduce that barrier practically and sustainably within the constraints of real clinical settings and organisational requirements.

We are proud of what the program produced, and grateful for the partners who made it worth building properly.

For organisations interested in MediCALD, please reach out at [elephantstripes.ai/contact](http://elephantstripes.ai/contact).

From the 2022 NSW SBIR brief to a production-ready platform Three years ago, South Western Sydney Local Health District (SWSLHD) issued a challenge that quietly captured something important...

The Last Chapter of Our NSW SBIR Journey

From the 2022 NSW SBIR brief to a production-ready platform Three years ago, South Western Sydney Local Health District (SWSLHD) issued a challenge...

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”...

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.

Blog

Why Your AI Subscription Feels Different Now

Recent thinking

Still Patching Servers at 2 AM? Stop.

How to Make AI Actually Know You for Job Applications

Translators vs. AI Reality

We Still Don’t Know If AI Is Our Servant or Successor

A Translator Called Me Out. They Were Right.

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

Your Complete VideoTranslatorAI Starter Guide

Bespoke Software is Back in Vogue

How I Used Codex to Fix My SEO in 20 Minutes

The Last Chapter of Our NSW SBIR Journey

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

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