AI product development: it's an authoring problem, not a review problem

When you're developing software with AI, the quality problem starts at authoring, not review. Review, testing, and QA still matter, but adding more gates downstream can’t compensate at scale for code that was authored without the context needed to make it correct. It only shifts the pileup to the review queue. The biggest gains come from giving AI the product context it needs while the work is being authored, not after it reaches review.

AI collapsed the cost of writing code, and when execution gets that cheap, the bottleneck moves somewhere else. It moves to coordination. Teams can now generate code faster than they can supply the context to get it right. The throughput charts look great, while the trouble accumulates downstream: review queues back up, defects increase, and incidents reach production. Pointing more review at the problem treats a coordination gap as an inspection gap. Inspection tells you what's wrong after the fact. It doesn't give the work the context it needed to be right in the first place.

Faros AI analyzed two years of telemetry from 22,000 developers across more than 4,000 teams, tracking each organization between its lowest and highest AI adoption.

The throughput gains were real:

• Epics completed per developer up 66%.

• Task throughput up about 34%.

• Pull request merge rates increased 16%.

But the costs appeared downstream:

• Bugs per developer increased 54%.

• The incident-to-PR ratio more than tripled.

• Code churn increased 861%.

• Review times increased several-fold.

• 31% more pull requests merged without review.

Faros calls the pattern Acceleration Whiplash: throughput rises while quality and coordination costs climb with it. Its report argues that the problem needs to be addressed at the point of authorship, rather than relying on review to catch problems later. In other words, the quality problem already exists by the time the code reaches review.

That framing is Faros’s. Our more specific conclusion is that one important thing the work is missing is the product’s meaning, captured somewhere the agent can reach it. It’s worth keeping those claims distinct.

Review is a filter. It catches what's obviously broken and passes what looks right. As AI authors more of the code, two things happen at once: the volume arriving for review grows beyond what humans can absorb, and more of that volume is almost right. Almost-right output is plausible. It follows common patterns, compiles, and may work in a demo. But it can still misunderstand the product, overlook an edge case, or violate a decision that was never included in the task.

You can add reviewers, QA passes, tests, and gates. They remain essential safeguards. But none of them changes the input the AI authored from.

I've shipped almost-right code. Everyone reading this probably has. It passes review, works in the demo, and falls over three weeks later when a real user does the thing nobody thought to specify.

Almost right is worse than wrong. Wrong gets caught. Almost right gets shipped. Wrong output fails loudly in review. Almost-right output passes, then costs a senior engineer a week to unwind once someone hits it.

DORA’s conclusion points in the same general direction. Its 2025 report, based on a survey of nearly 5,000 technology professionals, describes AI as a mirror and a multiplier. It amplifies the strengths and weaknesses of the system around it. AI doesn’t improve software delivery in isolation. Its value depends on the capabilities and practices already present in the organization, including the systems that provide people with information, support, and feedback. That’s not identical to our claim, but it supports the same underlying principle: the environment surrounding the work shapes the quality of the output.

The Context Gap Report from Refactoring.fm makes the problem more concrete. Based on a 2026 survey of 350 respondents, it found that only 8% of engineers said a ticket gives them what they need to start work. The context an agent needs to author correctly is not always inaccurate. Often, it was never written down, is spread across several tools, or is no longer current. Retrieval can’t return knowledge that doesn’t exist in a usable form.

If quality starts at authoring, the part of your stack that matters most is the authoring surface: the place where intent becomes executable work. This is where teams define what should be built, resolve ambiguity, record terminology, decisions, constraints, and acceptance criteria, turn product intent into buildable work, and make that context available to both people and agents. This is the same instinct behind spec-driven development: put the meaning in front of the work rather than inspecting for it afterwards.

Most teams spread this work across trackers, source control, documents, chat, and individual memory. Jira tracks the work. GitHub owns the code. Notion holds documents. Each tool may contain part of the picture, but the agent still has to reconstruct the product’s meaning from fragments.

The authoring surface is where those fragments become connected, buildable context. This is the category Atono is built for.

In Atono, the story becomes the hub for work. The specification and decisions behind it remain connected to the product terminology, related work, feature flags, and usage data that give the story meaning.

Agents author from your Product Knowledge:

• The Glossary defines the concepts in your product and how they relate.

• Living Stories carry the decisions and intent behind the work.

• MCP makes that context available to connected AI tools through an open standard.

The result isn’t code that no longer needs review. It’s work authored from a clearer understanding of what the product means, so reviewers have less missing context to reconstruct and fewer assumptions to catch downstream.

You don't have to replace your current tools to begin. Most teams start with the low-friction approach: using Atono as an Intelligence Layer beside their existing stack. They can add Product Knowledge without beginning with a full migration. That gives people and agents access to shared product context while the team continues using its existing tools for code, documentation, and delivery. Over time, the authoring surface can expand as it proves its value, one team and workflow at a time.

The future isn't simply more review. It's work authored with enough meaning that less interpretation is required downstream. Review, testing, and QA will remain essential, but the teams that get quality from AI will not rely on gates alone. They'll be the ones that move more context upstream, to where the work is defined and written.

Is AI code quality a review problem or an authoring problem?

It starts as an authoring problem. Faros's telemetry across 22,000 developers shows code volume increasing while quality and coordination measures worsen. Review can’t sustainably compensate for a growing volume of work authored from incomplete context. The greatest opportunity is to improve the information available when the work is defined and created.

Does adding QA and reviewers fix AI output quality?

Review and QA remain essential safeguards, but they don’t address the entire problem. They evaluate output after it has been produced. They can’t correct the incomplete terminology, decisions, constraints, or acceptance criteria that shaped the output in the first place. As AI increases the volume of authored work, downstream controls need to be supported by better context upstream.

What does "authoring context" mean in practice?

Authoring context is the product's meaning made available where work is written. It includes terminology, user needs, product decisions, architecture, constraints, and acceptance criteria. It should be accessible to both people and agents while they’re defining and building the work, not reconstructed after the fact.

Why isn't Jira enough for AI-assisted development?

A tracker records that work exists and helps a team manage its status. But the meaning behind the work is often distributed across documents, conversations, code, and individual memory. Retrieval can help an agent find what has been written, but it can’t return decisions that were never captured or determine which conflicting information is current. An authoring surface needs to carry intent, not only status.