Why We Stopped Adding Abstraction Layers to Our Dev Workflow

TL;DR: abstraction layers between our prompts and the model stopped saving time — see our dev abstraction layers comparison.

The Context

We spent the first half of this year experimenting with abstraction layers: prompt routers, context managers, and orchestration wrappers for AI coding tools. The pitch is attractive: abstract the grunt work, ship faster. The reality is that every layer introduces a failure mode you don’t control.

What We Tested

Tool	Use Case	Verdict	Why
Custom prompt router	Multi-model routing	❌	Hard to inspect; failures were opaque and hard to reproduce
Direct MCP calls	Context lookup	✅	Fast, predictable, debuggable
CLAUDE.md project files	Persistent context	✅	Version-controlled, readable, merges cleanly

The Pivot Point

The router misrouted a model-sensitive prompt to the wrong provider and returned an error we couldn’t attribute. It took an hour to trace. The same task, done directly, took one call and an obvious log line. That hour broke the abstraction ROI.

What We Use Now

Direct integrations. We call the model APIs or CLI tools we need, maintain project context in plain markdown files under git, and avoid middleware unless it is paying explicit rent. Our config surface is under a dozen files.

When You’d Choose Differently

If you are running a fleet of agents with different model or capability needs, abstraction may be necessary. We are not there yet. For organizations with strict compliance or audit requirements, a wrapper that enforces policies may be worth the opacity cost.

Tool Crucible Rating

Overall: 3 / 5
Ease: 4 / 5
Value: 2 / 5
Support: 4 / 5

---

This is part of our dev abstraction layers evaluation series. See full comparison: Dev Abstraction Layers