For the past decade, the confidence of platform teams came from a single mantra: don’t reinvent the wheel, we’ve already built it for you. If a business team wanted to set up CI/CD, the Infra team already had Jenkins templates and deployment scripts ready. Wanted to add a monitoring dashboard? Prometheus and Grafana configurations were already packaged as one-click integrations. Needed a message queue? Kafka cluster operations and SDK wrappers were all taken care of. The premise of this logic was that building wheels was expensive and slow — reuse was cheaper than building from scratch.
That premise is being eroded by AI. Not gradually loosening — the underlying economic model is being overturned.
GitClear’s 2025 code quality study, covering 211 million lines of changes, shows that AI-assisted coding led to a sharp increase in repeated code blocks, a notable decline in refactoring behavior, and a rising volume of copy-paste cloned code. When a product manager can spend ten minutes having AI generate an internal tool, a data dashboard, or an automation pipeline, the maxim “don’t reinvent the wheel” loses the weight it once carried. The cost of building wheels has dropped to a point where business teams no longer need to hesitate.
But this is not a signal for Infra teams to exit the stage. Their role needs to shift.
The DRY principle has ruled software engineering for decades, not because repetition itself is a sin, but because code was once expensive. I discussed this shift in Beyond DRY: Reflections on AI-Native Software Engineering: in the era of AI-generated software, what truly needs to be reused is no longer always the final code, but the kernel that drives code generation. When AI pushes the marginal cost of writing code close to zero, repetition at the code level ceases to be the primary concern. Viewed in isolation, the surge in duplicated code in GitClear’s data looks alarming — but placed in the context of the new cost structure, it points to something else: code is transitioning from a long-term asset to cheap consumable material.
This shift is already manifesting in engineering practice. In the past, when an engineer hit a tricky bug, the instinct was to read the source code, set breakpoints, and mentally simulate execution paths. Now, faced with the same bug, you can have AI generate an analysis script on the spot, run it across the full set of logs, and see the error root cause directly in a visualization interface. In Disposable Software and the Compressed Reality, I called these tools “decompression tools”: their value lies not in long-term existence, but in trading cheap code for high-resolution reality. Code is no longer just an asset to be carefully maintained — it can also be a cognitive tool, used and then discarded.
This is not an abstract software engineering debate for Infra teams. Business teams used to have no choice but to go through the platform because the startup cost of building something themselves was high, the maintenance cost was high, and the cost of fixing things when they broke was also high. AI has first reduced that first cost, making “let me just build something that works on my own” a more common choice. The value anchor that Infra teams have long taken pride in has thinned in the face of AI-assisted development.
What truly cannot be duplicated is not a particular function or module, but the core capability layer and the constraint layer. Payment and settlement capabilities cannot be rewritten in every business team. Data permission boundaries cannot be defined by each agent on its own. These are the things that must be centrally maintained, repeatedly reused, and never forked.
This brings us to a key concept: the generative kernel. What an organization delivers to business teams and agents is no longer a platform with fixed functionality or a finished piece of software, but a set of tool combinations that can be assembled on demand. This set consists of three parts.
The first part is non-fungible core capabilities. Payment APIs, product catalogs, user authentication — these are the assets that hold real value for the organization, and business teams cannot build them on their own. The second part is guiding knowledge: engineering design philosophies, best practices, common pitfalls. In the past, this knowledge required engineers to spend years internalizing it on the job; now it can be systematically encoded as agent context, becoming part of the deliverable itself. The third part is leverage tools that convert uncertain tasks where agents tend to make errors into deterministic operations. For example, Stripe’s subscription management tool: users describe the desired plan structure in JSON, and the tool automatically completes SKU creation and configuration, guaranteeing correct results.
Together, these three types of components form the complete interface through which an agent accomplishes its tasks. The layer at which reuse happens has changed: it is no longer about reusing a piece of code or an API, but about reusing a complete capability layer that enables agents to complete tasks reliably.
Shopify’s agent platform has already taken a step in this direction. Instead of building yet another “merchant admin SDK,” they turned the Catalog API into structured infrastructure that AI agents can query directly, and wrapped core merchant-side capabilities as an MCP server. The same logic is replaying in the payments space. Stripe’s agent toolchain packages payment capabilities and best practices into a trio of MCP servers, agent skills, and CLI tools. An agent calls it to process payments just as reliably as a human developer calling an SDK, but the interaction target has shifted from humans to machines.
Once the unit of reuse moves up a layer, what Infra teams deliver can no longer remain at the level of shared libraries and templates designed from a human developer’s perspective.
The CNCF Platform White Paper defines a platform as a foundation of self-service APIs, tools, services, and knowledge. DORA defines Platform Engineering as a sociotechnical practice of providing shared high-quality tools and golden paths. Both frameworks were valid in their respective eras, but they default to humans as the end users. Now we need to push one step further: the platform must simultaneously be callable, verifiable, and governable by agents.
GitHub Copilot’s cloud agent demonstrates the embryonic form of this. After acquiring a temporary development environment, it can browse code, make modifications, and run automated tests and linters. GitHub has wired repo, Actions, testing, and PR review into a closed execution loop for the agent. The agent is not merely permitted to write code — it can also verify for itself whether what it wrote is correct.
This paved road is the new product form for Infra teams, and it consists of several interlocking layers: agent-readable documentation — not wikis meant for human browsing, but knowledge structures that can be injected into an agent’s context window; a tool registry or MCP gateway that governs which tools an agent can invoke and under what conditions; golden paths encoded as agent-executable workflows; an eval, trace, and test loop that enables agents to self-verify; a permission and audit layer that establishes the principle of least privilege; baseline skills and context infrastructure that provide every agent with a default starting point; and a feedback mechanism that continuously reveals which paths yield high agent success rates and which ones lead to frequent failures.
None of these layers is particularly novel on its own, but together they form a complete agent execution environment: within it, an agent knows what capabilities it has, what it can do, where its boundaries lie, and how errors will be detected. This is the paved road of the agent era.
Once execution authority is delegated to agents, the risk surface does not shrink — it changes shape.
The OWASP Top 10 for LLM Applications explicitly lists prompt injection, insecure output handling, and excessive agency. Once agents are connected to tools, the failure mode escalates from generating wrong answers to executing wrong actions. MCP tool poisoning is a new attack surface: a compromised or improperly designed MCP server could inject malicious instructions into an agent, which could then trigger actual operations on production systems, customer data, or financial interfaces.
None of these risks can be independently absorbed by a business team. A marketing team might use AI agents to auto-generate dozens of competitive analysis reports, but has no ability to audit which tools those agents invoked, which data they read that they shouldn’t have, or which unauthorized operations they performed. The problem of shadow agents is more troubling than shadow IT, because the consequences of the latter are primarily unauthorized costs, while the consequences of the former include unauthorized actions.
The principles laid out in the OWASP AI Agent Security Cheat Sheet happen to map precisely to the new defense perimeter of Infra teams: least privilege, tool-scoped permissions, explicit authorization, monitoring and observability. These must be built into the paved road, not left for each business team to figure out on their own. It is in this sense that centralized boundaries are not constraints but protections: they give business teams the confidence to send agents out to execute tasks, knowing that a permission wall and audit log are always there as a safety net.
All of these threads ultimately converge on a single point: the core output of Infra teams is not platform features, but trust.
In the past, the trust-building logic was: “don’t build your own, use ours — we’ve tested it, it runs in production, it’s more reliable than what you’d cobble together.” After AI lowered the cost of self-building, the moat around that logic grew shallow. But a new source of trust has also emerged: when an agent follows the paths laid by Infra, its success rate is higher, its failure modes are more controllable, and its behavior can be audited and reviewed. This kind of trust doesn’t need to be built by convincing people to “stay away from code” — it only needs to speak through actual agent execution data.
This logic has a key premise rooted in practice: Infra adoption failures have never been a technology problem — they are a trust problem. Business teams don’t use your platform not because the technical architecture is flawed, but because they feel that following your path is more trouble than going their own way, or because they don’t trust your platform to hold up in edge cases. AI has lowered the cost of going around you, but it has also made the price of going around you more visible. When duplicated code and runaway agent behavior accumulate to a certain scale, they will surface in a way that management cannot afford to ignore.
The generative kernel addresses both ends simultaneously: it encapsulates all the capabilities an agent needs to succeed, and encodes the boundaries that control agent risk. The unit of reuse migrates from code and platform features to a packaged bundle of capabilities and constraints. The goal of Infra teams remains trust and adoption — only now, trust no longer comes from “we’ve built the wheels for you,” but from “follow this path, and your agent is more likely to succeed, and when something goes wrong, you’ll know where to look.” For any Infra team repositioning itself, this sentence is the first draft of a new pitch.