The Designer, the Engineer, the PDM — and Claude Design

The views expressed in this post are my own and do not represent those of any current or past employer.

Last weekend, I designed and shipped a production blog from scratch for my wife in a few hours.

I’m not a designer. I don’t run a UX practice. I haven’t touched Figma in any serious way. And yet, by Sunday afternoon, bookishbailee.com was live, a magazine-feel personal journal with the kind of considered typography, calm palette, and editorial sensibility that you’d expect from a small design studio that charged a few thousand dollars to put together.

What changed isn’t my skill set. What changed is the tooling.

Specifically: Anthropic’s newly released Claude Design, paired with Claude Code, has quietly crossed a threshold that I think a lot of people in our industry haven’t fully internalized yet. The lines between software engineering, design, and product management aren’t just blurring, they’re being redrawn from scratch.

Andrew Ng (LinkedIn) described the same shift recently when he wrote that AI-native software engineering teams operate very differently than traditional teams, that the obvious difference is faster product building, but the real change is in how we operate. He’s exactly right. And after this past weekend, I have a personal example of what he means.

How This Started

I started blogging few weeks ago, notes on engineering leadership, AI, and fintech. My wife Bailee watched me do this since then and casually said she should do something like it.

She had a specific vision. A magazine-feel personal journal with three threads, Reading, Mom Life, and Anatomy, written in a slow, quiet voice. Not a tech blog, not a mommy blog, not a Substack template. She’s a mom of two under two, a professor, and a serious reader, and she knew exactly what she wanted. She just had no way to build it without paying someone else to make compromises she didn’t want to make.

That’s where most personal projects die. This time, neither of us settled.

Enter Claude Design

I sat down on a Saturday morning with Claude Design and gave it the kind of brief I would have given a designer over coffee, feelings and references, not specs.

I described what we wanted: a magazine-feel personal journal. Three categories: Reading, Mom Life, and Anatomy. Editorial. Slow. Quiet. The voice was “written between bedtimes”, tired but thoughtful, intimate but not confessional. I wanted serif headlines that felt like print. I wanted the design to breathe. I didn’t want it to look like a tech blog or a mommy blog or a Substack template. I wanted it to look like her.

What came back genuinely surprised me.

Claude Design generated two distinct design directions, both polished, both production-ready, both clearly trying to solve the brief in different ways. One leaned more editorial and print-inspired, large serif display type, generous white space, an off-white background, a feel somewhere between a literary magazine and a quiet bookstore café. The other was a touch more contemporary, softer sans-serif accents, warmer earth tones, a slightly more visual, magazine-cover energy.

This is the part that struck me. It wasn’t generating one generic answer. It was thinking like a designer, presenting options, articulating tradeoffs, and letting me choose the direction before going deep.

I picked the direction that fit Bailee best (the editorial one, unsurprisingly), asked for a few refinements (a “currently re-reading” sidebar, an “On the shelf” reading list module, and a featured-essay layout for the homepage), and within an hour, we had a complete, considered design system: typography, color palette, component library, page layouts, the whole thing.

Bailee reviewed it, lit up, and said, “This is exactly what I wanted.”

That’s the first time anything I’ve built for her has gotten that reaction on the first try.

From Design to Production with Claude Code

Now came the part that, even a year ago, would have been the multi-weekend grind: turning a design into an actual deployed website.

I handed the Claude Design output to Claude Code and described the goal. Claude Code did the rest:

Scaffolded the project (chose the framework, set up the build pipeline, configured the dev environment)
Implemented the design fidelity-faithfully, typography, spacing, responsive breakpoints, component variants
Built out the three categories and the article layouts
Set up the content management approach so Bailee can write and publish without touching code
Wrote deployment configs, set up the domain, configured SSL
Pushed the whole thing live

A few hours of work. Some of it was Claude Code working autonomously while I made coffee, played with my kids, and reviewed diffs in between. The total time from “blank canvas” to “production blog with her name on the URL” was roughly an afternoon.

Three years ago, this would have been a week of evenings, minimum. Probably more.

Bailee’s first essay, Anatomy of a Working Mom: Caffeine, Curiosity, and Two Under Two — went up shortly after.

The Roles Are Blurring: In Real Time

This is where I want to step back, because what happened that weekend isn’t a one-off productivity story. It’s a small, concrete instance of a much bigger shift that I think most engineering leaders are still catching up to.

Traditionally, what I just did would have required at least three distinct roles:

A designer to develop the visual language, typography, color, and layout system
A software engineer to translate that design into a working, deployed application
A product manager to scope the project, prioritize features, and define what “done” looks like

Each of those roles comes with years of training, specialized tools, and a craft tradition. They’re real, and they’re valuable.

But here’s the thing. For a project of this size, a personal blog, a small SaaS MVP, a side project, an internal tool, those role boundaries are increasingly artificial. One person, equipped with the right AI tools and clear thinking, can now legitimately fill all three.

That doesn’t mean designers, engineers, and PDMs are going away. It means the threshold of what one person can build is rising rapidly, and the bottleneck is shifting somewhere else.

Where the Bottleneck Actually Is Now

Andrew Ng’s post nails this part. The constraint isn’t building anymore. The constraint is deciding what to build.

I felt this directly in the bookishbailee project. The “engineering” was nearly free. The “design” was nearly free. What mattered, what actually determined whether the project succeeded, was a few much harder questions:

Who is this for? (Readers who want something honest and slow in a feed full of fast and loud)
What’s the core value? (A specific voice, a specific point of view, a specific seasonal vantage point)
What’s the right editorial structure? (Three threads: Reading, Mom Life, Anatomy that overlap and reinforce, not five categories that fragment attention)
What’s the right voice and visual identity for that audience? (Quiet, considered, magazine-feel not Pinterest-mom or tech-bro minimalism)

Those are PDM-shaped and editor-shaped and designer-shaped questions, not engineering-shaped questions. And they’re where the real work happens now.

This matches what I’m seeing in my day job leading engineering teams in fintech. The engineers on my team who are pulling ahead aren’t necessarily the ones with the deepest algorithmic chops. They’re the ones who can think clearly about what to build, hold a strong product opinion, sketch a UX, write a tight PRD, and partner with AI to execute. The “T-shape” engineer is becoming the default, and the cross-bar of the T is widening fast.

A Second Example: Finscan (WIP)

The bookishbailee project wasn’t a one-off. I’ve been running this same playbook on a personal project I’ve been kicking around, Finscan, a tool I’m building in the personal finance space.

For Finscan, I started differently. I used Claude Plan mode to work through a proper PRD: problem statement, target user, core use cases, MVP scope, technical approach, and a phased rollout. The output was the kind of document I would have written myself as a senior PDM, but in a fraction of the time, and with a sparring partner that pushed back on weak assumptions in real time.

From that PRD, the path to a working prototype was startlingly short. Plan → Design → Build → Deploy, all within the same toolchain, all with AI doing the mechanical work and me making the judgment calls.

What used to be a sequential pipeline with handoffs and bottlenecks at every stage is now a single, fluid loop. Idea, decision, prototype, iteration. Repeat.

The Part That Still Has to Come From You

I want to be careful here, because there’s a version of this post that turns into AI hype, and I don’t want to write it.

The reason this weekend worked wasn’t the tools. It was Bailee. She knew she wanted three threads instead of five. She knew the voice was “written between bedtimes” and not “lifestyle blogger.” She knew magazine-feel was right and Pinterest-feel was wrong. She had a clear, opinionated point of view about what she was making and who she was making it for. None of that came from Claude. All of it came from her. The design and the deployment were the easy parts.

That’s the pattern I keep seeing. The judgment what to build, who it’s for, what good looks like still comes from a person. The tools just remove the distance between having that judgment and putting it into the world.

What’s changed is the ratio. The mechanical work used to be 80% of the project, and the judgment was the part you fit in around the edges. Now the judgment is the project, and the mechanical work fits around the edges.

That’s a different game.

The Lines Are Blurring

For Bailee, this weekend meant her dream of having her own corner of the internet stopped being a someday project and became an actual journal with her actual writing on it.

For me, it was a small, concrete preview of where things are heading. Three role boundaries designer, engineer, PDM quietly collapsed into one person at a kitchen table. For projects of a certain size, that’s the new normal. And the implications for how small teams operate, how engineering orgs should be staffed, what “full-stack” even means are going to take a while to fully play out.

What I keep coming back to, though, isn’t the org-chart implications. It’s the kitchen table.

More people are about to be able to make the things they actually want to make, in the shape they actually want to make them, without needing to convince a team of specialists that their idea is worth the build.

That’s a quieter story than the AI productivity headlines. But I think it’s the bigger one.

Bailee’s journal is live at bookishbailee.com — notes from a working reader between bedtimes.