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.

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.

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 word “RAG” is doing too much work in client conversations

Most of the confusion comes from collapsing three separate things into one word. A website is a corpus — raw source content. RAG is a pipeline that runs over a corpus, the architecture introduced by Lewis et al. in 2020. And the thing where “ChatGPT already knows about my site” is a third mechanism entirely. If you’re a developer fielding the “should we build a RAG?” question from a client or a founder, the first job is to pull those three apart. They behave differently, you control them differently, and only one of them is something you actually build.

Your website is the food, not the kitchen

A site is input. RAG is the machine that eats it. Saying “our website is already a RAG” is like saying a pantry is already a meal. The pages are content; retrieval-augmented generation is the chunk-embed-retrieve-generate loop that turns content into grounded, cited answers on demand. No loop, no RAG — just files on a server.

Three ways an LLM touches your content — only one is yours

This is the table I wish more people saw before greenlighting a build. The difference between these rows is who owns the pipeline.

The middle row is the one people mistake for RAG. It is retrieval-augmented generation — but it’s the engine’s pipeline, not yours. You shape it through answer engine optimization, clean structure, and machine-readable markup. You don’t own a single line of it. Treating AEO and “build a RAG” as the same project is how budgets get wasted.

The question RAG actually answers

RAG earns its place when your knowledge base is bigger than the context window. That’s the whole reason the architecture exists. You can’t paste a thousand support articles into a prompt, so you retrieve the handful that matter and pass only those. Retrieval is a workaround for a size constraint.

Which means the real design question is never “should we use RAG?” It’s “is my content bigger than the window?” A modern model comfortably holds 200K tokens — roughly a 150-page book. If your entire corpus fits inside that, retrieval is solving a problem you don’t have.

For a small site, context-stuffing wins

If a client wants a chatbot for a fifty-page brochure site, the correct architecture is not RAG — it’s context-stuffing. Put the full content in the system prompt and let the model answer over all of it, every time. Compare the two honestly:

Building a vector pipeline over fifty pages is engineering theater. It looks sophisticated and buys you nothing but a database to babysit. The instinct to reach for RAG by default is the same instinct that over-engineers a CMS for a five-page site — resist it the same way you’d resist any premature abstraction, the way you’d approach controlled AI coding rather than letting the tool decide the architecture.

When RAG is genuinely the right call

It flips the moment volume shows up. Build RAG when:

• The corpus is large enough that it can’t fit in one context window — hundreds of documents, long PDFs, sprawling FAQs.
• Content changes often and answers must reflect the current version, not a snapshot frozen in a prompt.
• You need citations back to source — the chunk that produced the answer is the receipt.
• You’re multi-tenant and each client’s data must stay walled off from every other client’s.
• Cost matters at scale — sending only the retrieved slice is cheaper per query than stuffing everything.

That last cluster is where most real product work lives. A managed chat service across many client sites, a support assistant over a deep documentation set, an internal tool over years of project files — those have the corpus that justifies the pipeline. Your own small marketing site almost never does.

What to actually do for a site like yours

For the agency’s own site, the answer is: don’t build a RAG. Point your effort at the live-search loop you don’t own — structure, schema, and clean answer blocks so the engines that fetch your pages can extract them. That’s the same discipline as JavaScript SEO and schema markup, extended to AI readers. Reserve real RAG builds for the client products where content volume is genuine and you can charge for the custom development work.

One honest exception: if your blog grows into hundreds of posts and you want an “ask our blog” assistant with citations, a lightweight RAG over the blog archive — not the whole site — starts to make sense. Even then, go hybrid: full context for the handful of core service pages, retrieval only for the long tail. And whatever you build, keep the codebase legible — RAG glue is exactly the kind of code that rots fast if you don’t write clean code with AI from the start.

You probably don’t need one, and here’s the tell

Most agency and small-business sites fall on the skip side. You can decide in under a minute. Skip RAG if any of these are true:

• Your whole site fits in a single context window: a few dozen pages, a handful of PDFs.
• The content is stable. It doesn’t change weekly, so a snapshot in the prompt won’t go stale fast.
• You don’t need per-answer citations back to a specific source chunk.
• It’s single-tenant: one brand, one body of content, no data-isolation requirement.
• A chatbot here is a nice-to-have, not the product itself.

Macronimous is the textbook skip. Fifty-odd pages, stable content, one brand, no citation requirement. Stuffing the full content into the system prompt is more accurate and zero-maintenance next to a vector pipeline. If your client looks like that, the honest answer is “you don’t need RAG, and here’s the cheaper thing that works.”

Where to start if you actually do

When the corpus is genuinely too big, you have two roads: a framework that hides the plumbing (LlamaIndex, LangChain), or rolling the four steps yourself. For a first real build, roll it. You’ll understand every failure mode, and the whole thing is smaller than it looks.

1. Use the store you already run. If you’re on Supabase, pgvector is right there, no new vendor. Pinecone or Qdrant are fine for a dedicated store, but don’t add infrastructure you don’t need on day one.
2. Chunk deliberately. Split content into roughly 500 to 800 token pieces with a little overlap, on real boundaries like headings and sections, not blind character counts. Bad chunking is the top reason RAG answers come out vague.
3. Embed and store. Run each chunk through an embeddings model (OpenAI text-embedding-3-small is cheap and good enough to start) and store the vector next to the source text and a link back to the page.
4. Retrieve, then generate. On a query, embed the question, pull the top few chunks by similarity, and pass only those into the model with an instruction to answer from them and cite the source. That’s the whole loop.

Build it over one real content set end to end before you generalize. The wiring is easy. The hard part is chunking quality and retrieval tuning, and you only learn those by watching real answers and fixing what retrieval missed. Treat version one as a measurement tool, not a finished product.

The short version for your next standup

RAG is a size workaround, not a magic AI feature. Your website is a corpus, not a pipeline. The “LLMs already learned my site” effect is unreliable and not yours to control — AEO is how you influence the part you can. Build RAG when the content is too big for the window and you need it current and cited. For everything smaller, stuff the context and move on. Knowing which problem you have is most of the job, and it’s the same judgment that runs through any sound SEO strategy for 2026.

The post RAG for Web Developers: When to Build It and When Not To first appeared on Macronimous Blog.

EmDash vs WordPress: Is Cloudflare’s CMS a True Successor?

A Technical and Agency Risk Assessment

Your agency just recommended a new platform. They called it modern, secure, and AI-native. They said it’s the spiritual successor to WordPress. The platform is Cloudflare’s EmDash, and this is the pitch you’ll hear at every tech conference this year.

Before you sign off, there are things worth examining.

At Macronimous, we’ve navigated every major web platform evolution since 2002. We’ve seen Joomla peak and fade, watched Wix and Squarespace mature, evaluated Webflow’s rise, and stress-tested AI site builders like Figma Sites and Lovable. The pattern is always the same: architectural change is presented as automatic progress. It isn’t.

EmDash is not a WordPress replacement. It is a pivot into a fundamentally different—and restrictive—model. It is serverless, edge-first, and tightly coupled to a single vendor’s ecosystem. For anyone responsible for a business’s long-term digital ROI, that distinction is everything.

1. The Technical Pivot: V8 Isolates vs. The Hook System

The core argument for EmDash is security. Let’s examine what that security actually costs.

• WordPress: Plugins operate with full access to the database and filesystem. This creates infinite flexibility but a massive surface area for risk.
• EmDash: Plugins run inside V8 isolates with a capability-based permission model. Nothing is accessible unless explicitly granted.

The V8 isolate model does solve the “rogue plugin” problem. But it introduces significant developer friction. In WordPress, extending behaviour is a simple add_action hook—a few lines of PHP and you’re done. In EmDash, you are designing interaction contracts. You must define permissions upfront, manage isolated execution contexts, and pass structured data across rigid boundaries. Even a simple feature—adding a custom field to a contact form, say—requires navigating this permission architecture.

The Verdict: You trade open extensibility for controlled execution. The runtime is safer, but development cycles slow down and the cognitive load increases for even the simplest customisations. For agencies billing by the hour, that friction becomes a direct cost to the client.

2. The State Problem: Edge-Native vs. ACID Compliance

EmDash runs entirely on Cloudflare Workers, eliminating the traditional origin server.

• WordPress Model: PHP + MySQL at the origin, optimised with Redis caching and CDN delivery.
• EmDash Model: Code runs at the edge; data lives in D1, Cloudflare’s SQLite-based distributed database.

For static marketing sites, this is lightning fast. Pages load from the nearest edge node with minimal latency. But for anything involving complex data relationships, the edge is a liability.

Consider a real scenario: an E-commerce site processing concurrent orders during a flash sale. Two customers attempt to purchase the last unit of a product at the same time, hitting different edge nodes. With MySQL’s ACID compliance, one transaction succeeds and the other fails cleanly. With D1’s eventual consistency model, both nodes may report the item as available. The result is an oversold product, a customer service headache, and a bug that is nearly impossible to reproduce in testing because it depends on network timing between edge nodes.

The same risk applies to multi-role dashboards, user progress tracking in EdTech platforms, and any application where two users can modify the same record.

The Verdict: You aren’t eliminating infrastructure complexity; you’re trading server complexity for data consistency risks. For static sites, the trade-off is favourable. For transactional applications, it’s dangerous.

3. The “AI-Native” Claim: Marketing Differentiator or Technical Necessity?

EmDash leans heavily on being “AI-native” via the Model Context Protocol (MCP). This deserves a more careful look than the marketing copy provides.

MCP is a genuinely interesting protocol. We use it ourselves in our internal workflows for connecting AI tools to live data sources. But the question isn’t whether MCP has value—it does—it’s whether you need to switch your entire CMS to get it.

You don’t. WordPress already provides structured data through its REST API and WP-GraphQL. Any AI tool that can consume an API can already work with a WordPress site. MCP integration can be layered on top of an existing WordPress installation without replacing the foundation. Switching your entire backend for a native AI protocol is like rebuilding your house because you want a better thermostat.

There is also what we call the AI Builder Paradox. We’ve tested this extensively with platforms like Figma Sites and Lovable. AI is excellent at generating standard layouts: hero sections, feature grids, and testimonial carousels. The output looks polished in a demo. But the moment a client requires unique business logic—a custom pricing calculator that pulls from a third-party API, a booking flow with conditional availability rules, a member portal with role-based access—the AI hits a wall. It generates the skeleton but cannot reason about the business rules.

We’ve seen AI-generated sites ship with hardcoded sample data in production, with forms that submit to nowhere, and with responsive layouts that collapse on tablet viewports. These are not edge cases; they are the norm once you move beyond template-grade output.

The Verdict: MCP is a useful protocol, not a reason to change platforms. AI-native is a marketing differentiator, not a technical necessity. The real question is whether your CMS gives AI tools clean data to work with—and WordPress already does.

4. SEO Reality: Guardrails vs. Open Air

This is where the risk becomes most tangible for business owners.

WordPress has a mature SEO ecosystem. Plugins like Yoast and RankMath handle canonical tags, XML sitemaps, Open Graph metadata, schema markup, and crawl directives automatically. Misconfigure something, and these tools flag it before it reaches production. The safety net is deep and well-tested across millions of sites.

EmDash, built on Astro, has no such safety net. SEO implementation is entirely manual and written in TypeScript.

Here’s what an invisible failure looks like in practice: a developer deploys an Astro page with server-side rendering (SSR) but introduces a hydration mismatch. The page looks fine in a browser. But Google’s crawler sees the server-rendered version, which may be missing the canonical tag, the structured data, or even the primary heading. Over the following weeks, the page silently drops in rankings. By the time it shows up in Search Console as a coverage issue, you’ve already lost weeks of organic traffic.

Or consider a simpler scenario: a missing canonical tag on a paginated archive. In WordPress with Yoast, this is handled automatically. In EmDash, it’s a line of TypeScript that someone has to remember to write, test, and maintain across every template. Forget it once, and you’ve created a duplicate content problem that dilutes your domain authority.

The Verdict: WordPress gives you guardrails. EmDash gives you open air. For an agency managing SEO across multiple client sites, the risk of invisible, silent failure is not theoretical—it’s operational.

Beyond the technical architecture, there are practical realities that affect your budget, your team, and your long-term ownership of your digital assets.

The Pioneer Tax: When an agency recommends an unproven, niche platform like EmDash, your project budget often stops funding your business goals and starts funding the agency’s Research and Development. Because EmDash lacks a mature marketplace, standard features—contact forms, SEO tools, analytics integration—must be custom-engineered from scratch. You are effectively paying for a developer’s learning curve and the creation of basic infrastructure that already exists off-the-shelf in the WordPress ecosystem.

• Predictable Rent vs. Algorithmic Billing: WordPress has a predictable total cost of ownership, often with a fixed monthly hosting fee. EmDash uses usage-based billing where you pay for “CPU time”—every request and edge computation is metered. A traffic spike that WordPress handles with a simple caching plugin becomes an unpredictable, volatile invoice on the Cloudflare stack.
• The Talent Problem: WordPress has a global developer talent pool. If your lead developer leaves, you can find a replacement. EmDash requires a niche combination of TypeScript, Astro, and Cloudflare Workers expertise. If your key developer moves on, the client isn’t just losing a team member—they are potentially stranded on a platform that very few people know how to maintain.
• The Ownership Trap: This is the most critical issue. WordPress is protected by the GPL—a license that guarantees the user’s rights to own, move, and modify their code. EmDash uses the MIT license for its source code, but the runtime is proprietary to Cloudflare. If you decide to leave Cloudflare due to pricing changes or service issues, you don’t migrate; you rewrite. Recommending this level of vendor lock-in without disclosure is a fundamental breach of trust regarding digital asset ownership.

6. The Macronimous Stance: Technical Curators, Not Just Builders

The “No-Code” and “AI-Native” era hasn’t eliminated the need for professional guidance. It has changed our job description.

We are no longer just builders. We are Technical Curators. Our role is to evaluate every new platform, protocol, and tool—and to make an honest recommendation based on what actually serves the client’s long-term interests. Not what generates the most exciting demo. Not what looks best in a pitch deck. What works, what lasts, and what you’ll actually own five years from now.

We believe in a hybrid future where AI strengthens the open web—acting as a security auditor, a content assistant, and a development accelerator within established ecosystems—rather than a corporate future where the web is locked behind a single vendor’s sandbox.

We test everything so our clients don’t have to. Right now, that means we are:

• Benchmarking D1’s consistency under write-heavy, concurrent scenarios to understand its real-world limits.
• Monitoring the EmDash community for genuine, non-corporate contributions.
• Mapping exit strategies to quantify the true cost of migrating away from the Cloudflare stack.

Until a platform demonstrates the maturity, the ecosystem depth, and the ownership guarantees that WordPress provides, our recommendation remains clear.

WordPress remains the industry’s operating system.

It balances flexibility, stability, and—most importantly—ownership. We build for the next decade. Not the next trend.

The post EmDash vs WordPress 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.

Upgrade Laravel Application

Stability can be deceptive in software development. If your Laravel application is running smoothly in production, the incentive to touch the codebase is usually low. However, the ecosystem around your application—specifically PHP versions, security patches, and Composer dependencies—is constantly evolving.

Staying on Laravel 8, 9, or even 10 might feel “stable,” but it introduces silent risks. You aren’t just missing out on features; you are accumulating technical debt. With Laravel 12 pushing the standard to PHP 8.2+, the gap between your current version and modern security standards is widening.

Here is a practical look at why upgrading to the latest stable version is a necessary maintenance step to keep your infrastructure healthy.

The Lifecycle Reality: Why Versions Matter

Laravel releases a major version annually to keep pace with backend technologies. Understanding the support lifecycle is critical for long-term planning.

Here is the current support status:

The Risk: If your application runs on Laravel 8 or below, you are operating without security patches. If you are on Laravel 9, you have a very short window before official support ends.

Key Technical Benefits of Upgrading

1. Security and Compliance (The Non-Negotiable)

Legacy frameworks often rely on older hashing algorithms and session handling methods that modern security standards have surpassed.

• The Impact: New releases patch specific vulnerabilities found in the framework core. Upgrading ensures your application meets current compliance requirements for data handling and payment processing.

2. Performance Optimization

Laravel continuously refactors its core to reduce overhead.

• Routing & Caching: Recent versions have significantly optimized the route registration and container resolution processes.
• PHP 8.2+ Support: Laravel 12 runs on PHP 8.2+. This version of PHP offers JIT compilation improvements and better memory management compared to PHP 7.4 or 8.0.
• Result: For high-traffic applications or API-heavy backends, this translates to lower latency and reduced server resource consumption.

3. Reducing Maintenance Costs (Technical Debt)

The longer you wait to upgrade, the harder it becomes. Skipping from Laravel 8 directly to 12 is a painful, complex migration that often requires rewriting large chunks of code due to “breaking changes” accumulated over four years.

• The Strategy: Incremental upgrades are predictable and low-risk. Delayed upgrades often turn into expensive “rescue projects.”

4. Developer Experience & Modern Tooling

Upgrading allows your development team to utilize modern architectural patterns, making the codebase easier to maintain.

• Laravel 12 Features: Includes cleaner API structures, improved job queue handling, and native support for modern frontend stacks (React/Vue).
• AuthKit: simplifies complex authentication flows like SSO and Passkeys, which are becoming standard user expectations.

When is an Upgrade Urgent?

You should prioritize this migration if:

• Hosting Compatibility: Your hosting provider is deprecating older PHP versions (many are dropping PHP 8.0 support).
• Dependency Hell: You cannot install new packages because they require a newer version of illuminate/support.
• New Feature Development: You are planning a sprint for new features. Building new code on top of a legacy framework is inefficient.

The Upgrade Strategy

We don’t recommend “blind upgrades.” At Macronimous, we treat upgrades as a structured engineering process:

1. Dependency Audit: We analyze composer.json to identify packages that have been abandoned or need replacement.
2. Phased Migration: We step through versions sequentially (e.g., v9 ? v10 ? v11) to isolate breaking changes.
3. Automated & Manual Testing: We run your test suite (Unit/Feature tests) and perform manual regression testing on critical flows.
4. Performance Benchmarking: We compare response times before and after deployment to ensure the upgrade delivered the expected speed gains.

Conclusion

Upgrading Laravel is not about chasing the “shiny new thing.” It is about infrastructure integrity. It ensures your application remains secure, fast, and compatible with the modern web.

At the outset, it may look like too much work—especially when your current site is running fine. But trust me, it is worth it.

If your application is running on a version older than Laravel 10, now is the time to plan your migration path.

Need a technical assessment of your current stack? Contact us to discuss a migration plan that minimizes downtime.

The post Upgrade Laravel Application: A Laravel 12 Migration Guide for Application Owners first appeared on Macronimous Blog.

Agile in the Age of Vibe Coding: What Changes, What Stays?

Introduction: Agile Beyond Buzzwords

For more than two decades, Agile has been the driving philosophy behind modern software development. It’s more than a collection of buzzwords or project management tools; it’s a mindset focused on delivering value through small cycles, fast feedback, and a deep commitment to adaptability. Agile taught us to stop building in rigid, monolithic phases and start collaborating in dynamic, iterative loops.

Now, a new paradigm is capturing the industry’s attention: “vibe coding.” Developers are increasingly experimenting with AI pair programmers like GitHub Copilot and Cursor, which can generate vast chunks of code from simple, descriptive prompts. The speed is intoxicating, and the potential is immense. This rapid evolution raises a critical question for development teams everywhere: Does Agile still matter in an era where code can be generated almost instantly?

The answer is a resounding yes. In fact, it may matter more than ever.

Agile at Its Core: Direction Over Tools

To understand why Agile remains relevant, we must remember what it has always been about. Agile was never concerned with how developers type code. Its focus has always been on the bigger picture:

• Delivering Value in Short Iterations: Consistently shipping working software allows for real-world feedback.
• Embracing Change: Staying flexible when requirements or market conditions shift is a core strength.
• Customer Collaboration: Keeping clients and stakeholders involved throughout the process ensures the final product solves the right problem.
• Continuous Improvement: Using feedback to constantly refine both the product and the process.

Whether a developer writes every line of code by hand or collaborates with an AI to generate it, these principles remain the compass for any successful project. AI changes the speed of the engine, but Agile is what steers the ship.

What Vibe Coding Brings to the Table

“Vibe coding” aptly describes the intuitive, prompt-driven style of development where AI assistants handle much of the boilerplate and implementation details. Instead of manually constructing every function, a developer describes their intent, and the AI produces a functional starting point. This introduces powerful new dynamics for Agile teams.

1. Shorter, More Intense Cycles

With AI assistance, functional prototypes and features can be produced in hours, not days or weeks. This allows Agile sprints to shrink into micro-iterations, enabling even faster feedback. The challenge shifts from development speed to the speed of decision-making. Can product owners and stakeholders provide feedback fast enough to keep up?

2. A Fundamental Shift of Focus

Teams will spend significantly less time wrestling with syntax, boilerplate code, and common algorithms. This frees up invaluable cognitive resources to focus on higher-level challenges: system architecture, user experience design, robust security models, and long-term maintainability. The developer’s role evolves from a pure creator to a strategic curator and integrator.

3. Amplified Pressure on Testing

AI can generate useful code with astonishing speed, but it can also introduce subtle bugs, security flaws, or inefficient logic with equal confidence. This makes Agile’s emphasis on automated testing, continuous integration (CI/CD), and Test-Driven Development (TDD) more critical than ever. A powerful CI/CD pipeline becomes the ultimate safety net, ensuring that AI-generated speed doesn’t come at the cost of quality.

4. The Need for Disciplined Knowledge Sharing

Without clear communication, teams risk creating “AI black box” systems where only the original prompter understands the logic. This is where Agile ceremonies gain renewed importance. Sprint reviews, retrospectives, and even daily stand-ups become essential forums for demystifying the code. Teams must discuss not just what was built, but how the AI was prompted and why its output was accepted, ensuring collective ownership and understanding.

5. Evolving Roles and Responsibilities

As developers become more like editors and architects, the role of the Product Owner becomes even more central. Since building things is faster and cheaper, the real challenge is choosing what to build. A clear vision and a ruthlessly prioritized backlog are paramount, because the cost of building the wrong feature is no longer just wasted time—it’s a massive squandering of opportunity.

A Remote Agency’s Perspective

At Macronimous, Agile isn’t a framework we adopted; it’s been our natural way of working for decades. As a remote-first web development agency, we rely on Agile principles to keep our distributed teams aligned, our clients engaged across different time zones, and our projects delivering value predictably. For us, Agile is the operational rhythm that makes remote collaboration seamless and effective.

That’s why we see vibe coding not as a disruption to Agile, but as a powerful force that Agile can help us harness. While we are still primarily human-coding our solutions in Laravel and other PHP frameworks—as AI-assisted coding is not yet fully mature or consistently reliable in this space—Agile has prepared us for this change. When the right tools stabilize, our Agile foundation will ensure we adopt them responsibly, always balancing speed with the trust and quality our clients expect.

The Verdict: Does Agile Still Matter?

Yes—and its importance is growing. AI provides the raw speed, but Agile provides the essential direction, discipline, and quality control.

• AI accelerates, but Agile steers. Without Agile principles, rapid code generation can quickly devolve into rapid chaos, leading projects far off course.
• Feedback loops protect quality. Agile’s insistence on short cycles and stakeholder validation ensures that what’s being built is frequently checked against real-world needs.
• Structure sustains trust. Agile ceremonies, automated testing, and a focus on working software ensure that projects don’t drift into an uncertain state of unverified, AI-generated code.

Agile is the compass; vibe coding is the engine. You need both to reach the right destination efficiently and safely.

Conclusion: The Future Is Agile-Plus

The real question isn’t whether Agile can survive the age of AI coding, but how it will evolve to guide it. At Macronimous, we see Agile as the enduring foundation and AI as a promising accelerator that will augment, not replace, human expertise.

For remote teams and forward-thinking agencies, the future of web development isn’t “Agile versus AI.” It is Agile-plus—a powerful synergy where timeless Agile principles combine with the unprecedented speed of AI to deliver better products, faster and more reliably than ever before.

The post Agile in the Age of AI Coding – Lessons for Web Development Teams first appeared on Macronimous Blog.