Leverage the best available tool; don't reinvent substrate
Status: open/published
Summary
Section titled “Summary”- Leverage external tools and agents being built by parties with more resources; don’t build parallel implementations.
- sdlc’s differentiation is the planning model (entities, contracts, relationships) and the zero-infrastructure coordination substrate; the coding agent, the review surface, and the version store stay leverage points.
- Adapter-shaped interfaces preferred; today’s prose skill becoming tomorrow’s thin adapter to an external engine is fine.
- Deliberate complement to P-0008-harness-agnostic-substrate: leverage liberally, but build abstraction proportional to swap risk. Heaviest abstraction in the LLM-tool dimension; lightest for standardized deterministic tools where swap is cheap.
Statement
Section titled “Statement”When external tools, frameworks, or agents are being built by parties with vastly more resources, SDLC’s architectural posture is to leverage them (via strategy patterns, adapter layers, or direct integration) rather than build parallel implementations. This holds even when leveraging means today’s prose skill becomes tomorrow’s thin adapter to someone else’s deterministic workflow engine.
Agentic-coding tooling is being developed at scale by Anthropic, OpenAI, GitHub, and dozens of others. A solo project that tries to build parallel implementations of orchestrators, workflow executors, LLM-provider abstractions, or coding-agent harnesses will lose on both quality and cadence, and the work doesn’t compound because the parallel implementation has to chase whatever the leaders ship.
The carve-out: the coordination substrate.
D-VSLI-distributed-work-runner-architecture builds a scheduler and a work-runner
engine rather than adopting one. That is this principle applied, not an exception to
it. No external engine supplies durable coordination with no server, no broker and no
database, over git refs and markdown (github-ref-leases/README) — every candidate
in D-VSLI’s prior-art table requires a hosted control plane or a database as system of
record. Where prior art does supply the semantics — Temporal’s event-sourced runs,
Orleans’ virtual actors, OTP supervision, Kubernetes reconcile loops, Airflow’s trigger
vocabulary — it is adopted as semantics over the substrate already shipped.
The rule this yields: leverage the semantics, build only the layer no one ships — and name the missing property before claiming the carve-out. “Nobody’s is quite right” does not qualify; “nobody’s runs without a server” does.
The architectural payoff of leveraging is asymmetric: when an external tool reaches a higher progression stage for a workflow than sdlc’s own implementation, swapping in is a net win. The cost is the discipline of building adapter-shaped interfaces rather than hard-coded integrations, the same discipline P-0003-pragmatic-architecture already demands.
How it applies
Section titled “How it applies”- The plugin architecture is harness-agnostic (P-0003-pragmatic-architecture). The data model and validators don’t depend on Claude Code; another harness can read the same artifacts. This is leverage by design: Claude Code is the harness today because it’s the best available; it’s swappable because the substrate doesn’t depend on it.
- Strategy patterns are the preferred integration shape for
orchestrators and workflow executors. The same task lifecycle can be
driven by sdlc’s own
task-workskill or by an external orchestrator that exposes equivalent primitives, because the task’s state, lease, and PR-open contract are all externally observable. - Avoid building things that aren’t differentiating. sdlc’s differentiation is the planning model: entities, contracts, and the relationships between them. Coding agents, IDE integration, test runners, and CI infrastructure are all leverage points, not build points.
Examples
Section titled “Examples”- Claude Code as today’s harness, rather than building one from scratch.
- GitHub PRs as the review surface, rather than a custom review tool.
- Obsidian as the editing/rendering UI, leveraging its transclusion, link graph, and Bases features.
- git as the version store; no custom revision system or DB-backed history.
- Astro Starlight for the public docs site under
site/(when site work resumes).
Implications
Section titled “Implications”- The deterministic workflow engine is built here rather than adopted (D-VSLI-distributed-work-runner-architecture), because no third-party engine runs on the zero-infrastructure substrate. That door was left open and then deliberately closed on the evidence — see the carve-out below. The agent driver, the coding agent, the review surface, and the version store remain leverage points.
- The “natural progression” in P-0001-prefer-deterministic-over-llm explicitly contemplates Stage 4 implementations that are external: the LLM-as-tool role can be filled by sdlc’s own scripts or by an external agent platform.
- Concrete implication for skill design: when a skill could be written as a thin adapter to an external capability OR as a full re-implementation of that capability, the adapter form is preferred. The adapter is shorter, easier to swap, and gets better when the underlying tool gets better.
- Deliberate complement to P-0008-harness-agnostic-substrate, not contradiction. P0004 says lean toward off-the-shelf so we don’t reinvent substrate; P0008 says keep the substrate shaped so LLM suppliers and harnesses can be swapped when the landscape shifts. Together: leverage liberally; build abstraction proportional to swap risk. The abstraction layer is heaviest in the LLM-tool dimension (rapid provider churn, supplier risk) and lightest for standardized deterministic tools (git, GitHub, Python) where swap is cheap.
- Leveraging Claude Code today (provider-specific) is consistent with the principle because the substrate doesn’t depend on Claude. If a leverage decision would couple sdlc’s substrate to a specific provider, the leverage decision is the wrong shape.