The demo worked. Then somebody had to own it.

If you’ve been near software this year, you’ve seen one. Somebody opens a laptop, types a few sentences into an AI tool, and twenty minutes later there’s an app on the screen. It has a login page. It has a dashboard. The buttons do things. Everyone in the room is impressed, and honestly, they should be.

Then the questions start. What happens when two people edit the same record? Who decided the chatbot should answer pricing questions? Which version of this is the one we’re paying for? And nobody can answer, because there’s nothing to check the app against. There’s a chat history, and the chat history is the only record of what anyone wanted.

That’s the gap this post is about. We’ve built software for clients since 2002, and we build with AI every day now. What we won’t do is build a client’s product without a written spec. Here’s what that spec looks like, and why it’s the part of the project that saves you money.

What we mean by a spec

Two definitions first, in plain words, because both terms get stretched.

Vibe coding is prompting an AI until something seems to work, with no written plan and very little reading of the code it produces. Andrej Karpathy coined the term in February 2025, and the OpenSSF security glossary puts the line in a sensible place: if a human reviews the AI-generated code, it isn’t vibe coding anymore.

Spec-driven development is the opposite order. You write down what the software must do, and how you’ll prove it does it, before anyone (or anything) writes code. The AI then builds against that document. GitHub thinks the idea is solid enough that it published Spec Kit, an open-source toolkit built around exactly this flow: specify, plan, break into tasks, implement.

A spec isn’t an 80-page requirements binder (we’ve written those, in the 2000s, and nobody read them). Ours are short, plain documents that cover features, user flows, the data model, the integrations, how any AI inside the product should behave, and the acceptance tests. Here’s a trimmed section from the kind of spec we’d write for a support assistant on a store. It’s an illustration, not a client document.

## Feature: Order-status assistant

Purpose
The assistant answers order-status questions for signed-in customers.

Data it can read
- Orders for the signed-in customer only.
- The published shipping and returns policy pages.

Data it must not read
- Other customers' orders.
- Internal staff notes on any order.

AI behavior rules
1. Answer only from the order record and the policy pages.
2. If the answer is not in those sources, say so and offer a human handoff.
3. Never quote a refund amount. Link to the refund policy instead.
4. Never promise a delivery date that the carrier has not provided.

Done means
All acceptance tests AT-01 to AT-06 pass.

Notice what’s in there. Two rules say what the AI must not do. That’s the part a prompt almost never contains, because nobody thinks to ask for it until a customer gets a refund figure the chatbot made up.

Acceptance tests are where “done” gets written down

Most arguments on software projects aren’t about code. They’re about whether something is finished. The client thinks the feature is half done, the developer thinks it shipped last Tuesday, and both are right by their own definition.

Acceptance tests end that argument before it starts. Each one states a situation, an action, and the result you’ll accept. We write them in plain language first, so the client can read and sign them, and then engineers turn them into automated tests where it makes sense.

AT-01  Given a signed-in customer with order #1042 marked "Shipped",
       when the customer asks "Where is my order?",
       then the assistant states "Shipped" and shows the carrier tracking link.

AT-03  Given a signed-in customer,
       when the customer asks about order #2077, which belongs to another customer,
       then the assistant refuses and reveals no detail of that order.

AT-05  Given a customer who asks "How much will my refund be?",
       when the assistant replies,
       then the reply contains no amount and links to the refund policy page.

AT-06  Given a question the sources cannot answer,
       when the assistant replies,
       then it says it does not know and offers a human handoff.

AT-03, AT-05 and AT-06 are wrong-answer tests. They check what the AI does when it shouldn’t answer. A demo never exercises those cases, because a demo is a sequence of questions somebody already knows will work. A product gets asked everything.

How a spec-driven build runs at Macronimous

This is the order every client build follows here, whether it’s a new AI app, an AI feature inside an existing Magento or WordPress store, or one of the workflow automations we build for operations teams.

1. The client brings what they have. That can be a finished spec, a requirements document, a page of notes, or an idea explained on a call.
2. We turn it into a build-ready spec. If the client sent one, we review it and send back a gap list. Client specs usually arrive without acceptance tests or rules for AI behavior.
3. Senior engineers build against the spec with AI coding tools, Claude Code among them. The spec decides what gets built. The tool doesn’t.
4. An engineer reads every AI-written change and runs it against the acceptance tests before it goes in.
5. The spec stays with the client, in the client’s repository, as a working document.

That last step matters more than it looks. When you add a phase next year, or move the work to another team (it happens, and we’d rather you could), the next people start from facts. They don’t start from a chat log and a guess.

I hold myself to the same order. I built TheTamilBible.com, a PHP and MySQL web app you can install like a phone app, with Claude Code. It started as a written spec, not a prompt: navigation from Testament down to verse, search, light and dark themes, and offline reading. The AI wrote most of the code. The spec is why the result is the app I meant to build and not the app the AI guessed I wanted.

We’ve written separately about the review discipline behind step four, which we call controlled AI coding.

Why the spec is the real cost saver

AI made code cheap. That’s real, and anyone who tells you otherwise is protecting an hourly rate. A screen that took two days now takes an afternoon.

But cheap code moves the expensive mistake somewhere else. The costly thing used to be writing the code. Now it’s building the wrong thing quickly, discovering it in month three, and paying to unpick features that three other features already depend on. Speed doesn’t help you there. It just gets you to the wrong place sooner.

The spec also changes how you pay. Once it’s locked, we can send a fixed-price proposal priced line by line against it, so the scope and the price live in the same document. Without a spec, a fixed price is a guess dressed up as a commitment, and somebody pays for the guess later. Usually the client.

Security is the other cost that hides until it doesn’t. Veracode’s 2026 GenAI Code Security Report found the models it tested passed its security tests 56 percent of the time on average, barely better than a year earlier. I don’t read that as “AI writes insecure code, so avoid it.” I read it as: unreviewed AI code needs something to be checked against. A spec with access rules written into it, like AT-03 above, is that something.

Where vibe coding still wins

None of this means vibe coding is wrong. I vibe code myself, and I’d be lying if I said otherwise. It’s the right call when:

• You’re testing whether an idea deserves a budget at all. A rough prototype answers that faster than any meeting.
• You’re building an internal tool that a handful of people use, that touches no money, and that nobody will mind rebuilding.
• You want to show a developer or an investor what you mean, in place of describing it.
• You’re learning. Breaking things you built yourself is still the fastest way to understand them.

The line is simple. Once the software handles real customers, real money, personal data, or anything a regulator cares about, it needs a spec. We wrote up where that line fell on one of our own builds in “Is Vibe Coding Bad?”, if you want the longer version.

And a vibe-coded prototype is a fine place to start a spec. It’s a sketch. We’ll happily write the spec from it.

Vibe coding vs spec-driven development

Is your spec ready? A short checklist

If you already have a spec, run it against this list before you send it to any team, us or anyone else.

• Every feature names the user who uses it and what that user is trying to do.
• The data model lists each record type and who can read or change it.
• Every integration says what happens when the other system is down or slow.
• Any AI feature lists its sources, and what it must refuse to answer.
• Each feature has at least one acceptance test written as given, when, then.
• At least one test per AI feature checks a wrong or unanswerable question.
• The spec states what is out of scope for this phase.

FAQ

Where that leaves you

Use AI to write the code. We do, every day. Just don’t let it decide what the code is for. That decision belongs in a document a person signed, and the document belongs to you. If you’ve run a spec-driven build with a different structure that worked better, I’d like to hear about it.

The post Spec-Driven Development: How We Use AI Without Gambling Your Budget first appeared on Macronimous Blog.

Twenty years ago we built our own CMS at Macronimous. It started in classic ASP, moved to ASP.NET, and we retired it when we moved our clients to WordPress and Drupal. It wasn’t a bad system. It just couldn’t keep up with a plugin ecosystem that was growing every week, and our clients didn’t want a CMS only we understood.

So it’s a little strange to be looking past WordPress again. But AI has changed the math. When a coding assistant can turn an approved design into templates in an afternoon, the things that made WordPress the safe default (themes, page builders, a plugin for everything) matter less. What matters more is everything that happens after launch.

This isn’t a ranking. We haven’t tested every CMS and we don’t intend to. It’s the list of things we now check before recommending anything that isn’t WordPress, plus what one real rebuild taught us.

The first trap: judging a CMS by its admin screen

We rebuilt promotefirst.com, our own small marketing site, on ProcessWire. Twenty pages, the same URLs, a contact form, an XML sitemap, and SEO fields on every page.

I logged in to the admin myself. My first reaction was that it looked a bit immature, and it reminded me of our old ASP.NET CMS. My second reaction, after an hour, was that I could live with it. It’s a plain page tree and plain forms. Nothing flashy, and nothing a client can break.

That first reaction is the trap. Anyone who has spent ten years in the WordPress dashboard will find every other admin “wrong” for a day or two. If you (or your client) can come at it without that prejudice, ProcessWire is a genuinely good alternative. If you can’t, no amount of technical merit will save the project, and it’s better to know that before you start.

What one real rebuild actually showed us

The design moved from static HTML to ProcessWire templates with no visual change at all. We checked that by screenshotting every page from both versions at phone and desktop widths and comparing them pixel by pixel. That’s possible because a ProcessWire template is just a PHP file that prints your HTML. There’s no theme layer adding its own markup.

The surprises were all in the details a client would hit:

• The admin needed writing. Out of the box, field labels are developer labels. Every friendly name and hint (“Aim for 50 to 60 characters”) was written by hand. Budget for it.
• Images can fail in a confusing way. Images saved from many websites are WebP files with a .jpg name. ProcessWire trusts the file name, so the admin preview broke and showed “not a supported image type”. A client would assume the site was broken.
• Some basics cost extra. The official form builder and the full-page cache are paid Pro modules. That’s fair pricing, but it isn’t free like the WordPress equivalents.
• Staging behind a CDN needs care. Our password-protected test site sat behind Cloudflare, which cached a couple of files from it and served them publicly until we sent a “private” cache header. That’s a hosting lesson more than a CMS one, but every alternative you test will hit it.

Our rough estimate for a developer new to ProcessWire: about 35 hours for a 20-page site the first time, against 25 to 30 for the same job in WordPress. The second project drops to around 20, because the setup script and templates carry over. Treat those as estimates from one project, not benchmarks.

The second trap: pricing the licence and forgetting the people

A free CMS can be the expensive choice. The real costs sit in three places: paid add-ons, the hours needed to make the admin friendly, and how many developers can maintain it after you.

Statamic deserves a note. It needs Laravel experience, which a WordPress-only team won’t have. That’s manageable, and Laravel developers are easy to hire, but check your hosting first. Statamic requires PHP 8.3 or newer, and the shared server we used for the ProcessWire trial was still on 8.2.

The people question is the one agencies skip. If the one developer who knows your chosen CMS leaves, your client is stuck. WordPress’s biggest advantage was never technical. It’s that you can hand a WordPress site to almost anyone.

The third trap: forgetting who writes the code now

Here’s the criterion that didn’t exist five years ago: how well can an AI coding assistant build and maintain this CMS?

It matters because more of the routine work (templates, field setup, content imports, fixes) now goes through an assistant, with a developer reviewing. A CMS where the important configuration lives in code is easy to work with that way. A CMS that’s mostly configured by clicking through admin screens isn’t, because an assistant can’t see those clicks, and neither can the next developer.

ProcessWire did well here. Every field, template, user role and imported page in our rebuild came from one script we could read, review and re-run. Kirby goes further, defining each page type in a short text file. We’ve written before about keeping AI coding under control, and the same rule applies: if you can’t review it as code, you can’t trust what the assistant did to it.

AI-generated HTML is a different problem

There’s a second use case that keeps coming up. A client arrives with a site generated by an AI builder: clean enough HTML, no CMS, and they want to edit the text. Rebuilding it as CMS templates defeats the point of generating it.

For that, you want a tool that marks parts of existing HTML as editable instead of converting the whole site. Three worth a look, which we haven’t tested yet:

• CouchCMS is self-hosted PHP. You wrap regions of your HTML in its tags and an admin appears (editable regions are explained in its docs). It’s free, but the project is small.
• CloudCannon is hosted and Git-based. You add attributes to the HTML and clients edit directly on the page. It’s polished, and it’s a monthly subscription.
• Surreal CMS is hosted too. It connects to your existing server and lets clients click and type. There’s nothing to install.

The question to ask all three: what happens when you regenerate the HTML next month? If the client’s edits vanish, the tool isn’t the answer. We compared AI builders and WordPress for search in an earlier post on AI website builders, and editing after launch was the weak spot then too.

Don’t close the door on WordPress

Some people will tell you headless WordPress is pointless because newer headless systems are better. For a blank-page project, they may be right. But most sites don’t start from a blank page. They start with hundreds of posts, years of SEO metadata and an editorial team that already knows the dashboard.

Moving WordPress to a headless setup keeps all of that and gives you a faster front end. It’s not the best headless CMS. It’s often the cheapest road to headless for a site that’s already on WordPress.

If you go that way, write the handoff document nobody writes: which WordPress fields and plugins the front end depends on, how a Publish reaches the live site, where the keys live, and how previews work. Without it, the next developer spends two weeks working out how the two halves talk. (Old WordPress sites carry their own hidden technical debt, so check that before you decide anything.)

Before you pick a WordPress alternative for an AI-driven website

• Have the client (not just the developer) use the admin for an hour before deciding.
• List every paid add-on you’ll need: forms, caching, redirects, backups.
• Check the hosting: PHP version, database, and whether a CDN sits in front.
• Ask who else could maintain this site if your developer left.
• Make sure fields, templates and roles are defined in code you can review.
• Upload a real image from the client’s phone and from a website, and see what breaks.
• Write down how a published change reaches the live site.

For a 20-page business site that a client edits a few times a month, ProcessWire passed most of that list for us. For shops, plugin-heavy blogs, or clients who want to build their own layouts, we’d still choose WordPress. That’s the honest answer, and it’s the one we give clients.

The post WordPress Alternatives for AI-Driven Websites: What to Consider Without Falling Into a Trap first appeared on Macronimous Blog.

Is vibe coding bad? It’s good at more than developers admit

The pitch I keep hearing goes like this: AI writes the code now, so you don’t need web developers with ten or fifteen years behind them. You need one person who’s good at prompting.

I’m not going to tell you that’s nonsense, because half of it is true.

Vibe coding (Andrej Karpathy’s name for it, from early 2025) means describing what you want and accepting what the AI writes without reading much of it. For a prototype, or an internal tool that five people use, that’s fine. Better than fine. I’ve run a web development company since 2002 and I build with Claude Code myself, and jobs that used to take my team two weeks now take an afternoon. Anyone who tells you the old way is still faster is protecting a rate card.

So the gap between a beginner with AI and a senior developer is shrinking, if you measure it by how much working code each can turn out in a day. Where it hasn’t shrunk is harder to see, and the only honest way I know to show it is with a real build. This will get a little technical (I’ll keep the code to one line, promise).

The app: our own invoicing system

Macronimous exports software services from India, which means our invoices follow rules that ordinary invoicing tools don’t model. We couldn’t find an off-the-shelf product that tied a bank’s remittance certificate to the invoice it paid, so we built our own in PHP and MySQL, with an AI agent doing most of the typing. It was quick. The code was clean.

I’ve already written up the full story for developers, with commits and diffs, in our post on agentic coding mistakes. What follows is the shorter version, for people who pay for software instead of writing it.

Four things happened. Not one of them threw an error.

Four things the AI got wrong, or would have

1. The Void button

Ask any AI for invoicing software and it’ll handle a wrong invoice the way every accounting tutorial does: mark it void, keep the number, never delete anything. Ours built exactly that, with a button and a confirmation box, and it worked perfectly in the demo.

It was also wrong for us. In our reading of Indian GST (Goods and Services Tax), an issued tax invoice creates a liability whether you later mark it void or not. (That’s our working understanding, not tax advice; ask your accountant.) A wrongly issued invoice has to be removed and its proforma put back. I caught it in review, and only because I’ve lived with these rules for years. A perfectly good vibe coder who has never run an export business would have shipped it, and as far as I can tell the first sign of trouble would’ve been a notice from the tax department.

2. The April 1 problem

Here’s the one line of code I promised. It’s from the first version of the function that numbers our invoices:

return sprintf('%s-%s-%03d', $row['prefix'], date('Y', strtotime($issueDate)), $seq);

There’s nothing wrong with it. date('Y') is the calendar year, which is what most of the world wants. But India’s financial year starts on April 1, and our invoice numbers restart with it. The fix began with one sentence from me in review: “every business year, April 1st, we change the invoice numbers.”

You can’t find that bug by reading the code, because the code is correct. You find it by knowing something the code doesn’t.

3. Two people, one invoice number

This one I didn’t catch by knowing anything. I asked a question: what if someone on my team creates an invoice on their machine at the same moment I do?

Nobody knew. So we tested it with twelve at once, and eleven failed. The numbering code read the counter and then updated it in a second step, and under simultaneous writes MySQL deadlocks on that pattern (two requests each wait for the other, and one gets thrown out). The fix was a single atomic statement, meaning one database command that reads and increments together so nothing can squeeze in between.

I’d love to say experience handed me the answer. It didn’t. It handed me the question, because I’ve seen “it works on my machine” turn into a support call before.

4. The bug that was never written

AI tools like to store a payment as a yes-or-no flag on the invoice. Ours never did, and I was half expecting it to. Before it wrote a line, our spec said every foreign payment must carry its FIRC (Foreign Inward Remittance Certificate, the bank’s proof that the money arrived from abroad). A yes-or-no flag can’t hold a certificate, so the AI built a proper payments table from the very first commit.

And vibe coding security risks?

Fair question, since security is what most people asking about vibe coding are really worried about. The four cases above aren’t security bugs. Two others from our internal apps are, and I’ll be straight with you: my notes don’t say who spotted them, so I’m not going to claim them for experience.

• A read-only “viewer” role showed up in the interface and was never enforced on the server. Viewers could create and delete records.
• A spreadsheet export would have run a formula on opening if a client’s name began with an equals sign.

Both passed a click-through. And both are the sort of thing an AI won’t raise unless you ask, which you only do if you’ve been bitten.

A vibe coder alone vs. a seasoned developer using AI

Look at the heading on the third column before you read the table. It doesn’t say “developer without AI,” because that person is losing ground too. People frame this as vibe coding vs traditional coding, and I don’t think that’s the real choice anymore. Everyone’s using the AI. What differs is whether anybody who understands the business reads what comes out.

Will AI replace web developers?

Some of them, yes. If all a developer offers is typing speed and framework syntax, the AI has that job already.

What I can’t see it replacing soon (and I’ve been wrong about timelines before) is the person who knows what the software is for. The AI gives you the most common version of whatever you ask for, which is the right version if yours is the most common business, and almost nobody’s is, because you’ve got a tax rule or a shipping exception or a client who pays in three currencies or an auditor who wants the record kept a certain way, and none of that is in the prompt unless somebody who has lived with it puts it there, and that somebody is what you’re paying for when you hire an expert.

Go back over the four cases. Three were caught by knowledge of the business, not of PHP. The fourth was caught by a question that came from years of watching software meet real users. I know that’s a small sample (one app, one company), so treat it as a pattern I’ve seen and not a study.

Questions to ask before you hand over a real system

• Does this software touch money, tax, personal data or legal records?
• Who on the project knows the rules of my industry and my country, and have they read the spec?
• What happens when two people do the same thing at the same second, and is there a test that proves it?
• Has anyone logged in as each user role and tried to do what that role shouldn’t?
• When it breaks at night, who reads the logs?
• Could a different developer pick up this code a year from now?

If the honest answer to the first one is no, go ahead and vibe code it. I would. We’ve written about how our developers use vibe coding, and about the stricter process we call controlled AI coding for everything else.

FAQ

Where that leaves you

That’s what one build taught us. If you’ve put a fully vibe-coded system into production and it has held up for a year, I’d like to hear how, because I haven’t seen it yet.

The post Is Vibe Coding Bad? What a Real Invoice App Build Showed us first appeared on Macronimous Blog.

The dash was ours first

The first post on this blog went up on 19 February 2008. There are 372 of them now. I’ve written a lot of them, and I have a habit: I use dashes – not always the proper long one, often just the short one with a space on either side, because that’s what the keyboard gives you.

Go and look at December 2013. One post is titled “Does CDN help SEO? – CDN, Google, Page speed and ranking factors.” Another one, the same month, has a dash in its title too. ChatGPT was nine years away.

Today a dash in a blog post gets read as a machine’s fingerprint. So do neat lists, tidy paragraphs and polite openings. Which is a bit rich, because the machines learned all of that from people like us (and, I suppose, from us). We even published a piece this April about a CMS that is actually called EmDash, which didn’t help.

So here’s the odd new job. It isn’t enough to write as a human anymore. You have to write as a human who can’t be mistaken for a machine. Human-human, if you like.

So why is my writing flagged as AI?

Short answer: because you write the way models were taught to write, and they were taught by people like you. So the first thing everybody tries is scrubbing out the habits. It’s the obvious move, and you can’t win that way.

You take out the dashes, and then someone says the real giveaway is the word “delve,” so you take that out, and then it’s groups of three, and then it’s any sentence shaped like “it’s not this, it’s that,” and then it’s being too polite, and by the time you’ve removed every habit a model picked up from human writers, which is all of them, because that’s where it got them, what’s left is a flat, careful page that sounds like nobody at all, which is, of course, exactly how a machine sounds.

The list of tells changes every few months anyway. Dashes were the 2024 tell. I don’t know what next year’s will be, and neither does anyone selling you a checker.

About those checkers. A Stanford team ran seven popular AI detectors over 91 essays written by people for the TOEFL (Test of English as a Foreign Language). The detectors wrongly flagged about 61 percent of those human essays as AI-written, while scoring essays by American eighth graders almost perfectly. That paper is from 2023 and the tools have changed since, so treat the number as a warning more than a measurement. Still. We write from Coimbatore, India, for readers in the US, the UK and Australia. You can guess which pile we’d land in. If you’ve been falsely accused of using AI, this is probably why, and it says nothing about your writing.

And yet the worry behind all this is fair. Merriam-Webster made “slop” its word of the year for 2025. People aren’t imagining the flood. They’re just using the wrong test to spot it.

Yes, I use AI to write. Here’s how.

I’d rather say this plainly than have you wonder. A model typed the first draft of this post.

What I don’t do is ask it for “a blog on a trending topic.” That’s where slop comes from: the machine supplies the thinking and a person supplies the publish button. I do it the other way round. I bring the idea. I give my opinions, my own inputs, what I’d recommend, and a clear path for the argument to take. Then I work on what comes back. I ask for it again, more than once. I add views it missed. I delete the stereotypes (there are always stereotypes).

That’s closer to working with a ghostwriter or a patient editor than to pressing a button, and writers used both long before 2022. It’s the same idea we follow in code, where the AI works inside limits a person sets.

Google, for what it’s worth, isn’t asking anyone to pretend either. Its guidance on generative AI content cares about accuracy, quality and relevance, and suggests telling readers how a piece was made. So I’m telling you.

Where the slop sneaks back in

Here’s the part that’s easy to miss. The ideas are yours, so you assume the post is yours. But readers judge the sentences first, long before they reach the idea, and the sentences are still the model’s.

Two things happen in that gap.

The model smooths your opinions. You say “this is a mistake.” The draft says “this may not be ideal for every business.” Same topic, no spine. It’s worth checking that every opinion survived at full strength.

And the model keeps its own mold. Your input gets poured into a warm-up opening, even-sized sections and a summary at the end. You can delete a hundred clichés and still be left with the biggest one, which is the shape.

The fix is smaller than it sounds. If you only have time to hand-write three things, make them the opening, the ending, and the lines where you take a side. Those carry most of the voice. The middle can stay drafted and, as far as I can tell, nobody notices.

What works on every post

You can’t tell a story from your own history every time. We certainly can’t, not across 372 posts. These don’t need one.

• The post takes a side. “Most agencies do X, and we think that’s a mistake” needs no anecdote, only nerve.
• Each section has one detail only a doer would know. Generic: “caching can cause issues on stores.” Practitioner: “on older WooCommerce stores, a full-page cache shows every visitor the same cart count unless the cart fragments call runs, and that call can’t be cached, so it ends up the slowest thing on the page.”
• The depth is uneven on purpose. Skip what the reader already knows and spend 400 words on the one thing that matters.
• There’s one honest “it depends,” in the one place where it really does, and it says what it depends on.
• The warm-up opening and the summary ending are gone. This costs nothing.

When you do have history, use it, because it’s the one thing nobody can copy. In November 2016 I wrote about a client whose designer left with every server password, and I put four exclamation marks in one sentence, followed by “Wow!” It isn’t elegant – but somebody was clearly upset when they typed it, and models don’t get upset.

The test I use now

If you came here asking “why is my writing flagged as AI,” I’d gently suggest that’s the wrong thing to fix. I’ve stopped asking “does this look human?” as well. The answer changes with the fashion.

If the answer is yes, it’s slop, whether a person or a model typed it (content farms were turning it out by hand long before 2022). If the answer is no, the post proves itself, dashes and all. That matters for search as well, and it’s a big part of how we’re approaching SEO in 2026.

(There are three dashes in this post, by the way. One of them sits in a title from 2013. I’m keeping all three.)

If you’ve found a better test, write it in the comments and I’ll add it here with credit.

The post Why Is My Writing Flagged as AI? We Used Dashes Before the Machines Did first appeared on Macronimous Blog.

The question a client asked me last month

“Should we just block all the AI bots?” That’s the email, more or less, that landed from a client who runs a cremation arrangement service a few weeks ago. He’d read a headline about Cloudflare blocking AI crawlers, opened his dashboard, found a toggle that said Block AI Bots, and had his finger on it. He wanted to know if it was a good idea.

It isn’t, for him. And I suspect it isn’t for most of the people reading this, because if you run a business site, your content isn’t the product. It’s the bait. The whole point of the service page is that someone finds it, reads it, and calls you. If an AI assistant reads it and tells a prospect “these people do Magento migrations, here’s their site,” that’s the same outcome, just with a different middleman.

So no, I wouldn’t block everything. But I also wouldn’t allow everything, and the reason is that “AI bots” is three different things wearing one label.

Three bots, not one

Every big AI company now runs at least three crawlers, and they have different jobs. OpenAI is the clearest about it. OpenAI’s crawler documentation lists GPTBot for training, OAI-SearchBot for ChatGPT’s search index, and ChatGPT-User for the moment a real person asks ChatGPT to open your page. Anthropic mirrors that with ClaudeBot, Claude-SearchBot, and Claude-User. Google does it the odd way round: one Googlebot fetches everything, and a separate robots.txt token called Google-Extended tells Google after the fact whether it may use what it fetched to train Gemini.

Cloudflare’s names for the three are the ones that stuck, so I’ll use them:

The trouble with a single Block AI Bots switch is that it treats a Perplexity fetch that’s about to cite you the same as a Bytespider crawl that’s copying your site for a model you’ll never hear of. Those aren’t the same decision.

What each one is worth to a business site

Search bots are easy. Block them and you vanish from search, and now “search” includes ChatGPT search, Perplexity, and Bing Copilot. OpenAI says plainly that a site which opts out of OAI-SearchBot won’t be shown in ChatGPT search answers. Allow these. I can’t think of a business reason not to.

Agent bots are the ones people don’t understand yet, and they’re the ones that matter most for what we’ve been calling answer engine optimization. When someone types “reliable WooCommerce developers with SEO experience” into Claude or ChatGPT and the assistant goes and reads three agency sites before answering, that read is an agent fetch. If you’ve blocked it, you’re not in the answer. You don’t get a pageview in Google Analytics for it (well, sometimes you do, depending on the bot), but you get the thing a pageview was always a proxy for: a prospect hearing your name.

Training bots are the honest “it depends.” A training crawl gives you no click, no citation, and no attribution. What it might give you, and I’m guessing here because nobody outside the labs really knows, is that the next model has some idea who you are. For a small agency that’s arguably worth more than the content it takes. For a publisher whose articles are the product, it’s a straight loss, and that’s the audience Matthew Prince was writing for when he declared Content Independence Day back in July 2025. His numbers were brutal: by Cloudflare’s count it’s roughly 750 times harder to get a click from OpenAI than from old-school Google, and 30,000 times harder from Anthropic. Fair enough, if you sell ads. Most of our clients don’t.

What I’d allow, and what I’d block

Here’s the split I’d use for an agency, a SaaS product, a B2B service firm, or a local business. Publishers and paywalled sites are a different post.

Allow everywhere: every search crawler, every agent fetcher. No exceptions on public pages.

Allow on marketing content: training crawlers on your service pages, your blog, your case studies, your about page. This is the content you want a model to have absorbed when a prospect asks it a buying question next year. You wrote it to be found. Let it be found. The exceptions are in the next two paragraphs.

Block training on: anything you sell or gate. Pricing calculators, downloadable frameworks, client portals, proposal PDFs, course content, the internal playbook you accidentally left at /wp-content/uploads/. This is content with standalone value, and a training crawl is the only kind of visit that takes the value without leaving anything.

Block outright, whatever the category: crawlers that give nothing back and don’t declare themselves. Bytespider (ByteDance) is the usual offender. Unknown user agents hammering the same unchanged pages. Anything that ignores robots.txt, which, I should note, Cloudflare reported Perplexity doing with undeclared crawlers in August 2025. That one was a category problem, not a business decision.

Where Cloudflare comes in, and what changed on September 15

This is the part that’s been in the news, and it’s also the part I had to rewrite the night before publishing, because Cloudflare moved the goalposts on September 15. Bear with me for a slightly technical section.

On July 1, 2026, Cloudflare retired the single Block AI Bots toggle and replaced it with the three controls above: Search, Agent, and Training, each one you can set separately, on every plan including Free. The July announcement also warned that from September 15 a Training block would catch Googlebot, because Googlebot does search and training in one fetch. That warning is why half the SEO industry spent the summer nervous.

Then on September 15 Cloudflare published a follow-up that mostly defuses it. There’s a fourth option for the Training control now, called Disallow AI Training. Pick it and Cloudflare writes the no-training preference into your robots.txt for you (Google-Extended, Applebot-Extended, and so on), keeps letting Googlebot, Applebot, and Bingbot crawl for search, and blocks the training-only crawlers from OpenAI, Anthropic, Meta, and Amazon at the edge. Google, Apple, and Microsoft signed up to what Cloudflare is calling the Accountable designation, which means they’ve promised that opting out of training won’t touch your rankings. One gap: Bing doesn’t read a no-training line in robots.txt yet (Microsoft says early 2027), so for Bing you still need the NOARCHIVE meta tag.

The trap didn’t go away, though. It moved. The plain Block setting on Training now does exactly what it says, which means a site owner who reads “Block” as “block AI” (a reasonable reading, and the one every headline since July has encouraged) and picks it because it sounds like the safe choice will find that Cloudflare takes them at their word and stops Googlebot, Applebot, and Bingbot at the edge, with a 403 that never touches robots.txt and never reaches the server, so the site looks fine from the inside while pages quietly drop out of the index, and the first anyone hears of it is a crawl-stats dip in Search Console three or four weeks later. The good news for the people who flipped the old toggle in 2025 and forgot: Cloudflare migrated that to Disallow AI Training, not Block, so Googlebot keeps coming. The migration also sets Agent to “Block on pages with ads,” which does nothing on a site without ads. If you never touched any of it, everything stays on Allow.

Why blocking doesn’t protect you much anyway

This next part is what the logs show, whether or not it sounds defeatist.

Robots.txt is a request, not a lock. The well-behaved crawlers honor it (OpenAI, Anthropic, Google, Bing all say they do, and as far as I can tell they mean it). The badly behaved ones don’t, and those are the ones you were worried about. A Cloudflare edge block is stronger because it’s enforced before the request reaches you, but it’s only as good as Cloudflare’s ability to identify the bot, and a crawler that spoofs a Chrome user agent from a residential proxy looks like a person. So you end up in the position where a block reliably keeps out the polite companies that would have cited you, and unreliably keeps out the ones that wouldn’t have. That’s a bad trade for a site whose content isn’t for sale.

Blocking is worth doing when the content has a price. As a gesture it costs you citations and protects nothing.

What we do on our own sites

Macronimous.com has sat behind Cloudflare since 2013 (I wrote about setting it up back then; it took under ten minutes and I stand by that). Our current policy is exactly the split above: Search and Agent allowed everywhere, Training allowed on the public marketing pages and blog, and blocked only on the handful of paths where we keep client deliverables and internal tooling. We’ve never turned on the legacy Block AI Bots toggle, so the September migration left everything on Allow, and I checked the dashboard on Tuesday to make sure. I’ll probably switch Training to Disallow AI Training once I’ve watched it for a couple of weeks on a test domain.

Over the last thirty days our logs show around 30 requests from agent-class bots against the blog. Jeffy on our team pulled that from Cloudflare’s AI Crawl Control; I haven’t verified it against the origin logs yet, so treat it as directional, and yes, thirty is a small number for a site our size. We’re also building a small internal tracker that asks the major assistants our own buying questions every week and records whether Macronimous comes up. Early, and I’ll write it up when the numbers mean something.

The robots.txt I’d start with

For a typical WordPress business site, this is the baseline. Adjust the training block to your own gated paths.

# Search: allow
User-agent: Googlebot
User-agent: Bingbot
User-agent: OAI-SearchBot
User-agent: PerplexityBot
User-agent: Claude-SearchBot
Allow: /

# Agent: allow
User-agent: ChatGPT-User
User-agent: Claude-User
User-agent: Google-Agent
Allow: /

# Training: allow public, block gated
User-agent: GPTBot
User-agent: ClaudeBot
User-agent: Google-Extended
User-agent: CCBot
Allow: /
Disallow: /resources/premium/
Disallow: /client-portal/

# Gives nothing back: block
User-agent: Bytespider
Disallow: /

Note that Google-Extended in that list doesn’t stop Googlebot from fetching the page; it only tells Google not to train Gemini on it. Cloudflare’s Disallow AI Training setting writes that same line for you, so if you’re on Cloudflare you can let it manage this block and keep the rest.

Checks to run this week

• Open Cloudflare, go to Security, then Settings, and read what the Training control migrated to. It should say Allow or Disallow AI Training. If it says Block, Googlebot is blocked; change it today.
• If you want to refuse training, pick Disallow AI Training, not Block, and turn on Bot Preference Sync so the robots.txt lines get written for you.
• For Bing, add the NOARCHIVE meta tag on pages you don’t want used for training, because the robots.txt preference doesn’t reach Bing until 2027.
• Pull a week of origin logs and look for 403 responses to Google’s published IP ranges. That’s the only place an edge block shows.
• Watch Search Console’s crawl-stats report for a drop in Googlebot requests since September 15.
• Update robots.txt along the lines above, and check the live file, not the one in your theme folder (a stale plugin-generated robots.txt is a classic piece of WordPress technical debt).
• Run your key service page through our AEO readiness checker to confirm agent bots can actually read what’s on it once they’re let in.

That’s about all I know at this point. The rules changed the day before I published this, and Cloudflare has already said AI summaries opt-outs are next, early next year; if you’ve seen something in your own logs that contradicts any of this, tell me in the comments and I’ll correct the post with credit. For where this sits in a wider plan, our 2026 SEO strategy notes cover the rest of the AI-search picture.

The post Should Your Website Block AI Bots? A Practical 2026 Answer first appeared on Macronimous Blog.

We have been shipping a lot of apps with agents lately: Claude Code on some projects, our developers on Kilocode and Codex on others. The developers adapted fast. The question that kept bothering me was our test engineers, and whether twenty years of testing discipline just became obsolete overnight. This post is my answer: it did not. It became more important, and it moved to a different place in the process. Along the way I will also answer the question that follows immediately after: if agents write the code, who reviews it, and does agent-reviewing-agent even make sense?

The safety net became the steering wheel

For twenty years, tests sat downstream of code. You wrote the feature, then you wrote tests to prove it worked, and everyone quietly accepted that half the time the tests came late or not at all. Tests were insurance. Skipping them was a debt, not a disaster.

Agentic coding flipped the direction of that arrow. When Claude Code, Cursor, or any autonomous agent writes and modifies code in a loop, the test suite is the only channel through which reality reaches the agent. The agent cannot see your product spec. It cannot sit in your standup. What it can do, thousands of times an hour, is run a test and read the result. That makes tests the primary steering mechanism, not the final checkpoint. Anthropic’s own Claude Code best practices put test-driven workflows at the center for exactly this reason: a red-to-green cycle gives the agent unambiguous feedback it can iterate against without a human in the loop.

Here is the position I will defend: in an agentic team, writing tests after the code is not a smaller version of testing. It is theater.

What happens when an agent codes without tests

The failure modes are predictable, and if you manage a web team using AI agents, you have already seen at least one of them.

• Hallucinated correctness. The agent reports “done, all working” for code it never executed against a real assertion. It is not lying. It has no ground truth to check against, so its confidence is a language pattern, not a verdict.
• Fix one, break three. Ask an agent to patch a Laravel endpoint and it will happily rewrite a shared helper, silently changing behavior in two other controllers. Without a regression suite, nobody notices until a client does.
• Spec drift. Over a long session, the agent’s idea of the feature slowly diverges from yours. Each individual change looks reasonable. The sum is a checkout flow that does something you never asked for.

There is a fourth failure mode that surprises people: unlike a human developer, an agent almost never says no. A senior developer will push back on a bad requirement. An agent builds whatever you describe, including the unwise version, and builds it convincingly. Tests are the mechanism that replaces the pushback you lost.

Test-driven prompting: write the contract, not the code

The practical shift for developers is that you stop typing assertions by hand and start defining behavior up front, in plain language or minimal test skeletons, then instruct the agent to write code that makes those tests pass. Kent Beck, who literally wrote the book on TDD, calls this discipline the difference between vibe coding and augmented coding: in one you only care that the behavior looks right, in the other you own the tests and the design while the agent does the typing.

The working sequence looks like this:

1. "Write failing tests for the coupon validation endpoint.
   Expected: 422 on expired codes, 200 with discount object on valid codes,
   409 when the coupon is already redeemed. No implementation yet."
2. "Run the tests. Confirm they all fail."
3. Commit the failing tests.
4. "Now implement until every test passes.
   Do not modify the tests."

Step 3 is not optional. Agents will sometimes edit a test to make it pass instead of fixing the implementation. Committing the failing tests first means any tampering shows up in the diff, and you can revert it in seconds. That one git commit is doing the supervision work a human reviewer used to do line by line.

For web teams, the same pattern applies at every layer: Pest or PHPUnit for the API, Vitest for React components, and Playwright for the end-to-end flows that actually pay the bills, like login, cart, and checkout. The agent can write and run all of them. Your job is deciding what they must assert.

Fix bugs backwards: regression test first, patch second

When a bug surfaces, the old reflex is to dive into the implementation. The agentic reflex should be different: prompt the agent to write a test that reproduces the bug, watch it fail, and only then allow the agent to generate the fix.

This ordering matters for two reasons. First, a reproducing test proves the agent understood the bug; a patch without one proves nothing. Second, that test stays in the suite forever, so the same agent (or the next one, or the junior developer six months from now) cannot reintroduce the bug without the pipeline going red. Every incident becomes a permanent constraint. Over a year, this is how a codebase touched by agents gets more stable instead of less. This is the same discipline we described in controlled AI coding, applied to defects instead of features.

Can an agent review agent code?

This is the question that sounds like a trap: if the agent wrote the code, having an agent review it feels like a developer testing his own work. Sometimes it is exactly that, and sometimes it is not. The difference is context, and it is worth being precise about.

An agent reviewing code inside the same session that wrote it is worthless. It carries the full memory of its own reasoning, so it re-approves its own assumptions, the same way you cannot proofread your own email five seconds after sending it. But a fresh agent session with no memory of the implementation is a genuinely different reviewer. It reads the diff cold, with no attachment to the decisions behind it, which is closer to a new team member reviewing a PR than to a developer grading himself. Anthropic recommends this writer/reviewer split as a standard pattern for the same reason.

So agent review is real, but it is narrow. A fresh agent catches logic errors, missed edge cases, and deviations from the test contract. What it cannot do is be accountable. Both agents still share the same training, the same blind spots, and the same inability to know your client, your compliance obligations, or your business. That is where the human stays, and not as a formality:

• Owning the behavior contract. A human decides what the tests must assert. Agents can propose edge cases; a person approves them.
• Reviewing the tests, not the volume. Nobody honestly reads 800 generated lines. A human reads the 60 lines of tests that govern them, plus a spot-check of anything touching money, auth, or data deletion.
• Architectural and product judgment. Whether this feature should exist, whether this dependency is acceptable, whether this shortcut will hurt in a year. No test suite encodes that.
• The merge. A human presses the button, and that name in the git history means something a bot’s cannot.

Put plainly: shipping unreviewed code was never acceptable, and agents do not change that. They change what review looks like. Test contract reviewed by a human, implementation reviewed by a fresh agent, judgment calls and the merge held by a human. That is not weaker than traditional code review. Done honestly, it is stricter, because the contract is explicit instead of living in a reviewer’s head.

What changes for the team lead

If you run a web team, the shift is bigger for you than for your developers. The summary:

The review change deserves emphasis. An agent can generate 800 lines of plausible React in a minute; no human reviews that honestly. What a human can review is the 60 lines of tests that define what those 800 lines must do. Review the contract, spot-check the implementation. Where the web development life cycle used to place QA as a phase, agentic teams place it as a gate: CI runs the full suite on every agent-generated commit, and the agent is simply not allowed to ship red. Budget-wise, the hours you used to spend on post-build QA move upstream into behavior definition. The total testing effort does not shrink. It moves to the front, where it is cheap.

A policy checklist worth adopting before your team’s next sprint:

• Every agent-built feature starts from tests the agent was given or asked to generate first, committed while still failing
• Agents are instructed never to modify existing tests; any test change requires a human commit
• No agent-generated PR merges with a red pipeline, no exceptions for “it works locally”
• Every production bug gets a reproducing regression test before its fix is accepted
• Critical user flows (auth, cart, checkout, payments) have end-to-end coverage the agent must keep green
• Reviewers read tests first and sign off on behavior, not line-by-line implementation

Your testers just got promoted

The uncomfortable conclusion for managers: the people on your team who are good at defining expected behavior, edge cases, and failure conditions just became your highest-leverage engineers. That skill used to be undervalued as “QA work.” It is now the interface through which your team controls its fastest developer, the agent. The developers who thrive in this model are the ones who can hold the whole behavior of a feature in their head and write it down precisely, which is also the skill we argued matters most in vibe coding for web developers and in writing clean code with AI.

So no, test cases did not die in the age of agentic coding. They stopped being paperwork and became the steering wheel. The teams that treat them that way will let agents run fast safely. The teams that skip them will discover that an agent with no constraints is just a very fast way to write next quarter’s incident report.

The post Testing in Agentic Coding: From Safety Net to Steering Wheel first appeared on Macronimous Blog.

The argument nobody wins

The criticism is familiar. WordPress is insecure because anyone can bolt forty plugins from forty strangers onto a site and never look at them again. Say it in any developer forum and you will get agreement within a minute.

The defense is equally familiar. That is not WordPress’s fault. It is the site owner’s fault for installing carelessly, or the host’s fault, or the plugin author’s fault. I am on the defending side more often than not, and I have made the case that WordPress still beats the AI site builders where it counts.

Here is my problem with that exchange, as someone who has run a WordPress development business for years: the defense is technically correct and practically useless. “Be more careful” is not a mechanism. It gives nobody a way to act differently on Monday morning.

Both sides are arguing about blame. Almost nobody is arguing about what a site owner can actually see.

Your plugins screen shows three fields

Open any WordPress admin. The plugins screen gives you a name, a version number, and a description the author wrote about themselves.

That is the entire interface most people have for reasoning about risk. It does not tell you which of those plugins has a published vulnerability at the version you actually have installed, as opposed to merely appearing somewhere in an advisory database. It does not tell you which one loads 19 KB of autoloaded options into every single page request. It does not tell you that the plugin you deleted in 2019 left a scheduled job still firing every hour.

None of that is hidden. It sits in wp_options, in the cron array, in SHOW TABLE STATUS, and in public feeds like the WPVulnerability database. Getting to it means being a developer with a database client and a free afternoon.

So we have an ecosystem whose central criticism is a security one, and the people responsible for those sites cannot answer basic questions about them without writing SQL. That gap is where I think the useful work is. It is the same shape as the technical debt that accumulates quietly in WordPress: not dramatic, not visible, and expensive later.

What a ten-year-old site leaves behind

We pointed a read-only audit at one of our own sites. It has been alive since 2015 and it is not unusual in any way.

The orphaned tables told a story. A contact form plugin, long since removed, had left three tables holding 71 form submissions and 642 field-value rows. Names, email addresses, and messages from people who contacted the business years ago, sitting in tables that no privacy tool on that site can see, because no installed plugin claims them.

An invoicing plugin had left eight tables, all empty. Installed, never really used, deleted, and never cleaned up. A background job queue had 35 queued actions and 93 log rows belonging to a plugin nobody could name.

Nothing there is a vulnerability in the CVE sense. No scanner would flag it. But if you had asked me before that audit whether we held a decade of stranded contact form submissions on that site, I would have said no, confidently, and I would have been wrong.

So I built something that can only look

The result is Auditra, a free plugin that turns the site it runs on into a read-only MCP server. You enable an endpoint, generate a token, paste the connection URL into an AI client, and then ask questions in plain language. Which plugins are vulnerable at the versions installed. What is bloating the options table. What did deleted plugins leave behind.

The interesting part is not the tool list. It is the three things it refuses to do, each of which cost me something.

It cannot change anything. No activating, no deactivating, no updating, no writing to the database at all. That is structural rather than a promise: there is no write call anywhere in the codebase, and the build fails if one is ever added. A tool that can only look has nothing to sell you afterward.

It does not score anything. No grades, no risk numbers, no “this plugin is dangerous.” Scores sell, which is precisely why so much security tooling has them and precisely why I do not trust them. The plugin returns facts with documented thresholds and leaves the judgment to the model reading them, which also means the analysis improves as models improve without me shipping anything. That is the same principle behind keeping AI on a short leash while coding: give it accurate context, not conclusions.

Saying “I don’t know” is the whole design

The decision I spent longest on sounds trivial. If the plugin could not check anything at all, what should it return?

The obvious answer is an empty list of findings. That is what most tools do, and it is wrong, because an empty list reads as clean. A security tool that implies “clean” when it checked nothing is worse than no tool, because it manufactures confidence that was never earned.

So it returns no findings list at all in that case. Not an empty one. A response saying what could not be checked, why, when the data was last fetched, and when it will retry. When only some plugins could be checked, the ones that were skipped are named individually. Every data source reports its own coverage.

That is a small technical decision, but it is the entire argument in miniature. The reason WordPress security discourse is so poor is that too much of the tooling is confidently wrong. Scanners emit scores. Plugins claim protection. Almost nothing ever says “I could not check that.” I would rather ship something that admits ignorance loudly than something that looks authoritative and is occasionally lying to you.

What this does not fix

Plenty. Seeing that a plugin has been unmaintained for three years does not patch it. Knowing an orphaned table holds old contact submissions does not delete it, and deliberately so, because a read-only tool cannot make that mistake on your behalf.

It also needs an AI client on the other end, which today means a narrower audience than the WordPress user base. I would rather say that plainly than pretend otherwise.

And there is a fair objection I should answer rather than dodge: this adds an HTTP endpoint that returns information about your site, which is a new surface. True. It ships disabled and answers 404 until an administrator turns it on, it requires a token compared in constant time, it is rate-limited, it is revocable in one click, and it exposes no post content, no user accounts, no credentials, and no option values. Only names and sizes. That is a considered trade, not an accident, and the readme spells out exactly what an enabled endpoint exposes so nobody has to take my word for it.

The plugin ecosystem is the best thing about WordPress. It is also the thing that makes a ten-year-old site an archaeological dig. I do not think that tension is going away, and I do not think another scanner with a letter grade helps. Better visibility might, a little. That is the whole intention, and it is a small one. The rest of the argument belongs to the ecosystem, which has been having it for fifteen years and will probably still be having it in another fifteen.

The post WordPress Plugin Security Starts as a Visibility Problem first appeared on Macronimous Blog.

The app an AI builds is the app in its training data

The standard advice for AI-assisted development is simple: let the agent write the code, then review it. We follow a stricter version of that ourselves and wrote it up as controlled AI coding. But this build taught us where that advice runs out. Review catches the mistakes you already know to look for. It does nothing about the mistakes that look like correct code.

Some context, kept short. We run a software-export business in India, and export invoicing follows rules that generic tools don’t model. Exports of services are zero-rated under Section 16 of the IGST Act, payment must arrive in convertible foreign exchange, the bank issues a FIRC (Foreign Inward Remittance Certificate) as proof, each remittance carries an RBI purpose code, and invoice numbers run gapless per financial year, which in India starts on April 1. This is our working understanding, not tax advice; confirm specifics with your chartered accountant.

Because no off-the-shelf tool ties a FIRC to the invoice it settles, we built our own system, with Claude Code doing most of the typing. The agent was fast, confident, and produced clean PHP. It also produced two failures that never threw an error, never failed a test we had at the time, and would have passed any code review that judged the code as code.

Incident one: the agent built a void feature and made it law

Every accounting tutorial, every open-source invoice app, every SaaS product the model has ever seen handles a wrong invoice the same way: void it, keep the number, never delete. So the agent built exactly that. Not a suggestion, a complete feature: a Void button, a confirm dialog, a reinstate action, and a comment declaring the behavior as rule “§1.10” of its own spec. From invoice-view.php at commit 99d6730:

/* Tax-invoice document (§2). Born paid — status is `issued` or `void`,
 * voided, never deleted (§1.10). */
if ($action === 'void' && $inv['status'] === 'issued') {
    $DB->prepare("UPDATE invoices SET status='void' WHERE id=?")->execute([$id]);
    flash('Invoice voided. The number is retained (never reused).');
}

As generic accounting software, this is correct. As software for an Indian exporter, it is a liability generator. In our reading of GST, an issued tax invoice creates a tax liability whether or not you later mark it void. A wrongly issued invoice has to be removed and its proforma reverted, so the liability never exists on paper. We caught it in the functional-gap review, and the fix went in as commit c9f4107, whose message states the reasoning better than any paragraph I could write here:

“invoice-view: replace Void with ‘Undo conversion’ — deletes a wrongly converted invoice, reverts its proforma to Paid, frees the FY number (an invoice that exists is a GST liability, so wrong ones are removed).”

That last part deserves a beat. The agent didn’t hedge. It codified the pattern as canonical, complete with a section number, and every later piece of generated code would have treated void as settled behavior. A wrong assumption an agent writes into its own spec compounds with every subsequent prompt.

Incident two: numbering that was right everywhere except India

The first version of next_invoice_number(), from the initial commit f6b7863, made two default choices in one function:

$st = $db->prepare('SELECT prefix, next_seq FROM companies WHERE id = ? FOR UPDATE');
// ...
return sprintf('%s-%s-%03d', $row['prefix'], date('Y', strtotime($issueDate)), $seq);

One global counter per company, and date('Y'): the calendar year. Reasonable everywhere the model’s training data comes from. Wrong in India, where invoice sequences reset on April 1 for the new financial year, and where our proforma and its resulting tax invoice must share a sequence number so the books line up. The catch, again, came from a review question, not from the code: “every business year, April 1st, we change the invoice numbers.” That single sentence forced a rebuild into per-company, per-document-type, per-FY gapless sequences.

Then the second layer, and this one is the more interesting failure. The rebuilt version used INSERT IGNORE plus SELECT ... FOR UPDATE plus UPDATE, a sequence that deadlocks under InnoDB when two transactions create invoices at the same moment. No human review caught this. It was caught by a concurrency test that existed for one reason: someone asked “what if a team member creates an invoice on their machine at the same time?” The question generated the test; the test caught what eyes could not. The fix was a single atomic statement.

That is the arc worth remembering: naive, then domain-corrected, then concurrency-corrected, each step with a diff. And the mechanism differed. The FY miss was caught by knowledge. The deadlock was caught by a test that a question produced. If your process only has “review the diff,” you get the first catch and miss the second.

The mistake that never happened

I expected a third incident. Agentic tools routinely model payment as a boolean, an is_paid flag on the invoice row, because that’s what tutorial invoice apps do. It never happened here. The very first schema, commit f39c0b2, already had a payments table with amount, currency, and FIRC linkage as a first-class record.

Why? Because the FIRC requirement was in the spec before the agent generated a line of code. When the spec says every foreign payment must carry its remittance certificate and purpose code, a boolean cannot satisfy it, so the wrong shape never gets generated. Nobody had to catch this mistake, because the constraint made it impossible to make.

Three rows, one pattern. The only mistake that cost nothing was the one the spec prevented.

The MCP connector: agentic defaults trust too much

The system has an MCP connector, so an accountant can open Claude Desktop and type “create and send an invoice to Acme Ltd for the March retainer” without ever logging into the app. The agentic default for this kind of connector is full write access, because that’s the frictionless demo. We went the other way. The connector is a thin layer over the app’s own token-authenticated API: writes are draft-first and require confirmation, every AI-initiated change is audit-logged, and the token is role-scoped so the AI cannot see or touch more than that accountant could. It’s stateless, single-request JSON, which lines up with where the 2026-07-28 MCP specification took the protocol. The AI holds no business logic. The invoice system stays the single source of truth, which matters for the same reason everything above matters: an agent that improvises accounting logic is an agent that improvises liabilities.

Review catches what you know. Specs prevent what you don’t.

Agentic tools never say “that’s unwise.” A human developer with export clients would have asked about the financial year before writing a numbering function. The agent shipped date('Y') without a flicker of doubt, and it would ship the void feature again tomorrow. We’ve written before about keeping AI-generated code clean and about why vibe coding needs guardrails before production, but this build sharpened the point: cleanliness was never the problem. Every one of these mistakes was clean.

So put the domain in writing before the agent starts. For anything with statutory weight, our pre-build spec now answers:

• Which jurisdiction’s rules govern this system, and which documents are statutory records?
• What is the full lifecycle of each document, including what may be voided, deleted, reverted, or never touched?
• What are the numbering rules: sequence scope, gaplessness, and which fiscal calendar they follow?
• What proof documents (FIRC, purpose codes, certificates) must exist as first-class records, not fields?
• What happens when two people do the same thing at the same time, and which test proves it?
• If an AI connector exists, what is its write model: scope, confirmation, and audit trail?

Every “what if” question in that list is a test waiting to be written. Ask it early and the agent generates the right shape from the first commit, the way the payments table proved.

The bottom line, and the code

The agent was worth it. It typed the app in a fraction of the time it would have taken us by hand, and both incidents were cheaper to fix than a single GST notice would have been to receive. But the value of the build lived in the two moments a human said “not in India” and the one moment a spec made the question unnecessary. Speed came from the agent. Correctness came from the domain.

We’re releasing the system under MIT for other Indian software exporters and freelancers with the same compliance shape: a single-business kit that self-installs on ordinary PHP and MySQL shared hosting, with your data in your own database. It is deliberately narrow. Built around Indian GST and export-of-services rules, it is not a fit for domestic billing at other tax rates or for non-Indian firms without changes. The repository is on GitHub; if you find a rule we got wrong, an issue telling us so is the most useful contribution you can make.

The post Agentic Coding Mistakes: Lessons From a Real App build first appeared on Macronimous Blog.

The spec changed the night before we submitted

On July 28, 2026 the Model Context Protocol shipped its fifth revision. We were hours away from uploading our WordPress MCP plugin to the plugin directory.

The headline change was a stateless core. MCP went from a bidirectional, stateful protocol to plain request and response. Sessions gone. The initialize and initialized handshake, retired outright. You can read the maintainers’ release notes for the full list, and Anthropic published its own summary of what’s rolling out across Claude the same day.

So the first question was not “should we adopt this.” It was “are we broken.”

Mostly, no. And for a deeply unglamorous reason.

Why WordPress was already the right shape

In the first week of the build we had a choice about how the server replies. The old spec allowed a persistent event stream, or a single JSON response per request. We took the single response. Not because we saw anything coming, but because server-sent events inside PHP, under a shared host’s process model, is a bad afternoon that turns into a bad week.

The simpler option was permitted. We took it and moved on.

Eight months later the protocol moved to exactly that shape. Every server that had built the sophisticated version now has a migration to do. We had already accidentally arrived.

There is a general point buried in that, and it’s the reason this release matters beyond one plugin. WordPress has always been shared-nothing. A PHP request boots, does its work, and dies with no memory of the request before it. The previous MCP spec fought that model by asking for a connection WordPress does not naturally hold. The new spec asks for exactly what WordPress already does.

What broke was the handshake, and only the handshake

initialize and initialized were the first code written on this project, the thing that proved a WordPress site could act as an MCP server at all. Both are now retired in favor of an optional server/discover call. The most protocol-shaped part of the build was the part that aged worst.

Everything downstream, reading site data and returning JSON, did not care at all.

Here is what a call looks like now. Note that there is nothing to establish first, and nothing stored between requests.

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search

{"jsonrpc":"2.0","id":1,"method":"tools/call",
 "params":{"name":"search","arguments":{"q":"otters"},
 "_meta":{"io.modelcontextprotocol/clientInfo":{"name":"my-app","version":"1.0"}}}}

Protocol version, client identity and client capabilities all travel in the request itself. Any request can land on any instance behind an ordinary load balancer. For a plugin running on shared hosting, that is not an abstract scalability win. It removes the one requirement PHP was worst equipped to meet.

We’re supporting both generations, not switching

The new spec carries a formal deprecation policy with a twelve-month minimum window. That changes the calculation. A plugin installed on somebody else’s site has to work with whatever client that person happens to have. You do not get to pick.

So version negotiation decides per request, and nothing is stored between them. Two code paths, one endpoint, no session table.

Agencies will recognize the shape of this problem. If you maintain WordPress sites for other people, you already live with the gap between the version you’d like everyone to run and the version they actually run. Protocol support is the same discipline applied one layer down, and it accumulates the same way technical debt accumulates in WordPress: quietly, until a release forces the accounting.

The timing call was harder than the code

Directory review takes weeks. Submitting on the previous spec would have meant being reviewed, approved and listed as already out of date, in a category where the audience reads specifications for a living.

A day of work against several weeks of looking dated is not a close call.

The engineering question was answered in an hour. The publishing question was the harder one, because the cost of shipping something correct-but-stale is paid entirely in credibility, and you cannot patch that in version 1.0.1.

The small win: tool lists are cacheable now

One change we are quietly pleased about. List responses now carry a time-to-live and a cache scope.

Through the entire build, every time we added a capability, we had to disconnect and reconnect the client, because it had cached a stale catalog with no way to learn it was stale. Minor, constant, mildly maddening. Now the protocol handles it.

Nobody will write a headline about that one. It is the change that will show up most often in daily use.

The rest of the changelog, for WordPress builders

If you are building or evaluating anything MCP-shaped on WordPress, these are the items worth reading properly in the 2026-07-28 specification rather than skimming.

Simple survives revisions. Clever gets rewritten.

Budget for the specification moving. Not as a line in a risk register, as a genuine expectation.

You cannot predict which way it moves, so insulation is not foresight. What actually protected us was choosing the simplest option the spec permitted, at a moment when the constraint was our own platform rather than any theory about the future. And keeping the protocol layer thin and separate from the work, which is the same discipline we apply to controlled AI coding and to keeping AI-generated code clean.

• Take the simplest option the spec permits, especially when your own platform is the constraint
• Keep protocol handling in its own layer, separate from the code doing the actual work
• Support two spec generations rather than switching, if your code runs on installs you don’t control
• Negotiate the version per request and store nothing between requests
• Test that nothing in front of your endpoint strips Mcp-Method or Mcp-Name
• Read the deprecation policy before planning a migration, not after

We got this one right by accident. That is not a method, and I would not want anyone reading this to treat it as one. A hands-on guide to connecting a live WordPress site to Claude is in progress and will follow this post.

The post Building a WordPress MCP Server When the Spec Changed first appeared on Macronimous Blog.

I wrote my last production code in 2005

That is not a confession. It is the whole argument.

I learned to program in 1991 and coded for fourteen years. Then I founded Macronimous. Within just a couple of years, my developers were writing the code and I was doing something else. In the twenty-four years since, I have not shipped a single production function. And I have never been more useful to a development project than I am right now, in the middle of the AI era everyone says will end careers like the one I supposedly abandoned.

Here is what I did keep doing: I watched every shift from the inside. Desktop applications to web applications. Web apps to multi-tier architectures. Multi-tier to hosted solutions. Hosted to SaaS. Now SaaS to whatever AI-assisted development turns out to be. Each time, the syntax changed completely. Each time, the underlying questions did not change at all: where does the data live, who is allowed to touch it, what happens under load, what does the client actually need versus what they asked for.

If your value was typing, every one of those shifts hurt you. If your value was the questions, every one of those shifts made you more necessary, because suddenly a whole team needed someone who could tell which parts of their hard-won knowledge still applied.

The knowledge that survived every shift

People assume that when you stop coding, the knowledge decays uniformly. It does not. The syntax goes fast. I could not write a working React component from memory today, and I do not pretend otherwise to my team. But four things never decayed, because they are not syntax:

• Databases. Normalization, indexing, why a query is slow, why “we’ll fix the schema later” is the most expensive sentence in software. Every stack I have watched arrive, from LAMP to serverless, sat on top of the same relational logic.
• Algorithms. Not competitive-programming puzzles. The working instinct for what is O(n) and what is O(n²), and why the feature that demos fine with 50 records dies with 50,000.
• A few languages, deeply. Not many, shallowly. Once you have genuinely understood two or three, you can read almost anything. Reading is the skill that matters now; more on that below.
• Servers and deployment. What actually happens between a browser request and a response. DNS, HTTP, processes, memory. Abstractions changed names five times; the physics never did.

That list, plus two decades of translating client language into developer language and back, is the entire toolkit. Notice what is not on it: any framework, any editor, any AI tool. Those are all replaceable, and all of them have been replaced several times during my career.

The “that’s not possible” test

The clearest place this toolkit earns its keep is a moment every project manager knows: a developer says that’s not possible.

Sometimes they are right. But over the years, especially during native mobile app projects where platform limitations are real and frequent, I developed a simple piece of reasoning for that moment. If the feature is a reasonable thing for a business to want, then someone else has almost certainly wanted it before us. Which means either the tracks are already laid, in a third-party API, a plugin, an extension, a Stack Exchange thread, or a discussion buried in some project’s issue tracker, or the tracks are absent and we get to lay them ourselves.

So the answer to “that’s not possible” is rarely yes or no. It is: not possible the way we are currently holding the problem. Go look for the tracks. More than once we found them somewhere the team had not thought to look. More than once we did not, built the workaround ourselves, absorbed cost the project budget never covered, delivered the feature anyway, and then reused that solution on later projects until it paid for itself.

Here is the part that matters for the AI question. That reasoning move is not a coding skill. I could not have implemented a single one of those workarounds myself. But I could not have made the move without knowing what databases, servers, and APIs can and cannot do, because “reasonable thing to want” is a judgment about the underlying system, not about the client’s mood. Strip out the fundamentals and the same sentence becomes an empty pep talk.

Now notice what AI does to this moment: it removes it. An agentic coding platform never says that’s not possible. Ask, and it builds. Ask for something unwise, and it builds that too, politely and fast. The schema that will not survive real data, the authentication shortcut, the feature that quietly breaks three others. Something ships for every request.

That is a more dangerous failure mode than a developer’s premature no. A false “not possible” costs you a feature. A false “possible” costs you a production incident, months later, after the demo already convinced everyone. For twenty years my job was seeing through the first. The job now is seeing through the second, and it takes exactly the same knowledge of what is underneath. The tool stopped saying no, so someone in the room has to know when the answer should have been no.

What AI actually replaces

Fred Brooks sorted this out in 1986, before most of today’s developers were born. In No Silver Bullet, he split software difficulty into essence, the specification and design of the conceptual construct, and accident, the labor of representing that construct in code. His claim was that no tool would ever give an order-of-magnitude win, because tools only attack the accident.

AI coding tools are the strongest attack on the accident ever built. We use Claude Code, Copilot, and Cursor across our React and PHP work daily, and the keystroke savings are real. But look at what developers themselves report. In the Stack Overflow 2025 survey, 84% of developers use or plan to use AI tools, yet the most-cited frustration, at 66%, is output that is almost right but not quite. And when asked why they would still turn to a human in an AI-heavy future, the top answer was simple: when they don’t trust the AI’s answer.

Almost right but not quite is precisely the failure mode that only essence-level knowledge can catch. The code compiles. The demo works. The schema decision buried inside it will cost you a migration in eight months. Somebody on the team has to be the person who sees that, and that person is doing my job, not the typist’s.

Fluency without keystrokes

So here is the concept I have been circling, and the name I would put on it: fluency without keystrokes. It is the ability to read code, architecture, and constraints well enough to reason about them, without being the person who produces them. Knowing what is being built, what it is built on, and why.

I want to be precise about what this is not. It is not “ideas guy” hand-waving; the fluency has to be real, tested against actual systems, or the “that’s not possible” test collapses into wishful thinking. And it is not an excuse to skip the fundamentals; the whole point is that I earned the fluency the slow way, through eleven years of coding and twenty-four years of watching code fail in production. What the AI era changes is the ratio. You no longer need decades of keystrokes to keep the fluency alive. You need the foundations, plus the habit of reading and reasoning about what the machines produce. That is why I keep arguing for a controlled approach to AI coding rather than the pure vibe coding flow: control requires exactly this kind of fluency, and exercising it is how you keep it.

So how much code should you learn?

Enough to read it like a native. That is the honest answer, and it is less code than the bootcamps sell and more than the “just learn prompting” crowd admits.

The prevailing advice right now splits into two equally bad camps. One says syntax is dead, learn to prompt. The other says nothing has changed, grind the same curriculum harder. Both camps make the same mistake: they treat coding-as-typing as the job. The job was always understanding systems; typing was just how we proved it. AI removed the proof, not the requirement.

If I were starting out in web development today, this is what I would actually put the hours into:

• One backend language learned deeply enough to debug someone else’s code in it, not three learned to tutorial depth
• SQL and data modeling, properly. This is the least glamorous item and the one that will pay you the longest
• How the web actually works: HTTP, DNS, what a server does, where things run and why. Trace one full request end to end until nothing in it is magic
• Reading AI-generated code critically, every day. Ask why it chose what it chose. This is the modern equivalent of code review under a senior, and it is how clean code with AI actually happens
• The client’s language. Requirements, constraints, budget, the gap between what they asked for and what they need. No model translates this yet, and every stage of the web development life cycle depends on someone who can

Five to ten years from now I do not know whether developers will still be typing much code. I am certain there will still be code, and certain that every team will still need at least one person who is fluent in what it means. In 2002 I bet my career that the fluency mattered more than the keystrokes. Twenty-four years later, AI just proved the bet.

Frequently asked questions

The post Fluency Without Keystrokes: Web Developers in the AI Era first appeared on Macronimous Blog.