Product Over Code

I've never run an engineering team. I've run product and engineering teams, every time, and I never understood the org chart that puts engineering in one department, product in another, and design in a third. They're all making the same thing. Code and design were always in service of the product, something that creates value for a person and makes their day a little better.

For most of my career that was a preference. A company could get by with engineers who only cared about the code, because the code was the expensive part and somebody had to be great at it.

Code is the cheapest thing a company produces now. Features, scale, most of the engineering problems that used to eat a quarter all got dramatically easier. If the code is what you're proud of, you're proud of the part that got cheap.

So there are two things to rethink here: what an engineer values, and who gets to build.

You're a product engineer

The product is the whole breadth of your role now. What are we building? Who needs it? What's valuable about it? How will we measure whether it worked? How fast can we test it and try again?

Product sense gets talked about like a personality trait. It's a learnable skill, the same way Rails was. You got good at Rails by reading about it constantly and shipping things. Read about product the same way, and when you ship something, go look at whether anyone used it.

In Stop Writing and Reading Code I said every hour I spend reading a diff is an hour I'm not spending on whether the feature should exist at all. This is where those hours go.

Everyone else gets to build

The second half is the one I didn't expect to like so much.

Your technical experience is still worth a lot. One of the best uses of it is making it possible for the rest of the company to contribute to the product. Marketing should be able to split test copy, build a landing page, and change a drip campaign without filing a ticket and waiting on me. Sometimes that's a feature in the main product. Sometimes it's an internal tool that connects their job to the product. Either way, they should be able to build it directly.

They can, because the agent writes the code. What they can't do alone is set up the environment that makes it safe and makes the result any good. That part is the engineer's job. It's what keeps you relevant, and for me it's what keeps the work exciting.

Some of it is plain teaching: workshops, trainings on Claude Code, an orchestration layer like OpenClaw. Most of it is the harness you hand them.

Guardrails and paths

As a developer, my guardrails are basically off. I run everything in YOLO mode, because I know what the agent is about to do and what it would cost me if it went wrong.

That's not safe for someone in marketing, and it's not fair to ask them to know. Their harness needs tighter permissions, work that's easy to test, and no way to break something they can't see.

Guardrails only cover what can't happen, though. I spend more of my time on paths: skills and deterministic scripts that carry a non-technical person from "I want to try this" to something that works and that somebody can maintain later. I built the marketing team skills that pull their AdWords data, set up split tests, and build dashboards for themselves. They don't have to work out how to do any of that. They say what they want and the path is already there.

The product PR

The first version of this had a problem, and the problem was me.

The rest of the team was using the same workflow skills I use, so their work showed up as pull requests. On a small engineering team, review is quick. We trust each other's testing, and we're all product engineers, so I trust everyone's product sense too.

A PR from outside engineering needs a different kind of look. I need to see the interface. Is it using good UX and UI patterns? Does it feel like the rest of the product? The PR told me none of that. I'd check out the branch, run it locally, play with the feature, leave comments, and do it again on the next round. I had opened the product up to the whole company and then made myself the bottleneck.

So I built a product PR skill. When someone opens a PR through it, the agent produces this:

## Product tour
A video of the agent walking through the feature

## Before and after
Annotated screenshots of every screen that changed

## Approach
What it built, the pros and cons, and what it passed on

## Architecture
A mermaid diagram of the pieces and how they connect

## Code trade-offs
A summary of the technical decisions and why

## Checks
Linting and automated checks, a lot more than a normal PR runs

The old PR was fine for what it was built for. A few engineers with shared context and shared taste don't need a video. It stopped working when the people opening PRs changed.

The review got much easier, which I expected. I didn't expect their work to get better. An agent that has to record a tour of the feature and annotate its own screenshots ends up looking at the product the way a user would, and it fixes what it sees before I ever get the PR. A step I added for my own convenience ended up improving the product work.

The abstraction moved

I used to think in classes and modules. Now I think about harnesses, skills, guardrails, and trainings, and it's the same kind of thinking. I'm still designing an interface. It's just one the whole company builds through.

This has been one of the biggest changes to how I work and how the company works. Marketing isn't waiting on engineering. There's a lot more trust between departments, and it's been a lot of fun.

Put the product first, more than you ever have. Then make the product something the whole team can reach.

This is part of Rethink Everything.