Generation speed is no longer the real issue
Software teams have crossed a threshold: AI is no longer a marginal tool for writing a few snippets, it is now contributing to code that enters repositories. Sonar’s latest State of Code report estimates that developers using AI already report a significant share of assisted or generated code in their commits, with further growth expected in the coming months. Black Duck, meanwhile, observes that coding assistants increase output and save time, but that the most mature companies are the ones putting real governance mechanisms in place.
The lesson is less spectacular than the marketing promises, but far more useful for engineering leaders: the question is not whether AI can produce code quickly. It can. The question is whether the organization can turn that speed into reliable, maintainable, secure software. In other words, the new constraint is not generation. It is verification.
This shift changes how projects should be managed. For a long time, development automation was imagined as a linear acceleration: less time spent writing, therefore more features shipped. Early usage patterns show a more nuanced reality. Developers get help starting work, explaining code, generating tests, or producing a first version. But they must then understand, filter, correct, secure, and take responsibility for what the tool produced. The gain exists only if this second part of the work is organized.
The trust gap is becoming a maturity signal
The most interesting point in Sonar’s report is not adoption alone. It is the confidence gap. Sonar says 96% of developers do not fully trust AI-generated code, and that only part of them always verify it before committing. This does not mean the tools are useless. It means developers have understood something essential: plausible code is not necessarily correct code.
That nuance matters. An agent can respect syntax, follow the apparent conventions of a repository, produce green tests, and write a convincing explanation. Yet it can still miss an implicit business rule, move a responsibility to the wrong layer, choose an unsuitable dependency, weaken a security check, or introduce invisible debt. The more fluent the agent is, the harder the error can be to spot, because it looks like a design decision.
In this context, distrust is not resistance to progress. It is professional skill. A mature team does not ask developers to believe or reject AI on principle. It gives them the means to verify: targeted tests, static analysis, security review, change traceability, explicit acceptance criteria, and the right to reject a proposal that does not explain its assumptions.
Human review has to change shape
The classic reflex is to add “mandatory human review” at the end of the process. That is necessary, but insufficient. If an agent produces far more diffs than a team can seriously read, final review becomes a ritual. The reviewer scans, feels reassured because the tests pass, and approves. In that model, the human remains officially responsible, but no longer has the practical conditions needed to exercise judgment.
The better response is to move review earlier and make it more structured. Before an agent starts, the human should define the scope: which files may be changed, which dependencies are forbidden, which business constraints must not be touched, and which tests will have to prove the result. During execution, tools should produce readable traces: commands run, files changed, errors encountered, and trade-offs chosen. After execution, review should focus on reasoning and risk, not only on the appearance of the diff.
This model gives the human a stronger role, not a weaker one. The point is no longer to correct every line generated by a machine. It is to define the boundaries of delegation, choose the level of autonomy appropriate to the criticality of the change, and decide whether the evidence is sufficient. That is a form of technical command.
Governance numbers reveal the gap
Black Duck’s report highlights a revealing paradox: many developers want an automated system to track AI-generated or AI-assisted code, but far fewer teams have complete governance in place. The gap is understandable. Tools arrive quickly, often through individual usage, while company rules, pipelines, security baselines, and review practices evolve more slowly.
But that lag has a cost. Without traceability, a team no longer knows which changes were heavily AI-assisted, which models were used, what data might have been exposed, or which areas of the code deserve stronger review. Without a clear policy, developers compensate with manual comments, personal habits, or implicit decisions. That can work for a few experiments. It does not hold when AI becomes a normal production channel.
Governance should therefore not be understood as administrative friction. It is what makes usage scalable. When an organization can identify assisted code, measure incidents, compare outcomes, enforce checks, and document decisions, it can use AI with more confidence. It does not slow delivery; it prevents speed from turning into debt.
Verification must combine machines and judgment
A practical conclusion follows: the answer is neither “all human” nor “all agent.” Deterministic controls remain essential. Compilation, type checking, unit tests, integration tests, dependency analysis, secret detection, security rules, test coverage, and license policies should be automated as much as possible. A human should not manually re-check what a machine can verify reliably and repeatedly.
But automation is not enough. Pipelines are very good at detecting some defects, and very poor at detecting others. They cannot always say whether a decision respects product intent, whether a business exception is appropriate, whether an API will remain understandable in six months, whether a local simplification creates a global cost, or whether the system still fits the target architecture. Those questions remain human, even when agents prepare the evidence.
The right balance is to reserve human attention for decisions that involve meaning, responsibility, and risk. AI can propose a hypothesis, generate a set of tests, summarize an incident, compare two options, or flag an inconsistency. But the decision to merge, expose data, change critical behavior, or deliberately accept debt must remain explicit and assigned to a person.
What teams can put in place now
Organizations do not need to wait for a perfect platform to improve. They can formalize a few simple rules today. First, classify tasks by risk level: documentation, tests, and local refactors can receive more autonomy than security, data, or architecture changes. Second, require a clear description of what was generated by AI, especially in sensitive pull requests. Third, connect AI usage to evidence: which tests were added, which checks were run, which files were excluded, and which assumptions still need validation.
Another lever is to define stop conditions. An agent should not continue indefinitely just because it can rerun commands. It should stop when it leaves scope, when a test reveals an unexpected issue, when it asks for new permissions, when it touches a critical area, or when the cost of exploration exceeds the expected benefit. These stopping points give humans a real opportunity to intervene.
Finally, teams should measure effects. The right indicator is not only the number of generated lines or the time saved while writing. Teams need to look at post-merge defects, review comments, incidents, reopened tickets, debt created, test quality, and developer satisfaction. If AI accelerates production but increases correction work, the apparent gain is misleading.
The key skill is learning to delegate
The developer does not disappear in this model. The work moves toward a more demanding skill: delegating without giving up control. That requires knowing how to state a verifiable goal, limit the tool’s rights, read technical evidence, detect risk areas, and reject a solution that is attractive but fragile. These are engineering skills, not merely prompting skills.
This evolution also concerns managers and product leaders. If objectives are vague, agents will produce plausible answers to poorly framed problems. If deadlines reward speed alone, teams will accept insufficiently verified changes. If governance is perceived as a blocker, usage will move into the shadows. Mastering AI is therefore as much an organizational question as a tooling question.
The good news is that this approach makes AI more useful. By giving machines repeatable tasks and keeping value decisions with humans, a team can increase cadence without sacrificing quality. But that requires clearly accepting the central rule: the agent may help produce, explore, and verify; the human remains responsible for deciding.
A simple framework for the coming months
To move from experimentation to a robust practice, a team can adopt a framework built around four questions. First: how critical is the change being delegated to the agent? A documentation edit, a missing test, or an internal script does not require the same guardrails as a change to authentication, billing, or personal data processing. Second: what minimum evidence is required before review? The answer may include a test report, a before-and-after comparison, dependency analysis, or a note explaining why some options were rejected.
Third: who owns the final decision? That person must be identifiable, competent in the relevant area, and free to request more evidence. Responsibility cannot be transferred to a model, or diluted across a chain of tools. Fourth: what should be learned afterwards? Every incident, false positive, regression, or real gain should improve the rules of delegation. This is how governance becomes a living system: not a static document, but a continuous improvement loop.
This framework also has a cultural benefit. It avoids a sterile opposition between enthusiasts and skeptics. The first group gets a clear path for using AI without waiting for endless approval. The second gets evidence, limits, and control points. The conversation then focuses on the acceptable level of risk, not on a general belief about AI.
It also protects learning. If every AI-assisted change carries enough context to explain what was attempted and what was verified, future reviewers can understand decisions instead of reverse-engineering them from the diff. That matters for onboarding, audits, maintenance, and incident response. The goal is not bureaucracy. The goal is to keep the reasoning attached to the code, so speed today does not become confusion tomorrow. Over time, those records become an operational memory that improves prompts, checklists, tests, and escalation rules consistently.
Conclusion: accelerate, yes, but with evidence
Recent reports converge on a simple message. Generative AI and development agents have become too present to be treated as gadgets, but too imperfect to be left alone. Their value depends on the quality of the system around them: scope, traceability, automated controls, human review, and explicit decisions.
For software teams, the strategic question is therefore no longer “should we use AI to code?” The question is: “what evidence do we require before accepting what AI produced?” That is where the real gain lies. An organization that keeps humans in command does not slow innovation. It turns the raw speed of agents into reliable delivery.
