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.

What WordPress 7.0 actually added

The headline feature in Armstrong isn’t a chatbot. It’s plumbing. WordPress 7.0 ships three things: the WP AI Client, a provider-agnostic PHP API that plugins call instead of wiring up OpenAI or Anthropic themselves; the Connectors screen at Settings > Connectors, where API keys live; and the Abilities API, which lets plugins and core expose actions like “create a post” or “add an excerpt” in a machine-readable form. That last piece is what makes 7.0 natively agentic. An AI agent can now discover and trigger site actions through a defined interface, which is the same shift that’s reshaping optimizing for AI-powered search. Three provider connectors come pre-registered: OpenAI, Anthropic, and Google. Each still needs its plugin activated and your own API key, on PHP 7.4 or higher.

Where the token cost actually starts

Here’s the part most of the coverage gets wrong. Installing WordPress 7.0 costs you nothing in tokens. The AI Client sits dormant until two things happen: you add a provider key in Connectors, and a plugin makes a call through the client. No key, no calls, no bill. When calls do happen, the provider bills you on its own per-token rates against the key you supplied. WordPress is only the router. It never sees a cent of that traffic, and it has no native spending cap of its own. The credential is entered once, encrypted, and shared across every compatible plugin on the site, which is cleaner than the old habit of each plugin storing its own key.

Four ways the AI gets paid for

Before you connect anything, decide which of these you’re actually signing up for. They have very different cost profiles.

For privacy-sensitive clients or high-volume workloads, the community Ollama provider runs open models like Llama or Mistral on your own server. No data leaves the box and there’s no metered token cost, which is the same instinct behind keeping AI on a tight leash in any production workflow. If you’ve ever weighed a hosted builder against self-managed WordPress, the trade is familiar; we’ve argued before that WordPress still wins for SEO, and owning your AI plumbing is part of why.

The real exposure isn’t the bill. It’s who can run it up.

Because keys live in one screen and every compatible plugin shares them, the risk concentrates instead of spreading out. Anyone who can reach Settings > Connectors can attach a provider and open the meter. The Abilities API widens the surface further: it defines what an AI agent is permitted to do on your site, and the official guidance is blunt that it needs administrator-level capability checks so untrusted users can’t fire arbitrary prompts at your paid providers. On a multi-author site, or any client install you manage, that’s the first thing to lock down. The MCP Adapter, which ships as a separate plugin, goes further again, letting external assistants like Claude or ChatGPT discover and trigger your site’s abilities over MCP. Genuinely useful, but only with permissions set deliberately. Left loose, this becomes exactly the kind of technical debt that piles up quietly until a bill or a breach surfaces it.

What to do now

Whether you run one site or forty client installs, the moves are the same.

• Update on staging first. Armstrong rebuilt the admin in React and the release slipped a full month for stability reasons, so test plugin and theme compatibility before production.
• Restrict the Connectors screen to a single admin role so no one quietly attaches a key.
• Set hard spend caps and rate limits at the provider dashboard, because WordPress has none. Use one project-scoped key per site so you can attribute and kill spend independently.
• Decide billing per client up front: you hold the key and bill managed usage, or the client brings their own and owns the invoice. Don’t leave it ambiguous.
• Audit the Abilities API permissions and any MCP Adapter exposure before switching on agentic features.
• For privacy-sensitive or high-token work, evaluate the Ollama local-model provider instead of a metered cloud key.
• Disable the AI layer entirely on brochure sites that won’t use it. Less attack surface, zero accidental spend.

My read

7.0 is the right architecture and the wrong moment to switch your brain off. The provider-agnostic design genuinely protects you from lock-in, and centralizing keys beats the old one-plugin-per-provider mess. But “native AI” has been sold as a feature when it’s really a billing relationship you now own. Treat the AI Client like any outbound paid API: gate who configures it, cap it at the source, and turn it on only where it earns its keep. With 7.1 due in August and 7.2 in December, the agentic surface only gets wider, so get your governance right before then. It pairs directly with how search is shifting in 2026.

The post WordPress 7.0 AI: The Token Cost Reality for Site Owners first appeared on Macronimous Blog.

It usually goes like this. A developer points Cursor or Copilot at a gnarly legacy file and asks it to clean things up. The model does what it’s good at and collapses a nest of conditionals into something half the length and twice as readable. Tests pass locally. The diff looks clean. It ships. A week later, a quiet edge case that one of those “redundant” branches used to catch shows up in production, on a client site nobody has opened in years.

There’s a hundred-year-old name for the mistake. Chesterton’s Fence goes like this: you find a fence across a road with no obvious purpose. The reckless reformer says, “I don’t see the use of this, clear it away.” The wiser one answers: go find out why it’s there first, then you may remove it. Every codebase older than its current team is full of fences. The validation that looks paranoid. The handler for a case that “can’t happen.” The query that dodges an obvious index for reasons lost to time. We are now handing those codebases to tools that are fast, confident, and carry zero memory of why anything was built.

The clean diff is the trap, not the safeguard

The standard advice sounds responsible: let AI move fast, then review the diff. Clean change, green tests, merge. The problem is that a diff shows you what changed, not what the change knew. A deleted block leaves no trace of the bug it was preventing. The tests pass because nobody ever wrote one for that edge case, which is precisely why there was a guard sitting there instead of a test. So you get a clean diff, a green build, and a landmine reburied for next quarter. The review ritual feels like diligence while it quietly rubber-stamps the deletion of context.

None of this is an argument against AI in the workflow. We run Claude Code, Copilot, and Cursor across React and PHP every day, and the speed is real. It’s an argument against confusing velocity with progress when you’re standing in code you didn’t write. The discipline of writing clean code with AI starts with knowing when not to let it touch something.

Why this bites agencies hardest

If you run an offshore or white-label shop, the exposure is sharper than it is for a product team that has lived on one codebase for years.

• You inherit. Most of what we touch was built by someone else, often years ago, for a client whose original developer is long gone. The fence and the person who built it both left before we arrived.
• Juniors lean on it hardest. A mid-level developer using AI to cover gaps is making the right move, until the model suggests something elegant and wrong and they don’t yet have the scars to tell the difference. In a pull request, elegant-and-correct and elegant-and-wrong look identical.
• The data risk is its own category. Pasting a client’s source, an API key, or a slice of proprietary logic into a public model is a one-keystroke NDA breach. That isn’t a code-quality problem. It’s a get-fired problem.

This is the same pattern we flagged in hidden technical debt: the costliest problems are the ones nobody can see in a quick review.

Not every old line is a fence

Here’s where the lazy reading of Chesterton, “never delete old code,” is as wrong as the reckless one. Plenty of old code is genuinely dead: commented-out blocks, an abandoned feature flag, a function nothing calls anymore. That is not a fence. It’s litter, and AI is excellent at hauling it away. Let it. The whole skill is telling the two apart.

When in doubt, treat it as a fence. The cost of investigating a line that turns out to be litter is two minutes. The cost of deleting a fence is a production incident on a client’s site.

Make the human own the commit

The rule we land on isn’t “trust the AI” or “distrust the AI.” It’s a short set of habits that cost time on purpose. The human owns the commit: “the AI wrote it” explains nothing, and if you push code, you defend every line in review. The AI builds inside your guardrails, not its own: state the stack versions, conventions, and component structure explicitly, every time, or it will invent a perfectly reasonable pattern that contradicts the three already in the project. And before you let a tool rewrite or remove anything, you find out why it’s there. We’ve written up the full workflow as Controlled AI Coding, but the pre-flight before touching existing code fits on one card:

• Run git blame on the block and read the commit message
• Check the original issue or ticket for the why, not just the what
• Confirm whether a guard is covering an edge case the diff would silently remove
• Make sure the change matches existing stack versions and conventions
• Verify no client source, credentials, or keys are going into the prompt

This is not about slowing everyone down. It’s about spending two minutes on the handful of lines that are actually fences, and letting AI fly on everything else. The same caution applies when the speed feels intoxicating; the high of vibe coding is exactly when fences get cleared without anyone noticing.

The one thing AI can’t bring to the review

AI doesn’t tear down fences because it’s reckless. It tears them down because it has no memory and no stake. It was never paged at 2 a.m. by the bug that guard was written to stop, so it feels no caution. Which means the caution is now entirely ours.

Reading that map, and knowing which fences to keep, is quietly becoming one of the more valuable things a developer can do, right at the moment the tools are most eager to skip it. Treat it the way Martin Fowler frames technical debt: something you take on deliberately and pay down on purpose, not something an assistant runs up for you while you watch the diff scroll past.

The post The Code Your AI Wants to Delete Is Load-Bearing first appeared on Macronimous Blog.

The 6-month codebase problem

If you run a development team in 2026, you’ve probably already seen this movie. A developer ships a feature in two days that would have taken five. Everyone is happy. The PR gets merged. Three sprints later, somebody else needs to extend that module and finds 400 lines of code nobody fully understands — half of it generated, half of it hand-edited, none of it documented. The original developer says, “Yeah, I let Copilot handle that part.” The original Copilot session is gone. The reasoning is gone. What’s left is working code that nobody can confidently change.

This is not an AI problem. This is a discipline problem that AI has accelerated.

At Macronimous we’ve been writing PHP and JavaScript for clients since 2002. We’ve watched every productivity wave — frameworks, no-code, low-code, and now AI assistants — promise to remove engineering discipline from the picture. None of them have. What they actually do is shift where the discipline needs to live. AI coding is no different. The teams that will still be maintainable in 2028 are the ones treating AI output the same way a senior engineer would treat code from a junior who’s fast, prolific, and occasionally confidently wrong.

Why traditional discipline matters more, not less

There’s a tempting narrative that AI changes everything about how teams should write code. It doesn’t. The practices that mattered before AI matter more now, because the volume of code being produced has gone up while the per-line attention has gone down.

The four traditional disciplines we lean on hardest:

• Modular code review. A 50-line function reviewed properly is worth more than a 500-line file skimmed. AI makes large files cheap, which means insisting on modularity is more important, not less.
• Scheduled refactoring intervals. If you only refactor when something breaks, you’ll only refactor what’s already on fire. We refactor at sprint-end, every two weeks, before the debt compounds.
• Reusable component repositories. The oldest practice in software engineering — keep what works, call it when you need it. AI tempts teams to regenerate similar code from scratch each time. That’s how you end up with seven slightly different date pickers in one project.
• Documented intent. AI can write the code. It can’t write why you needed the code. That part is still on you, and it’s the part that matters in month seven.

The Code-Check-Refactor (CCR) loop

We organize our AI coding workflow around a three-step loop we call CCR. It’s deliberately boring. Boring is what survives.

Code — the AI-assisted writing phase. Cursor, GitHub Copilot, and Claude Code all earn their keep here. The developer is in charge; the AI is a collaborator, not an author. Generation happens against a clear, scoped prompt — a single function, a single component, a single migration. Not “build me the dashboard.”

Check — human review of every AI-generated block before it touches the main branch. This is non-negotiable. Two questions every reviewer asks: Do I understand what this does? and Do I understand why it does it this way? If the answer to either is no, the code goes back, regardless of whether tests pass.

Refactor — sprint-end consolidation. Every two weeks we set aside time to look at what was added, what duplicated existing utilities, and what should be promoted into the shared repository. This is when AI-generated sprawl gets compressed back into reusable parts.

How we actually do this at Macronimous

Specifics matter, so here’s the actual workflow our React and PHP teams run, not a generalized version of it.

1. Scoped prompts, not open-ended ones

We treat the AI like a contractor. Contractors get scopes of work. So does the AI. Instead of “build the user profile page,” the prompt is “write a React functional component that takes a user object as a prop and renders name, avatar, role badge, and last-login timestamp. Use our existing <Avatar /> and <Badge /> components from /shared/ui.” The narrower the scope, the better the output and the easier the review.

2. The shared repository is sacred

Every project has a /shared/ directory — components, utilities, hooks, helpers — that’s been written, reviewed, and battle-tested. AI is instructed to use these, not to regenerate equivalents. When a developer notices the AI has produced something that duplicates shared code, that’s a Check failure. The PR gets sent back.

3. Two-pass review on AI-heavy PRs

Any PR where more than 30% of the diff is AI-generated gets a second reviewer. Not because we don’t trust the first reviewer, but because AI-generated code has a particular failure mode: it looks reasonable. Two pairs of eyes catch the “looks reasonable but isn’t” cases.

4. Sprint-end refactor block

Last day of every sprint, two hours blocked. The team walks through what was added that sprint and asks three questions:

• What duplicates something we already had?
• What got hand-patched in three places that should be one utility?
• What’s complex enough that future-us will thank present-us for simplifying it now?

5. Commit messages that explain why

AI is great at commit messages that describe what changed. We require commit messages that describe why. “Refactored auth flow” is rejected. “Refactored auth flow to remove duplicate token validation between middleware and controller” is accepted. The why is what makes the code base navigable in month seven.

6. The “explain it to me” gate

Before any AI-generated code merges, the developer who wrote the prompt has to be able to explain the code without referring to the AI. If they can’t, they don’t understand it well enough to maintain it. Which means nobody on the team does.

Seven practical tips you can apply Monday morning

1. Set a “no main branch from AI alone” rule. Every AI-generated change passes through human review and a named human author on the commit. Not as a formality — as a record of accountability.
2. Build a prompt library, not a prompt history. Save the prompts that produced good code. Treat them like reusable assets. New developers should be able to read your prompt library and understand how the team works with AI.
3. Cap AI-generated PR size. We use a soft 400-line limit. Above that, the PR gets split. Large AI PRs are where review fatigue compounds and bugs slip through.
4. Tag AI-generated functions during review. Not forever — just during review. A simple // AI-generated, reviewed by [name] comment makes the second reviewer’s job easier and creates a temporary audit trail.
5. Run a duplication check before each sprint-end refactor. Tools like jscpd for JavaScript or PHP Copy/Paste Detector for PHP take five minutes and surface where AI has reinvented something you already had.
6. Write the test first when the AI writes the implementation. If you let the AI write both, you get tests that pass against the implementation rather than tests that prove the implementation is correct. Human-written test, AI-written implementation — that order.
7. Document the prompt alongside the code, not just the code. A short comment block at the top of an AI-generated module noting the original prompt and intent saves an hour of archaeology in month nine.

Uncontrolled vs. Controlled AI coding

The team audit checklist

Run this checklist on your team’s current AI workflow. If you can’t tick five of these, you have an emerging maintainability problem — even if everything is shipping fine right now.

• Every AI-generated PR has a named human reviewer who can explain the code without the AI
• The team has a documented shared repository of reusable components, and AI is instructed to use it
• Refactoring is scheduled, not reactive
• AI-heavy PRs (above 30% generated) get a second reviewer
• Commit messages explain why, not just what
• Prompts that produced good code are saved in a team-accessible prompt library
• There is a hard or soft cap on AI-generated PR size
• Duplication detection runs before each sprint-end refactor
• Tests are written by humans for AI-written implementations, not the other way around
• New developers are onboarded onto the team’s AI workflow as part of their first week

Frequently asked questions

The bottom line

AI coding is not the end of engineering discipline. It’s the beginning of needing more of it, applied differently. The teams that recognize this and build a controlled workflow — Code, Check, Refactor, sprint after sprint — will own maintainable, extendable code bases that compound in value. The teams that don’t will spend 2027 and 2028 untangling what they shipped in 2026.

The old practices weren’t outdated. They were waiting for a moment exactly like this.

The post Controlled AI Coding: A Practical Guide for Dev Teams first appeared on Macronimous Blog.

The 7-Minute Temptation: AI Website Builder vs WordPress for SEO

Seven minutes. That is all it took to build something that nearly made me question 28 years of professional instinct.

I was sitting in my office planning the launch of outsourcewp.com—a new Macronimous vertical dedicated to high-end WordPress white-label services. Naturally, the plan was to build it on WordPress. But as a visual reference for my team, I decided to feed our actual strategy document into two of the most talked-about AI site builders: Figma Sites and Lovable.

The result was an immediate, high-fidelity rush. Within minutes, I wasn’t looking at a wireframe; I was looking at a finished product. It was clean, sophisticated, and—for a moment—genuinely tempting.

I’ve been working with CMSs since the mid-90s and doing SEO since 1999. I founded Macronimous in 2002. My career has been built on the “long game” of web architecture. Yet, there I was, staring at a 7-minute miracle, wondering if the old way of doing things had finally been disrupted by a prompt.

The “Wow” Factor: Figma vs. Lovable

To give you an idea of what triggered this mid-career crisis, you can see the actual prototypes I generated here:

• The Figma Version: https://asset-beige-76899864.figma.site/
• The Lovable (React) Version: https://frame-fable-engine.lovable.app/

The Figma site gave me an impressive first page almost instantly. Mega menu, clean layout, perfect spacing—it looked like it had been labored over by a senior designer for a week. The Lovable version was equally polished, generating a React-based structure that felt modern and incredibly fast.

The irony was not lost on me. Here I was, building a platform to sell WordPress expertise, and I was dangerously close to building that platform without WordPress. It wasn’t an act of laziness; it was an honest reaction to how seductive these tools have become. They remove the friction of development and replace it with immediate visual gratification.

But then the professional reality hit.

The Invisible Wall

The temptation lasted exactly as long as it took for me to look for the “engine.” As someone who has lived inside backend systems for nearly three decades, the realization that there was no Content Management System was simply not digestible.

These tools are brilliant at creating a “look,” but they are currently incapable of supporting a “business.” When you strip away the beautiful typography and the smooth transitions, you’re left with three fundamental problems that make these builders a liability for any serious commercial project.

1. The SEO Control is Skin-Deep

In the modern landscape of Answer Engine Optimization (AEO), your site needs to be more than just readable; it needs to be “data-dense” for search engines. When I audited these AI builds, the SEO control was shallow.

To rank today, you need surgical access to structured data (Schema markup) so Google knows exactly what services you offer and where. You need control over canonical tags to ensure you aren’t penalized for duplicate content, and you need a dynamic sitemap that updates the second you add a new page. In these AI builders, you are essentially locked out of that deep-level plumbing. You are trading long-term visibility for a 7-minute head start.

2. The Scalability Trap

A business site is a living organism. It needs to grow. Today it’s five pages; next year it’s fifty service pages and a hundred case studies. With a CMS like WordPress, scaling is a structural feature. You create a template once, and the system handles the rest. With these AI builders, you cannot simply “prompt” your way to a massive, authoritative site. Every new section or major content update requires a fresh round of design-level intervention.

3. The Portability Crisis

This is the ultimate dealbreaker. When you build on a proprietary AI platform without a decoupled CMS, you don’t really own your site—you’re renting it. There is no “Export to WordPress” button. There is no easy migration path if the platform changes its pricing model or decides to pivot its features. If you need to move, you are essentially starting from scratch. For a business that plans to be around for the next decade, building on a foundation you can’t move is an unacceptable risk.

The Ethics of the “Sign Out”

This experiment solidified my ethical stance as the founder of an agency: “We could have impressed until delivery, but not after we sign out.”

If we used these tools for client work, we could deliver a stunning website in record time. The client would be thrilled during the demo. But the moment we handed over the keys and signed out of the project, we would be leaving them in a bind. The first time they wanted to add a blog post or update a service price, they would realize they don’t have a system—they have a static asset that they can’t manage themselves. Recommending a site with no CMS to a business that needs to grow is an injustice to the client.

An Honest Verdict

Does this mean AI site builders are a gimmick? No. In fact, they are now a permanent part of our workflow at Macronimous—but only as prototyping engines. They are incredible for visualizing a strategy document in real-time or building a high-fidelity “visual brief” to show a stakeholder. They are the ultimate “mood board” on steroids.

But until these builders integrate a proper, robust CMS—one that allows for data portability and deep technical SEO—they are not ready for prime time. I nearly built a WordPress service site without WordPress. It was a moment of genuine temptation, but it served as a vital reminder: AI can build a beautiful facade in seven minutes, but it still hasn’t figured out how to build the foundation.

Frequently Asked Questions: AI Website Builder vs WordPress for SEO

1. Are AI website builders like Figma Sites or Lovable good for deep, technical SEO?
While visually impressive, most AI website builders provide only skin-deep SEO control. To rank effectively, you need surgical access to technical plumbing like structured data (Schema markup), canonical tags, and dynamic sitemaps. Currently, these builders often lock you out of these critical, long-term optimization features. However, given how fast the technology is moving, I expect them to be accommodating full SEO readiness soon.

2. Can I effectively scale an AI-generated website as my business grows?
Scaling requires a structured architecture. At least for now, you cannot simply “prompt” your way to a massive, authoritative site. Every significant addition, new service section, or major content update requires fresh manual intervention, making long-term growth difficult without a traditional CMS like WordPress.

3. What is the biggest long-term risk of building a serious business site with an AI builder?
The biggest risk is the portability crisis. Since you are building on a proprietary AI platform, you are essentially “renting” your foundation. There is usually no realistic migration path, meaning you cannot easily move your site or content to a new host if the platform changes its features or pricing. For businesses seeking a serious, long-term online presence, we discourage building core business sites solely with these AI tools.

4. What is the best use case for modern AI site builders in a professional workflow?
AI site builders are exceptional prototyping engines. At Macronimous, we use them to present client demos the next day, saving days of manual visual reference work, while having all the necessary elements visually in place. They are invaluable for visualizing a brand strategy document in real-time, testing layout ideas quickly, and generating high-fidelity visual briefs to get a team or stakeholder on the same page before production coding begins.

5. Is it ethical for an agency to deliver a final business website that has no CMS?
Our position at Macronimous is no. Recommending a site with no CMS to a client who needs organic growth and long-term content management leaves them with an unmanageable static asset. We believe in providing clients with a sustainable foundation they can actually use after the final handoff.

The post AI website builder vs WordPress for SEO first appeared on Macronimous Blog.

I’ll be honest with you. This blog post about giving “AI layer for iOS apps” started as an internal conversation at Macronimous.

We’ve been building web and mobile applications since 2002 — over two decades of shipping products for clients across the USA, UK, and Australia. Right now, we’re in the process of reaching out to our mobile app clients about adding AI capabilities to their existing apps. For our Android clients, the path is relatively clear. Google’s Gemini is integrated at the system level, third-party AI APIs are straightforward to implement, and the ecosystem is moving fast.

But for our iOS clients? We’re genuinely unsure how to advise them right now. And we think that uncertainty is worth sharing — because if an agency that’s been doing this for 23 years is navigating this carefully, chances are you should be too.

What Sparked This Conversation about AI layer for iOS apps

In March 2026, at SXSW in Austin, Nothing CEO Carl Pei made a bold prediction: the app era is ending. AI agents, he argued, will soon replace the app icons on your phone. You’ll simply state your intent — “get me a ride,” “order dinner,” “cancel my subscription” — and the AI handles everything. No icons. No app switching. No friction.

When we read this at Macronimous, the first reaction wasn’t “he’s right” or “he’s wrong.” It was: what does this mean for the apps we’re building for clients right now?

Because Pei isn’t entirely wrong. And the implications are different depending on whether you’re building for Android or iOS — and that difference is what most articles on this topic completely miss.

Where Pei Is Right: Simple Tasks Will Go to AI

Pei’s core argument is that apps have become fragmented and overwhelming. The average smartphone user has dozens of apps, each with its own interface, login, notification system, and learning curve. For simple, transactional tasks — booking a ride, ordering food, checking a flight status — the current process of opening an app, navigating menus, and tapping buttons is unnecessary friction.

He calls this the shift from app-centric to intent-centric computing.

We agree with this for a specific category of tasks. At Macronimous, we think of it as “command tasks” — one-shot instructions with a clear outcome. “Book me the cheapest Uber.” “Reorder my last Swiggy meal.” “Send this message to my team.” AI can handle these today, and it will only get better.

Where It Breaks Down: Complex Apps Aren’t Going Anywhere

But now think about the apps your business actually depends on.

Open a WooCommerce dashboard. Navigate through orders, filter by status, adjust shipping rules, compare product variations. Open Figma and iterate on a design. Open Lightroom and fine-tune an exposure curve. Open your CRM and work through a pipeline.

These aren’t “commands.” They’re explorations. You don’t always know what you want until the interface shows you the options. The value of these apps isn’t just in completing a task — it’s in the visual decision-making, the iterative control, the ability to browse, compare, and adjust on the fly.

We build these kinds of apps for clients every day. And from that experience, we can tell you: no voice command or AI agent replaces this. Not today. Not for a long time.

So the real picture isn’t “apps die.” It’s: apps become the infrastructure that AI agents operate on top of. The front door to your product is changing, but the engine behind it stays.

The Apple Problem: Why We’re Hesitant to Advise iOS Clients

This is where we need to be transparent about the challenge we’re facing as an agency.

On the Android side, the AI roadmap is clear. Google’s Gemini is embedded at the system level. AI agents can interact across apps, read screens, chain actions, and orchestrate multi-step workflows. Samsung is pushing toward what it calls an “AI OS.” When we approach our Android app clients about adding an AI layer, we can point to a concrete ecosystem, working tools, and a clear direction.

On the iOS side? The picture is far murkier.

Apple announced Apple Intelligence at WWDC 2024 with over 20 AI features. It showcased a personalised, context-aware Siri that could understand your apps, execute multi-step tasks, and act as a true digital agent. The iPhone 16 was marketed heavily on these capabilities.

The problem? Many of the most exciting features never shipped.

The enhanced Siri with personal context awareness and in-app actions was delayed repeatedly. Tim Cook acknowledged in 2025 that it was “taking a bit longer than we thought.” As of March 2026, Apple insists the features are “still on track to launch in 2026,” but reports suggest some capabilities may not arrive until iOS 26.5 (May) or even iOS 27 (September).

The delays were severe enough to trigger multiple class-action lawsuits. Consumers accused Apple of false advertising, arguing they purchased iPhone 16 devices based on AI features that didn’t exist. South Korea’s National Pension Service, the world’s third-largest pension fund, led a shareholder fraud lawsuit. Apple is fighting to dismiss these cases, but the reputational damage is real.

As an agency, this puts us in a difficult position. When a client asks, “Should we add AI capabilities to our iOS app?”, we can’t point to a stable, shipping AI orchestration layer from Apple the way we can with Google’s Gemini on Android. The system-level intelligence that would let Siri chain actions across apps — the kind of experience Carl Pei is describing — simply doesn’t exist on iOS yet.

What IS Available Right Now on iOS — And It’s More Than You Think

That said, it’s not all waiting. Apple has shipped some genuinely useful building blocks that developers can act on today. Here’s what’s on the table:

App Intents: The Foundation You Need to Lay Now

Apple’s App Intents framework is the bridge between your app and Apple Intelligence. It’s how Siri discovers what your app can do, triggers actions, and chains tasks across multiple apps. Think of App Intents as the universal API for the AI era on iOS — if your app doesn’t speak this language, it won’t get discovered.

When the enhanced Siri does finally arrive, it will be able to perform requests like “Find the receipt I got yesterday, crop it, and email it to my accountant” — but only if the apps involved have adopted App Intents. Apps that haven’t will simply be invisible.

Our advice to clients: adopt App Intents now, even before Siri catches up. It already powers Siri Shortcuts and Spotlight integration, and it’s the clear direction Apple is heading. Building this foundation today means you’re ready when the AI orchestration layer ships — whenever that may be.

Foundation Models Framework: Free, On-Device AI

With iOS 26, Apple released the Foundation Models framework, giving developers direct access to the on-device large language model. With as few as three lines of Swift code, you can integrate text extraction, summarisation, guided generation, and tool calling — all running locally, offline-capable, and at zero inference cost.

This is already being used in production. Apps like CellWalk generate conversational explanations of scientific terms. Grammo built an AI grammar tutor that creates exercises on the fly. Signeasy uses it to summarise contracts and answer document-specific questions.

This is the part that excites us at Macronimous. It’s available now, it’s free, and it’s genuinely useful for a wide range of app types. If your app involves any kind of text processing, search, content summarisation, or contextual suggestions, this framework is worth exploring immediately.

Third-Party AI APIs: Don’t Wait for Apple

Here’s something important that often gets lost in the Apple-centric conversation: nothing stops you from building AI capabilities inside your iOS app today using third-party APIs.

OpenAI’s GPT models, Google’s Gemini, Anthropic’s Claude — these are all accessible via standard API calls from within any iOS app. You can add smart search, natural language queries, personalised recommendations, conversational interfaces, or AI-powered workflows without waiting for Apple to ship a single thing.

This is the approach we’re most likely to recommend to our iOS clients in the near term. It sidesteps Apple’s uncertainty entirely. You control the AI layer, you choose the model, and you ship on your own timeline.

The Honest Dilemma: What We’re Telling Our Clients

When our clients ask about AI today, here’s the honest conversation we’re having:

A Practical Checklist: Preparing Your App for the AI Layer

Whether you’re building a new app or maintaining an existing one, here’s what we recommend prioritising based on our own evaluation:

1. Adopt App Intents now. Map your app’s core actions — what can a user do? What data can be surfaced? Make these intents discoverable by Siri, Spotlight, and Shortcuts. This is non-negotiable for iOS apps going forward.
2. Explore the Foundation Models framework. If your app involves text processing, search, summarisation, or contextual suggestions, Apple’s on-device LLM is free and ready to use today.
3. Build API-first architecture. If an AI agent can’t “read” your app, your app won’t exist in the coming ecosystem. Expose your data and actions through well-structured APIs.
4. Map your user flows into two buckets. Identify which workflows are “command tasks” (automatable by AI) vs. “exploration tasks” (where your UI is the product). Invest heavily in the latter — that’s your moat.
5. Integrate third-party AI APIs for immediate wins. OpenAI, Gemini, and Claude APIs are available now. Add smart search, natural language queries, or conversational interfaces without waiting for Apple.
6. Test the AI experience on both platforms. If you’re cross-platform, understand that Android’s AI integration is meaningfully ahead. Don’t assume feature parity.
7. Watch WWDC 2026 closely. Apple’s developer conference will likely focus heavily on AI — expanded Foundation Models, more powerful App Intents, and potentially the long-awaited Siri overhaul. Be ready to move fast when it lands.

The Bigger Picture: Why We’re Writing This

We could have kept this analysis internal. Most agencies do. But we’ve been in this industry long enough to know that the developers and app owners who thrive through transitions are the ones who see them coming early.

In 2007, the iPhone changed how people interacted with software. In 2008, the App Store created an entirely new economy. We were there for both of those shifts, building through them.

What’s happening now feels like a similar inflection point — not as dramatic as “apps are dead,” but a real structural change in how users will interact with your product. The interface is no longer the only way in. AI agents, voice assistants, and system-level intelligence are becoming new front doors to your services.

The apps that survive this transition will be the ones that AI can work with, not around. And the developers who start preparing now — even amid Apple’s uncertainty — will be the ones best positioned when the pieces finally fall into place.

We’re preparing. We think you should be to

The post AI Layer for iOS Apps: What Developers Need to Know in 2026 | Macronimous first appeared on Macronimous Blog.