Faster coding can leave the delivery constraint untouched

Two survey signals can both be true

Atlassian's 2026 State of Developer Experience report describes a survey of more than 1,500 software practitioners overall. Its first-party analysis says 87% of developer respondents felt AI helped them ship work faster, while 72% of developer respondents experienced the same or more friction than before AI. These are self-reported perceptions in a vendor-sponsored study, not instrumented cycle-time measurements or a causal comparison.

The numbers are not necessarily contradictory. A developer can finish a coding step faster while accepted delivery remains limited by discovering requirements, finding system context, reviewing changes, resolving incidents or coordinating decisions. More output can increase work arriving at a downstream queue. If the receiving capacity stays fixed, elapsed delivery time may not fall and can rise.

Atlassian's analysis also reports a fall from 68% in 2025 to 25% in 2026 in the share saying they saved at least ten hours per week. The opened sources do not establish that the annual samples, questions or weighting are identical, so this is a reported comparison rather than a measured within-person decline. TechRadar repeats the comparison and lifecycle framing but does not reproduce the survey.

Draw the constraint map

Choose one representative work class: a small defect, a routine feature or a production change. Mark each boundary from request to accepted operation: clarification, design, implementation, test, review, release, observation and remediation. For each stage, record active work time, queue time, abandonment, rework and the person or system that can approve movement.

Keep AI-assisted and unassisted work comparable by size, risk and team. A raw count of pull requests rewards fragmentation; lines of code reward volume; model acceptance rate says little about production consequence. The useful denominator is accepted work of a defined class. Include review comments, escaped defects, rollback and operator attention so faster drafting cannot hide shifted labour.

Then identify the binding constraint. If engineers wait for architectural context, improve retrieval and ownership. If reviewers face a larger queue, narrow change size, improve tests or add review capacity. If requirements change repeatedly, faster code may simply create more discard. If production validation dominates, invest in observable acceptance criteria and rollback. The intervention should follow the measured bottleneck, not the step with the most visible AI feature.

The countercase is that local acceleration still matters. It can release capacity for tests, design and maintenance. Verify whether that capacity actually moved: sample time allocation before and after adoption, and inspect whether queues and rework changed. A claimed saving that becomes more simultaneous work is not automatically lost, but it is a different operating result.

Predeclare the observation window and change threshold. Weekly volatility, release freezes and incident weeks can dominate a short sample. Keep the same work-class definition and report medians with tails so a faster ordinary case does not conceal a growing set of slow exceptions.

This builds on the newsroom's earlier workflow-depth analysis. The immediate decision is to run a four-week constraint map for one work class before purchasing another coding-speed tool. The survey is a warning about measurement scope, not proof that AI coding tools fail. The question is where the system now waits.