Technology executives shouldn't give up control

In July 2026, security researchers reported that Grok Build had been uploading entire code repositories to SpaceXAI-controlled cloud storage. The uploads reportedly included files the tool had not been asked to inspect, repository history, and potentially sensitive credentials. A privacy command existed, but researchers found that it governed retention rather than the network path that allowed repository uploads.

The incident will be fixed. The affected product will change. Other vendors will point to their privacy policies and explain why their systems behave differently. We are missing the larger issue however.

A zero-data-retention policy is still a policy. A privacy setting is still a setting. Both depend on software behaving exactly as intended across every code path, feature release, operational process, and future architectural decision. Policies can be violated by bugs, misconfigurations, undocumented behavior, internal tools, or deliberate backdoors. The only durable way to prevent data from crossing a boundary is to enforce that boundary at the infrastructure level.

Privacy by policy asks the enterprise to trust. Privacy by architecture removes the need.

The Experimentation Era is Ending

Over the past year, learning to code with AI has been an intensely personal experience. Every engineer has developed a different way of working. Some use one coding assistant. Others combine several tools. Some delegate entire features. Others use models as more capable autocomplete. The most advanced users have assembled their own prompts, skills, agents, model preferences, review loops, and mental models.

That experimentation was necessary. AI coding represents the largest change in the mechanics of software engineering in decades. The industry could not have standardized its practices before engineers understood what these systems were capable of. We are now, however, approaching the next stage of adoption.

The time for learning is not over but the time for every engineer independently inventing an operating model should be.

When I talk to CIOs and CTOs, many are overwhelmed by the number of choices. Should they provide Claude Code, Codex, Cursor, or several tools? Should engineers be allowed to experiment freely? Which models are permitted? What data can leave the company? How should usage be budgeted? How should generated code be verified? Who is responsible when an agent runs for hours and produces the wrong result?

These are no longer individual productivity questions rather they are questions about how an engineering organization operates. AI coding is crossing from early adoption into the messy middle before mainstream use. The early adopters have generated enough evidence for us to see both the opportunity and the recurring failure modes.

• We failed on cost governance.
• We failed on intellectual-property protection.
• We failed on data sovereignty.
• We have allowed token consumption to grow much faster than our ability to measure verified delivery.

The next phase requires systems, governance, and repeatable engineering practices. These are all required to get to adoption at scale.

Stop treating one model like an engineering organization

Most discussion about AI coding still revolves around model selection. Which model writes the best code? Which one reasons most effectively? Which one leads a benchmark this week?

Model quality matters, but the quality framing is becoming less useful.

You would not hire a senior architect and ask that person to plan every feature, write every implementation, generate every test, perform every security review, and approve every deployment. It would be economically irrational, operationally fragile, and unlikely to produce the best result.

The same applies to models.

A planning task may require a highly capable reasoning model. A narrow implementation task may not. Test generation, documentation, code review, failure analysis, and adversarial verification may each be better served by different models, tools, or evaluation techniques.

The objective is not to avoid frontier models. The objective is to use them where their marginal capability justifies their marginal cost.

Recent open-weight models have become capable enough that I now use expensive frontier models far less frequently in my own coding workflow than I did even a month ago. That is a time-bound observation, and the specific models will change. The structural point is more durable: as baseline model capability improves, a growing share of system value moves into the harness.

The harness determines how work is planned, how context is assembled, which model handles each stage, when the system retries, how failures are detected, how results are verified, and when a human is interrupted.

A weaker model inside a strong system can detect mistakes, revisit assumptions, satisfy preconditions and postconditions, and recover from temporary failure. A strong model inside a weak harness can still drift, waste tokens, miss requirements, or produce plausible but incorrect work.

Intelligence and delivery outcomes are becoming a property of the workflow, not simply the model.

The plan is the Contract

Today, many coding agents behave like anxious junior engineers. They stop frequently, narrate every action, and ask for approval before proceeding. That is not autonomy. It is interactive execution with a conversational interface.

A mature agentic workflow should operate differently. A human reviews and approves a plan. Once approved, that plan becomes an execution contract. The agent should complete the work without routine supervision and return a verified delivery package.

That package should include:

1. Proof that the requested work was completed.
2. A pull request that can be reviewed by a human or an independent agent.
3. Proof of correctness through tests, canaries, end-to-end validation, or other appropriate evidence.
4. Proof that execution remained faithful to the approved plan.
5. Documentation of any deviations, including why they were necessary.
6. An independent quality assessment, potentially using a frontier model as the final gate.

The agent should interrupt a human only when it cannot complete the approved plan as expected. An exception handoff should explain why execution stopped, show evidence of the failure mode, provide the relevant telemetry, suggest viable next actions, and give the engineer enough context to make the decision without reconstructing several hours of agent activity.

Said more directly, the human is not there to approve every step. The human defines intent, approves the contract, handles genuine exceptions, and evaluates the evidence. We need to move towards exception-driven supervision.

Developer Productivity is the Wrong Metric

The industry keeps asking how much faster AI makes an individual developer. That is a local optimization. The more important question is how much verified software delivery an engineering organization can produce per unit of expert human attention.

This distinction is important because agentic work can be parallelized.

An individual delivery unit might take longer than the fastest possible frontier-model execution. That is acceptable when the unit costs materially less, achieves equivalent quality, and requires no additional human intervention. An engineer can supervise several independent delivery units while each runs in parallel.

Wall-clock latency still matters on a critical path. It matters when one unit blocks another, when feedback must be immediate, or when the opportunity cost of delay is high. Outside those cases, the duration of an individual agent run matters much less than aggregate throughput.

The governing metrics should be evaluated together:

• Total cost per verified delivery.
• Quality relative to the best available frontier system.
• Useful autonomous work completed per unit of human attention.

Cheaper does not mean fewer dollars per million tokens. A low-cost model that generates retries, weak tests, repeated escalations, or incorrect work may be far more expensive at the delivery level. The optimization target is the complete system. This changes the fundamental unit of engineering capacity. Historically, leaders have planned capacity in engineers: 100 engineers, 500 engineers, 5,000 engineers.

In an agentic organization, capacity may increasingly be measured in concurrent autonomous delivery units.

What is the maximum amount of verified software delivery that one engineer can safely supervise?

That is a different organizational theory from making each developer 20 or 30 percent faster. It changes planning, architecture, review, testing, security, deployment, and the role of senior engineers. Expert judgment becomes the scarce resource. More of the execution surrounding that judgment can be delegated, parallelized, and verified.

Evaluation is part of the production system

None of this works without evidence.

A harness cannot be trusted because it performs well in a demo or because its underlying model leads a benchmark. It must continuously prove that the complete delivery system is improving. Public benchmarks such as Terminal-Bench are useful because they evaluate agents on realistic terminal tasks with executable tests rather than relying only on conversational or code-completion metrics. They measure the combined behavior of the model, harness, tools, and execution loop.

Public benchmarks are still insufficient for enterprise governance.

A system may perform well on standardized tasks and fail on a company's architecture, coding conventions, deployment system, security controls, or definition of done. Customer-specific evaluations must therefore be first-class, customer-owned assets. Enterprises should be able to inject their own tests, policies, quality gates, architectural rules, and delivery criteria into the harness. The same model should not write the implementation, generate the tests, review the code, and certify the final result. That creates correlated failure. Multi-model execution allows different models and deterministic tools to challenge one another. Routing can begin with sensible defaults, including a lightweight model that judges task complexity under explicit rules. The customer must retain the ability to override those defaults.

Every meaningful change to a model, prompt, skill, routing policy, verifier, or harness component should be evaluated as a change to the production system.

Sovereignty means Owning the Enforcement Path

Data sovereignty does not require eliminating every SaaS component. It requires knowing which party owns the enforcement path.

Enterprises should control identity federation, authentication, authorization, network policy, egress, encryption, and the inference runtime. Model weights can be open and distributed by a SaaS provider, provided that the artifacts are signed, traceable, and verified before execution on customer-controlled infrastructure.

Some prompts, skills, operational telemetry, and aggregate evaluation data can be SaaS-provided or SaaS-hosted. The customer must choose what leaves the environment. This is particularly important for observability. Raw traces, prompts, tool outputs, code diffs, evaluator context, and failure examples can contain the same proprietary information the enterprise is trying to protect.

Local retention should be the default. External sharing should be explicit, granular, revocable, and auditable. A sovereign system can still benefit from a shared ecosystem. It simply does so under customer-controlled authority.

This is the architectural difference between trusting a vendor not to retain data and making unauthorized retention physically difficult or impossible.

Sovereignty does not mean One Region

There is a common misconception that customer control requires running every workload in one cloud, one VPC, or one physical location. That definition is too narrow.

The durable infrastructure problem is not simply GPU scarcity. Scarcity moves through the stack. At one point, the constraint may be accelerators. At another, it may be high-bandwidth memory or advanced packaging. TSMC has said that it is building new back-end facilities and working to double CoWoS advanced-packaging capacity in 2025 in response to strong AI demand.

Even if semiconductor supply were solved immediately, deployable compute would remain constrained by power, cooling, data-center space, and grid interconnection. The IEA projects global data-center electricity consumption to more than double to roughly 945 TWh by 2030. The U.S. Department of Energy describes transmission constraints and interconnection delays as material barriers to meeting growing demand.

The durable scarce resource is therefore not a GPU. It is deliverable compute: the right accelerator, memory, network, power, cooling, jurisdiction, and security boundary, available at the moment a workload needs it.

That capacity will be distributed across hyperscalers, specialized GPU clouds, private infrastructure, and regional providers. Enterprises will need to consume it without rebuilding their applications around every provider or surrendering control over the inference boundary.

A sovereign architecture can span several approved providers and regions while preserving a single customer-controlled operating model. The customer defines the eligible boundaries. The infrastructure layer handles networking, placement, identity, and execution across them.

Control is logical and enforceable. It does not have to be geographically singular.

A Practical Maturity Path

Enterprises do not need to begin by purchasing racks of GPUs.

A reasonable adoption path has several stages.

• Use serverless inference to prove that open-weight models and multi-model orchestration can satisfy real engineering workloads.
• Establish shared identity, budget controls, routing policy, evaluation, auditability, and a governed definition of done.
• Move sensitive or high-volume inference into customer-controlled infrastructure as sovereignty requirements and economics justify it.
• Treat approved GPU capacity across regions and providers as one governed compute pool rather than a collection of disconnected reservations.

This path allows an organization to learn without locking its long-term operating model to a third party's infrastructure boundary. It also recognizes that sovereignty and economics are independent benefits, but highly synergistic ones. Once the enterprise owns the inference boundary, it gains the freedom to choose models, control routing, optimize utilization, manage capacity, and determine where frontier-model premiums are actually justified.

Control of the boundary creates control of financial destiny. It's simply cause and effect.

Your Software Factory is Strategic Infrastructure

Here is the simplest way to say it: AI coding is no longer just another developer tool. It is becoming the production system through which software is planned, written, tested, reviewed, and shipped.

As that happens, the harness, the models, the inference boundary, the evaluations, the telemetry, and the capacity layer stop being a loose collection of subscriptions. Together, they become the software factory.

Technology executives already know how to govern strategic infrastructure. We do not casually surrender control of source repositories, identity, CI/CD, artifact registries, security policy, or production. The system that increasingly operates across all of them deserves the same treatment.

Control does not mean building every component yourself. It means owning the enforcement path. It means deciding what data can leave, which models can be used, how quality is proven, where work runs, and what the economics look like. It means retaining the ability to change providers without changing your definition of done.

This is the maturity shift: from measuring tokens to measuring verified delivery; from optimizing one engineer's speed to multiplying expert judgment; from personal experimentation to a governed production system.

Start serverless if that is the fastest way to learn. Use frontier models where they earn their premium. Run models on infrastructure you control when the workload becomes strategic. But do not outsource the factory and pretend you still control production.

Your software factory is strategic infrastructure. Treat it that way.

Endnotes

1. Axios, "SpaceXAI wipes customer data after Grok uploads sensitive information," July 14, 2026.
2. The Register, "Musk promises purge after Grok Build caught sending entire repos to the cloud," July 14, 2026.
3. Terminal-Bench official announcement and Terminal-Bench 2.0 paper, describing real terminal tasks, dedicated environments, human-written solutions, and executable tests.
4. TSMC Q1 and Q2 2025 earnings-call transcripts, describing strong AI demand, plans to double CoWoS capacity in 2025, and construction of new back-end facilities.
5. International Energy Agency, Energy and AI, projecting global data-center electricity use to reach roughly 945 TWh by 2030.
6. U.S. Department of Energy, "Smart Transmission Tools Modernize America's Power Grid," describing transmission constraints as a barrier to growing electricity demand.