Glue for Spec Writing

By Priya Shankar

Product specs that ignore the existing codebase cause rework. A product manager codebase gap means specs describe desired behavior without accounting for current architecture, existing capabilities, or technical constraints. Engineers read the spec, realize it conflicts with how the system actually works, and the negotiation begins. Glue eliminates this pattern by giving product managers direct insight into the code so that specs are grounded in reality from the start.

Rework is the silent tax on product development. Studies estimate that 20 to 40 percent of engineering effort goes toward work that could have been avoided with better upfront specifications. The root cause is not careless PMs or uncommunicative engineers. It is a structural problem: the people who write specs and the people who build from them operate with different information about the system.

Specs cause rework through three common patterns.

Duplicating existing capability. A PM writes a spec for a feature that partially or fully exists in the codebase. Engineering begins work, discovers the overlap, and must decide whether to build on top of the existing code (which the spec did not account for) or start fresh (wasting the existing implementation). Either path costs more than a spec that acknowledged the existing code from the start.

Conflicting with architecture. A PM designs a workflow that requires data to flow in a direction the current architecture does not support. The spec reads beautifully from a user perspective but requires architectural changes that the PM did not know about and the engineer did not anticipate during estimation. The project scope expands mid-sprint.

Underspecifying edge cases. The codebase handles dozens of edge cases that accumulated over years of production use. A spec that describes the happy path without referencing these existing edge cases forces engineers to make unguided decisions about whether to preserve existing behavior or let the new spec override it.

All three patterns share a root cause: the PM lacked visibility into the codebase when writing the spec. Product managers are not expected to read code, but they do need access to what the code represents. That is what Glue provides.

Glue inserts codebase context into the spec-writing process at three critical points.

Before writing: Discovery. Before starting a spec, a PM can ask Glue what exists in the codebase related to the planned feature. Glue returns relevant endpoints, components, data models, and business logic. This survey prevents the PM from designing something that conflicts with or duplicates existing code.

During writing: Validation. As the PM drafts the spec, Glue can validate assumptions. "Does our API support pagination on this endpoint?" "What data does the user profile object currently contain?" "Which services touch the billing workflow?" These questions get instant, accurate answers from the code rather than requiring a Slack conversation with an engineer.

After writing: Estimation support. Once the spec is complete, Glue analyzes it against the codebase to identify which files and modules will need to change. This file-level impact analysis feeds directly into effort estimation, making the handoff from spec to planning seamless.

Glue also flags potential conflicts. If the spec implies a data model change that would affect three other features, Glue surfaces this dependency before engineering begins work. This early detection is where the biggest time savings occur.

A spec written with Glue looks different from a traditional one in several ways.

It references existing code. Instead of describing desired behavior in isolation, the spec notes which existing components will be modified and which new ones must be created. This gives engineers clear starting points.

It acknowledges constraints. The spec explicitly notes architectural constraints that shaped the design. "The notification service is event-driven, so the new feature will publish events rather than making synchronous calls" demonstrates that the PM understood the system.

It addresses edge cases. Because the PM explored the existing code before writing, the spec accounts for edge cases that the current system handles. Engineers do not have to guess whether to preserve or override existing behavior.

It includes impact analysis. The spec comes with a Glue-generated list of files and services likely to be affected. This serves as a starting point for engineering planning rather than a mandate, but it demonstrates that the spec was written with the codebase in mind.

This level of grounding builds trust between product and engineering. When engineers see that a PM has done the homework, the trust gap narrows. Estimation conversations become collaborative rather than adversarial. Fewer surprises emerge mid-sprint.

How does Glue help write better specs? Glue gives product managers visibility into the codebase during spec writing. PMs can discover existing capabilities, validate assumptions, and identify affected files before the spec reaches engineering. This grounding reduces rework caused by specs that conflict with or ignore the current system.

Can Glue generate specs automatically? Glue does not generate complete specs. It provides the codebase context that makes specs accurate: what exists, how it works, and what would need to change. The product judgment about what to build and why remains with the PM.

How do specs reduce rework? Specs grounded in codebase reality reduce rework by preventing three common problems: duplicating existing capabilities, conflicting with current architecture, and missing edge cases the system already handles. When specs account for these factors upfront, engineering builds the right thing the first time.