Towards Data Science iconTowards Data ScienceSep 27, 2026 ~7 min source read

Good Architecture Deletes the Signals Your Agent Depends On

Well-structured codebases remove the textual cues retrieval-based agents rely on. That makes similarity search the wrong tool for finding what a change will break.

Share this story

Send the public story page.

Useful takeaways from this story.

Similarity-based retrieval finds code that looks like your query, not the code that will break when you change something.

Import graphs and repository boundaries also break discoverability: references can point outside an index or collapse into package artifacts that contain no consumer text.

# The problem in one sentence Similarity search answers "what looks like this?" but agents need "what will break if this changes?". Those are different questions and require different signals.

# Why similarity retrieval fails

DORA's 2025 State of AI-assisted Software Development report is cited: developers save time during generation but re-spend it on auditing and verification, and about 30% of developers reported little or no trust in AI-written code. The author isolates one structural cause: tooling expects overlap in vocabulary that architecture intentionally removes.

# Two sets that matter The article separates two sets of files:

  • The resemblance set: files that look like the query. Retrieval is optimized for this.
  • The impact set: files that will break when the target changes. Agents need this.

These sets overlap less than tooling assumes. For example, a theme file and a button may share no words, yet changing the theme contract breaks the button. Conversely, two validators written at different times may look alike and confuse an agent into reconciling them incorrectly.

# How good architecture hides signals

The author lists real shared artifacts across product scopes: visual primitives, a theme, a build environment, a running widget in another product, and a backend service in a different product. The more valuable and cross-cutting the artifact, the less it resembles its consumers. Those are exactly the things a code-change impact analysis must find, and similarity search performs worst on them.

# Why imports and package boundaries don't solve it Reading imports helps, but it breaks two ways and gets worse as systems become better assembled. Imports may exist but be followable only through build-time artifacts, package resolution, or monorepo boundaries that aren't indexed. Or imports resolve to a published package where consumer text is absent. A change that touches a build environment or runtime service can reach many components, yet none of those consumers contain text resembling the environment files.

# Practical implication

# Bottom line Good architecture removes the textual signals similarity-based agents rely on. If you want agents that change code safely, you must give them tools that find dependency impact rather than similar text.

More context around this story.

Multi-Agent Systems: Architecture Patterns for Developers
Dzone iconDzoneSep 18, 2026

Multi-Agent Systems: Architecture Patterns for Developers

Most production agent projects do not fail because the model is weak. They fail because one agent was asked to hold too much at once: routing, planning, tool use, memory, and error recovery all inside a single growing prompt. By 2026, this failure mode shows up in nearly every engineering retro, and the fix is usually

Loading more related stories...

Keep reading in the app

Open the app view to save this story, compare related coverage, and continue from the same source.

Open in app