We Are Product Builders Now

A few nights ago I autoshipped 35 tickets. My pipeline takes a ticket, has an agent implement it, and pushes the change through tests and review gates. I went to sleep. The pipeline did not.

In the morning I opened the laptop and could not tell you what had changed. Not the code. The basics: what each change did, for whom, and why it was worth doing.

In July I wrote that the implementation can autoship from an approved spec. That is still true. What I had not priced in was the morning after. The machine did its job. I had not done mine.

The old deal

For most of my career I was the engineer who learns a new domain just enough to move. Get the big picture, connect the dots, start building. In my head the number was about 30%: enough to ask the right questions, design the system and write the code.

The other 70% stayed unknown for a good reason. There was no time. Coding, architecture and infrastructure ate the week.

That deal is over, and the reason can be measured. METR, a research group that evaluates frontier models, times how long a task takes a human expert and checks which tasks an agent can finish on its own. In March 2025 it reported that this time horizon had been "consistently exponentially increasing over the past 6 years, with a doubling time of around 7 months." Its updated task suite puts the doubling at about 131 days since 2023. The horizon is the task length at which an agent succeeds half the time. In METR's own data, Claude 3.7 Sonnet reached tasks of about an hour in February 2025. Claude Opus 4.6 reached about twelve hours a year later.

Then the ruler ran out. METR now warns: "Measurements above 16 hrs are unreliable with our current task suite." The horizon is a measure of how hard a task is for a human, "rather than the time an AI spends to complete the task," and the tasks are mostly software. That is exactly the part of my job that keeps getting longer.

So I hand the work off and go to sleep. A Ralph loop, Geoffrey Huntley's technique that in its purest form is a Bash loop around the agent, keeps it working through the night.

The hours that went to typing are free now, and the excuse went with them. My new number is 80%, at least: the workflows, the exceptions, the reasons behind the rules, and what it costs the business when we get one wrong.

Don't be a pipe

Here is the version of my job I want to get rid of. Information arrives from chat, from email, from a ticket, from a cleanup list. I add a little of my own thinking. I hand it to an agent. I pass the result back.

That is a pipe. A pipe has an obvious upgrade: an automatic pipe. Anything that only routes will be routed by software.

The question that matters is what changes because the work passed through me. Did I notice that the ticket treats a symptom? Did I connect it to the same failure somewhere else? Did I kill a feature because it would cost more to maintain than it returns? Did I ask the customer question nobody had asked?

"The agent wrote it" explains how the code appeared. It does not explain why the change was made, and it is no longer an excuse for not knowing.

Anthropic surveyed 132 of its own engineers and researchers last year. They estimated that "27% of their Claude-assisted work wouldn't have been done without it," and one of the report's findings is that "Everyone is becoming more 'full-stack'." The same report names the trap, the "paradox of supervision": supervising Claude takes the coding skill that leaning on Claude can wear down. One respondent estimated their work had shifted "70%+ to being a code reviewer/reviser rather than a net-new code writer." Another saw "taking accountability for the work of 1, 5, or 100 Claudes" as part of their future role.

Accountability is the word that matters. A pipe has none.

Ten, not thirty-five

Thirty-five tickets in one night was the wrong scale for me. About ten is right: ten I can explain exactly. Not every line of code. Every decision: what it changes, why it exists, what proves it works, what it could break.

That takes time, and I now budget for it. Up to half of my working time goes into understanding what the agents did. It is not overhead around the job. It is the job.

Faros AI, a vendor of engineering analytics, reported higher output alongside longer review times. Its 2025 report drew on telemetry from over 10,000 developers, most of whom used only autocomplete features. On teams with high AI adoption, developers completed 21% more tasks and merged 98% more pull requests, and PR review time went up 91%. Faros found "no significant correlation between AI adoption and improvements at the company level."

Passing tests is not the same as understanding either. In a METR study of 18 real tasks from two large open-source repositories, a Claude 3.7 Sonnet agent passed the maintainers' tests 38% of the time. When METR reviewed 15 of its pull requests by hand, "none of them are mergeable as-is." Developers' trust is conditional: in Stack Overflow's 2026 survey, the most common answer to how far they trust AI output was "I trust it when I can easily verify the output," at 48%. And our own sense of speed is a poor guide. In METR's early-2025 trial, developers took 19% longer with AI and still believed it had sped them up. METR now says: "These results are out of date." I covered the trial and its 2026 follow-up in Know the Code, Write the Spec.

The product builder

For as long as I have worked in software, a product team had separate seats: engineer, product manager, designer, data scientist. Each seat owned a slice, and context leaked at every handoff.

Agents change the economics of those seats. An engineer can explore interface options and analyze usage data. A product manager can build a working prototype. A designer can ship the interaction instead of a mockup of it.

The change already has job titles. In August 2025 LinkedIn's chief product officer at the time, Tomer Cohen, wrote that "The Full Stack Builder (FSB) is a new archetype" and announced an Associate Product Builder program in which "builders will not just write specs. They'll build end-to-end, from idea to launch." At Miro's Canvas 26 conference this year, he put it more bluntly: "The lines do not make sense anymore." Instagram now hires for a title called Member of Product Staff. The posting describes "small, talent-dense teams of product builders, engineers, designers, and data scientists" whose members "create directional design, analyze data hands-on, and leverage AI tools to move faster with fewer handoffs."

I think the seats merge into one role, and product builder is the right name for it: one person who owns a problem end to end. Agents cover the gaps. Your strengths are what you push through the agents.

AI-native does not mean deferring everything to AI. It means stepping up to product thinking and knowing exactly how to direct different agents to do different jobs.

The path is not new. A programmer starts out loving code, and years later the same person is doing architecture, system design and, eventually, the business. I expect agents to pull that path forward. They give access to the wider work sooner. The judgment it needs still has to be earned.

This is a prediction, and it has limits. Excellent specialists still matter, most of all where errors are hard to detect or expensive to repair. Breadth should make specialist judgment easier to apply. It should not make expertise invisible.

What stays human

Three things, for now:

• Finding the right problem before anyone writes a ticket for it.
• Thinking hard about the business and the customer, not only about the code.
• Knowing exactly what your agents did, and being able to defend it.

Once a problem is precise and specific, agents take more of it every few months. The hard, unstructured part moves the other way. Anthropic's January 2026 Economic Index found that the most complex tasks people bring to Claude tend to be the ones where it struggles most. Rather than displacing highly skilled professionals, Anthropic writes, this could "reinforce the value of their complementary expertise in understanding AI's work and assessing its quality."

So the tools you use say less about you than they used to. Better questions: Do I think independently? Do I catch problems before they are assigned? Can I reason about design and the business, not only engineering? Do I change my mind when the evidence does?

Not only software

The same shift is visible outside engineering. McKinsey is counting agents as staff. On HBR IdeaCast in January 2026, McKinsey's global managing partner Bob Sternfels described his firm as "40,000 humans and 20,000 agents." He also said what the models lack: "there's not judgment in the model. Humans need to impose those parameters." He expects clients to do for themselves much of the work McKinsey used to do for them, and the firm to "move to the even more complicated questions."

The labor data fits the same pattern, and it is uneven. Stanford's Digital Economy Lab tracks payroll data, and its August 2026 note is headlined "No Widespread Displacement, but the AI Employment Gap for Young Workers Has Widened to 19%." Employment of workers aged 22 to 25 in highly AI-exposed occupations "now stands about 19% below where it would be if it had kept pace" with peers in less-exposed occupations. The authors draw a distinction between two kinds of knowledge. Employment declined among young workers in occupations that rely on "codified knowledge," and rose among experienced workers in occupations that rely on "tacit knowledge acquired through practice, mentorship, and repeated exposure to real situations." They stress that these are "descriptive patterns, not causal estimates of the effect of AI." Even so, that distinction is the clearest statement of this article's thesis I have found.

Where agents can do the work, making the artifact can get cheaper. Establishing that it is right and useful still takes judgment.

The culture it needs

Broader ownership only works where people can exercise judgment.

Tough questions are a feature. The hard conversations are where the real work is. People need room to question both weak plans and weak agent output. That matters more now, because a questionable decision can get a working interface and passing tests before anyone has examined its premise.

Feedback in real time. Expectations should be clear, and gaps should surface while someone can still act on them. Nobody should discover at a year-end review that they were measured against a standard nobody stated.

Process earns its place. A daily status ritual that adds nothing can go. Longer cycles give people time to understand a domain and think. Removing a ritual creates an obligation to share the useful information some other way.

Small teams on purpose. I would rather see a few strong builders, each directing many agents, than a team that grows its headcount and shrinks later. Shopify's CEO made a version of this explicit in April 2025, telling teams they "must demonstrate why they cannot get what they want done using AI" before asking for more headcount. Lovable passed $400 million in annual recurring revenue in February 2026 with 146 full-time employees, and it now plans to grow its headcount. The bet holds only while agents stay reliable and affordable.

Make understanding cheap for others. I have started replacing long generated documents, which nobody reads, with short explainer videos like the one at the top of this page.

The morning-after check

The objections

"So one person does two roles' work." Calling someone a builder does not create more hours. The trade only works if typing and boilerplate actually leave the week. Review time counts as work. Learning the domain counts as work. Killing a feature counts as a result.

"Specialists are not going away." Agreed. A deep specialist can own a narrow, hard problem end to end and help every other builder see the limits they would miss.

"Agents are not free." Usage limits and cost are real constraints, and a tool that fails at its one job is too expensive at any price. A small team that bets on agents has to keep measuring that bet.

"This is a prediction." It is. If agents stopped getting better at long tasks, or if checking their work stayed as expensive as doing it, the case for one role would weaken. The first is not what the evidence shows today. The second is the open question, and it is why I budget up to half of my time for it.

The job will change

I started as a skeptic. Now I think the future is bright, and that it means adapting.

My next overnight batch is ten tickets. Before I queue the one after it, I will be able to explain every one of them.

Sources

• METR: Measuring AI Ability to Complete Long Software Tasks, 19 March 2025; Time Horizon 1.1, 29 January 2026; Task-Completion Time Horizons of Frontier AI Models and its results file; Research Update: Algorithmic vs. Holistic Evaluation, 13 August 2025; Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, 10 July 2025.
• Geoffrey Huntley: Ralph Wiggum as a "software engineer", 14 July 2025.
• Anthropic: How AI is transforming work at Anthropic, 2 December 2025; Anthropic Economic Index report: Economic primitives, 15 January 2026.
• Faros AI: The AI Productivity Paradox Report 2025, July 2025.
• Stack Overflow: 2026 Developer Survey, trust in AI.
• Tomer Cohen: Bringing the Full Stack Builder to Life, LinkedIn, 4 August 2025; Miro: The full-stack builder and the new shape of the product organization, Amy Hsuan, 22 July 2026.
• Meta Careers: Member of Product Staff, Instagram, read 18 October 2026.
• HBR IdeaCast: Where McKinsey—and Consulting—Go From Here, January 2026.
• Stanford Digital Economy Lab: No Widespread Displacement, but the AI Employment Gap for Young Workers Has Widened to 19%, 12 August 2026.
• TechCrunch: Shopify CEO tells teams to consider using AI before growing headcount, 7 April 2025; Lovable says it added $100M in revenue last month alone, with just 146 employees, 11 March 2026.