Every few weeks someone announces that WordPress is dead. Or websites are dead. Or developers are dead. Or designers are dead. Or nobody needs to know how to code anymore because AI can just build the thing for you.

I’ve been around long enough to have heard versions of this many times. Flash was going to change everything. Then it was Drupal. Then custom CMSs. Then Squarespace. Then WordPress. Then headless. Now we’re in the middle of another enormous wave of AI tools, agents, skills and platforms that promise to make building things faster and easier than ever. Some of them are remarkable. I’m not arguing with that.

I’ve spent the last six months going very deep into this stuff because I want to understand where it’s actually going. Learning, testing, building, taking things apart, and running all of it through my own site first to understand what is happening underneath all the shiny interfaces. And strangely, I’ve come out of it thinking more about the fundamentals of development than I have in years.

Wow. Look what it just made.

One of the things that’s both exciting and slightly terrifying about these new tools is how impressive the output can be. You ask for a site and suddenly there’s an HTML file sitting in front of you. It has tabs, animations, interactions, responsive layouts, little bits of JavaScript doing clever things. You open it in a browser and think, holy shit, it made that?

Yes. It made that.

But then I want to ask a few more questions. Why is this an HTML file? What’s actually in it? Where does it live? What files does it depend on? Is the CSS embedded in the page or somewhere else? Is the JavaScript doing something essential or could half of it disappear without anyone noticing? What happens when we need to change something six months from now? Can someone else open the project and understand what they are looking at?

And perhaps most importantly: do you know what you just built? Because there is a big difference between being able to generate something and understanding something, and you can’t direct what you don’t understand. I think we’re going to have to get much better at knowing the difference.

The file is not the system

This is where some of the new development workflows get interesting. Claude, for example, will create a CLAUDE.md file and suddenly that becomes part of the workflow. That’s useful. But I don’t want CLAUDE.md to become another piece of magic that nobody really understands.

What’s in it? Why is that instruction there? Is it still relevant? How many lines are actually useful and how many were generated because the system thought they sounded helpful? What happens if you remove one? Where does the file live, and how does Claude actually use it?

The same thing happens when you add a skill. Great, you’ve added a skill. But where is it? What does it contain? What does it depend on? When does it get called? How does it connect to the rest of the project? Is it solving a real problem or have you just added another layer because the tool made it very easy to do?

These questions might sound overly technical if you’re used to thinking of AI as a magic box. They’re actually ownership questions. If you’re building a system for a business, you should understand the system.

I don’t want the magic to become a black box

I’m not against abstraction. We need abstraction. Good software hides complexity all the time so people don’t have to think about every underlying detail just to get something done. But there is a point where hiding complexity becomes hiding understanding, and that’s the part I’m wary of.

A platform can make it incredibly easy to build something while making it incredibly difficult to understand how that thing is actually put together. Your content might live in their database. Your components might live inside their system. Your design might depend on their framework. Your functionality might rely on services you don’t even know you’ve connected.

Everything can work beautifully until you need to leave. Then the questions become much less exciting.

  • Where is my stuff?
  • Can I export it?
  • What exactly do I own?
  • What depends on this?
  • If I change this, what breaks?
  • Can another developer take this over?
  • Can I move it somewhere else?

Those are the questions I want answered before we get ourselves too impressed by the blinking lights.

This is where planning comes back in

The funny thing is that after all this deep diving into new technology, I’m not coming away thinking we need to throw out everything we knew about development. I’m coming away thinking we need to remember why we learned it in the first place.

Planning. Architecture. Information architecture. Content structure. File organization. Dependencies. Documentation. Knowing what belongs where and understanding how the pieces connect. Thinking about what happens when the thing gets bigger, when someone else takes over, when a platform changes, or when you eventually need to move it somewhere else.

None of this is particularly sexy. But it is what makes something maintainable, and it is the same reasoning behind rebuilding my own Design Guidelines before I touched the site.

I’ve seen the alternative

I’ve worked on enough sites to know what happens when nobody thinks about the roots.

A site starts with a simple idea. Then someone adds a plugin. Someone adds a form. Another person adds a custom script. A new template gets created. Somebody duplicates it because that’s easier than figuring out how the original works. A year later there’s an integration nobody remembers setting up and a piece of functionality that absolutely nobody wants to touch because they’re afraid of what might happen.

Eventually the person who built it is gone. Now the business has a site, but nobody really understands the site. That’s not a technology problem. It’s an architecture problem, and it usually started as a planning problem.

I’m not interested in making things complicated

This isn’t an argument for going back to hand-coding every page or refusing to use modern tools. I love modern tools. I love how much faster we can work now. I love being able to prototype something in an afternoon that would have taken days or weeks when I started. I love experimenting and seeing how far I can push these systems.

The difference is that I want to understand what I’m building. If an AI tool creates an HTML file, I want to know what HTML is doing there. If it creates a folder full of files, I want to understand why those files exist. If it adds a skill, I want to know what the skill does and where it fits. If it creates a CLAUDE.md, I want to know what’s in it and whether every instruction deserves to be there. If something is stored in the cloud, I want to know whose cloud it is, what is actually being stored there, and what happens if I decide I don’t want to use that platform anymore.

That’s not me being precious about development. That’s me wanting to understand the thing I’m responsible for. It’s also why I care so much about what things are named, because a name is the part a tool actually reads.

The platform is not the architecture

This is probably the biggest thing I’ve come back to. WordPress isn’t the architecture. Neither is Webflow, Squarespace, Shopify, Claude, whatever AI builder is currently getting attention, or whatever comes next. Those are tools and environments.

The architecture is the thinking about how the pieces fit together. What lives where. How information is organized. What depends on what. What can change independently. What needs to stay consistent. How someone else can understand the system. How the system can evolve without everything having to be rebuilt.

That’s the stuff I want to get right. Because once you understand those fundamentals, you have choices. You can change platforms. You can change tools. You can introduce AI. You can rebuild the interface. You can hand the project to another developer. You can change the way the business works without throwing away everything underneath it.

That’s freedom.

I’ve come full circle

I started my career when development required a lot more deliberate thinking. You couldn’t just ask a tool to build you a beautiful interface and watch it appear. You had to understand what you were making, where the files lived, how things connected and what would happen when you changed something.

Technology has made an enormous amount of that easier, and I’m grateful for it. But easier doesn’t mean we should stop understanding. After six months of going very deep into what’s happening now, I’ve found myself back at the beginning: thinking about planning, architecture, structure and the fundamentals of development.

The tools are getting better at making things. Our job is to get better at understanding what we’ve made.

Because eventually the animation stops being impressive. The tabs are just tabs. The HTML is just HTML. The CLAUDE.md is just a file. And then you’re left with the thing that actually matters: whether you understand the system you built well enough to change it, maintain it, move it and keep making it better.

That’s the part that doesn’t become obsolete.