You might not read code anymore, but your agent has to

There is a growing discussion about whether software engineers need to read code anymore. The reasoning is understandable: if an agent writes the implementation, runs the tests and demonstrates that the feature works, reading every diff becomes a significant part of the remaining human work. Engineers would rather spend that time on requirements, architecture and deciding whether the software solves the right problem.

Software factories take this approach further by organizing development into automated workflows with limited human involvement. However, the engineering decisions within those workflows still require understanding the software. Choosing a library, designing an integration and maintaining a deployed application all involve questions that are answered by reading code.

When we delegate that work, we also delegate the reading. An agent taking responsibility for a feature has to understand the existing implementation and the software around it. I consider access to that code a basic requirement for delegating engineering work, including the decisions made before anyone starts writing the implementation.

Coding agents are also code readers

Consider adding background jobs to an application. Before proposing a design, an agent has to understand how the application handles tasks, how its services start and stop, and which operations belong outside the request lifecycle. Reading those parts of the application establishes the scope of the feature and where it belongs. The same understanding is needed later when implementing the integration and reviewing its behavior.

The tools shipped with coding agents reflect this work. Codex exposes shell execution through its exec_command handler, and its default base instructions explicitly recommend rg for text search and rg --files for file discovery. These are ordinary source-navigation operations that give the model access to the application it is working on.

OpenCode provides dedicated grep, glob and read tools for searching file contents, finding paths and reading sections of source. Together, these operations let an agent follow an implementation from its public interface through the code that performs the work. The model then uses what it reads to understand the design, check assumptions and decide what to inspect next.

The local workspace is only part of the application

An application’s behavior also depends on frameworks, database clients, authentication libraries, SDKs and their dependencies. These introduce design choices and constraints that the local application inherits. Understanding the application therefore requires following some of its behavior into code maintained elsewhere.

For the background-job feature, selecting a library involves understanding its retry behavior, concurrency model and shutdown process. Existing open-source applications also show how other teams have integrated it and where they have introduced their own abstractions. Comparing those implementations helps establish an appropriate design before committing to a library or building a custom solution.

That understanding carries into implementation and verification. The integration relies on the library’s extension points and lifecycle behavior, which have to be checked against the release being used. Later, upgrading the library means examining what changed and whether the original design assumptions still hold. Reading external code is part of this entire process.

Some of that source is available in installed packages or local caches. Other packages contain compiled binaries or generated JavaScript, with the original implementation and tests maintained in an upstream repository. There is also a versioning problem: a repository’s default branch does not establish how the installed release behaves. The investigation has to stay connected to the package and version the application actually uses.

A concrete example from credential storage

I saw the importance of this while investigating a bug in keyring-node, the native wrapper behind @napi-rs/keyring, with GitHits. The underlying libraries distinguished a missing credential from a storage-access failure or another platform error. At the JavaScript boundary, however, the wrapper called Rust’s .ok() on the password-read result, discarding the error information. Different failures consequently appeared to the application as null or undefined.

Following the versioned source through the wrapper and its underlying libraries located where that information was lost. The upstream fix preserves an absent password for NoEntry and propagates other password-read errors. This distinction matters to the application: an absent password and an inaccessible credential store require different handling. A local test that simply mocks an empty result leaves the difference unexamined.

A description of the library’s purpose would not explain that failure without covering the .ok() call. This is why I treat generated documentation as a lossy cache of the source: the summary discards detail and has to stay synchronized with the implementation. Architecture documentation should explain design intent and constraints, while questions about implementation behavior require reading the code that performs the operation.

Code discovery and verification infrastructure

We are building GitHits as code discovery and verification infrastructure for software factories and agents. It provides code, docs and package intelligence for open-source software, giving agents access to existing solutions and the implementations behind their dependencies. The same investigation they perform in a local workspace then extends to the external software involved in their decisions.

The value extends across the software development lifecycle. Discovering an existing implementation during planning informs what to build and what to reuse. Comparing how projects solve a similar problem exposes architectural tradeoffs. During implementation and verification, the questions become more specific to APIs, call sites and dependency behavior. Maintenance brings those decisions back into consideration as releases, dependencies and vulnerabilities change.

An agent with shell access also has the option of cloning repositories and downloading packages. GitHits provides a shared index and retrieval tools for this work across agents and stages of a software factory. Code search locates implementations, documentation explains API contracts, and package intelligence covers dependencies, releases and vulnerabilities. Local and private code stays within the agent’s workspace tooling.

Shared retrieval infrastructure also provides observability into how agents use open source. GitHits tool calls and their results show what an agent searched for, which sources it retrieved and the revisions or package versions returned. Recording those calls in the software factory’s traces gives teams a history of the external material the agent consulted. This traceability supports compliance work, including license and security reviews, and lets engineers examine the source context behind an agent’s decisions.

I used GitHits to find and read the Codex and OpenCode implementations linked in this post. Each link points to the exact revision I inspected. This is the same process an agent follows when checking a library recommendation or an integration design: locate the source, understand the implementation and explain how it supports the decision.

Trusting the work you delegate

Building a feature around an unsupported API wastes developer time and model tokens. The same problem starts earlier when a plan assumes capabilities a dependency does not provide, or later when an upgrade changes behavior the application relies on. Checking the software behind these decisions is part of the engineering work we are delegating.

For me, trusting that work requires understanding how the agent reached its conclusions. Which alternatives did it examine, which versions did it inspect, and how did it check its assumptions? Those details give me enough understanding to explain a library choice, defend an architecture and take responsibility for the resulting software.

This is why I consider code discovery and verification part of the infrastructure of a software factory. As agents take on more of the development process, their access to the code behind these decisions becomes essential. The engineer remains responsible for the outcome, and the agents doing the work need to read the software on which that outcome depends.