Do Anything AI — Blog

Most of AI engineering is glue

chris@doanythingai.com (Chris) — Sat, 18 Apr 2026 00:00:00 GMT

I opened a pull request this morning for a feature that took me three days. The PR has 640 lines changed. Forty of them call the LLM. The other 600 are the reason the thing actually works in production.

That ratio is not unusual. That ratio is basically every AI feature I have ever shipped, and it's been gnawing at me how different it is from the way "AI engineering" gets talked about online. So I want to write down the ratio, why it refuses to budge, and what it means if you're hiring or applying for these jobs.

The feature I shipped this morning

User pastes in a long piece of text. The app summarises it, pulls out the entities, assigns a category, stores the whole thing. Simple product, one screen, one input.

The LLM code is forty lines. A prompt, a JSON schema, a retry loop, a parse, some small validation. That part took me about ninety minutes, most of which was wording the prompt.

The other 600 lines are, and I'm going to list them so the shape is visible: authentication, rate limiting per user, the job queue, the worker that pulls from the queue, the storage schema, idempotency keys so retries don't double-charge the user, per-request cost tracking, error states for when the text is too long or the model times out, the admin tool I built for myself to inspect runs that went sideways, the tiny dashboard that tells me whether today's cost is tracking where it should, tests for the non-LLM parts, and observability hooks for when something goes wrong at 3am.

Nothing in that list is "AI." All of it is how software has always worked. The AI is a function call in the middle.

Why the ratio never inverts

When I started shipping LLM features four years ago, I assumed the AI layer would grow over time and the plumbing would shrink. The opposite has happened, consistently.

Every time a better model comes out, I delete AI code. The GPT-3-era version of the feature I shipped this morning had custom chunking, a reranker, a manual eval rig, three different prompts that got composed together. The modern version is five lines of structured output, one prompt, one schema, done. The model got reliable enough that the complexity moved out of my codebase.

But it didn't disappear. It moved into the surrounding system. When the model becomes reliable, the bottleneck becomes everything else. How you queue the work. How you recover from failures. How you let users see what's happening. How you don't burn through your API budget in a week because one user found a way to paste in a 400k token input.

None of that is AI. It's just engineering. And because the AI layer keeps getting simpler, the glue layer keeps getting proportionally bigger. Better models make the ratio worse, not better, if you measure "worse" as "percentage of code that is actually about the model."

The moat is in the 600 lines

This is the part I want people to sit with, because it's the part that changes how you should spend your time.

The forty lines that call the LLM? Anyone can write those. They're a copy of the API docs. The moat of an AI product isn't in the prompt. It's in the idempotency, the cost controls, the error UX, the queue, the admin tooling. The stuff that makes the product not fall over when real users hit it at real scale.

A competitor who studies your prompt can replicate the prompt in an afternoon. A competitor who has to replicate your whole production system — the retry logic, the cost guardrails, the admin UI you built so your support team can answer a refund email — is going to take months, and might not even bother. The glue is where the durable advantage lives.

If you understand this, you spend less time tinkering with prompts and more time building the boring infrastructure. Which is exactly backwards from the Twitter version of the job.

Who you should hire (and who you are)

Every month I see roles posted for "AI engineer" where, if you read the actual job description, 85% of the work is queues, databases, retries, dashboards, and frontends. And then the company is surprised when the research-heavy candidate they hire is disappointed by the job, and the company is disappointed by the candidate.

If you're hiring to ship AI products, you are hiring a product engineer who happens to be comfortable calling a model. Not a researcher. Not a fine-tuning specialist. Not someone whose last project was comparing chunking strategies on a 200-page PDF.

I'd rather hire an engineer who has taken one boring SaaS from zero to a thousand users than an engineer who has fine-tuned five models but never deployed anything. The former will pick up the prompt layer in a week. The latter will spend six months figuring out why their jobs aren't getting processed, and by the time they solve it, the feature will have missed its launch.

The flip side is also worth saying out loud: if you're applying for AI engineer roles and you came from a non-AI background, you are massively underestimating how much of the job is stuff you already know how to do. Apply.

What this isn't

I want to say this before anyone reaches for the comments.

I'm not saying the LLM layer is trivial. Getting a prompt to be reliable across real user inputs is genuinely hard. Evals are genuinely hard. Latency-cost-quality trade-offs are genuinely hard. If you're building a product where the model is the product — a coding agent, say, or a legal-search engine — that ratio tips much further toward AI work than what I'm describing.

But for the majority of "AI features" that are shipping inside normal software products right now, the ratio is 10% model and 90% everything else. The sooner you embrace that the sooner you ship, and the sooner you ship the sooner you find out whether the model actually solved the problem you thought it did.

Learn the 10%. Learn the 90%. People who only know the 10% can make a prototype. People who know both can ship a product.

Programmatic SEO still works

chris@doanythingai.com (Chris) — Fri, 17 Apr 2026 00:00:00 GMT

In March of 2024 I watched a pSEO site of mine go from 300k monthly pageviews to 14k in nine days. Same site, same pages, same content. Google just stopped showing it. It never recovered.

A few months later, a different pSEO site I run hit a million pageviews for the first time. Same framework, same deploy pipeline, same "programmatic" approach to generating the pages.

Both are true at the same time, and the difference between them is the most useful thing I've learned about SEO in the last three years. This is me trying to spell it out, because every time Google runs a big update someone announces programmatic SEO is dead on LinkedIn and I want to be able to link to this post instead of typing the same rebuttal.

The specific kind of pSEO that died

Not all of it. The version that died is the version that deserves to be called dead.

If you scraped Wikipedia, ran it through an LLM to "rephrase," dropped the output into a template with 50,000 thin pages, and waited for traffic — that site is dead. Google got extremely good at spotting that exact shape around early 2023 and they've only sharpened since. The shape is what they can detect: enormous page count, tiny information-per-page ratio, no signal that any human ever touched the content.

My site that dropped from 300k to 14k looked like that. Not because I'd deliberately farmed it, but because over three years it had drifted in that direction. I'd kept adding pages faster than I was deepening them. Google noticed.

Google doesn't hate scale. It hates thin. The two get conflated in every "pSEO is dead" post I read, and they're completely different things.

The one test that predicts which sites survive

Here's the test that would have saved me that 300k site if I'd known it in 2021:

Would I be proud of this page if I'd had to write it by hand?

If the answer is yes — if a human could look at one of my pages and think "oh, someone who knows what they're talking about wrote this" — the page survives updates. If the answer is "uh, maybe if you squint," it's at risk. If the answer is "no, this only exists because templates made it exist," it's going to get nuked sooner or later.

Apply that test to KeqingMains, which is technically a pSEO site with thousands of pages. Each page is a character guide, a weapon guide, a mechanic explainer. Each one exists because somebody actually wanted that specific answer, and somebody who cared wrote or reviewed it. I'd be proud to put my name on any of them. The site has been through every major Google update since 2021 and it just keeps growing.

The word "programmatic" describes how the pages get produced. It does not describe whether the pages are worth anything. Those are separate axes, and if you flatten them into one thing you'll draw the wrong conclusions about what ranks.

What I actually ship differently now

Three things changed in how I build pSEO sites after that 300k-to-14k afternoon.

First, I cite actual data. Numbers, quotes, sources, screenshots. Not "studies show" but "in the March 2024 patch notes, the attack scaling changed from 1.2x to 1.4x." Pages that know a specific thing the rest of the internet doesn't tend to survive the updates that flatten the rephrasing farms.

Second, I make authorship obvious. Bylines on every page. A real about page. A consistent voice across the site. If a reader lands and asks "who wrote this and why should I trust them" and the answer is unclear, AI Overviews won't cite me and Google will eventually stop showing me. This is newer — it wasn't a ranking factor four years ago, and now it very much is.

Third, I cut ruthlessly. I used to publish everything that could theoretically rank. Now I unpublish more than I publish. If a page isn't in the top ten for anything after six months, I either rewrite it until it deserves to be, or I delete it. My sites are smaller than they used to be and they earn more.

The part where I eat crow

I've had other pSEO sites get hit in the last two years. It's not a hypothetical. Every time, the common thread was the same: I was pushing the definition of "useful" a little further than it wanted to go. I was making pages that were technically correct, technically answering a question, but that I couldn't have written with a straight face by hand.

When I failed the proud-by-hand test and shipped anyway, Google eventually caught up. Every time. No exceptions.

That test is honestly annoying to live by, because it caps your output. You can't ship 50k pages if you'd only have been proud of 5k of them. But the 5k will still be earning in three years, and the 50k won't.

The bigger point, if you're deciding what to work on

Programmatic SEO as a free-money glitch is finished. Nobody's going to 5x a site by spinning up 100k template pages anymore, and if anyone's telling you otherwise they're selling you a course.

Programmatic SEO as a legitimate way to structure a content site around a specific problem domain is alive, growing, and maybe more valuable than it's ever been. The glitchy version got cleared out of the SERPs, which means there's more oxygen for the real version.

I'm still using it. I'll still be using it in 2027. I just apply the proud-by-hand test to every page before it ships now, and the 300k-to-14k afternoon hasn't repeated.

Running twenty sites solo

chris@doanythingai.com (Chris) — Thu, 16 Apr 2026 00:00:00 GMT

A friend came over last week and watched me close my laptop at 5pm. He said "wait, that's it? You run twenty sites." It sounded like an accusation.

I get asked this at least once a month. How do you maintain twenty sites by yourself? The honest answer is that I don't, really. Most of them don't need maintaining. Which is what I want to tell you about, because the part that makes that possible is a rule I wish someone had drilled into me five years ago.

The rule that made everything else possible

If a project needs me to check on it weekly, it's a bad project.

That's it. That's the whole rule. Every time I find myself in a Monday routine of "let me go make sure X is still working" — whether it's a dashboard I built, a content pipeline I wrote, a dependency I'm nervous about — the project is failing. Not slowly. Failing.

The options at that point are three, and only three: automate what I keep checking, rebuild the thing until it doesn't need checking, or kill it.

Two years ago I had a site that scraped a gaming leaderboard and republished it with commentary. Decent traffic, a few hundred bucks a month. I was checking it every Monday because the source site kept changing their HTML. Every few weeks something would break and I'd spend an afternoon chasing it. I finally added up the hours and the revenue and realised I was earning $4 an hour on this thing when you count the babysitting. Killed it the next day. Haven't missed it once.

The ones I didn't kill — the twenty I still run — all pass this test. They sit there quietly. I can leave them alone for a month, and they'll be fine a month later.

What "sits there quietly" actually means

Boring is the whole trick. Every new project I start now, I ask: can this be boring?

Static pages wherever possible. No user accounts unless the product literally cannot exist without them (turns out, usually it can). No cron jobs I can't explain in one sentence. No third-party integrations that can fail silently. When a dependency upgrades, I want to know within seconds if the site broke, not three weeks later when someone emails.

The corollary is: I build almost nothing in isolation anymore. Every site I ship uses the same bones. Astro for the pages, Cloudflare for hosting and DNS, Markdown or a JSON file for content, Postgres if I need persistence. That's it. Four pieces. If a new project doesn't fit this stack, I'll often just not build it, because the long-term cost of a bespoke stack is higher than the short-term win of the feature.

Standardising was the biggest single productivity change I've made as a solo operator. When every project has the same bones, the bones stop costing me cycles.

The monitoring I actually have

You would assume, running twenty sites, I'd have an elaborate observability setup. Grafana dashboards, alert channels, a PagerDuty rotation of one.

I don't. I have UptimeRobot hitting the important URLs every five minutes, and that's the whole monitoring stack. If something breaks badly enough to matter, it'll show up in revenue or traffic within a day, and I'll see it. If it's too subtle to show up that way, it's also too subtle to be worth waking up for.

Real engineers hate this. That's fine. The ops practice that would be correct at a company of fifty people is comic overkill for a company of one. I'd rather spend the hours I'm not spending on dashboards on writing the next thing.

What actually eats my time

Maintenance doesn't. The two things that eat my week are:

Deciding what to build next. This is harder than it sounds when you already have twenty things you could be pushing on. I wrote more about this in another post.

And then actually building it. Shipping the next project, or the next big feature for one of the flagship sites.

I probably spend 15% of a typical week keeping old stuff alive, 20% on the blog and the consulting, and the rest on whatever the next thing is. If that ratio tips the other way for more than a few weeks, one of the old projects has started failing the weekly-check rule, and I need to fix it or kill it. There's no middle ground.

The takeaway, if you're managing more than one thing

Apply the weekly-check test to every project you run. Be honest about which ones demand regular attention. Then fix them until they don't, or let them go. You can run a portfolio ten times the size of mine if none of the individual items are loud, and you can run zero sites if even one of them is loud enough to take over your week.

Twenty quiet sites beat three loud ones, every time. The hard part is being willing to kill the loud ones when they stop being worth the noise.

Pricing a one-hour consult

chris@doanythingai.com (Chris) — Wed, 15 Apr 2026 00:00:00 GMT

A guy named Jake emailed me last month asking how I priced my consult. I wrote him back a long reply, realised halfway through I'd never actually written this down anywhere, and here we are.

I sell one-hour consults and nothing else. One call, one invoice, done. No discovery call, no retainer, no "let me send over a statement of work." The price on the page is the price.

People want to know how I landed on the number. Here's the useful part, and then the part nobody tells you.

The morning-after test

Here's the trick that did more than anything to get my pricing right.

Whatever you're charging, imagine you just hung up on a consult. It went fine. Client was friendly, you helped, nobody's unhappy. It's 9am the next day. You're making coffee. How do you feel?

If you feel fine, you're priced about right. If you feel like you'd rather have been shipping your own thing, your price is too low. Not because you're greedy. Because the money has to cover both the hour you spent and the hour you didn't spend on your own work. Opportunity cost is real, and it shows up in your gut before it shows up on a spreadsheet.

I moved my price three times on this test alone. Each time it was because a few mornings in a row the answer was "I would rather have shipped." The number went from $500 to $750 to what it is now, and demand didn't change once. The only thing that changed was how I felt on Tuesday mornings.

Better than a market survey. Better than asking friends. Better than a conversion rate. Your gut updates faster than any of that.

Why I stopped letting the price climb

There's a ceiling too, and I hit it by accident.

Past a certain point, people who booked started expecting a deliverable. They'd ask for a memo, a follow-up, a Slack thread. Anything tangible to justify what they'd paid. That's a different product. That's a mini-consulting engagement, not a consult. Different margins, different headaches, different version of me to run it.

I didn't want that business. So now the ceiling is "the highest I can charge without the client quietly expecting more than sixty minutes of talking." Below that, they're buying my time and leaving happy. Above it, they're buying an outcome I never promised, and we're going to end up in an awkward email thread.

Know there's a ceiling. Don't blow past it by accident.

The part nobody writes about

The price isn't the hard part. Holding the scope is.

Every person who books will try — usually without realising it — to turn an hour into three. They'll email follow-up questions the next day. They'll ask you to pre-read a deck. They'll reschedule twice and show up unprepared. They'll DM you a week later with "quick question." If you say yes to any of it, the real hourly rate plummets and you'll start to resent the whole thing.

The fix is being blunt before they ever book. My page literally says: one hour, no follow-ups, no implementation work, no pre-reads. About one in ten prospects reads that and bounces. Those are the ones who'd have caused most of the scope problems. Good filter.

The fraud feeling, and what actually kills it

You will sometimes feel like a fraud for charging money to talk for sixty minutes. This feeling is persistent and it is wrong, but "it's wrong" isn't enough to make it go away.

What worked for me was a little text file I started keeping a year in. Every time a client emailed back later with an outcome, I logged it. One founder shipped a feature she'd been stuck on for four months. Another killed a project that would have cost her $80k to build. One guy pivoted his product's positioning off a single sentence I said near the end of the call.

None of those outcomes were worth an hourly rate. They were worth ten times the hourly rate, at least. Once that file had six or seven entries, the fraud feeling just evaporated. The rate turned into a rounding error on the outcome, and I stopped flinching when people paid.

If you're just starting out and you don't have the file yet, borrow mine: assume the price you're nervous about is already too low, and find out for real by charging it.

If you're sitting on a pricing page tonight

Pick a number that passes the morning-after test. Write the scope in one sentence. Enforce it on the booking page so the scope-creepers self-select out. Then raise the price every six months until someone emails back "that's too high for me" — not as a negotiation, just a real no.

The first real no tells you where the market actually is. Until then, you're guessing. Guess high.

Hello, this is a blog now

chris@doanythingai.com (Chris) — Tue, 14 Apr 2026 00:00:00 GMT

I've been meaning to start a blog for about two years. I kept not doing it because I wasn't sure what I'd write about. Today I decided the answer is "doesn't matter, just start."

So this is the start.

Why I waited so long (and why that was dumb)

The reason I didn't start sooner is the same reason most people don't start their blog: I was waiting to figure out the theme. What's my niche. What's my voice. Who's the audience. What would the first post even be.

Two years of that. Meanwhile, a few people I know who just started writing in 2022 have built whole audiences off posts that were, charitably, nothing posts. The first post on almost every writing career I respect is forgettable. The reason the rest of the career exists is that the person kept going.

So: if you've been waiting for clarity before you start the thing you want to start, stop. The clarity comes from doing it for six months, not from sitting and thinking about it.

What I'll probably write about

Short notes, mostly. Stuff I figure out while building. Things I'd normally tweet but want to keep in one place where I actually own the URL. Occasional longer writeups when something's worth it.

A few recurring topics: whatever I'm shipping that week, LLM-specific weirdness I run into, programmatic SEO (because it's what pays for half the portfolio), and short posts about running a one-person studio.

What I'm not going to write

Listicles. "10 Ways AI Will Change X." Anything a content farm could write. Posts where I don't have an opinion. If I find myself writing a summary of other people's ideas without adding anything, I'll kill the draft.

How often

Roughly daily for a while. I have a backlog. That pace will drop once I'm caught up. Quality over schedule, always, but right now there's a backlog so schedule wins for a few weeks.

That's the setup. More soon.