What do we do now that code is a lot cheaper?

Do you remember the EDP Workflow diagram from 2024?

This is one representation of the Product Development Lifecycle. We used this while EDP leadership was swarming on figuring out how we get out of this slow-shipping rut we seemed to be stuck in.

“engineering” is the biggest bubble here. And if you combine “engineering” with “testing” then it dominates the center of this process.

At every team I’ve worked with since the start of my career, engineering has been the bottleneck. This started to shift in ~2023 when autocomplete models got a lot better, and the change accelerated in 2025 as the quality of AI tools for engineering exploded.

As a result, the time and effort it took to build and maintain most (not all) code shrank significantly.

This is what it looks like to me when we say “the long pole moved”.

I feel the effects of this today when engineers and designers are chomping at the bit to build but we haven’t built the process and tooling to support it.

Now that the cost of building a feature has dropped from weeks to days or hours…

• Waiting hours or days for a PR review feels especially painful
• Setup and teardown for experiments is relatively expensive
• Any input outside of the small team working on the feature becomes a bottleneck (design feedback, estaff feedback, DSE feedback, eng architecture review)

This is not a blame game.

More like… I have never worked on a team where the cost of writing code is so low, which makes everything else feel like high friction, even if everything else didn’t change (or even improved, just not as much).

So what needs to change?

Some things are easy to point to.

#We need to figure out PRs.

I’ve heard everything from “humans need to get out of the loop and we should automate pretty much all PRs” to “humans have to look at all the code or we’ll drift into an unrecoverable end”. There’s some truth to both, and we should end up somewhere in the middle.

We can get a lot more mileage from AI PR reviews. And authors can do a lot themselves to simplify their own code and make their changes easier to review.

PRs deserve their own post… but where I’d start is by seeing what burden we can reduce for the reviewers, like standardizing PR templates and having authors go through a checklist (e.g. “run /pr-review against your own PR, run /simplify, fill out your PR description”), or assigning an agent to summarize PRs (similar to Graphite’s “tour” mode) in the description. I’m sure lots of people have opinions here.

#We need to push decisions down.

The cost of waiting on someone outside of your team is too high. Teams need to be able to make decisions fully. I think we’re moving there. But this means teams will need to level up their ability to think through the whole product (eng, design, data, strategy). so…

#We need to teach Product thinking.

The people that work here are, without exception, quite smart. They can learn. We’ve done ourselves a disservice by not intentionally teaching Product Management (that’s right, I said the PM word!) to teams. Project Leads get a little bit of it, but more in the form of tasks they need to accomplish (e.g. reporting on experiment results) than understanding the why behind what they’re doing.

#We need to reduce the cost of experimentation.

Melissa is right that we should default to experiments. And in order to really do that, we need to improve tooling and skill in this area to the point where it would be stupid to not do it.

#We need to support cross-domain contributors.

Cross-domain contributions are not new at Medium, but the frequency and size of these contributions are new for some teams. Data Platform and Core Platform have always dealt with it. (Eddie has done a great job at leading the Platform team to keep the quality bar high while supporting other teams working in their garage. There’s probably a lot to learn from them.)

This requires some combination of a cultural shift and a process improvement. We are all on the same team, and assuming good intentions will go a long way when solving this problem. But still some teams don’t have the capacity to do the work they need to do while also supporting contributors from outside their domain. In these cases I think we should start by raising the standard for contributions, while the owning team adds tooling for these contributors to serve themselves (docs, agent tools, etc). Guilds should own this problem in their areas.

(Cross-domain contributors obviously include PRs for changes outside of the author’s normal domain, but also include product thinking and suggestions outside of your domain, like engineers working in content, designers shipping PRs, teams shipping and analyzing experiment data, etc)

#We need to do fewer things and finish them.

This is definitely a thing on an individual level, still true on a team level. With our increased capacity now, there’s a tendency to take on more work in parallel. That leads to burnout and lots of WIP slows down other parts of the system. Instead, we should limit WIP and focus on fewer things. Use that increased capacity to get stuff done more completely and faster. Small teams (2-3 people) are very effective at this.

---

I’m sure I’m not seeing everything. There are places where we’re feeling friction now like we’ve never felt before. At best, it slows us down in ways we weren’t expecting. Often, though, it leads to more frustration from people that are running into roadblocks that used to not be so jarring (you might find yourself bumping into others (or receiving bumps yourself) as these new bottlenecks become more apparent).

First, and foremost, we’re on the same team here. It’s critical that you assume good intentions from others.

It’s also important that you give yourself and others grace. We’re going through a major change in our industry and we’re all trying to figure out how we need to work. No one here has for sure done it all the way somewhere else, and we’re all learning together. That includes your peers and your leaders. It’s hard to change how we work. We need to do it, and we’re working on it, and it’s hard. The discomfort is expected and doesn’t mean things are going badly. But we can’t stop.

I don’t like rapid change. But I do like working with you all. Let’s do this.