Episode 32: Where does Spec Driven Development fit?

Published: Saturday, May 16, 2026 • Duration: 55 minutes • Season 1

My first spec kit (SDD) project: https://github.com/kaihendry/ai-check-guardrails

0:00 - Introduction to Certification Challenges 0:20 - Experience with Microsoft SQL Server Certification 0:46 - Discussion on Corporate Certification Requirements 1:06 - Trust Issues with Certifications 1:35 - Learning from Exam Questions 1:59 - Security Events Data Management 2:26 - Setting Up Kinesis Stream Endpoints 2:51 - Slack Notification for Unusual Activity 3:14 - Security Tooling and AWS Organizations 3:44 - Shared Services Account and Control Tower 4:45 - Root Account Access and Security 5:44 - New Role in Security Administration 6:08 - Spec Driven Development Concerns 6:40 - Changes in SpecKit and Skills 7:24 - Commands and Skills in Anthropic 8:11 - Handoffs in Cloud Code 9:04 - Onboarding Flow in SpecLedger 10:06 - Spec Driven Development Workflow 11:09 - Bug Fixing and Workflow Efficiency 12:20 - Impact Assessment and Planning 13:29 - Feature Branch Management 14:35 - AI Agents and Process Flexibility 15:51 - Expertise and Process Adaptation 16:43 - Git Commit Hooks and History 17:26 - SpecKit Documentation and Maintenance 18:14 - Spec Drift and Project Principles 19:25 - Documentation and End-to-End Tests 20:44 - Quick Start and CLI Testing 21:15 - Constitution and Process in SpecLedger 22:21 - Monorepos and Hexagonal Architecture 23:13 - Alignment Driven Development 24:22 - Workspaces and Debugging in VS Code 25:43 - SpecKit Archive Command 26:24 - Task Management in SpecLedger 27:32 - GitHub App and Task Visualization 28:21 - Beats and Task List Management 29:52 - Multiplayer Development Vision 30:34 - Shared Group Chat and User Stories 31:47 - Clarify Command in SpecLedger 32:15 - Metadata and Comments in SpecLedger 33:05 - Visualization of Development Phases 34:10 - Mockup UI and Design in SpecLedger 35:17 - UI Changes and Future Plans 36:27 - Comments and Collaboration in SpecLedger 37:04 - Open Source and SuperBase Architecture 38:08 - SQLite and Database Management 39:25 - Distributed SQL Database at the Edge 40:44 - Security and Package Management 41:29 - Local Privilege Escalation and Patching 42:30 - Zero Day Exploits and Remediation 43:37 - Defense in Depth and Security Tools 44:41 - AWS Inspector and Wiz.io 45:42 - Public IPs and Security Risks 46:27 - Nginx and Web Server Security 47:13 - Security Chat Groups and Risk Assessment 48:05 - 10stack Hack and Package Verification 49:12 - OIDC and Security Posture 50:11 - Caching Techniques and Security Risks 51:31 - Poisoned Package and Cache Exploits 52:07 - AI and Repository Misconfigurations 53:22 - Dependency Management and Security Scans 54:18 - Dependabot and Security Vulnerabilities

https://dabase.com/podcast/

Watch on YouTube

`summarize "https://youtu.be/osM0n8gxPAI" --timestamps --slides`

Quick take: a long conversation that mixes practical AWS security learnings with a detailed, experience‑level critique of Spec Driven Development (SDD) tooling (SpecKit, Spec Ledger and others). Major themes: certs and why they can mislead; concrete AWS features the speaker only learned via exams; how SDD can work (onboarding, handoffs, agent skills) and where it breaks in real teams (huge feature branches, spec drift, bad commit metadata, task sync conflicts). The speaker offers concrete mitigations: use executable tests as the source of truth, enforce a constitution rule that plans update docs/tests, scope features tightly, and prefer per‑spec task data to avoid merge churn. I never trust someone who has a certificate.

Certificates, early career pressure and exams

The host recounts being forced to collect many certifications quickly (five certificates in three months), each exam asking for “three to six years” experience; one anecdote: scoring 100% on a Microsoft SQL Server 2005 exam and worrying it would be revoked. The takeaways: exams teach some useful, obscure tooling (the speaker only learned about CloudTrail Lake from an exam), but certificates are an imperfect signal of skill and can create hiring/organizational pressure.

Practical AWS security features learned

Concrete AWS notes: CloudTrail Lake (audit-event data lake) vs dumping logs to S3 + Athena; out‑of‑the‑box security tools exist (GuardDuty, Security Hub); AWS Organizations supports delegating security or IAM responsibilities to specific accounts; best practice is separating management/DevOps/shared services accounts (CDK pipelines often recommend a pipeline account); Control Tower provides aggregation and default controls; you can restrict or temp‑gate root user access—overall the speaker is brushing up for a security‑focused role with AI tooling oversight.

Spec Driven Development — commands, skills and handoffs

Experience with SDD tooling: started on SpecKit, then explored alternatives (Spec Ledger, Opus, agent shells). Key technical point: many systems moved prompts into “skills” so slash commands load a skill; handoffs between phases (specify → plan → implement) are explicit and used to refresh context; onboarding can be automated: an explore agent inspects repo layout and suggests principles. Using a large context window (million‑token models) makes these handoffs and long onboarding flows smoother.

Where the SDD process slows you down

Operational friction the speaker hit in practice: small fixes shouldn’t always trigger a full SDD specify→plan→implement flow. Their pattern: continue the main feature work and spawn a parallel agent session or a Git worktree to file/handle a quick bug in “plan” mode only. Problems observed: long, multi‑domain feature branches that never land; giant PRs; auto‑commit hooks that write opaque commit messages (e.g., many commits labeled generically by the tool), so the Git history isn’t the useful granular audit trail they expected.

Spec drift, docs vs executable specs, and task conflicts

Solutions and engine-level design choices: avoid spec drift by making docs and tests part of the plan’s final tasks and enforcing it in a project constitution; one effective pattern: generate a QuickStart MD per spec and keep it synced with an E2E test suite so docs are executable — The tests are the source of truth. Task tracking lessons: using a single repo‑wide task list (beats style) caused frequent merge conflicts; Spec Ledger moved to per‑spec JSONL task files so each feature contains its own task graph and avoids sync‑branch churn.

Multiplayer, mono‑repo tradeoffs and UI ideas

Multiplayer workflow notes: a web UI that organizes artifacts by SDD phase (specify, plan, tasks, changes) helps reviewers know what to read first; threaded comments can be attached to selections in spec artifacts and pulled back into agent clarify flows so the agent can resolve open questions. Mono‑repo setups and editor workspaces (VS Code workspaces) make cross‑component development and debugging easier, though language servers and debuggers sometimes need careful config. The speaker stresses experimentation—try different SDD tools, but be ready to tune constitution rules, test hygiene, and scoping to avoid the common pitfalls described.

Model: openai/gpt-5-mini