Agentic code is changing how we think about code quality | Harness Blog

AI has changed the speed at which we can write code. Developers can move from an idea to a pull request faster, agents can work through changes autonomously, and the amount of code moving through development pipelines is only going up. But writing the code is only the beginning.

Every change still has to be built, tested, reviewed, and validated before anyone can trust it. And as the time it takes to produce a change falls, the time it takes to understand whether that change is actually good starts to matter a lot more. That changes what developers and agents need from CI. The goal can't just be to execute builds faster. The tool needs to give developers and agents useful feedback about every change fast enough for them to act on it: What tests actually matter? Did they pass? What code did they exercise? What did they miss? Is this change ready to move forward?

The next generation of Builds and Code Coverage isn't just about faster builds. It's about faster answers and better code quality.

More code means more feedback loops

A single pull request can go through several builds before it’s ready to merge, especially when a coding agent is making fixes and rerunning tests. A fix for a failed test produces another build. So does an update made during review. With multiple agents working in parallel, the workload grows with both the number of changes in progress and the number of attempts each change takes.

Running the full test suite on every attempt seems like the straightforward solution, but it can mean waiting for tests that have little to do with the change itself. A small update to one service may trigger the same work as a change to a shared dependency used throughout the application. Treating those changes identically makes each iteration more expensive than it needs to be.

Test selection gives builds a way to account for that difference. Harness Test Intelligence maps tests to the code they exercise and uses information about a change to select relevant tests. That allows teams to reduce unnecessary execution without choosing tests by hand or assuming that only the files in the diff could be affected. The remaining question is then whether the tests that ran actually exercised the change sufficiently.

Running everything isn't the same as knowing everything

Running the full test suite still does not tell you whether the changed code was actually exercised.Say a developer adds a new timeout path to a service. The existing tests cover the normal request and response flow, so they all still pass. But none of those tests simulate a timeout. The new branch never runs, and a bug in that path could make it through the build without showing up anywhere in the test results.

That is what code coverage helps make visible. It shows which parts of the code were exercised during the build and which were not, so developers and agents can understand where a passing suite still leaves gaps.

It's important to note that code coverage is not the same as quality. A line can execute without a test checking the behavior that matters, and a high coverage percentage does not necessarily guarantee the code is correct. But when code has just changed, seeing which paths were never exercised gives us a much better place to look. Test results tell you whether the tests and builds passed. Code coverage tells you what they actually touched. Together, they give a clearer picture of what a passing build really means.

Code coverage becomes more important when code moves faster

So as teams and agents produce more changes, coverage becomes harder to reason about from a single number. In fact, a code repository can look healthy overall while one branch is trending in the wrong direction or a frequently changed file keeps accumulating untested code.

That is why a useful view of coverage is very important and has to get more specific.

At the repository and branch level, teams can see whether coverage is holding steady, improving, or declining over time. Trends make it easier to spot whether testing is keeping pace with development instead of waiting for a large drop to become obvious.

At the file level, developers can see exactly where coverage is missing. That matters because a percentage alone does not tell you what to fix. Seeing the uncovered lines gives someone working on the change a much more direct next step: inspect the missed path, decide whether it needs a test, and add one if it does.

Teams can also set coverage thresholds directly in the pipeline. So, if the code coverage falls below the agreed threshold, the build can fail before changes even move forward. That turns coverage from something developers and agents check after the fact into something the CI tool can enforce as part of the build itself.

The faster code moves, the more important that becomes. Coverage is most useful when it is close to the change, easy to interpret, and tied directly to the decision about whether the build should continue.

Signals are better together

Code coverage does give teams and agents a clearer view of what their tests exercised, but it is still only one part of truly understanding code quality.

A change can have strong coverage and still fail for other reasons. The wrong tests may have run. A failure may come from a flaky test rather than the code itself. The unit tests may pass while the application behaves differently once a user actually interacts with it. That is why code quality is better understood as a set of signals rather than a single score of coverage.

Harness Builds brings those signals into the same build. It helps teams run the tests that matter, understand what those tests actually covered, identify when a failure is coming from a flaky test, and use playwright execution to check whether the application still behaves as expected.

Each signal tells you something different about the change. That becomes more important as agents produce and iterate on code faster, because there is less room to rely on a single test result or metric as proof that the change is good. Code quality has to keep pace with code generation. That means giving developers and agents enough information during the build to understand what was tested, where the gaps are, and what still needs attention before the change moves forward.

Agents need feedback even more than devs do

As agents take on more of the development cycle, code quality has to become part of the context they work from. A developer can look at a build and bring years of experience to the result. They can recognize a flaky test, understand whether an uncovered path matters, or decide that a failure is unrelated to the change. An agent needs more of that context to be explicit.

That is why code quality cannot be reduced to a single score or check. The agent needs to know which tests mattered, what failed, what code those tests actually exercised, where coverage dropped, and what still needs attention. 

Code coverage is a good example of this. A percentage may tell the agent that something is wrong, but missed lines and uncovered paths tell it where to look next. The same is true for other quality signals: the more specific the feedback, the more useful the next iteration becomes.

The loop becomes:

The better these signals are, the easier it is for agents to iterate and for developers to trust the work they produce. As agents take on more of the cycle, code quality has to become a critical part of that handoff between human judgment and agentic execution.

Conclusion

For years, better CI mostly meant faster builds. That still matters, especially as more code moves through the system.

But speed only helps if the result is useful.

As developers work alongside agents, builds need to return enough context to understand what happened and what should happen next. That is where code quality starts to matter more: not as a separate step at the end, but as part of the feedback developers and agents get while they work.

The next generation of CI will not be defined by how quickly it can process more code. It will be defined by how quickly it can help teams understand whether that code is actually ready for production.

See code coverage in Harness Builds