Code Is Cheap Now. What Are Developers Actually For?

Something shifted in engineering over the past two years, and most teams haven't caught up to what it means.

Writing code used to be the hard part. You hired developers to produce code — to translate requirements into working software, line by line. The bottleneck was output. Ship faster meant hire more engineers or work longer hours.

That bottleneck is gone.

The cost of code collapsed

Copilot, Cursor, Claude, ChatGPT — the specific tool doesn't matter. What matters is the trend: generating functional code is now fast, cheap, and increasingly reliable. A developer with Cursor can scaffold an entire feature in the time it used to take to write the boilerplate. A junior engineer with Copilot produces code at a rate that would've been senior-level output three years ago.

Teams consistently report 2-3x increases in PR volume after adopting AI coding tools. Not 2-3x more features shipped — 2-3x more code generated that needs to be reviewed, tested, and integrated.

The cost of writing code dropped. The cost of everything around it stayed the same.

Developer attention is the new scarce resource

If code is cheap to produce, what's expensive?

Reviewing it. Someone has to read every PR, understand the context, check for bugs, evaluate architectural decisions, and decide if it's ready to merge. This requires deep understanding of the system — the kind of knowledge that AI can't fake.

Deciding what to build. AI can generate code for any specification, but it can't tell you if the specification is right. Should this feature exist? Does it align with the product direction? Is this the right abstraction?

Ensuring quality. AI-generated code often works but isn't necessarily good. It might introduce subtle performance issues, use deprecated patterns, or create tech debt. Catching this requires experienced eyes.

Triaging what matters. When your team generates 3x more PRs, someone has to decide which ones need careful review and which are safe to approve quickly.

Developers are moving from code producers to code reviewers, decision-makers, and quality gatekeepers. The job isn't disappearing — it's transforming. And the new version is harder, not easier, because it requires more judgment and less typing.

Nobody is building for this reality

Look at the developer tooling landscape. Most tools are still optimized for the old world:

• IDEs help you write code faster (the part that's already fast)
• CI/CD automates testing and deployment (important but not new)
• Project management tools track tickets and sprints (built for the output-focused era)
• GitHub's notification system broadcasts events to email (where they go to die)

Where are the tools for the reviewer? The decision-maker? The developer whose primary job is now evaluating other people's (and AI's) code?

The senior engineers who spend 60% of their time reviewing PRs and 10% writing code have zero tools built for that 60%.

The teams that adapt will win

The engineering teams that figure out this shift first will have an enormous advantage. They'll ship faster — not because they generate more code, but because they review and decide faster. They'll have fewer bugs — not because AI doesn't make mistakes, but because they've built workflows to catch them efficiently.

The teams that don't adapt will drown in PRs, context-switch constantly, and merge code they didn't really review because the volume was too high.

This isn't a tools problem you can solve by buying another SaaS product. It's a workflow redesign. How does your team triage reviews? How do notifications reach reviewers? How do you allocate attention across a growing volume of PRs?

What we're building

Tenpace exists because we think the developer workflow needs to be rebuilt around attention, not output. Our first product is PR notifications done right — the right person, the right context, the right time. Not because notifications are exciting, but because they're the first link in the review chain. Break the notification and the whole workflow stalls.

But this is bigger than notifications. The question we're answering is: how should developers work now that code is cheap?

We don't have all the answers yet. But we know the question matters, and we know most tools are ignoring it.

Follow along as we figure it out.