The discovery tax: why AI's biggest win in software engineering isn't writing code

Software engineers spend surprisingly little time writing new code.

A feature request usually begins with a search. Teams read product requirements, inspect repositories, compare deployments, trace service dependencies, and revisit old architecture decisions before touching a production system. The implementation frequently takes less time than assembling the context required to perform it safely.

This is not a new observation. Program-comprehension research has measured it for over a decade. Xia et al. (IEEE TSE, 2018) instrumented professional developers and found that roughly 58% of their development time went to comprehension rather than authoring. The information foraging theory has modelled programmers as foragers following "scent" through unfamiliar systems since the late 2000s. 

What's new is that we finally have tools good at foraging – let’s explore this in more detail.

The missing layer of the software development lifecycle

Software development lifecycle diagrams show planning, architecture, development, testing, deployment, and maintenance as a sequence of activities. They explain how software moves from an idea to production. What they don't show is the work that happens before every technical decision.

Every phase begins by gathering context.

Planning teams review product requirements, customer feedback, analytics, and previous initiatives before estimating effort. Architects inspect existing services, API contracts, Architecture Decision Records, and infrastructure definitions before proposing a design.

The same is true for testing, deployment, and maintenance.

The lifecycle looks linear on paper. In reality, every stage starts with discovery.

The artifacts change from row to row. The underlying loop does not:

(IMAGE)

A feature request illustrates this process.

A product team asks for promotional pricing in an existing checkout service. The change may amount to a few dozen lines in the pricing engine. Before opening an editor, an engineer needs to know:

• which service owns pricing calculations, and who owns that service today;
• what the OpenAPI specification promises to downstream consumers;
• what recent pull requests changed in the pricing path;
• what the relevant ADR says about why the current pricing model exists;
• how feature flags differ across development, staging, and production;
• whether events, caches, or reporting pipelines depend on the current response shape.

Only after these activities can implementation begin with confidence.

Production support follows the same workflow.

Suppose the checkout service starts returning elevated latency shortly after a deployment. Engineers do not begin by changing code. They begin by assembling evidence from multiple engineering systems.

The objective is not to collect information for its own sake. Each artifact contributes another piece of context that helps engineers evaluate possible causes, eliminate false assumptions, and choose the safest course of action.

What is the discovery tax?

Standard engineering metrics such as deployment frequency, lead time, pull request throughput, change failure rate, and incident resolution time measure visible delivery. They tell us what happens after engineers understand the problem.

What they don't capture is the work required to get there.

The Discovery Tax is the time spent gathering, verifying, connecting, and interpreting technical information before an engineering decision can be made.

Every feature, architecture review, deployment, and production incident begins with this work. It's essential to software development, yet it rarely appears in delivery metrics despite shaping almost every engineering workflow.

The first four activities create context. The final two create software that customers can use.

One clarification, because the word tax can be misleading. 

Discovery is necessary non-value-added work in the Lean sense, much like compilation or testing. It doesn't directly create customer value, but it can't be skipped either. If you skip discovery, the time usually comes back later as debugging, production incidents, or a postmortem.

The Discovery Tax also grows with system complexity. A single repository behind one deployment pipeline is relatively easy to understand. An enterprise platform with hundreds of services, shared libraries, asynchronous messaging, infrastructure as code, multiple deployment pipelines, feature flags, and distributed ownership is a very different story.

This is also where much of an experienced engineer's advantage comes from. On an unfamiliar codebase, they're not necessarily better at writing code. They already know where to look: which repository owns a service, where the Architecture Decision Records live, which team maintains a component, or which production incident explains why the system works the way it does.

AI is particularly effective during discovery because it quickly connects information that is normally scattered across engineering systems. Repositories, documentation, API specifications, pull requests, deployment history, and operational telemetry become part of the same investigation.

With more relevant context available from the start, engineers can make technical decisions faster and with greater confidence.

In parallel, engineers continue to evaluate trade-offs, approve changes, and accept responsibility for technical decisions. That remains true even as AI capabilities improve. Recent research found that LLMs can still misjudge requirement conformance during code review, leaving engineers responsible for evaluating recommendations and making the final decision.

Why every engineering task starts with discovery

(IMAGE)

Enterprise software generates a growing body of technical knowledge throughout its lifetime. Product requirements, architecture decisions, source code, deployment history, production telemetry, and incident reports all contribute to how a system evolves.

Engineers rely on this knowledge every day, yet it is rarely stored in one place. Answering a single technical question often requires navigating multiple repositories, documentation systems, and operational tools before implementation can begin.

A seemingly simple feature request demonstrates how quickly discovery expands.

Task: Add a new optional field to the Customer API.

The implementation may involve changing a few files. Before making those changes, the engineer needs to understand how customer data flows across the platform.

Together, these artifacts provide the information needed to make a safe engineering decision.

Large enterprise platforms make this process more demanding because engineering knowledge is distributed across many systems. A developer rarely finds every answer in a single repository. Relevant information may live in documentation, source control, deployment history, observability platforms, architecture diagrams, infrastructure definitions, and previous production incidents.

A single implementation task often follows a workflow similar to this.

(IMAGE)

By the time implementation begins, most of the engineering investigation has already taken place.

This observation aligns with recent developer research. Microsoft Research found that developers consistently want AI assistance with documentation, code understanding, debugging, operational work, and information gathering instead of focusing exclusively on code generation. The requested capabilities closely match the discovery activities shown above.

The discovery loop found in every SDLC phase

The same engineering workflow appears throughout the software development lifecycle. The technical artifacts change from one phase to another, yet the objective remains consistent: gather enough context to make a well-informed decision.

Although each phase uses different tools, the engineering workflow remains remarkably similar.

(IMAGE)

This recurring workflow explains why AI has gained traction across software engineering. Large language models perform well when information already exists but remains scattered across repositories and engineering systems. Documentation, API specifications, infrastructure definitions, deployment records, production telemetry, and historical pull requests can all be searched, summarized, and connected into a coherent explanation.

The value of AI extends beyond generating code because coding occupies only a fraction of software engineering. Microsoft found developers spend roughly one-tenth of their workday writing code, yet many AI products still focus almost exclusively on that activity. The researchers describe this boundary as bounded delegation. 

Google adds another perspective: developers spend a median of two hours each day using AI, and more than 80% report higher individual productivity. 

Those findings reinforce the Discovery Tax.

AI compresses the work required to assemble context.

Engineers remain responsible for interpreting that context and making the decisions that shape software systems.

How AI changes the cost of engineering decisions

There's a reason people say time is money. In software engineering, time is often spent buying enough confidence to make the next decision.

Before a single line of code is written, engineers trace dependencies, review previous changes, inspect production behavior, and validate assumptions. AI shortens this phase by making the relevant engineering knowledge available much earlier.

This changes the speed of several engineering activities.

Notice that none of these examples involve generating production code.

Let’s review how it works on some practical use cases.

Use case: Understanding change impact

A product owner asks for a field in the OrderCreated event to be renamed.

Under every standard schema-registry compatibility mode, a rename is a breaking change. The actual implementation is: add the new field, dual-publish both, migrate consumers, and deprecate the old one after a transition period. 

The real task is figuring out who those consumers are, how they use the field, which services can be migrated together, and what dependencies could be affected. The implementation is usually straightforward.

That question is pure discovery, and a good assistant returns something like:

(IMAGE)

Two things about that output are deliberate. 

First, it separates what was retrieved from what was inferred. 

Second, it names the source and the age of each fact.

Use case: Production incident investigation

A latency alert on the checkout service normally means opening dashboards, traces, deployment history, Kubernetes eve

Correlated into one timeline:

Note the percentile. “Database latency increased” is not a finding – p50 moving and p99 moving are different incidents with different causes and different fixes, and any timeline that omits which one moved is decoration.

Two prerequisites also deserve to be said out loud. Correlating deployments with traces requires your CD system to emit deployment markers into your observability platform, which many don't. 

And if you use head-based trace sampling, the slow requests may simply not be in the dataset. AI does not fix missing telemetry; it inherits it.

Use case: Architecture reviews

Architecture reviews frequently begin by reconstructing historical decisions, which may involve:

• related Architecture Decision Records
• previous design proposals
• existing implementation patterns
• affected services
• known operational constraints
• historical production incidents
• engineering teams responsible for each component

With that context available from the start, the discussion can move directly to evaluating alternatives. Better context leads to better decisions, earlier identification of implementation risks, and more productive architecture reviews.

It all sounds fairly straightforward: connect the engineering systems, let AI assemble the context, and make discovery faster.

In reality, that's where the interesting engineering begins (or, what we call “interesting”). A discovery platform is only as useful as the information behind it:

• Complete coverage. Missing repositories, services, or runtime metadata leads to incomplete answers.
• Trustworthy evidence. Every answer should link back to its source so engineers can verify it quickly.
• Fresh data. Deployment history, ownership, and production state need to reflect the system as it exists today.
• Enterprise readiness. Permissions, compliance, and auditability need to be built in from the start.

Engineering readiness starts with your existing engineering knowledge

One question comes up in almost every conversation about AI adoption:

"How do we prepare our engineering organization?"

In our experience at TYMIQ, the answer is not "add more AI." The organizations that see the biggest gains already have strong engineering practices. AI simply makes those practices more accessible.

The engineering artifacts below already exist in most mature organizations. Together, they provide the evidence AI needs to accelerate discovery.

One caveat applies to every artifact in this table: they age. Teams reorganize, services change, and yesterday's design decision becomes today's legacy. AI has no way of knowing what's still true and what's quietly gone stale.

That's why the goal is engineering knowledge that's maintained, connected, and easy to verify. Those practices benefit every engineering team, with or without AI.

In a nutshell

Software development was never mainly about writing code. Every meaningful change starts with understanding a system well enough to decide how it should change.

That is where AI earns its keep: compressing the effort required to find, connect, and interpret engineering knowledge, so the path to an informed decision gets shorter. The engineer still makes the decision, accepts the risk, and owns the outcome – and given what the throughput data says about the alternative, that division of labor is a feature rather than a limitation.