AI Coding Speed vs. Engineering Quality: Where Work Moves

Decision Brief: AI Coding Moves the Bottleneck, Not the Responsibility

AI coding can turn a carefully described feature into a plausible implementation faster than I can manually type the same first draft. That is useful. But a program is not delivered merely because source files exist. It becomes part of a dependable product only after somebody has established what behavior is required, checked its interaction with the existing system, verified consequential edge cases, controlled release, and accepted responsibility for future change. The most valuable question about AI coding is therefore not simply how quickly code appeared. It is where the work moved after that acceleration.

A faster AI coding stage can expose weaknesses that were previously hidden by slower implementation. If requirements are ambiguous, many plausible implementations can be generated before the ambiguity is resolved. If integration tests are fragile, additional changes compete for the same verification capacity. If release authority is unclear, a backlog of completed-looking changes can accumulate without a reliable path into production. My central argument is that throughput must be evaluated at the verified product boundary, not at the moment of code generation.

This article separates evidence from inference. Research on AI coding describes outcomes that vary by task, developer, organizational context, measurement and time period. Some controlled experiments reveal acceleration in specific tasks; other experiments found slower work in established open-source projects. Survey-level organizational findings add another perspective. I will not turn any of these into a universal productivity percentage for my own projects.

Decision brief: Use AI coding where it reduces the total cost of reaching a verified outcome. Protect specification quality, independent tests, review capacity, system integration, operational recovery and long-term ownership as distinct requirements. If one of those boundaries cannot be satisfied, the generated draft is a proposal, not an authorized release.

Quick Summary

• Generation: AI coding can reduce implementation effort, but that gain is not identical to end-to-end delivery improvement.
• Bottleneck: Specification, integration, review capacity, test evidence, release safety or maintenance may become the limiting step.
• Proof: Track verified outcomes, change scope, independent tests and recovery rather than counting generated lines.
• Decision: Continue, revise, investigate or hold each consequential change according to its documented evidence and authority.

The Bottleneck Is a System Property

Source code production is one stage in a longer workflow

A typical development path begins before the editor. A person identifies a user problem, describes acceptance criteria, selects an architecture, weighs dependencies and security constraints, and chooses the change boundary. The implementation then travels through local checks, automated tests, review, integration, deployment, monitoring and eventual maintenance. AI coding primarily changes the cost and speed of some activities within this chain. It does not make every adjacent activity disappear.

An AI coding workflow can accelerate at one station and become slower overall when the downstream queue grows. That is not an assertion that AI necessarily harms productivity; it is a capacity problem that must be measured. More draft output can be genuinely valuable when review and release processes absorb it safely. The same AI coding increase can produce idle inventory, repeated context switching and high rework when the rest of the system is unprepared.

My preferred unit of analysis is the verified change: a meaningful requirement that has passed an agreed acceptance boundary, been integrated without unresolved material risk, and reached the intended environment with observable behavior. For AI coding, a line of code, prompt count, generated test count or merged pull request is a weaker proxy. Each can be useful telemetry, but none necessarily proves a user outcome.

Local acceleration can hide downstream waiting

Imagine a developer who once spent a substantial part of an afternoon drafting a module. With AI coding, the first draft may arrive in minutes. If the developer now spends the rest of the afternoon recovering missing requirements, repairing integration assumptions, and checking test validity, the work has changed shape. That may still be a net benefit. It may even be a very large benefit. The result cannot be inferred without counting what happened after generation.

The distinction matters particularly when AI coding serves small teams and solo developers. There may be no dedicated quality assurance group or independent infrastructure team to receive the change. The same person must switch between architecture, implementation, review, security and operations. In that setting, an impressive AI coding session can create a larger verification obligation for a single accountable human.

Delivery capacity is constrained by the weakest necessary boundary

A product has simultaneous constraints: design clarity, code correctness, dependency health, deployment access, legal obligations, data quality, interface accessibility and support capacity. Some requirements are non-negotiable gates rather than work that can be traded for more speed. An authorization failure cannot be offset by generating five additional features. A broken migration is not made safe by passing unrelated unit tests.

In an AI coding workflow, I find it helpful to describe each boundary explicitly and decide which evidence makes the change eligible to move forward. This is more actionable than declaring that AI coding is either productive or dangerous in the abstract.

What the Research Actually Supports

DORA: AI amplifies the surrounding engineering system

The 2025 DORA State of AI-assisted Software Development report frames AI as an amplifier of organizational strengths and weaknesses. Its research includes survey responses from nearly 5,000 technology professionals and extensive qualitative work. That makes it valuable for patterns across organizations, but observational relationships do not establish the causal effect of a specific model or workflow on an individual team.

DORA’s March 2026 analysis of AI adoption and the software development lifecycle describes a tension worth testing locally: initial code generation may improve while saved time is reallocated toward audit and verification. It also discusses associations with increased throughput and increased instability. This is not proof that every adoption increases incidents. It is a reason to examine delivery flow and recovery, rather than relying on developer perceptions alone.

METR: productivity experiments are sensitive to who and what is measured

In a 2025 experiment involving experienced open-source developers, METR found the studied participants were slower with AI tools on the selected tasks. In its February 24, 2026 methodological update, METR explained why a newer experiment could not reliably estimate the current productivity effect: selection effects, changes in participation, and difficulties measuring concurrent agent use distorted the signal. It explicitly cautioned against taking the new results as a confident estimate of the magnitude of AI speedup.

I draw a narrow conclusion. Task familiarity, repository complexity, AI coding usage patterns and experimental design matter. The 2025 result does not prove AI coding must slow developers today. The 2026 follow-up does not validate a universal acceleration factor. Both show why responsible measurement needs a defined task population and a counterfactual.

Maintainer outcomes are not reducible to output volume

A controlled study published in Empirical Software Engineering examined whether developers without AI assistance could subsequently evolve code previously written with AI assistance. In the tasks examined, researchers reported no statistically significant difference in later evolution time or code quality. That challenges an overly broad claim that AI-produced code is inherently harder for the next maintainer to change. The study’s scope remains limited; it does not settle every question about large systems, incident recovery, hidden dependencies or multi-year ownership.

A separate 2026 empirical repository study examined maintenance of agent-generated files and found much maintenance was performed by humans, with different observed modification patterns. Repository observations and controlled trials measure different outcomes. Neither should be treated as a universal forecast of future technical debt.

Separate observation, inference and permitted decision

These AI coding findings motivate a testable operating model. It does not authorize fabricated before-and-after outcomes. Where I illustrate a workflow below, the scenarios are conceptual unless a real measurement is explicitly supplied.

Specification Quality Becomes a Primary Constraint

A fluent implementation can satisfy the wrong requirement

Suppose an account page must allow users to export their own activity. A vague request for an export button leaves important questions unanswered: Which records? Which date range? Which user roles? What data must be redacted? How does the user know an export has completed? What happens when the request is too large? A model may provide a polished interface, a controller and a file download before these decisions have been made.

The AI coding problem is not necessarily poor syntax or even incorrect code. It is an unresolved contract between product behavior and business rules. AI coding can conceal that gap because a working demonstration feels like evidence that the requirement was understood. I would instead establish expected behavior and prohibited outcomes before asking for implementation.

Acceptance criteria should include failures, not only happy paths

A practical specification identifies the normal task, observable success, relevant permissions, invalid inputs, interruption behavior, and the recovery path. “The download works” is not a sufficiently strong acceptance criterion for a sensitive data export. “The authenticated user can retrieve only their own permitted records, receives a clear status, and cannot access another account’s export” makes a materially different demand.

For AI coding, the acceptance boundary should be written in terms that a reviewer can verify without trusting the model’s own explanation. This matters when AI coding also produces the tests: if both implementation and assertions derive from the same mistaken assumption, passing tests can become an elegant confirmation of the wrong behavior.

Good context is more than a larger prompt

A project-specific AI coding instruction file can preserve code conventions, environment facts, permission boundaries, test commands and architectural decisions. But context size is not a substitute for source authority. A stale architecture note can make a model confidently implement an obsolete pattern. A copied example from a neighboring service may contain permission assumptions that do not apply to the target module.

I prefer a small hierarchy of authoritative context: current requirement, source code and tests, documented invariants, architecture rules, and version-specific vendor documentation. AI coding suggestions must remain subordinate to these sources. When they conflict, the workflow should stop and investigate rather than silently choosing whichever explanation sounds most coherent.

Integration Becomes More Important Than Generation

The difficult boundary often lies between components

An AI coding output can be correct in isolation and still violate a system-wide assumption. It may return an object with an unexpected lifecycle, bypass a cache invalidation step, write data at the wrong point in a transaction, or contradict a shared authorization convention. These failures are not always visible through a unit test limited to the function’s own behavior.

Integration asks whether the change preserves contracts across modules. Which component owns the state? Which side is allowed to retry? Are events idempotent? What does a failed request leave behind? Can the operation be reversed? AI coding may help draft the adapter, but the architectural answers require evidence from the existing system.

Dependency changes expand the review surface

An assistant may introduce a library to simplify an otherwise modest feature. That choice adds maintenance and security obligations: update cadence, licensing, transitive dependencies, runtime compatibility, package provenance and replacement options. The new dependency may be appropriate, but it should not be accepted merely because it made code generation shorter.

In an AI coding change, before merging I would inspect the dependency diff, its purpose, its maintained status, and the smaller alternative. GitHub’s official guidance for reviewing AI-generated code likewise emphasizes checking functional behavior, context, dependencies, security and maintainability. This is a vendor practice guide rather than proof of a specific productivity outcome.

Small changes preserve the ability to reason

If AI coding makes it cheap to regenerate an entire module, that does not mean the best review unit is the entire module. An unrelated AI coding refactor bundled with a feature makes it harder to isolate why behavior changed. A small reversible patch has fewer interactions to assess, particularly when working within mature systems.

I would divide a large idea into observable increments: prepare a contract, add compatibility tests, introduce the minimal change, verify integration, then remove obsolete paths separately. There are exceptions, such as an atomic migration that cannot be safely split. The principle is to preserve reviewability, not to enforce an arbitrary line-count rule.

Verification Is an Independent Engineering Activity

Compilation is necessary but not sufficient

In AI coding, static checks answer useful but limited questions. A project can compile while returning the wrong business result, leaking information, or failing to preserve data through a migration. AI coding makes it easier to produce large amounts of syntactically valid code, which increases the value of independent behavioral checks.

For a change with consequential behavior, I would expect a traceable line from requirement to test, from test to observed result, and from observed result to a release decision. Tests should include representative invalid states and authorization boundaries where appropriate. The absence of a failing test does not prove the absence of a bug.

Do not ask one generated artifact to certify another

An AI assistant can propose tests and adversarial cases. It can also overlook the same edge case in both the code and the tests. Independent verification means at least some assertions are established from authoritative requirements or observed reference behavior rather than solely from the generated solution.

Independent checks in AI coding are achievable without pretending that every change requires a large manual audit. For low-risk formatting work, automated checks and visual comparison may be proportionate. For payment calculation, permission changes, deletion operations, or sensitive data handling, independent invariant tests and explicit review are harder to avoid responsibly.

Use a layered verification plan

For AI coding, these are classes of evidence, not a mandatory universal pipeline. Proportionality depends on change impact and the system involved. A check should be chosen because it reduces a defined uncertainty, not because an automated tool can generate another green badge.

Review Capacity and Ownership Are Still Finite

More drafts do not create more accountable reviewers

An AI coding pull request still asks someone to understand a change and accept its consequences. AI coding can produce additional drafts, but it cannot guarantee additional reviewer attention. When reviewers face larger or more numerous changes, the queue may lengthen or reviews may become superficial. Neither outcome is inevitable. Both are measurable risks.

An AI coding review must distinguish implementation style from product correctness. A reviewer may approve clean naming and organized modules while the original user requirement remains invalid. Effective review needs enough product and system context to assess both.

The owner must be able to explain the change without the assistant

My ownership test is simple: can the responsible developer explain the invariant, dependency choice, expected failure path, monitoring signal and rollback method without asking the generation tool to reconstruct an explanation? If not, the team may have acquired code faster than it acquired understanding.

This does not reject AI coding. It is a reason to maintain a short decision record alongside a consequential change. Record what was intended, which evidence was observed, what remains uncertain, and who authorized the action. The record should be brief enough to maintain rather than become ceremonial documentation.

Solo developers need independence of method

In AI coding, a second human reviewer is useful when available. A solo developer may have no teammate on hand for every change. Independent method can still reduce correlated error: write acceptance tests before generation, inspect relevant existing behavior, run tools that do not depend on the model’s explanation, test from a different user role, and wait to authorize the deployment until the evidence is visible.

Using a second model as a critic can surface questions, but it is not automatically an independent proof. Models may share assumptions, training patterns or missing context. A critical model response should lead to reproducible tests and source inspection, not replace them.

Security and Release Authority Are Different From Code Completion

Generated code must not inherit release permission

An AI coding agent may propose a database migration, configuration change or production command. The authority to write a draft should not imply authority to execute destructive or security-sensitive operations. Tool permissions, credential scope, production access and approval are separate engineering concerns.

I favor a narrow execution boundary: read and suggest where possible, edit in an isolated workspace, test in a permitted environment, and require explicit approval before consequential external effects. The correct control depends on the system, but the general principle is that faster generation must not erase the decision owner.

Check security invariants before speed claims

A change that weakens authentication, authorization, data isolation or input validation cannot be counted as a successful improvement merely because it reduced implementation time. Security analysis should ask what assets and trust boundaries are affected, which new dependencies appear, and whether legitimate workflows still function after controls are tightened.

Where possible, include adversarial tests for the exact permissions and failure modes the change touches. Tool findings require context; automated scanners can miss logic flaws and can report false positives. A human-owned decision should preserve the distinction between observation, inference and authorization.

Deployment requires monitoring and recovery

For AI coding, release readiness includes what happens after code is merged. Does the team know which signal will reveal a regression? Can it roll back without losing data integrity? Are database transitions backward compatible? Does the feature have a safe disabled state? An agent may generate deployment configuration, but the responsible operator must verify the consequences.

DORA’s software delivery metrics history distinguishes throughput and instability and describes the evolution of recovery and rework measures. Those measures can reveal how the delivery system behaves; they should not be repurposed as a contest for maximum commit frequency.

The Specification–Integration–Verification–Ownership Contract

I use the following contract as a conceptual governance aid for AI coding, not as a validated empirical scoring system. Each domain has its own evidence requirement. A fast result in one domain does not compensate for a missing authorization or unacceptable security risk in another.

For AI coding, the contract helps answer a practical question: where does AI coding end and verified engineering begin? In my view, it ends wherever the proposed change needs independent evidence or a human authorization it does not possess. The same contract supports four possible dispositions: PROCEED when the defined requirements are satisfied; REVISE when the change is repairable within scope; INVESTIGATE when evidence or effects remain unclear; and HOLD when a material constraint cannot be met.

This contract is not a formal standard, statistical estimator or security certification. Its value is traceability. It forces an explicit link between the requested outcome, the introduced change, the checks that actually ran and the person responsible for the release.

How to Find the New Bottleneck Instead of Guessing

Map the journey of one verified change

Start from an approved requirement and follow the change until the intended behavior is available to users. Record queue time, active work time, rework, blocked handoffs, and failures by stage. Capture when AI coding is used, but also capture task type and complexity. Without those distinctions, a team may compare unrelated changes and attribute the difference to tooling.

A useful AI coding sequence is specification, drafting, local verification, integration, review, release preparation, deployment, and observation. It is acceptable if an organization uses different stages. Consistent definitions matter more than fashionable labels.

Measure cost per verified outcome

For a defined observation window, I would track meaningful changes reaching an independently verified acceptance boundary, the time to get there, review and rework load, change failure rate, recovery work and operational incidents. A simple conceptual efficiency ratio is total engineering effort divided by verified successful outcomes. That ratio alone should not govern policy: task complexity, severity and user value must be considered alongside it.

Avoid comparing one handpicked AI coding feature with an unusually difficult earlier manual feature. If a controlled comparison is infeasible, document confounders, use comparable work classes, and report observations without claiming causation. If concurrent agents make individual time attribution difficult, say so rather than fabricating precise savings.

Do not reward the wrong proxy

This is an operational dashboard proposal, not a report of measured performance. A team should select the smallest set of measures that can change a real engineering decision and avoid creating a surveillance system around individual developers.

Three Illustrative Scenarios

Scenario A: a small presentation change

Consider a hypothetical interface update that adjusts a non-critical layout and improves wording. The scope is narrow, permission boundaries are untouched, and a visual regression can be checked in a known browser matrix. AI coding could remove a significant drafting burden while leaving modest verification work. The appropriate outcome may be to proceed after comparison with the acceptance criteria and accessible interaction states.

The failure to watch for is accidental alteration of unrelated component behavior. A clean snapshot comparison and interaction check are useful. There is no need to claim that this class always benefits from AI; its narrower risk profile simply makes the path to verification more direct.

Scenario B: a service integration change

Now consider a hypothetical event-processing integration that must remain idempotent across retries. The generated adapter compiles, and the happy-path test passes. But the real risk is a duplicate event after a network timeout. The bottleneck has moved from producing an adapter to verifying state transitions and failure recovery. I would hold release until duplicate delivery and retry behavior have evidence behind them.

Human oversight of the verification plan remains essential. A model can help enumerate failure cases, but the test oracle should be grounded in the actual system contract. The outcome could still be faster overall if AI speeds implementation and developers retain an effective integration harness. The scenario does not imply an observed customer incident.

Scenario C: a permission-sensitive account action

Finally, consider a hypothetical account operation that can delete records. Code generation is not the limiting problem. The defining work involves authorization, ownership, retention, auditability, recovery and safe confirmation. Even a flawless-looking implementation cannot authorize its own production execution.

For this class, I would require explicit separation of proposal and approved action, independent negative permission checks, and a recovery or irreversible-action policy that product and security owners accept. The outcome may be a narrower AI role, such as drafting an explanation, with the binding action enforced by deterministic application controls.

A Practical Operating Model for a Solo or Small Team

Before generation: define the contract

Write the user outcome, acceptance checks, architectural constraints and forbidden behavior. Link the exact code locations and documents that are authoritative. Decide which tools the assistant may read or edit, and which external effects require confirmation. A short, bounded task is easier to reason about and verify than an open request to improve an entire subsystem.

I prefer to ask the assistant to list unresolved assumptions before implementing anything risky. That does not turn every task into a committee meeting. It makes unknowns visible while changing them is still cheap.

During generation: keep scope observable

Work in a branch or equivalent isolated context. Inspect file changes as they happen. Avoid granting broad production credentials, silently installing new dependencies, or allowing a tool to rewrite unrelated modules without review. When the output drifts from the requirement, stop and return to the specification instead of repeatedly asking for a more polished solution.

AI coding can be especially useful for repetitive adapters, boilerplate, refactoring proposals, test-case candidates and explanatory documentation. The value comes from saving time without obscuring which decisions remain open.

After generation: verify with different evidence

Run the build and static checks, then tests tied to acceptance criteria. Add negative and integration cases appropriate to the change. Inspect dependencies, permissions, data migrations and accessible interaction where relevant. Review the diff against the original requirement, not only the assistant’s summary of its own work.

If a second assistant helps challenge the change, make its output a source of test hypotheses, not a release signature. Preserve a simple record of what actually passed and what remains unknown. Do not imply that a proposed test was executed if it was only written down.

Before release: choose an accountable disposition

A small decision record can say: PROCEED under these conditions, REVISE this limited change, INVESTIGATE missing integration evidence, or HOLD due to a material unresolved risk. Describe what can be rolled back, what must be monitored, and who will respond if the behavior changes unexpectedly. The release decision remains human-owned.

That discipline may look slower than accepting every generated patch immediately. It is designed to reduce the gap between a fast proposal and a sustainable product, which is the actual engineering outcome.

Common Failure Modes When AI Coding Looks Successful

The demo answers a different question from the user

A convincing AI coding demonstration can show that the model understood a surface pattern rather than the real requirement. An interface that works for the ideal account may fail under role restrictions, localization or interrupted requests. Define the user job and inspect disconfirming cases.

A green pipeline becomes a false assurance

The pipeline may cover syntax and standard unit tests but not crucial domain invariants. High test coverage is not proof that the right assertions have been written. AI-generated tests can inherit implementation errors. Tie important checks to external requirements and include negative examples. An absence of alerts is evidence about the tool’s detection coverage, not a universal safety verdict.

More agents increase coordination cost

Parallel AI coding agents may each produce plausible changes that conflict at integration boundaries. Shared state, file ownership and version drift require explicit orchestration. Running more agents is beneficial only if the work can be partitioned and merged with bounded risk. Otherwise the bottleneck moves to reconciliation.

Technical debt grows without a visible owner

Even high-quality code needs maintenance when requirements, dependencies and platforms change. A team that cannot explain why a component exists or who is responsible for it may accumulate cognitive debt. The solution is not exhaustive documentation; it is enough traceability to modify or retire the code deliberately.

Eight Questions About AI Coding and Engineering Quality

1. Does AI coding always make software development faster?

No. Results depend on developer productivity context, familiarity, task type, repository complexity, tool behavior and the measurement boundary. Some studies find faster completion in particular tasks, while others show slowdown or uncertain estimates. Measure verified work in your context rather than assuming a universal percentage.

2. Where does the bottleneck usually move?

There is no single universal destination. It can move toward requirements, integration, review, testing, approval, deployment or recovery. Identify the actual queue by tracing real changes from approved requirement to observed user outcome.

3. Is more generated code evidence of higher productivity?

Not by itself. Additional code may represent useful completed work, unnecessary complexity or rework. Pair output measures with acceptance quality, review effort, release stability and product value.

4. Can AI-generated tests verify AI-generated code?

They can contribute useful checks, but correlated assumptions are a risk. Important assertions should derive from requirements, established behavior or independent analysis, and test execution must be observed rather than merely described.

5. Does AI coding necessarily damage maintainability?

No. Evidence is mixed and task-dependent. Some controlled work has not detected systematic downstream maintainability disadvantages in the tested conditions. That does not eliminate risks from poor scope, incomplete context, dependencies or ownership gaps.

6. Should every AI-assisted change need a separate human reviewer?

Review intensity should reflect impact, and organizational obligations vary. In a solo environment, independent methods can compensate partly for the absence of a second person, but cannot magically substitute for mandatory approvals or expert review on high-risk changes.

7. What should a CTO measure first?

Start with meaningful changes completed, rework, review queues, change failure and recovery, stratified by task class. Only then try to determine whether AI coding changes the flow. Developer satisfaction and cost are useful complementary measures.

8. When should a team stop an AI coding workflow?

Stop when requirements, permission boundaries, integration effects, independent verification or release ownership remain materially unresolved. Faster drafting is not a valid reason to waive a non-negotiable constraint.

Evidence and Methodology

This is a conceptual engineering analysis informed by public primary research and technical guidance, not a laboratory experiment or a benchmark of my own development tools. DORA provides organization-level patterns; METR provides task-based experimental and methodological evidence; maintainability studies examine narrower code and evolution outcomes; GitHub documentation informs practical review checks. Their populations, definitions and causal strength are different. I have not combined their findings into a synthetic speedup percentage.

Where the article uses a developer or product example, it is explicitly hypothetical. The proposed Specification–Integration–Verification–Ownership Contract has not been independently validated as a universal framework. It can be adopted as an internal checklist and then judged against real defects, rework, delivery performance and user outcomes.

If You Only Read One Thing

AI coding changes how quickly a plausible implementation can appear. Engineering quality still depends on defining the right behavior, verifying interactions, controlling authority and maintaining the result. The relevant outcome is not code produced per hour; it is valuable, independently verified functionality delivered with acceptable risk and accountable ownership. When the bottleneck moves, inspect it and redesign the workflow rather than celebrating the speed of the stage you just accelerated.

Related Reading

• Code Review: The Hidden Cost of AI-Generated Code examines verification and review responsibility at the level of an individual change.
• AI Feature or Simpler Software? A Value-and-Risk Test asks whether AI is the right technology for a user need in the first place.
• AI Interface Trust: Correct Answers Can Still Mislead extends the separation between model output, user understanding and authorization into product design.

Author’s Note

I work across product requirements, software architecture, coding workflows and validation, often with direct responsibility for the whole handoff rather than a large team. That perspective makes me interested in the total cost of a correct and maintainable outcome, not the visual speed of a code generator. I use AI as a proposal and implementation tool while keeping authorization, source-of-truth checks and responsibility separate. I have not presented any personal speed benchmark in this article because no controlled, comparable measurement is provided here.

Primary Sources and Technical References

• DORA (2025), State of AI-assisted Software Development.
• DORA (March 10, 2026), Balancing AI Tensions in the SDLC.
• METR (February 24, 2026), We Are Changing Our Developer Productivity Experiment Design.
• Borg et al. (2026), Echoes of AI: Investigating the Downstream Effects of AI Assistants on Software Maintainability.
• Sawada et al. (2026), To What Extent Does Agent-generated Code Require Maintenance?.
• GitHub Docs, Review AI-generated Code.
• DORA, A History of DORA’s Software Delivery Metrics.