A new role for SWE, managing outcomes not outputs

A lot of hand-wringing is happening right now about reviewing code — whether AI-written code needs the same scrutiny human-written code does, whether skipping it is negligence or just the next abstraction layer. I have a confession: I haven’t reviewed code for over a decade.

How? I transitioned into being a PM for technical products around 2008, and there was never time for it in the job description. No one even asks the question of PMs, even technical ones. I kept writing code alongside the teams I worked with, and got genuinely proficient at finding bugs, improving developer experience, and shaping highly technical products. I sat in on PR reviews. I had opinions about language selection. I just never formed them by looking at the code. Why? I cared about outcomes, not output. You should too.

It felt weird to start, which is clearly the awkward phase a lot of engineers are going through right now. I remember the first few features I reviewed as a PM — I weighed in on code quality, library choice, things that weren’t mine to weigh in on. It was not welcome, and I learned quickly to stay in my lane. Trust came from proving outcomes, not from meddling. And this wasn’t consumer apps or dashboards — I hold patents on distributed logging systems, container bootstrapping, and databases I helped build from scratch. Trust from engineers still required a lot of engineering on my part. Just not on the pieces I’d explicitly delegated.

When I started coding again myself, with models doing the typing, I was embarrassed that I wasn’t reading the code. I’d watch the diffs scroll by and google whatever I didn’t recognize — after all, someone might ask me about it, and I was responsible. But that had been true as a PM too. Not reading the code never meant not learning the language or the abstractions underneath it. I did Kubernetes the hard way — the actual hard way, step by step, no shortcuts. Outcomes require understanding. Trust requires verification. Curiosity never left.

A year ago I was pushing Sonnet to build an MCP server in TypeScript for a client. Verification was where I put my attention, and it pulled me somewhere I didn’t expect: I ended up building a full DSL and a platform for running evals, vibecheck. The outcome stayed front and center. I was looping — the same concentric-feedback thinking I’d been writing about since 2018, just running on agents instead of teams.

Opus 4.6 was the real unlock — the point where I started treating models like actual SWEs. Harnessing Sonnet was cumbersome enough that it wasn’t meaningfully faster than a human who already knew how to code. Opus 4.6 changed that math. That’s when I stopped running one loop and started running many. I stopped looking at diffs entirely, and got a lot more serious about verification and benchmarking, because that was now the whole job.

Fable is a new paradigm on top of that. Orchestration is becoming a real discipline — multiple agents, coordinated — and validation still matters as much as ever, except now you can trust the model to build its own verification loops too. I’ll admit that still gives me some vertigo. It’s pushing me to change my workflows again: hand off more to the models, and build out increasingly complex validation systems in response. It feels exactly like managing a larger team, which is to say more bugs surface, and the software I’m responsible for is bigger and not always knowable to me as a PM.

The skills this requires are different from where I started as an engineer, but they’re a continuation, not a departure. Some SWEs will embrace it. I expect many won’t. Neither is more right, and I expect there’s a role for both — but the role itself has changed for good. Systems where outcomes can be verified directly by the stakeholders who need them may not need a software team in between at all. Measurement and observability are the skill to build next.