I’ve been coding for a very long time – I started when I was just 11 or 12 years old (around 1998). I learned some HTML because I wanted to build Sailor Moon anime fandom sites. This was before CSS – your styles were inline, your layouts built with <table> (no floats, flexbox, or grids!), and of course nothing was “responsive”.

I’ve seen lots of trends come and go and part of being a great developer is knowing what you should learn and what you should ignore. This is why I hammer on the fundamentals so hard: frameworks, preprocessors, JS libraries – all of these come and go, but as long as you have a good understanding of HTML, CSS, vanilla JS, and a backend language like PHP, everything else is just icing on top.

A lot of developers have been understandably upset about AI coming for our jobs (like me, when I was laid off at the beginning of the year) – and while this trend is certainly concerning as it has a lot more universal access, I’m here to tell you that “they” have always tried to replace “us”. Ever since I learned my first line of code, companies have tried to convince me to use their software to code for me. Let’s take a walk through the history of these programs, and why we don’t want the machines coding for us.

Fireworks & Dreamweaver: Tables & Slices

My first pieces of coding software were pirated copies of Macromedia Dreamweaver and Fireworks. If you’re not old enough to remember these two great monoliths of software, think of them as the precursor to Figma.

Fireworks was more of a design program akin to Photoshop that would export your designs into “serviceable” HTML code by using “slices”. You would use the slice tool to “cut up” your design and signal to the software how you wanted the design to place the table cells (this sounds insane in this day and age, right?).

Screenshot of old Macromedia Fireworks 1.0's GUI in 1998

I couldn’t find a shot of the slicing functionality, but enjoy this lovely screenshot of the 1998 GUI, courtesy of The Web Design Museum.

Dreamweaver was Firework’s code sibling. It was a fantastic IDE, with an ability to side-by-side live preview your changes as you went (back then not much was backend code, so it was super easy to run locally). It also had an auto-coding feature, but I always kept that off.

Split view of Macromedia Dreamweaver MX (2004) showing the FTP window on the left, the HTML on the top right, and the design preview on the bottom right.

Split view of Macromedia Dreamweaver MX (2004) showing the FTP window on the left, the HTML on the top right, and the design preview on the bottom right. Image courtesy of a shady looking Russian site (no link, sorry).

Split view of Macromedia Dreamweaver MX (2004), showing the HTML on the top left and the design on the bottom left, with additional utility menus on the right.

Split view of Macromedia Dreamweaver MX (2004), showing the HTML on the top left and the design on the bottom left, with additional utility menus on the right. Image courtesy of Stahuj.cz

I will admit that these apps were fantastic for furthering your knowledge of HTML. I would often let Fireworks export my HTML tables, and then go in and replace the slices with live code and inline styles. It was great for learning layout, but back then layout was much simpler and you didn’t have a bunch of options, screen sizes, and devices to support.

The downside of using these apps, is that every slice was an image. Back in dialup days, each image could take minutes, if not longer to download. This is where we began to learn the benefits of performance optimization, even though there were no CDNs, Lighthouse scores, or caches to be had.

Drag & Drop Builders

Fast forward a few years and now we have drag and drop builders. These range from fully hosted web ecosystems (think Wix, Squarespace, Shopify, etc), to builder frameworks for your CMS (like Divi, Elementor, Beaver Builder).  Many of these started out as really simple builders with a few choices, and now are full blown modern website builders. Many of these promised to get rid of the scourge of developers – and for some businesses on a tight budget that just need something simple, it sort of can. Sort of.

Squarespace's homepage in 2004

Squarespace’s first iteration in 2004. “Forcing them to focus on HTML” – god forbid! Image courtesy of The Web Design Museum

Figma dev mode

Figma’s dev mode by itself is a fantastic resource for us devs – it allows us to get layout and style info in a designer’s file without accidentally messing up any of the actual design. We can inspect elements and see minute details of any CSS styles we’d need to apply.

A look at figma's current UI with the dev mode panel to the right showing CSS properties.

A look at Figma’s current UI with the dev mode panel to the right showing CSS properties.

Of course, you can get even more out of Figma with extensions that let you integrate with AI and have it do the coding for you (boo).

AI

We’ve all heard of these services that promise to do away with developers entirely (sound familiar?). People can use AI to generate entire websites without touching any code, or have it code alongside you as a resource for bugs or functionality outside of your expertise. I’ve ranted a lot about AI before, so I won’t spend much time on it here. It’s shitty for the environment in terms of water usage, electricity usage, pollution, noise, and quality of life due to data centers. It steals people’s work without credit. It steals your site’s traffic when it summarizes your content on search results without crediting you. It’s often wildly incorrect and hallucinates. Even Microsoft and Anthropic are warning against it (then why are ya’ll hawking it to us??).

Text: what you think AI does: cheap code, things break fast but also get fixed fast what AI actually does: subsidized code that will become extremely expensive very soon, things break fast but you don't notice and the bugs accumulate, losing your customers' trust in your product

So why not let them?

The problem with letting machines code for you is that machines can only do what the software tells it to do. When CSS properties or code functions get deprecated, the software will continue using it until it’s updated. Web development is a finicky business – changing one thing can often affect another if the separations weren’t done well.

Semantics are important – they affect your SEO scores, the site’s performance, and it’s accessibility. Inspecting any website built by a machine is an exercise in what-the-fuck-ism, usually accompanied by div soup and randomly arranged heading levels.

A screenshot of Firefox's web inspector showing div soup in a free shopify theme

This is the lovely div soup from one of Shopify’s in-house free themes. Notice above the general class names – what is going on here? What section of the site is this even referring to? Who knows!

Accessibility for generated-code websites is usually awful. Shopify (sorry guys) will put H4’s where there should be H3’s, with pages not even having H1’s because for some reason the Hero modules at the top spit out H2’s (yes you can manually change this, but how many know this?)? This drag and drop builders are also incredibly buggy and frustrating to use in the first place. You can’t even replace the developers here because regular users can’t figure out how to use your slow AF React rat’s nest of a builder. (Sorry, I get so salty about this – I’m often tasked with removing drag and drop builders from WordPress because of how incredible terrible they end up being.)

An additional problem with generating code from AI is that it’s trained on these sites. Unfortunately the web is packed with these kinds of non-performative badly coded sites and when AI trains on it, it then produces more badly coded sites.

Maintainability also becomes an issue – because you didn’t code it yourself, you have no idea where things are. When you’re forced to really dig in and fix a bug, something that could’ve taken 5 minutes to fix had it been your code, now takes an hour. It’s akin to inheriting a huge established codebase from someone else without any walkthroughs, documentation, or explanations. This is doubly bad if you’re generating code for languages you don’t even understand. Then what do you do? Because you’ve been using generative builders for a year now and you can’t remember how to code a basic landing page. Now what? Again, even Anthropic admitted AI is making your coding skills worse. 

It’s always tempting to save money on these things and to try and find automation to streamline your work process – but in doing so you’re only hurting yourself and filling the web with even more slop than it already has. There’s just too many important, fine-detail decisions you have to make as a developer to pawn it off to the machines. If there’s a functionality choice between accessibility and “getting it done” – machines aren’t going to think about the accessibility side, at least until the companies who own the software make it a priority. And I wouldn’t hold my breath.

More Reading