Why the old process existed, and why it worked

To understand where software development is going, it helps to understand where it came from. The waterfall methodology, requirements, design, build, test, deploy, wasn't a bureaucratic power grab. It was a direct import from manufacturing, where Henry Ford's assembly line had proven that predictable sequential steps produced reliable, scalable output. When applied to software in the early 1970s, it brought something valuable: discipline. For the first time, there was a clear spec to follow, a budget to hold to, and a structure that let non-technical stakeholders understand what was being built.

But software isn't a car. By the time the internet era arrived, waterfall's rigidity had become its fatal flaw. Requirements changed faster than a multi-year development cycle could accommodate. You'd build exactly what was specified, and it would arrive into a world that had moved on. Engineering teams grew exhausted under plans that couldn't flex.

So in 2001, seventeen software practitioners gathered in Utah and wrote the Agile Manifesto, four values and twelve principles that tried to put humans and adaptability back at the centre. Scrum, which had been formalised six years earlier by Ken Schwaber and Jeff Sutherland, emerged as the dominant framework for putting those values into practice. Sprints. Standups. Backlogs. Story points. The vocabulary became so ubiquitous that a generation of product and engineering teams grew up thinking it was simply how software was built.

And it worked. Not perfectly, the process introduced its own overhead and rituals, but well enough to become the global standard for shipping software across companies of every size and type. It solved a real problem: how do you coordinate large, distributed teams of expensive specialists across complex, uncertain work? The handoff model, PM to designer to engineer to QA, created clear ownership and visibility. The sprint gave teams a tempo. The ticket gave work a home.

"The sprint, the standup, the PRD, these weren't invented by people who loved process. They were invented by people who needed to coordinate scarce, expensive humans across complex work."

The system earned its place. The question now isn't whether it was good, it was. The question is whether the constraints it was designed around still apply.

Where the process actually breaks down

The honest critique of agile isn't that its values are wrong, they aren't. It's that the ceremonies designed to embody those values have, over time, become the opposite of what they intended. The agile manifesto explicitly valued "working software over comprehensive documentation." Decades later, teams spend hours in sprint planning sessions producing comprehensive documentation about what working software they plan to build.

The deeper structural problem is timing. The entire process front-loads thinking into a phase before anyone has real information. A PM writes a specification based on user research, assumptions, and stakeholder input. A designer translates that into wireframes. An engineer picks up a ticket three weeks later and begins building against a document that was always, to some degree, a fiction, a confident guess about what good looked like before the work began.

The spec is not a bad idea badly executed. It is a structurally flawed idea. No document written before implementation can survive contact with implementation. Code reveals constraints, edge cases, and opportunities that no amount of upfront research can fully anticipate. The engineer isn't failing when they build something different from the spec. The process is failing by treating the spec as truth.

There is also the problem of translation overhead. Most PMs are non-technical, intentionally so, to maintain user focus rather than implementation bias. But this means every requirement must be re-encoded as it passes from PM to designer to engineer. Context degrades at each handoff. Intent gets lost in the gap between what was meant and what was understood. The ticket, which was supposed to capture that intent, often captures only a shell of it: the what, without the why or the what-if.

Story points, perhaps the most widely criticised artefact of agile practice, illustrate the problem perfectly. Designed to estimate complexity rather than time, they are almost universally converted back into days by teams trying to make sprint commitments. As one industry observer noted, they were designed to avoid the planning fallacy, yet teams inherit it anyway by a different name. The ceremony absorbs hours. The output, a sprint backlog, is a plan that everyone on the team privately expects will change by Wednesday.

What AI agents actually make easier

Coding agents have arrived faster than most anticipated, and their adoption numbers are striking. But the headline statistics obscure something important about how they're actually being used, and where the real opportunity lies.

The majority of developers using AI tools today are using them as faster autocomplete: generating boilerplate, scaffolding functions, writing tests, drafting documentation. These are meaningful gains. Developers report saving an average of 3.6 hours per week, and daily AI users are merging roughly 60% more pull requests. At Google, roughly a quarter of new code is now AI-assisted. These aren't trivial numbers.

But the more significant shift is in what agents can now do with the right context. Tools like Cursor, GitHub Copilot's agent mode, and Claude Code can now take a problem statement and handle multi-step execution across files, run tests, interpret errors, and iterate, without a human manually directing each step. This isn't autocomplete. It's a fundamentally different interaction model where the agent takes a goal and figures out the tasks itself.

This matters enormously for the old process. If an agent can decompose a problem, scaffold an implementation, and surface the decisions it cannot make alone, then the primary value of a ticket is eliminated. The ticket existed to package work so it could be handed to a human who needed clear, bounded instructions. Agents don't need that packaging in the same way. They need intent and context, not pre-decomposed subtasks.

The parts of the process that become dramatically easier with capable agents:

• Code implementation, boilerplate, scaffolding, repetitive patterns

• Testing and QA, test generation, edge case coverage, regression checking

• Bug triage, reproducing, localising, and often fixing reported issues

• Documentation, generating, updating, and keeping in sync with code

• Ticket decomposition, breaking large pieces of work into executable steps

• Code review prep, summarising changes, flagging risks, suggesting improvements

What this means in practice: the engineering bottleneck that the entire agile process was designed to manage is no longer as scarce as it was. Writing code is getting cheaper. The constraint is shifting upstream, to the quality of intent, and downstream, to the quality of judgment applied to the output.

How software development teams are actually evolving

The team structures emerging around agents don't look like what most thought leaders predicted. The narrative of "agents replace engineers" hasn't materialised, demand for human developers has remained strong, even as AI generates an increasing share of code. What is changing is what the job requires.

Job postings for pure implementation roles, developers whose primary skill is translating specifications into code, have declined meaningfully. Job postings requiring experience with AI coding tools and the ability to orchestrate and review AI-generated work have risen sharply. The most valued engineers in 2026 are not the fastest typists, they are the ones with the architectural judgment to evaluate what an agent produces, and the contextual awareness to know when to override it.

At the PM level, a convergence is beginning. As AI automates more of the mechanical PMM tasks, competitive analysis, user story formatting, metrics reporting, the distinction between product marketing and product management is blurring. The role that remains irreducibly human is the one that synthesises technical constraints, user needs, and business priorities into a coherent direction. That is not a task agents handle well, because it requires judgment across domains that don't reduce to patterns in training data.

One telling data point: developers show the most resistance to AI handling "deployment and monitoring" (76% don't plan to use AI for this) and "project planning" (69% resist AI involvement). These aren't just technically complex areas, they are the areas with the highest accountability and consequence. Teams are instinctively keeping humans at the decision points that carry real risk. That instinct is probably correct.

Linear, whose product is built for exactly this transition, recently noted that coding agents now appear in over 75% of their enterprise workspaces, with agent-authored issues growing 5x in a single quarter. This isn't a distant future, it is the current state of software teams at the frontier, right now.

The parts of the process that no longer need to exist

This is the uncomfortable part. Some of what teams do today, genuinely, as a matter of daily routine, doesn't survive as a useful activity in an agent-native workflow. Not because it was ever pointless, but because it was serving a coordination function that no longer needs serving in the same way.

The honest pros and cons of this shift are worth naming. The upside is enormous: teams that redesign around agents can move faster, with less overhead, and with tighter feedback loops between intent and production. The downside is less discussed. When agents handle execution, the quality ceiling is set by whoever is defining the intent and reviewing the output. If that judgment is weak, if the problem statements are vague, or the design taste is poor, agents will faithfully execute mediocrity at speed. The new bottleneck is human quality, not human capacity.

There is also a trust problem that hasn't fully resolved. Only 29% of developers report trusting AI output without verification. That gap between adoption and trust is creating a new kind of overhead: the human-in-the-loop review bottleneck. As one practitioner observed, an agent can generate 10,000 lines of code overnight, but a team might only have capacity to securely review 1,000. The old bottleneck (writing code) has been replaced by a new one (reviewing it). Teams that ignore this will build up an unmerged PR backlog just as damaging as the old sprint carryover.

What a new process looks like, from first principles

If you stripped away every inherited assumption and asked what a software development process needs to do, the answer is deceptively simple: capture intent clearly, route it to the right actor, and close the feedback loop fast enough that you can correct course before it matters.

The current system does none of these particularly well. Intent degrades through handoffs. Routing to the right actor requires a full sprint planning ceremony. Feedback loops are measured in weeks, not hours.

The new system is built around a different unit of work. Not the ticket, the outcome. Not "build a login page with these fields" but "users need to authenticate securely and with minimal friction." The agent figures out what the tasks are. The human decides which outcomes to pursue and whether the results are right.

How does this system interact in practice? Not through a dashboard you check, but through a system that is ambient and surfaces to you at the moments that require a decision. You define a problem. The system proposes an approach and asks one clarifying question. You come back when it needs a call you're better placed to make, a product tradeoff, a design judgment, a priority conflict. The rest runs.

This is, in rough outline, what companies like Linear are building toward, a shared product system where context flows from customer feedback through to production without degrading at every handoff. The insight in their recent announcement is exactly right: agents are not mind readers. They become useful through context. The system's job is to hold and preserve that context so nothing has to be re-explained, re-specified, or re-negotiated at every step.

But the system is only as good as what goes into it. The new job for founders and startup teams is not managing process, it is being the taste and judgment layer that the system executes from. Writing good problems, not good specs. Setting clear intent, not detailed requirements. Reviewing output against what matters, not against what was planned.

Teams that get this right early will compound the advantage as agents become more capable. The process they design now, the habits, the context structures, the judgment loops, will scale with the technology. The teams that bolt agents onto the old process will get faster at doing the wrong things, and hit the same ceiling they always did: not capacity, but clarity.

"The teams that win won't have the most agents. They'll have the clearest intent, the fewest judgment loops, and the sharpest taste."

The ticket isn't dead. But the idea that coordination overhead is unavoidable, that the process must always be this complex, that's what's changing. The conditions that made the ticket necessary are shifting. The process can shift too.