AI adoption is the wrong goal for engineering teams

Why adoption looks like a sensible goal

Engineering leaders have reason to pay attention to adoption. GitHub’s October 28, 2026 Octoverse report says that more than 40% of pull requests on its platform began with an agent’s first draft in September, compared with 17% in March. GitHub also reports that among newly created repositories, those with an agent configuration file averaged eight times as many commits as new repositories without one. These figures suggest that agent use is spreading and changing how work enters review. They can help a team decide whether a workflow deserves investigation. They do not establish that the extra commits represent more useful product work, or that the change caused improved delivery.

Where adoption stops being evidence

The distinction matters because activity can rise while the work remains difficult to verify or operate. GitHub’s report itself separates agent-started pull requests from other pull requests and notes that its agent signal detects only identifiable involvement. The figures describe platform activity; they are not a controlled comparison of business outcomes. A team that copies those figures into a target risks rewarding the detectable behavior, even if review, testing, integration or maintenance becomes harder.

A September 19, 2026 Google Cloud account describes a different approach in Google’s infrastructure code security work: agents scan changes before submission, a triage step checks whether a reported vulnerable path is reachable, and proposed fixes go to human review. Google reports more than 92% precision for that triage agent and says it completes in under a minute. Those are Google’s reported results for its own system, not a promise that another organization will reproduce them. The useful lesson is the shape of the claim: a defined task, a check against code structure, a measured quality criterion and a review path. “We use agents” has none of that precision.

Replace adoption targets with workflow evidence

Treat adoption as a prompt for inquiry. Pick a real workflow where a team believes AI may help, then write down what success would mean before changing the process. Keep the measure connected to work the team is responsible for, not to a count that flatters tool usage.

1. Name the task and its boundary. For example, evaluate whether an agent-assisted security review finds actionable issues in a specific class of changes. State what is excluded.
2. Set a baseline and quality bar. Record how the existing workflow performs, including review effort, false alarms, missed issues, elapsed time and any material operating cost. Do not infer quality from output volume.
3. Run a limited comparison and inspect the exceptions. Keep a person accountable for checking results, resolving uncertain cases and deciding whether the changed workflow is worth keeping.

An editorial recommendation for Nythrex

For this subject, Nythrex should frame AI reporting around evidence for a defined engineering outcome: what changed, how it was checked, and what remains uncertain. Keep tool usage as context for that review rather than presenting it as proof of productivity or return. This is an editorial recommendation, not a claim about current Nythrex product capabilities.

Sources

• GitHub Blog — Octoverse: Commits, pushes, reach new highs in 2026 as developers build with agents (October 28, 2026)
• Google Cloud Blog — Changing the game: Using agentic AI to secure infrastructure code (September 19, 2026)