Last updated: October 23, 2026. This story is still moving, and we’ll revise this post as framework vendors and hosts publish more.

Want it on one page for your team or your host? Download the PHP2Shell checklist (PDF). It has every check and command from this post, with tick boxes.

Every hosting company spent this week sending the same email: update PHP. That’s correct, and it’s also where most of the coverage stops. cPanel shipped patched builds, the security vendors published their notes, and the people who actually maintain the PrestaShop store or the Laravel app were left with a question nobody answered for them. Is the host’s update the end of it?

No. It’s the most important part, but it isn’t the end. A few of the conditions these bugs rely on live in your application’s configuration and code, not in the host’s PHP package, and the host won’t touch them (they can’t, really, because they don’t know your app).

What PHP2Shell actually is

On October 21, 2026, the PHP project released 8.2.35, 8.3.36, 8.4.27 and 8.5.12 to fix two bugs rated Critical, with a CVSS (Common Vulnerability Scoring System) v4.0 score of 9.2. Both allow remote code execution, which means an attacker can make your server run their commands.

The first, CVE-2026-109618, is about running out of memory at a bad moment. If PHP hits its memory limit while it’s still setting up a request, it leaves half-built data behind, and the shutdown code later trusts that data. On Apache mod_php this all happens before your application code runs at all.

The second, CVE-2026-109619, is about state leaking between requests. Something from one request survives on the worker after its memory is freed, and the next request on that same worker uses it. That second request can be triggered by something as mundane as a PHP warning from a deprecated setting.

The timing made this worse than usual. According to Sansec’s timeline, details leaked on October 20, and Cloudflare saw early attacks the next morning, hours before the fixed versions were out. The vulnerable code goes back to PHP 5.4.0, released in 2012, so nearly every PHP site you’ve ever worked on was in scope.

Why your framework update won’t fix it

This is the part clients get wrong, and honestly some developers too. The bugs are in the PHP engine. PrestaShop, Magento and Laravel all run on top of that engine, so a composer update or a new module version changes nothing here. Sansec put it plainly for eCommerce: Magento stores are affected even when their own code is clean.

As of today, we haven’t found an advisory from PrestaShop, Adobe or the Laravel team about these CVEs. So the stack-specific notes further down are our own practitioner guidance, not quotes from the vendors. If that changes, we’ll update this post and say so.

The app-side checklist, step by step

These steps assume you have SSH (Secure Shell, the remote terminal) access to the server or at least to the site’s files. Paths in uppercase are placeholders. Replace SITE_ROOT with your site’s document root, for example /home/USER/public_html on cPanel hosting.

Step 1: Confirm the patched PHP is really running

The version number alone can mislead you. cPanel backported the fix into older branches (ea-php74 through ea-php81), so a server that still reports PHP 8.1 may already be patched. Upstream PHP has no fix for 8.1 and older, which is why the changelog matters more than the number. On a cPanel server running RHEL or AlmaLinux, run this, replacing php81 with the version the site uses:

rpm -q --changelog ea-php81-php-cli | grep -m1 CVE-2026-109618

If it prints a changelog line that mentions CVE-2026-109618, that PHP build has the fix. If it prints nothing, the build isn’t patched yet. For PHP older than 7.4, cPanel points to TuxCare ELS (Extended Lifecycle Support), a paid service that keeps backporting security fixes.

Step 2: Find out which SAPI serves the site

The SAPI (Server API) is the way PHP connects to the web server, and it changes your risk a lot. Apache mod_php is the worst case, because both bugs were proven against it with default settings. PHP-FPM (FastCGI Process Manager) is harder to attack, but one confirmed attack path works against it too, so don’t treat it as safe. Create a temporary file in the site root with this content:

<?php echo PHP_VERSION . ' ' . PHP_SAPI;

Open it in a browser. You’ll see something like 8.3.36 fpm-fcgi or 8.1.34 apache2handler. The second word is the SAPI, and apache2handler means mod_php. Use a random file name, and delete the file the moment you’ve read it.

The command line can report a different PHP from the one serving web requests, which is why this check goes through the browser and not php -v. (On shared hosts, those two disagree more often than you’d think.)

Step 3: Clean up per-directory PHP settings

This is the step only your team can do, and it’s the one I’d put first if I could only pick one. On mod_php, any php_value or php_flag line in an .htaccess file is applied before the request starts. If that value is deprecated or invalid, PHP raises a warning at that early stage, and the second bug uses exactly that kind of early warning. Hiding the warning doesn’t help, because the advisory says the damage happens before PHP decides whether to display or log it. List every such line in the site:

grep -rn --include=.htaccess -E "php_(value|flag|admin_value|admin_flag)" SITE_ROOT

Remove the obsolete ones and move the rest into php.ini or the FPM pool configuration. The advisory names these as typical offenders:

• The mbstring encoding settings mbstring.internal_encoding, mbstring.http_input and mbstring.http_output are a problem whenever they’re set explicitly.
• The iconv settings iconv.input_encoding, iconv.output_encoding and iconv.internal_encoding are a problem in the same way.
• The setting auto_detect_line_endings=1 raises a deprecation warning on current PHP.
• Malformed values such as a memory_limit written with a typo raise warnings on PHP 8.2 and later.

On nginx with PHP-FPM, the same risk applies when the server passes PHP_VALUE or PHP_ADMIN_VALUE to PHP. Check the nginx configuration too:

grep -rn -E "PHP_VALUE|PHP_ADMIN_VALUE" /etc/nginx/

Step 4: Turn off session upload progress

Session upload progress is a PHP feature that reports how far a file upload has got. It’s on by default, almost nothing uses it, and it’s the path behind one of the confirmed attacks on both mod_php and FPM. PHP’s own advisory suggests keeping it off even after you patch, because attackers will keep poking at it. Check whether your code uses it first:

grep -rn "upload_progress" SITE_ROOT --include=*.php

If that finds nothing outside vendor libraries, add this line to php.ini or the FPM pool configuration:

session.upload_progress.enabled = 0

Restart PHP so every worker picks it up. On a typical Ubuntu server with PHP 8.3, the command is below; on cPanel, restart PHP-FPM from WHM instead.

sudo systemctl restart php8.3-fpm

Step 5: Hunt the fatal errors an attacker can trigger

The second bug needs a request to die halfway through something, and a fatal error is how that happens. Out-of-memory is the obvious one, but the advisory also counts uncaught errors, failed require calls and “Maximum execution time exceeded.” It specifically asks teams to look at upload, import, error page, shutdown, destructor, serialization and extension paths, not just the pages you browse every day. Pull the most frequent fatals from the PHP error log:

grep -oE "PHP Fatal error: .{0,120}" SITE_ROOT/error_log | sort | uniq -c | sort -rn | head -30

Any fatal that an outside visitor can cause on purpose (a huge CSV import, an oversized image, a malformed upload) is worth fixing now, patch or no patch. A clean log isn’t proof, though. Old logs often skipped deprecation notices, and a log only covers the routes people actually hit.

Step 6: Stop oversized requests before PHP sees them

The first bug’s memory exhaustion tricks rely on multipart requests (the format forms use to send files) that look small but expand inside PHP. Keep post_max_size conservative, lower max_input_nesting_level, and set sensible caps on max_input_vars and max_file_uploads. Better still, if a route never accepts file uploads, refuse multipart requests at the web server. On nginx, for a JSON-only API path:

location /api/ {
    if ($http_content_type ~* "multipart/form-data") {
        return 415;
    }
    try_files $uri $uri/ /index.php?$query_string;
}

On Apache 2.4, the same rule looks like this in the virtual host or the root .htaccess:

<If "%{REQUEST_URI} =~ m#^/api/# && %{HTTP:Content-Type} =~ /multipart\/form-data/i">
    Require all denied
</If>

After the change, send a test upload to that route. You should get a 415 or 403 response, and your normal JSON requests should still work.

Step 7: Check for signs of compromise

Exploitation started before the patch existed, and watchTowr lists both CVEs as exploited in the wild. So check, even if your host patched on day one. Start with PHP files that changed since the leak:

find SITE_ROOT -name "*.php" -type f -newermt "2026-10-20"

Your own deployments will show up here too, so compare the list against your Git history. Anything you can’t explain, especially in upload folders or cache folders, needs a closer look. Then search the access logs for the public scanner, which Imunify360 reports sends a User-Agent starting with php2shell-:

grep -i "php2shell-" /var/log/apache2/access.log

A hit means someone scanned you, not that they got in. Also check the admin user list in your store or app for accounts nobody remembers creating. A clean result is reassuring, but I wouldn’t call it proof, and I don’t think anyone honest would.

PrestaShop notes

A lot of PrestaShop stores live on shared cPanel hosting under Apache, which often means mod_php or LiteSpeed’s LSAPI. Those are the more exposed setups, so Steps 2 and 3 matter more here than anywhere else.

Old 1.6 and 1.7 stores tend to carry php_value lines in .htaccess that someone added years ago to make an old module work, and nobody’s looked at them since. Those are exactly what Step 3 is hunting for. The product CSV import and the module upload screen are the places where a big upload can push PHP into memory exhaustion, so put them at the top of your Step 5 list.

The back office needs a high max_input_vars for product and module forms, and that’s fine. Just don’t loosen every other input limit to match it; let the request size limits in Step 6 do their job on the storefront.

And the uncomfortable one: PrestaShop 1.6 stores frequently still run PHP 7.x. Those stores are now relying on a host backport or TuxCare to be patched at all. If that’s you, this is the week to put the upgrade on the calendar, and our PrestaShop development team can plan it with you. If you’re already on 9.x, our post on what changed in PrestaShop 9.x covers the newer architecture.

Magento notes

Magento (Adobe Commerce) stores tend to run with a very high memory_limit, often 2G or more, and it’s a common assumption that this protects them. It doesn’t. The attack works by pushing a request into whatever finite limit is set. A higher limit makes the attacker work a bit harder; it doesn’t remove the condition. PHP’s own temporary workaround is to remove the limit entirely (more on why that’s a bad idea below), which tells you the limit’s size isn’t the point.

Catalog and customer CSV imports, and the admin’s upload paths, belong in Step 5. Stores on older releases have a version problem as well. According to Adobe’s system requirements, the 2.4.4 and 2.4.5 lines were tested on PHP 8.1 only, and PHP 8.1 gets no upstream fix. Those stores depend on the host’s backported build. Our Magento maintenance team can check that for you if you’re not sure which build you’re on.

Laravel and custom PHP notes

Laravel apps that ship as Docker images have a trap of their own. Your host’s PHP update does nothing for a container. Any image built from a php:8.x base before October 21 still has the vulnerable PHP inside it until you rebuild with a fresh base. The "php" line in composer.json doesn’t protect you either; it only checks the version number. Rebuild and pull the new base image explicitly:

docker build --pull --no-cache -t IMAGE_NAME .

Then run Step 2 against the running container to confirm the new version is live. If you use FrankenPHP, note that PHP’s advisory says it likely behaves like mod_php here, so treat it as the higher-risk case. We wrote about FrankenPHP for modern PHP development last year, and this is the first time that choice has carried a security footnote.

JSON-only Laravel APIs are the easiest win in this whole post: block multipart on the API routes (Step 6) and you’ve closed off the request type both bugs lean on. Laravel Excel imports and image processing are the usual memory hogs, so they go on the Step 5 list. If your app is a version or two behind, our Laravel 12 upgrade guide is a reasonable next read, and our Laravel developers can take that work on.

Custom PHP apps, the ones built in-house ten years ago and kept alive since, are where I’d expect the most trouble. They’re the most likely to have stale .htaccess directives and the least likely to have any upload limits at all. If one of them has a custom upload progress bar, that’s the one legitimate user of the feature in Step 4, so test it before you switch the setting off.

If your host hasn’t patched yet

Push the host first. While you wait, PHP’s advisories list a few temporary settings. None of them is a complete fix, and the advisories say so plainly.

session.upload_progress.enabled = 0
fatal_error_backtraces = 0

The second line only exists on PHP 8.5, where it removes the producer behind the strongest confirmed exploit. The advisory also lists memory_limit = -1 as the main stopgap for the first bug, but I’d only use it for a day or two on a server you’re watching closely. It lets a single request eat all the memory on the box, which trades one problem for a different outage. Restart every PHP worker after any change, or the old settings keep running.

Who owns what

The short checklist

• The package changelog on every server shows CVE-2026-109618.
• Every Docker image has been rebuilt on a PHP base released after October 21.
• You know whether each site runs mod_php, FPM, LSAPI or FrankenPHP.
• No .htaccess file or nginx config sets a deprecated or invalid PHP value.
• Session upload progress is off, and PHP has been restarted.
• The top fatal errors in the error log have been reviewed and fixed.
• Routes that never take uploads now refuse multipart requests.
• New PHP files since October 20 match your deployment history.
• The admin user list holds no accounts nobody can explain.

The same list, with the commands, is in the printable PHP2Shell checklist (PDF).

FAQ

Where this leaves you

If you take one thing from this: the host’s patch closes these two bugs, and your team’s cleanup makes the next one in this family harder to use. I’d expect more of them, because researchers now know exactly where to look, and the leak showed how fast attackers move once details are out. That’s not a prediction I can back with a number. It’s just how the last few PHP-wide incidents have gone.

We’ll update this post as PrestaShop, Adobe or the Laravel team publish anything. If you’ve seen something in your own logs that belongs here, tell us and we’ll add it with credit.

The post PHP2Shell: What PHP Developers Must Do After the Host Patches first appeared on Macronimous Blog.

The demo worked. Then somebody had to own it.

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

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

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

What we mean by a spec

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

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

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

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

## Feature: Order-status assistant

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

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

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

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

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

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

Acceptance tests are where “done” gets written down

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

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

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

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

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

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

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

How a spec-driven build runs at Macronimous

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

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

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

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

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

Why the spec is the real cost saver

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

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

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

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

Where vibe coding still wins

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

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

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

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

Vibe coding vs spec-driven development

Is your spec ready? A short checklist

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

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

FAQ

Where that leaves you

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

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

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

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

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

The first trap: judging a CMS by its admin screen

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

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

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

What one real rebuild actually showed us

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

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

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

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

The second trap: pricing the licence and forgetting the people

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

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

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

The third trap: forgetting who writes the code now

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

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

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

AI-generated HTML is a different problem

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

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

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

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

Don’t close the door on WordPress

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

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

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

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

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

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

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

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

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

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

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

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

The app: our own invoicing system

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

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

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

Four things the AI got wrong, or would have

1. The Void button

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

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

2. The April 1 problem

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

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

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

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

3. Two people, one invoice number

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

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

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

4. The bug that was never written

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

And vibe coding security risks?

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

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

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

A vibe coder alone vs. a seasoned developer using AI

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

Will AI replace web developers?

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

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

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

Questions to ask before you hand over a real system

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

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

FAQ

Where that leaves you

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

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

What happened on a Tuesday

On the 8th of September, macronimous.com’s admin went from sluggish to unusable. Opening Pages took long enough to make coffee. By the Wednesday, visitors were getting Cloudflare’s 524 timeout page on the front end, which means Cloudflare reached our server, asked for the page, and gave up waiting after a hundred seconds. The site has been on the same WordPress install since 2015, it has 54 active plugins (we know), and it shares an InMotion account with our blog, which is a second, separate install with 33 plugins of its own.

We’d published Auditra three weeks earlier, a free, read-only MCP server for WordPress that lets an AI client read a site’s plugin inventory, autoload, cron schedule, database tables and known vulnerabilities. So the obvious move was to point it at our own site and see how far it got. This post is the honest version of that: what it found, where it stopped, and what it took to get the rest of the way.

We’ll warn you now, it runs long, because the interesting part is the sequence of wrong turns and not the final fix.

Why is the admin slow when the front end is fine? Where to look, in order

If you’re here because your own admin is crawling and you’d rather skip the story, this is the order we’d check now, having done it the long way.

1. cPanel ? Resource Usage. If CPU and memory are low, faults are zero, and Entry Processes reads 0 while the site is timing out, your PHP workers are running outside your account and you can’t see them. That’s a hosting question, not a plugin question.
2. Bypass Cloudflare. Point the domain at the origin IP in your hosts file and hit the login page with curl. If it hangs direct, Cloudflare is cleared.
3. Hit a bare phpinfo.php. If a one-line PHP file hangs, WordPress is cleared too.
4. Ask the host two things: the PHP-FPM max_children for your pool, and a one-day count of requests to wp-cron.php, 404s, and top user agents.
5. Read the autoload, cron list, and plugin inventory with a read-only audit (Auditra, WP-CLI, or by hand). Fix what’s obviously wrong, but don’t assume it’s the cause.
6. Install Query Monitor, open an admin page, and read the HTTP API Calls tab before anything else. Dead remote calls hide there.

Now the long way.

The 12 MB autoload: a real problem, and the wrong one

The first call was analyze_autoload. Autoloaded options are the rows in wp_options that WordPress pulls out of the database on every single request, admin or not, before a plugin has done anything. A healthy site keeps that under a megabyte. Ours was 12.7 MB across 989 options, and 98% of it was unattributed, which is the tool’s way of saying no active plugin claimed ownership of those rows.

The largest entries were all _transient_string-locator-search-files-N, numbered past 200, at 77 to 90 KB each. String Locator is a search-and-replace plugin we’d used and then deactivated, and it never cleaned up after itself. Every one of those transients had no expiry, and every one of them was autoloaded. We ran one DELETE in phpMyAdmin (206 rows, 0.08 seconds), called analyze_autoload again, and watched the number drop to 730 KB.

The first response from the model that read the audit opened with “Found it.” We’ve left that line in because it was wrong, and because it’s the most useful wrong answer in the whole story. A 12 MB autoload is a genuine defect that costs every request on the site, and fixing it changed nothing we could feel. The admin was exactly as slow afterwards. So the finding was correct and the diagnosis was not, and that distinction is the whole point of a tool that reports facts instead of verdicts.

Where the audit stops

Auditra reads state. It can’t time a request, and it can’t see anything below WordPress. So from here the work moved to things it has no access to: cPanel’s resource graphs, a shell, and the hosting company.

The cPanel numbers made no sense at first. CPU sat at 9 to 15% of the limit, memory under 250 MB of 4 GB, zero faults on every hourly row, and Entry Processes (the count of web requests being handled) at zero while the site was timing out. At one point CPU read 215% with Entry Processes still at zero and six processes total, which is not what a busy website looks like. A ps aux from the cPanel terminal during a hang showed nothing running under our user at all.

To rule out Cloudflare we edited the hosts file on a Mac to point the domain straight at the InMotion IP and ran curl against the origin. The home page came back in 1.4 seconds (a cached file served by WP Fastest Cache from disk, no PHP involved). The login page hung indefinitely. So did phpinfo.php, a one-line file with no WordPress in it. That was the moment the site stopped being the suspect. Nothing in WordPress can make a bare phpinfo() hang.

We read all of that, at the time, as “requests aren’t reaching PHP.” That turned out to be the wrong layer too, and we’ll own it: the requests were inside PHP, in a place we couldn’t see.

Six PHP-FPM workers: the max_children limit on shared hosting

The InMotion engineer (a patient man, by the third hour) found it: the PHP-FPM pool for the account was hitting its max_children limit, and that limit was six. Six PHP processes for a 54-plugin admin, a 33-plugin blog, all their cron jobs, and every bot on the internet. And the number is fixed per plan on shared hosting; it can’t be raised, and there’s no slow log to tell you what’s holding the slots.

In hindsight every odd number fit. The pool runs as a server user outside the cPanel account, which is why ps showed nothing and Entry Processes read zero. The six processes and the 215% CPU on Tuesday were the six workers, all busy. And the front page kept loading because a cached HTML file never asks the pool for anything.

WP-Cron and bot 404s were eating the pool

What was filling six slots all day? The same engineer pulled a day of access logs, and this is where the audit’s cron finding from the first hour turned out to matter after all.

WordPress has no clock. Its scheduled jobs run when a visitor’s page load notices one is due and spawns an extra request to wp-cron.php. With bots hitting the site a few thousand times a day, that’s a few thousand cron spawns, each one taking a worker for a full WordPress boot. Auditra had listed 65 cron events on the main site, one of them (a management connector we’d installed and never used) firing every minute. We’d noted it as “secondary” on day one. It wasn’t secondary. It was a sixth of the pool, permanently.

The 404s were ordinary background noise, scanners probing for install.php and fake plugin paths, no single source worth blocking. The problem was only that each one cost a worker, because a 404 page is never cached.

The last seven seconds

After the cron and bot traffic was dealt with (details below), the admin was still slow, and this is where a read-only audit has nothing left to offer. You need something that times a live request. We installed Query Monitor, opened the Pages list, and read the panel: 13.2 seconds page generation, 569 database queries, and an HTTP API tab that told the rest of the story in four lines.

Simple Job Board, which ran our careers page, was calling its vendor’s add-on marketplace on every admin page load to check for updates. That server was stuck in a redirect loop, so each call ran 2.8 seconds before giving up, and it made the call twice. Five and a half seconds per admin page, holding a worker the whole time, for a marketplace we’d never bought anything from. CrawlWP, an indexing plugin, was trying to refresh a Yandex Webmaster token twice per page and getting a 400 each time, another 1.2 seconds, for a search engine none of our clients use.

We deactivated both. Page generation went from 13.2 seconds to 1.37.

Neither plugin was flagged by anything. Both were up to date, both were actively maintained, both had clean vulnerability records. An inventory tool can’t see that a plugin’s phone-home endpoint died last month. Only a profiler watching the request can, and only when you happen to look.

What we changed

For anyone in the same situation, this is the list, in the order we did it. Most of it is in the wp-config reference and Cloudflare’s cache rules docs if you want the full detail.

• Deleted 206 orphaned String Locator transients (12.7 MB autoload to 730 KB)
• Removed the every-minute management connector, and confirmed via analyze_cron that it left no orphaned events
• define('DISABLE_WP_CRON', true); on both installs, with two cPanel server crons at 5 and 15 minutes replacing 2,800 daily visitor-triggered hits with about 380
• Cloudflare cache rule: 404 responses under /blog/ cached at the edge for an hour, so repeat scans never reach PHP
• Cloudflare WAF rules blocking the two scrapers by user agent, and the usual scanner paths (install.php, xmlrpc.php, .env)
• A physical robots.txt for the blog, because WordPress only serves its virtual one at the domain root
• WP Fastest Cache preload throttled to 4 pages a minute
• 13 inactive plugins deleted, 8 redundant active ones removed, 2 deactivated (down to about 42 active)
• Simple Job Board and CrawlWP deactivated; the careers page became a paragraph of text

Two things we didn’t fix, for the record. The theme depends on Titan Framework, which has an unfixed medium-severity CVE from 2021 and has been closed on wordpress.org for years; replacing it is a theme rework, not a Tuesday job. And the blog’s 33 plugins haven’t been audited yet. If you’ve read our post on technical debt in old WordPress installs, you already know how this goes: you never finish, you just get to the point where the site stops fighting you.

What a read-only WordPress MCP server is actually for

We built Auditra to be read-only on purpose, and we wrote up why in the plugin security post: no write calls, no scores, facts with thresholds next to them, and the reasoning left to whoever (or whatever) reads the output. This week was the first real test of that split on a site we actually cared about, and here’s our verdict.

It did the first hour and the inventory. Autoload, cron, table sizes, the plugin list with vulnerability flags and content usage, all in a few calls, with none of the clicking through fifty settings screens that a plugin cleanup usually means. And it did the verification: after every change, one call confirmed the cron flag was set, the connector was gone, the server cron had fired. That’s the part people underrate. Knowing a fix took is worth as much as the fix.

It could not diagnose a live hang, and we don’t think a read-only tool should pretend to. That took cPanel graphs, a hosts-file bypass, the host’s view of a pool we couldn’t see, and a profiler timing a real request. Four tools, none of them the audit. If we’d sold Auditra as “finds your performance problem,” it would have failed this week, publicly, on our own site.

So the pitch we’d make to another senior WordPress developer is smaller than the one we started with, and we think it’s the right one. Every site you inherit has a history you can’t see from the admin. A read-only audit reads that history in a minute, in a form an AI client can reason over, and tells you what to rule out first. Ruling out is where the hours go on a bad day. It won’t tell you the pool has six workers. But it’ll get you to the question a lot faster, and it’ll confirm you fixed what you think you fixed.

That’s what we found on our own site. We’d be curious what a ten-year-old install of yours turns up, and if Auditra tells you something you didn’t know, or misses something it should have caught, the comments are open and we’ll add it with credit.

The post Our WordPress Admin Took 13 Seconds a Page. Here’s the Audit. first appeared on Macronimous Blog.

A white screen right after a plugin update is almost always that plugin throwing a PHP fatal error. The fix is to deactivate it without going through wp-admin (which you can’t reach anyway): click the recovery mode link WordPress emailed you, or rename the plugin’s folder over FTP. The site comes back. Then you decide what to do about the plugin.

So your site is a blank white page, wp-admin is a blank white page too, and the last thing you did was click Update on a plugin. I’m going to assume that’s you, because that’s who searches for this. You did not break anything permanent, and this is roughly a ten-minute job if you have hosting-panel or FTP access (or can get it from whoever set the site up).

Make sure it’s actually the plugin

It usually is. But “usually” has cost people an afternoon, so spend two minutes checking.

Look in the site admin’s inbox for an email from WordPress with a subject like “Your Site is Experiencing a Technical Issue.” WordPress has sent these since version 5.2 (that’s 2019, so unless your site is a museum piece, you have it). The email names the plugin that failed and includes a special login link. If it names the plugin you just updated, you’re done diagnosing. Skip to the fix.

No email? Check spam, then check the hosting error log. cPanel calls it “Errors”; on Hostinger it’s under the site’s PHP settings; on InMotion it’s a file called error_log sitting in your site root or in wp-admin. You’re looking for a line that starts with PHP Fatal error and contains a path with /wp-content/plugins/ in it. The folder name after that is your culprit.

If the log points at /wp-content/themes/ instead, it’s the theme (same fix, rename the theme folder). If it says “Allowed memory size exhausted,” the update tipped a tight PHP memory limit over the edge, and raising it in wp-config.php fixes that. Those are the other two suspects. This post is about the plugin case, which is by far the most common as far as I can tell from the tickets that reach us.

The fix, three ways, easiest first

Pick the first one you can do. You don’t need all three.

Way 1: the recovery mode link

This is the one WordPress built for exactly this situation, and almost nobody uses it, which I think is because the email goes to whatever address was typed into Settings, General back when the site was built, which was often the developer’s address, or a mailbox that was created for the launch and never opened again, so the link sits there unread while the owner is on a forum reading about FTP.

• Find the “technical issue” email and click the recovery mode link. It’s valid for 24 hours by default, so don’t sit on it.
• Log in as normal. You’ll see a “Recovery Mode Initialized” notice, and the broken plugin will be listed as paused.
• Go to Plugins, deactivate the paused one, then click “Exit Recovery Mode” in the admin bar.

The WordPress.org recovery mode page has screenshots if the admin screen looks unfamiliar.

Way 2: rename the plugin folder

No email, or the link expired. This is what I’d do anyway; it takes a minute and it’s hard to get wrong.

• Open your hosting file manager (cPanel, hPanel, whatever your host calls it) or connect with an FTP client like FileZilla.
• Go to wp-content/plugins/ and find the folder named after the plugin. It’s usually obvious: woocommerce, elementor, wordfence.
• Rename it. Add -off to the end, so elementor becomes elementor-off. Reload the site.

WordPress can’t find the plugin’s main file anymore, so it quietly deactivates it and carries on. Your site is back. Once you’ve sorted the plugin out, rename the folder back and reactivate.

Way 3: WP-CLI

Only if you have SSH access and that sentence made sense to you. If it did:

cd /path/to/your/wordpress   # the folder that contains wp-config.php
wp plugin list --status=active
wp plugin deactivate the-plugin-slug

It’s back. Don’t walk away yet.

Clear every cache you have, in this order: the caching plugin (WP Rocket, LiteSpeed Cache, W3 Total Cache), then the hosting cache (most managed hosts have a purge button in the panel), then Cloudflare if the site runs through it. Skip this and you’ll get a call in an hour from someone still seeing the white page while you’re looking at a working site. Been there.

Then click three things. The homepage. One inner page that matters, a product page or a services page. The contact form, and actually send it. A site that renders but can’t take an inquiry is still down as far as your business is concerned.

Now the plugin. You have three options, and I’d rank them like this:

1. Roll it back to the version that worked. The WP Rollback plugin does this from the Plugins screen for anything on WordPress.org. For a premium plugin, download the previous version from the vendor’s account area and upload it over FTP.
2. Leave it deactivated and wait. If the update broke you, it broke a few hundred other people too, and there’s often a patch within days.
3. Replace it. If this is the second or third time the same plugin has done this, that’s your answer.

When you shouldn’t do this yourself

This is the part I’d rather write honestly than write well. Everything above assumes a simple case: one plugin, one update, one error. Some white screens aren’t simple, and the DIY route makes them worse.

The last one is a different problem wearing the same symptom. Renaming a plugin folder won’t help, and poking around in the file system while a site is compromised can destroy the evidence someone needs to clean it properly. That’s a security cleanup, not a maintenance job, and it’s the one case where I’d say close the FTP window and pick up the phone.

On the WooCommerce one, I’ll admit I’m more cautious than most Reddit answers. A store that stays white for twenty more minutes while a developer checks the order tables is cheaper than a store that comes back with a broken checkout nobody notices until Monday.

So it doesn’t happen again

Three habits. Nothing clever. Test the update on a staging copy first; most hosts give you one for free now. Take a backup right before you click Update, not the nightly one from twelve hours ago. And update one plugin at a time, so when something breaks you know which one did it. That’s the whole prevention plan.

Quick questions

The post WordPress White Screen After a Plugin Update: How to Fix It in 10 Minutes (and When Not To) first appeared on Macronimous Blog.

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

The safety net became the steering wheel

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

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

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

What happens when an agent codes without tests

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

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

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

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

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

The working sequence looks like this:

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

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

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

Fix bugs backwards: regression test first, patch second

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

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

Can an agent review agent code?

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

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

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

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

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

What changes for the team lead

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

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

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

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

Your testers just got promoted

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

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

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

The argument nobody wins

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

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

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

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

Your plugins screen shows three fields

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

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

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

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

What a ten-year-old site leaves behind

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

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

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

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

So I built something that can only look

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

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

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

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

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

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

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

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

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

What this does not fix

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Incident two: numbering that was right everywhere except India

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

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

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

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

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

The mistake that never happened

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

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

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

The MCP connector: agentic defaults trust too much

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

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

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

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

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

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

The bottom line, and the code

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

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

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

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.