Ways of Working — SDD · TDD · Agentic

Three concepts, one sentence each:

SDD = write the spec first ·

TDD = write the test first ·

Agentic = the engine that runs both.

Pick SDD or TDD per task; Agentic is always on.

wow-bigpicture

Which mode? (the one decision that matters)

wow-decision

At a glance

SDD (spec-first) TDD (test-first) Agentic (engine)

Write first

the spec/design

a failing test

— (it runs SDD/TDD)

The "contract" is

the approved SDD

the test

the standard + skills + gates

Best for

new module/feature · cross-cutting · contract/schema change · unknowns

bug fix · one business rule · protocol msg w/ known spec · bounded change

every task — it’s how we deliver

Gate before "done"

CTO approves SDD before code

red → green → refactor

audit + /code-review + tests before report

FT grade

architecture-led

TDD-led

ft-developer grades (architecture-led / TDD-led / simple-addition) & orchestrates

❌ Don’t when

it’s a one-line fix (over-process)

the design is unknown (you’d test the wrong thing)

n/a — it’s always on; the only misuse is skipping a gate (no SDD, code without tests, or --no-verify)

SDD — spec-first ⭐

For work where getting the design right matters more than typing speed. The spec is reviewed and approved before any code; see how to write one.

wow-sdd
Live example — a 6-line SDD skeleton
Goal   : bulk-disable CPEs by serial list (ops needs it for incidents)
Scope  : in = REST endpoint + service; out = UI, scheduling
Design : new api/Cpe action `disable` (PUT), batch via existing CpeWriteService; no new dep
Data   : no schema change; audit cols already present; one IT against the emulator
Tests  : should_disable_all_when_serials_valid; should_report_unknown_serials
Risks  : large lists → cap at 1000 (J-DB batch tier)

TDD — test-first

For work with a known expected behaviour. The failing test pins the spec; you write the minimum to make it pass, then refactor with the test as a safety net.

wow-tdd
Live example — red → green
// RED — write this first, watch it fail
@Test @DisplayName("rejects a write to a read-only path")
void should_reject_when_path_is_read_only() {
  var result = handler.apply(new WriteTaskRequest(READ_ONLY_PATH, value));
  assertThat(result).isInstanceOf(OperationResult.Denied.class);
}
// GREEN — minimal guard in WriteTaskHandler, then refactor

Agentic — the engine that runs both

Agentic isn’t an alternative to SDD/TDD — it’s how the work gets done: detect → grade → (SDD or TDD) → delegate to the stack coding agent (which reads the authoritative skill) → verify behind the same gates. Full fleet in Claude Toolkit.

wow-agentic
Guardrail What it guarantees

Approval gate (every grade)

no production code is delegated before the user approves the plan — the verified SDD for architecture-led, a mini-plan confirm for TDD-led / simple-addition

Requirements elicitation

every blocking unknown is asked before design; assumptions are explicit in SDD §0

Adversarial checkpoints

independent verifier lenses attack the SDD (checkpoint D) and the final diff (checkpoint F) on architecture-led tasks; bounded convergence, never an endless loop

Authoritative skills

the coding agent enforces ft-java-standards / ft-angular-standards

Tests with the code

ft-*-coding-agent never ships code without tests (≥80% diff coverage)

Test-adequacy adversary

after the coding agent reports green, ft-test-adversary (read-only) attacks the delivered tests to prove them insufficient — honest-RED, negative/observability, regression-guard, seam composition, challenged assumptions, emulator-leniency, skip-gate — and its missing-test briefs are re-delegated until it finds nothing new. Distinct from /code-review (reviews the diff, not the tests). Shared canon — the same agent runs on the bugfix pipeline’s Gate B, so both pipelines get the identical test-adequacy attack

Audit + review

the baseline gate (no NEW failures vs baseline) + ft-architecture-audit + /code-review before the orchestrator reports
Next → Writing an SDD · Java standard · the agent fleet.