For twenty years, software engineering has been organized around an implicit assumption:
The hard part is before the code.
You write tickets. You estimate. You plan sprints. You decompose work into stories, assign points, debate scope.
Then — finally — someone writes the code.
The entire tooling industry was built on this premise. Jira. Linear. Asana. Notion boards. All of them sit between the intent and the implementation, managing the gap.
Well, that gap is now closing, thanks to AI.
What we were really doing
The old model looks like this:
Intent → Ticket → Assign → Decompose → Implement → Review → Ship
Every step between intent and implementation exists because coding was expensive.
A senior engineer’s time was scarce, so you needed to make sure they worked on the right thing. You planned meticulously because mistakes were costly to undo. You estimated because stakeholders needed predictability.
You decomposed because large tasks were too risky to hand to one person without a map.
Planning was a hedge against the cost of building.
Sprint ceremonies, story points, backlog grooming — these aren’t engineering practices.
They’re risk management rituals.
Rituals designed for a world where implementation is slow and expensive.
What happens when it isn’t?
The collapse
Today, an AI coding agent can take a well-stated intent, spin up an isolated branch, implement a feature across multiple files, write tests, and open a pull request.
Not in days. In minutes.
The new model:
Intent → Agent implements → Review → Ship
Look at what shrinks: planning, estimation, task decomposition, sprint ceremonies, assignment.
The entire coordination layer that justified project management tooling is compressing toward zero.
And look at what grows:
review
evaluation
architectural judgment
integration testing
outcome validation
The bottleneck has flipped.
We no longer spend most of our time figuring out what to build and who should build it. We spend it evaluating whether what was built is correct, coherent, and aligned with the system it lives in.
This isn’t a minor shift. It inverts the value chain.
After the code, not before it
In the old world, a senior engineer’s most valuable contribution was in planning. The architecture doc. The task breakdown. The technical design review before any code was written.
In the new world, their most valuable contribution is after the code exists.
Can this agent’s output actually be trusted? Does it fit the existing architecture? Did it introduce subtle regressions? Does it handle edge cases the agent couldn’t anticipate?
Is it maintainable by the next human — or agent — who touches it?
These questions require deep system knowledge. Taste. Judgment. They can’t be reduced to a checklist.
And they happen after implementation, not before.
The irony is that we’ve always known code review matters. We just treated it as a gate rather than the main event.
Now it is the main event.
What dies, what survives
What dies:
Story points and estimation — when implementation costs minutes, estimation is overhead
Sprint planning as a ritual — the cadence was built for human implementation speed
Ticket management as a profession — the coordination layer between intent and code is shrinking
Backlog grooming — infinite backlogs made sense when each item took days; now you can just try it
What survives — and grows:
Architectural judgment — someone still needs to know what the system should look like
Code review and evaluation — the primary quality gate shifts from planning to review
Intent clarity — garbage in, garbage out applies even more when agents execute instantly
Integration and system thinking — individual features are cheap; coherent systems are not
What transforms:
The PM role shifts from “plan the work” to “evaluate the output”
The senior engineer shifts from “design the solution” to “judge the solution”
The standup shifts from “what are you working on?” to “what did the agents produce, and is it right?”
What this means for tools
If this analysis is directional, then the next generation of developer tools should optimize for review, not planning.
That means:
Diff-centric workflows instead of board-centric ones
Automated quality signals — test coverage, architectural fit, complexity metrics — surfaced at review time, not sprint time
Agent output dashboards rather than sprint dashboards
Intent-to-outcome traceability instead of ticket-to-PR traceability
Jira was built for a world where the constraint was coordinating human effort toward correct implementation.
The new constraint is evaluating machine output for correctness and coherence.
The tools that win will be the ones that help humans do that faster and better.
The artifact nobody wanted to write
There’s a quiet practice that turns out to be surprisingly well-suited for this new era.
Architectural Decision Records.
ADRs are short documents — typically living in the repo — that capture why a decision was made. The context. The options considered. The rationale for the choice.
They were originally a documentation practice. Something teams knew they should do but rarely prioritized. Who has time to write a decision record when there are sprints to run?
But something interesting happens when you put ADRs in front of AI agents.
Agents can read them. They can implement against them. And — critically — reviewers can validate agent output against them.
Did the agent respect the constraint we documented? Did it follow the pattern we chose? Did it violate a trade-off we explicitly considered?
This is what tickets never were.
A Jira ticket says what to build. An ADR says why we build it this way.
The ticket is consumed during implementation and becomes dead weight.
The ADR persists and compounds — useful during implementation, during review, during the next feature that touches the same boundary, and during onboarding six months later.
In the old model, ADRs felt like overhead.
In the new model, where implementation is near-instant and the constraint is judgment, they become the primary artifact.
The codified form of architectural reasoning.
The thing that makes review meaningful rather than perfunctory. They give reviewers a reference frame. They give agents a constraint set.
If tickets were the artifact of the planning era, ADRs might be the artifact of the review era.
Closer to the code
There’s a broader pattern here.
AI coding agents live in the repo. They read files, write code, create branches, open pull requests. Their entire world is the codebase and its surrounding context.
Yet we still keep their task context — the what and why of the work — in a completely separate system. A SaaS board. A ticket database. An API call away.
This made sense when humans were the primary consumers of task information. Humans need dashboards, drag-and-drop boards, notification emails, mobile apps.
Agents don’t.
Agents need context where they already are: in the repository.
A markdown file with clear intent. A decision record with constraints. A task description co-located with the code it affects.
The further task management infrastructure sits from the code, the more translation overhead there is — for agents and for the humans reviewing their output.
When an agent’s task lives in Jira and its implementation lives in Git, the reviewer has to mentally bridge two systems to evaluate whether the output matches the intent.
When both live in the repo, the feedback loop tightens. The agent reads the task, implements it, and the reviewer sees task and implementation side by side.
This isn’t a radical idea. It’s where the gravity is already pulling.
CLAUDE.md files. TASKS.md. ADRs in /docs/decisions/. These are all early signals of task context migrating into the repository.
The tools followed the humans into the browser. Now they need to follow the agents into the repo.
The career question
This isn’t just a tooling argument.
It’s a career argument.
If you’re an engineer who derives your value from being a fast implementer — from translating tickets into code efficiently — you are now competing with agents on their strongest axis.
If you derive your value from judgment — from knowing why a system is shaped the way it is, from catching the subtle architectural drift that no test suite will flag, from saying “this works but it’s wrong” — you are more valuable than ever.
There’s an irony here that cuts against the dominant narrative.
For years, the industry has been asking: will AI replace developers?
But what’s actually happening is closer to the opposite.
In the old model, developers were increasingly commoditized. Ticket takers. Spec implementers. The better the PM wrote the requirements, the less the developer’s judgment mattered. Agile, for all its good intentions, made developers more interchangeable — not less.
Now the commodity part — the implementation — is handled by agents.
What remains is the part that was always undervalued because organizations optimized for throughput: architectural judgment. System understanding. The ability to look at working code and say this is wrong.
AI isn’t replacing the developer.
It’s removing everything that wasn’t really engineering in the first place.
And the people who always cared more about getting it right than getting it done?
They’ve been training for this moment their entire career.
The paradox, again
I wrote previously about the Bainbridge paradox — how automation doesn’t eliminate the need for expertise, it eliminates the opportunity to develop it. (See: “AI, Jobs, and the 40-Year-Old Paper We Forgot to Read.”)
The same dynamic is at work here.
If engineers stop planning, decomposing, and estimating, they lose the practice that builds system understanding. The muscle atrophies.
But there’s a more hopeful reading.
If that freed-up time goes into review — deep, architectural, critical review — engineers may develop better judgment than the old planning rituals ever produced.
Planning was always partially theater. Review, done well, is not.
The question is whether teams make that investment. Or whether they let the review step become as perfunctory as the old “LGTM” culture.
If review becomes rubber-stamping agent output, the Bainbridge paradox wins.
If it becomes the primary site of learning and quality, we come out ahead.
The tool choices we make now will shape which path teams take.
What comes next
We’re in the awkward middle.
Most teams still use Jira or Linear. Most standup rituals haven’t changed. The tools are legacy, but the workflows haven’t caught up.
That won’t last.
The teams that adapt first — that reorganize around review rather than planning, that invest in evaluation infrastructure rather than coordination infrastructure — will move faster and ship better.
The question isn’t whether ticketing dies.
It's whether we replace it with something better — or just let the gap fill with noise.
The teams that treat review as their core engineering practice, not an afterthought, will build things that work.
The rest will ship fast and debug forever.