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.

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

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

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

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

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

The “Wow” Factor: Figma vs. Lovable

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

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

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

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

But then the professional reality hit.

The Invisible Wall

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

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

1. The SEO Control is Skin-Deep

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

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

2. The Scalability Trap

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

3. The Portability Crisis

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

The Ethics of the “Sign Out”

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

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

An Honest Verdict

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

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

Frequently Asked Questions: AI Website Builder vs WordPress for SEO

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

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

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

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

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

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