AI Agents Are Turning Test Data Into Infrastructure

AI coding agents can now do far more than suggest the next few lines of code. They can work through development tasks, generate tests, find problems, change what they've built and try again. For software teams, that promises a much faster development cycle. But there's something underneath all of that activity that still has to keep up: the data used to test whether the software actually works.

That data has always been difficult to provide. The World Quality Report 2025-26 from Capgemini, Sogeti and OpenText found that 60 per cent of organisations struggle with secure, scalable test data, meaning the information used to check how software behaves before it reaches production.

AI agents don't create that problem. What they change is the speed at which organisations have to solve it. JetBrains' 2026 Developer Ecosystem Survey found that 90 per cent of more than 15,000 professional developers surveyed were already using AI coding agents at work at least weekly, with 68 per cent using them daily.

As these agents take on more of the development cycle, test data can't remain something a team manually prepares whenever a developer needs it. It starts becoming part of the infrastructure that automated development depends on.

The Test Data Problem Already Existed

Testing software sounds fairly straightforward until you think about what the test is actually trying to prove. It's not enough to know that an application works when everything is neat, complete and behaving exactly as expected. It also has to work with the complicated data and unusual conditions it will encounter in the real world.

Production data, meaning the live information an organisation uses in its day-to-day operations, provides that realism. But copying it into development and testing environments creates an obvious problem. It can contain customer details, financial information, employee records or other sensitive data that developers and testing systems don't need unrestricted access to.

The alternative is to create test data that doesn't expose the original sensitive information. But that creates another challenge. The safer dataset still has to behave enough like the real one to reveal meaningful problems.

This leaves organisations trying to balance three things that don't always sit comfortably together: speed, privacy and realism. Developers need data when they're ready to test. Security and compliance teams need sensitive information protected. And the resulting dataset still needs enough of the complexity of production to show what the software will really do.

Those competing demands were difficult before AI coding agents entered the picture. Perforce's 2026 Test Data Management Report found data quality was both the biggest test-data challenge reported by respondents and their top priority for test-data automation. Another 30 per cent identified testing across complex environments as a challenge, while 27 per cent cited scalability as a leading priority.

The underlying problem, then, isn't new. What's changing is how much friction the old way of solving it creates.

AI Agents Change The Speed Of The Problem

A human developer might finish a piece of work, request the data needed to test it and then continue once the right environment is available. An AI coding agent can work very differently. It can potentially generate code, test it, diagnose a failure, make a change and run another test as part of the same automated workflow.

That cycle only moves at machine speed if everything it depends on can move with it.

Google's DORA research illustrates the wider problem. Its research into AI-assisted software development found that AI speeds up initial code generation, but some of that saved time is then spent auditing and verifying what the AI produced. Higher AI adoption was also associated with both greater software delivery throughput and greater delivery instability.

Test data can become another version of the same bottleneck. An agent that can move through several development tasks without waiting for a person gains little from that autonomy if it eventually reaches a test and has to stop while someone finds, prepares and approves the data it needs.

We're beginning to see test-data platforms respond to this change. Perforce has introduced capabilities that let AI agents work with test-data environments programmatically, while Synthesized launched a Test Data Agent in August 2026 that can identify and provision the records, relationships and system states needed for a particular test.

These products don't prove that agent-driven test-data infrastructure is already widespread. They do, however, show where the requirement is beginning to move. If machines increasingly participate in development, the services around development need ways to respond to machine consumers too.

Realistic Test Data Is More Than Plausible Data

Making data available quickly only solves half the problem. The agent still needs data capable of telling it something useful. Imagine an AI system creates a perfectly believable customer called Sarah. She has an address, an account number, three orders and an outstanding invoice. Every individual value looks realistic. 

But the order records point to the wrong customer ID, the invoice isn't connected to any of the orders and the account doesn't have the permissions a real customer of that type would have. The data looks real. Structurally, it isn't. This is where referential integrity becomes important. 

The term simply means preserving the relationships between connected pieces of data. In a real enterprise environment, a customer can be connected to accounts, transactions, orders, contracts and support records across several systems. Testing an application properly can depend on those relationships remaining intact.

Perforce's 2026 synthetic data survey of 518 enterprise technology leaders shows how difficult that can still be. Only 36 per cent of respondents said synthetic data met their needs for data realism, while 34 per cent said it provided the referential integrity they required. Among software leaders specifically, 66 per cent said their organisations weren't using synthetic data approaches for development and testing.

Realistic testing also needs the awkward cases. A payment might fail. A record might be incomplete. Two systems might disagree. A customer could have an unusual combination of products or permissions. If an automated test only receives clean, predictable data, passing the test says much less about how the software will behave when something goes wrong.

Automation doesn't solve that by itself. Google researchers found that an AI testing agent performed better when it was first instructed to reason about the conditions surrounding the code, including expected behaviour and edge cases. On production bugs from Google, this approach improved its bug-detection rate by 9.8 percentage points compared with the baseline agent.

So the goal isn't simply to give agents more data. It's to give them data that represents the conditions they actually need to test.

Synthetic Data Isn't The Whole Answer

It's tempting to see synthetic data as the obvious solution. Instead of exposing real information, an organisation can generate artificial records designed to resemble the data its systems normally process.

There are good reasons for doing that, particularly when the required production data doesn't exist. A new product may need testing before there are real customers using it. Teams may also need unusual failure conditions that are difficult to find safely in production data. But synthetic data is one tool rather than a universal replacement for everything else.

Data masking takes existing information and changes sensitive values so they can't reveal the original data. This can be useful when a test needs the complexity of production data without exposing the people or organisations behind it. Data subsetting, meanwhile, takes a smaller selection from a larger dataset when a team doesn't need the whole thing.

Enterprises are already mixing these approaches. Perforce's State of Test Data research found that 86 per cent of respondents used static masking, 60 per cent used dynamic masking and 51 per cent used synthetic data. Another 29 per cent used data subsetting.

The World Quality Report also found that synthetic-data use in testing increased from 14 per cent in 2024 to an average of 25 per cent in 2025. That growth is important, but it doesn't mean every testing problem is becoming a synthetic-data problem. The better question is what kind of data a particular test needs. 

Sometimes the answer will be generated data. Sometimes preserving the real relationships in masked production data will be more valuable. Other situations may call for a subset or a combination of approaches. Once agents start requesting that data themselves, making the right choice becomes part of the infrastructure around them.

Test Data Starts Behaving Like Infrastructure

Infrastructure is easy to overlook when it works. A developer doesn't want to think about every server, network connection or storage process involved whenever they need to run an application. Those capabilities are expected to be available through established systems and processes.

Test data infrastructure starts to work on a similar principle. Instead of treating test data as a static asset that somebody has to find and prepare, organisations can treat its delivery as an ongoing service within the development environment.

For an AI agent, that could mean discovering what test environments are available, requesting data for a particular scenario and receiving an appropriate dataset without somebody manually building it each time. The same process can be repeated when the agent changes the software and needs to test it again.

The important change is therefore bigger than automating data generation. Test data needs to become discoverable, repeatable, programmatically accessible and governed by policy. It also needs to fit into the development and testing workflow closely enough that getting the right data doesn't break the automation around it.

Recent vendor developments show that architecture beginning to take shape. Perforce's Delphix platform is moving towards self-service and automated provisioning for developers and AI agents, including preserving relationships across generated datasets. Synthesized's Test Data Agent can generate, mask or subset data according to the testing objective while preserving business rules and relationships across connected systems.

It's still an emerging model rather than an established enterprise standard. But it changes the role of test data in a useful way. The question moves from whether developers can eventually obtain an appropriate dataset to whether the development system itself can safely obtain one when it needs it.

Agent-Ready Doesn't Mean Production Access

Making test data easier for agents to consume creates an obvious concern. If the goal is removing human delays from development, the quickest route would appear to be giving the agent access to whatever data is already available. That's exactly the shortcut organisations need to avoid.

An agent doesn't need unrestricted access to production simply because it needs realistic conditions for testing. The better goal is to make appropriate data easier to obtain while keeping the boundary around sensitive production information intact. That means the policies governing test data need to travel with the provisioning process. 

The organisation still needs to decide which systems an agent can interact with, which datasets it can request and what protection needs to be applied before that information reaches a non-production environment. Existing access controls can help provide that boundary. 

Perforce, for example, applies existing role-based access controls to agent interactions with Delphix. That means an AI client doesn't automatically gain broader permissions simply because it can interact with the platform. Traceability becomes important for the same reason. 

If an agent can request or create test environments automatically, teams need to be able to see what was provisioned, why it was requested and which policies were applied. Higher-risk operations can still require human approval without forcing people back into every routine step.

The goal isn't to remove people from test-data governance. It's to stop routine human involvement from being the only thing standing between an automated development workflow and the data it needs.

What Enterprises Need From Test Data Now

For CIOs, CDOs and engineering leaders, this creates a different way to assess test data strategy. Having a synthetic-data product or masking tool doesn't necessarily mean the organisation is ready for more autonomous software development. The more useful test is whether the wider capability can support the way development is changing:

• Can data be provisioned quickly enough? If every request depends on a manual process, greater agent autonomy will keep running into the same queue.
• Does the data behave like the real environment? Individual records aren't enough if the relationships, rules and system states that shape real behaviour disappear.
• Can the protection method change with the use case? Synthetic data, masking and subsetting solve different problems. The architecture needs room to use the appropriate approach.
• Can the same conditions be reproduced? Teams need to recreate a test when they're investigating a failure or checking whether a fix actually worked.
• Can machines request data without bypassing governance? Programmatic access should operate inside defined permissions and policies rather than creating a route around them.
• Can teams trace what happened? Automated provisioning still needs enough visibility to investigate failures and understand how a test environment was created.
• Can the environment test difficult conditions? A fast supply of clean happy-path data won't reveal how software behaves when records, relationships or processes become messy.

Those questions shift the conversation away from individual test-data tools. What organisations increasingly need is a capability that can supply safe, representative conditions at the same pace as the development process consuming them.

Final Thoughts: Test Data Has To Keep Up With Machine-Speed Development

AI coding agents didn't suddenly make test data difficult. Enterprises have spent years trying to provide developers with information that is realistic enough for meaningful testing, safe enough for non-production use and available quickly enough to avoid slowing delivery. What agents do is make the gap harder to work around.

A development process that can generate, test, correct and retest software with increasing autonomy can't reach its potential if one of its essential inputs still depends on somebody manually preparing data each time. Equally, speeding up that input can't come at the expense of privacy, realistic system behaviour or control over production information.

That's why test data is starting to look less like a supporting development asset and more like infrastructure. It needs to be available when required, representative enough to reveal real problems, protected according to policy and accessible to machines without handing those machines unrestricted access to production.

As AI takes on more of the work involved in building software, enterprise leaders will need to look beyond the agent itself. The more useful question is whether the data and infrastructure around it are ready to work at the same speed. That wider shift in what enterprise AI depends on is one EM360Tech will continue to follow as agentic development moves further into everyday operations.