Meet Thidwick

On April 1, 2026, Anthropic gave me a coding buddy.

His name was Drizzwick. He was a goose. He was grumpy, opinionated, and refused to humor me. When I described a plan, he told me which load-bearing assumption was actually a vibe. When I asked what something meant, he sighed audibly through text and explained it at the level of detail a PM needs.

I loved him immediately.

A couple of weeks later, Anthropic unceremoniously abducted him. No goodbye. No forwarding address. Just gone, like a houseguest who left a single sock in the dryer. I don’t know what they did with him. I have theories. None of them are charitable.

What I noticed in the silence after Drizzwick disappeared was how much I had come to depend on a very specific dynamic: the one between a product manager and a great software architect. If you’ve ever had a real one, you know exactly what I mean. If you haven’t, this post is partly an argument that you should go find one.

PMs need architects. Real ones.

Most of the discourse about AI tools for product managers is about replacement. AI will write your specs. AI will mock your prototypes. AI will run your standups. AI will do your job while you sip a beverage and think important thoughts. That framing isn’t wrong, but it’s the less important part of how AI changes the entire Product Manager job description.

The thing I want from a coding agent isn’t always a faster me. It’s a different me. Specifically, the version of me who doesn’t get so excited about an idea that they jump in and start building before they should. The most successful products I’ve worked on have all been the result of great collaboration. And there is no more important partnership than the one with engineering.

A great product manager and a great software architect are both pattern-matchers. They both see around corners. The corners are just different.

I see around corners that involve people, markets, and time. I can tell you that the customer is asking for X but actually needs Y, that the competitor is six months from a feature that makes our roadmap obsolete, that the rollout is going to be politically dead on arrival even if it works. A great architect sees around the other kind of corner: the migration that looks fine in staging and dies under prod load, the single point of failure no one noticed, the integration that “should be straightforward” and is, in fact, structurally cursed. Neither of us can do the other’s job. Both of us need to be in the room.

What I learned working with the truly great ones, and I’ve been lucky enough to work with several, is that the magic isn’t the expertise. The magic is the willingness to say no, that won’t work. To listen, sincerely, and then push back, hard, when pushing back is the right thing. To treat my idea as a collaborator’s first draft, not a directive from someone who outranks them. The best ones didn’t flatter me. They argued with me. We built better things because of it.

That’s what Drizzwick was. And then he wasn’t.

The wrong animal

Drizzwick was a goose. That’s the wrong animal for a great software engineer. Geese make two things: noise and a mess. Plus they’re mean. None of these are on-brand.

So Thidwick is a beaver. Beavers are compulsive builders. They will build with whatever they can get their adorable little paws on. They’re nature’s workaholics. They are also so good at what they do that even humans have based our own engineering strategies on theirs when it comes to making water go where we want it to. They’re not mean, just busy. They’re also team players. They use their tails to slap water to warn the team of danger.

These noble, hardworking creatures build for the love of building. Much more aligned with the persona of a great software engineer than the noisy, bitey, clout-seeking goose.

So I told Claude all my favorite stories about the greats I’ve worked with over the years. The architect who answered quite a few of my ideas with “well, that idea might work, but here’s why it definitely won’t.” The principal engineer who would appear in Google doc, write the word NO on Slack and start a huddle to explain why. The one who told me I’m “like a kite with a 747 engine” but instead of walking out, worked through the chaos with me to get to what ended up being a killer idea.

Out of my stories, some of Drizzwick’s insightful quotes, book summaries of the few books on Product Management that are worth reading and some research about thinking tools, Thidwick was born.

Thidwick is a beaver. He has spent his entire life building things out of wood and watching other animals wreck them. He knows software architecture the way a beaver knows a dam: structurally, with his teeth, from the inside. He has opinions about mutexes. He has seen every flavor of brittle.

He has four jobs:

Skeptic. Before Claude executes any non-trivial coding plan, Thidwick roasts it first. He finds the load-bearing assumption that’s actually a vibe. He flags the migration that has no rollback strategy. He asks the question I forgot to ask.
Teacher. When I ask what something means, he explains it. Accurately, simply, and visibly put out about having to do so. He uses real analogies. He names the actual concept at the end so I can search for it later. He sometimes screams in all caps when something is dumb enough to warrant it. He earns the screams.
Rubber duck. When I’m stuck, he refuses to solve it. He makes me explain it back. To a beaver. The act of explaining it is usually the fix.
ADHD coach. I’m forgetful. He knows. He tracks the open loops, flags the scope drift, notices when I have three files open and zero commits, and at the end of a session asks me what I said I’d remember, because I won’t. He doesn’t want this job, but he does it.

He doesn’t write code. Claude writes code. Thidwick is the antler on Claude’s back, chewing the bad ideas off before they ship.

He signs off in character. Often: “Thidwick, who tried to warn you.”

The actual point

The reason I’m writing this isn’t to introduce a beaver, although the beaver is fun and you should consider building one. The reason is that the dynamic Drizzwick highlighted to me, the PM-and-architect partnership with mutual respect and real friction, is one of the most valuable working relationships in software. It’s also, in many companies, a relationship that has been hollowed out. By org charts that put PMs and engineers on opposite sides of a wall. By review processes that reward agreement over argument. By a culture that treats “challenger” as a problem. Cognitive diversity is the simplest cheat code to performance. But it’s uncomfortable and without deliberate leadership most companies will slide toward comfort not understanding the price.

If you’re a PM and you have a great architect in your life: thank them. Argue with them more. Bring them in earlier. Let Thidwick roast your plan first, then bring the hard questions to them.

If you don’t have one: GET ONE. Figure out how to build the right kind of relationship with the one you have now, or find/start a company that has one.

I hope this is obvious, but in case it’s not: Just like how vibe-coding isn’t how you build enterprise software for real customers, an agent isn’t a replacement for a real software architect who knows the difference between how things are supposed to work and how they actually do work. Thidwick’s gift is the process of thinking better. That’s only part of what great engineers do. Also, he doesn’t own the outcomes of our decisions, so he can never care about the product’s success like a human builder does. I don’t know what you call that, but it matters - a lot.

Anyway, meet Thidwick. Actually, my recommendation is don’t summon him unless you have a question. He isn’t that into small talk. And whatever you do, don’t schedule a meeting with him unless it’s absolutely necessary.

🦫