Skip to content
jamesdarin
← Writing
WritingNov 20262 min

I was a developer first

Four years and 50+ websites before I designed anything. What that changes about building with AI, and what it doesn't.

Before I was a designer I was a front-end developer at TriMark Digital. From 2013 to 2017 I built more than 50 websites from scratch in HTML, CSS, JavaScript and PHP, some on a WordPress back end. Most were for regional businesses: Window World, Bojangles, Pinehurst and others.

Now most of the code I ship is written by Claude. So it’s fair to ask what four years of writing it by hand is still worth. Here’s my answer.

I know what I’m asking for

A lot of building with AI is naming things correctly. A dialog element for a dialog. A real button for anything you press. Images that hold their space so the page doesn’t jump while they load. I learned those by getting them wrong on client sites, and they show up in a lot of what I ask for now.

I know where the work belongs

When I design something I can usually tell what runs in the browser and what has to happen on a server. The password panel I designed at Daimler is an example. Every rule in it checks what you’ve typed as you type it. The breached-password and history checks can’t, because they need the server, so the prototype says so instead of pretending. That line came from knowing how the page works, and it’s what lets engineers trust a prototype instead of rebuilding it.

Performance and accessibility were the job

At TriMark a client site had to load fast on whatever phone a customer had, and work for people using a keyboard or a screen reader. I still check those first. They’re the problems AI-written code has most often without looking broken.

What I don’t do

I don’t read every line Claude writes, and I can’t always tell good code from code that only works. What I check is what it does: tab through it, turn on VoiceOver, see what the page weighs, open it on a slow connection. When something’s wrong I can usually say exactly what, and that’s what gets it fixed.

Getting better at reading the code itself is what I’m working on next.

Try it on this site

Press i on any page, or the Inspect button in the footer. Hover anything and you’ll see the component it belongs to, what a screen reader calls it, its type, colour, contrast and spacing. The panel also shows what the page weighs, how long it took to load, and how many tab stops it has. It’s the same set of checks I run on anything I build, built into the site so you can run them too.