Over the last two years, the economics of software development have inverted. Producing code has become fast, but validating it remains painfully hard.For developers building a standalone application, a coding agent can be immediately transformative. The feedback loop is local and tight: write, run, observe, adjust. But in enterprise environments, where applications are composed of dozens of microservices spanning multiple teams, the gap between generation and validation is widening into a crisis. Agents can refactor a service in seconds, yet proving that the change actually works still depends on infrastructure and processes that were never designed for this pace.“Producing code has become fast, but validating it remains painfully hard.”The industry has spent years talking about “shifting left.” Coding agents are about to force the issue. Forward-thinking platform teams are recognizing the need for infrastructure that gives developers and agents both environment access and tools to safely validate their code against the reality of the dependency graph.The CI feedback loop is too lateIn most enterprise organizations, “safety” means a continuous integration (CI) pipeline that triggers only after a pull request is opened. That model worked when developers produced a handful of pull requests (PRs) per week. It does not work when agents help them produce a handful per hour.The math is straightforward. If each change requires 30 minutes of validation in a shared staging environment and an agent-assisted developer generates 5 or 6 PRs a day, the developer spends the majority of their time managing a deployment queue rather than building software. The agent accelerates code output velocity, but if the surrounding system stays slow, that velocity hits a wall.The real bottleneck is no longer the speed of writing code. It is the speed at which it is validated. By the time code reaches a CI pipeline, it is already too late. Validation needs to happen inside the development loop itself, not after it.The complexity ceiling for agentsThis problem compounds as system complexity grows. For a monolithic application or a simple API, an agent can run tests locally and get a reasonable signal. For a cloud-native distributed system with a dozen interdependent services, that approach falls apart.When a change in one service ripples through multiple downstream dependencies, an agent operating without infrastructure access is effectively blind. It produces code that looks correct in isolation but fails at deployment because it lacks visibility into the broader system’s runtime behavior. The agent cannot see how a request flows, observe how a schema change affects a downstream consumer, or verify that a new endpoint behaves correctly when called by the actual services that depend on it.This forces developers into a frustrating cycle: the agent generates a PR, the developer manually interrogates it, deploys to a shared environment, waits, discovers a side effect that only emerges under real infrastructure conditions, and then starts over. The agent did its job. The system around it just failed to provide the context the agent needed to do that job well.The foundation: Kubernetes sandboxesThe first piece of the puzzle is giving agents access to realistic infrastructure without the overhead of duplicating entire clusters. To solve this, we leverage an approach that uses service meshes like Istio or Linkerd to create sandboxes, lightweight, ephemeral environments that use request routing to provide a realistic runtime rather than full environment replication. Instead of spinning up a complete copy of a staging cluster for every change, a sandbox deploys only the modified service and routes specific requests through it while the rest of the traffic flows through the shared staging infrastructure. The cost per environment drops to a fraction of the traditional approach, and sandboxes can spin up in seconds rather than minutes.This architecture changes the calculus. When environments are cheap, fast and disposable, they stop being a scarce resource that developers and agents compete for. They become a tool that agents can use programmatically as part of their normal workflow, testing changes against a live version of the entire system without blocking anyone else.From environments to validation toolingBut access to infrastructure alone is not enough. An agent also needs structured, reliable ways to interact with that infrastructure. And enterprise teams need confidence that agents consistently and safely validate code across the organization.This is the next challenge for platform engineering. Just as platform teams today provide CI pipelines, deployment tooling, and observability as shared services, they will need to provide validation capabilities that developers and agents can use during the development phase itself.“The key insight is that validation in a distributed system is not a single check. It is a composed sequence of steps.”These capabilities need to be deterministic, so that results are reproducible and trustworthy. They need to be governed so that platform teams retain control over what agents can do in a live environment. And they need to be composable so developers can assemble them into workflows that match the specific validation needs of their services, rather than relying on a single, monolithic test suite.The key insight is that validation in a distributed system is not a single check. It is a composed sequence of steps that spans infrastructure provisioning, service interaction and result verification.Closing the loopThe vision here is straightforward. When a coding agent generates a change, it should be able to verify that change against realistic infrastructure before presenting it to a developer. The developer should receive not just a PR, but a proof of correctness: a record showing that the agent tested its work against live services, that the integration points behave as expected, and that no regressions were introduced.This collapses the traditional CI feedback loop into the development phase itself. Instead of write, commit, open PR, wait for CI, discover failure, and fix, the cycle becomes write, validate, present verified result.How we are approaching this at SignadotAt Signadot, we are building toward this vision with what we call the Skills framework. Skills build on our ephemeral sandbox infrastructure with a library of platform-governed primitives we call Actions, such as sending an HTTP request to a service in a sandbox, capturing logs, or asserting that a response matches an expected schema.Each Action is individually governed by the platform team, which means security and compliance requirements are enforced at the primitive level rather than bolted on after the fact. Because Actions are deterministic, platform teams can give developers and agents the flexibility to compose their own validation workflows without sacrificing consistency in how code is validated across the organization.A developer or agent authors a plan, a sequence of Actions that validates a specific behavior. That plan gets tagged, versioned, and exported as a native skill for the developer’s coding agent. When the agent makes a change, it automatically runs the skill in a live sandbox and reports the results.The goal is to give agents the autonomy to validate their own work while keeping platform teams in control of the boundaries. We think this balance between autonomy and governance is essential for enterprises to see the benefits of agentic development at scale.Come read more about what we’re building with Skills in our architecture blog. We’re welcoming feedback!The post Enterprise dev teams are about to hit a wall. And CI pipelines can’t save them. appeared first on The New Stack.