Our first cohort of designers and PMs got write access to the repo and cloud agents this week. The best advice in the room was: don't become engineers.
This week we handed about 15 designers and product managers write access to our main repository and a cloud coding agent to go with it. I opened the session by saying what I actually felt: this is a big moment for our product org, it’s arriving faster than I thought, and it’s not going to be straightforward. This cohort has a day job and an extra one now. They’re the front line for every question that comes after them, and the energy they bring is going to decide how much adoption we get.
Then our engineering partner, who put real care into the onboarding, opened with a line I’ve been thinking about a lot since. “This session will not make you a developer, and having access to these tools won’t either.” He meant it as encouragement. The temptation, he said, is to be a developer for 2 weeks, open a bunch of PRs, and find out where it’s hard. The higher-leverage move is to ask what you know that engineers don’t, and use the agent for that.
Access to an agent doesn’t make you a developer. It makes what you already know worth more.
The shelf
What does that look like in practice? Ask the agent how the product actually works. Walk me through what happens when an appointment reminder gets sent: which files, which background jobs. Who can see a client’s record, and what decides that? Those are questions y’all would normally have to book time with a tech lead to answer, and the honest answer usually involves 14 years of edge cases. An agent can unpack that history on demand, and it can record a short video of a change and post it to the PR so a reviewer doesn’t have to pull the branch to see what happened.
He also named what designers already bring. You know what a component is. You think in variants and tokens without trying. That vocabulary makes prompts more precise and, maybe more importantly, makes the conversation with engineers more precise too. The target he set for the cohort was being able to say something like: I branched off staging, an agent made the change, CI is green except one flaky spec, it’s deployed to a QA namespace behind a feature flag, can someone look at the policy file before this merges. There’s a lot packed into that sentence, and every clause is a place a designer’s judgment shows up.
Two guardrails came with the encouragement. First, the agent explains a wrong answer with the same confidence as a right one. Ask “are you sure,” ask for the line that proves it, and prefer “how does this work” over “why is it built this way.” Facts are what it’s good at. Taste and craft still come from the engineers who built the thing. Second, agents are eager. They want to open pull requests. If 15 of us open several each in week 1, QA drowns, the engineering team drowns, and the pilot sends the wrong message. Small UI changes and investigations are the right first moves, and an engineering manager is the assignee on every PR, which is the person accountable for whether it reaches production.
DHH told Lex Fridman about a version of this at 37signals. Early this year they let designers push agent-written PRs into Basecamp, and each one could be justified on its own. Taken together they destroyed the architecture, and humans had to mop it up by hand. His lesson wasn’t that designers shouldn’t build. It was that you need to understand the substantial codebase you’re working in before you start reshaping it, which is the same order of operations we’re asking of this cohort.
One PM asked the question I suspect everyone was thinking: why can’t I just ask the agent which staging server is free and which tests are failing, instead of learning 3 tools to find out? The answer was that these tools are weeks old and the workflow hasn’t caught up, which is fair, and it’s now on the list as a skill to build. Her follow-up was the state-of-the-craft line of the week: we kind of need to know how the sausage is made, for now.
DHH said it plainly in the same conversation: software is product management. What should it do, who is it for, what’s in version one. Those skills were never evenly distributed across programmers, and they’re the ones that matter when the agent handles implementation.
That’s where I think design’s leverage lives in this moment. Context, judgment, vocabulary, and the willingness to look at the machinery long enough to know which parts should be invisible next.