In December 2025, Large Language Models crossed a significant threshold. They became good enough to carry the median software engineering task to acceptable quality. According to METR, in Feb-Apr 2026 developers have reported a median productivity increase of 2x. With some outliers reporting between 10x and 20x. A paradigm shift that has been acknowledged by Andrej Karpathy too.

Three observations follow as the industry adapts to this new reality:

1. The unit of work has grown: Software developers used to execute tasks within a specific tech stack, turning product specifications into code. Today, they are increasingly asked to take more ownership, either horizontally like covering more technical ground such as system design and architecture, or vertically like owning product features end-to-end. “Write this function, fix this bug” is being absorbed by the model. The unit of work moved one level up the stack: deciding what the feature is, why it exists, how it fits, and how the system architecture around it should be designed.
2. The cost of coordination starts to exceed the cost of building: When building was expensive, the cost of coordination was collateral. With building compressed, coordination becomes the expensive bottleneck. See Andrew Ng slide on Stanford CS230 | Lecture 9: Career Advice in AI. In our view, Cost of Coordination = the time spent on meetings + the time lag between decision and execution + the cost of loss opportunity witnessed during this time.
3. As a result, team topologies are reorganizing: Smaller teams with broader scope produce more coherent output at a faster pace compared to larger groups with narrow scope.

The persona emerging from this shift is the product engineer: someone who can hold a product question and a technical question in the same head, that can orchestrate agents under lenses, and that can learn and adapt quickly to the continous shifts in customer demand and technology landscape.

Product

The ability to think on behalf of the customer and translate their needs into product heuristics and specifications.

Think like a Product Manager

Engineering

The ability to translate ambiguous product specifications into high-quality technical architectures and rich specifications, harnessing the speed of coding agents without sacrificing output quality.

Think like an Architect and CTO

This rearrangement is creating new problems the industry is still discovering and understanding. Quality drifts when multiple agents ship in parallel without a shared sense of intent. Scope creeps because building is cheap. Ownership distribution and work orchestration across these new functions. Quality assurance and functional testing require a completely new approach to cover the increased output without losing customer trust. Cat Wu (Head of Product, Claude Code) names this directly in her Lenny’s podcast interview: “What gets sacrificed when you ship so fast”.

We observed that the tools already existing in the industry are good at coordinating how to build. They are largely silent on why and what to build, which is precisely the coordination work that now matters most.

Productmind is our hypothesis on how to close that gap. We believe the product engineer needs a centralized product mind: a system that can learn from customers, remember why a feature exists, who asked for it, what shape it should take, and how it connects to everything around it.
Context that should be maintained and packaged to ground coding agents and increase their output consistency at scale, while allowing Product Engineers to keep full control and accountability. Speed at 10x is also drift at 10x, unless quality and intent are held with the same care.

We have a long list of assumptions we are committed to validate. We will keep publishing what we learn, what holds, what we got wrong, and what surprised us.

If our thoughts resonate with how your own work is changing, we would like to hear from you.

Book a demo and join the beta!

— Steen & Alessio.