Why I also build software as well as design it now

I trained as a designer and I’ve carried the title for about twenty years. Lead Product Designer, Senior UX Designer, Group Design Manager, Head of UX. I still love the craft and I still spend most of my week inside it. What changed in the last two years is what happens after the design is done.

In a lot of senior design roles the job drifts toward coordinating the design of software rather than designing it. Stand-ups, alignment docs, steering committees, a long Slack thread about the wording on a toast message. The design itself happens in whatever ninety minutes I can find between meetings. Most senior designers I know are somewhere in the same spot and most of them aren’t especially happy about it.

Then the AI tools got genuinely good. Not the demo version. The version where I can sit down on a Sunday morning, describe a screen, and have a working React component by lunchtime. Where I can write a Postgres migration without going off to read the docs first. The distance between having an idea and having a working thing got a lot shorter.

That didn’t replace the design work. It extended it. If I can build the prototype faster than I can run the meeting about whether we should build the prototype, then the design decision gets argued against something real instead of against a picture of it. Producing a screen got cheap. Knowing which screen is worth producing didn’t, and that half is still the design job.

Jenny Wen, who runs design at Claude, said a version of this on Lenny’s Podcast recently, in an episode called “The design process is dead. Here’s what’s replacing it.” She describes three kinds of designer going forward: the strong generalist who designs, prototypes and ships across disciplines, the deep specialist with real craft in one area, and the prototyper-builder who works directly in code. I recognised myself in the first one. The third is the one I’ve been adding to it, rather than trading it in.

She also talks about the work itself splitting in two. One half is helping engineers take AI-generated prototypes and get them to something that actually ships. The other is short-horizon vision work, three to six month directional prototypes that keep engineering teams pointed the same way. Both of those assume the designer sits closer to the code than they used to, and both of them are still design jobs. Reading it felt a bit like being given permission for something I’d already started doing.

Figma’s State of the Designer 2026 report found something similar, with designers moving into what they call the messy middle and picking up work that used to belong to other people on the team. If you want the line between designer and engineer to go away, it’s going away. That’s been the pattern for a while now.

The specific reason this was open to me at all is that I started out building. Sportal Australia, 2011, front-end work alongside the UX. I drifted into design management because that’s where the org charts at big companies push you. AI didn’t teach me how to build software. It gave me a reason to remember I already could, and picking it back up took much less time than I expected.

I’ll also admit the less serious reason, which is that it’s more fun. Designing in code, end to end, with the tools we’ve got now, is the most fun I’ve had at a keyboard since the Sportal days.

I want to be clear about what this is and isn’t, because the framing matters. I’m not a designer who left to become an engineer. I’m a designer who can now take the work all the way through, and the building has made me better at the design half rather than pulling me away from it. You make different decisions about a flow when you know exactly what it costs to build, and you stop handing over things that were never going to survive contact with a codebase.