In the AI era, we need engineers with a stronger "product mindset."

Claude Code makes Anthropic's engineering organization's actual output reach about three times the manpower, but the bottleneck hasn't disappeared; it has moved from "writing code" to "deciding what to do."

(Background: Claude Code adds cloud scheduled task feature! No need to turn on the computer, AI automatically reviews PRs and upgrades)

(Background supplement: Anthropic engineers don't write code anymore: Claude is training the next generation of Claude, CEO says "not sure how much time is left")

Engineers' productivity has tripled, but the company is still hiring more people. This sounds like a contradiction, but that's exactly what Anthropic is doing. According to a guest commentary by Amazon software engineer Ishan Gupta on VentureBeat, Anthropic recently asked its growth team to "hire more" product managers (PMs), rather than cut them, because Claude Code allows the entire engineering organization to achieve about three times the actual output, and the bottleneck has shifted from the IDE (where code is written) to the people who "decide what to do."

Simply put, the tool is faster, but the people telling the tool what to do haven't kept up.

The bottleneck is not in typing

Gupta described the typical pattern of engineering workflows over the past decade: engineers dive into technology, write code, and check Stack Overflow when stuck. Now, the number of new questions on Stack Overflow per month has dropped about 77% since the launch of ChatGPT in November 2022. This figure itself is an industry profile: Engineers no longer need to wait for answers in communities.

He breaks down this transformation into five stages. The first stage is the Stack Overflow era (2014 to late 2022), where engineers' thinking was concentrated in one place and problems had fixed community solutions. The second stage is the browser tab era (late 2022 to 2024), where the first-generation ChatGPT operated outside the IDE, and engineers wrote prompts in the browser and pasted them back into VS Code; the entire workflow was still single-threaded and engineer-driven.

The third stage is the IDE-native era (2024 to 2025): Cursor and Claude Code brought models into the editor and granted access to the entire repo. A key consequence of this step is that the role of senior engineers as an "escalation path" has largely disappeared. Junior engineers no longer need to knock on senior colleagues' doors when stuck; the model is more patient than any colleague.

By 2026, the first command many developers type in a new terminal is already "claude".

The fourth stage is the specification-driven era (2025 to 2026): larger context windows compress work that previously required tickets, design files, and entire sprints into a single session. Amazon's Kiro IDE team reportedly compressed feature development from two weeks to two days. An AWS engineering team completed a refactoring originally estimated to require 30 engineers over 18 months, done by 6 people in 76 days.

The fifth stage, which is now, is the Routines era (2026): Anthropic launched Claude Code Routines in April, which are scheduled, persistent agents that can run periodically, via webhooks, or overnight with the laptop lid closed.

Cron is back. Hooks are back. Engineering work begins to have an element of "orchestration": launch a fleet of agents before bed, review a stack of PRs in the morning.

Who decides what to do?

However, engineering productivity tripled, but product management didn't move. To fill this gap, LinkedIn replaced the associate product manager (APM) track with a "Product Builder" program, training generalists across product, design, and engineering; Anthropic chose to directly hire more PMs.

Gupta's advice to engineers is straightforward: The important engineer in 2026 is not someone who waits for ticket requirements to come in. Instead, they proactively talk to customers, read customer support suggestions, sit in on sales calls, and can actually generate ideas rather than just passively give estimates.

The good engineer in 2026 is not the one who writes the most code, but the one who knows what to do, can prove it's worth doing, has a fleet of agents plus review discipline to ship it, while not letting the system collapse due to speed.

Gupta's conclusion leaves a clear choice: Engineers who internalize this will live through the most interesting decade in software history; engineers who continue to wait for tickets will watch the agents beside them process the tickets.