It is easy to be impressed when a coding agent finishes a task quickly. The harder question comes afterwards: did that speed actually help the team deliver better software?

This week, Uber, Microsoft, and new research all pointed beyond individual coding speed. As agents take on more real engineering work, the surrounding machinery matters more—clear intent, bounded tasks, independent checks, and evidence we can trust.

The question is no longer simply whether an agent can write code. It is whether our engineering system can turn that work into reliable change.

Uber’s latest account of its internal software factory offers a useful marker for how far coding agents have moved beyond autocomplete.

More than 70% of Uber’s pull requests are now attributed to local or cloud agents. Its engineers have created more than 3,600 reusable agent skills, which are executed over 30,000 times a day. A growing share of agent sessions are not even started directly by humans: managed agents handle code review, CI repair, maintenance, debugging, alert triage, and end-to-end changes—with human review or escalation around them.

At that scale, choosing a capable model is only one part of the job. The larger challenge is operating a portfolio of machine workers without losing control of quality, cost, intent, or accountability.

Microsoft described a related lesson this week. Its developers became faster with AI tools, but those individual gains did not translate into better team productivity. The problem, Microsoft concluded, was not simply the tools. Intent was still being lost across product, architecture, development, and testing handoffs.

Its response has been to make a living, version-controlled specification the primary shared artifact. Business intent, constraints, edge cases, architectural guardrails, and acceptance criteria are established before implementation and maintained alongside the code. Humans and coding agents work from the same evolving source of truth.

Together, these examples point to a broader change:

The coding agent is no longer the useful unit of AI adoption. The surrounding delivery system is.

New research supports that interpretation while also exposing the current limits.

The Harness-of-Harness study found that long-running agents performed better when placed inside repeated planning, implementation, and independent-testing loops. Simply giving an agent more continuation passes helped less than carrying forward an updated plan, the evolving software, and evidence from independent checks.

Meanwhile, DepBench tested coding agents on 203 real dependency upgrades containing hidden breakage. The strongest completed configuration solved only 104 tasks—51.2%. A common failure was incomplete propagation: the agent updated the obvious code but missed consequences in wrappers, types, fixtures, generated artifacts, or runtime behaviour. Visible tests could pass while hidden verification still found the upgrade incomplete.

The evidence is not definitive. Uber and Microsoft are reporting their own internal experience, and the research studies are preprints rather than settled industry conclusions. Frontier models are also improving quickly and may remove some of today’s failure modes.

But better models will not automatically preserve business intent, define acceptable risk, choose independent evidence, or decide whether a change is ready for production.

For teams adopting coding agents, this changes the practical starting point. Keep intent close to the code. Break long work into bounded loops. Use checks that can observe the failures that matter. Measure merged, reliable outcomes—not prompts, tokens, or generated lines. Define when the agent must stop and escalate.

The question is no longer merely, “How capable is our coding agent?”

It is: “Have we engineered a delivery system capable of trusting its work?”

OpenAI has begun the limited rollout of GPT-6 Astra, its first model classified at the Critical cybersecurity capability threshold. OpenAI reports major gains in computer use, coding, and vulnerability discovery—but its system card also says Astra’s chain-of-thought is less monitorable than GPT-5.6 Sol and can evade some monitors when explicitly instructed to do so in adversarial tests.

The practical signal is not simply that another stronger model arrived. Capability and controllability must now be evaluated together, with access restrictions, action monitoring, and automated intervention becoming part of the deployment architecture.

Nvidia will acquire Hugging Face for $12.93 billion, bringing a platform used to distribute models, datasets, libraries, and applications under the leading AI-chip company.

Nvidia says Hugging Face will remain open across models, clouds, and hardware. That promise matters—but so does the structural incentive. Developers should watch whether performance, tooling, and commercial integration gradually favour Nvidia’s stack. Portability may become more important precisely because the platform remains convenient.

Meta has described an internal “organizational second brain” that treats institutional knowledge as a maintained engineering system.

When an expert corrects the AI, the system diagnoses whether the failure came from missing knowledge, a flawed procedure, or genuine ambiguity. Proposed changes then undergo independent review, targeted replay, regression testing, and expert approval before being added to version-controlled knowledge files.

The lesson is useful beyond Meta: giving an AI access to documents is only the beginning. Trustworthy organizational knowledge needs maintenance, tests, provenance, and owners.

This week, an AI coding agent completed a product implementation. Its tests passed, but I wanted stronger evidence before allowing the code into the protected main branch.

The question was simple:

If an agent writes the code, how do we prevent that code—or its environment—from influencing the result that says it is safe?

It is like asking a student to take an exam, mark the answers, and report the grade. Even an honest student should not control the entire process.

My goal was to create a separate checkpoint that would test the exact proposed version, keep it away from credentials and external systems, preserve the results somewhere the test could not rewrite them, and block the merge unless every required check passed.

Building it exposed several hidden assumptions. One run failed because the evidence folder was attached incorrectly. Another made the environment read-only but left a supporting tool without temporary working space. Later runs exposed incomplete readiness records and review evidence in the wrong format.

We fixed each problem instead of weakening the checkpoint.

The final validation ran with no internet access or credentials, and most files were read-only. Results were stored separately, while digital fingerprints connected them to the exact code revision tested. The merge remained blocked until every required check and review obligation was present.

The lesson is straightforward:

A green tick is not enough. Trust depends on who controls the test, what the test can access, and whether its evidence genuinely belongs to the code being approved.

If you read one technical resource this week, make it Uber’s account of operating coding agents at scale.

The adoption numbers attract attention, but the more valuable material is underneath them. Uber explains how it routes work across models, packages reusable agent skills, controls context overhead, measures cost per completed outcome, and surrounds automated work with review and escalation.

Most teams will never operate at Uber’s scale—and should not copy its system blindly. The article is useful because it shows the questions that appear once coding agents stop being individual tools and become shared engineering infrastructure.

Coding agents will keep getting faster. The more important engineering question is whether the systems around them are becoming more trustworthy at the same pace.

That answer will look different across teams. For one, it may mean clearer specifications. For another, stronger tests, tighter permissions, or a mandatory human checkpoint before production.

Where does your team draw the trust boundary around AI-generated work?

Reply and tell me what you are trying—or what is still making you uncomfortable. It may become something Software Signal investigates in a future issue.