Reuse and architecture in the AI era

Reuse and architecture in the AI era: when code. Code output went up fast. The catch: production change still fails for the same reasons as 2019. Unclear boundaries, weak tests, messy data, and teams that can’t reason about behavior.

Most CTOs I talk to feel the tension. AI makes new code feel cheap, so reuse and architecture start to sound like “old rules.” That instinct burns teams. Architecture still matters, but the unit of reuse shifts. Outcomes matter too, but outcomes without constraints turn into outages, cost spikes, and compliance pain.

Is code reuse still worth it if AI makes code cheap?

“Code. AI assistants cut the time to get a working draft. AI assistants don’t cut the cost of owning that draft for 3 years.

Here’s a useful definition for 2026:

Reuse is any repeatable asset that reduces rework across releases without raising operational risk.

That asset can be code, but in AI-heavy systems it’s often something else.

What the data says about reuse and rework

The classic argument for reuse was never just speed. Reuse reduced rework and defects.

A University of Maryland study on object oriented reuse found lower rework effort for reused code, even when teams modified the reused components heavily. The report also found no observable difference between verbatim reuse and slightly modified reuse, from a total rework view (Basili et al., 1995).

AI changes how teams produce code. AI doesn’t change why rework happens. Rework still comes from misunderstandings, integration bugs, and missing constraints.

The AI era shifts reuse up the stack

AI pushes reuse away from “shared libraries” and toward “shared intent.” In practice, the best reuse targets in AI products aren’t code modules. They’re the artifacts that make behavior repeatable.

Five reuse targets I see paying back more than code reuse in AI-heavy products:

Evaluations. Golden datasets, scoring rubrics, and pass fail gates for model outputs.
Prompts and tool contracts. Stable tool schemas, input validation, and output types.
Retrieval assets. Chunking rules, metadata standards, and embedding models.
Workflow patterns. “On-rails” flows, routing, fallbacks, and human review steps.
Operational controls. Rate limits, caching, audit logs, and cost budgets.

ZenML’s roundup of 419 LLMOps case studies describes teams that win with evaluation-driven development and hybrid deterministic plus probabilistic designs, not with clever prompt hacks (ZenML).

Reuse still matters. The thing you reuse changes.

A quick decision matrix: reuse, rewrite, or generate

I use this matrix in architecture reviews. It fits on one slide.

Asset	Change rate	Failure cost	Best move	Why
UI glue code	High	Low	Generate	AI drafts are fine, tests catch regressions
Domain rules (pricing, eligibility)	Medium	High	Reuse as services	Bugs cost money and trust
LLM prompts	High	Medium	Reuse as versioned artifacts	Prompt drift breaks behavior
RAG ingestion pipeline	Medium	High	Reuse as platform capability	Data bugs poison many apps
Model selection logic	Medium	High	Reuse as policy + router	Cost and latency blow up fast
One-off scripts	High	Low	Generate	Delete later, don’t “productize”

Failure cost is the hinge. Cheap code still creates expensive incidents.

Does good architecture still matter for AI systems?

Good architecture matters more, because AI adds nondeterminism and new supply chains.

InfoQ’s 2025 architecture trends report calls out RAG adoption and the rise of agentic AI and small language models. The report also warns architects to watch AI-assisted development and citizen developers, since the barrier to shipping code dropped again (InfoQ trends report 2025).

Architecture is what keeps “fast code” from turning into “fast chaos.”

AI changes the failure modes

Classic systems fail in known ways. AI systems fail in weirder ways, and the weirdness is what hurts.

Silent wrong answers. The system returns fluent text that is false.
Data boundary leaks. RAG pulls the wrong doc set, or pulls too much.
Tool misuse. Agents call tools in the wrong order, or with unsafe inputs.
Cost cliffs. One prompt change doubles tokens and blows the budget.
Latency spikes. One extra model call adds 800 ms and kills conversion.

Agentic AI turns orchestration into a first-class architecture problem. InfoQ’s panel on 2025 trends frames agentic AI as a trust gap problem. Teams struggle to let nondeterministic software make important decisions (InfoQ panel video).

Architecture patterns that still pay back

Some patterns feel boring. Good. Boring patterns survive because they keep teams out of trouble.

Hexagonal architecture (ports and adapters). Keep domain rules testable and stable, while swapping models and vendors. The pattern still shows up in 2025 pattern lists for a reason (Medium pattern roundup).
Event-driven boundaries. Capture model inputs and outputs as events for audit and replay.
Cell based resilience. Limit blast radius when an agent goes off script.
Policy as code. Gate tools, data access, and output formats.

The AI twist: “ports” now include model calls, retrieval calls, and tool calls. Treat each one as a dependency with a contract, not as a casual SDK import.

RAG and data architecture are now product architecture

RAG isn’t a feature. RAG is a data product.

InfoQ calls out RAG as a common technique, and notes that architects design systems to accommodate it (InfoQ trends report 2025). DBTA’s 2025 Q1 survey framing also points to vector databases, knowledge graphs, and semantic layers as AI-enabling components that still need enterprise governance and security (DBTA survey webinar page).

One practical implication: the “reuse layer” for AI apps often sits in the ingestion and retrieval stack, not in shared UI components.

Is it all outcomes now? What changes for engineering leadership?

Outcomes matter. Output doesn’t.

AI tools create a trap for leaders. Teams ship more pull requests, so leadership assumes progress. The business only feels progress when behavior is stable, costs stay bounded, and risk stays inside guardrails.

A question that keeps coming up in exec staff meetings: should we relax architecture standards to move faster? Relaxing standards speeds up week one and slows down month three. The interest shows up as incident load and rewrite cycles.

The “Outcome Guardrails” model

Use this model to lead AI delivery without turning engineering into a feature factory.

Guardrail 1: Quality. Define evals that block releases.
Guardrail 2: Safety. Define tool permissions and data scopes.
Guardrail 3: Cost. Define token budgets and caching rules.
Guardrail 4: Latency. Define p95 targets per user journey.
Guardrail 5: Auditability. Log prompts, retrieval sets, and tool calls.

Product Talk’s writeup of lessons from AI product teams describes “on-rails” architectures that constrained what an LLM could do, since early models were error prone. That same writeup also describes teams building uncertainty and confidence management into the core system (Product Talk).

Guardrails are what make outcomes repeatable.

Citizen developers and AI-assisted development change governance

InfoQ replaced low-code as a tracked trend with AI-assisted development, and calls out the overlap with citizen developers. AI assistants make it easy to use APIs that were never designed for non-professional use (InfoQ trends report 2025).

That shift changes the work for leadership teams:

Platform teams need safer default APIs.
Security teams need better detection for shadow deployments.
Engineering leaders need clearer “what you can ship” rules.

If your org already struggled with internal tooling sprawl, AI will amplify the problem fast.

What should CTOs do: a practical playbook for reuse and architecture

Most teams need a reset. Not a rewrite. A reset.

Immediate actions (next 30 days)

Inventory AI entry points. List every model call, RAG endpoint, and agent tool. Track owners and environments in Command Center (/command-center).
Add eval gates to CI. Block merges on a small eval set. Start with 50 to 200 examples per use case. Use the same discipline as our guide to incident postmortems, but apply it to model failures (/tools/incident-postmortem).
Create a model router. Route cheap requests to smaller models, and hard requests to stronger models. ZenML’s Zoro UK example used a two-tier design, with Mistral 8B for classification and GPT-4 for complex sorting (ZenML).
Set a token budget. Put a dollar cap per workflow and per tenant. Use the Cloud Cost Estimator to model worst-case token spikes (/tools/cloud-cost-estimator).

Policy framework (what to standardize)

Versioned prompt artifacts. Store prompts like code. Require reviews. Tie prompt versions to eval results.
Tool contracts. Define JSON schemas for tool inputs and outputs. Reject unknown fields. Log every call.
Data access tiers. Separate public docs, internal docs, and regulated data. Gate retrieval by tier.
Release criteria. Require p95 latency, cost per request, and eval pass rate for release.

Policy work feels slow. Policy work prevents the 2 am incident.

Architecture principles (what to build once and reuse)

Shared RAG platform. Build one ingestion pipeline, one chunking standard, and one retrieval API. Treat it like an internal product. Track adoption and SLOs in our Engineering Metrics Dashboard (/tools/engineering-metrics-dashboard).
Ports and adapters for models. Hide vendor SDKs behind a thin interface. Swap models without rewriting domain logic. The pattern maps well to hexagonal architecture (Medium pattern roundup).
Hybrid deterministic core. Keep business rules in code, and use LLMs for language and fuzzy matching. OpenAI’s Forward Deployed Engineering work, as summarized by ZenML, leans on hybrid designs and long trust-building phases (ZenML).
Reuse through caching and plans. Cache LLM responses and reuse agent plans where safe. Research on plan reuse and response caching shows teams can reduce latency by reusing semantically similar responses, and can improve plan reuse by tracing tool execution steps (arXiv plan reuse mechanism).

A checklist you can reuse: “AI Reuse Readiness”

Run this checklist before you let five teams build five assistants.

Evals exist for each workflow, with pass fail thresholds.
Prompt versions are tracked and tied to releases.
Retrieval scope is explicit, with tiered data access.
Tool schemas are strict, and tool calls are logged.
Fallback paths exist for model errors and timeouts.
Cost budgets exist per tenant and per workflow.
Audit logs capture prompt, context, model, and output.

The checklist is boring. The checklist works.

Bigger picture: reuse is back, but it looks different

AI makes code generation easy, so teams confuse code with capability. Capability lives in constraints, data, and feedback loops. Reuse shifts toward those assets.

The next 12 months will push more teams toward agentic workflows, smaller tuned models, and RAG-first designs. InfoQ calls out all three as active trends for architects to track (InfoQ trends report 2025). That same shift raises the bar for governance, since more people can ship more code.

A CTO question worth asking isn’t “does architecture matter?” The real question is whether your org can ship AI features fast without losing control of cost, risk, and behavior.

What part of your AI stack do you want to reuse across 10 teams: code, or constraints?

Reuse and Architecture in the AI Era: When Code Is Cheap, What Still Matters?